[00:03] <lamont> lifeless: practice makes perfect
[00:17] <jdong> \sh_away: just confirmed gaim is not affected by the pidgin <a> exploit
[00:18] <ion_> doko: Why was icedtea bootstrapped with gcj, btw? Because it was formerly bootstrapped with a non-free implementation?
[00:39] <soren> slangasek: Just for fun, I decided to see if I could figure out why the heck we log_success_msg the usage in the samba init scripts. All I've found out is that it's been that way since warty.
[00:40] <slangasek> soren: I think we can chalk it up to lamont's bad influence
[00:40] <lamont> soren: if it's been that way since warty, then it's probably crack.
[00:40] <soren> lamont: Clearly :)
[00:40] <lamont> slangasek: it was a gentoo guy...
[00:41] <lamont> he didn't work for canonical for very long....
[00:41] <soren> There's a changelog entry from a Nathaniel McCallum that says that he prettified the init script.
[00:41] <soren> lamont: Him?
[00:41] <slangasek> oh, really? :)
[00:41] <lamont> just long enough to "fix" all of desktop to do lsb-ish inits.  nevermind about that -e flag at the top and checking return values and such...
[00:42] <slangasek> hahaha
[00:42] <slangasek> yeah, I'm still bitter about having had to drop the -e from the samba init scripts :)
[00:42] <soren> Is the name supposed to ring a bell?
[00:42] <lamont> you know... change it to say start-stop-daemon .... ; lsb_<mumble> $? in a script that says #!/bin/sh -e ....
[00:43]  * lamont doesn't discuss names
[00:43] <lifeless> lamont: changelog does that for you
[00:43] <lamont> lifeless: I will nether refute nor confirm that. :-)
[00:44] <slangasek> "never speak ill of the braindead"?
[00:45] <lamont> "what's an soname?"
[00:45] <ScottK> Ah.  Him.
[00:46] <soren> Haha!
[00:46] <lamont> "I mean, if you just recompile everything, then you don't need multiple copies of the library"
[00:46]  * lamont wonders if it would violate the CoC to say that some distros foster gentoo-esque thinking
[00:47]  * soren goes to bed
[00:47] <soren> Good night.
[00:47] <slangasek> 'night
[00:47] <Ng> Amaranth: yes. the fix is to make the window menu work
[00:47] <ScottK> lamont: As long as you don't explicitly define gentoo-esque, I think you're safe.
[00:47] <Ng> Amaranth: imo :)
[00:48] <ScottK> good night soren.
[00:48] <Ng> Amaranth: in that all of the functions of the window menu are still entirely applicable to an undecorated window
[00:48] <lamont> ScottK: heh
[00:49] <lamont> ScottK: context can be a real bitch, you know.
[00:49] <ScottK> Whatever people choose to infer from that is not your responsibility.
[01:04]  * Hobbsee waves
[01:06]  * lamont waves Hobbsee 
[01:06] <Hobbsee> heya lamont!
[01:26] <pwnguin> hey uh, who put thinkfinger in from my ppa?
[01:26] <Hobbsee> ?
[01:27] <Hobbsee> pwnguin: it's not in the archive, unless it's in source new or something.
[01:30] <pwnguin> i just got an email
[01:30] <jdong> wasn't my fault! I swear! ;-)
[01:31] <Hobbsee> pwnguin: it's probably something bothced with LP
[01:31] <Hobbsee> LP likes sending random email
[01:32] <Hobbsee> of course, ti doesn't help that people seem to like assigning bugs to groups with 100+ people in them
[01:32] <RAOF> Yup.  There it is, sitting in NEW.
[01:33] <lifeless> I think you should not be able to assign
[01:33] <lifeless> only accept
[01:33] <pwnguin> well, i filed a sync request
[01:33] <pwnguin> pitti seconded it
[01:33] <pwnguin> i thought it was gonna come from debian, not my ppa
[01:33] <Hobbsee> pwnguin: so you got the accepted mail, for the sync.
[01:33] <slangasek> arr, not funny
[01:34] <slangasek> cjwatson: debian-installer has failed to build with mklibs errors, am hunting now
[01:34] <Hobbsee> pwnguin: http://launchpadlibrarian.net/10626425/thinkfinger_0.3-2_source.changes - isn't that from experimental?
[01:34] <pwnguin> Hobbsee: im not sure, but the .dsc has my name on it
[01:34] <Hobbsee> pwnguin: because of maintainer mangling
[01:34] <Hobbsee> see the spec.
[01:34] <pwnguin> ok
[01:35] <crimsun> it is from experimental.
[01:38] <pwnguin> oh, heh
[01:38] <pwnguin> the next email in line has the log from the sync ;)
[01:57] <StevenK> lamont: http://launchpadlibrarian.net/10554595/buildlog_ubuntu-hardy-hppa.libgpod_0.6.0-2_CHROOTWAIT.txt.gz if you've not seen it
[01:58] <StevenK> lamont: Specifically, Inconsistency detected by ld.so: dl-fini.c: 180: _dl_fini: Assertion `ns != 0 || i == nloaded' failed!
[01:59] <lamont> FTW.
[01:59] <StevenK> Heh
[01:59] <StevenK> It's PA-RISC hardware wonderful? :-)
[01:59] <StevenK> Er, Isn't
[02:00] <lamont> doko: what did the new gcc-4.2 do to hppa????
[02:01] <LaserJock> what is hppa useful for?
[02:02] <lamont> LaserJock: it's useful for keeping lamont happy
[02:02] <LaserJock> useful indeed
[02:02] <lifeless> its useful for finding bugs
[02:02] <lamont> StevenK: on the bright side, libgpod is the first such failure in a while.  so dunno... maybe I'll just give it back and see how it does..
[02:02] <lifeless> because its an anal platform
[02:02] <lamont> lifeless: and big endian
[02:03] <lamont> and can be told to throw a fit at unaligned loads/stores
[02:03] <lifeless> big endian, weird alignment rules
[02:03] <lifeless> if only it had stayed slow
[02:03] <lifeless> ;)
[02:04] <lamont> "This special 2-4 week Online program that will earn you a full non-accredited
[02:04] <lamont> degree based on your work experience and past/present knowledge."
[02:04]  * lamont rotfl
[02:05] <LaserJock> cool
[02:05] <LaserJock> I shoulda tried that instead of 9 years of sweat and tears
[02:07] <ScottK> Blood. Don't forget the blood.
[02:07] <zul> LaserJock: its useful as a doorstop
[02:08] <LaserJock> ScottK: I tried to avoid the blood
[02:08] <LaserJock> ScottK: although i did crush a NMR tube and cut my hand once
[02:09] <RAOF> Ow.
[02:10] <LaserJock> well, the bad part is it was a $180 1cm, quartz, flat-bottom NRM tube
[02:14]  * ScottK figured there'd be blood.  What with the lasers and all.
[02:14] <LaserJock> well
[02:14] <LaserJock> lasers tend to coagulate blood well
[02:15] <ScottK> Don't they also blow up sometimes?
[02:15] <LaserJock> well ...
[02:15] <LaserJock> it didn't exactly "blow up"
[02:15] <ajmitch> LaserJock isn't human anymore, he's a grad student
[02:15] <Hobbsee> argh
[02:15] <ajmitch> argh to you too
[02:15] <Hobbsee> don't make me feel bad for finally taking a break from writing these pracs up.
[02:16] <ajmitch> heh
[02:16] <ajmitch> you deserve a break, don't you?
[02:16]  * Hobbsee wants to get this stuff done!
[02:16]  * Hobbsee was bad, procrastinating earlier in teh semester.
[02:17]  * slangasek gives lamont a full non-accredited degree: ⁰
[02:17] <RAOF> This is how you can tell Hobbsee isn't a grad student.  We procrastinate *all through* the semester.
[02:17] <LaserJock> haha
[02:19] <lamont> slangasek: thank you so much.  remind me to by you $BEVERAGE next time we meet.
[02:19] <Hobbsee> RAOF: i've got a deadline of friday, and i said i'd have it done by yesterday.
[02:20] <LaserJock> haha
[02:20] <slangasek> so given how long it's taking bzr to pull down the debian-installer repo, I should probably ask sooner rather than later - is there anyone around willing to be my designated core-dev for this evening? :)
[02:20] <LaserJock> another non-gradstudent remark
[02:20] <Hobbsee> no really. friday is the solid deadline
[02:20] <LaserJock> saying you'd have *anything* done before a deadline?
[02:21] <pwnguin> yes, but why would it be done before the deadline?
[02:21] <Hobbsee> the deadline that they were quoting for it, during semester, was the 8th, iirc.
[02:21] <slangasek> (someone to merge changes to https://code.launchpad.net/~ubuntu-core-dev/debian-installer/ubuntu, and to upload the results)
[02:21] <Hobbsee> well, i didn't know the hard deadline until a few hours after when i got the phonecall saying "where's your stuff?"
[02:21] <LaserJock> Hobbsee: ouch
[02:21] <pwnguin> you're starting to redeem yourself ;)
[02:21]  * TheMuso feels for Hobbsee, having been through something similar when he was at uni.
[02:22] <ajmitch> LaserJock: I'd say Hobbsee is quite qualified to be a grad student, don't you think?
[02:22] <Hobbsee> ajmitch: nah, i don't have the patience
[02:22]  * RAOF used to be able to hit deadlines.
[02:22]  * ajmitch hits deadlines & keeps on sailing through
[02:25] <lamont> slangasek: if you need a core-dev-bitch, I suppose I could fill in
[02:25] <lamont> but I'm gonna take back that $BEVERAGE
[02:26] <slangasek> that's fair :)
[02:26] <lamont> slangasek: but only until 11PM your time.
[02:27] <slangasek> ack
[02:29] <LaserJock> ajmitch: I just forget deadlines
[02:29] <LaserJock> "oh, there was a meeting today? huh"
[03:18] <StevenK> lamont: Heh, libgpod moves from chroot problem to dep wait
[03:18] <lamont> yep.  I was just going to say that
[03:28] <lamont> slangasek: so what are you breaking in debian-installer?
[03:29] <tonyyarusso> hopefully something encryption-related
[03:31] <slangasek> lamont: I'm planning to break the FTBFS
[03:31] <slangasek> but haven't had any luck yet
[03:31] <lamont> oh
[03:31] <slangasek> it's a thrice-damned mklibs problem
[03:35] <slangasek> ah, we may be in luck and it's just Debian bug #443248 surfacing because newt isn't merged yet
[03:35] <ubotu> Debian bug 443248 in newt "Please link with -ldl" [Normal,Fixed] http://bugs.debian.org/443248
[03:37]  * StevenK tries some of his wife's "digestive helping tea"
[03:37] <StevenK> It even looks insipid
[03:38] <jdong> StevenK: ugh that stuff is all placebo and marketing
[03:39] <slangasek> ...
[03:39] <lamont> jdong: if it works, who cares?
[03:39] <StevenK> If it helps my stomach get over lunch, I don't care. :-)
[03:39]  * StevenK high fives lamont 
[03:39] <StevenK> /usr/bin/ld: final link failed: Nonrepresentable section on output
[03:40]  * StevenK sighs
[03:40] <jdong> StevenK: in China they use domperidone for that purpose.... I find that slightly unsafe though extremely effective :)
[03:40] <StevenK> I'm little bemused that the ingredients list was "Please refer to leaflet"
[03:41] <jdong> StevenK: lol that's to separate it from the "FDA says this is total BS" label they are required to affix.
[03:42] <slangasek> not in Australia
[03:42] <StevenK> Right
[03:43]  * StevenK sighs at XUL 1.9
[03:43] <jdong> ah, right you people aren't from the states
[03:43]  * lamont got a kick out of update-manager's "this is gonna take forever, and you can't stop and restart it, ok?" question
[03:43] <lamont> jdong: slangasek is from portland.  that's not in the US>
[03:43] <StevenK> Bwahaha
[03:43] <StevenK> Now I get undefined reference to the gtkmozembed functions it's using.
[03:43] <slangasek> I was referring to StevenK, but thank you all the same
[03:44] <lamont> StevenK: are you racing slangasek to a solution?
[03:44] <StevenK> I'm from that island prison that the English keep
[03:44] <StevenK> lamont: I suspect slangasek and I are sighing about different things
[03:44] <jdong> StevenK: awesome, with the kangaroos! I learned about that in 4th grade geography!
[03:44] <lamont> ah, ok
[03:44]  * StevenK kicks jdong in the head
[03:44] <slangasek> yes, gtkmozembed is not used in d-i
[03:45] <jdong> hahahaha
[03:45] <lamont> hrm.. I need a fax/modem board with caller id
[03:45] <StevenK> Although, help with debugging linking against gtkmozembed gratefully accepted
[03:46] <lamont> slangasek: good.  I didn't want to have to hurt StevenK
[03:46] <slangasek> StevenK: which arch?
[03:46] <StevenK> amd64
[03:46] <slangasek> StevenK: look for the bits built without -fPIC?
[03:47] <slangasek> or the system .a files being linked in
[03:47] <StevenK> slangasek: Last time I saw -fPIC problems, it told me. Here I'm just getting undefined references
[03:48] <slangasek> you said "Nonrepresentable section on output", that's not an undefined reference
[03:48] <StevenK> I see both; http://paste.ubuntu.com/2339/
[03:49] <slangasek> oh, then, find where those functions are defined :)
[03:49]  * slangasek <-- help with debugging
[03:49]  * StevenK digs up the patch asac gave him for tinymail
[03:50] <StevenK> Maybe applying that to modest will help
[03:50] <slangasek> modest mussorgsky?
[03:50]  * lamont finally dist-upgrades his home hppa box from gutsy-stage0 to gutsy
[03:51] <StevenK> slangasek: There's a e-mail client called 'modest'
[03:52] <slangasek> StevenK: named after mussorgsky?
[03:52] <StevenK> Named because it's designed for modest hardware
[03:52] <StevenK> slangasek: How can I determine which library defines those symbols?
[03:53] <slangasek> StevenK: with nm -D /usr/lib/library-I-suspect.so?
[03:54] <StevenK> I wonder what nm is supposed to expand to.
[03:54] <StevenK> (Like ls being list)
[03:54] <minghua> name?
[03:55] <StevenK> That seems too obvious. :-)
[03:56] <slangasek> Number Muncher
[03:56] <StevenK> jdong: That tea has seemed to help, so nyah
[03:57] <slangasek> lamont: tada, d-i fixed.  I suppose you want a full-fledged merge request rather than me just dumping files somewhere? :)
[03:57] <lamont> slangasek: for you?  signed source.changes and files
[03:58] <StevenK> Which you'll have to resign
[03:58] <lamont> duh
[03:58] <StevenK> Heh, sorry
[03:59] <lamont> StevenK: I just want trackability...
[03:59] <StevenK> slangasek: Okay, I have the library that contains those symbols
[04:00] <lamont> StevenK: and it'll have some fixup that's not PIC, and you're building a PIC binary
[04:00] <lamont> apply sledge-hammer love to the library
[04:00] <StevenK> The library in question is /usr/lib/xulrunner-1.9b1/libxul.so, it has it's own sledge-hammers
[04:00] <slangasek> heh
[04:02] <lamont> StevenK: slangasek signing the changes lets me go 'he should know better' when cjwatson slaps me upside the head for uploading some silliness of slangasek's. :)
[04:02] <lamont> slangasek: unless you think I should review your changes....
[04:03] <StevenK> I'm just waiting for slangasek to upload a d-i to Ubuntu that installs Debian
[04:03]  * StevenK hides
[04:04] <StevenK> slangasek: The final gcc command run contains -I<includedir>, but does not add -lxul or /usr/lib/xulrunner-1.9b1/libxul.so to the command line
[04:05] <lamont> is it guilty of using gcc to link g++ binaries?
[04:06] <StevenK> I don't think so
[04:06] <lamont> I wonder if the hppa box will boot without me typing ctl-D this time
[04:07] <Fujitsu> lamont: It won't.
[04:07] <slangasek> lamont: http://people.ubuntu.com/~vorlon/newt_0.52.2-11.1ubuntu1_source.changes
[04:08] <lamont> fsck.ext3: Unable to resolve 'UUID=37b0a8ff-e4d7-40af-b7e7-597001b30bf6'
[04:08] <lamont> fsck died with exit status 8
[04:08] <lamont>    ...fail!
[04:08] <lamont>  * File system check failed.
[04:08] <lamont> and now I have the error message.
[04:12]  * StevenK sprinkles some magic inside configure.ac and tries a rebuild
[04:13] <slangasek> lamont: do I still have your attention, or are you lost to the wonders of libuuid and udev? :)
[04:13] <lamont> still fetching
[04:13] <lamont> do I need to test this?
[04:13] <slangasek> no
[04:14] <lamont> so, once it gets published and queue-mangler gets done, then the buildd will get to it.
[04:15] <lamont> I assume you can do the retry-a-thon on d-i once it's built/published?
[04:15] <lamont> otherwise, whack me.
[04:15] <slangasek> TTBOMK I'll need to whack you
[04:15] <slangasek> unless there's a dep-wait capability in soyuz
[04:15] <lamont>  checkgrp
[04:15] <lamont> admin: 109 106
[04:15] <lamont> crontab: 106 107
[04:15] <lamont> lpadmin: 108 104
[04:15] <lamont> scanner: 104 105
[04:15] <lamont> ssh: 107 108
[04:15] <lamont> root@j6700:~#
[04:15] <lamont> I hate it when ldap and /etc/group disagree
[04:16] <StevenK> slangasek: Soyuz does automatic depwait stuff
[04:16] <slangasek> StevenK: automatic dep-wait isn't useful for this case
[04:17] <slangasek> this is a "we know why it failed to build, we know which version fixes it, admin wants to set a manuall dep-wait on the fixed version"
[04:17] <lamont> slangasek: not that I've seen
[04:18] <lamont> I mean, one could do sql-foo if one had access, but that's not exactly "in launchpad"
[04:18] <slangasek> :)
[04:18] <StevenK> Sigh, my magic had no effect
[04:21] <lamont> -rwxr-sr-x 1 root crontab 78472 2007-10-04 22:26 /usr/bin/ssh-agent
[04:21] <lamont> see, because that's just wrong
[04:23] <lamont> slangasek: you're right.  I'll need to whack it
[04:23] <lamont> remind me when, eh?
[04:24] <slangasek> lamont: yep, I'm polling vigorously :-)
[04:24] <lamont> queue-builder is a 30 min runtime, and then it sleeps 1800 before it runs again
[04:25] <lamont> so start polling at 20:44 PST, and you might get results
[04:25] <lamont> slangasek: how come your key doesn't have your ubuntu.com addr on it?
[04:26] <lamont> because /me didn't do --recv-keys recently
[04:26] <lamont> doh
[04:27]  * slangasek grins
[04:27] <slangasek> better question, why does dpkg-buildpackage not acknowledge that it has my ubuntu.com addr on it :P
[04:30] <StevenK> Sigh. Nothing I do has any affect.
[04:31] <RAOF> StevenK: Move the package out of the globe of invulnerability; your magic will be more effective
[04:34] <lamont> Disabling interface: eth0 ... done.
[04:34] <lamont>  * Reloading system message bus config...                                [ OK ]
[04:34] <lamont>  * Restarting network connection manager NetworkManager
[04:34] <lamont> neato.
[04:34] <lamont> somehow that do-release-upgrade run over ssh kinda hurt
[04:38] <lamont> must. kill. network-mangler.
[04:39] <ScottK> This is news?
[04:39] <lamont> I keep forgetting that it keeps sneaking back onto the machine and requires another application of the sledgehammer.
[04:40]  * lamont will file a bug against update-manager to die horribly (or DTRT) if networkmangler is going to trash an sshed do-release-upgrade
[04:41] <lamont> on the bright side, it appears that the update-manager run finished.
[04:41] <ScottK> I've always had good luck with apt doing upgrades (even though I know it's 'wrong')
[04:42] <lamont> it's the whole remembering to remove the crap that shouldn't be there any more that got me to switch to playing mvo's game
[04:43] <ScottK> Still needed even with autoremove in apt?
[04:44] <lamont> dunno
[04:46] <mdomsch> sudoers Defaults !env_reset is a good idea when running pdebuild and using sudo...
[04:46] <mdomsch> that was annoying to find...
[04:49]  * calc uses dselect for package management :)
[04:50] <Amaranth> calc: 1995 called, they want their package manager back
[04:51] <StevenK> Hah
[04:52] <calc> does aptitude sort decently yet, last time i tried it was a bit pita to change sort order
[04:52] <calc> and i like to know what new packages are available each time i update
[04:52] <calc> which is extremely easy to do with dselect
[04:52] <calc> hit 'o' a few times and it pops them up
[04:53] <calc> besides the fact it is very easy to fix conflicts, etc in dselect by placing things on hold or back out if the archive is too screwed up
[04:54] <calc> i'm sure using something like update-manager/aptitude/etc is great if you only run stable releases that don't change hourly
[04:55] <calc> eg the last time i used aptitude you had to remember a bunch of arcane characters to change the format of the sort order, it didn't have an option to cycle through common ones
[04:55] <Amaranth> synaptic shows new packages
[04:55] <Amaranth> and lets you hold things and such
[04:55] <calc> so it had a more powerful sort mechanism at the expense of being easy to do
[04:55] <calc> Amaranth: ah synaptic may be a good replacement for dselect (for me) then
[04:56] <calc> of course i am also an old fart that has been using dselect over 9 years now so why change... ;-)
[04:57] <Amaranth> by the time i learned what dselect was i'd already been using synaptic for a year :P
[04:58] <StevenK> I used dselect once when I installed hamm
[05:15] <lamont> newt building as of a minute ago
[05:15]  * slangasek nods
[05:20] <slangasek> I'm going to forego putting publisher on auto though, I'm too tired to properly attend it
[05:20] <lamont> heh
[05:20] <lamont> so we did freeze for the CD burn?
[05:22] <slangasek> no
[05:22] <jdong> aren't we not freezing but playing broken package roulette? :)
[05:22] <slangasek> lamont: see, I'm so tired I said "auto" instead of "manual"
[05:22] <slangasek> \o/
[05:33]  * lamont builds bind9 9.4.2-1 for debian
[05:34] <lamont>  hardy amd64   Successfully built  (ACCEPTED)
[05:35]  * lamont twiddles thumbs
[05:35] <lamont> Uploaded By:  Steve Langasek
[05:35] <lamont> launchpad for the win
[05:36] <lamont> dear launchpad, is there any way to identify the signer of the source.changes file?
[05:36] <lamont> ECHAN
[05:36] <jdong> lamont: that'd be nice to have
[05:36] <StevenK> lamont: Grab the _source.changes file from the librarian and run who-uploads on it
[05:37] <lamont> StevenK: feh. boring
[05:37] <StevenK> lamont: It shouldn't misrepresent Changed-By like that, though
[05:37] <lamont> wow.  sig survived a cut/paste from the web site
[05:37] <lamont> but how else can we blame slangasek ?
[05:38] <StevenK> Changed By: Steve Langasek ; Uploaded By: LaMont Jones
[05:38] <StevenK> ?
[05:39] <lamont> it should say that, yes.
[05:39] <slangasek> perhaps it misrepresents changed-by because he signed the .changes I sent him instead of re-rolling it?
[05:39] <lamont> Uploaded By: Steve Langasek; Sponsored By: LaMont Jones
[05:39]  * StevenK sighs at his rsync skills not sticking around, but disappearing into the ether five minutes after he uses them
[05:39] <Fujitsu> Changed-By is meant to be the person in the changelog.
[05:39] <lamont> slangasek: I _SAID_ I was trusting you... :-)
[05:39] <Fujitsu> Not the sponsor.
[05:40] <StevenK> Fujitsu: slangasek did the work, lamont uploaded it. My line is correct
[05:40] <slangasek> lamont: well I hope you didn't expect me to build the changes file using your name :)
[05:40] <Fujitsu> StevenK: Right. What is the Changed-By it gave?
[05:40] <StevenK> I daresay, slangasek
[05:40] <StevenK> But I've not looked
[05:41] <slangasek> Fujitsu: https://launchpad.net/ubuntu/hardy/+source/newt/0.52.2-11.1ubuntu1 currently shows an Uploaded By: me, which is not entirely accurate
[05:41] <Fujitsu> Changed-By -> Uploaded By in LP speak.
[05:42] <lamont> slangasek: it's your upload... I just sponsored it... :-)
[05:42] <slangasek> fair enough
[05:43] <lamont> slangasek: I gave back d-i on the theory that it shouldn't noticibly hurt if I did it a few minutes early
[05:44] <slangasek> is it going to noticeably help, though?  I don't know what the timings look like for publishing
[05:45] <cjwatson> the publisher is running cron.germinate now, so the archive itself should be in place
[05:46] <cjwatson> oh, except for mirrors, hmm
[05:46] <cjwatson> but buildds fetch directly off ftpmaster.internal (i.e. drescher)
[05:46] <lamont> cjwatson: what mirrors.
[05:46] <lamont> :-)
[05:46] <cjwatson> so I think it should work
[05:46] <cjwatson> right :)
[05:46] <lamont> as long as Packages is right
[05:47] <slangasek> so, the fact that newt is still listed in 'accepted'...?
[05:47] <cjwatson> slangasek: means it needs another publisher run
[05:48] <cjwatson> libnewt-pic | 0.52.2-10ubuntu2 |         hardy | amd64, hppa, i386, ia64, lpia, powerpc, sparc
[05:48] <cjwatson> saith madison on drescher
[05:48] <lamont> and d-i rescored to 10000
[05:48] <cjwatson> lamont: try again in an hour
[05:48] <StevenK> Heh is it really called madison?
[05:48] <lamont> of course it is
[05:48] <StevenK> Hah, way cool
[05:49] <lamont> she's been doing that job for a number of years
[05:49] <cjwatson> well. it's madison-lite
[05:49] <lamont> post fen-fen then
[05:49] <slangasek> cjwatson: as opposed to daring to put things on manual at this point and shove it through?
[05:49] <cjwatson> I just have it aliased to 'm' so I forget what it's really called
[05:49] <cjwatson> slangasek: works for me if you're sufficiently awake
[05:49] <StevenK> cjwatson: Ah, and it just points directly at the Packages files that the publisher generates
[05:50] <cjwatson> StevenK: right
[05:50] <slangasek> if we're looking at a full hour cycle more, I can probably be that awake
[05:50] <cjwatson> there's a sort of madison-a-like in the LP web output now mind you
[05:50] <StevenK> slangasek: As in, the coffee pot is just boiling?
[05:50] <cjwatson> slangasek: depends how much we think that the result is going to work
[05:50]  * StevenK waits for hildon-input-method, so he can do the next part of the dance.
[05:51] <cjwatson> probably a good time for me to sponsor evand's base-installer merge ...
[05:51] <StevenK> Ugh. I had no idea it was that early in London.
[05:51] <slangasek> cjwatson: well, getting it in at least lets us do livecds
[05:51] <slangasek> and should give us alternate CDs to inspect
[05:52] <cjwatson> to an extent, yeah. ubiquity will probably have to be uploaded before you can install live CDs
[05:52] <slangasek> and I'm planning to get to that point before falling off the network for the night
[05:52] <slangasek> oh, erm, ok
[05:52] <cjwatson> but being able to run them would be a mighty good start
[05:53] <slangasek> so what you're saying is that I failed to release-manage my manager in a timely manner... :)
[05:53] <cjwatson> ubiquity -> evand
[05:53] <cjwatson> :-)
[05:53] <slangasek> ok :)
[05:55]  * StevenK tries to remember the flags to get rsync to tell him just the files it's transferring
[05:56] <lamont> cjwatson: does it make sense to add slangasek to launchpad-buildd?
[05:56] <lamont> that would at least let him rescore things
[05:59] <lamont> although that requires tech board or infinity
[05:59] <lamont> or a duck
[06:00] <lamont> StevenK: -avk
[06:00] <lamont> er, -avn
[06:00] <lamont> fat fingers
[06:00] <lamont> cjwatson: network challenges?
[06:01]  * lamont throws bind9 9.4.2-1 at sid
[06:01] <cjwatson> lamont: bloody router
[06:01] <StevenK> lamont: -n doesn't transfer though
[06:01] <lamont> quit bleeding on it then.
[06:01] <StevenK> Muahaha
[06:02] <lamont> -n says just say what you're gonna do
[06:02] <StevenK> Which spits out every file
[06:02] <StevenK> Not all of them have changed
[06:02] <lamont> cjwatson: since you went away... does it make sense to add slangasek to launchpad-buildd, so he can rescore things? (which would require tech-board, infinity, or a duck.)
[06:02] <lamont> StevenK: no. it spits  out every file it would change
[06:03] <cjwatson> fine by me
[06:03] <lamont> either by changing contents, or by changing times
[06:03] <cjwatson> pitti is in launchpad-buildd-admins for basically the same reason
[06:03] <lamont> yeah - that group
[06:03] <lamont> I'll let you use your daylight hours to get TB/infinity/duck to do that for him then
[06:04] <lamont> StevenK: maybe you want -I in there to, so it'll ignore timestamp[s
[06:05] <StevenK> lamont: Mmm. I just wish I could remember rsync's runes
[06:05] <lamont> like, say, that guy. :0)
[06:05] <lamont> StevenK: there aren't _THAT_ many...
[06:06] <lamont> and for everything else, there's "man rsync" :-P
[06:06] <StevenK> lamont: I know. I don't use it often enough.
[06:06] <lamont> don't ask me to expand -a :-)
[06:07] <lamont> cjwatson: and if someone wants to make me an admin, I can be very good about saying 'no' :)
[06:07] <slangasek> ah, evidently no need to publish on manual
[06:07]  * lamont wants to never ever ever have a duck
[06:07] <slangasek> since accepted seems to have been emptied for me in the meantime
[06:08] <slangasek> -a should expand to -dpr, or thereabouts
[06:08] <lamont> and more
[06:08] <StevenK> -rlptgoD
[06:08] <slangasek> à la cp -a
[06:08] <lamont> -a expands to "what I want, for starters"
[06:08] <slangasek> right
[06:08] <slangasek> -a is "yes, I'm using Unix already"
[06:09] <StevenK> -a isn't what I want in this case, though, since I want to ignore symlinks.
[06:09] <lamont> yeah
[06:09] <lamont> piffle.  clearly you're not using Un*x
[06:09] <StevenK> Clearly, I don't want to copy the build logs to rookery.
[06:10] <lamont> slangasek: so d-i didn't ftbfs on ia64
[06:10] <lamont> yet.
[06:10] <StevenK> Look at that optimism
[06:11] <lamont> when do we figure we want to give things back again?
[06:11] <lamont> StevenK: korofice and monotone are keeping ithe ia64 buildds busy still
[06:11] <StevenK> They're just the distractions.
[06:12] <lamont> yeah, but people'd get upset if I cancelled the builds... :-)
[06:12] <StevenK> Like anyone uses KDE on ia64
[06:12] <StevenK> s/KDE on //
[06:12] <StevenK> :-P
[06:12] <lamont> I'm pretty sure dannf uses gnome.
[06:13] <lamont> StevenK: I'm the one who copies build logs to rookery... :-)(
[06:13] <StevenK> Not stuff I'm building locally, you don't. :-P
[06:13] <lamont> http://p.u.c/~lamont/buildLogs/Test being the gutsy autotest of main
[06:13] <cjwatson> I suspect these days most people fetch build logs out of LP
[06:13] <lamont> cjwatson: and we only copied the failures to rookery
[06:14]  * cjwatson goes back to try to sleep again
[06:14] <lamont> but it's already 6AM...
[06:15] <slangasek> lamont: we don't have the fixed newt in the Packages file yet, I'd think we should wait for that before bothering
[06:15] <frostburn> where can i find more information on how xchat was built in 7.10?
[06:15] <lamont> slangasek: yeah
[06:15] <lamont> you're looking at drescher?
[06:16] <lamont> frostburn: https://launchpad.net/distros/ubuntu/+source/xchat2
[06:16] <lamont> feh
[06:16] <lamont> frostburn: https://launchpad.net/distros/ubuntu/+source/xchat
[06:16] <frostburn> lol
[06:16] <StevenK>  /distros is old
[06:16] <slangasek> lamont: drescher, yes
[06:16] <lamont> frostburn: which eventually gets you to http://launchpadlibrarian.net/9601818/buildlog_ubuntu-gutsy-i386.xchat_2.8.4-0ubuntu5_FULLYBUILT.txt.gz
[06:17] <lamont> slangasek: then I won't go fetch it from another DC machine to look myself.
[06:17] <lamont> StevenK: the link still works, and therefore my shortcut... so I haven't fixed it
[06:17] <lamont> StevenK: so I can drop the /distros?
[06:17] <StevenK> lamont: Right
[06:18]  * lamont fixors
[06:18] <frostburn> lamont, ty
[06:19] <lamont> StevenK: mind you, the key for the shortcut is 'dap' :-)
[06:20] <lamont> and amd64 threatens to pass 98% on graph2
[06:23] <lamont> frostburn: alternatively, you can get pretty close to that with 'apt-get source xchat' on a gutsy system, and looking at debian/rules
[06:24] <lamont> assuming that xchat isn't one of the evil packages that believes that debian/rules should be a twisty little maze of makefiles, all different
[06:24] <StevenK> # automatically generated by dh_gtkmodules, do not edit
[06:24] <StevenK> Cannot load module /build/steven/hildon-input-method-framework-1.99.23/debian/hildon-input-method-framework/usr/lib/gtk-2.0/2.10.0/immodules/hildon-im-module.so: libhildon_im_common.so.3: cannot open shared object file: No such file or directory
[06:24] <StevenK> Thank you dh_gtkmodules, you win.
[06:24] <frostburn> lamont, i'm just trying to figure out if aspell is statically compiled, it looks like it is
[06:25] <lamont> ah, ok
[06:25] <lamont> StevenK: WIN!
[06:25] <StevenK> But, how do I fix that. Grumble
[06:26] <slangasek> StevenK: where is libhildon_im_common.so.3?
[06:26] <StevenK> slangasek: /usr/lib/
[06:27]  * lamont was gonna vote "disk"
[06:27] <lamont> yep.  definitely late.
[06:27] <slangasek> StevenK: I... don't believe you?
[06:27] <slangasek> StevenK: or is the problem that the error message is being output to some file at build-time?
[06:28] <StevenK> slangasek: Right.
[06:28] <slangasek> ok
[06:28] <slangasek> then are the two bits in the same package?
[06:28] <StevenK> The dh_ prefix should have given that away. :-)
[06:28] <lamont> StevenK: iz gtk bug
[06:28] <lamont> (that was a joke)
[06:28] <slangasek> StevenK: just wasn't clear on the context
[06:28] <StevenK> slangasek: Ah. And yes, they are.
[06:29] <StevenK> lamont: I figured. :-)
[06:29] <lamont> I was just worried you might have believed me, is al;l.
[06:29] <slangasek> StevenK: try setting LD_LIBRARY_PATH=./debian/$pkg/usr/lib when calling dh_gtkmodules
[06:29] <StevenK> slangasek: I was thinking that.
[06:29] <minghua> StevenK: Heh.
[06:30] <lamont> and remember to make that LD_LIBRARY_PATH=./debian/$pkg/usr/lib:$LD_LIBRARY_PATH
[06:30] <lamont> at least if there might be anything that needs fakeroot to work
[06:30] <StevenK> lamont: Surely $$ ?
[06:30] <slangasek> yes
[06:30] <StevenK> This is in make, after all
[06:31] <minghua> StevenK: Debian bug 427654.
[06:31] <ubotu> Debian bug 427654 in libgtk2.0-dev "dh_gtkmodules outputs garbage to immodule list files" [Important,Fixed] http://bugs.debian.org/427654
[06:31] <StevenK> Yay!
[06:31] <lamont> LD_LIBRARY_PATH=$$(pwd)/lib/isc/.libs:$$(pwd)/lib/isccc/.libs:$$(pwd)/isccfg/.libs:$${LD_LIBRARY_PATH} $(MAKE)
[06:31] <lamont> that's from bind9's debian/rules
[06:32] <StevenK> dh_strip --dbg-package=hildon-input-method-framework
[06:32] <StevenK> Oh, sigh.
[06:33]  * StevenK rebuilds hildon-input-method-framework again.
[06:33]  * StevenK plots evilness against lool.
[06:34]  * lamont yawns
[06:35]  * realist seconds that motion
[06:38] <slangasek> lamont: give-back please
[06:40] <StevenK> Way cool. I've been an ubuntu member for nearly two years
[06:41] <lamont> no d-i on lpia?
[06:41] <StevenK> Mobile doesn't use it, currently.
[06:41] <StevenK> That may change.
[06:41] <lamont> ok
[06:41]  * lamont does math..
[06:41] <lamont> 2007.11-2004.03 == 3 2/3 years.  kewl
[06:42] <StevenK> chown: changing ownership of `debian/hildon-input-method-framework/usr/lib/gtk-2.0/2.10.0/immodule-files.d/hildon-input-method-framework.immodules': Operation not permitted
[06:42] <StevenK> Sigh
[06:42] <lamont> see - you didn't keep fakeroot around
[06:42] <lamont> :-)
[06:42] <StevenK> I did, though.
[06:42] <StevenK> LD_LIBRARY_PATH=./debian/hildon-input-method-framework/usr/lib:${LD_LIBRARY_PAT} dh_gtkmodules
[06:42] <StevenK> OH, BLAH
[06:42] <StevenK> Excuse me.
[06:42]  * StevenK gets a brown paper bag.
[06:43] <slangasek> LD_LIBRARY_PAT_ROBERTSON
[06:43] <lamont> don't you mean 'O, BLA'?
[06:43] <StevenK> lamont: Shush
[06:43]  * StevenK wipes the egg off his face
[06:44] <lamont> IRC is really fun when you're so tired you're punch-drunk
[06:44] <StevenK> Haha
[06:48] <dholbach> good morning
[06:48]  * lamont decides to put in a little kobodeluxe time, in case slangasek needs anything else
[06:50] <LaserJock> morning dholbach
[06:51] <dholbach> hi LaserJock
[06:59] <StevenK> Way cool. I think I crashed NetworkManager on my Q1
[06:59] <StevenK> Ah. Just the applet.
[07:00] <pitti> Good morning
[07:01] <StevenK> Morning pitti
[07:03] <slangasek> lamont: successfully built, go to bed :)
[07:03] <lamont> sir. yes sir.
[07:03] <lamont> and g'night
[07:03] <slangasek> night, thanks for the help
[07:05] <pitti> hey slangasek
[07:05] <slangasek> pitti: hi
[07:05] <pitti> hardy_probs.html looks promising :)
[07:06] <pitti> so if the universe font dependency of tuxmath is solved, everything should be good enough, right?
[07:13] <slangasek> pitti: looks like it to me
[07:32] <slangasek> ah, there we are, d-i published and just in time for the ubuntu cd cron.daily
[07:34] <tjaalton> nice
[08:10] <pitti> doko_: wrt. db4.4, do you care about keeping libdb4.4-java-gcj? Nothing uses it
[08:11] <pitti> doko_: we need to drop lamont's NTPL enabling (bug #153996), and if we drop libdb4.4-java-gcj we can just sync it again
[08:11] <ubotu> Launchpad bug 153996 in db4.4 "libdb4.4 in gutsy breaks postgrey and subversion" [Unknown,Fix released] https://launchpad.net/bugs/153996
[08:25] <MacSlow> Greetings everybody!
[08:26] <\sh> MacSlow, moins...btw..which app do you use for your screencasts? :)
[08:28] <MacSlow> xvidcap
[08:52] <doko_> pitti: no, as long as we have libdb4.6-java-gcj
[08:52] <pitti> doko_: that's what I thought; thanks for confirming
[09:03] <DktrKranz> pitti: hi. I saw your comment in bug 103481. Is there anything I can do?
[09:03] <ubotu> Launchpad bug 103481 in strigi "[SRU] upgrade from edgy causes file overwrite error" [Medium,Fix committed] https://launchpad.net/bugs/103481
[09:03] <pitti> DktrKranz: if you think it's urgent, you could do a no-change upload (just bump the version) straight to -updates
[09:04] <DktrKranz> pitti: it affects edgy -> feisty upgrade, so it is not that urgent
[09:10] <\sh> DktrKranz, ping tikiwiki, I fixed at least gutsy and feisty...and it should be removed from the archive for hardy, as it is in debian
[09:14] <DktrKranz> \sh \o/
[09:26] <popey> \o/ xvidcap
[09:26] <soren> Will the LiveCDPersistence stuff work if I put the loopback file on a USB device?
[10:04] <tkamppeter> pitti, hi
[10:04] <pitti> hey tkamppeter
[10:14] <lool> pitti: If you have a couple of minutes, and since you might be more interested in it than anybody else, do you think you could sync avahi from Debian unstable if you think it's suitable in Ubuntu?
[10:14] <pitti> lool: sure, if you merged the interesting changes to Debian and there's nothing left we need to keep?
[10:14] <lool> pitti: It should have all changes we care about; one that has been dropped is the ".local check on ifup only" which was a mistake, but apart of that it should be fine
[10:15] <pitti> right, I saw the commits to the debian svn
[10:15] <lool> i wanted to wait a couple of days in the archive, but it seems fine (no bug report received)
[10:15] <pitti> lool: the SetHostName issue is negligible for the moment; indeed at_console would be better
[10:16] <pitti> but ATM nothing uses it (nm-applet is supposed to support it, but doesn't)
[10:16] <pitti> and eventually I'd like to see a proper CK integration into dbus to support at_console upstream
[10:17] <lool> Fine with me; I guess you'll bring this up with upstream directly
[10:17] <pitti> yes, already in the works (I talked to Lennart yesterday)
[10:17] <Keybuk> pitti: !
[10:18]  * pitti takes a jump backwards; what did I screw up?
[10:18] <Keybuk> pitti: "nma_dbus_init(): could not acquire its service.  dbus_bus_acquire_service() says: 'Connection "1:31" is not allowed to own the service "org.freedesktop.NetworkManagerInfo" due to security policies in the configuration file"
[10:19] <pitti> ???
[10:19] <pitti> on current hardy for you? weird, WFM
[10:20] <Keybuk> yeah
[10:20]  * pitti upgrades his laptop to the latest crack, but there haven't been changes in the last few days
[10:20] <Keybuk> updated just now
[10:20] <pitti> and nm on my desktop works well, too (just ethernet, though)
[10:20] <Keybuk> hmm
[10:20] <pitti> Keybuk: when did you update last, yesterday?
[10:21] <Keybuk> nm-applet.conf still has at_console=true
[10:21] <Keybuk> last updated about 10 mins ago
[10:21] <pitti> oh, wait
[10:21] <pitti> Keybuk: does ck-list-sessions output something?
[10:21] <pitti> occasionally gdm doesn't register my session with CK
[10:21] <pitti> so that few things work
[10:21] <pitti> lool: synced
[10:22] <Keybuk> pitti: is there an easy way to tell?
[10:22] <Keybuk> ck-list-sessions has me in it
[10:22] <pitti> Keybuk: if ck-list-sessions doesn't have your session (e. g. it's empty), that's that bug
[10:22] <pitti> hm
[10:22] <pitti> ok, let me dist-upgrade
[10:23] <pitti> "404 Impossibile trovare l'oggetto"
[10:23] <pitti> ???
[10:24] <pitti> seb128, did you 0wn apt-get update now and translated everythihng to french?
[10:24] <lool> pitti: Cool, thanks
[10:25] <pitti> cjwatson: current hardy alternate install fails with a debootstrap error
[10:26] <cjwatson> details?
[10:26] <cjwatson> does it have current base-installer?
[10:26] <slangasek> pitti: that's Italian... :)
[10:26] <cjwatson> oh, I bet bootstrap-base is missing
[10:27] <cjwatson> pitti: do carry on though in case my snap diagnosis is incomplete
[10:27] <pitti> http://people.ubuntu.com/~pitti/tmp/d-i-debootstrap-syslog.png
[10:27] <pitti> cjwatson: sorry, nc doesn't seem to work for me today, and I forgot that anna-install package which gives me ssh
[10:27] <cjwatson> yeah, missing bootstrap-base, I'll seed it
[10:28] <cjwatson> anna-install openssh-client-udeb
[10:28] <pitti> ah, -udeb
[10:28] <pitti> thanks
[10:28] <seb128> pitti: that's not french, somebody probably screwed the takeover change  ;-p
[10:30] <cjwatson> pitti: seed fix committed, try rebuilding
[10:30] <pitti> thanks, doing
[10:35] <pitti> cjwatson: ok, I merge that to Ubuntu & friends
[10:35] <pitti> (or isn't that necessary?)
[10:38] <cjwatson> pitti: it will be necessary; but also, could you NEW bootstrap-base?
[10:38] <pitti> whoops, sure; I'll defer the CD rebuilds then until after the next publisher
[10:38] <cjwatson> yeah
[10:39] <cjwatson> sorry, forgot we needed that; but we did need the new base-installer because a piece moved from debootstrap to base-installer
[10:39] <cjwatson> and we already had the new debootstrap
[10:40] <pitti> newed, checking for other stuff in NEW
[10:40] <pitti> should be fine
[10:43] <pitti> Keybuk: hm, nm is happy after dist-upgrade and reboot, and I don't have any error like that in .xsession-errors
[10:44] <pitti> Keybuk: oh, that's from the daemon, not the applet, right?
[10:44] <Keybuk> pitti: from the applet
[10:45] <pitti> if you start it from teh command line? or where do you see that?
[10:45] <pitti> cjwatson: all seeds merged
[10:47] <Keybuk> pitti: 5th reboot now, still failing
[10:47] <pitti> Keybuk: ah, do you have libpam-foreground uninstalled?
[10:47] <cjwatson> pitti: ta
[10:47] <Keybuk> pitti: Status: purge ok not-installed
[10:47] <pitti> I still had that, uninstalled, rebooting now
[10:50] <pitti> Keybuk: yep, confirmed, thanks
[10:50]  * pitti fixes
[10:51] <pitti> Keybuk: I'll add libpam-foreground as a dbus dependency for now until at_console works with CK
[10:51] <pitti> that should do for alpha 1
[10:54] <Keybuk> is at_console expected to work with CK?
[10:55] <pitti> not right now, but eventually I hope so
[10:55] <pitti> I talked to Lennart about this yesterday, and discussion is ongoing with David
[10:56] <Keybuk> hmm
[10:56] <Keybuk> so the reason it's using that is to decide whether it can take the bus name?
[10:56] <Keybuk> that seems like a long-term wrong design
[10:56] <Keybuk> isn't nm-applet always supposed to work
[10:56] <Keybuk> and network manager to use PK to decide whether to accept requests from it or not?
[10:57] <Keybuk> (so if I'm not the user on the console first seat, I can still see the wireless status, but if I try and change it I get an error)
[11:00] <lool> asac: I think firefox slightly regressed on dual screen for me: it used to open on whatever screen my mouse pointer was in, but it seems it's now always opening on the left screen
[11:00] <pitti> Keybuk: I guess it is to avoid that a remote X11 session can start nm-applet and control the local daemon with it?
[11:00] <lool> asac: Could that be a regression in gnome-support stuff?
[11:01] <pitti> Keybuk: anyway, I think unbreaking at_console is safer for alpha 1 at this point, so I uploaded that workaround
[11:01] <pitti> Keybuk: changing the dbus access policies should be discussed anyway, of course
[11:02] <pitti> meh, our alternates exploded again
[11:02] <pitti> we removed a lot of gnome help duplicates, upstream changelogs, etc., and still they grew by about 15 MB instead of shrinking
[11:03] <asac> lool: hmm
[11:03] <asac> lool: what kind of dual setup?
[11:04] <asac> lool: can you please verify that its really a regression of firefox (e.g. downgrade to 2.0.0.8) ?
[11:04] <lool> asac: I think a xrandr or intel one, don't know how that's called: I use the intel driver and set a virtualsize and describe my monitor layouts
[11:05] <lool> asac: I'll try to downgrade to the gutsy version (.6) unless there's an easy way to downgrade which I don't know about
[11:08] <asac> lool: you can download the version from launchpad
[11:08] <lool> asac: Same behaviro from gutsy version; must be some GNOME or xorg change then :-(
[11:08] <asac> yeah ... that makes sense :)
[11:09] <asac> do you have DISPLAY=:0.1 and DISPLAY=:0.2 in your setup?
[11:09] <lool> asac: No
[11:09] <asac> ok
[11:10] <StevenK> pitti: Can any particular package be blamed?
[11:28] <seb128> Mithrandir, StevenK: bluez-utils screws gstreamer at the moment, like totem hang on video playing, etc
[11:28] <StevenK> seb128: But ... how?
[11:28] <seb128> how what?
[11:28] <seb128> slomo: ^
[11:28] <StevenK> I'm curious how it does?
[11:28] <slomo> StevenK: it ships a2dpsink and that is broken :P
[11:28] <seb128> it sinks is overanked and broken
[11:28] <StevenK> Ahh, right
[11:28] <slomo> it a) has primary rank, thus is tried as one of the first sinks by autoaudiosink
[11:29] <StevenK> Can I fix it tomorrow, please?
[11:29] <slomo> and b) it doesn't fail gracefully
[11:29] <seb128> StevenK: which means alpha1 with have audio and video playing broken
[11:29] <slomo> like all other sinks do... so people who have it can't play anything it seems
[11:29] <seb128> s/with/will
[11:29] <StevenK> seb128: My muscles have been aching for like ten hours and it's 10:30pm. I'd really really rather sleep.
[11:30] <seb128> StevenK: ok, go to sleep that's alright, that's only alpha1 and I'm sure we will manage to fix it anyway
[11:30] <seb128> StevenK: have a good night
[11:30] <StevenK> seb128: I'm just waiting for a build to fail
[11:30] <StevenK> It's getting harder and harder to wait, though
[11:30] <slomo> seb128: just don't ship that gstreamer plugin then ;)
[11:31] <loskobosko> hi, anyone reading?
[11:31] <seb128> slomo: we could do that
[11:31] <StevenK> seb128: I've added looking at it to the top of my todo list
[11:32] <seb128> StevenK: I'll have a go at fixing it now, don't worry
[11:33] <slomo> StevenK: if you're bored you could forward that upstream though ;)
[11:33] <StevenK> seb128: Right. I'll have a poke and see if it's been uploaded tomorrow
[11:33] <seb128> StevenK: thanks
[11:35] <loskobosko> hi everyone, i know i'm pretty new here, but i would like to start a tiny project for ubuntu-linux.. or only give the idea, too :)
[11:37] <loskobosko> can anyone read me? feel like i am writing on dev>null
[11:37] <loskobosko> \/dev/null, pardon
[11:38] <persia> loskobosko: Your text is transmitting, but you've perhaps not hit the right place.  What are you trying to do?
[11:38] <loskobosko> yuppy!
[11:41] <loskobosko> do anyone know where i can find the source of installation wizard used in the live-cd?
[11:47] <pochu> pitti: apport added a retraced stacktrace to bug 172769 and then removed it with all the other files (coredump, registers...). Is that because it found it's a duplicate, or is this a bug in apport?
[11:47] <ubotu> Launchpad bug 172769 in tracker "trackerd crashed with SIGSEGV (dup-of: 155424)" [Medium,New] https://launchpad.net/bugs/172769
[11:47] <ubotu> Launchpad bug 155424 in tracker "trackerd crashed with SIGSEGV" [Medium,Fix committed] https://launchpad.net/bugs/155424
[11:50] <cjwatson> loskobosko: http://wiki.ubuntu.com/InstallerDevelopment
[11:55] <pitti> StevenK: no idea, haven't investigated yet
[11:56] <pitti> pochu: yes, because it's a dup and thus the same stacktrace
[11:56]  * Hobbsee waves
[11:57] <pochu> pitti: Ok, thank you. that's a new feature, isn't it?
[11:57] <pitti> pochu: hm, not that new, we got it early in gutsy
[11:58] <pochu> It's the first time I see apport removing all the attachments, including the retraces :-/
[11:58] <pitti> hm; I thought it has always done this since we started auto-dup'ing
[12:00] <persia> Just to make sure, does it only remove all the extra attachments when they are present for the dup?  I sometimes find a nice useful apport trace as a dup of a bug with only limited available information.
[12:00] <pitti> persia: it does not remove all attachments, only the apport specific ones (CoreDump.gz, stack traces, dependencies, etc.)
[12:01] <persia> pitti: Right.  I just wanted to make sure it only removed them when the master bug was an apport bug, as I've seen dupes where the master bug didn't have a stacktrace, or only a user-supplied stacktrace.
[12:01] <pochu> pitti: for the above bug I mentioned it has removed all the attachments, including those it just attached :-)
[12:02] <pochu> pitti: oh well, those are apport specific ones, sorry!
[12:03] <pitti> persia: well, that's not checked explicitly
[12:03] <persia> pitti: Could it be?
[12:03] <pitti> persia: but apport's dup database only has bugs which were filed by apport itself
[12:03] <persia> That works: I was afraid it was relying on the Malone dup markers.  Thanks for the clarification.
[12:04] <pitti> pochu: hm, if you think there's a bug or an undesirable behaviour there, please file a bug against apport
[12:04] <pitti> pochu: so far we just cleaned up the apport specific attachments to save space on LP, and they are usually completely redundant
[12:07] <pochu> pitti: as long as it's a duplicate, it's fine with me.
[12:07] <pochu> and from a user POV, it's really nice.
[12:07] <pitti> alright :)
[12:09] <pochu> pitti: although it might sense not to attach the retraced stacktrace if it's going to remove it. Better check it first :-)
[12:09] <pochu> Want me to file a bug about it?
[12:10] <pitti> pochu: right; please do, yes
[12:16] <pitti> hm, current live CD misdetects screen resolution in vmware
[12:16] <pitti> tjaalton, bryce: ^
[12:18] <pitti> no xorg.conf on the live system
[12:19] <tjaalton> pitti: what does it use?
[12:19] <tjaalton> pitti: +resolution
[12:19] <pitti> tjaalton: 800x600 (max resolution is 1024x768)
[12:19] <pitti> and displayconfig-gtk doesn't allow me to raise it either
[12:21] <pitti> 'not using built-in mode 1024x76, hsync out of range
[12:22] <tjaalton> more interesting would be that why there is no xorg.conf
[12:22] <tjaalton> I'll test the image myself
[12:22] <tjaalton> on real hw
[12:23] <pitti> yeah, me too, but for an initial smoke test vmware is good
[12:23] <pitti> tjaalton: if i force a h/v sync range manually, it doesn't help
[12:24] <pitti> might be a regression in the vmware driver
[12:26] <pitti> ah, it's because dpkg-reconfigure xserver-xorg refuses to create a /etc/x11/xorg.conf if none exists yet
[12:26] <tjaalton> pitti: sigh :)
[12:26] <tjaalton> well, more stuff to remove from the postinst then
[12:27] <tjaalton> or preinst
[12:27] <tjaalton> pitti: I'll take a look at it
[12:27] <pitti> tjaalton: thanks a lot
[12:27] <tjaalton> pitti: what's the deadline for an upload?
[12:28] <pitti> tjaalton: no particular one
[12:28] <pitti> if it works on real hw and is a vmware problem, it's no biggie at all
[12:28] <pitti> if it happens on real iron, it would be, though
[12:28] <tjaalton> sounds like it's broken logic
[12:29] <pitti> I just can't reboot my desktop right now, I have some stuff running
[12:29] <tjaalton> I have plenty of machines to test on :)
[12:29] <tjaalton> two laptops and desktops
[12:30] <tjaalton> but lunch first, bbl ->
[12:31]  * pitti tests it on his laptop
[12:32] <pitti> brb, restarting desktop session
[12:34] <pitti> hm, my background image is gone
[12:35] <ion_> Sorry, i borrowed it for a while.
[12:39] <pitti> seb128: hm, does nautilus-cd-burner work for you? I only see 'file image' in the dropdown
[12:41] <pitti> seb128: ah, nevermind, PEBCAK
[12:41]  * pitti still had ide-cd blacklisted for test reasons
[12:44] <Mithrandir> seb128: bluez-utils and gstreamer > do you have a bug report about it?
[12:58] <pitti> tjaalton: resolution is fine on my latitude (intel driver), so it seems more like a vmware driver regressiosn
[13:01] <tjaalton> pitti: do you have xorg.conf on the latitude?
[13:01] <lamont> ,e waves
[13:01]  * lamont , even
[13:01] <pitti> tjaalton: no, I don't
[13:01] <pitti> should I?
[13:01] <tjaalton> pitti: so that's a problem as well :)
[13:02] <pitti> well, maybe it should have my keyboard configuration, but gnome papers over it
[13:02] <pitti> or do you already use hal fdi input hotplugging?
[13:02] <tjaalton> nope
[13:11] <Amaranth> ahh apport got flipped back on
[13:19] <tjaalton> pitti: hmm, preinst should create the config
[13:19] <tjaalton> : > "$XORGCONFIG"
[13:19] <cjwatson> preinst? odd place to do it
[13:19] <tjaalton> well.. :)
[13:20] <tjaalton> it'll get cleaned up eventually
[13:20] <ogra> hmm
[13:20]  * ogra wonders why he doesnt get LTSP clients booting into shell
[13:22] <cjwatson> bryce: do you think you could send your xresprobe Intel workaround to Debian bug 430545?
[13:22] <ubotu> Debian bug 430545 in xresprobe "xresprobe breaks display at the middle of installation" [Normal,Open] http://bugs.debian.org/430545
[13:23] <cjwatson> I think it's the same deal
[13:24] <ogra> hmm, looks like an oddness with the framebuffer in virtualbox ... weird
[13:25] <pitti> new desktop images building
[13:29]  * ogra checks whats wrong with asound-plugins 
[13:29] <ogra> s/asound/alsa/
[13:49] <seb128> Mithrandir: not sure, but I asked lool to look at the bug
[13:52] <soren> Uh, isos!
[13:54] <pitti> ogra: edubuntu alternates are oversized
[13:54] <ogra> pitti, i see that, worse is that libasound2-plugins has some issues ...
[13:55] <ogra> hmm .... "Package libavcodec1d blacklisted in ship but seeded in server (libasound2-plugins)"
[13:56] <ogra> GAH !
[13:56] <ogra>    * Drop unnecessary Ubuntu-specific change:
[13:56] <ogra>      - debian/control: drop libavcodec-dev build-dependency to save
[13:56] <ogra>        space [this Ubuntu delta didn't save significant space and
[13:56] <ogra>        removed a feature].
[13:57] <lamont> jdong: so about git-core to backports....
[13:57] <lamont> thoughts?
[13:59] <MacSlow> seb128, pitti, mvo: I've a backported (from gstreamer upstream) patch for gst-plugins-good (videobox crashing)
[13:59] <seb128> MacSlow: cool
[13:59] <MacSlow> seb128, pitti, mvo: I hand that over to whom best?
[13:59] <seb128> MacSlow: that would be me probably
[14:00] <seb128> or slomo if you wants it added to Debian but he's not around apparently
[14:00] <MacSlow> seb128, pitti, mvo: I can provide signed .dsc .diff.gz and .changes
[14:01] <seb128> MacSlow: good, just give me the url
[14:01] <ogra> pitti, i'd need a rebuild with the fixed alsa-plugins i just uploaded to fix the uninstallables
[14:01] <pitti> cjwatson_: d-i fails with 'couldn't find package busybox'
[14:02]  * pitti also files bug 172807, but that has an easy workaround
[14:02] <ubotu> Launchpad bug 172807 in debian-installer "automatic keyboard layout detection loops and messes up screen" [Undecided,New] https://launchpad.net/bugs/172807
[14:04] <MacSlow> seb128, http://people.ubuntu.com/~mmueller/gst-plugins-good0.10_0.10.6-0ubuntu5.dsc http://people.ubuntu.com/~mmueller/gst-plugins-good0.10_0.10.6-0ubuntu5.diff.gz http://people.ubuntu.com/~mmueller/gst-plugins-good0.10_0.10.6-0ubuntu5_i386.changes
[14:04] <pitti> cjwatson_: http://people.ubuntu.com/~pitti/tmp/syslog
[14:05] <MacSlow> seb128, these three are all you need right?
[14:06] <seb128> MacSlow: yes, thanks
[14:09] <cjwatson> pitti: will investigate, thanks
[14:11] <pitti> ogra: ok, please tell me when the fixed package is in; we need to wait with the rebuilds until d-i is fixed
[14:11] <ogra> seb128, i see you will be working on pppoeconf-gui ? i used pppoeconf recently with the gdialog frontend (set the DIALOG variable in the pppoeconf binary) despite the warning in the code it worked like a charm, did you consider just using that ?
[14:12] <ogra> pitti, well, since i think that might need an upload as well, i guess my package will be built by then
[14:12] <pitti> right
[14:12] <seb128> ogra: I don't plan to work on that if I can avoid doing so, I said I would look at pppoeconf-gui if we could use it
[14:12] <seb128> ogra: I didn't know about the gdialog (zenity you mean?) frontend but I'll have a look, thanks
[14:13] <ogra> seb128, adding a switch to the script that just changes DIALOG would be easy i think
[14:13] <ogra> seb128, i didnt look deeper, there is a note in /usr/sbin/pppoeconf
[14:13] <ogra> i couldnt find any bugs and didnt see any breakage regarding that comment though
[14:15] <pitti> argh, silly me; /me fixes PAM for dbus at_console to use libpam-foreground again
[14:16] <seb128> ah ah, pitti touched dbus, the merge is for him now :-p
[14:16]  * seb128 hugs pitti
[14:16] <pitti> oh, eww
[14:21] <seb128> MacSlow: ah, your update is a gutsy one, gutsy is stable it requires a SRU if you want a change there, https://wiki.ubuntu.com/StableReleaseUpdates
[14:21] <geser> pitti: please give-back open.app. Thanks
[14:22] <pitti> geser: done
[14:22] <pitti> oops, no, sorry (script doesn't work here)
[14:22]  * pitti does it manually *clickfest*
[14:22] <MacSlow> seb128, yeah I did it for gutsy as I expect hardy to get this gstreamer-upstream stuff anyway
[14:22] <tjaalton> pitti: I still don't understand why xserver-xorg fails to create a config
[14:23] <MacSlow> seb128, I mentioned it in my changelog-entry as "backport" what it actually is afaik
[14:23] <tjaalton> pitti: casper.log doesn't show anything suspicious
[14:23] <seb128> MacSlow: well, SRU are complicated, they need a good rational, review for the sru team, testing for regression, etc
[14:23] <pitti> geser: done
[14:23] <seb128> MacSlow: that's not something we do for random bug fixes
[14:24] <pitti> tjaalton: what should actually be in it? I thought we want to get rid of it in the long term?
[14:24] <seb128> MacSlow: do we have lot of angry users complaining on launchpad about this issue?
[14:24] <tjaalton> pitti: of course, but not just yet :)
[14:26] <jdong> lamont: I replied yesterday about that already, I said it would be fine by me
[14:26] <ogra> does anyone here test on virtualbox ?
[14:27] <MacSlow> seb128, no... I just ran into it and was surprised about the regression... it used to work on feisty... I wanted to have that fixed
[14:27] <MacSlow> seb128, I admit that using videobox isn't usually something the "average user" does.
[14:27] <MacSlow> seb128, still it's an obvious bug-fix
[14:27] <seb128> MacSlow: right, you can read the wiki page I pointed, but I don't think it's worth the efforts to do a stable update
[14:27] <lamont> jdong: oh.  ok.
[14:28] <MacSlow> seb128, so what's the plan for it?
[14:28]  * lamont missed that.
[14:28]  * MacSlow reads
[14:28] <cjwatson> pitti: did you file a bug about the busybox breakage? (if not, don't bother, since I've found it - just want the bug number if there is one)
[14:28] <seb128> MacSlow: we have been bitten by bug fixes creating regressions and that's why it's not trivial nowadays to do a stable update, there is regression testing, etc
[14:28] <pitti> cjwatson: no, I didn't (only half-brain here, meeting going on)
[14:28] <cjwatson> no problem, fix in the pipeline
[14:31] <pitti> cjwatson: you rock, thanks
[14:38] <cjwatson> pitti: also cdebconf-keystep's a bit broken
[14:38] <pitti> cjwatson: is that bug 172807?
[14:38] <ubotu> Launchpad bug 172807 in debian-installer "automatic keyboard layout detection loops and messes up screen" [Undecided,New] https://launchpad.net/bugs/172807
[14:39] <cjwatson> sounds right
[14:39] <cjwatson> I have a working theory and will investigate
[14:40] <geser> pitti: please give-back gphotocoll. Thanks.
[14:41] <pitti> geser: done
[14:45] <pitti> tjaalton: nope, even with a manual xorg.conf and a Monitor section with exaggeratingly high rates I can't get 1024; I blame the vmware driver
[14:50] <tjaalton> pitti: commit "Filter out default modes that are larger than the hardware" could have something to do with it
[14:50] <pitti> tjaalton: hm, so far it worked fine with 1024 (that's what I configured in vmware)
[14:51] <poningru_> gaah :(
[14:51] <poningru_> trying to do alpha release notes
[14:51] <poningru_> need halp
[14:52] <tjaalton> pitti: ok, if you can file a bug with Xorg.0.log and we'll take it from there
[14:53] <pitti> tjaalton: sure, thanks
[14:53] <tjaalton> reinstalling xserver-xorg touches xorg.conf, but still not properly configured
[14:54] <pitti> tjaalton: same with vesa, BTW
[14:54] <pitti> tjaalton: so should I file it against video-vmware or xorg-server?
[14:54] <tjaalton> hmm, the server might be better
[14:56] <tjaalton> hm, it's dexconf failing
[14:58] <tjaalton> uh, my fault
[15:00] <pitti> ah, wait, it seems to use vesa to begin with
[15:00] <pitti> x.org's own autodetection apparently doesn't know about vmware
[15:00] <tjaalton> oh, that's correct
[15:00] <tjaalton> so add a Device section
[15:02] <ogra> really ?
[15:02] <ogra> it works fine in virtualbox
[15:03] <tjaalton> the reason why dexconf fails was that extra_options was missing from xserver-xorg.templates :/
[15:05] <tjaalton> ..which is odd
[15:07] <pitti> tjaalton: I wrote everything to bug 172821
[15:07] <ubotu> Launchpad bug 172821 in xorg-server "[hardy] only get 800x600 in vmware" [Undecided,New] https://launchpad.net/bugs/172821
[15:07] <slomo> doko: ping?
[15:08] <doko> slomo: contentless pong
[15:09] <slomo> doko: great, ok, i have a python package here (python-gst0.10) that has a file (pygst.py) that is different when building against different python versions. problem is now, that pycentral doesn't notice this and the 2.4 file is used always
[15:10] <tjaalton> pitti: thanks
[15:10] <slomo> doko: see debbug #453402
[15:10] <slomo> doko: what can i do about that? :)
[15:10] <tjaalton> pitti: I'll readd extra_options (lost during the first git-merge..) and upload a new xorg
[15:12] <doko> slomo: Do not move the files to /usr/share/pycentral, or modify the file: import sys; _pygst_dir = '/usr/lib/python%s/site-packages/gst-0.10' % sys.version[:3]
[15:12] <slomo> doko: thanks
[15:13] <pitti> tjaalton: hm, was that the bit I added for restricted-manager?
[15:13] <slomo> doko: can't pycentral get the same magic that python-support has for detecting such differences and handle them correctly? :)
[15:13] <pitti> tjaalton: we don't actually need it any more, since r-m uses the guidance-backends now
[15:13] <slomo> doko: and does pycentral have something like a -X switch to ignore a file?
[15:13] <pitti> tjaalton: so if you wish you can revert all those changes
[15:14] <tjaalton> pitti: sweet, although it's not preseedable anymore?
[15:14] <pitti> tjaalton: well, if it's good for something, you can leave it :), just telling that I don't depend on it any more in r-m
[15:14] <tjaalton> doesn't matter
[15:15] <tjaalton> nvidia should fix their driver ;)
[15:15] <tjaalton> I'll rip it off then, thanks!
[15:17] <doko> slomo: what would -X be good for?
[15:17] <slomo> doko: to let pycentral not move the files i want
[15:17] <doko> slomo: DH_NOMOVE
[15:17] <slomo> doko: thanks again
[15:18] <doko> slomo: why just one or more files? that doesn't make sense. either the package becomes version specific, or it stays version independent
[15:26] <lool> doko: Would be nice if pycentral would handle this transparently
[15:27] <lool> doko: Josselin just argued that python-support handles this, and I had to debunk switching to -support afterwards
[15:27] <lool> (I did switch to -support and reverted in the past, and nowadays I would feel the switch to be risky; but I'd prefer not to have to discuss it :)
[15:28] <lamont> jdong: where's the magic "gimme a backport of this" button on LP?
[15:31] <pitti> lamont: it's called a 'backport request' bug
[15:31] <doko> lool: send a patch? otoh, there is a solution: DH_NOMOVE. just because things *can* be handled, you don't have to.
[15:31] <lamont> pitti: ah, ok
[15:31] <lamont> can I do forward ports too?
[15:32] <lamont> after I backport this to dapper and upload it, that version should build on edgy/feisty backports just fine.
[15:32] <pitti> lamont: what does that mean? backport a feisty package to gutsy?
[15:32] <lool> doko: Well I'm not within the pycentral internals; I'd prefer NOT to have to learn about them
[15:32] <cjwatson> lamont: the tools don't support that
[15:32] <pitti> lamont: usually we fix the hardy package to be backportable and then do it for all requested releases
[15:32] <cjwatson> lamont: though they do support backports to multiple targets, as pitti says
[15:32] <lamont> it's a hardy package, backporting to dapper-gutsy.  gutsy has a new enough dpkg that 'backport this' works.  the others require a little source love
[15:33] <lool> doko: And I'd fear regressions would I do the changes following my gut feeling, unless there's a complete testsuite nowadays?  I think it would make sense to have the functionalities on par overall
[15:33] <lamont> pitti: feisty and earlier require sourceful uploads... sounds like I want to do dapper/edgy/feisty source uploads then?
[15:33] <pitti> lamont: hm, nothing that can be fixed in the hardy package?
[15:34]  * pitti really doesn't like soure uploads to -backports, since someone has to maintain them
[15:34] <lamont> well, there's a build-depends that probably fixes some subtle doc formatting issue that I'm kinda handwaving over, as well
[15:34] <lamont> and then it uses ${source:Upstream-Version} in debian control, which showed up in gutsy
[15:35] <pitti> right, that won't work in earlier releases
[15:35]  * pitti bumps base-installer build score; we need you now
[15:39] <lamont> pitti: so it's 3 source uploads for me?
[15:39] <cjwatson> cdebconf-keystep coming shortly
[15:40] <pitti> lamont: apparently yes, if you really care about edgy and feisty?
[15:40] <tjaalton> pitti: I'll upload xorg since now dexconf actually works :)
[15:40] <pitti> tjaalton: alpha 1 appropriate changes only?
[15:40] <pitti> tjaalton: thanks a lot for fixing
[15:41] <tjaalton> pitti: yes, dropped the extra_options from there
[15:41] <lamont> pitti: well, only slightly.
[15:41] <lamont> :)
[15:42] <tjaalton> pitti: and monitor_identifier which was a leftover (and would also make dexconf fail since it's not in templates anymore)
[15:42] <pitti> lamont: surprising how fast a release changes from "our highest pride" to "chained to our testicles for supporting" :)
[15:42] <lamont> pitti: and the tools won't let us promote  a package from dapper-backports to edgy-backports etc, right?
[15:42] <lamont> pitti: takes about what, 3 weeks?
[15:42] <cjwatson> actually
[15:42] <cjwatson> technically they do
[15:42] <pitti> lamont: is it a new packatge?
[15:43] <cjwatson> as long as the binaries in dapper-backports work
[15:43] <pitti> lamont: we could copy-package it
[15:43] <lamont> git-core
[15:43] <cjwatson> pitti: right
[15:43] <cjwatson> we just can't copy only the source and rebuild
[15:43] <pitti> lamont: what we cannot do is copy-package the source only, since the binaries need new version number
[15:43] <lamont> cjwatson: of course - that'd give us two diff debs with the same name
[15:43] <cjwatson> but we can pretend as if it was in dapper all along and got copied into edgy/feisty in the normal course of events
[15:43] <cjwatson> s/was/were/
[15:44]  * lamont will check that.
[16:14] <davmor2> ogra: edubuntu server is too oversized :(
[16:15] <ogra> davmor2, yep
[16:15] <davmor2> just letting you know couldn't burn it to cd so can't test it :(
[16:16] <ogra> davmor2, it wont install anyway
[16:16] <davmor2> :)
[16:16] <ogra> there are broken deps
[16:16] <ogra> http://cdimage.ubuntu.com/edubuntu/daily/current/report.html
[16:16] <davmor2> okay I'll let the testers know :)
[16:16] <ogra> libasound2-plugins was fixed and uploaded but is waiting for a rebuild ...
[16:16] <ogra> it will still be oversized then though
[16:17] <ogra> so they need to use a DVD or 800M CD
[16:17] <davmor2> np I'll pass it on
[16:21] <Asusu> hello. when programming Linux, are there functions to allocate memory from private heaps? (much like the win32 heapcreate and sort functions). It's for porting code to linux.
[16:23] <ogra> thats probably a good question for #linux :)
[16:23]  * ogra points at the topic
[16:29] <Asusu> ops sorry
[16:29] <Asusu> where could I go ask for that?
[16:30] <soren> Asusu: #linux as ogra just said :)
[16:30] <Asusu> gee, I'm blind sorry :( and thanks.
[16:30] <soren> Asusu: np
[16:56] <pitti> cjwatson: pam is in, I think I can already build desktops, and build alternates once cdebconf-keystep lands
[16:56] <ogra> ltsp in in alternate ?
[16:57]  * ogra just saw it has the same report.html content)
[16:57] <pitti> hm, in ship probably, why?
[16:57] <ogra> because it wont work without linux-image-i386
[16:57] <ogra> err
[16:57] <ogra> linux-image-386
[16:57] <ogra> that shuld be seeded as well then
[16:58] <illovae> hello :)
[17:01] <cjwatson> pitti: debian-installer needs to build after cdebconf-keystep in order for it to be useful
[17:01] <cjwatson> pitti: evand is preparing ubiquity too if you want to give that a shot
[17:02] <pitti> cjwatson: oh, we need a new ubiquity? or is it a target of opportunity?
[17:02] <cjwatson> well, if you want the live CDs to be installable
[17:03]  * ogra thought alpha1 is only about having a booting image ...
[17:03] <cjwatson> in the past alpha 1 has been alternate-only sometimes
[17:03] <cjwatson> so in that sense it's a target of opportunity
[17:03] <pitti> cjwatson: hm, the current desktops install just fine
[17:03] <pitti> cjwatson: they just break dbus's at_console, which kills network-manager applet, etc.
[17:03] <pitti> but in general...
[17:04] <ogra> pitti, edubuntu has only amd64 -desktop apparently ...
[17:04] <ogra> did you cancel the build ?
[17:04] <pitti> no, I didn't
[17:04] <cjwatson> pitti: err. they have old choose-mirror so it's rather surprising that they end up with a correct sources.list
[17:04] <cjwatson> (the choose-mirror built into ubiquity)
[17:05] <cjwatson> pitti: you sure they don't say gutsy in sources.list after install?
[17:05] <pitti> hm, I didn't check sources.list, just that it installs
[17:05] <cjwatson> worth checking that
[17:05] <cjwatson> if that's correct then I guess you can go with it
[17:05] <pitti> ok, booting that again
[17:06]  * pitti invents a grub boot stanza
[17:09] <pitti> cjwatson: sources.list is hardy; it's just all commented out because I installed without network
[17:09] <pitti> (my laptop)
[17:09] <cjwatson> hm, ok
[17:09] <pitti> heno: when you installed the current hardy desktops, did you do a networkful install? do you still have one where you could check apt sources.list?
[17:11] <Riddell> siretart: I believe your life may be in danger
[17:11]  * pitti raises the shields around siretart
[17:12] <Riddell> makeing xine depend on libxine1-gnome can have that affect
[17:12] <ogra> heh
[17:13] <Riddell> natually I'm a passifist quaker so no danger from me, but others might not be so forgiving
[17:14] <cjwatson> pitti,seb128,Riddell,slangasek,Mithrandir: I'm going to accept linux 2.6.24 source so that it can build, but I recommend holding off on accepting the binaries until after alpha-1, since it provides a new linux-libc-dev
[17:14] <seb128> that's what you get for using xine instead of gstreamer ;-)
[17:14] <ogra> just fix KDE to use the right toolkit
[17:14]  * ogra hides
[17:14] <seb128> cjwatson: noted
[17:14] <pitti> cjwatson: acknowledged
[17:15]  * pitti wants drescher:~/bin/make-build-records-NOW-dammit
[17:15] <Mithrandir> cjwatson: good point.
[17:15] <cjwatson> pitti: let me know when cdebconf-keystep binaries are publishing, and I'll upload d-i
[17:16] <pitti> cjwatson: I will
[17:16] <pitti> (that's what I'm waiting for; source is there for 30 minutes, and it still doesn't have build recs)
[17:17] <cjwatson> you'd want s/drescher/cesium/ anyway
[17:17] <cjwatson> prodding buildd stuff from drescher generally considered harmful AIUI
[17:18] <pitti> Riddell: curious; how can koffice-l10n still have a differing orig.tar.gz md5sum if the merge was a new upstream version?
[17:18] <pitti> cjwatson: right, just whining
[17:19] <Riddell> pitti: it wasn't, we both had 1.6.3
[17:20] <pitti> ah, -0ubuntu1?
[17:20] <Riddell> yes, I packaged it before debian did
[17:20] <pitti> ah, our kernel source is now just called 'linux'; nice and slick
[17:22] <cjwatson> binaries will still be versioned though
[17:22] <cjwatson> pitti: do you object to a new ubiquity? evand has it ready
[17:22] <pitti> cjwatson: no, I don't object to it at all
[17:22] <cjwatson> slangasek: ^-- if you're up - noticed you were sort of late last night :)
[17:23] <pitti> I just wanted to know whether it's  critical path
[17:23] <cjwatson> not AFAICS
[17:23] <pitti> cjwatson: I'm currently building new desktops, so it won't make it there, but we might have other reasons for rebuilding
[17:24] <cjwatson> right
[17:24] <ogra> if we rebuild anyway i have a ltsp-client fix i'd like in (apparently pulseaudio-esound-compat doesnt depend on pulse anymore so i need a dep)
[17:25] <ogra> pitti, would that be ok with you ?
[17:25] <pitti> ogra: alternates need a rebuild, blocking on at least two publishers (probably three)
[17:25] <pitti> ogra: so please go ahead
[17:25] <ogra> great
[17:25] <ogra> gimme a sec
[17:27] <lamont> jdong: feel free to bless git-core_1:1.5.3.6-1.1~dapper1
[17:42] <geser> pitti: please give-back cameleon. Thanks
[17:42] <pitti> geser: done
[17:48] <cjwatson> pitti: cdebconf-keystep has build records now
[17:48] <pitti> aaaah
[17:48]  * pitti bumps up the score
[17:48] <pitti> cjwatson: I'll delay the publisher for this if necessary; this has taken long 'nuff already
[17:49] <cjwatson> is it possible for me to upload debian-installer source in the same publisher run?
[17:50] <cjwatson> I know that in theory it ought to start building before the source is published
[17:50] <pitti> right
[17:51] <pitti> cjwatson: but if it starts building before the cdebconf binaries are published it'll build against the old version
[17:51] <cjwatson> exactly
[17:52] <pitti> cjwatson: so if you set proper build depends, you should do it now
[17:52] <pitti> then we can get build records
[17:52] <pitti> hah, built everywhere
[17:52] <pitti> well, except sparc
[17:53] <cjwatson> technically, it is used on sparc
[17:53] <cjwatson> we could decide not to care for this
[17:53] <pitti> cjwatson: easy: we just build the server images last
[17:53] <nxvl_work> i need a given-back for gtoaster
[17:54] <pitti> cjwatson: I don't care about sparc desktops/alternates at this point
[17:55] <cjwatson> I'm happy to have a release note that says that on sparc you need to answer no to the detect-keys question
[17:55] <pitti> nxvl_work: I'll do it; I just want to fix my magic buildd script which doesn't want to work for this case
[17:55] <lamont> mvo: so can I test upgrading yet?
[17:55] <pitti> cjwatson: if it builds within an hour, we are good anyway (we build server images last)
[17:56] <pitti> if not, yes, release-note sounds appropraite
[17:56] <cjwatson> order of building images does not affect when d-i itself builds
[17:56] <cjwatson> though you could crank d-i's build score on sparc way down temporarily, and that would do the job
[17:56] <pitti> cjwatson: but with versioned build-deps?
[17:56] <cjwatson> err
[17:56] <cjwatson> not so much on udebs, no
[17:56] <pitti> ah, right
[17:57] <pitti> cjwatson: sure, can do
[17:57] <cjwatson> it builds with whatever's in the archive
[17:57] <pitti> setting it to 1 will make it build in two years approximately
[17:57] <cjwatson> :-)
[17:57] <cjwatson> so how about I wait until this publisher run is nearly done and then upload d-i?
[17:57] <pitti> deal
[17:57] <mvo> lamont: no yet :(
[17:58] <lamont> pitti: and if it gets too close, just smack sparc into manual
[17:58] <lamont> pitti: not 2 years...
[17:58] <lamont> mvo: ok.  poke me when, eh?
[17:58] <pitti> lamont: yep
[17:58] <lamont> mvo: btw, update-manager should really notice if network-mangler is going to change existance and not do that if I'm running over ssh
[17:58] <lamont> not just warn me that it's problematic.
[17:59] <mvo> lamont: n-m is *cough* I signed the CoC so I can't tell you what I think about the fact that it kills netowrks on upgrade
[17:59]  * lamont ran into that last night when his daughter's computer picked up network-mangler as part of upgrading (do-release-upgrade) from feisty and it happily trashed the network, as it competed with dhcp3-client
[18:00] <cjwatson> man, I love having the debian-installer source package in bzr at long last
[18:00] <lamont> mvo: if network-manager is not installed before the upgrade, don't install it in the upgrade, if the upgrade is being done over the network.
[18:03] <cjwatson> mvo: you're lucky, it kills my keyboard on upgrade
[18:03] <cjwatson> (though I expect that's a kernel bug and am sort of hoping that 2.6.24 fixes it ...)
[18:04] <mvo> cjwatson: network-manager? woah!
[18:04] <mvo> ogra: is hwdb-client maintained in bzr?
[18:04] <elmo> cjwatson: haha
[18:04] <ogra> mvo, no idea ... Riddell took more care of it than i did the last year
[18:04] <elmo> cjwatson: ng claims that the n-m in gutsy-proposed fixes his X driver
[18:04] <ESphynx> hi guys
[18:04] <ESphynx> How can I use XRender on this 565 visual when XRender only support 555 format? :(
[18:04] <cjwatson> elmo: have been running that or equivalent for a while
[18:05] <cjwatson> it's certainly better in various ways
[18:05] <ogra> mvo, if he has a branch that should be preferred
[18:05] <ogra> ESphynx -> #ubuntu please
[18:05] <Riddell> mvo: sure https://code.edge.launchpad.net/~ubuntu-core-dev/hwdb-client/trunk
[18:05] <ESphynx> ogra ok thanks.
[18:05] <mvo> Riddell: then the Vcs-Bzr is missing ;) let me fix it
[18:07] <Ng> it did fix it! clearly that makes no sense and I'm on crack, but my network manager doesn't break anymore and X stopped segfaulting on resume!
[18:07] <ogra> Ng, so you have the ubuntu-magic reop enabled eh ?
[18:07] <ogra> *repo
[18:07] <Ng> hehe
[18:10] <mvo> Riddell: checking it out now and bringing it in sync again, sorry
[18:13] <cjwatson> pitti,slangasek: watch out, apparently ubiquity 1.7.0 actually doesn't work so well
[18:14] <mvo> Riddell: bzr updated
[18:14] <pitti> cjwatson: ok, once it has build records I'll set it to low build prio
[18:16] <Riddell> mvo: thanks
[18:17] <wasabi> hal is confusing me. it's refusing to start. but it prints out so much crud that I can't isolate why.
[18:17] <wasabi> and when it exists, it leaves it's addons running. =/
[18:17] <wasabi> *exits
[18:18] <wasabi> *** [DIE] hald_runner.c:runner_died():202 : Runner died   no idea what a runner is, though.
[18:25] <bryce> cjwatson: sent
[18:25] <bryce> cjwatson: you're right - same thing.
[18:30] <pitti> nxvl_work: given back
[18:31] <pitti> Mithrandir, LongPointyStick: FYI, I uploaded a new buildd.py which fixes version numbers with a + in it
[18:32] <cjwatson> bryce: thanks
[18:33] <bryce> when I see gravity online I'll encourage him to look at all the stuff we did for xresprobe; I think it'd fix a bunch of issues for them too
[18:33] <bryce> however I know their plan is to excise xresprobe entirely, so it might be moot
[18:34] <cjwatson> pitti,slangasek: debian-installer 20070308ubuntu22 uploaded; I notice sparc is now building cdebconf-keystep too
[18:38] <pitti> cjwatson: hah, I just went back from dinner preps to ask you :) thanks
[18:39] <pitti> cjwatson: crap; this time q-b fooled me, and ubiquity is already building; how bad is it?
[18:39] <pitti> cjwatson: I can just reject the binaries if necessary
[18:40] <cjwatson> pitti: might be best to reject the binaries - it'll break in clock-setup
[18:40] <cjwatson> 18:03 <evand>  /usr/lib/ubiquity/clock-setup/clock-setup: 35: tzsetup not found
[18:40] <pitti> acsk
[18:41] <geser> pitti: please give-back sqlrelay. Thanks.
[18:49] <slangasek> poningru_: what kind of help are you looking for for the release notes?
[18:50] <slangasek> cjwatson: ack on linux-2.6
[18:50] <slangasek> so the new ubiquity that's uploaded doesn't work so well, so we're better off not rebuilding desktop again?
[18:50] <poningru_> slangasek, what features you guys wanted to go on there
[18:50] <cjwatson> slangasek: if pitti rejects the binaries, shouldn't be a problem
[18:50] <poningru_> I am currently looking at the blueprints downloading an image to install here
[18:50] <poningru_> and looking at gnome 2.20.2 release notes
[18:50] <poningru_> also what gnome release will be on here?
[18:51] <slangasek> cjwatson: ah, I see that now
[18:51] <poningru_> around what time do you think the release will happen?
[18:53] <slangasek> poningru_: I don't think gnome 2.20 is even all in yet, I have my doubts that it's worth mentioning for this round?
[18:53] <slangasek> the one spec that has landed is Xorg 7.3, so that deserves a mention
[18:53] <slangasek> otherwise it's fine to be light on lists of features
[18:54] <slangasek> poningru_: I think we'll want more space for caveats than for lists of features (it's very alpha)
[18:55] <pitti> slangasek: good morning
[18:57] <slangasek> pitti: morning
[18:57] <pitti> slangasek, cjwatson: ubiquity lpia, i386 binaries rejected; amd64, powerpc, sparc disabled with build prio
[18:58] <cjwatson> ok, thanks
[18:58] <pitti> slangasek: so, quick report: current desktops aren't too bad (they *should* fix nm-applet, haven't tested them yet), alternates need d-i which was uploaded a couple of minutes ago
[19:03] <slangasek> pitti: "aren't too bad" -> should be pushed for a quick QA round?
[19:04] <slangasek> wow, why is someone claiming on ubuntu-devel that dash isn't a POSIX shell?
[19:04] <soren> pitti: Will you have time to look at source NEW tomorrow?
[19:08] <soren> pitti: Never mind, I'll talk to you tomorrow.
[19:08]  * soren vanishes
[19:09] <poningru_> ok
[19:12] <geser> pitti: please give-back sqlrelay. Thanks.
[19:16] <cjwatson> slangasek,pitti: ubiquity 1.7.1 uploading, should actually work if you find yourself needing/wanting to let it through
[19:16] <cjwatson> (but 1.6.8 will be fine
[19:16] <cjwatson> )
[19:20] <pitti> slangasek: yes, please (qa)
[19:20] <pitti> slangasek: I tested the previous ones only, though; since then I fixed at_console for dbus (unbreaking network-manager), not much else happened
[19:20] <pitti> cjwatson: thanks
[19:20] <pitti> soren: yep, archive day tomorrow
[19:21]  * pitti -> back to oven
[19:27] <slangasek> pitti: ok.  I don't think I have access to the ISO QA site to make those live for testing?
[19:29] <slangasek> stgraber: ping
[19:29] <stgraber> pong
[19:30] <slangasek> stgraber: we have some new desktop CDs for alpha1 that I think should go on the ISO QA site, and I'm pretty sure I can't do that :)
[19:31] <stgraber> now you can :)
[19:31] <stgraber> slangasek: https://iso.qa.stgraber.org/qatracker/addbuild
[19:32] <stgraber> tick the builds you want to add/update, put the version number and click add builds (the right milestone should have been set by default)
[19:32] <slangasek> ah, interesting, ok
[19:32] <slangasek> ogra: what's the state of edubuntu?  you have something that's worth testing for the alpha, or are you passing due to the reorg?
[19:33] <ogra> well, the next images should at least be installable ... oversized by some MB though
[19:33] <slangasek> ok, probably best to not push oversized images as an alpha
[19:34] <ogra> and since cjwatson and i still havent discussed the CD reorg i have to assume the status quo atm ...
[19:34] <ogra> so let them test if tehy have DVDs to write to ;)
[19:34] <ogra> (or 800M CDs)
[19:39] <stgraber> yeah, I have Gutsy running on a 500Mhz computer with 128MB of RAM :) (and ~50MB free)
[19:39] <ogra> still no i386 builds for edubuntu desktop isos ?
[19:39] <ogra> hrm
[19:40] <slangasek> ogra: I don't know that I see much value in releasing an alpha CD image that doesn't even fit on a CD.  any chance of getting these down to size?
[19:40] <slangasek> (langpacks?)
[19:41] <ogra> slangasek, well, we never treally cared for the first build in the past ... i'll take a look
[19:41] <slangasek> ogra: so in the past there's been useful feedback on oversized alpha CDs?
[19:42] <ogra> from VM testers, and people using DVDRW, yes
[19:44] <stgraber> if that's about Edubuntu server, all the servers I use with Edubuntu (my test network or schools) all have DVD reader, that's not the same as the workstation, usually servers have recent hardware in them (and then tons of crappy hardware as client :))
[19:45] <ogra> anyway, let me drop the langs
[19:45] <ogra> slangasek, ok, changed the ship seed and dropped all langs but en, that needs a publisher run afaik
[19:45] <ogra> yeah
[19:45] <ogra> well, disabling the langs doesnt cost much ... (and is actually done now)
[19:46] <ogra> i cant do that for the liveCD though ...
[19:46] <ogra> and there is nothing to drop atm ...
[19:48] <cjwatson> ogra: the CD reorg is a spec like any other, and thus targeted for feature freeze
[19:48] <cjwatson> ogra: if it happens ahead of that, great
[19:48] <cjwatson> ogra: but it is not at present targeted for any particular milestone
[19:49] <ogra> cjwatson, well, i'D like to discuss if we really want it in hardy as it will bring up heavy issues with LTS to LTS Cd upgrades
[19:50] <cjwatson> yes, we do
[19:50] <ogra> ok
[19:50] <cjwatson> all it means is that CD upgrades require (at least) two CDs
[19:50] <ogra> and the apps to know whats where
[19:50] <cjwatson> I'm not entirely convinced that dapper->hardy CD upgrades will work with a single CD (as opposed to the DVD) anyway
[19:51] <cjwatson> it would be great if they did, but I wouldn't like to guarantee it
[19:51] <ogra> i mean synaptic or u-m dont know where they find what
[19:51] <cjwatson> I'm sure they can be taught
[19:51] <cjwatson> it's an issue that should be recorded in the spec, but I don't think it's as serious/hard as you're suggesting
[19:51] <ogra> right, but thats a huge amount of work we'd save if we did it in hardy+1
[19:51] <cjwatson> it's not huge
[19:51] <ogra> ok
[19:51] <cjwatson> all the underlying technology supports media change requests
[19:51] <cjwatson> it's just a matter of exposing it in the UI
[19:51] <ogra> i'm not the one to judge here (mvo would)
[19:52] <cjwatson> if it isn't already
[19:52] <cjwatson> bear in mind that Debian has been doing multi-CD stuff for years and years
[19:52] <ogra> i know
[19:52] <ogra> but we dont use their setup  ...
[19:52] <cjwatson> and thus the package management system has built-in support for CD changing
[19:52] <cjwatson> the only place we have actually disabled multi-CD support is in the installer
[19:53] <Keybuk> cjwatson: BUT THE SKY IS FALLING
[19:53] <Keybuk> ;)
[19:53] <ogra> Keybuk, :P
[19:53] <cjwatson> I'm not aware that it has been disabled for upgrades
[19:53] <cjwatson> update-manager might not have been taught about it, but I really can't imagine it being rocket science
[19:53] <ogra> it surely isnt
[19:53] <Keybuk> it's probably a python function in the release upgrader bit
[19:54] <cjwatson> update-manager definitely has at least stub support for it
[19:54] <cjwatson> dpkg -L update-manager | xargs grep mediaChange
[19:55] <cjwatson> I imagine the only thing that needs to be done is for the process that starts the upgrade to prompt you for the second CD so that it can register it
[19:56] <ogra> how would it know it needs the second one ?
[19:56] <ogra> i mean people will upgrade using ubuntu laternate but pieces are missing ...
[19:57] <cjwatson> echo you need two cds if you are edubuntu, kthxbye > .disk/magic_file
[19:57] <ogra> will it just default to ask for a second one ? (that would break on ubuntu then)
[19:57] <keescook> Keybuk: race condition email> the example is a setuid program, no ptrace possible... ??
[19:57] <ogra> ah, cool
[19:57] <cjwatson> it could special-case on edubuntu-desktop or something
[19:57] <cjwatson> I'm sure it's not difficult
[19:57] <ogra> yeah
[19:57] <Keybuk> keescook: ah, that bit I didn't see
[19:57] <ogra> i didnt say its difficult i just think its more work i hardy than doing it in hardy+1
[19:58] <ogra> but well, we'll go for it :)
[19:58] <cjwatson> if it isn't done in hardy, it's just another LTS to support
[19:58] <slangasek> keescook: "I have incredible proof of this security vulnerability, but there's insufficient room to write it in the margin of this email" -- Scott James Remnant
[19:58] <keescook> slangasek: heheh
[19:59] <Keybuk> talking of which, whatever happened to that kernel update? :)
[20:00] <keescook> now that 2.6.24 is landing in the archive, cjwatson, Keybuk: we need to resolve the procps conf file issue.  cjwatson: Keybuk recommended we exclude /etc/init.d/procps from configs because if we don't we have to carry the /usr/share/procps/procps.init-dist file forever.
[20:00] <Keybuk> err, 2.6.24 is landing?
[20:00] <Keybuk> I thought that was missing alpha 1
[20:00] <cjwatson> keescook: it's not going to be accepted before alpha-1
[20:01] <keescook> cjwatson: right, I just mean, we'll have it soon, and I want to sort out the procps silliness.
[20:01] <cjwatson> I don't understand the last sentence. "exclude /etc/init.d/procps from configs"?
[20:01] <cjwatson> anyway, ask me tomorrow or something, I'm finishing for the day :)
[20:01] <cjwatson> sorry
[20:01] <keescook> cjwatson: okay
[20:02] <keescook> Keybuk: what is the actual mechanism to exclude an /etc file from dpkg config management?
[20:02] <Amaranth> I thought it was opt-in
[20:02] <Keybuk> keescook: just don't include it in conffiles
[20:03] <Keybuk> excluding it from debhelper sticking it in there requires giving joeyh a lobotomy
[20:03] <cjwatson> no it doesn't
[20:03] <cjwatson> you have to not ship it in the deb
[20:03] <Keybuk> why?
[20:03] <Keybuk> point me to the line in debian-policy ;)
[20:03] <cjwatson> if you ship it in the deb and exclude it from conffiles, you have a file in /etc that cannot be user-edited
[20:03] <Mithrandir> Keybuk: how do you then preserve user changes?
[20:03] <slangasek> which is therefore either an FHS violation or a policy violation
[20:04] <pitti> geser: sqlrelay bounced
[20:04] <slangasek> (take your pick)
[20:04] <Mithrandir> slangasek: or both!
[20:04] <Mithrandir> :-)
[20:04] <keescook> so, here's the issue...
[20:04] <Keybuk> cjwatson: if you don't, you can't ever have it editable anyway
[20:04] <Keybuk> since dpkg is fucked
[20:04] <keescook> procps.sh was obsoleted
[20:04] <Keybuk> (I was asked for a solution to get rid of the obsolete line)
[20:04] <keescook> er procps was obsoleted in favor of procps.sh
[20:04] <keescook> now they've moved back to just plain procps
[20:04] <Keybuk> cjwatson: given this is an init script, I REALLY DON'T CARE about it being user-edited ;)
[20:04] <keescook> but dpkg won't create that file since it's obsolete now
[20:05] <Keybuk> they shouldn't be conffiles in the first place
[20:05] <cjwatson> oh I thought you were talking about /etc/sysctl.conf
[20:05] <cjwatson> but still
[20:05] <keescook> no, /etc/init.d/procps{,.sh}
[20:05] <Mithrandir> Keybuk: I disagree; I edit init scripts on a regular basis.
[20:05] <slangasek> keescook: oh, ugh
[20:05] <Amaranth> I used to, then I realized I kept breaking things
[20:05] <Keybuk> Mithrandir: yes, but you also use evms, so you're hardy a common use case <g>
[20:06] <cjwatson> regardless of your opinions about where /etc/init.d/ should be, they're in /etc and the promise that they're user-editable to at least some degree has been there for a very long time
[20:06] <cjwatson> I do not think it is acceptable to break that without at least some care
[20:06] <slangasek> stgraber: what have I done wrong, that all of the edubuntu server disks list as invalidated on the iso tracker?
[20:06] <keescook> Amaranth: yeah, I had init-modification beaten out of me in the same way  :)
[20:06] <Keybuk> easy to unbreak
[20:06] <Keybuk> make them non-conffile but config files
[20:06] <Amaranth> Speaking of breaking things, what happened to native upstart jobs? :)
[20:06] <Keybuk> put the md5sum in postinst, and deal with it later ;)
[20:06] <Mithrandir> keescook: rm the non-.sh file in the preinst if it matches something we've ever shipped?
[20:06] <Amaranth> Isn't that what X does?
[20:06] <slangasek> Mithrandir: the problem is it'll already be gone due to previous upgrade handling
[20:07] <cjwatson> there are certainly plenty of ways to do it, such as openssh's vile preinst hack
[20:07] <slangasek> Mithrandir: but dpkg will still know about it, and apparently refuse to reinstate it
[20:07] <slangasek> (as a conffile)
[20:07] <keescook> Mithrandir: right, that's what the postinst does already -- it's handling everything correctly.  the hiccup is that with the file _missing_, dpkg will not create the fresh procps
[20:07] <Mithrandir> slangasek: ah, point.
[20:07] <keescook> because it was obsolete.
[20:07] <Keybuk> as I said
[20:07] <cjwatson> (encode the intended contents of the conffile in the preinst and write it out there)
[20:07] <Keybuk> I think this is bad
[20:07] <Keybuk> and definitely a violation
[20:07] <Mithrandir> keescook: check in postinst what version you're upgrading from and the cp it in if it's missing, then.
[20:07] <Keybuk> but it's just for one release
[20:07] <Keybuk> then it can go back to being a conffile
[20:07] <Keybuk> otherwise we have to carry the PAIN! forever
[20:08] <cjwatson> no you don't, the preinst hack would be just fine
[20:08] <Keybuk> which preinst hack?
[20:08] <cjwatson> ^-
[20:08] <Keybuk> any preinst hack I can think of will result in dpkg either failing to install the file, or conflicting it
[20:08] <Keybuk> copy in preinst => BOOM! YOU PUT A FILE THERE! I'M SULKING
[20:08] <cjwatson> I have done this
[20:08] <cjwatson> it worked
[20:08] <stgraber> slangasek: looking
[20:08] <Keybuk> cjwatson: really?
[20:08] <cjwatson> openssh-client.preinst
[20:09] <slangasek> of course, that's a preinst hack that occasionally caused dpkg itself to segfault... :)
[20:09] <keescook> was that dealing with a conf file marked "obsolete" ?
[20:09] <Mithrandir> if it's obsoleted, but not removed, then reinstated with the same contents, that'll just work on upgrades, won't it?
[20:09] <cjwatson> keescook: no, but I'm not convinced it's meaningfully different, and I definitely think somebody should try it
[20:09] <stgraber> slangasek: current version is 20071129.2 for edubuntu alternate ?
[20:09] <Keybuk> the obsolete case is pathological
[20:09] <Keybuk> you end up with
[20:09] <slangasek> stgraber: yes
[20:09] <Keybuk>  /etc/init.d/procps.sh meaningfulmd5sum
[20:09] <Keybuk>  /etc/init.d/procps obsolete
[20:10] <slangasek> stgraber: granted I haven't verified it's actually on the public cdimage mirror, so maybe I'm a slacker and should be looking before asking you
[20:10] <Keybuk> you need to remove procps.sh *in preinst* to make sure you don't get another obsolete line
[20:10] <slangasek> stgraber: nope, looks like it's there
[20:10] <Keybuk> but if you put procps back, even in preinst, dpkg will still sulk and think it's obsolete
[20:10] <keescook> sounds dpkg needs to ignore obsolete markings if the file is in the .deb
[20:10] <cjwatson> given that update-manager is going to upgrade with the new dpkg (thanks to mvo), we could just fix dpkg
[20:10] <Keybuk> the only way I found was to put it back in the package list as a non-conffile
[20:10] <stgraber> yes they are, I just re-enabled them on the tracker and I'm investigating why they have been disabled
[20:11] <Keybuk> cjwatson: sounds platform to me ;)
[20:11] <slangasek> stgraber: ok, thanks
[20:11] <slangasek> Keybuk: haha
[20:12] <keescook> so is the sane solution "fix in dpkg" ?
[20:13] <cjwatson> keescook: it does sound like that's where the root bug is
[20:14] <stgraber> slangasek: edubuntu server ISOs have been added by pitti at 14:48, then disabled (no information about that)
[20:14] <cjwatson> but, it would mean *everyone* would have to use update-manager, or something else that could use the new dpkg
[20:14] <cjwatson> since procps is priority: required
[20:14] <cjwatson> or we could both fix dpkg *and* include some kind of workaround
[20:15] <keescook> workaround: sed the package list.  :P
[20:15] <stgraber> slangasek: are you sure the current ISOs are .2 ? (.2 have been uploaded to cdimage at ~13:40)
[20:16] <cjwatson> keescook: unfortunately dpkg is probably running by the time you get to this, otherwise sedding /var/lib/dpkg/status might actually be viable
[20:16] <Keybuk> keescook: given we have a python upgrader, if this is a quick hack solution, it would work
[20:16] <cjwatson> but sedding status while dpkg is running is really not a plan
[20:16] <Keybuk> cjwatson: we could sed it before running apt/dpkg inside update-manager ;)
[20:16] <cjwatson> I think people are still going to upgrade in other ways, and while That's Not Supported And Don't Do That, it would be nice if we could come up with a way to make it work
[20:17] <cjwatson> if it were a package that only some people had installed, then I'd agree that just doing it in update-manager was fine
[20:17] <keescook> cjwatson: right, sed + copy file in place from /usr/share
[20:17] <cjwatson> but for something that's priority: required it would be pretty unfortunate to *guarantee* breakage for everyone using apt
[20:17] <keescook> is there really no mechanism to force dpkg to drop an "obsolete" entry?
[20:18] <slangasek> stgraber: oh, well, edubuntu hasn't been respun; I don't know why they were disabled then, feel free to leave them disabled and I'll talk to him (or just respin gratuitously if that's faster)
[20:18] <Keybuk> keescook: obsolete needs more development work to complete
[20:19] <ogra> slangasek, do a publisher run before respinning please ... i dropped tuxmath from live so i386 should actually build
[20:19] <slangasek> keescook: taking a step back, why is this init script moving again?
[20:19] <Keybuk> the patches were written by us, so they might be readable to someone who understands C and fancies a challenge
[20:19] <Keybuk> (it's iwj-C, so drink about half a bottle of good red wine first)
[20:19] <slangasek> ogra: not relevant for server, though?  I was only going to respin server at the moment
[20:19] <stgraber> ok, just disabled them again
[20:20] <cjwatson> slangasek: I haven't checked, but my guess is that the semantics of .sh and non-.sh are different in a way that's meaningful to sysvinit, and somebody wanted the other semantics back
[20:20] <Mithrandir> Keybuk: why good?  You might just buy the cheapest whisky you can get.
[20:20] <ogra> slangasek, i was told live images need a publisher run (usually i'd upload a new -meta, but live doesnt build any binary so publisher should suffice to re-read the live seed)
[20:20] <Mithrandir> .sh vs non-sh is sourced or not, iirc
[20:20] <Keybuk> Mithrandir: if you want to do a good job
[20:20] <keescook> slangasek: .sh is sourced, so exit kills things
[20:20] <slangasek> cjwatson: I understand the difference in semantics between the two :)
[20:20] <Keybuk> maybe that's why I stopped maintaining dpkg, I stopped drinking
[20:20] <slangasek> Keybuk: so put the bits in functions and call "return" instead of "exit"
[20:21] <Keybuk> slangasek: .sh are sourced by sysv-rc so you can't call "exit"
[20:21] <Keybuk> slangasek: that would be a divergence from debian though
[20:21] <Keybuk> for the world's most trivial package
[20:21] <slangasek> Keybuk: yes, I understand the difference in semantics, I want to know why *this* script is flip-flopping
[20:21] <keescook> the changelog isn't clear, but basically they realized they didnt want .sh
[20:21] <slangasek> Keybuk: ok, but surely Debian has the same problem and will want to also fix it?
[20:21] <keescook> (after moving there one before)
[20:21] <Mithrandir> it'd be interesting to spend some time on hacking dpkg to support run-time file registration and such.  Features people have asked about for years and years.
[20:21] <Keybuk> I don't think Debian released their last stable with obsolete support
[20:21] <keescook> I thought debian didn't have obsolete?
[20:22] <Keybuk> (and may not even have it)
[20:22] <Mithrandir> but I think mdz would kill me if I spent a week doing that.
[20:22] <ogra> Mithrandir, dont you have holidays left ?
[20:22] <slangasek> Keybuk: damn, you're right :/
[20:23] <slangasek> Keybuk: er, wait, no - sarge and etch both shipped with procps.sh
[20:23] <Keybuk> yes, but did they ship with a dpkg that had the "obsolete" support patches?
[20:24] <Keybuk> which is what's tickling our internal organs in an upwards direction
[20:24] <slangasek> oh, that bit, hmm.  no idea
[20:24] <Keybuk> I can't even find it mentioned in their changelog
[20:24] <Keybuk> so it may be a patch we're carrying
[20:24] <slangasek>  /etc/init.d/sudo 3ea7480674a8288c36fbac9ef3b26632 obsolete
[20:24] <slangasek> like that
[20:24] <slangasek> ?
[20:25] <Keybuk> yeah
[20:25] <Keybuk>    * Improve processing of disappearing conffiles (Ian Jackson).
[20:25] <Keybuk>      This is part of the fix for #108587.
[20:25] <Keybuk> I guess
[20:25] <Keybuk> dpkg 1.13.14
[20:25] <slangasek> yah, I have obsolete conffiles even on a system that was installed as etch and never had non-stable dpkg on it
[20:26] <slangasek> so I think Debian has the same problem, and it's healthier to just make procps play nice as a .sh?
[20:26] <Keybuk> Debian got the problem on 15 Feb 2006
[20:26] <slangasek> well
[20:27] <slangasek> I guess I don't see evidence of Debian ever having shipped /etc/init.d/procps, so there's no reason that would be recorded as an obsolete conffile
[20:27] <slangasek> so the move would be painless on Debian, but still gratuitous?
[20:27] <Keybuk> yeah, I'm trying to find that too
[20:27] <Keybuk> keescook: when did we have /etc/init.d/procps ?
[20:28] <cjwatson>  * When we take over a Conffile entry from one package to another,
[20:28] <cjwatson>    during unpack, we clear the disappearing flag.
[20:28] <cjwatson> I wonder why the "from one package to another" qualifier is there
[20:28] <keescook> Keybuk: checking...
[20:28]  * Keybuk grabs the dapper package
[20:28] <Keybuk> it's procps.sh in dapper
[20:29] <keescook> hurm.
[20:29] <keescook> it's .sh in all 4 releases
[20:29]  * Keybuk downloads the warty package
[20:29] <cjwatson> warty had procps.sh
[20:29] <Keybuk> someone hold kees down for the forfeit
[20:29] <cjwatson> (I'd already checked that on drescher :))
[20:29] <keescook> so perhaps this'll only be an issue for people that tracked gutsy?
[20:30] <slangasek> some earlier gutsy had /etc/init.d/procps?
[20:30] <Keybuk> it's procps.sh in gutsy
[20:30] <cjwatson> $ for x in /home/lp_archive/ubuntu/pool/main/p/procps/procps_*_i386.deb; do dpkg -c $x | grep etc/init.d/p; done
[20:30] <cjwatson> -rwxr-xr-x root/root      1080 2004-09-14 20:36:01 ./etc/init.d/procps.sh
[20:30] <cjwatson> -rwxr-xr-x root/root      1144 2004-12-08 10:36:04 ./etc/init.d/procps.sh
[20:30] <cjwatson> -rwxr-xr-x root/root      1144 2005-04-21 11:07:13 ./etc/init.d/procps.sh
[20:30] <cjwatson> -rwxr-xr-x root/root      1234 2006-01-23 16:10:19 ./etc/init.d/procps.sh
[20:30] <keescook> slangasek: at some point during gutsy it was procps
[20:30] <cjwatson> -rwxr-xr-x root/root      1226 2006-09-08 16:24:25 ./etc/init.d/procps.sh
[20:30] <cjwatson> -rwxr-xr-x root/root      1208 2007-03-07 21:41:40 ./etc/init.d/procps.sh
[20:30] <cjwatson> -rwxr-xr-x root/root      1208 2007-07-31 09:13:23 ./etc/init.d/procps.sh
[20:30] <cjwatson> -rwxr-xr-x root/root      1208 2007-11-10 16:41:40 ./etc/init.d/procps.sh
[20:31] <cjwatson> there were three procps versions in gutsy, total
[20:31] <slangasek> +  * Remove /etc/init.d/procps Closes: #53818
[20:31] <slangasek> I think that predates Ubuntu altogether though ;)
[20:31] <cjwatson> in 1999
[20:31] <Keybuk> keescook: so, I just grepped through all of the uploads to gutsy, ever :p
[20:32] <Keybuk> they all have procps.sh :)
[20:32] <keescook> wtf, how did I get an obsolete line then?
[20:32] <slangasek> keescook: this must be on the box that you upgraded from slink
[20:32] <slangasek> keescook: did you by any chance /downgrade/ procps at some point?
[20:32] <keescook> but... wouldn't have obsolete tracking not existed then?
[20:33] <Keybuk> slink -> gutsy? :)
[20:33] <slangasek> keescook: oh sure, pick on /that/ detail of my absurd statement
[20:33] <keescook> hehe
[20:33] <cjwatson> keescook: one of the uploads to gutsy was yours - you didn't by chance test a broken version?
[20:33] <cjwatson> (1:3.2.7-3ubuntu3)
[20:33] <keescook> at this point, it must just be my own problem.  no one else has obsolete lines then, I take it?
[20:34] <slangasek> I have one in the opposite direction only
[20:34] <cjwatson> $ grep /etc/init.d/procps /var/lib/dpkg/status
[20:34] <cjwatson>  /etc/init.d/procps.sh 01704631f74e171a0cbb2b084d7c38e8
[20:34] <Keybuk> keescook: nope
[20:34] <Keybuk> so all you have to do is remove procps.sh in preinst
[20:34] <keescook> joy.  most wasted time evar.
[20:34] <slangasek> :)
[20:34] <keescook> *sigh* sorry for the (outstanding amount of) noise
[20:35] <keescook> I will go fix my status file and finish the procps merge.
[20:35] <slangasek> on the bright side, you don't have to get covered in preinst viscera
[20:35] <keescook> hehe
[20:35] <keescook> well, I learned a huge amount during the investigation, that's for sure.
[20:35] <Keybuk> NCC-2007-5678: Incorrect assertions by senior developers can result in significant time loss by the entire team
[20:35] <Keybuk> :-)
[20:35] <keescook> but I'd rather not waste everyone's time on wildly theoretical problems.  :P
[20:35] <keescook> heh
[20:36] <cjwatson> we probably should fix the obsolete conffiles thing before it actually bites us for real, though
[20:36] <keescook> a friend of mine calls this "Stupid Initial Thought"
[20:36] <cjwatson> but, really gone for the evening
[20:36]  * slangasek waves
[20:38] <seb128_> geser: any reason you didn't send this gtk-engines change to Debian?
[20:39] <Keybuk> keescook: are you sure you hadn't just done a test upgrade to a version with /etc/init.d/procps
[20:39] <Keybuk> then downgraded again to a released version?
[20:39] <keescook> Keybuk: that must have happened -- it's the only way I can see getting that line.
[20:40] <keescook> while we're still on procps: you have 2 changelog entries about inotify stuff
[20:40] <Keybuk> yes
[20:40] <keescook> the 2nd seems to say "nah, nevermind", but I still see the max changed
[20:40] <Keybuk> it says nevermind to one of the two
[20:40] <Keybuk> first change adds two sysctl changes
[20:40] <Keybuk> second removes one, and leaves the other
[20:40] <Keybuk> # Increase inotify availability
[20:40] <Keybuk> fs.inotify.max_user_watches = 524288
[20:40] <Keybuk> --
[20:40] <keescook> ah, okay, I never saw what happened in 1:3.2.7-3ubuntu6
[20:40] <Keybuk> is the current state
[20:40] <keescook> right
[20:41] <keescook> okay, merging...
[20:41] <Keybuk> http://patches.ubuntu.com/by-release/atomic/ubuntu/p/procps/
[20:41] <Kmos> why there isn't libbluetooth2-dev ?
[20:42] <Keybuk> Kmos: libbluetooth-dev
[20:42] <Mithrandir> Kmos: why should there be?
[20:42] <Kmos> it comes from bluez-utils right? debian has it.. and we don't have version 2 ?
[20:42] <Kmos> Keybuk: i know that one :)
[20:42] <Kmos> thx
[20:43] <seb128_> Kmos: why do you ask if you know?
[20:43] <Kmos> seb128_: i'm asking why ubuntu don't have version 2 ...
[20:43] <seb128_> that's how it's named
[20:43] <seb128_> because only the lib is versionned
[20:44] <ogra> but not the -dev
[20:44] <seb128_> Kmos: what is your issue exactly?
[20:44] <geser> seb128_: no, simply forgot
[20:44] <ogra> Kmos, so your apps can depend on -dev without caring for the version
[20:44] <slangasek> libbluetooth2-dev is only in Debian stable.  the current dev package is libbluetooth-dev, which is much more reasonable
[20:44] <seb128_> geser: there is a bug open, could you attach the patch and tag it?
[20:45] <seb128_> geser: thanks
[20:45] <Kmos> i understand.. it's better to not have a version on it
[20:45] <Kmos> the bad is debian keep it on version 2
[20:45] <slangasek> no, they don't. read what I just said.
[20:46] <Kmos> slangasek: so packages in debian with version 2 need to cut the version ?
[20:46] <Kmos> in a near future
[20:46] <seb128_> Kmos: it's already done
[20:47] <Kmos> gnokii package on debian still uses version 2 and builds fine
[20:47] <seb128_> Kmos: the name you mention is only used in Debian stable
[20:47] <Mithrandir> Kmos: that's impressive given it's not in testing or unstable
[20:47] <slangasek> libbluetooth-dev in Debian and Ubuntu Provides: libbluetooth2-dev
[20:47] <slangasek> what is the problem you're trying to solve?
[20:48] <slangasek> because I don't see anything broken
[20:48] <Kmos> slangasek: gnokii package in ubuntu need to uses without version
[20:48] <Kmos> in build-depends
[20:48] <seb128_> why?
[20:48] <slangasek> no, it doesn't
[20:48] <slangasek> it /should/, but it's not currently broken if it doesn't
[20:48] <seb128_> there is a Provides there
[20:49] <Kmos> apt-cache showsrc libbluetooth2-dev
[20:49] <Kmos> should give something ?
[20:49] <seb128_> no
[20:49] <geser> seb128_: for adding the tag, is adding "tags 374284 + patch" enough or need I cc control@bugs.d.o?
[20:49] <Mithrandir> geser: don't Cc control@bugs, Bcc it instead.
[20:49] <seb128_> geser: adding that where?
[20:49] <Mithrandir> so it's not there when people do "reply to all"
[20:49] <seb128_> use the bts command line if you have a working mta installed
[20:50] <broonie> but if you do *please* make sure you give it a comment.
[20:50] <broonie> (use BTS, that is)
[20:50] <seb128_> geser: easier is what Mithrandir wrote
[20:50] <geser> seb128_: I wanted to add the control command at the begin of the mail with the patch
[20:51] <Mithrandir> geser: also, do add "thanks" or "kthxbye" to the line below "tags ..."
[20:51] <Mithrandir> so the control bot doesn't try to parse the rest of your mail
[20:55] <geser> Mithrandir: I've seen it in many mails on the Debian MLs but never done it myself before
[20:55] <Mithrandir> geser: sure.  "tags $number + patch\nthanks" is fine.
[20:56] <geser> that's exactly what I've added to the begin of my mail
[20:56] <Mithrandir> and Bcc to control@bugs.d.o and you're set.
[20:56] <Mithrandir> if you screw it up, you can always fix it later.
[20:57] <geser> thanks
[20:57] <Amaranth> Wait, the 'fix' for tracker eating all the inotify watches was to make the watch limit half a million?
[20:58] <Mithrandir> Amaranth: yes.  "fix".
[20:58] <Amaranth> I hope I never have half a million inotify watches
[20:58] <Amaranth> I mean, I know the kernel has some crazy list implementation but that'd still be painful
[20:58] <Mithrandir> no reason for it to be a list
[20:58] <Mithrandir> /dev/sda2                13M    802K     12M    7% /home
[20:59] <Mithrandir> that's the number of inodes used on my desktop.
[20:59] <Mithrandir> good think I don't use tracker.
[20:59] <Keybuk> Amaranth: if you can come up with a better ... ?
[20:59] <Amaranth> Keybuk: I think we need to lock racarr in a room until he finishes his thing
[21:00] <Keybuk> there's already a patch for that on lkml
[21:00] <Keybuk> it comes up most releases
[21:00] <Keybuk> and never gets applied
[21:00] <Keybuk> (I pointed racarr at it at the time)
[21:00] <Amaranth> Ah, right
[21:00] <Amaranth> It never get applied because no one 'important' ever brings it up
[21:00] <Keybuk> http://marc.info/?l=linux-kernel&m=114317090219269&w=2
[21:02] <Keybuk> if tracker was changed to use it and demonstrate it works, then it might have more clout
[22:22] <slangasek> https://iso.qa.stgraber.org/qatracker/build/All is looking a bit fuller
[22:23] <Keybuk> slangasek: all 0/ ? :)
[22:23] <ogra> meh, not in firefox 3.0
[22:23]  * ogra sighs and digs into the guts of the certificate settings again
[22:23] <ogra> grrr
[22:25] <slangasek> Keybuk: the fact that there are images available which people can test, hint :)
[22:25] <Keybuk> slangasek: I'm On Leave :-)
[22:26] <Keybuk> (from my senses)
[22:26] <ogra> mmm, properly sized images :)
[22:38] <stgraber> ogra: just import the CaCert root cert, then everything should go well :)
[22:38] <ogra> stgraber, well, ff 3.0 dropped nearly all UI elements to do that
[22:38] <ogra> thats my prob
[22:39] <ogra> you have to go deeply into the advanced settings to enable a cert
[22:42] <Keybuk> *sigh*
[22:42] <Keybuk> I hate C
[22:42] <Keybuk> printf's %* thing should be type ptrdiff_t not "int"
[22:43] <Keybuk> or size_t
[22:45] <Keybuk> but not int
[22:45] <Keybuk> because then I have to cast ptr - str for 64-bit madness
[22:45] <Chipzz> Keybuk: well, I guess the probability of pointers being more than 2^32 bytes apart is quite slim
[22:46] <Keybuk> I might want to printf a 4GB string
[22:46] <Keybuk> I might
[22:46] <Chipzz> especially in situations where it makes sense to compare them
[22:46] <Keybuk> I'm more annoyed that
[22:46] <Keybuk>  printf ("%.*s", ptr - str, str);
[22:46] <Keybuk> fails to compile on amd64 with -Wall -Werror
[22:47] <Keybuk> since the * bit expects an int
[22:47] <Keybuk> and ptr - str is long int on amd64
[22:47] <Keybuk> *BLAT* the printf!
[22:49] <Keybuk> I blame doko ;)
[22:51] <siretart> Riddell: in dapper, we shipped ALL plugins in libxine1. We now seperated them, but for upgrade purposees, libxine1 must depend on libxine1-gnome to not introduce regressions and conform to policy
[22:52] <slangasek> Keybuk: you blame him for C, or for 64-bit archs?
[22:52] <ogra> for every evil in the world ?
[22:54] <Keybuk> both
[22:58] <nxvl_work> did the tribe 1 iso is somewhere to download it?
[22:59] <somerville32> Tribe 1 ISO? Why would you want that?
[22:59] <nxvl_work> s/tribe/alpha/
[22:59] <nxvl_work> somerville32: testing proposes
[23:02] <ogra> nxvl_work, https://iso.qa.stgraber.org/qatracker/build/All
[23:02] <nxvl_work> ogra: thnx
[23:03] <pawalls> ubotu, help
[23:03] <ubotu> I am ubotu, all-knowing infobot. You can browse my brain at http://ubotu.ubuntu-nl.org/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
[23:06] <Keybuk> !ati
[23:06] <ubotu> To install the Ati/NVidia drivers for your video card, see https://help.ubuntu.com/community/BinaryDriverHowto
[23:06] <Keybuk> oh god, it speaks ;)
[23:06] <Keybuk> (and is violating the IRC RFC there by replying in /MSG)
[23:07] <Keybuk> !hi
[23:07] <ubotu> Hi! Welcome to #ubuntu-devel!
[23:07] <ogra> well, its used in #ubuntu mainly
[23:07] <ogra> you dont want in line replies with the heavy traffic over there
[23:07] <Keybuk> !ogra is looks like a pirate :-)
[23:07] <ogra> lol
[23:07] <ogra> arrrr
 Your edit request has been forwarded to #ubuntu-ops.  Thank you for your attention to detail
[23:07] <Keybuk> lol
[23:08] <ion_> keybuk: I’ve complained about the PRIVMSG thing before. :-)
[23:09] <somerville32> Some people have trouble having a conversation without ubotu
[23:10] <Keybuk> !ohmy somerville32
[23:10] <ompaul> !ohmy | somerville32
[23:10] <ubotu> somerville32: Please watch your language and topic to help keep this channel family friendly.
[23:10] <Keybuk> heh
[23:10] <somerville32> : O
[23:10] <ompaul> Keybuk, you got him speaking out of turn
[23:10] <Keybuk> I wondered what that would do
[23:11] <Keybuk> I just found a list of ! thingies
[23:11] <ompaul> Keybuk,  /msg ubotu search foo and have fun
[23:11] <somerville32> !botsnack | keybuck, you're
[23:11] <ubotu> keybuck, you're: Yum! Err, I mean, APT!
[23:12] <Keybuk> we should have a !notasupportchannel or something
[23:12] <Keybuk> though isn't the fact you have to say these things in public a bit of a silly thing?
[23:12] <ion_> Buck? :-)
[23:12] <ion_> Where does your nick come from, btw?
[23:12] <Keybuk> since then you may as well just say what you were going to say anyway
[23:12] <Keybuk> instead of getting the bot to say it on your behalf
[23:12] <Chipzz> Keybuk: how about: "please read the topic"
[23:12] <Keybuk> that's a bit like
[23:12] <Keybuk> ogra: please tell ubotu that this isn't a support channel
[23:12] <somerville32> Keybuk, !goaway takes less time to type :P
[23:12] <ion_> I’ve suggested making ChanServ tell people to read the topic on join.
[23:12] <Chipzz> ion_: heh. excellent idea
[23:12] <Keybuk> somerville32: and this is why we got macros in our irc clients
[23:13] <Keybuk> ion_: google keybuk.com
[23:13] <PriceChild> !support-#ubuntu-devel The official ubuntu support channel is #ubuntu. Please be aware that this channel is for Ubuntu Development only. (also read /topic)
[23:13] <ubotu> I'll remember that, PriceChild
[23:13] <Keybuk> http://www.geocities.com/rick_lively/MANUALS/FILELIST/MSDOS/321.HTM
[23:13] <PriceChild> How's that?
[23:13] <ogra> Keybuk, i have no influence on the bot ...
[23:13] <Chipzz> ion_: an even better idea imho: make channel moderated, have chanserv notice the users on joining, and give users voice after 30 secs or something
[23:13] <pawalls> Is this a bad channel to ping developers about untouched (security) bugs that include a patch?
[23:13] <Chipzz> or is that over the top? :P
[23:14] <ion_> keybuk: Ah, ok. :-)
[23:14] <slangasek> PriceChild: that is... an instance of the exact thing Keybuk is saying is silly?
[23:14] <pawalls> Or is it more of a "Yeah.. go wait at the end of the line" issue? ;)
[23:14] <Keybuk> pawalls: not especially, though you might want to just ping keescook directly
[23:14] <keescook> pawalls: which one do you mean?
[23:14] <pawalls> ubotu, bug 164231
[23:14] <ubotu> Launchpad bug 164231 in linux-source-2.6.22 "NFS regression causes subsequent mounts from same superblock to silently use previous mount options" [High,Triaged] https://launchpad.net/bugs/164231
[23:14] <pawalls> keescook, ^
[23:15] <somerville32> Ummm... Where is the Xubuntu desktop cd on Ubuntu QA?
[23:15] <keescook> pawalls: yup, we're aware of it -- the next kernel release will have it fixed most likely.
[23:15] <pawalls> keescook, Excellent! :)
[23:15] <keescook> :)
[23:15] <Keybuk> there should be an opposite of +v
[23:15] <pawalls> keescook, Sounds great. Just was curious because no one had commented on the bug.
[23:15] <keescook> pawalls: I'll poke the kernel team again.
[23:15] <pawalls> Keybuk, mode +m ? ;)
[23:15] <PriceChild> Keybuk, +q
[23:16] <pawalls> keescook, Thanks a lot.
[23:17] <pawalls> keescook, Feel free to have them ping me here if they have any questions about the patch, or need help reproducing. I'm watching the bug like a hound, but just in case... ;)
[23:17] <Keybuk> actually, that'd stop it working on bug replies, damn
[23:17] <keescook> pawalls: okay, thanks
[23:17]  * ogra doesnt have a clue who maintains the bot since seveas is gone
[23:17] <ion_> pawalls: I got a chuckle out of the wording. :-)
[23:17] <somerville32> Seveas is gone?
[23:17] <Keybuk> ion_: there's a story attached, but it's not interesting
[23:17] <ion_> (Admittedly, i’m tired.)
[23:18] <jdong> ion_: shhh not that kind of reproducing.... ;-)
[23:18] <pawalls> ion_, Hahah... indeed ;)
[23:18] <jdong> but... what's the patch for? :D
[23:18] <PriceChild> ogra, sev still maintains him.
[23:19] <pawalls> jdong, Well, you can only reproduce *before* you've applied the patch ;)
[23:19] <Keybuk> !ogra is looks like a pirate :-)
[23:19] <jdong> pawalls: and also after it's been removed. Boy a patch like that would make you rich :)
[23:19] <ogra> arrrr
[23:19] <Keybuk> yay
[23:20] <Keybuk> !ogra
[23:20] <ubotu> ogra looks like a pirate!
[23:20] <Keybuk> ;-)
[23:20] <ogra> heh
[23:21] <ogra> hmm, now you deletedt the entry they had set in #edubuntu for !ogra
[23:22] <ogra> (cant remember what that was though ... not important .. but apparently its changing it globally)
[23:22] <Keybuk> blame mneptok ;
[23:22] <Keybuk> ;)
[23:23] <ogra> he's always good to blame :)
[23:23] <somerville32> !ogra-#edubuntu
[23:23] <ubotu> Sorry, I don't know anything about ogra-#edubuntu - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[23:23] <Keybuk> there wasn't an ogra on there before
[23:24] <PriceChild> Nothing was overwritten.
[23:24] <ogra> hmm
[23:24] <ogra> might have been the edubuntugirl bot then and i misremembered
[23:28] <somerville32> Who looks after QA - ISO Testing? Henrik?
[23:30] <_MMA_> somerville32: AFAIK yes.
[23:30] <somerville32> I noticed that the Xubuntu desktop images aren't listed on Ubuntu QA - ISO
[23:30] <slangasek> somerville32: Xubuntu desktop CD isn't on Ubuntu QA because it's not had a successful build
[23:30] <somerville32> Ah
[23:31] <slangasek> livefs build failure, apparently
[23:31] <slangasek> I'll look into it in a few
[23:31] <somerville32> Where are the logs again?
[23:31] <slangasek> I don't know that the logs are mirrored publically
[23:32] <ogra> they are
[23:32] <ogra> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
[23:32] <slangasek> well, it's a livefs build failure, and I don't know that those are mirrored publically :)
[23:33] <somerville32> Is there a notification system for build failures?
[23:33] <Keybuk> you get mailed them if you caused them
[23:33] <Keybuk> (package builds, anyway)
[23:34] <somerville32> mv: cannot stat `/srv/cdimage.ubuntu.com/scratch/xubuntu/daily-live/tmp/hardy-i386/CD1/casper/filesystem.kernel-generic': No such file or directory
[23:34] <ogra> slangasek, right the livefs logs are not public ... i think they were once
[23:35] <ogra> somerville32, thats normal
[23:35] <somerville32> ogra, Pretty sure I saw them the other day
[23:35] <slangasek> E: Couldn't find package libgoffice-gtk-0-4
[23:35] <slangasek> somerville32: ^^ that's the livefs build failure on i386
[23:35] <somerville32> slangasek, Right, we changed the seeds to use 0-5
[23:35] <slangasek> changed when?
[23:36] <somerville32> Yesterday morning
[23:36] <slangasek> morning by which timezone? :)
[23:37] <ogra> and did you change it in the live seed or in desktop ?
[23:37] <ogra> desktop needs a -meta rebuild
[23:37] <slangasek> it had one
[23:37] <ogra> ah
[23:37] <slangasek> just checked that
[23:37] <slangasek> so I'll retry the livefs build, if it still fails we'll have to backtrack
[23:38] <somerville32> thanks
[23:39] <somerville32> So the link you gave me is for what logs?
[23:39] <somerville32> These are different then the ones I saw yesterday
[23:42] <slangasek> somerville32: the logs ogra linked to are the CD build logs, which show a failure because the livefs build failed before it
[23:43] <somerville32> I saw the livefs logs yesterday. Where are they located?
[23:43] <slangasek> I don't know
[23:43] <slangasek> a fresh livefs build has failed with the same libgoffice-gtk-0-4 error, though
[23:43]  * slangasek tries something new
[23:44] <somerville32> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs it seems
[23:44] <slangasek> ok
[23:45] <slangasek> hmm, well, the logs there are two cycles out of date, and I can't really help with that :)
[23:46] <torahteen> Hey, who's here?
[23:46] <torahteen> I'm reading about buffer overflows
[23:47] <torahteen> So I made a simple little program, and compiled it. The point of the program being to change the return address of a program to skip the statement after the call.
[23:47] <torahteen> I ran it... and got:
[23:47] <torahteen> *** stack smashing detected ***: ./example2 terminated
[23:47] <torahteen> Aborted
[23:47] <torahteen> -_- Any way to disable this?
[23:47] <crimsun> -fno-stack-protector
[23:48] <torahteen> Where? As a gcc arg?
[23:48] <ogra> yep
[23:49] <torahteen> Ah, ok... welp didn't get the right address apparently, but thanks anyway
[23:49] <torahteen> Ok, quick Q... my asm is rusty... MOV x,y will put the value of y into x?
[23:49] <torahteen> Or other way around?
[23:50]  * ogra points to topic ....
[23:50] <pawalls> keescook, Crap.. I forgot to ask. Do you think there's any possibility that the fix will actually make it into Gutsy ever?
[23:50] <torahteen> Oops... a'ight sorry
[23:50] <torahteen> *sigh*
[23:51] <keescook> pawalls: yup, certainly -- that's what I meant by "update" (security update for feisty, gutys)
[23:51] <pawalls> keescook, Excellent!
[23:51] <pawalls> keescook, Thanks.
[23:51] <keescook> np :)
[23:53] <AlinuxOS> ყველას კარგი გამარობა!
[23:53] <Fujitsu> keescook: Did my attempted merge request on LP do any emailing?
[23:53] <AlinuxOS> კარგი გამარჯობა უფრო სწორედ :)
[23:53] <pochu> AlinuxOS: agreed.
[23:54] <AlinuxOS> pochu, ah good ძალიან კარგი :)
[23:54] <pochu> :-)
[23:54] <keescook> Fujitsu: hurm, if so, it got very filtered...
[23:54] <Fujitsu> keescook: I'm not sure if it's meant to generate email, but I'm not sure I see the point of it otherwise.
[23:55] <keescook> Fujitsu: it's possible I lost it, but I'll pull a merge regardless.  ;)
[23:55] <Fujitsu> keescook: Danke.
[23:56] <slangasek> AlinuxOS: uh, why are you expecting people in #ubuntu-devel to speak Georgian?
[23:57] <AlinuxOS> slangasek, simply test ;)
[23:58] <keescook> Fujitsu: for future notes, prepend your nick, " Fujitsu> wordpress upstream has advised that their version is not affected."
[23:59] <Fujitsu> keescook: Sure, sorry. I noticed that people were doing that this morning after I got a lot of diffs in the mail.