[00:00] <mok0> hehe :-)
[00:00] <superm1_> according to http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html, it seems %U is for urls whereas %F is for a list of files directly
[00:00] <mok0> I want to upload the near-perfect theseus package before ending tonite
[00:00] <superm1_> so i think that %U makes more sense since it appears it can take either or
[00:00] <norsetto> superm1_: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
[00:00] <superm1_> do you agree?
[00:01] <norsetto> superm1_: yes, it makes sense
[00:02] <superm1_> okay i'll finish this merge then now :)
[00:03] <norsetto> oh well, that was the coup de grace
[00:04] <norsetto> g'night all .....
[00:04] <superm1_> night
[00:05] <azeem> 33
[00:05] <azeem> oops
[00:16] <mok0> Well goodnight folks, it was good fun
[00:18] <jdong> that's what... that's what.... *must resist* ahhh that's what she said!
[00:19] <mok0> jdong: :-) hehe
[00:34] <persia> mok0: About theseus: why gawk vs. mawk?  mawk is smaller and more efficient for most cases. (doesn't really matter: I just couldn't resist the challenge)
[00:57] <dsop> some reviewer online?
[01:03] <persia> dsop: Yes.  Which package?
[01:09] <bddebian> Hey folks.  Anyone familiar with/run OpenSUSE?
[01:10] <bddebian> persia: My buddy!! :-)
[01:10]  * Fujitsu stabs bddebian over to #opensuse
[01:10] <persia> bddebian: I haven't run SUSE since before Novell had an interest.  Can't really help you here.
[01:11] <bddebian> persia: No I still have to bug you about comixcursors ;-P
[01:11]  * StevenK has never run SuSE
[01:11] <persia> bddebian: The preinst / postinst still doesn't work?
[01:11] <dsop> persia: gcutils
[01:11] <bddebian> I don't want to run SUSE, I want to figure out if they have patch clanbomber to build against clanlib 0.8
[01:12] <bddebian> persia: No, I suck :-(  I think it should work.
[01:13] <persia> dsop: It's best when advertising your package to put something like: "Could a reviewer please look at http://revu.ubuntuwire.com/details.py?package=gcutils ?  I've addressed the last set of comments, and am looking for my first advocate".  I'll take a look, and let you know if I see anything in particular.
[01:13] <persia> bddebian: The CVS is fairly easy to read, and the patches reasonably organised.  Take a look :)
[01:14] <dsop> Okay persia, please can you review my package http://revu.ubuntuwire.com/details.py?package=gcutils. I tried to fix things and i'm looking for an advocate.
[01:14] <dsop> persia: for sure you are right, i've to be friendly
[01:15] <persia> dsop: Just comparing the debdiff to the last comments, I don't see the changes for the manpage differentiation.
[01:15] <dsop> persia: because i'm the upstream author, i also changed the orig.tar.gz
[01:16] <persia> dsop: Right.  That's what I get for looking at the debdiff :)
[01:18]  * StevenK kicks automake
[01:19] <bddebian> persia: Sorry, what CVS?
[01:19] <persia> dsop: Looks fairly clean to me.  I don't have the tools available to put it through proper testing now, but perhaps another reviewer might.  If you're feeling especially cool, you might make the scripts point to the local license file pre-installation, and to the /usr/share/doc/ file post-installation, but that's certainly not important enough to block.
[01:20] <dsop> persia: thx, i'll think about that.
[01:24] <persia> bddebian: I'm not finding the link now: maybe google will be nicer to you.  http://download.opensuse.org/repositories/ has all the code though.
[01:27] <Fujitsu> Hi Hobbsee.
[01:27]  * Fujitsu requests that rkward be given back on all archs but lpia and hppa.
[01:27]  * Hobbsee waves
[01:28] <Hobbsee> Fujitsu: given back
[01:29] <bddebian> Hmm, I can find the source rpm, does that help me any?
[01:29] <Fujitsu> Hobbsee: Thanks.
[01:29] <persia> bddebian: Yes.  Unpack it.  There should be separated patches for all the changes.
[01:29] <Hobbsee> no problem
[01:30] <bddebian> How do I unpack an rpm?
[01:30] <Fujitsu> Use rpm2cpio, I guess.
[01:52] <dsop> Hobbsee: online?
[01:52] <dsop> i was told that you are a revu admin>
[01:53] <Hobbsee> dsop: yes and yes
[01:53] <dsop> i've a problem with my accound
[01:53] <tonyyarusso> Could someone tell me their thoughts on Tormod Volden's comment at the bottom of https://bugs.edge.launchpad.net/ubuntu/+source/nvu/+bug/99433 ?  It seems like it might make sense, but I'm not sure what policy issues might be involved.
[01:53] <ubotu> Launchpad bug 99433 in nvu "[needs-packaging] nvu html editor is not in the repositories" [Wishlist,Fix released]
[01:54] <dsop> my key is synced, so i can upload packages, but i never received an email concerning my revu accopunt
[01:54] <dsop> and if i try to recover, no message is display to descript
[01:54] <dsop> descrypt
[01:54] <dsop> decrypt...
[01:54] <imbrandon> you dont get a new account untill you make your first upload
[01:54] <persia> imbrandon: There are uploads
[01:54] <dsop> Hobbsee: and I checked twice if i entered the right email address :)
[01:55] <imbrandon> whats one of th uploads ?
[01:55] <Hobbsee> dsop: which email address are you using, and have you uploaded anything to revu yet?
[01:55] <persia> tonyyarusso: I don't think it makes sense for SRU, but it would be nice for LTS->LTS upgrades.
[01:55] <dsop><EMAIL_ADDRESS>and yes i uploaded some packages (approx 10 times, and every package was shown on the revu site)
[01:56] <tonyyarusso> persia: Fair point.  So I should just remember to do a second package for Hardy and not worry about the others too much?
[01:56] <Fujitsu> Hobbsee: Can you please give back the following? They're some of the remaining fallout from the texlive mess. ara, backup-manager, blitz++, bobcat, bochs, cfengine2, cffi, cjk, cl-asdf, cmucl
[01:56]  * tonyyarusso guesses that a significant portion of the userbase is probably LTS - Edubuntu especially
[01:57] <persia> tonyyarusso: I'd say so.  If there are people with leftovers from edgy, they should get fixed during gutsy -> hardy, but pushing NEW in SRU is discouraged.
[01:57] <Hobbsee> imbrandon: you deal with revu, i'll do the givebacks
[01:57] <imbrandon> Hobbsee: ok
[01:57] <tonyyarusso> persia: okay, thanks
[01:57] <imbrandon> dsop: looking into it now
[01:57]  * Fujitsu wonders if somebody can be poked into doing a mass-giveback soonl
[01:57] <Fujitsu> s/l$/./
[01:57] <dsop> imbrandon: thanks
[01:58]  * persia thinks there are enough blow-by-blow givebacks happening that the "mass-give-back" won't have many candidates by the time it is decided.
[01:59]  * emgent heya
[01:59] <tonyyarusso> apachelogger__: ah, just saw the e-mail about you - and now I know what on earth this nick is!  Congrats.
[02:00] <Hobbsee> Fujitsu: given back all but blitz++
[02:00] <Fujitsu> Hobbsee: Because your buildd.py doesn't urlencode properly?
[02:01] <Hobbsee> cjk also may be botched
[02:01] <Hobbsee> Fujitsu: yeah
[02:02]  * Fujitsu concocts a package name that does bad things.
[02:03] <Hobbsee> Fujitsu: appears it doesn't like searching
[02:05] <Fujitsu> Hobbsee: What?
[02:05] <Hobbsee>   File "/usr/lib/python2.5/re.py", line 134, in search
[02:05] <Hobbsee>     return _compile(pattern, flags).search(string)
[02:05] <Hobbsee>   File "/usr/lib/python2.5/re.py", line 233, in _compile
[02:05] <Hobbsee>     raise error, v # invalid expression
[02:05] <Hobbsee> sre_constants.error: multiple repeat
[02:05] <Hobbsee> (there's more than that)
[02:05] <jdong> Hobbsee: oh that's a GREAT error message. Go python!
[02:06] <Hobbsee> heh
[02:06] <Hobbsee> Traceback (most recent call last):
[02:06] <Hobbsee>   File "/usr/local/bin/buildd.py", line 39, in <module>
[02:06] <Hobbsee>     m = re.search('"/ubuntu/%s/\+source/%s/(\d[^"]+)"' % (release, package), page)
[02:06] <Hobbsee> is the top bit
[02:06]  * persia likes stacktraces
[02:06] <jdong> Hobbsee: reminds me of a popular embedded chipset C compiler, whose only error message is "syntax error" or "Abort.
[02:06] <jdong> :D
[02:06] <imbrandon> dsop: hrm even looking at the code i dont know whats up, you will likely have to get siretart's attention and/or email him
[02:06] <Hobbsee> hah!
[02:07] <Fujitsu> imbrandon: What's the issue?
[02:07] <imbrandon> i'd imagine its soemthing with the _ in your email
[02:07] <imbrandon> Fujitsu<EMAIL_ADDRESS>[02:08] <dsop> imbrandon: hm, okay
[02:09] <dsop> imbrandon: do you have his email?
[02:09] <imbrandon> dsop: i think Fujitsu is also looking into the issue
[02:09] <dsop> k
[02:09] <imbrandon> dsop<EMAIL_ADDRESS>[02:09] <imbrandon> if it comes to that
[02:09] <TheMuso> Well. It is now a known fact that the upper blue mountains power grid is as flaky as the first Linux release. :p
[02:10] <imbrandon> TheMuso: solar :)
[02:10] <TheMuso> imbrandon: Trees + not enough sun most of the year.
[02:18] <StevenK> Mmm. There's going to be a huge storm
[02:18] <Hobbsee> oh dear
[02:19] <Fujitsu> StevenK: We just had a lot of thunder and lightning here for about 45 minutes.
[02:19] <TheMuso> StevenK: Probably similar to what we just had.
[02:19] <TheMuso> StevenK: However your power grid will likely stay up.
[02:19] <bddebian> OK so how the hell is rpm2cpio supposed to work?
[02:19] <TheMuso> Unlike ours...
[02:19] <StevenK> bddebian: rpm2cpio < .rpm > .cpio
[02:19] <TheMuso> c
[02:19] <TheMuso> ugh fingers
[02:21] <bddebian> StevenK: I tried that but it just dumps a bunch of crap to the console
[02:22] <bddebian> Am I suppose to dump it to something?
[02:22] <Fujitsu> Hobbsee: Can you please resync the REVU keyring?
[02:23] <persia> bddebian: The output is the .cpio file, no?
[02:23] <StevenK> bddebian: Can you paste the exact command you ran?
[02:24] <Fujitsu> imbrandon: I've sorted out dsop's issue (the key on keyserver.ubuntu.com was out of date).
[02:24] <bddebian> rpm2cpio clanbomber-1.05-76.5.src.rpm
[02:24] <Fujitsu> bddebian: Right, that will output the cpio archive to stdout.
[02:25] <bddebian> Oh those are redirects not options for < foo > eh? :-)
[02:26] <Fujitsu> Ahah, you're right, it did look a bit like that.
[02:26] <bddebian> OK so then wtf do I do with a cpio file?
[02:26] <Fujitsu> Use cpio to extract things from it.
[02:36] <imbrandon> Fujitsu: ahh
[02:37] <Fujitsu> imbrandon: The UID containing that email address wasn't on REVU's keyring, so it died.
[02:38] <bddebian> Well shit, that was a waste of time for nothing.. :-(  Thanks though StevenK, Fujitsu, persia
[02:39] <persia> bddebian: No patches? :(
[02:39] <bddebian> Yeah but not to build against clanlib 0.8
[02:40] <bddebian> I'm freaking sucking more than usual lately :-(
[02:41] <dsop> btw is there an review admin that might review my gcutils package. It would be really nice. So i please an revu reviewer to take a look at this package, as I tried to fix all the problems from the previous comments.
[02:42]  * persia thinks it looks pretty good and someone should give it a proper review
[02:45] <TheMuso> As soon as I've finished my buntuStudio work, I'll take a look.
[02:45] <TheMuso> UbuntuStudio
[02:45] <TheMuso> c
[02:45] <TheMuso> ugh
[02:51] <bddebian> persia: If you get bored/have time: http://www.bddebian.com/packages/debian/comixcursors/
[02:51] <joejaxx> persia: what is the policy on applying patches to software that is in the repository?
[02:51]  * joejaxx never attempted to add his gnupg patch
[02:51] <bddebian> Or if anyone else feels like seeing how I have f'd up the pre/post/rm/inst
[02:52] <Hobbsee> joejaxx: ???
[02:52] <joejaxx> it makes the maximum bit key limit higher :D
[02:52] <joejaxx> instead of it being at 4096
[02:52] <Hobbsee> joejaxx: no.  you may only add patches to newly done software.  nothing in the archive is allowed to be patched!
[02:52] <joejaxx> :(
[02:52] <joejaxx> oh ok
[02:52] <joejaxx> :)
[02:52] <Hobbsee> :P
[02:52] <bddebian> heh
[02:52] <Hobbsee> joejaxx: you can fix it in hardy
[02:52] <joejaxx> Hobbsee: that is what i meant :D
[02:53] <Hobbsee> :)
[02:53] <joejaxx> right now the limit is 4096
[02:53] <joejaxx> i want to make it higher lol
[02:53] <persia> joejaxx: Patches are welcome, but new functional changes require a bit of justification.
[02:54] <joejaxx> persia: the maximum is too low
[02:54] <joejaxx> :P
[02:54] <persia> bddebian: Be careful about publishing a signed changes file.
[02:54] <bddebian> Gah, crap
[02:54] <bddebian> thx
[02:54]  * imbrandon uploads bddebian packages to ubuntu
[02:54] <Fujitsu> persia: Best not upload to PPA, then.
[02:54] <persia> Fujitsu: Does that expose .changes publically?
[02:55] <imbrandon> Fujitsu: what?!?
[02:55] <Fujitsu> persia: In 1.1.10 in did, but it has been mostly fixed now.
[02:55] <dsop> bddebian: you are running hurd? debian/hurd?
[02:55] <Hobbsee> "semi-fixed"
[02:55] <persia> Fujitsu: That's very dangerous.  If that's true, anyone on earth can put anything I put on a PPA directly into hardy.
[02:55] <bddebian> dsop: On about 5 machines, yes
[02:56] <Fujitsu> persia: Exactly.
[02:56] <Hobbsee> persia: at least you don't have main upload rights
[02:56] <joejaxx> bddebian: i have not tried that in a while, thanks for reminding me :D
[02:56] <dsop> bddebian: wow, nice i've to try it out, but it's not that easy to get a lot of information about the current progress ,is it ?
[02:56] <persia> Hobbsee: That's fine.  I only maintain 1 package in main anyway.
[02:56] <Fujitsu> There was a semi-workaround put in place for 1.1.11, so it's not quite as blatant (ie. the links have been removed).
[02:57]  * persia decides not to prep the libopenal1 transition in the PPA until 1.1.12 is out and fixes that.
[02:57] <Fujitsu> Good idea.
[02:57] <imbrandon> woot, $70 in my new computer fundraiser , its getting there :)
[02:57] <joejaxx> lol :)
[02:57] <imbrandon> Fujitsu: grr all the more reason for them to clear my /pool
[02:57] <bddebian> dsop: Sure it is, see the wiki on that same site. ;-)  http://www.bddebian.com/~wiki/  :-)
[02:58] <persia> Pity though, as it allows for lots of acceleration on amd64 & powerpc.
[02:58] <persia> Fujitsu: Do you happen to know the bug #?
[02:58] <Hobbsee> Fujitsu: it's a private bug
[02:58] <Fujitsu> persia: It's private4.
[02:58] <Fujitsu> Hobbsee might know it, though.
[02:59] <Hobbsee> i don't
[02:59]  * persia fails to subscribe, and hopes there will be public disclosure of the fix.
[02:59] <imbrandon> ha
[02:59] <Fujitsu> It's fairly safe at the moment.
[02:59] <persia> Fujitsu: Safe enough to process an entire library transition with ~50 packages that might not work, and doesn't belong in hardy?
[03:00] <Fujitsu> I probably wouldn't risk it.
[03:01]  * persia rejects that definition of "fairly safe2
[03:08] <persia> bddebian: Looks sane to me, but might be worth a mention in the changelog.  I can't test now :(
[03:09] <proppy> I finally managed to compile juce against it's packaged external dependencies
[03:09] <proppy> instead of relying on inlined sources in the tarball
[03:10] <persia> proppy: Excellent.  You get a gold star!
[03:11] <proppy> persia: thanks for supporting !
[03:11] <proppy> next step will be to be the new upstream
[03:11] <proppy> I don't know if there are any guidance in this field
[03:12] <proppy> I guess just crafting a new tarball and host it on a http is not enought
[03:12] <bddebian> persia: It doesn't work, I've tried it.  I get: /var/lib/dpkg/tmp.ci/preinst: 13: ComixCursors-Orange-Regular: not found
[03:12]  * persia looks again, more carefully
[03:14] <persia> bddebian: Try putting quotes around REPLACE_ME_SHIP_LIST.  I suspect it's doing something like `REPLACE_ME_SHIP_LIST=/some/theme/file /some/other/theme/file and attempts to execute the second argument.
[03:14] <bddebian> I was just thinking that a minute ago.
[03:22] <choudesh> Hi all.
[03:22] <choudesh> I would like to join the MOTU team - but I need a mentor first
[03:22] <imbrandon> choudesh: well you dont "need"
[03:22] <imbrandon> a mentor to help
[03:23] <imbrandon> and after helping a while you will be invited to join
[03:23] <choudesh> imbrandon: true - I would like the help of a mentor. ;-)
[03:23] <choudesh> imbrandon: I know how to package debs - just not sure what needs to be packaged. is there a launchpad page on what needs to be packaged?
[03:23] <imbrandon> ahh okies :) well in that case i would email the mentors front desk as usgested on the wiki
[03:24] <imbrandon> and request one to be assigned
[03:24] <choudesh> imbrandon: can I get some linkage to the front desk?
[03:24] <imbrandon> choudesh: well NEW packages really arent the best way for new contributors IMHO, you might check qa.ubuntuwire.com for bugs
[03:25] <imbrandon> to get some experince
[03:25] <imbrandon> and buys taged "bite-size" on LP are also good
[03:25] <imbrandon> bugs*
[03:25] <bddebian> persia: Well at least it acts differently: :-)
[03:25] <bddebian> /var/lib/dpkg/tmp.ci/preinst: 35: SHIP_LIST: not found
[03:25] <bddebian> /var/lib/dpkg/tmp.ci/preinst: 35: TMP_THEME: not found
[03:30] <choudesh> imbrandon: seems at the moment all bitesize bugs have fixes proposed. ;-(
[03:30] <imbrandon> sure then apply the fixes and request a sponsord upload :)
[03:30] <imbrandon> thats the point of them
[03:31] <choudesh> how do I request a sponser upload?
[03:43]  * emgent heya
[03:54] <persia> choudesh: I'd recommend reading https://wiki.ubuntu.com/MOTU/Contributing to get started.  http://qa.ubuntuwire.com/uehs/no_watch.php is a good list of packages that need work.
[03:55] <Hobbsee> morning mdomsch
[03:55] <mdomsch> good evening Hobbsee
[03:55] <Hobbsee> mdomsch: keep up with the times, will you?
[03:56] <Hobbsee> it's 3pm!
[03:56] <Hobbsee> 5pm, even!
[03:56]  * Hobbsee mutters about backwards people :)
[03:56] <bddebian> Damnit, fixed that, now getting a grep usage error :-(
[03:56] <mdomsch> you're always a step (or 17 time zones) ahead of me
[03:57] <persia> bddebian: Put quotes around $(TMP_THEME) :)
[03:58] <mdomsch> http://www.ideastorm.com/article/show/75123?comment_id=98964#comment98964
[03:58] <mdomsch> rough draft of how to do BIOS updates on 240+ Dell system types from within Ubuntu
[03:58] <imbrandon> heya mdomsch
[03:59] <mdomsch> greetings imbrandon
[03:59] <persia> bddebian: Also, line 14 might benefit from sed -n "s!$(ICONDIR)/\(.*\).theme/p"
[03:59] <persia> Err.. "s!$(ICONDIR)!\(.*\).theme!p"
[04:00] <persia> single quotes won't expand the variable, and there's not usually a good reason to call sed twice.
[04:02] <bddebian> Oh, use double quotes instead of single quotes?
[04:02] <imbrandon> zomg, i got past the iniramfs bug on hardy ppc and got X and all working :)
[04:02] <persia> bddebian: If you want $(ICONDIR) to mean anything :)  You might need to escape * - best to test.
[04:03] <imbrandon> means UW will soon have a ppc box to access soonish
[04:03] <imbrandon> :)
[04:03] <imbrandon> brb
[04:04] <persia> mdomsch: Might it be worth adding `aptitude install $(bootstrap_firmware -a)` in a small wrapper so people don't need to remember commands?
[04:06] <mdomsch> persia, yeah; on other distros it's yum install $(bootstrap_firmware) or up2date -i $(bootstrap_firmware -u)
[04:06] <Hobbsee> mdomsch: do you have a lsit of all the dell systems that works on?
[04:06] <mdomsch> and apt-get is *supposed* to be able to ignore not-available packages, but it doesn't
[04:06] <mdomsch> Hobbsee, not really; most have "pretty names", but there are a few I don't have the name mappings for yet
[04:07]  * Hobbsee nods
[04:07] <mdomsch> basically, every system sold in the past 4-5 years, modulo a few with very early and broken update capability
[04:07] <persia> mdomsch: Maybe you could have /usr/sbin/install-firmware-updates that checks /etc/release (or whatever), determines $dist and calls one of `yum install $(bootstrap_firmware)`. `up2date -i $(bootstrap_firmware -u)` or `aptitude install $(bootstrap_firmware -a)`
[04:07] <mdomsch> and modulo a few of the newest Vostro systems
[04:08] <mdomsch> persia, yes, a 'download_firmware' app would be a welcome addition I agree
[04:08] <Hobbsee> mdomsch: nice :)
[04:08]  * Hobbsee wonders if there's anything of interest in them
[04:08]  * persia doesn't have tools available now, but thinks it's a 10-15 line shell script.
[04:09] <persia> mdomsch: I guess the only thing that confuses me in particular is the for loop.  Should be able to do without that.  The rest looks rather exciting.
[04:11] <mdomsch> persia, yeah, it should be
[04:11] <mdomsch> the only challenge is knowing which tool should be used
[04:12] <mdomsch> when multiple tools are present
[04:12] <persia> mdomsch: Of apt-get, aptitude, or dpkg?  They should all be present by default.
[04:12] <mdomsch> apt-get vs aptitude vs yum vs up2date vs Novell tool hell vs
[04:12] <persia> heh.  I see now.  I would think that /etc/lsb-release should provide hints, but it's a fair bit of detective work.
[04:13] <Hobbsee> mdomsch: the solution to that is, of course, trivial
[04:13] <mdomsch> Hobbsee, when we sell considerably more Ubuntu/Debian systems than we do Red Hat systems on the whole, I'd agree with you.  We're not there yet. :-)
[04:14] <Hobbsee> mdomsch: if [! -e /usr/bin/dpkg]: ubuntu.install().  or something.
[04:15] <persia> Hobbsee: doesn't help.  dpkg.rpm is available.  /etc/lsb-release is the key.
[04:15] <Hobbsee> my syntax sounds wrong
[04:15] <mdomsch> persia, not all distros provide that by default :-(
[04:15] <mdomsch> but I could make firmware-tools depend on it I suppose...
[04:16] <Hobbsee> if they don't, format them to ubuntu. i tell you, the problem is trivial!
[04:16] <persia> mdomsch: They should.  Not providing that is a bug.  Not providing aptitutde or up2date or yum or what-have-you is a distro decision.
[04:16] <pwnguin> mdomsch: actually, i have a slight question -- does the script check for battery power?
[04:16] <mdomsch> pwnguin, no - that's an interesting idea though
[04:17] <mdomsch> the actual flash happens after a reboot, during very early POST
[04:17] <mdomsch> and *that* does check for AC
[04:17] <bddebian> persia: Nice, well I got no errors and everything seems to work but I don't really know if it did the right thing for update-alternatives..
[04:17] <pwnguin> ok
[04:17] <pwnguin> what happens if ac isnt found?
[04:17] <Fujitsu> mdomsch: Ah, that's nice.
[04:17] <persia> So what happens if you prep for flash update on batteries?  Is the system in a good state after reboot?
[04:17] <mdomsch> pwnguin, the it tells you it can't flash and continues without flashing
[04:18] <mdomsch> persia, yes
[04:18] <pwnguin> how visible is that warning about the flash?
[04:18]  * Hobbsee wonders what happens if the flash fails.
[04:18] <persia> bddebian: Test case: install the package from the repos.  update-alternatives to a new theme.  upgrade to your version.  make sure your theme didn't get reset.
[04:18] <persia> mdomsch: Ah.  Good :)
[04:18] <mdomsch> pwnguin, it's on the screen for several seconds
[04:18] <bddebian> persia: Oh aye, duh :-)
[04:19] <pwnguin> it might make sense to add a info popup (however that's done) to inform users that power is needed on reboot
[04:19] <Fujitsu> Hobbsee: We laugh at you.
[04:19] <Hobbsee> awww
[04:19] <mdomsch> Hobbsee, if the flash starts writing to the flash, and fails midway through for some reason, you're in trouble of course
[04:19] <Hobbsee> oh, if the flash fails, we blame mdomsch, and come and kill him.  got it.
[04:19] <mdomsch> but I've never seen that happen
[04:19]  * Fujitsu looks for BIOS upgrades for his Inspiron.
[04:20]  * Hobbsee just wants a battery upgrade :P
[04:20] <mdomsch> that's one of the reasons it's done by BIOS itself during POST - there's few things that can go wrong short  of yanking the power cord
[04:20] <bddebian> Oh and stop shipping broadcom wireless adapters in your laptops.. ;-P
[04:20] <pwnguin> out of curiosity, what happens if the power cord is pulled halfway through a flash?
[04:20] <persia> mdomsch: it's only likely in cases of sudden power failure or extreme environmental conditions.
[04:20] <mdomsch> bddebian, we don't sell those with our Ubuntu systems :-)
[04:20] <pwnguin> mdomsch: assuming a battery backup, of course
[04:20] <Fujitsu> Hopefully the battery is charged enough.
[04:20] <bddebian> mdomsch: Ah nice.  Smart.
[04:21]  * Hobbsee only managed to land one broadcom component
[04:21] <Fujitsu> Mine has Broadcom Ethernet NIC, but that works fine.
[04:21] <pwnguin> mdomsch: also, this two stage install can introduce semantic inconsistancies -- the package can be "installed" but the BIOS can still be out of date. im not sure what can be done about that though
[04:21] <Hobbsee> Fujitsu: 6400?
[04:21] <Fujitsu> Other than parts of the card reader, everything works flawlessly.
[04:21] <bddebian> Both laptops I "borrowed" from work had them.  Luckily we had a few other so I switched to the Intel's that they had. -)
[04:21] <Fujitsu> Hobbsee: 630m.
[04:21] <mdomsch> broadcom wired is fine, wireless sucks with Linux
[04:22] <persia> pwnguin: postinst?
[04:22] <Hobbsee> Fujitsu: ahhh.  what, even now?
[04:22] <mdomsch> it's easily remedied with a $30 "customer kit"
[04:22] <pwnguin> persia: on a reboot?
[04:22] <Fujitsu> mdomsch: ie. new MiniPCI card?
[04:22] <mdomsch> Fujitsu, yep
[04:22] <persia> pwnguin: On install.  State is inconsistent until next powered reboot.  Notification to the user that powered reboot is required.
[04:22] <mdomsch> pwnguin, sure - I can have 240 bios images "installed", though only 1 would be appropriate for my system
[04:23] <mdomsch> I've got a bootable USB key like that, for manually running the update tool
[04:23] <pwnguin> anyways, i like the idea
[04:23] <pwnguin> just wanted to double check that it's not a recipe for disaster once digg finds out
[04:24] <mdomsch> pwnguin, we've been using it on RPM-based systems for a couple years
[04:24] <Fujitsu> mdomsch: Out of interest, will it reflash the first time you're powered, or only on the first reboot?
[04:24] <mdomsch> Fujitsu, only on the first reboot
[04:24] <Fujitsu> OK.
[04:24] <mdomsch> because the tool itself only throws the image into memory, and sets a cmos flag
[04:24] <Fujitsu> Ah.
[04:24] <mdomsch> BIOS POST sees the flag, re-assembles the image, and does the flash
[04:25] <Hobbsee> and kaboom!
[04:25] <mdomsch> http://linux.dell.com/firmware-tools  for more details
[04:25] <mdomsch> Hobbsee, always the pessimist :-)
[04:26] <Hobbsee> mdomsch: :P
[04:26] <Fujitsu> Are there changelogs for the BIOSes around somewhere?
[04:26] <pwnguin> mdomsch: anyways, i brought up the semantics not because of the 240 images, but because you may have 0 installed if you reboot on battery
[04:26] <mdomsch> Fujitsu, great question
[04:26] <Hobbsee> mdomsch: so i've been told.  but really, watching things blow up is fun!
[04:26] <Hobbsee> assuming they're not *my* things, of couse
[04:26] <pwnguin> Hobbsee: only when you have spares
[04:26] <mdomsch> Fujitsu, yes there are, but they're not included in the BIOS packages posted on support.dell.com, so they're not included in the .deb packages either
[04:27] <pwnguin> these days, you cant be a good computer student without a second computer ;)
[04:27] <Fujitsu> It's only fun when you can see the magic smoke *and* have a spare.
[04:27] <Hobbsee> pwnguin: as someone else does teh blowing up, and on their own equipment, it's all good
[04:27] <mdomsch> they're posted separately on support.dell.com alongside the windows images
[04:27] <mdomsch> which sucks
[04:27] <Hobbsee> well, i'm surprised my toshiba hasn't caught fire yet.
[04:27] <mdomsch> and is something we're looking to get changed
[04:27] <Fujitsu> Ah, found it.
[04:27] <LaserJock> evening MOTU land!
[04:27] <Fujitsu> Hey LaserJock.
[04:27] <Hobbsee> hey LaserJock
[04:27] <StevenK> LaserJock: Ponies!
[04:27] <Fujitsu> How'd I guess.
[04:27] <Fujitsu> *?
[04:28] <mdomsch> pwnguin, run 'update_firmware' again and it'll tell you. :-)
[04:28]  * persia fondly remembers the IBM 5151
[04:28] <pwnguin> mdomsch: i dont own any dells, but its encouraging the progress im seeing ;)
[04:29] <mdomsch> pwnguin, it's just a framework - it could be extended to handle IBM, Toshiba, ...
[04:29] <Hobbsee> pwnguin: id' really prefer not to test on my production machine :P
[04:29] <mdomsch> we spoke with the IBM team a few months ago about it, they liked the idea
[04:29] <bddebian> Crap, didn't seem to work
[04:29] <pwnguin> mdomsch: anyways, as long as you prompt the user to remind them about AC before reboot, sounds good
[04:29] <mdomsch> there's one more catch
[04:29] <mdomsch> depending on the age of the system, you may need to reboot, run update_firmware, reboot again
[04:29]  * Fujitsu blinks.
[04:30] <Fujitsu> 1. Update 2006 Intel logo.
[04:30] <mdomsch> because it needs 1-2MB _physically contiguous" kernel memory
[04:30] <Fujitsu> What a useful update.
[04:30] <persia> bddebian: OK.  Now, take a backup of everything, and run one script at a time, to figure out what breaks.  Might be the new theme installation.
[04:30] <mdomsch> which we've fixed for newer systems
[04:31] <mdomsch> the first reboot gives you a better chance of your memory not being too fragmented yet
[04:33] <pwnguin> i dont do any kernel hacking, but what happens if you request a kmalloc of 2MB and theres no existing holes big enough?
[04:34] <mdomsch> pwnguin, 1) you can't kmalloc >128KB; you use get_free_pages()
[04:35] <mdomsch> 2) get_free_pages fails, and the error is reported to update_firmware to tell you
[04:35] <pwnguin> so the kernel doesnt push user memory into VM to make more room
[04:35] <mdomsch> pwnguin, no
[04:35] <imbrandon> mdomsch: gonna make packages to flash the PERC controlers too ? hehe
[04:35]  * imbrandon would love that
[04:36] <mdomsch> imbrandon, we have them in RPMs yes, so it's quite conceivable
[04:36] <pwnguin> imbrandon: you need to get a new email server or something
[04:36] <imbrandon> mdomsch: rockin
[04:36] <Fujitsu> PERC?
[04:36] <mdomsch> imbrandon, patches welcome... :-)
[04:36] <imbrandon> pwnguin: i havent resent
[04:36] <imbrandon> mdomsch: the only box i could "test" on only has a PERC 3
[04:36] <imbrandon> :(
[04:37] <mdomsch> upgrade!
[04:37] <imbrandon> but mostly we have 5's in production with an occasional 4
[04:37] <Hobbsee> speakinig of upgrades..
[04:37] <imbrandon> mdomsch: heh trust me all our production systems are on the 4hour plan :)
[04:38]  * Fujitsu wonders why the Inspiron 630m doesn't have a bios package.
[04:39] <Fujitsu> Or at least it's not detecting any.
[04:39]  * Fujitsu checks Packages.
[04:39] <pwnguin> mdomsch: well, as long as that old system setup fails gracefully, that's at least something that can be addresed or fixed
[04:39] <imbrandon> mdomsch: are the .spec / srpms files available for the PERC firmware ?
[04:39] <mdomsch> Fujitsu, running as root?
[04:39] <imbrandon> i might be able to convert them
[04:40] <mdomsch> Fujitsu, 'sudo bootstrap_firmware | grep -i bios'
[04:40] <imbrandon> Fujitsu: PERC is the raid controlers in most modern dell rack servers
[04:40] <imbrandon> maybe other things too
[04:40] <Fujitsu> imbrandon: Ahh.
[04:41] <Fujitsu> mdomsch: Ahh, I didn't sudo it.
[04:41] <mdomsch> Fujitsu, yeah, it needs root to make the call to get the system type
[04:41] <Fujitsu> So I just got PCI IDs.
[04:41] <Fujitsu> Yep.
[04:41] <mdomsch> it should find an A04 package
[04:41] <Fujitsu> So it does.
[04:42] <imbrandon> heh dell should just send all MOTU new laptops and we can all test / patch / help  :) /joking
[04:42] <Fujitsu> Hey, it works.
[04:42] <mdomsch> imbrandon, you're welcome to beg them from rtg and BenC :-)
[04:42] <Fujitsu> Hm, another storm. That's special, two in a day.
[04:42] <imbrandon> ahh ben has some ? /me contemplates
[04:43] <mdomsch> and whomever is in montreal
[04:43] <imbrandon> the support guys
[04:43] <Hobbsee> imbrandon: that's what i was thinking.
[04:43] <Hobbsee> mdomsch: neat.  oy, mneptok!
[04:43] <imbrandon> yea mneptok
[04:43] <Hobbsee> magicfab might do it too
[04:45] <imbrandon> so kernel + support :)
[04:45] <imbrandon> mmm speakin of, i need to finish the xvesa patch
[04:45] <imbrandon> bbiab
[04:46] <imbrandon> mdomsch: the .spec / srpms avail for those PERC rpm's ?
[04:46] <imbrandon> if i could peek at those it would make convertign a ton easier
[04:46] <imbrandon> converting*
[04:47] <mdomsch> imbrandon, yes, in http://linux.dell.com/git/dell-repo-tools.git/
[04:47] <imbrandon> killer /me looks
[04:47] <imbrandon> err gets bzr-git ftw
[04:49] <imbrandon> mdomsch: you know its really sweet how much time it seems dell is putting into this stuff
[04:49] <imbrandon> :)
[04:50] <mdomsch> imbrandon, we're trying...
[04:50] <imbrandon> specialy when you stare at 2k+ dell servers in the DC daily at work
[04:50] <imbrandon> hehe
[05:07] <LaserJock> hmm, anybody know how often we are syncing NEW packages from Debian?
[05:08] <persia> LaserJock: three or four times a week, but only for main: contrib & non-free need manual requests.
[05:09] <LaserJock> hmm
[05:10] <persia> LaserJock: Something is missing?  There was a mini-freeze of NEW for Alpha1, but I thought pitti tried to clear it all on Friday.
[05:10] <LaserJock> well, goffice was split into versioned packages
[05:12] <LaserJock> so there should be goffice and goffice0.4
[05:12]  * persia doesn't have enough information to provide advice, and points at https://launchpad.net/ubuntu/hardy/+queue and http://qa.ubuntuwire.com/multidistrotools/all.html
[05:12] <LaserJock> I don't see goffice0.4 in Ubuntu yet
[05:21] <gpocentek> LaserJock: goffice 0.4 ?
[05:21] <gpocentek> we have 0.5.3
[05:21] <persia> gpocentek: It's the old API, preserved in a separate package in sid.
[05:21] <gpocentek> hum
[05:22]  * persia wonders why we don't just port everything NBS-style
[05:22] <LaserJock> gpocentek: yeah, 0.4 is the stable version of goffice needed by other apps
[05:22] <gpocentek> yep, I see now
[05:25] <LaserJock> I'm waiting for 0.4 so we can merge gchemutils/gchempaint
[05:25]  * Fujitsu returns from some surprise family fun, going by the name of `shit, why is there water coming through that wall?'
[05:25] <Fujitsu> (yay, thunderstorms)
[05:25] <RAOF> Awesome.
[05:25] <RAOF> I'm all for internal pools.
[05:26] <StevenK> Fujitsu: Followed by, "Damn, that isn't good." ?
[05:26]  * persia advocates suspending dwellings from airborne frameworks
[05:26] <Fujitsu> A number of drains outside were rather blocked, and the water was a good 20cm deep in parts. Hopefully it's resolved now...
[05:26] <Fujitsu> StevenK: Yeah.
[05:26] <LaserJock> Fujitsu: wow, we don't get that much rain here in a year for that
[05:27] <Fujitsu> This is the most rain we've had in a looong time.
[05:27] <LaserJock> we get ~ 30cm/year
[05:27] <Fujitsu> And these are particularly low-lying parts of the yard right against the house, so get a lot of drainage to them.
[05:27] <Hobbsee> water through walls?  you need better walls!
[05:27] <Fujitsu> Hobbsee: Well, through bottom of walls.
[05:28] <Fujitsu> Said wall bottoms are well below ground, and sometimes the water level rises above the waterproofing, and leaks down.
[05:40]  * persia encourages reviewers to comment or advocate the 10 open REVU candidates.
[05:45] <StevenK> Fujitsu: I heard about a part of South Australia (near the Northern Terriority border) that got 3 metres of rain. In 48 hours.
[05:45] <LaserJock> persia:  there are only 10?
[05:45] <Fujitsu> StevenK: Blink.
[05:45] <Fujitsu> That's impressive.
[05:45] <Fujitsu> Rather impressive indeed.
[05:45] <persia> LaserJock: Yep.  You can reduce that number.  If we can hit 0 today, we win :)
[05:45] <StevenK> Fujitsu: After that downpour, there was a lake where one didn't used to exist.
[05:47] <Fujitsu> Haha.
[05:47] <persia> StevenK: only one ?
[05:47] <StevenK> A rather large one
[05:47] <LaserJock> StevenK: yeah, that's like 3 years of precipitation for here all in one 48hrs
[06:02] <StevenK> Neat. Seems this storm isn't done yet
[06:03] <StevenK> We had a bolt so close it set of a car alarm earlier
[06:03] <LaserJock> yikes
[06:18] <Hobbsee> kaboom!
[06:19]  * LucidFox advertises http://revu.tauware.de/details.py?package=inkblot
[06:20]  * StevenK advertises the LACK of PONIES to LASERJOCK
[06:25] <Fujitsu> Hobbsee: Do you use Evolution?
[06:25] <Hobbsee> Fujitsu: no.  it's imap support is known to suck.
[06:25] <Hobbsee> Fujitsu: why?
[06:26] <Fujitsu> Hobbsee: Bah, its IMAP support works for me.
[06:26] <StevenK> It's IMAP support sucked for me
[06:26] <StevenK> It could never remember which folders I didn't want to see
[06:26] <Fujitsu> The Evolution process trio is eating my CPU and RAM as of this morning's upgrades.
[06:26] <Hobbsee> mmm...hail.  tasty.
[06:26] <StevenK> HAIL!?
[06:26]  * StevenK chekcs
[06:26] <Fujitsu> We had a bit here before, but it's all bright and sunny now.
[06:26] <Hobbsee> looks like bits of it, and very heavy rain
[06:27] <LaserJock> I've just tried Evolution in the last couple days
[06:27] <LaserJock> I set up an IMAP server at home
[06:27] <StevenK> Not here yet
[06:27] <StevenK> I might move my car under cover, though
[06:27] <LaserJock> right now it works fine except for periodicly pegging the CPU for a while at a time
[06:28] <Hobbsee> hrm.
[06:29]  * Hobbsee ponders teh damage of getting her car undercover, vs leaving it out
[06:29]  * RAOF ponders the advantages of having no car
[06:29] <Hobbsee> city slicker.
[06:30] <RAOF> Public transport FTW!
[06:30] <Hobbsee> public transport?  what's that?
[06:30] <RAOF> A form of hair lice.
[06:30] <Hobbsee> ahhh
[06:34] <Hobbsee> hum.  i wonder if 'im about to lose power
[06:34] <Fujitsu> What email client does everybody use for IMAP? (other than Thunderbird)
[06:34] <Hobbsee> tb
[06:35] <Hobbsee> KABOOM!
[06:36] <StevenK> Fujitsu: I use Thunderbird too
[06:36] <StevenK> Right, back from car undercover and the fun of next doors dog getting into our backyard
[06:37] <LaserJock> Fujitsu: this is one other than Thunderbird? ;-)
[06:37] <LaserJock> *there
[06:38] <persia> mutt is nice if you don't have an aversion to using the keyboard.
[06:38] <LaserJock> I like it ok, but I've not figured out how to deal with attachments well with mutt
[06:39]  * persia is currently in mailer-dissatisfaction-mode, but vaguely remembers a MIME-type hook to launch external viewers
[06:39] <StevenK> I'm quite happy with Thunderbird
[06:39] <StevenK> After using Emacs to read mail for years
[06:40] <persia> StevenK: You went from rmail to Thunderbird?  Has rmail development slowed, or is Thunderbird really that good?
[06:42] <StevenK> persia: I used Wanderlust, not rmail
[06:42]  * persia looks up Wanderlust
[06:45] <LaserJock> I looked at wanderlust when I was on my "OMG, emacs is a whole stinkin' OS"
[06:46] <LaserJock> but well, I didn't want to spend the time to set it up
[06:48] <StevenK> steven@liquified:~% wc -l .xemacs/*.el | tail -n 1
[06:48] <StevenK>   51 total
[06:48] <Fujitsu> Nooo, a Mozilla app! My eyes are burning.
[06:52] <LaserJock> StevenK: that's not much
[06:52] <StevenK> LaserJock: Right, but's Elisp!
[06:52] <StevenK> And:
[06:52] <StevenK> 117 .wl
[06:59] <RAOF> Is anyone else finding that trackerd is continually using 100% of a core?
[06:59]  * Fujitsu finds that trackerd is quite comfortably not on his disk.
[07:01] <RAOF> I can see why it's installed by default, then :P
[07:02] <persia> RAOF: Supposedly if you let it do that for two or three days it calms down.
[07:03] <persia> Alternately rm -rf /home/raof, and only add things you really want indexed.
[07:04] <Hobbsee> hah
[07:04] <RAOF> It's already indexed everything, or at least should have.  This only started relatively recently.
[07:04] <Fujitsu> RAOF: tracker-status should tell you what it thinks it was doing.
[07:04] <RAOF> Fujitsu: Now, that was what I was after ;)
[07:04] <RAOF> Thanks, I was unaware of that utility.
[07:05] <Fujitsu> I found it useful to work out that it had indexed over 10x the number of files in my ~, and so gave up.
[07:05] <RAOF> ... right.
[07:05] <Fujitsu> (*I* gave up, that is, and removed it)
[07:06]  * persia thinks it updates the index for every update in +atime rather than every update in +mtime, and so reindexes repeatedly, but this is superstition
[07:07] <RAOF> persia: atime would be rediculously stupid, surely it doesn't do that.
[07:07] <RAOF> Eh, plus noatime :)
[07:07] <persia> RAOF: I haven't checked: see the note above about superstition.  noatime might also be the culprit, as it can't see that it's been viewed since it was indexed :)
[07:07]  * RAOF 's spelling hasn't returned with his improving health, I see.
[07:08] <StevenK> RAOF: That comes later
[07:08] <StevenK> RAOF: Mark a few first years exams as zero, that'll help
[07:09] <Fujitsu> Heh.
[07:10] <LaserJock> StevenK: that does perk one up after feeling unwell ;-)
[07:12] <StevenK> LaserJock: Ponies! That does too.
[07:12] <RAOF> StevenK: My supply of first year tests has run out, at least untill next yer.
[07:12] <StevenK> RAOF: I'd suggest you set some more, but they've turned into second years!
[07:15] <pwnguin> what's so great about tracker, besides how it digs through emails i dont have?
[07:16] <RAOF> pwnguin: Apparently that it prevents one of your cores from sleeping, ever.
[07:17] <LaserJock> hmm, if it could tell me where I put journal articles I could find it useful
[07:17] <LaserJock> my pdfs tend to have somewhat random alphanumerical names
[07:18] <pwnguin> thats what my desktop's for
[07:18]  * persia thought there was a good app for tracking articles featured on DPOTD recently
[07:20] <pwnguin> i havent seen a dpotd in a while
[07:20] <LaserJock> persia: yeah, but think that implied you used it from the beginning. not sure though
[07:20] <pwnguin> are they really low on articles?
[07:20] <persia> pwnguin: Always.
[07:20] <LaserJock> pwnguin: I think they pretty much put them up as they get them
[07:20] <pwnguin> i see
[07:21] <pwnguin> i thought i saw a queue or something like that
[07:21] <persia> pwnguin: There's a review queue, but it's never very long.
[07:21] <persia> (usually 0 or 1 items )
[07:21] <TheMuso> Hrm. Fresh alpha 1 instal of hardy, and pulseaudio doesn't seem to be runnin.
[07:21] <TheMuso> running
[07:21] <Fujitsu> TheMuso: Is it meant to be?
[07:22] <TheMuso> Fujitsu: I thought it was.
[07:22] <mok0> Good morning
[07:25] <persia> mok0: Just for fun: have you considered using the smaller default mawk, rather than gawk for theseus
[07:25] <mok0> persia: mawk gives a syntax error
[07:25] <mok0> persia: I don't think mawk has the match function
[07:26] <persia> mok0: Right.  If it mattered, I'd suggest fixing the syntax.  On the other hand, we don't feel the same way about mawk/gawk as we do about dash/bash, so it's not important :)
[07:26] <mok0> persia: I could use perl ;-)
[07:26] <persia> mok0: That would be moving the size of the build-depends in the other direction :)
[07:27] <mok0> persia: I could use sed, but then I'd have to invoke a pipe -> several processes
[07:28] <mok0> persia: ... and I love awk
[07:31] <persia> mok0: isn't it just something like sed /^theseus\s\([\d\.]*\)-.*/\1/p | head -1 ?
[07:32]  * mok0 tests
[07:32] <persia> Err.  sed -n ...
[07:33] <persia> Err... sed -n /^theseus\s(\([\d\.]*\)-.*/\1/p | head -1
[07:34] <mok0> ... like I said, I love awk :-)
[07:35] <persia> I like awk too, but not generally for one-line scripts: I just don't remember syntax well off the top of my head.
[07:36] <mok0> persia: can you do it with mawk
[07:36] <mok0> ?
[07:40] <mok0> persia: I couldn't figure out how to print out the matched group space without using that function
[07:40] <mok0> persia: I seem to remember it can be done, but perhaps it's another language
[07:41] <persia> Grr.  Lost log.  Likely, but not off the top of my head (I don't have mawk locally right now).  Something involving /theseus.../ { split $2, arr, [(-)]; print arr[1]; exit} no?
[07:41] <persia> Umm.  the split() arguments should probably be in parentheses :)
[07:42] <mok0> This is my regexp: \((.*)-
[07:42] <mok0> which should find the lparen, then the version and finally a minus
[07:43] <mok0> .* is grouped inside a pair of (), and you should be able to get at the match for that
[07:43] <persia> Also catches "tweak the settings (fixes missing-parameter errors)"
[07:43] <persia> You really want to wrap it with /^theseus/
[07:43] <mok0> persia: ??
[07:44] <mok0> persia: I want it to be general
[07:44] <persia>  \((.*)- matches "tweak the settings (fixes missing-parameter errors)"
[07:44] <mok0> Ah
[07:44] <mok0> Of course, but awk only reads the first line if you call exit after the match
[07:45] <persia> \(([\d\.]*)- is likely closer to what you want.
[07:45] <mok0> yeah, ok, but that still leaves the problem of getting at the grouping
[07:45] <persia> mok0: True, and it works: I'm just poking for the sake of poking :)  I'll test it later, if you can't find two advocates in the next 3 hours.
[07:45] <mok0> :-)
[08:05] <dholbach> good morning
[08:14] <gpocentek> good morning dholbach
[08:14] <dholbach> hey gpocentek
[08:28] <mok0> persia: can do it with mawk :-)
[08:29] <persia> mok0: Hurrah!  Now, can you do it with sed?
[08:29] <persia> (or dpkg-parsechangelogs, if you like)
[08:29] <mok0> persia: you said perl was off-limits
[08:31] <persia> mok0: perl scripts existing only for packaging are sufficiently different as to be not recommended.  Using the supplied utilities (which may be in perl) for which there are no additional build-depends is encouraged.
[08:31] <mok0> persia: I thought this was about efficiency :-)
[08:32] <mok0>  94616 Oct  4  2006 /usr/bin/mawk
[08:32] <persia> mok0: It's about package management efficiency: reduction of build-depends is good.  CPU time on the buildds is nice to save, but not as important.  mawk, sed, and dpkg-parsechangelogs are all installed by default.  gawk isn't.
[08:33] <mok0> persia: so you'll accept mawk?
[08:33] <persia> mok0: I'll accept gawk, but couldn't resist your last comment :)
[08:35] <mok0> persia: I'll accept your challenge to do it in sed. I started out with that, but quickly turned to awk (I always do that if sed doesn't budge in a few tries)
[08:36] <persia> mok0: OK.  sed -n /slkfhjalkfa/\1/p | head -1 is something I've seen a lot before, but it's finding the right slkfhjalkfa that can be tricky :)
[08:36] <mok0> Hehe, yeah
[08:46] <mok0> persia:  sed -e 's/.*(//; s/-.*//; 1q' < changelog
[08:46] <persia> mok0: That's extra clean, but don't forget to use $(CURDIR)/debian/changelog :)
[08:46] <mok0> :)
[08:47] <mok0> But I don't need $(CURDIR), dh_test makes sure I am in topdir
[08:48] <persia> mok0: OK.  I usually add things to be safe anyway.
[08:48] <mok0> persia: so which do you prefer??
[08:48] <mok0> mawk or sed?
[08:49] <persia> Also, s/.*(\([\d\.]*\)-.*/\1/ only does one pass :)
[08:49] <mok0> I can not get the final \1 to parse
[08:49] <persia> mok0: I like sed better, but that's a personal preference.  From what I see, there's nothing actually wrong with the package on REVU.
[08:49] <persia> mok0: Are you quoting the string?
[08:50]  * mok0 tries again
[08:50] <persia> (if not, you need \\1)
[08:51] <mok0> persia: it doesn't work
[08:51] <mok0> persia: it just cats out the whole file
[08:52] <persia> mok0: Are you using sed -n ?
[08:52] <persia> mok0: You'll need /1pq at the end to generate the output though.
[08:52] <mok0> persia: then it gives nothing
[08:52] <persia> mok0: Even with /p ?
[08:52] <mok0> nope
[08:53] <persia> Very odd.  I can't test well from here.  Sorry.
[08:53] <mok0> persia: I'll mutate it
[08:56] <\sh> moins
[08:56] <Fujitsu> 'lo, \sh.
[08:56] <\sh> ScottK, that's a shame with openssl097
[08:56] <Fujitsu> Yes, /me sighs.
[08:57] <\sh> this shouldn't happen at all...:(
[08:57]  * persia thinks it is short term, and given that the same binary blob is available from lots of sources, an acceptable short-term workaround until the blob is fixed (which ought happen this week, or it's no longer short-term)
[09:01] <\sh> persia, tbh, the bug was known...we released sec-updates already for 0.9.8 and then this...sad
[09:01] <persia> \sh: Yes, but nobody poked the ISV team to coordinate an update with the blob vendors.
[09:02] <persia> \sh: if it's not gone in a week, it's worth making a stink, but considering that the problem exists with the blob, it is required in order to support the blob, despite the issues.  None of the software we support is built against it, so I don't really care.
[09:03] <imbrandon> no one should have to imho, if they want to proviced blobs that one of the risks, stay ontop of it
[09:03] <\sh> persia, regarding the fact, that we are distributing this, we should have done something
[09:03] <persia> imbrandon: Well, it's nice to tell other members of ~ubuntu-dev when things are happening.
[09:03] <imbrandon> yea
[09:03] <persia> \sh: We aren't distributing it.  Canonical is distributing it.
[09:04] <\sh> persia, under the ubuntu flag, yes...so it's more a "we" in the public view
[09:05] <persia> \sh: No, it's in partner.canonical.com.  That's the reason I don't care.  It's the ISV team's problem, and it only affects one piece of ISV software.
[09:05] <imbrandon> yes, i would too say it wasent "we" if we dident have the commented out partnet deb lines in sources.list
[09:05]  * Fujitsu notes that partner packages appear very much as a part of Ubuntu, particularly on LP where one would file security bugs.
[09:05] <persia> Further, the software in question is open to the same exploits downloaded directly, or for any other distribution.  If the user wants to install it, that's their hazard: there are alternatives available.
[09:06] <imbrandon> yea, and it lookes like version2 is even more evil, i was a big vmware fan untill this
[09:06] <imbrandon> and the bad part is we use vmware extrnsively at work
[09:07] <imbrandon> extensively*
[09:07] <\sh> persia, well, regarding the last bad publicity about the fragged community servers, the common news were "ubuntu is not secure" not "the admins were not doing their work"...the latter is correct, the former is the public view, which gives more problems of explanation
[09:07] <persia> Fujitsu: True.  I'll stop saying others shouldn't care, but it's the vendors' issue, and while it's annoying that partner doesn't look like a 3rd party repo, it is, and so I'd rather look at the problems we can solve.
[09:07] <persia> \sh: True.  Complain to Canonical PR.
[09:07] <coNP[uni]> Good morning MOTUs!
[09:07] <Fujitsu> Hi coNP[uni].
[09:08] <imbrandon> persia: if it were truely 3rd party it wouldent be in the default sources.list either, imho thats a bug OR we should include medibuntu and seveas etc
[09:08] <imbrandon> ( even commented out )
[09:08] <persia> imbrandon: That's a bug.  Please fix it.
[09:09] <imbrandon> that will cause flack, i'm 100% sure, think aobut it, thats one of the seeling points to ISV's ( "hey look its in the default sources.list, easy to turn on" )
[09:10] <imbrandon> but i'm all for trying
[09:10] <imbrandon> selling*
[09:10] <persia> imbrandon: Sure, but it doesn't go both ways.  If partner is not community supported, the community shouldn't support it.
[09:10] <imbrandon> oh i 100% agree with you, i'm just playing devils advocate kinda to my self
[09:10] <StevenK> I didn't think the community was expected to support it?
[09:11] <persia> StevenK: They aren't.  It's not a community issue.  The complaint is that it looks like a community issue because it's in the default sources.list.
[09:11] <StevenK> Ah, that lovely P word. (Perception)
[09:12] <\sh> persia, honestly, it's not my job...I wrote something about this on my blog, especially for my fellow readers and colleagues....if it would be my job to complain or to do something on canonicals side, I would search a new Marketing and PR manager for the department...we can only complain about technical issues, what happened now is a technical issue.
[09:12] <persia> Precisely :)
[09:12] <Fujitsu> And anybody who goes to LP to file a bug about it will find it being `openssl097 in Ubuntu'
[09:12] <Fujitsu> In the release pocket, looking like a perfectly normal package.
[09:12] <StevenK> Isn't there a bug saying that partner != Ubuntu ?
[09:12] <persia> \sh: No.  The only application affected by possible security issues is affected by the same issues for every distribution.  We can not permit install, or we can permit install.  With a binary blob, there are no other choices.
[09:13] <Fujitsu> Yes, lemme find it..
[09:13] <Fujitsu> Bug #153178
[09:13] <ubotu> Launchpad bug 153178 in linux-source-2.6.22 "Don't recognise USB Pendrive -> sr0: disc change detected. (dup-of: 125250)" [Undecided,New] https://launchpad.net/bugs/153178
[09:13] <ubotu> Launchpad bug 125250 in linux-source-2.6.22 "Don't recognise USB Pendrive -> sr0: disc change detected." [Low,Confirmed] https://launchpad.net/bugs/125250
[09:13] <Fujitsu> Ergh, no.
[09:13] <\sh> persia, of course there are...not publishing it, not following the mainstream..
[09:13] <proppy> oy
[09:13] <Fujitsu> Bug #153798
[09:13] <ubotu> Launchpad bug 153798 in soyuz "canonical partner repo packages showing as "in ubuntu"" [Undecided,Confirmed] https://launchpad.net/bugs/153798
[09:14] <persia> \sh: That's the "not permit install" option.
[09:15] <imbrandon> err it dosent look truely "3rd party"
[09:15] <\sh> persia, I call it "safe the users from doing something nasty to their systems" (more known examples: automatix, the old thirdparty package repos, etc.)
[09:15] <mok0> persia:  sed 's/.*(\(.*\)-.*).*/\1/;q' < changelog
[09:16] <slicer> Hi. I have a licensing question. Mumble's sourcecode is BSD, as it's intended to be freely used by any other project. However, it does use Qt, so until now all binaries have been released under the GPL (as the binary becomes GPL the second it includes a Qt header). Recently, Trolltech made a long list of "addional acceptable licenses", and BSD is one of them. So, technically speaking, it should be possible to BSD license the binaries as well.
[09:16] <persia> mok0: Excellent !
[09:17] <StevenK> dpkg-parsechangelog | grep Version | cut -d\  -f2
[09:17] <mok0> StevenK: Trying to do it without perl and pipes
[09:17] <slicer> However, the source also includes a few third-party things, and one of these have a few GPL-licensed files. These files are not used in compilation, but they're still in the tarball. .. Is the sane thing to do to just keep the whole thing GPL'd?
[09:17] <persia> \sh: Sure.  It'd be nice.  But 153798 aside, I'd rather fix our stuff than worry about other stuff.
[09:18] <persia> slicer: I'd keep the collection GPL, as it'd be easier for end-users.  As long as all the BSD stuff is mentioned in debian/copyright and file headers, those seeking to reuse the code will be aware of their options.
[09:19] <imbrandon> sad thing is 153798 hasent even been triaged, i filed that quite a while back
[09:19] <\sh> well, I'll deal with wireshark now...
[09:20] <\sh> looks like that i'm going to have a bore-out syndrome during the last days in office ;)
[09:20] <slicer> persia: It is. In that case my copyright file actually only needs the two lines of saying that the packaging itself is GPL.
[09:20]  * slicer heads to do a revu upload again.
[09:22] <slicer> BTW. #ubuntu-desktop and the wiki and whatnot have been unable to say if hardy ships with PulseAudio by default. As you can't use both ALSA and PulseAudio at the same time, I'll have to choose one as the default audio backend. Any suggestions?
[09:22] <persia> https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble
[09:23] <persia> slicer: target ALSA for now, but be prepared to patch later.
[09:23] <Amaranth> Why? ALSA is fine
[09:23] <slicer> Amaranth: No, it's not.
[09:23] <persia> Amaranth: Depends on what you do.  In many cases, yes.
[09:24] <Amaranth> Err
[09:24] <Amaranth> You said patch later
[09:24] <imbrandon> alsa is good for users, hell for programers from what ive been told by the gstreamer team
[09:24] <slicer> imbrandon: I fully agree.
[09:24] <persia> imbrandon: Well, again it depends on what you do.
[09:24] <Amaranth> Pulseaudio plugs into alsalib
[09:24] <Amaranth> So if you're using alsa you'll be using pulseaudio and probably not even notice
[09:25] <persia> Amaranth: If hardy does PA by default, and the app can connect directly to PA rather than through the PA ALSA plug, it will be a better user experience.
[09:25] <huats> morning dear MOTU
[09:25] <huats> :)
[09:25] <slicer> No. Mumble strives towards low latency, meaning it uses ALSA features that are "not common" and as such fails completely with the wrapper.
[09:25] <awalton__> but does pulse-audio do alsa emulation (so current applications written to write to alsa can instead write through pulse audio?)
[09:25] <mok0> persia: Using your sed expression. I got rid of the awk scripts. Re-uploaded to REVU, it should be visible shortly. Will you sponsor it?
[09:26] <persia> mok0: Not without testing (which I can't do here).
[09:26] <slicer> Yes, it does ALSA emulation, but only if your application is "normal".
[09:26] <Amaranth> I've never had an app break on it
[09:26] <persia> awalton__: For simple cases, yes.
[09:26] <mok0> persia: Ah, ok
[09:26] <persia> Amaranth: try JACK :)
[09:26] <Amaranth> People use that crap?
[09:27] <persia> I think it breaks on the ALSA entropy plugin as well.
[09:28] <proppy> hi huats
[09:28] <slicer> For me, it breaks when I ask for a socket descriptor to do select() on, and it breaks when I iterate the sound devices to let the user choose a specific one.
[09:29] <coNP[uni]> Wow, PhD Comics is aware of us: http://www.phdcomics.com/comics.php?f=946 :)
[09:29] <slicer> Anyway, I have a native PulseAudio backend now, so no worries :)
[09:29] <huats> proppy: hey
[09:29] <persia> slicer: Sounds like you really want PA if you can get it.  Can you set a config that tries PA and falls back to ALSA?
[09:30] <imbrandon> debian policy <IP_ADDRESS> uploaded ( debian ) time for a lintian/linda patch and some REVU backports
[09:30] <imbrandon> looks like
[09:30] <Fujitsu> It has been a while]
[09:30]  * persia doesn't like hearing that on Monday :(
[09:30] <imbrandon> Fujitsu: where a while == 2 hours ?
[09:31] <slicer> persia: Not really. PA is asynchronous, so you don't know if you have PA until you're program has been running for a short while.
[09:31] <slicer> s/you're/your/
[09:31] <persia> slicer: Right.  Alas.
[09:32] <Fujitsu> imbrandon: I meant since 3.7.2 was released.
[09:32] <imbrandon> Fujitsu: ahh yea, and the release email says 3.7.4 isnt far behind, but that could still be months in debian time
[09:35] <imbrandon> hrm ok, i got a bit of support question ( but to keep it on-topic, i promis to fix if yall help me find why the "why" ) anyhow ... you all know i got hardy to install on that ppc, well after install after reboot it drops to a initramfs busybox shell, i have to "modprobe ide-disk; ^C-d" to get it to finish successfully booting, i thought that just dpkg-reconfigure linux-image-`uname -r` would work to fix this, but it dosent
[09:35] <imbrandon> ideas ?
[09:35] <imbrandon> ( and did that get cut-off )
[09:36] <Fujitsu> imbrandon: Try running `update-initramfs -u', and if that doesn't work add the module to /etc/modules and run the command again.
[09:37] <imbrandon> k, what what would cause this, or would i be better just filing a bug and lettign the kernel team fixing it , i hate to do that as the ppc team is thin as it is
[09:37] <Fujitsu> It seems odd that it wouldn't be there.
[09:39] <imbrandon> i also saved the initrd.img on another disk as sugested in some bugs when this happened massivly in dapper
[09:39] <imbrandon> just incase later it helps to debug
[09:40] <imbrandon> ( the broken initrd.img that is )
[09:41] <imbrandon> moins jono
[09:41] <\sh> moins jono
[09:42] <jono> hey all
[09:42] <Fujitsu> Hi jono.
[09:42] <Hobbsee> hi jono
[09:43] <persia> hi jono
[09:44] <imbrandon> hrm well without adding it to /etc/modules dident work, trying with it now ...
[09:46] <imbrandon> btw anyone know how the sources.list is generated durring install ? since the ppc moved to "ports" its adding deblines for http://ports.ubuntu.com/ubuntu-ports/ hardy .... which is correct, but the deb-src lines it adds are also the same, when ports.u.c domain dosent house sources, the normal http://archive.u.c/ubuntu hardy ... is required for sources
[09:46] <imbrandon> man i really need to auto-break my lines somehow
[09:46] <imbrandon> on irc
[09:47] <imbrandon> ( plus i can poke about the partner commented out repo in the same package hehe )
[09:47] <\sh> imbrandon, write a patch for xchat, irssi, konversation ,-)
[09:48] <imbrandon> \sh: heh konversation alrady does it, but i've been using irssi a few months now
[09:48] <imbrandon> err probably more like a year, but still
[09:52] <imbrandon> Fujitsu: thanks , hat seemed to fixer up, now to figure out why :)
[09:52] <imbrandon> that*
[09:54]  * persia laments the apparent lack of reviewing during REVU day, and encourages reviewers to just pick one app to hit (there's only 10)
[09:54]  * Hobbsee lends persia the whip
[09:55] <LucidFox> well, if it comes to picking one app, may I recommend http://revu.tauware.de/details.py?package=inkblot ?
[09:55]  * persia walks quietly off with the whip, noting that activity will be checked upon return...
[09:56] <slicer> What's the minimum feature set we support on x86 platforms?
[09:56] <slicer> .. and is there a way to mark a package as "only suitable for >= Pentium3"?
[09:57] <imbrandon> slicer: not really, you can make it build for amd64 only, but imho thats silly
[09:57] <Amaranth> slicer: No, it should be generic or switch to alternatives like SSE at runtime
[09:57] <imbrandon> slicer: yes the minimum featureset is 486
[09:58] <Amaranth> It'd be 586 if not for Via, right?
[09:58] <imbrandon> DX
[09:58] <slicer> Even though no 486 will ever have enough power to pull it around?
[09:58] <slicer> Ah well. I'll adapt.
[09:58] <Amaranth> slicer: iirc it's 486 because the chips via puts out don't support the full 586 set of instructions
[09:59] <imbrandon> Amaranth: no because that the lowest denom :) we dont only support "new" hardware
[09:59] <imbrandon> other x86's dont support more than 486 opcodes too
[09:59] <Amaranth> imbrandon: Sure but I can't see any version of Ubuntu working on a 486
[09:59] <imbrandon> besides via
[09:59] <Amaranth> Like what?
[09:59] <imbrandon> Amaranth: -server
[10:00] <imbrandon> VenomSX comes to mind as one, i know there are a few
[10:00] <Amaranth> The kernel takes up more memory than the 486 I owned had
[10:00] <imbrandon> via probably is the bigest but not the only
[10:01] <imbrandon> btw if yall have digg accounts, help a brother out and digg me, http://digg.com/linux_unix/Help_an_OpenSource_Developer_Get_a_New_Computer
[10:01] <imbrandon> :)
[10:01]  * imbrandon goes back to the initrd thing
[10:01] <aplg|mobile> imbrandon: do I need a revu for a fixed watch file?
[10:01] <imbrandon> aplg|mobile: nah, i would attach a debdiff to a bug
[10:01] <imbrandon> for that
[10:02] <aplg|mobile> there is no bug yet
[10:02] <imbrandon> and subscribe u-u-s
[10:02] <imbrandon> aplg|mobile: make one :)
[10:02] <aplg|mobile> well
[10:02] <aplg|mobile> <-- apachelogger :P
[10:02] <aplg|mobile> imbrandon: can sponsor myself ;-)
[10:02] <imbrandon> ahh ok, well then just upload :)
[10:02] <aplg|mobile> k, thanks
[10:02] <imbrandon> i dident know whom you were :)
[10:02] <imbrandon> hehe
[10:03] <aplg|mobile> yeah, that nick is kinda confusing
[10:03]  * aplg|mobile needs to think about something more meaningful
[10:03] <imbrandon> i would attach it to a debian bts bug also ( the debdiff ) if the package is in debian
[10:03] <imbrandon> mobileapache :)
[10:04] <imbrandon> or ... wap.apachelogger :)
[10:04] <imbrandon> lol
[10:05] <imbrandon> aplg|mobile: what pacakage, just curious ? ( makin sure its not something i look after hehe )
[10:05] <aplg|mobile> qtpfsgui
[10:05] <aplg|mobile> strange thing is
[10:05] <aplg|mobile> that has no watch file at all
[10:06]  * aplg|mobile kicks ubuntuwire :P
[10:06] <Fujitsu> aplg|mobile: What is the issue?
[10:07] <imbrandon> ahh nope
[10:07] <aplg|mobile> Fujitsu: http://qa.ubuntuwire.com/uehs/wwiz_detail.php?id=8529&type=watch
[10:07] <imbrandon> thats watch wiz, those are autogenerated
[10:07] <Fujitsu> What imbrandon said.
[10:07] <aplg|mobile> oha
[10:07]  * aplg|mobile includes a watch file
[10:07] <imbrandon> watch != wwiz
[10:08] <imbrandon> :)
[10:08] <aplg|mobile> makes sense :)
[10:09] <imbrandon> hrm actualy Fujitsu that dident work, i thought it would ( even adding to /etc/modules )
[10:09] <imbrandon> i'll poke the kernel guys later for more hints , atleaste enough to file a memeaningfull bug
[10:10] <imbrandon> i'll just deal wih having to mod-probe that on boot for the moment
[10:14] <\sh> can someone rebuild mplayer to catch up with libx265-56? :) (bug #173624) thx
[10:14] <ubotu> Launchpad bug 173624 in mplayer "mplayer : dependency is not satisfiable in Hardy" [Undecided,New] https://launchpad.net/bugs/173624
[10:15] <\sh> libx264-56 ,-)
[10:15] <imbrandon> \sh: i think Hobbsee can do give-backs
[10:16] <\sh> Hobbsee, ? :) can you ? :)
[10:16] <geser> imbrandon: without checking this sounds like a new upload (library transition)
[10:16] <imbrandon> geser: err yea true, build1 would probably need appened, \sh want me to do that ?
[10:17] <\sh> imbrandon, if it builds properly (didn't check it) sure, would be cool one bug less ,)
[10:17] <imbrandon> ok, i'll do a fast buld check and then if successfull do that
[10:17] <imbrandon> build*
[10:17] <\sh> imbrandon, cool thx :)
[10:18] <\sh> I'm fighting with CVE-2007-6113 :( wireshark is a bitch...the changes are coming to fast to the source
[10:18] <ubotu> Wireshark (formerly Ethereal) 0.10.12 to 0.99.6 allows remote attackers to cause a denial of service (long loop) via a malformed DNP packet. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6113)
[10:29] <Hobbsee> \sh: given back, but it appears to be in depwait anyway, so would have been retried
[10:29] <imbrandon> Hobbsee: eer ok so i shouldent upload ?
[10:30] <Hobbsee> imbrandon: shouldn't need to
[10:30] <Hobbsee> oh, hang on
[10:30] <imbrandon> k, poke me if that changes
[10:31] <Hobbsee> right, now it's working
[10:32] <imbrandon> koies
[10:35] <geser> imbrandon: it needs an upload as it build successfully on i386 and amd64
[10:36] <geser> Hobbsee: it was in depwait for !(i386, amd64)
[10:38] <imbrandon> geser: ok, i'll just upload, it cant make it worse
[10:38] <imbrandon> Hobbsee: ^^
[10:39] <\sh> thx imbrandon
[10:39] <\sh> thx Hobbsee
[10:45] <Hobbsee> imbrandon: oh, yeah, point
[10:48] <StevenHarperUK> Hi, I am seeing that vm-server is stuck on 1.0.4-1gutsy1 in apt, even post install it seems to think  that it need to be installed - synaptic says  .0.4-1gutsy1 (gutsy) is replacing .0.4-1gutsy1(now) : do I need to raise a bug?
[10:49] <imbrandon> StevenHarperUK: probably but you need to file it against Canonical Partner not Ubunut
[10:49] <imbrandon> ubuntu*
[10:49] <Hobbsee> there's a bug filed.
[10:49] <Hobbsee> on soyuz
[10:50] <Hobbsee> it's mangling spaces, so it thinks it's different, and tries to install it again
[10:50] <StevenHarperUK> Hobbsee: can you post me a link pls
[10:50] <Hobbsee> that woudl require looking it up...
[10:50] <StevenHarperUK> Hobbsee: I thought it looked like a name problem, but great to see your onto it
[10:50] <StevenHarperUK> Hobbsee: Ill try to find it
[10:51] <Fujitsu> It's a problem with Soyuz leaving out fields in Packages files.
[10:51] <Hobbsee> StevenHarperUK: https://bugs.edge.launchpad.net/soyuz/+bug/172275
[10:51] <ubotu> Launchpad bug 172275 in soyuz "vmware-server in feisty-commercial keeps getting reinstalled" [High,In progress]
[10:51] <Fujitsu> Pre-Depends and Recommends, among others.
[10:51] <Fujitsu> That one.
[10:51] <StevenHarperUK> Hobbsee: thanks
[10:52] <Hobbsee> https://bugs.edge.launchpad.net/soyuz/+bug/165230 appears to be a dupe
[10:58] <persia> Hi proppy
[11:00] <Amaranth> Hobbsee: But mortals don't have access to the original so I can't blame them for duping it
[11:00] <Hobbsee> Amaranth: everyone should be able to view those bugs.
[11:00]  * Hobbsee cannot view soyuz private bugs
[11:00] <proppy> hi persia
[11:00] <proppy> :)
[11:00]  * Hobbsee does not work for canonical
[11:00] <Amaranth> https://bugs.edge.launchpad.net/bugs/172308 tells me "Not allowed here"
[11:00] <Amaranth> dang
[11:01]  * persia dislikes the message, and wishes for something nicer
[11:01] <Amaranth> Hobbsee: https://bugs.edge.launchpad.net/bugs/172308 tells me "Not allowed here"
[11:01] <proppy> Amaranth: same for me
[11:01] <Amaranth> and ubotu says it's private
[11:01] <StevenHarperUK> Hobbsee: I see that too
[11:01] <Hobbsee> O.O
[11:02] <Hobbsee> Amaranth: erm, where did you get that link from?
[11:02] <Amaranth> oh, that's the one above yours
[11:02] <Amaranth> cprov linked to it
[11:02] <Amaranth> I just opened every link in the bug report :P
[11:02] <Hobbsee> ahhh
[11:03] <Amaranth> cprov refers to that bug in the one you linked to as well
[11:03] <Hobbsee> well, he can read the private bugs, obviously
[11:03]  * Hobbsee cannot.
[11:03] <Amaranth> odd that it'd be private
[11:04] <Amaranth> They must have discovered the bug while doing something with the partner repo
[11:08]  * persia hints that reviewers should try to review at least one REVU package during REVU day.
[11:08] <Amaranth> heh, the next hug day is my birthday
[11:09] <Amaranth> and since it's my 21st i suspect i'll be too drunk to help with bugs :P
[11:09] <Hobbsee> bad Amaranth.
[11:10]  * imbrandon notes his birthday is a few days away ( 19 dec ) he'll be 29, ugh
[11:11]  * Hobbsee makes comments about people being old and decrepit, and needing walking sticks.
[11:11]  * Fujitsu will be 17 in 4.5 months, so hah.
[11:11]  * Hobbsee runs
[11:11] <Fujitsu> Hobbsee: You're ol.
[11:11] <Fujitsu> *old.
[11:11]  * persia hands Hobbsee a walker
[11:11] <Hobbsee> not that old
[11:11]  * Hobbsee watches persia fall over, as he's now without his walker
[11:12]  * persia doesn't need to walk :)
[11:12]  * Fujitsu isn't sure how old Hobbsee is.
[11:12] <persia> Fujitsu: Somewhere between you and I.
[11:12] <Hobbsee> 93
[11:12]  * Fujitsu isn't sure how old persia is either :P
[11:12]  * StevenK is sure how old Hobbsee is, but isn't saying
[11:12]  * Hobbsee is 93 in alien years.
[11:13] <geser> Hobbsee: which number base?
[11:13]  * txwikinger2 is an alien too
[11:14]  * imbrandon knows Hobbsee's age too , but not sure why its secrative now, wasent before heheh
[11:14]  * persia encourages Fujitsu and StevenK to do a REVU
[11:14]  * txwikinger2 wonders what alien years are
[11:14] <Hobbsee> geser: aliens don't use archaec things such as number bases to calculate ages.
[11:14]  * StevenK shrugs off persia's encouragement
[11:14]  * persia encourages geser to do a review in lieu of StevenK
[11:14]  * Hobbsee encourages imbrandon to do a REVU too
[11:14] <persia> Yeah!
[11:15]  * Hobbsee cracks the whip
[11:15] <StevenK> Ouch!
[11:15]  * persia has previously returned it
[11:15] <Hobbsee> persia: i have multiple whips.
[11:15] <StevenK> Watch where you aim that thing
[11:15] <txwikinger2> who said anything about aiming?
[11:16] <StevenK> Like you can aim a whip anyway
[11:16] <imbrandon> ok mplayer seems to build fine, uploading now-ish
[11:16]  * geser is lucky to be far away from Hobbsee
[11:16]  * Hobbsee has a very long whip
[11:16]  * txwikinger2 doesn't like miracle whip
[11:17]  * persia grumbles at changelogs that read "New Upstream Release" for every upload, with serveral bugs marked closed, and no explanation.
[11:17]  * Hobbsee also has a VERY long Long Pointy Stick of DOOM!!!!!!!!!!!!!!! ™
[11:17] <Hobbsee> i'ts also HIGHLY ACCURATE!
[11:17] <imbrandon> persia: btw after i make this upload i'd like to discuss a few of the comments on xbiso package ( revu ) some dont apply, and some i dont think should .... give me a sec ( just preping you )
[11:17] <Hobbsee> so, get reviewing!
[11:17] <persia> imbrandon: Sure.
[11:17]  * txwikinger2 thinks Hobbsee must be very old to have been involved in the DOOMSDAY books
[11:18]  * Hobbsee is 93, as said earlier.
[11:18] <txwikinger2> not old enough
[11:18] <Fujitsu> Hobbsee: 93 non-linear alien years?
[11:18] <Hobbsee> *now* you're getting the idea....
[11:19]  * txwikinger2 thinks about disappearing into the sixth dimension
[11:20]  * persia smiles at cprov
[11:20] <Fujitsu> Evening, cprov.
[11:20] <Hobbsee> persia: giong to make him review too?
[11:20] <Hobbsee> sounds sinister.
[11:21] <persia> Hobbsee: I don't think the keyring matches.
[11:21] <cprov> morning, dudes
[11:21] <txwikinger2> Is persia now jumping at any new arrival?
[11:21] <persia> txwikinger2: No.
[11:21]  * txwikinger2 supports persia's encouragements anyway
[11:22] <imbrandon> cprov: gonna be arround for a minute? i wanna poke you about a potential PPA bug but i'm busy the next ~15 minnutes
[11:22]  * Hobbsee encourages persia to review
[11:22] <persia> norsetto: Good news.  I finally got my audio toolchain working again: I should be able to get lash up tonight.
[11:22] <persia> Hobbsee: I've reviewed every package awaiting review at least once :P
[11:22] <Hobbsee> persia: and the sponsorship queue is empty too?
[11:22] <cprov> imbrandon: k
[11:23] <norsetto> persia: hey, good to know, lemme know if there is any probs with the package
[11:23] <persia> Hobbsee: No, but that's on the TODO list (see previous note)
[11:26]  * txwikinger2 just found another gutsy bug
[11:26] <txwikinger2> is even a packaging bug
[11:26]  * persia waits for the patch
[11:27] <txwikinger2> hehe :D
[11:27] <txwikinger2> k.. I report the bug with the patch
[11:29] <txwikinger2> well.. how about a package sync
[11:42] <imbrandon> Fujitsu: fyi , cprov just informed me that the system requires a new upload to the PPA to trigger the archive-cleanup system :)
[11:43] <Fujitsu> imbrandon: Ah, I guess it needs to trigger a publisher run, right.
[11:43] <imbrandon> yea, makes sense now that he said it, but ... yea
[11:46] <imbrandon> \sh / Hobbsee : mplayer uploaded, i used a ubuntu3 version instead of build1 since there was already a ubuntu delta
[11:47] <imbrandon> but its clearly stated in the changelog thats its a rebuild only
[11:48] <Fujitsu> imbrandon: Did you push it to bzr?
[11:48] <imbrandon> Fujitsu: doing it now
[11:48] <imbrandon> puter slow :)
[11:48] <Fujitsu> Danke.
[11:48] <Fujitsu> It should only take a couple of hours to checkout.
[11:48] <imbrandon> yea i noticed it was bzr hosted
[11:49] <imbrandon> dude since i got bzr-svn working i'm in love
[11:51] <imbrandon> Fujitsu: all imported and commited with bzr-svn :) http://apt-mirror.svn.sourceforge.net/viewvc/apt-mirror/trunk/
[11:51] <Fujitsu> imbrandon: Aha, nice.
[11:51] <imbrandon> once the initial bzr co svn://... is done everything else is just as you would use bzr normaly
[11:52] <imbrandon> makes it seemless
[11:52] <imbrandon> i had to use bzr 0.92 from the website and rebuild bzr-svn against it , but its great
[11:53] <imbrandon> should be transparent fr everyone come hardy
[11:54] <imbrandon> man are you serouis this co is gonna take hours?
[11:55] <imbrandon> kinda nice that bzr has plugins like svn and git etc, makes devs able to use one tool ( if they use bzr )
[12:03] <\sh> imbrandon, did you mention bug #173624 in the changelog?
[12:03] <ubotu> Launchpad bug 173624 in mplayer "mplayer : dependency is not satisfiable in Hardy" [Low,Fix released] https://launchpad.net/bugs/173624
[12:03] <imbrandon> \sh: yes i closed it via the changelog
[12:03] <\sh> imbrandon, rock :)
[12:04] <imbrandon> infact looking at the bot it seems it already closed it :)
[12:06] <imbrandon> hrm persia / Fujitsu : i just had an evil thought
[12:06] <imbrandon> you know the PPA changes thing?
[12:06] <Hobbsee> mmm?
[12:06] <imbrandon> s/changes/.changes/
[12:06]  * persia wonders about xbiso
[12:07] <imbrandon> what stops someone from getting a signed .changes of a normal package from LP ( say xorg or similar ) where the person is also a DD , and uplaoding to ftp-master ?
[12:07] <imbrandon> not just the PPA's
[12:07] <Hobbsee> imbrandon: wrong target.
[12:07] <persia> imbrandon: The distribution targets are different.
[12:07] <imbrandon> ahhh rockin, ok
[12:08] <imbrandon> i just had one of those WTF moments heh
[12:08] <\sh> can't we build as well debian distros with PPA?
[12:08] <imbrandon> \sh: if you force it via uploading to ~ubuntu/gutsy or similar
[12:08] <imbrandon> yes
[12:09]  * Hobbsee didn't think it did debian stuff
[12:10] <persia> Well, we can build debian packages, but not debian distros.  Needs to follow an Ubuntu base distro.
[12:10] <imbrandon> Hobbsee: it will build for anything if you overide it via uploading to the correct target
[12:10] <imbrandon> persia: right
[12:10] <persia> imbrandon: anything (as long as it's brown)
[12:10] <imbrandon> if you upload it to ~ubuntu/dapper it will still build agaist dapper no matter what the changelog says
[12:11] <imbrandon> in short
[12:11] <soren> The changelog doesn't matter anyway.
[12:11] <soren> It's what's in the .changes file that matters.
[12:11] <persia> soren: Except insofar as it is used to geneate .changes
[12:11] <Hobbsee> imbrandon: sure, i just didn't raelise that they even did debian builders
[12:11] <soren> (or where you upload to, apparantly. I didn't know)
[12:11] <Hobbsee> would have thought it'd reject going to unstable.
[12:11] <persia> Hobbsee: It doesn't.
[12:12] <soren> persia: But it's perfectly overridable with dpkg-genchanges or manually afterwards.
[12:12] <persia> soren: Sure.
[12:12] <imbrandon> Hobbsee: it dosent but it will not reject it if it is specificly uplaoded to a target
[12:12] <imbrandon> soren: yea but %99.9 percent of people just use whats generated :)
[12:12] <Hobbsee> imbrandon: yet the unstable target in ppa doesn't seem to exist?
[12:13] <soren> imbrandon: I'd add significantly more 9's at the end of that :)
[12:13] <persia> Hobbsee: Right.  You can't upload to build against sid.  You can upload to build an unmodified sid package against feisty.
[12:13] <soren> imbrandon: It's a relevant detail, though.
[12:13] <Hobbsee> well, of course
[12:13] <Hobbsee> that's different
[12:13] <imbrandon> Hobbsee: ugh, your not getting what i said, if you have an package that says unstable in the changelog/changes you can uplaod it to ~ubuntu/$dist and it will not reject it, rather build it for said $dist
[12:14] <imbrandon> whereas if you have an unstable package and just uplaod it to ~/ubuntu it WILL reject it
[12:14] <Hobbsee> right
[12:14] <Hobbsee> i got all but the last part then :)
[12:14] <imbrandon> :)
[12:14] <imbrandon> i probably wasent very clear, i hate irc at times
[12:14] <Hobbsee> i thought if you uploaded it to ~ubuntu/unstable it would surely also fail, too.  that was my point
[12:14] <imbrandon> heh
[12:15] <persia> Hobbsee: It does :)
[12:15] <Hobbsee> good!  :)
[12:15] <imbrandon> persia: ahh yea xbiso , lemme bring up the pacakge, one sec
[12:15]  * persia cheers everyone being right, and encourages soren & imbrandon to do REVU reviews (it being REVU day)
[12:15] <imbrandon> although that would be a nice feature for those that wish to give back to debian ( unstable PPA also )
[12:16] <txwikinger2> well lets hug debian :)
[12:16]  * persia prefers "also work on" to "give back to"
[12:18] <imbrandon> persia: re: xbiso , 2) why? 4) yes its required for this upstreams build system 5) huh? 6) huh? , everything else is "will-do"
[12:19] <imbrandon> http://revu.ubuntuwire.com/details.py?package=xbiso
[12:19] <\sh> hmmmm? njam 1.25-5ubuntu1 ?
[12:19] <\sh>  Merge from Debian unstable (LP: #159318) remaining changes:
[12:19] <\sh>      - updated .desktop file to be freedesktop and HIG compliant
[12:19] <\sh> and the debian changelog mentions:
[12:19] <\sh> * Make .desktop file freedesktop-compliant
[12:19] <\sh> ?
[12:19] <imbrandon> lol
[12:19] <persia> imbrandon: 2) I didn't check, but it's often handy, 4) that sucks, 5) \- vs. \(hy, 6) man lexgrog
[12:20] <\sh> !ircnick Mario Bonino
[12:20] <imbrandon> k
[12:21] <DktrKranz> persia, I improved http://people.ubuntuwire.com/~dktrkranz/NBS/, it's not perfect, but can be of help
[12:21]  * imbrandon wishes there was a "very simplest form" howto on man pages, everything i found on google is way way way complicated
[12:23] <DktrKranz> \sh, any troubles with njam? I can contact Mario, if you want
[12:23] <\sh> DktrKranz, I wonder what was the difference between freedesktop compatible from debian and our freedesktop compatible ,-)
[12:23] <persia> DktrKranz: Looks great, but: 1) Difficult to navigate: perhaps anchor the sections, 2) Be nice to separate main from universe to aid efforts, 3) Be nice to have text indicating that the first chunk likely need porting, and the second chunk likely need a recompile, 4) Be nice to have a link to a wiki page explaining about -XbuildY (but I can't find the page, so I don't expect this one to get done :) )
[12:25] <DktrKranz> \sh, I'll ask him when he well login. His IRCname is Rospo_Zoppo, FYI
[12:25] <DktrKranz> *will
[12:25]  * persia wonders if we can just drop all the xmms modules rather than recompiling them
[12:26] <imbrandon> heh
[12:26] <DktrKranz> persia, it should quite easy to do, I'll try to adjust, but I will need a hand for 1), I'm a disaster in these issues :)
[12:26]  * persia seeks a UI person to help put a front end on http://people.ubuntuwire.com/~dktrkranz/NBS/
[12:27] <persia> DktrKranz: Can you stick a link to the code somewhere on that page?
[12:27] <imbrandon> if no one gets to it before i do i'll poke at it ~1 hour
[12:27] <DktrKranz> Sure
[12:28] <imbrandon> well ~1.5 i have to get the kids ready for school soon'
[12:28] <persia> DktrKranz: OK.  Since all my wishlists were UI issues: any chance you could look at building a list of packages not yet compiled for hardy?
[12:29] <DktrKranz> persia, it will be harder since we haven't no autosync logs, but perhaps we can solve by running multidistrotools
[12:30] <persia> DktrKranz: You mean comparing gutsy to hardy, and looking for packages with the same version?
[12:30] <DktrKranz> I fear it is not complete
[12:30] <imbrandon> hrm that sounds like it will generate los of false positives
[12:30] <Fujitsu> It should be very easy to do that, actually.
[12:30] <persia> imbrandon: Why?
[12:30] <persia> DktrKranz: How?
[12:30] <imbrandon> not all versions will bump
[12:30] <imbrandon> between releases
[12:31] <Fujitsu> I can probably generate that list in a few seconds.
[12:31] <persia> imbrandon: It needs a bump to get compiled against the new toolchain, no?
[12:31] <imbrandon> no
[12:31] <DktrKranz> Fujitsu, great. Maybe we can compare your output with that taken from hardy build logs to see if there are differences
[12:31] <imbrandon> some things stay at the same version from warty to hardy :)
[12:31] <persia> Fujitsu: I don't really consider it a target until we near UVF, but it'd be nice.
[12:31] <imbrandon> persia: ^
[12:31] <Fujitsu> persia: I'll try it now.
[12:31] <\sh> DktrKranz, cool thx
[12:32] <persia> imbrandon: Right.  Those didn't get rebuilt.
[12:32] <Fujitsu> imbrandon: Right, which is a problem.
[12:32] <persia> imbrandon: Further, many of them would FTBFS if retried today.
[12:33] <DktrKranz> Yes, especially some with bashisms
[12:33] <imbrandon> hum okies
[12:33] <imbrandon> i guess i was off then
[12:34] <persia> imbrandon: You were correct, it's just that we consider that to be less than ideal.
[12:34] <imbrandon> :)
[12:35] <DktrKranz> Another false positive could be when a package FTBFS on Gutsy and compiled successfully on Hardy
[12:35] <persia> Further, we may miss things given-back: it might be worth doing a changelog analysis from the resulting list before pushing (but I don't advocate pushing until near UVF anyway)
[12:37] <Fujitsu> Only 8957 sources unchanged since Gutsy. yay.
[12:37] <DktrKranz> \o/
[12:37] <persia> That's actually a nice low number.  Let's see if it gets better in the next couple months, and start pushing recompiles in January.
[12:38] <DktrKranz> Mass-rebuilds?
[12:39] <imbrandon> Fujitsu: just to give some context how long woudl it take to get the number from feisty to gusty ?
[12:39] <imbrandon> would*
[12:39] <imbrandon> to see "where we're at"
[12:39] <persia> DktrKranz: Basically.  I read that as the buildds having a capacity of slightly over 1000 packages a week, so we should be in decent shape.
[12:40] <persia> (and I suspect the buildd queues zeroed out a couple times as well, so the capacity is likely higher)
[12:40] <DktrKranz> so, it will take about two months
[12:40] <Fujitsu> imbrandon: I'm doing it for all releases now.
[12:40] <imbrandon> cool
[12:40] <persia> Right.  So if we start at the beginning of January, we should finish in plenty of time for the release.
[12:41] <imbrandon> if there are no problems or oter builds going :)
[12:41] <DktrKranz> We need to coordinate to avoid dobule uploads
[12:41] <persia> Although actually, that's a lot of uploads.  Maybe we need to start earlier to have enough time.
[12:41] <persia> DktrKranz: Yes.  maybe a simple comment / assignment on some coordination page?  Maybe bugs?
[12:42] <imbrandon> bugs would take too long, you would / should be able to take a hunk of 10 or so, just for rebuilds
[12:42]  * Fujitsu pokes orko.
[12:42] <DktrKranz> File ~ 8000 new bugs? Someone will be *very* upset
[12:43] <persia> DktrKranz: No you're right.  Maybe we can arrange a scripted rebuild for them once DIF hits, and chase the FTBFS list?
[12:43] <imbrandon> persia: that sounds mildy sane
[12:46] <DktrKranz> persia, if everybody take responsibility for 100 rebuilds/week, we should 1) be sure not harming packages maintained by others 2) be sure of the results
[12:47] <persia> DktrKranz: True, but scripting would be better.
[12:47] <DktrKranz> Scripting would mean do it without manual intervention?
[12:47] <Fujitsu> fujitsu@orko:~/mdt/versions$ wc -l unchanged_since_dapper
[12:47] <Fujitsu> 1525 unchanged_since_dapper
[12:48] <DktrKranz> If so, we should really inform people of the plan.
[12:49] <imbrandon> concentrating on those 1500 sounds much more sane
[12:49] <imbrandon> at leatse a good starting point
[12:49] <imbrandon> e.g. higher priority
[12:50] <Fujitsu> fujitsu@orko:~/mdt/versions$ wc -l unchanged_since_warty
[12:50] <Fujitsu> 340 unchanged_since_warty
[12:51] <DktrKranz> I think these are all almost broken
[12:52] <minghua> Not necessarily.  They may be docs, fonts, etc.
[12:53] <imbrandon> Fujitsu: what kinda output can you quickly give those, like removing dupes then putting the 340 in red at the top , then the next X then the next X etc
[12:54] <imbrandon> so they can atleaste be looked at in order, and maybe flagged as minghua said some maybe doc/fonts/etc
[12:57] <persia> Just got feedback in -devel: Let's try to trim by reason: recompiling everything is frowned upon.
[12:58] <Fujitsu> That makes sense.
[12:58] <persia> Reasons I know off the top of my head: CDBS changes, docbook changes, ddeb generation.
[12:58] <Fujitsu> Yep.
[12:58] <persia> Anyone else have a couple reasons?
[12:58] <Fujitsu> SSP..
[12:58] <persia> Fujitsu: Doesn't that affect everything compiled?
[12:59] <Fujitsu> Pretty much, so it's not useful here.
[12:59] <persia> Fujitsu: When did we get SSP?
[12:59] <Fujitsu> I don't recall.
[12:59] <minghua> persia: I believe perl/python stuff are not affected by SSP change?
[12:59] <persia> minghua: Right.  Not compiled by the buildds :)
[13:00] <soren> Edgy.
[13:00] <soren> minghua: ^^
[13:00] <persia> soren: The beginning or the end of edgy?  Can we trust that all edgy uploads have SSP?
[13:00] <minghua> soren: The "Edgy" is for me?
[13:00] <soren> minghua: Yes.
[13:01] <soren> persia: No.
[13:01] <soren> :)
[13:01] <minghua> soren: Why?  I didn't ask anything, persia asked...
[13:01] <soren> minghua: Erh... Because I can't read?
[13:01] <soren> :)
[13:02] <persia> OK.  Can we trust that anything uploaded to feisty has SSP?
[13:02] <Fujitsu> http://people.ubuntuwire.com/~fujitsu/mdt/unchanged/ has the raw stuff for the moment.
[13:03] <soren> persia: No.
[13:03] <soren> persia: Sorry. Yes.
[13:03] <persia> unchanged since warty!
[13:03] <DktrKranz> persia, can we trust anything with SSP is not broken?
[13:03] <Fujitsu> Unless it has it explicitly disabled.
[13:03] <soren> persia: It was added on June 30th last year.
[13:03] <persia> DktrKranz: No, but those are different bugs.
[13:03] <persia> soren: Thanks.
[13:03] <soren> persia: So most of edgy, all of feisty.
[13:03] <DktrKranz> I face dietlibc-related programs, which are *all* broken
[13:04] <DktrKranz> Gotta go right now, see you later
[13:06] <persia> OK.  CDBS: everything < hardy, SSP everything < June 30th 2006, docbook < feisty, ddeb : compare against ddeb repo.
[13:06] <imbrandon> is the georga font installed on a default ubuntu system ? ( how would one find out )
[13:08] <persia> + dietlibc : all
[13:15] <minghua> imbrandon: fc-list Geogia?  I don't think it's installed by default.
[13:15] <imbrandon> minghua: thanks
[13:15] <minghua> s/Geogia/Georgia/
[13:16] <minghua> Georgia is one of the Microsoft "web core fonts".
[13:16] <imbrandon> ahh ok, i've always liked that font, just wondered if it was in the default
[13:18] <ScottK> Fujitsu: Are you planning on looking at python-numpy for merge/sync (hint: I'd really rather not)?
[13:20] <Fujitsu> ScottK: I was talking to the maintainer about it this morning. I'll handle it.
[13:20] <Fujitsu> (they're trying to work out what to do about f2py)
[13:21] <ScottK> Fujitsu: Great.  I discussed it with them some on the Debian Python IRC channel over the weekend.
[13:23] <persia> ScottK: Would you be willing to look at a python packaging effort?
[13:24] <ScottK> persia: If it's quick and not for ~14 hours (am pretending to do $WORK right now).
[13:24] <persia> ScottK: http://revu.ubuntuwire.com/details.py?package=lash is a new upload enabling the python libraries.  I just want to make sure it's sane, and don't understand python packaging well enough to check effectively.  Eyes only: no real testing needed.
[13:25] <persia> (and not for ~14 hours works)
[13:25] <ScottK> persia: OK.  I'll try to remember.  Someone feel free to ping me if I don't get to it tonight.
[13:26] <persia> ScottK: Thanks.
[13:33] <\sh> Fujitsu, ping acidbase -> bug #173646 (CVE-2007-6156) -> only hardy is affected....should be fixed with a sync from debian
[13:33] <ubotu> Launchpad bug 173646 in acidbase "[CVE-2007-6156] cross site scripting vulnerability" [Undecided,In progress] https://launchpad.net/bugs/173646
[13:33] <ubotu> Multiple cross-site scripting (XSS) vulnerabilities in base_qry_main.php in Base Analysis and Security Engine (BASE) before 1.3.9 allow remote attackers to inject arbitrary web script or HTML via the (1) sig[0] and (2) sig[1] parameters. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6156)
[13:34] <Fujitsu> \sh: Looking.
[13:34] <\sh> Fujitsu, I checked allready all former versions from dapper to gutsy :)
[13:34] <Fujitsu> \sh: Very good, thanks.
[13:34] <\sh> Fujitsu, the CVE is wrong. I informed nico already
[13:35] <ScottK> superm1: Would you also please look at pigment.  I suspect it's good for a sync too.
[13:35] <\sh> (wrong regarding the statement all versions before 1.3.9 it's only 1.3.8)
[13:35] <Fujitsu> \sh: I can commit to testing-security now, if you ever need anything.
[13:35] <Fujitsu> I'll mark it off in ubuntu-cve.
[13:35] <Fujitsu> (and request a sync)
[13:38] <Fujitsu> \sh: It hasn't been uploaded to Debian yet.
[13:40] <\sh> Fujitsu, ah...it's on the list of the sponsor...
[13:40] <\sh> Fujitsu, it will be automagically synced anyways
[13:40] <Fujitsu> \sh: Yep.
[13:42] <\sh> Fujitsu, I just synced mitre...and there are some new ones ;) rsync, asterisk etc....
[13:43] <slicer> Anyone have time to look at the latest update for http://revu.tauware.de/details.py?package=mumble ?
[13:45] <\sh> phew...wireshark in edgy and feisty are fixed now...now for gutsy :(
[13:52] <slytherin> apachelogger_: ping
[13:53] <apachelogger_> slytherin: hi
[13:53] <slytherin> apachelogger_: Congrats. :-)
[13:53] <apachelogger_> slytherin: thank you :)
[13:53]  * persia suggests apachelogger_ really wants to do 10 reviews for REVU day today.
[13:54] <apachelogger_> wow, 10 reviews
[13:54]  * apachelogger_ also got other things to do :P
[13:54] <slytherin> apachelogger_: Now that you are MOTU, do you have time to review my package officially? I hope I have incorporated all the things you suggested. :-)
[13:54] <ScottK> apachelogger_: Just find 9 with gutsy in debian/changelog and do one real revu.
[13:55] <Hobbsee> ScottK: a bit hard with only 10 there :)
[13:55] <apachelogger_> lol
[13:55] <ScottK> I guess I should've looked first.
[13:55] <apachelogger_> bah, mumble makes me mumble
[13:55] <imbrandon> gnight all
[13:55] <Hobbsee> i havent, but persia's been talking about it
[13:55] <persia> ScottK: All 10 are reasonable candidates too: no easy ones.
[13:56] <apachelogger_> hm
[13:56] <ScottK> persia: Good thing for me I'm still on strike then (modulo the one I agreed to look at).
[13:56] <apachelogger_> mok0: I told you about the PD stuff :P
[13:56] <persia> ScottK: That one is abusing REVU as a upload repo for an upgrade anyway: it's really bug #164333
[13:56] <ubotu> Launchpad bug 164333 in lash "Please upgrade to 0.5.4" [Wishlist,Fix committed] https://launchpad.net/bugs/164333
[13:56] <mok0> apachelogger_: yes? It's been superseeded it seems
[13:58] <mok0> Douglas is distributing those files under the GPL, which he is entitled to
[13:58] <apachelogger_> yes
[13:58] <apachelogger_> but ye forgot about the copyrights :P
[13:58] <mok0> D*mn
[13:58] <apachelogger_> mok0: http://revu.ubuntuwire.com/details.py?package=theseus
[13:58] <persia> apachelogger_: Good catch!
[13:59] <mok0> grrr
[13:59]  * apachelogger_ takes a all new look at gcutils
[13:59] <apachelogger_> hopefully the last one -.-
[14:03] <slytherin> Do I have to specifically ask someone for reviewing my package or is it going to be done on FIFO basis?
[14:05] <apachelogger_> sl#
[14:05] <apachelogger_> hr
[14:05] <apachelogger_> slytherin: nah, more like on a I feel like revuing that basis ;-)
[14:05] <slytherin> apachelogger_: oh
[14:07] <persia> slytherin: It's usually done in REVU order: FIFO, except that everything with a comment is pulled, and things with advocates go first.  Advertising that you're here might get someone to review your package, especially if you upload soon after a previous review, but when the list is this short, it doesn't help as much.
[14:09] <slytherin> persia: apachelogger_ provided me some comments offline just few days before he became MOTU. :-) I have tried to incorporate those.
[14:10] <persia> slytherin: Excellent.  It's always best to get reviews from lots of different sources for your package.
[14:15] <mok0> apachelogger_: I addressed norsetto's comments. Have you got any before I re-upload?
[14:16] <apachelogger_> mok0: nope
[14:17] <mok0> ok, here goes...
[14:19] <persia> mok0: Just to make sure, build-stamp doesn't need to be .PHONY, as you've touch $@
[14:20]  * mok0 sighs
[14:20] <mok0> persia: I did the change...
[14:21] <persia> mok0: :(
[14:21] <mok0> persia: I'll get rid of it again and make a note for norsetto
[14:21] <persia> mok0: There you go :)
[14:21] <persia> get-orig-source is .PHONY though.
[14:22] <mok0> persia: yes. I switched off thinking and just did the change
[14:22] <persia> mok0: Not best.  All the reviewers have different strengths and weaknesses, and we're all likely to be wrong sometimes.
[14:23] <mok0> persia: Of course. Contributors tend to get sloppy when its getting close to the end, I guess....
[14:23] <apachelogger_> mok0: totally
[14:23] <persia> :)
[14:24] <mok0> persia: there's always that one last thing you forget :-)
[14:25] <persia> mok0: True for reviewers as well, which is one of the reasons I don't like to serially review packages when others aren't.  It's tempting to advocate because all the things I mentioned before are fixed, but that's not the right thing to do.
[14:26] <mok0> persia: that's a very good point
[14:27] <mok0> persia: it's probably better to be patient, and look at it again the next day
[14:27] <persia> mok0: patience is usually good.
[14:29] <ScottK> Bah.  Patience is for the, um ..., patient.
[14:29] <apachelogger_> oioi
[14:30]  * apachelogger_ testbuilds qca2 backport for feisty
[14:32] <persia> ScottK: Never mind about the python packaging check: norsetto already uploaded.
[14:33] <ScottK> persia: OK. Thanks.
[14:34] <ScottK> persia: Just goes to show that usually if you procrastinate long enough, things take care of themselves.
[14:34] <ScottK> ;-)
[14:34] <norsetto> I'm accepting bets on how long it will take before I loose the connection
[14:35] <persia> ScottK: See.  Patience is good :)
[14:35] <ScottK> persia: patience != procrastination.
[14:36]  * persia would disagree, but lacks sufficient ruth
[14:37] <ScottK> persia: How much ruth is required?
[14:38] <persia> ScottK: enough to overcome either the procrastination involved in developing a coherent reply or block the attitude of patience which indicates that all things will develop in the fullness of time
[14:39] <ScottK> Right,  Which just shows patience != procrastination.  They have the same effect, but require an opposite will.
[14:40] <persia> ScottK: So I'm procrastinating when I say "I ought to that, but not right now", and being patient when I say "I ought not do that right now"?
[14:40] <ScottK> persia: Exactly.
[14:40]  * persia does both
[14:53] <apachelogger_> hum
[14:53] <apachelogger_> norsetto and persia did leave because they knew I would come up with a question -.-
[14:54] <apachelogger_> ScottK: bug 161835 - package removal request, the replacing package now creates a transitional package, just assign the bug to ubuntu-archive now?
[14:54] <ubotu> Launchpad bug 161835 in contactsmenu "[Package Removal Request] contactsmenu should be removed from hardy" [Wishlist,In progress] https://launchpad.net/bugs/161835
[14:55] <ScottK> Subscribe, not assign if you're sure it's ready.
[14:59] <apachelogger_> ScottK: ok, thanks
[15:08] <dholbach> does anybody of you know how to write my own macro for moin? do I have to be site admin to deploy it?
[15:12] <dholbach> according to HelpOnMacros I have to be, hrm
[15:27] <dholbach> NICE.... [[Include(page,,editlink)]] is what I wanted - no need for a macro then :-)
[15:28]  * emgent hi
[15:50] <bddebian> Heya gang
[15:57] <\sh> phew
[15:59] <geser> bddebian: Hi!
[15:59] <bddebian> Heya geser
[15:59] <\sh> there is one rule, when you work in a team in your company: if something really terrible happens to you, e.g. some servers are falling onto the ground and break into pieces, please learn to speak up...if not, the team has a problem...and afterwards you have a problem...just happened with a young one here...:(
[16:05] <zul> \sh: your servers are so fragile that they break? :)
[16:06] <\sh> zul, well, the server rails were deformed....
[16:06] <zul> \sh: ah i see
[16:06] <\sh> zul, and we have to buy new ones for those servers
[16:07] <\sh> zul, and the guy didn't tell us, so we as a team were in question...(this guy left the company last week) :(
[16:09] <zul> ah yes..i hate it when that happens
[16:11] <\sh> I mean, there is really no big deal about it, it's insured everything, but he had to say something
[16:31] <Ubulette> damn, tzdata is now stopping on a question even without vty/tty.
[16:35] <Ubulette> apt-get -q -y upgrade in a non-interactive env is now stuck on tzdata :(
[16:39] <ScottK> jdong: I can't set bug importance in gutsy-backports, so I think there's some permissions thing that needs to be flipped.
[16:46] <\sh> ok..time to leave the office...cu later
[16:54] <ScottK> Yeah.  Package history page is fixed on edge.
[16:56] <jdong> ScottK: any idea how to fix that? Assign backporters as the driver?
[16:57] <ScottK> jdong: No idea.
[16:57] <ScottK> jdong: You're the boss.  I just volunteer here.
[17:02] <mok0> wtf? pbsd_main.c:604: warning: string length '753' is greater than the length '509' ISO C90 compilers are required to support
[17:05] <jdong> mok0: careful, gcc might go on strike if you continue using larger strings than the union contract agrees to!
[17:06] <mok0> jdong: I've never seen this warning before. I'll have to investigate
[17:07] <mok0> jdong: ah, it's a joke :)
[17:22] <moteyalpha> I was advised you might know why Planeshift is not in the repository.
[17:24] <moteyalpha> stdin are you a bot?
[17:24] <stdin> no :p
[17:25] <moteyalpha> lol
[17:53] <moteyalpha> moteyalpha is slow today, went to wiki/MOTU and got an answer, Thx, Ishould just RTFM huh?
[17:57]  * txwikinger wonders if he should read the whole Debian policy manual
[17:58] <james_w> ian_brasil: hi. On the MOTU school page you voted for "How do Debian Packaging Teams work?", but your comment said "voted for mobile", did you make a mistake.
[18:00] <ian_brasil> yes i did but i am happy to let my vote stand for the teams tutorial too
[18:04] <james_w> ian_brasil: ok, I'll update it, thanks.
[18:11] <ScottK> txwikinger: Well to be a DD, it's a requirement that you claim to have done it.  It certainly couldn't hurt.
[18:19] <tsmithe> apachelogger__, re your comment on the upstream tarball: it has been modified because upstream supplies a bzipped archive, whereas we want a gzipped one. the recompression would obviously be a form of modification, no?
[18:19] <tsmithe> (about mscore, this is)
[18:19] <LucidFox> If upstream ships a bz2 archive, just bunzip2 the tar and then gzip -9 it
[18:20] <tsmithe> hmm actually that sounds saner than unpacking it completely
[18:20] <ScottK> Substantially.
[18:51] <Adri2000> dfiloni: hi. any progress on wxwidgets2.8?
[18:52] <dfiloni> Adri2000: tomorrow I wil work at the package, now I'm working at italian weekly newsletter
[18:52] <dfiloni> *will
[18:52] <Adri2000> ok, great
[18:53] <slicer> Is there a way to get revu to send you an email when someone posts a comment?
[18:56] <Adri2000> slicer: not as far as I know
[19:00] <ScottK> slicer: There's a mailing list you can subscribe to that gets them all.
[19:01] <griffinc> asac: ping
[19:01] <asac> griffinc: pong
[19:01] <griffinc> hello.  :-)  I have uploaded debdiffs for a merge.    I'm old and I forgot about 10 seconds after I mentioned it.
[19:04]  * ScottK has a vague recollection of thinking he was trying to be helpful and not just mess with you.
[19:04] <bddebian> :-)
[19:05] <keescook> ScottK: pong, from under piles of email
[19:05] <ScottK> keescook: Sure.  Are you responsible for security in partner repo too?
[19:06] <ScottK> keescook: If so, just thought I'd make sure you were aware of the unpatched openssl097 that was uploaded there recently....
[19:06] <mok0> What is "partner repo"? Excuse my ignorance pls
[19:07] <keescook> ScottK: not directly, but I have upload rights.  We're aware of the issue, but since nothing in hardy is linked against it except vmware-server and there is no -dev package for it, and vmware-server doesn't use any of the vulnerable functions, it's technically safe.
[19:07] <keescook> we're waiting for vmware to build against 098, and this was used as a temporary work-around
[19:07] <ScottK> keescook: Good  I'm glad it's not a real issue.
[19:08] <ScottK> keescook: It was more than a little disheartening to see it reappear after having expended a lot of effort personally to get it out of Universe before the Gutsy release.
[19:08] <ScottK> mok0: It's Canonical's commercial repo for stuff that's not distributable without a license.
[19:09] <keescook> ScottK: yup, I feel the pain.  I did tons of universe control+rebuild uploads for edgy to get fewer things to link against it.
[19:09] <mok0> ScottK: interesting, thanks
[19:12] <txwikinger> ScottK: what is more important? consistency or policy?
[19:13] <ScottK> txwikinger: Depends on the context.  What specifically.
[19:13] <txwikinger> I have packaged this perl-library package
[19:13] <ScottK> OK.
[19:13] <txwikinger> it is an additional library for tk
[19:14] <ScottK> Yes.
[19:14] <txwikinger> perl-tk
[19:14] <txwikinger> it is arch-independent
[19:14] <txwikinger> so it should be in usr/share/perl5
[19:14] <ScottK> Shouldn't it be something like libtk-perl?
[19:14] <txwikinger> yes
[19:14] <txwikinger> but libtk-perl is arch-dependent
[19:14]  * ScottK looks for the Perl policy.
[19:15] <txwikinger> anyway... all similar arch-independent libraries for tk are in /usr/lib/perl5 where tk is
[19:15] <maiatoday> is there a log file for last friday's MOTU Q&A in the classroom, please?
[19:16] <Pici> !logs | maiatoday perhaps
[19:16] <ubotu> maiatoday perhaps: Channel logs can be found at http://irclogs.ubuntu.com/ - Logs for LoCo channels are at http://logs.ubuntu-eu.org/freenode/
[19:16] <ScottK> txwikinger: I'm reading of Perl policy right now.
[19:16] <txwikinger> is it on the MOTU wiki?
[19:18] <maiatoday> ubotu thanks, irclogs did the trick
[19:19] <ScottK> txwikinger: http://www.debian.org/doc/packaging-manuals/perl-policy/
[19:19] <txwikinger> Ah debian :)
[19:20] <ScottK> txwikinger: If you haven't read that, then check that and see if your question is answered.  I think it is.
[19:21] <txwikinger> well, I know what lintian says and it makes sense
[19:21] <txwikinger> I think it is just odd that all the other ones are in the wrong place
[19:22] <txwikinger> ScottK: yes it is there: In each of the directory pairs above, the lib component is for binary (XS) modules, and share for architecture-independent (pure-perl) modules.
[19:23] <ScottK> I'd suggest then that you see if you can figure out why the others are located where they are.  It may be a bug or there may be some special reason.
[19:24] <txwikinger> ScottK: Yes, I will do that
[19:35] <bdgraue> jdong: i requested to backport psi 0.11, i tried to build it with prevu and added the logto https://bugs.launchpad.net/feisty-backports/+bug/173532 , ScottK told me it would need an source backport. can you take a look at this?
[19:35] <ubotu> Launchpad bug 173532 in feisty-backports "please backport psi 0.11" [Undecided,New]
[19:35] <ScottK> jdong: I'm leaving it to you if it's worthy of a source backport or not.
[19:36] <ScottK> bdgraue: Be patient.  I wouldn't be suprised if jdong is in class or something right now.
[19:36] <bdgraue> yes, thanks for you help ScottK
[19:37] <ScottK> No problem.
[19:49] <jdong> ScottK / bdgraue I am indeed in class, in the middle of a final project, and have to answer to an exam soon
[19:49] <jdong> so give me 6 hours and I'll do backports :)
[19:49] <ScottK> jdong: Do it now or we cut your pay in half.
[19:50] <bdgraue> good luck for the exam, jdong
[19:56] <SWAT> is 'smart' to remove LDFLAGS from the ./configure command? Without my package seems to build fine.
[20:11] <dcordero> hi
[20:12] <dcordero> i know how to do packages, i have learn reading the Packaging Guide, but, how and where can i get experience and how to check if my packages are correctly created?
[20:13] <ScottK> dcordero: This is the place.
[20:14] <ScottK> You can upload your packages to REVU and MOTUs will have a look at them and give you feedback.
[20:14] <ScottK> !revu| dcordero
[20:14] <ubotu> dcordero: REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[20:14] <keescook> Fujitsu: you have some mplayer security bugs set to "in progress" without a debdiff.  is that intentional?  (should they be "triaged" until there's a debdiff?)
[20:15] <dcordero> i see, thanks
[20:23] <SWAT> on that note, is it safe to just remove the LDFLAGS in debian/rules on the './configure' line? There it doesn't accept += to 'add' them instead of replacing them.
[20:24] <slangasek> SWAT: can you describe more concretely what it is you're doing?
[20:26] <SWAT> I'm compiling a package from source. If LDFLAGS="-Wl,-z,defs" (at ./configure), then it complains about not finding libraries. If I remove LDFLAGS from the ./configure line, it works. But I imagine that LDFLAGS set more or less important additional libraries. So it's probably 'nice' to 'add' them (+= or something like that) instead of completely removing them
[20:28] <slangasek> first of all, LDFLAGS is only supposed to be used for flags, not libraries.  second, LDFLAGS are not (generally, currently) set from outside debian/rules itself, so if this is the only value of LDFLAGS being set in debian/rules it's probably ok to drop it from ./configure - but if you have any doubts, the more "correct" way is to not set -Wl,-z,defs in the first place
[20:28] <TheMuso> Hey MOTUs.
[20:29] <geser> Hi TheMuso
[20:29] <lifeless> where?
[20:29] <slangasek> SWAT: third - what package is this?  -Wl,-z,defs is very important, and with the exception of things that are plugins, things that fail to build under -Wl,-z,defs are buggy
[20:30] <lifeless> slangasek: buggy or hard core old style unix trickery abusers.
[20:31] <slangasek> lifeless: I consider the latter a subset of the former ;)
[20:31] <lifeless> :)
[20:31] <ScottK> Heya TheMuso.
[20:32] <slangasek> lifeless: yes, it's either buggy or it's c-client; see also: buggy
[20:34] <SWAT> slangasek, it's a small application. But thanks for the info. I think the application itself sets a lot of things (when ldflags is active, the libraries don't link). But I know enough, thanks a lot!
[20:36] <jcastro> ScottK: got some time, I have a motu procedural question
[20:36] <ScottK> jcastro: If ot
[20:36] <ScottK> it's quick
[20:36] <jcastro> I have this guy who fixed bug 91964 by applying a patch and publishing via ppa
[20:37] <ubotu> Launchpad bug 91964 in network-manager-vpnc "No Option To Save Group Password" [Undecided,Confirmed] https://launchpad.net/bugs/91964
[20:37] <nxvl_work> jcastro: just ask, if ScottK can't someone else can help you
[20:37] <slangasek> SWAT: yes, if they're libraries failing to link with -Wl,-z,defs, then the libraries are missing declarations of their dependencies; the consequences of this can range from undeclared package dependencies to improper resolution of versioned symbols
[20:37] <jcastro> is that useful or is there a more "correct" way?
[20:37] <jcastro> nxvl_work: thanks!
[20:37] <ScottK> jcastro: Let me look
[20:38] <DaveMorris> is there a nice watch file howot I can read?
[20:38] <nxvl_work> jcastro: a patch is a better way, so any sponsor can look at it, instead of creating it or checking the diff.gz and compare them
[20:38] <ScottK> jcastro: Well that's useful for testing, but he really ought to work on getting it into Ubuntu.
[20:39] <ScottK> DaveMorris: man uscan.  Did you ask about this yesterday?
[20:39] <jcastro> ScottK: ok
[20:39] <jcastro> nxvl_work: ok, so should I have him post the patch instead?
[20:40] <DaveMorris> ScottK: I did, however that just explains what it is, not what files I should be watching on the ftp/http servers
[20:40] <ScottK> jcastro: What we need is a debdiff for the package that's suitable for upload.
[20:40] <nxvl_work> jcastro: yep, but i think you can ask him to post it too
[20:40] <jcastro> ok, and attach the debdiff to the bug then?
[20:40] <ScottK> DaveMorris: That depends on the package and where it is.  It's the tarball for the package you want.
[20:40] <nxvl_work> jcastro: yes
[20:40] <jcastro> excellent, thanks guys!
[20:40] <ajmitch> jcastro: https://wiki.ubuntu.com/SponsorshipProcess
[20:41] <nxvl_work> jcastro: if he post the debdiff is easier to look what exacly has he changed
[20:41] <ScottK> jcastro: and then subscribe ubuntu-universe-sponsors to the bug (assuming the package is in universe)
[20:41] <DaveMorris> ScottK: what happens when it's changed then?
[20:42] <ScottK> Argh.
[20:42]  * ScottK tries again.
[20:42] <ajmitch> :)
[20:42] <\sh> highvoltage, dude, just see my comment on your blog :) those are important games, forget battle of wesnoth ,-)
[20:43] <\sh> hey ajmitch
[20:43] <ajmitch> hi
[20:51] <nxvl_work> is there any way of getting the sources from a .deb file?
[20:51] <\sh> nxvl, nope...in .deb files are no source files (no tar.gz if you mean this)
[20:51] <dsop> nxvl_work: dpkg -x or -X ?
[20:52] <nxvl_work> dsop: this is from a dsc, not from a deb file
[20:52] <\sh> going back to bed :)
[20:53] <norsetto> nxvl_work: you mean the files inside a deb?
[20:53] <nxvl_work> norsetto: i have a deb, and i want to make some changes so i need the sources, but they aren't available, can i get them?
[20:54] <norsetto> nxvl_work: not from the deb
[20:54] <nxvl_work> norsetto: ok, i will make it from tha tar.gz, thnx
[20:54] <norsetto> nxvl_work: is it from ubuntu?
[20:54] <nxvl_work> i'm working on bug #145193
[20:54] <ubotu> Launchpad bug 145193 in ubuntu "[needs-packaging] Phatch" [Wishlist,Confirmed] https://launchpad.net/bugs/145193
[20:55] <norsetto> nxvl_work: and there is a deb somewhere you want to use as a starting point I guess?
[20:55] <nxvl_work> norsetto: yep
[20:56] <norsetto> nxvl_work: hmmm, if its from getdeb you should find the sources there too
[20:57] <nxvl_work> norsetto: i will do it the traditional way :D
[20:58] <TheMuso> Is anbody working on the transcode package? If so, there is https://bugs.launchpad.net/bugs/173662 to be considered.
[20:58] <ubotu> Launchpad bug 173662 in transcode "needs rebuild for libglib1.2ldbl transition" [Undecided,New]
[20:58] <TheMuso> anybody
[20:59] <TheMuso> If not, I'll take care of it.
[21:00] <nxvl_work> if i'm doing a new package, should i name ubuntu1 to the version or it's only if i make changes to it?
[21:00] <norsetto> nxvl_work: upstreamversion-0ubuntu1
[21:00] <nxvl_work> thnx
[21:03] <Fujitsu> keescook: They're fixed by the debdiff in the other bug.
[21:03] <keescook> Fujitsu: oh! okay, sorry
[21:03] <keescook> (i haven't made my way through all of them yet)
[21:03] <nxvl_work> where can i find a list of "Section"'s and the criteria to pick one
[21:06] <DaveMorris> ScottK: is this correct for a watch file http://www.pastebin.ca/804866  I run uscan-report and it doesn't return anything so I'm not sure
[21:06] <keescook> Fujitsu: I must be blind, I can't find any mplayer bug in-progress with a debdiff
[21:07] <Fujitsu> keescook: Hum, I'll give you a number in a sec.
[21:07] <geser> nxvl_work: Debian policy should contain a list
[21:07] <Fujitsu> Bug #92968
[21:07] <ubotu> Launchpad bug 92968 in mplayer "CVE-2007-1246: MPlayer DMO buffer overflow" [Undecided,In progress] https://launchpad.net/bugs/92968
[21:07] <Fujitsu> keescook: ^^
[21:09] <norsetto> nxvl_work: if you want the debian/, most probably is available in the bzr branch: https://launchpad.net/phatch/
[21:09] <keescook> Fujitsu: ah-ha!  thanks.
[21:10] <nxvl_work> norsetto: thnx
[21:10] <nxvl_work> norsetto: the developer should post it on the bug :S
[21:14] <james_w> DaveMorris: try uscan --report-status
[21:14] <nxvl_work> norsetto: it isn't there :S
[21:16] <DaveMorris> james_w: thanks
[21:16] <Fujitsu> Um, anybody here use yarssr? There was apparently a regression (bug #172667), but I tested the patch beforehand, and can't reproduce it even now.
[21:16] <ubotu> Launchpad bug 172667 in yarssr "yarssr improperly generates urls" [Undecided,New] https://launchpad.net/bugs/172667
[21:28] <dsop> oh revu day
[21:28] <apachelogger__> still -.-
[21:28] <apachelogger__> will that never end
[21:29] <dsop> hehe
[21:30] <apachelogger__> dsop: so, what is to be revued?
[21:31] <dsop> apachelogger__: for you, nothing, still searching somebody who is willing to be the second advocate on my gcutils
[21:31] <dsop> apachelogger__: you allready advocated (thx so far)
[21:32] <apachelogger__> aye :)
[21:32] <apachelogger__> jpatrick: pling
[21:32] <jpatrick> apachelogger: can't tonight, not suppose to be online right now ;)
[21:32] <frafu> Hello, If I remember correctly, some time ago I downloaded the changes of which revision of a project in launchpad as a diff file; unfortunately I cannot find anymore how to do it. Has that possibility been removed?
[21:33] <apachelogger> jpatrick: ok :)
[21:34] <apachelogger> mok0: pling
[21:35] <DaveMorris> can someone please review my package at http://revu.tauware.de/details.py?package=cpptest (takes around 5 mins to build on my machine)
[21:36] <apachelogger> DaveMorris: did I comment on it already?
[21:37] <apachelogger> ah
[21:37] <apachelogger> diffent package
[21:37] <apachelogger> nm
[21:37] <frafu> Another question: I uploaded a package to revu and a reviewer posted some comments. Unfortunately I don't understand one of the comments and posted also a comment to ask for more details. Will the reviewer be automatically notified about my comment?
[21:38] <james_w> DaveMorris: libcpptest-dev should be Section: libdevel
[21:39] <apachelogger> frafu: no
[21:39] <james_w> DaveMorris: you don't need XSBC-Original-Maintainer
[21:39] <apachelogger> frafu: you might try to reach him on IRC, usually fastest solution
[21:39] <james_w> (unless this is from Debian, but I guessed not)
[21:39] <DaveMorris> james_w: how come?  No one else has picked up on it?
[21:39] <DaveMorris> no it's a new package
[21:39] <james_w> DaveMorris: which one?
[21:40] <DaveMorris> XSBC-Original-Maintain
[21:40] <frafu>  apachelogger: thanks; he is not online at the moment
[21:40] <dsop> apachelogger: grad gesehen, das du paniq kennst/magst
[21:41] <james_w> well, you can have it, you don't *need* it. It states who maintains it in a distro that Ubuntu merged from and in this case that is none. Your name is in changelog if people want to see who packaged it.
[21:41] <james_w> DaveMorris: if you want to have absolute control then put yourself in Maintainer:
[21:41] <apachelogger> dsop: kinda ;-)
[21:41] <DaveMorris> no I'm fine
[21:41] <DaveMorris> just wondered why no-one else had picked up on it
[21:42] <dsop> apachelogger: from where, demoscene stuff or just found it somehwere in the inet?
[21:42] <apachelogger> james_w: nope, I really think our policy says ubuntu motu needs to be maintainer
[21:42] <apachelogger> that's why XSBC-Original-Maintainer is used
[21:43] <apachelogger> dsop: the amarok founder knows him personally IIRC
[21:43] <apachelogger> and since I'm part of the team I came to get in contact with his work ;-)
[21:43] <DaveMorris> so what should I use?
[21:44] <apachelogger> DaveMorris: from my knowledge you should stick to the current version
[21:44] <james_w> apachelogger: I believe Original-Maintainer was to prevent claiming a package was maintained by the Debian maintainer when Ubuntu had changed it. However whether or not ubuntu-motu is in maintainer is a different question.
[21:44] <apachelogger> you might check back with a third motu though
[21:44] <james_w> second, I'm not a motu
[21:44] <apachelogger> ok, so my opinion is more imporant :P
[21:44] <apachelogger> DaveMorris: well, seriously check back with another motu whether it is needed
[21:45]  * apachelogger is quite sure though
[21:45] <apachelogger> DaveMorris: Standards-Version: <IP_ADDRESS> please
[21:45] <DaveMorris> sispoty didn't say not to have it when he reviewed it before
[21:45] <apachelogger> so it might at least be legal ;-)
[21:45] <apachelogger> DaveMorris: you might put the source package section to libs and remove it from the binary section of libcpptest0
[21:45] <apachelogger> saves you one line
[21:46] <james_w> DaveMorris: shouldn't -doc be Architecture: all?
[21:46] <DaveMorris> any != all then?
[21:46] <apachelogger> depends on the doc type
[21:46] <imbrandon> maintainer must equal a @ubuntu.com or @kubuntu.org email address, if it dosent , even for new packages it needs to use Orig-Main as the packager and MOTU as the Maint addr
[21:47] <imbrandon> ( this is on the wiki )
[21:47] <apachelogger> DaveMorris: nope, any states it can be built for any platform, so you still ned up with builds for all platforms
[21:47] <james_w> sorry, I was just describing a suggested convention then.
[21:48] <apachelogger> DaveMorris: control: line 18, 30, 42 -> unnecessary white space at line end
[21:48] <james_w> DaveMorris: no, any means build it on each architecture, all means you can build it on one and install it on the rest.
[21:48] <james_w> DaveMorris: is there is reason that you patch the .pc file in to place, rather than installing from debian/?
[21:48] <apachelogger> DaveMorris: you might want to add a description text like "This package contains the development libraries and headers" for lib and -doc as well
[21:49] <james_w> DaveMorris: also did you send that file upstream?
[21:49] <Ubulette> Prism needs review / test from someone. Please, have a look. http://revu.tauware.de/details.py?upid=798 or at least tell me why it's being ignored
[21:49] <keescook> \sh_away: just a note for your CVE debdiffs: can you use your own words for the "SECURITY UPDATE:" section?  I like having a short summary of the issue in the form "[worst case] from [cause]".  This is mentioned on the SecurityUpdateProcedures wiki.  Regardless, thanks.  Keep up the great work.  :)
[21:49] <DaveMorris> apachelogger: isn't that obvs?
[21:49] <apachelogger> DaveMorris: might not be to users
[21:49] <DaveMorris> james_w: afaik it doesn't matter which way you do it, and no I've not sent it upstream yet
[21:49] <keescook> Fujitsu: sweet, I think I've got all your uploads processed now.  Thanks for getting them all ready!  :)
[21:50] <apachelogger> DaveMorris: then you could use the same reason to remove the text from the -dev
[21:50] <apachelogger> DaveMorris: typo: "framework" not "frame work"
[21:50] <DaveMorris> true
[21:50] <Fujitsu> keescook: Thanks.
[21:51] <james_w> DaveMorris: the .a file belongs in the -dev package.
[21:51] <apachelogger> DaveMorris: line 16, 28, 40 also have a trailing white space
[21:51] <imbrandon> the .a file should die, iirc we dont wwant static libs unless nessesary
[21:52] <apachelogger> yep
[21:52] <james_w> DaveMorris: what imbrandon said as well.
[21:52] <apachelogger> DaveMorris: just don't list the .a files in any .install
[21:52] <slangasek> hrm? the vast majority of libraries still ship static libs
[21:53] <apachelogger> imbrandon: extendability isn't a valid word, is it?
[21:53] <james_w> DaveMorris: also the /usr/include files should be in the -dev package.
[21:53] <james_w> DaveMorris: sorry, being stupid, they are already I see.
[21:54] <imbrandon> slangasek: sure but we dont want them e.g i've always been told to rm the .a and .la:)
[21:55] <slangasek> imbrandon: for new packages or packages imported from Debian?  I don't think deleting the .a is a very good reason to diverge from Debian...
[21:55] <slangasek> (deleting .la files is worthwhile everywhere, OTOH :)
[21:55] <imbrandon> slangasek: yea, this is for NEW NEW
[21:55] <imbrandon> is the reason i mentioned it
[21:56] <imbrandon> e.g. -0ubuntu1 version
[21:57] <DaveMorris> any other problems guys?
[21:57] <apachelogger> DaveMorris: typo: extensibility, not extendability
[21:57] <pgquiles> is it possible to build packages using pbuilder and distcc? I'm building a customized kernel and it takes forever :-(
[21:57] <apachelogger> -dev should depend on libcpptest0 (= ${source:Version})
[21:58] <slangasek> ${binary:Version}, really
[21:58] <slangasek> (not a relevant difference for Ubuntu, but relevant for Debian)
[21:58] <apachelogger> *shrug*
[21:58] <apachelogger> ok
[21:58] <apachelogger> DaveMorris: in copyright please include GPL version of packaging
[21:59] <apachelogger> DaveMorris: trailing white space at line 4
[22:00] <DaveMorris> apachelogger:  so for the depends do I put in what you've posted and cdbs works it out for me, or do I need to put the numbers in myself
[22:00] <apachelogger> DaveMorris: yep, but as slangasek state you should use binary:Version
[22:00] <apachelogger> trailing white space at line 11 of debian/rules
[22:01] <DaveMorris> is trailing spaces really an issue?
[22:01] <apachelogger> DaveMorris: nah, but really no biggie to fix, is it?
[22:01] <james_w> DaveMorris: also your debian/copyright should be more like http://paste.ubuntu-nl.org/46756/
[22:01] <DaveMorris> I'm fixing them
[22:02] <apachelogger> DaveMorris: please remove commented cruft from debian/watch
[22:02] <james_w> (and apachelogger's comment about the version of yout packaging).
[22:02] <DaveMorris> the commented cruft was in the gnash example I looked at
[22:02] <apachelogger> there is no such thing as a perfect example package ;-)
[22:03] <dsop> james_w: shouldn't be said which version of the gpl is used ?
[22:03] <apachelogger> DaveMorris: at least the intro crap can be removed
[22:03] <james_w> dsop: yes.
[22:03] <apachelogger> pointed that out already
[22:04] <james_w> DaveMorris: sorry, can you break the long line in the copyright file that I pasted, my mistake.
[22:06] <ScottK> james_w: We usually use orignal maintainer for new packages, but you're right.  It's not required.
[22:06] <ScottK> DaveMorris: No response from uscan is normal when it found the current version.
[22:07] <DaveMorris> thanks
[22:07] <DaveMorris> anything else, I think I've kept up with your changes and make them all
[22:07] <james_w> ScottK: ah, thanks for the clarification.
[22:07] <ScottK> james_w: Generally for new packages it's set to whoever packaged it.
[22:08] <ScottK> If anyone wants revu comments/uploads via mail, you can sign up here: http://lists.tauware.de/listinfo/motu-reviewers
[22:08] <ScottK> imbrandon: Since you're making RSS feeds, http://lists.tauware.de/listinfo/motu-reviewers might be nice to have as a feed.
[22:09] <imbrandon> ScottK: k
[22:10] <apachelogger> hm
[22:10] <apachelogger> actually
[22:10] <apachelogger> I should blog about the list, especially how to filter it to personal needs ;-)
[22:10] <apachelogger> though revu should really get an automatic notification on comment feature for uploaders
[22:11] <persia> apachelogger: The code is out there: patches encouraged.
[22:11] <ScottK> persia: You type faster than I do.
[22:11] <apachelogger> I no :P
[22:11]  * persia is skeptical, and suspects distraction
[22:11] <apachelogger> persia: what is revu written in anyway?
[22:12] <ScottK> apachelogger: Python
[22:12] <apachelogger> hm
[22:13] <apachelogger> <-- not exactly a python haxor :|
[22:13] <james_w> DaveMorris: rest looks good to me.
[22:13] <persia> DaveMorris: cpptest advocated
[22:15] <apachelogger> persia: btw, you might take a look at theseus, should be kinda advocatable
[22:15] <DaveMorris> persia: I was just fixing the issues others had mentioned
[22:15] <tsmithe> apachelogger, new upload of mscore to revu: This upload fixes all the above issues, fixes a regression (by installing a small soundfont enabling instant playback, which had been lost due to the patch to use the Ubuntu-supplied FluidSynth), installs an icon, and fixes the .desktop file to work in KDE as well as GNOME/XFCE.
[22:16]  * persia hides in shame
[22:16] <tsmithe> (where the above issues were those you raised on revu)
[22:16] <ScottK> DaveMorris: If persia has already advocated your package, you might check to make sure the other comments you got are correct from his perspective.
[22:16] <apachelogger> persia: hide in theseus :P
[22:16] <tsmithe> apachelogger, http://revu.tauware.de/details.py?upid=855 if you are interested
[22:16]  * persia disagrees with ScottK: there are many reviewers for a reason
[22:17] <apachelogger> tsmithe: checking that out as soon as cpptest ist uploaded
[22:17] <mok0> apachelogger: :-)
[22:17] <tsmithe> apachelogger, thank you
[22:17] <Fujitsu> Anybody around who knows much Perl?