[00:38] <mathiaz> slangasek: do you know which libc is used in the installer environment?
[00:38] <slangasek> glibc
[00:39] <mathiaz> slangasek: apparently getpwuid is not working properly
[00:39] <mathiaz> slangasek: in the installer environment
[00:39] <slangasek> the nss modules may not be there
[00:39] <kirkland> slangasek: this test program doesn't work in jaunty alpha1: http://people.ubuntu.com/~kirkland/test.c
[00:39] <mathiaz> slangasek: however it ^^ works in interpid
[00:40] <slangasek> there's a separate udeb, libnss-files-udeb, that contains ./lib/libnss_files.so.2; is that present in the image?
[00:41] <mathiaz> slangasek: hm - no
[00:41] <mathiaz> slangasek: only libnss_dns.so.2
[00:41] <slangasek> well, there's the problem then :)
[00:42] <slangasek> I'm not sure whether there's anything else in the installer that cares about nss_files by default, though?
[00:42] <mathiaz> slangasek: awesome - works!
[00:42] <kirkland> slangasek: anna-install libnss-files-udeb fixes it ;-)
[00:42] <slangasek> sure
[00:42] <kirkland> slangasek: we're working on iscsi at the moment
[00:42] <slangasek> and that needs uids in the installer environment (as opposed to within the target chroot)?
[00:42] <kirkland> slangasek: and we've got a failure somewhere in there related to a b0rked getpwuid() call
[00:43] <kirkland> slangasek: well, the source code thinks it does, anyway ;-)
[00:43] <kirkland> slangasek: the iscsid daemon has to be running
[00:43] <kirkland> slangasek: for the iscsiadm target discovery to work
[00:43] <kirkland> slangasek: the iscsid does some getpwuid() checking
[00:44] <slangasek> ah, and that has to be run in the installer rather than the target in order to support install-to-iscsi, hmm
[00:44] <kirkland> slangasek: right, needed to establish the scsi device
[00:44] <ogra> kirkland, iscsi ? fixing the ftbfs on armel for us ? :)
[00:45] <kirkland> slangasek: okay, so shall we just add a depends in the open-iscsi-udeb on libnss-files-udeb?
[00:45] <kirkland> ogra: :-P
[00:45] <mathiaz> ogra: doko fixed it
[00:45] <kirkland> ogra: i'm sure all the armel customers out there are just dying to run with root on iscsi :-)
[00:45] <ogra> mathiaz, oh, right :)
[00:45] <slangasek> kirkland: that would do it, though I wonder if it wouldn't be more technically correct to remediate iscsid's uid checks
[00:46] <kirkland> slangasek: what's the alternative?
[00:46] <kirkland> slangasek: slashing them?
[00:46] <slangasek> probably? :)
[00:46] <ogra> kirkland, why not ? ARM is the perfect HW to cluster NAS arrays :)
[00:46] <mathiaz> ogra: BTW are there any chroot available?
[00:46] <mathiaz> ogra: for arm
[00:47] <ogra> mathiaz, nope, we dont have enough HW yet, i have a board here if you need a testbuild
[00:47] <kirkland> ogra: how's qemu's armel support?
[00:47] <mathiaz> ogra: ok - doko's patch may not be needed anymore with the new upstream version of open-iscsi
[00:47] <ogra> but the buildd machines are still busy building the archive ... and after that we'll need them for livefs builds
[00:48] <mathiaz> ogra: but I don't know how to test it
[00:48] <ogra> kirkland, bad for what we target ... ok for more common arm platforms
[00:49] <ogra> i think qemu has support up to armv5 we're targeting armv7
[00:49] <ogra> though armv5 should suffice for bare testing
[00:49] <persia> No, that's not the issue.
[00:49] <persia> The problem is that qemu targets armeb, and we have armel
[00:50] <ogra> ah, right
[00:50] <ogra> well, whats scratchbox running then ?
[00:50] <ogra> i thought they use armel
[00:50] <persia> armv5 vs. armv7 is just having a couple lipcap libraries, or worst-case, parallel installs (a la libc6-i686)
[00:50] <persia> No, armeb
[00:51] <ogra> hmm, isnt the n8x0 omap2 ?
[00:51] <ogra> that should be armel
[00:51] <ogra> and scratchbox targets the n8x0
[00:52] <persia> omap2 doesn't require armel.
[00:52] <ogra> ah
[00:52] <persia> See http://qemu-arm-eabi.wiki.sourceforge.net/ for work-in-progress
[00:54] <ogra> ah, right
[00:54] <ogra> well, i bootstrapped my initial rootfs for the evm board in qemu-arm
[00:54] <ogra> (not -eabi though)
[00:55] <persia> Some of the patches were going upstream.  I haven't tested the latest.
=== Pici` is now known as Pici
[00:59] <ogra> anyway, i'll better go to get some sleep now ... else i'll miss my train
[00:59] <ogra> night
[01:03] <lifeless> persia: what was the session you wanted me at?
[01:06] <persia> Well, we were discussing https://blueprints.launchpad.net/ubuntu/+spec/archive-reorganization , but it might be a bit strong to say I wanted you there, rather that I thought you might be interested based on your thoughts on the model.
[01:08] <persia> kirkland, Is armel support included in any of the svn snapshots for the current qemu?
[01:08] <kirkland> persia: i haven't checked
[01:09] <persia> kirkland, OK.  I'm not sure of the upstream status, and saw the svn pull and hoped.  I suppose I ought install jaunty on something.
[01:10] <kirkland> persia: :-D
[01:10] <kirkland> persia: i'll check for you later tonight
[01:10] <kirkland> persia: i merged qemu from debian;  soren merged from svn shortly thereafter
[01:10] <persia> kirkland, Hrm?  That doesn't match the changelogs I see, and now I'm confused.
[01:11] <persia> I see svn snapshots in Debian experimental, and a changelog with your name claiming a merge from Debian unstable (but it looks like a merge from experimental)
[01:12] <kirkland> persia: I uploaded 0.9.1-7ubuntu1, -- Dustin Kirkland < kirkland@canonical.com>   Thu, 20 Nov 2008 18:10:36 -0600
[01:12] <kirkland> persia: soren uploaded 0.9.1+svn20081112-1ubuntu1, https://edge.launchpad.net/ubuntu/+source/qemu/0.9.1+svn20081112-1ubuntu1
[01:13]  * persia fails at diff-reading
[01:14] <kirkland> persia: i, too, dislike the fact that Launchpad drops the uploader from the changelog of the last entry at https://edge.launchpad.net/ubuntu/+source/qemu
[01:15] <persia> At one point it listed it, but it was removed in response to a bug about it usually getting it wrong.
[01:15] <persia> (for various values of "it")
[01:16] <persia> I think the plan was to take a deeper look at the concept of "Changed-By" and "Last Changelog By", but that probably awaits the next UI changes.
[01:17] <kirkland> persia: i am a little puzzled why soren's upload "replaced" my changelog entry ... http://launchpadlibrarian.net/19890588/qemu_0.9.1-7ubuntu1_0.9.1%2Bsvn20081112-1ubuntu1.diff.gz
[01:17] <kirkland> persia: oh, wait, nevermind ... it's further down in the diff
[01:18]  * kirkland fails at diff-reading, too
[01:20] <persia> kirkland, That's just the format.  Scroll down to 0.9.1-7ubuntu1 (confusingly underneath 0.9.1+svn20080822-1 )
[01:20] <persia> I suspect the version issues are related to the branching on the Debian side : it would be less confusing if there was a common parent between your merge and soren's.
[01:22] <calc> pitti: you there?
[01:23] <FAJ> hi, i am trying to set up a ppa, but am having difficulties with signing the ubuntu code of conduct...
[01:24] <FAJ> can anyone help?
[01:24] <FAJ> It says that there is no public key?
[01:25] <Hobbsee> try #launchpad
[01:25] <persia> FAJ,
=== j1mc is now known as j1mc|away
[01:46] <slangasek> kirkland: ok, so open-iscsi uses getpwuid for peercred validation... it's questionable because they're hard-coding a check against "root" instead of just hard-coding one against uid 0, but probably non-trivial to correct, might as well just add the udeb dep :)
=== j1mc|away is now known as j1mc
=== nhandler_ is now known as nhandler
=== nhandler_ is now known as nhandler
[04:27] <elpargo> hi, anyone knows if they are any plans to upgrade firebug in ubuntu -1
[04:27] <elpargo> lastest package is a version from svn due to a bug.
[04:29]  * Hobbsee wonders what ubuntu -1 is, as she heads out
[04:37] <elpargo> Hobbsee, 8.04 :)
[05:46] <kirkland> slangasek: so we came to the same conclusion, independently ...  the "root" string check vs. "0" uid check is kinda dumb...
[05:46] <kirkland> slangasek: but, ultimately, open-iscsi-udeb already depends on the lib-nss-files packages
[05:47] <kirkland> slangasek: mathiaz and i brought this problem on ourself, though, in testing the installer
[05:47] <kirkland> slangasek: we were udpkg -i 'ing our own new open-iscsi udeb
[05:47] <kirkland> slangasek: rather than anna-install'ing the open-iscsi-udeb already on the cd
[05:47] <kirkland> slangasek: so we hadn't pulled the dependencies
[05:47] <kirkland> lose.
[06:08] <slangasek> kirkland: ah :)
[06:08] <kirkland> slangasek: yeah.  doh.  sorry for your cycles :-)
=== tkamppeter_ is now known as tkamppeter
[09:02] <fabbione> doko_: ping?
[09:04] <doko_> fabbione: pong
[09:07] <fabbione> doko_: what's up? i saw your ping this morning
[09:08] <doko_> fabbione: sparc ... can you reproduce the build failures of gcc-4.1/gcc-4.2 locally?
[09:09] <fabbione> doko_: i haven't built gcc.. but I can try
[09:09] <fabbione> doko_: what release? what chroot? info please? :)
[09:10] <doko_> fabbione: jaunty
[09:10] <fabbione> doko_: ok.. i'll give it a shot when I can
[09:18] <soren> kirkland: My changelog entry didn't replace yours. It's just diff(1) being confusing. Both of our entries were at the top and they looked similar, so diff shows it as though mine replaced yours and then added yours again further down. Check the final changelog.
[09:19] <soren> kirkland: If you already worked that out, sorry. On this internet connection, even just scrolling back through irc logs is painful :)
[09:19] <fabbione> soren: everything working like a charm now! thanks for the help the other day
[09:19] <soren> fabbione: Ay time, dude. Glad to hear it.
[09:20] <soren> any time, even.
[09:20] <fabbione> soren: eheh
[09:20] <fabbione> i just wish virt-manager was a bit more mature to configure machines from remote
[09:20]  * soren nods
=== doko_ is now known as doko
[12:20] <kirkland> soren: yep, figured that out eventually :-)  sorry
[12:38] <soren> kirkland: No worries.
=== nhandler_ is now known as nhandler
=== Trewas666 is now known as Trewas
=== nenolod is now known as moogle
[14:02] <asac> doko: how can #pragma GCC diagnostic ignored "-Wstrict-prototypes"
[14:03] <asac> be made apply to only a few lines ... or how to unset that if its in a header (so its restricted to that header at least)
[14:08] <doko> asac: see the gcc-4.3 manual, section 5.52.9 Diagnostic Pragmas
[14:12] <asac> doko: link?
[14:13] <doko> asac: apt-get install gcc-4.3-doc
[14:13] <asac> doko: i can see how i can change it explicitly to warning again. but how can i reset to the "default"?
[14:14] <asac> or is "warning" default?
[14:14] <doko> asac: probably depends on the options used to run gcc. I don't know
[14:15] <asac> doko: yeah. i guess warning is correct
[14:29] <hunger> Any idea why the kdegames stuff build on LP yesterday is not in the archives yet?
[14:29] <hunger> other kde stuff build later is available:-(
[14:30] <hunger> Is it possible that kdegames (and others) contain new debs that require it to get ok'ed before going into the archives?
[14:31] <NCommander> hunger, yeah
[14:31] <hunger> Could somebody please OK it then?
[14:32] <persia> hunger, It is possible.see https://launchpad.net/ubuntu/jaunty/+queue
[14:32] <persia> The archive admins review that every couple days, and tend to push things through as long as the changes are sensible.
[14:33]  * hunger sighs.
[14:33] <hunger> Currently I can not even start the unholy mix of kde 4.2 and 4.1 in the archives:-(
[14:33]  * NCommander sighs
[14:33] <NCommander> Binary NEWs
[14:33] <NCommander> I still don't know if thats a feature or a bug
[14:34] <persia> Definitely a feature.
[14:34] <ScottK-laptop> https://launchpad.net/ubuntu/jaunty/+queue?queue_state=0&queue_text=kde
[14:37] <NCommander> Ok, finally
[14:37] <NCommander> kde4bindings built
[14:37] <NCommander> YAY!
[14:37] <NCommander> er
[14:37] <NCommander> kde4libs built and installed
[14:46] <bigon> I have 4 pkg (compiz-fusion-plugins-main libv4l-0 system-cleaner system-cleaner-gtk) installed on my machine (running jaunty since yesterday) that have higher version in intrepid than jaunty :/
=== nhandler_ is now known as nhandler
[15:03] <liw> bigon, system-cleaner was updated in hardy to fix some serious bugs, I'll have an update for intrepid as well in the near future, sorry about the confusion
[15:03] <hunger> Any archive admins around who can push the kde beta stuff through the new queue?
=== LucidFox is now known as Sikon_Stargate
=== kirklan`` is now known as kirkland
=== The_Company is now known as Company
[15:48] <allquixotic> Hello. I'm looking for approval to do an SRU for a main package in Intrepid. I've filed a bug yesterday and am now informally poking anyone interested to take a look and provide feedback, please. :) https://bugs.launchpad.net/ubuntu/+source/libshout/+bug/304843
[15:49] <ubottu> Ubuntu bug 304843 in libshout "SRU Request: libshout3 in intrepid" [Undecided,New]
=== Sikon_Stargate is now known as LucidFox
=== robbiew1 is now known as robbiew
[16:32] <lifeless> I have a weirdness removing a kernel package, what package should I file the bug on?
[16:35] <persia> lifeless, What sort of weirdness?
[16:36] <persia> (and #ubuntu-bugs is generally a better forum for this class of question)
[16:40] <lifeless> persia: regenerating initramfs for the thing being removed
[16:42] <persia> I'd file that against "linux", although I suspect it's because there's still some modules package left unpurged.  Probably useful fodder for the kernel packaging UDS session next week.
[16:42] <lifeless> its related to a linux-restricted-modules removal bug I found too
[16:42] <lifeless> which is that if someone has removed a kernel by hand
[16:42] <lifeless> removing the lrm package blows up on System.map missing
[16:43] <persia> Well, that's arguably a case of someone shooting themselves in the foot, but it's all part of the same collection of scripts to generate maintainer scripts for the kernel packages.
[16:44] <lifeless> persia: not really, lrm can be configured but no installed
[16:44] <lifeless> you can't drop it to purged without having the system.map present :P
[16:46] <persia> Ah.  I had thought that was part of the configuration, but if not, then certainly a bug.
[16:46] <lifeless> I have a bunch of lrm packages that are state 'c' and can't be removed
[16:47] <lifeless> I suspect its unusual to get this way, but once here its wedged
[16:47] <persia> I suspect you'd have to either install the relevant kernels (or at least configure them), or fake it.
[16:47]  * StevenK returns from breakfast, disenheartened.
[16:47] <lifeless> oh, I had them installed
[16:54] <pitti> calc: HI
[16:59] <Chipzz> persia: I would say it's not someone shooting themselves in the foot. lrm should depend on the corresponding kernel, and hence be removed when the kernel gets removed
[16:59] <Chipzz> simple matter of dependencies\
[17:00] <Chipzz> unless by "shooting themselves in the foot" you mean dpkg -P --force-all the corresponding linux kernel :P
[17:01] <persia> Chipzz, I mean simply rm -f /boot/vmlinuz-${whatever}
[17:25] <apw> superm1, you about?
[17:26] <apw> superm1, i have a debdiff against dkms and it looks like you are the man to talk to about getting it applied
[17:28] <superm1> apw, yeah i just saw it on kernel-team.  i just added it to trunk, go ahead and upload it to jaunty too
[17:29] <apw> oh is there a spearate tree for it somewhere?
[17:30] <superm1> apw, only dell employees have access to the git tree
[17:30] <superm1> apw, so normally submitting patches to dkms-devel ML is the way to go, but i happen to be on kernel-team ML too, so this works
[17:31] <apw> superm1, thats my bad for not looking for the upstream
[17:31] <superm1> apw, er you don't have core-dev rights do you.  do you need a sponsor then for that patch into jaunty?
[17:31] <apw> superm1, any reason for it not to be externally accessible, the git tree?
[17:31] <apw> superm1, nope, no upload privs here, a sponsor would be great
[17:32] <superm1> my bad, it's accessible at linux.dell.com, just only writable by internal
[17:32] <apw> oh then that makes complete sense
[17:32] <superm1> http://linux.dell.com/git/?p=dkms.git;a=summary
[17:32] <apw> and my bad for not noticing it, i assume its int he control file
[17:32] <superm1> apw, okay i'll sponsor it for you in jaunty then.
[17:32] <apw> yep there it is, my bad
[17:33] <apw> how does that work then, this is my first time (upload virgin)
[17:33] <superm1> apw, no problem. i'll just grab that patch out of the email and do the upload for it.  you've got it right with a debdiff in the email
[17:33] <superm1> is there a bug opened for this though?
[17:33] <apw> yes bug #300773, referenced in the diff
[17:34] <ubottu> Launchpad bug 300773 in linux "Removal does not clean up after dkms, l-r-m(?)" [Medium,In progress] https://launchpad.net/bugs/300773
[17:34] <apw> in the debian/changelog entry i mean
[17:34] <superm1> ah i read right past it.
[17:34] <apw> oh hrm, that debdiff is against intrepid, do i need to make a new one against jaunty
[17:35] <apw> and how indeed do i get the jaunty source ... hmmm ... /me goes find out
[17:35] <superm1> no it's okay. it's a small change, s/intrepid/jaunty i'll just do and upload
[17:36] <superm1> apw, but you've got it right putting the debdiff on the bug and grabbing the main uploader or a main sponsor, so good job with that :)
[17:36] <apw> so how does one get the source for a non-'the one i am running' system
[17:36] <apw> superm1, one tries.  have to learn somehow and bugging people seems to work :)
[17:37] <superm1> apw, so it turns out the same version is in jaunty and intrepid.  you can look here:  https://edge.launchpad.net/ubuntu/+source/dkms
[17:37] <apw> so it is
[17:37] <superm1> apw, if that wasn't the case, then you could grab the orig.tar.gz and such from launchpad, or you could add a jaunty deb-src entry to sources.list
[17:38] <apw> ahh i can add just the jaunty deb-src's can i, and then i can use t
[17:38] <apw> the =version to get the jaunty one i guess
[17:38] <apw> superm1, ok, as its the same version i wonder if we should SRU it to Intrepid
[17:39]  * apw is in two minds, its such a small mess made against its pretty simple to fix
[17:39] <superm1> apw, up to you.  i think with such a simple fix an SRU does make sense
[17:40] <superm1> so you can nominate it to intrepid on that bug, and then follow the SRU process at https://wiki.ubuntu.com/StableReleaseUpdates
[17:40] <apw> well i guess then i'll take it under advisement, in that it only makes sense to bother with that if we also fix the kernel issues there too
[17:40] <apw> so we can have that discussion on the kernel-list in tandem for both
[17:43] <superm1> what's the kernel side of the issue?
[17:54] <apw> the kernel makes a mess in the /lib/modules/<version> too
[17:54] <apw> not cleaning out some of the depmod information
[17:54] <apw> so that also stops the directory going away when the modules are deinstalled
[17:54] <superm1> apw, so another comment about uploading methodolgies, don't worry about sending patches for packages that are not within the kernel team's direct responsibility (linux,linux-meta,lrm,etc) to kernel-team ML.
[17:54] <superm1> ah i see
[17:55] <superm1> but for those other packages, i'm not sure the kernel-team ML policy.  i thought it was just for SRU's they all needed ack'ing, but perhaps that's changed
[17:55] <apw> superm1, yeah it seemed appropopriate to send it there too as it was a fix for a problem the kernel people were seeing
[17:56] <apw> yeah ... as its jaunty it probabally can just be shoved in, but it does change the semantics of when we remove them so some discussion may be appropriate
[17:56] <apw> and frankly even if i was jsut going to commit it, it being in the logs and recorded seems appropriate
[17:56] <superm1> right
[17:56] <apw> i am not used to not sending it somewhere ... too much kernel work in the community
[17:56] <apw> superm1, so does dkms only build on i386?
[17:57] <superm1> apw, it only builds on one architecture because it's arch all.  that means the same binary package works on all architectures
[17:57] <kees> doko: isn't bug 305176 just a complaint about -D_FORTIFY_SOURCE=2 ?
[17:57] <ubottu> Launchpad bug 305176 in glibc "[PR25509] can't disable __attribute__((warn_unused_result))" [Unknown,Confirmed] https://launchpad.net/bugs/305176
[17:57] <apw> ahh i see, and that doesn't appear as 'generic' it just appears as i386 or something
[17:59] <doko> kees: no, just the question why this attribute is set for fwrite, and not for fprintf/printf
[18:01] <kees> doko: okay, fair enough.
[18:07] <Tuju> we're packaging fonts to ubuntu, should we use defoma or is that being removed?
[18:08] <slangasek> defoma is not being removed, TTBOMK?
[18:09] <Goodi> bug #279824 seems to indicate that
[18:09] <ubottu> Launchpad bug 279824 in update-manager "ionice Update Manager" [Wishlist,Triaged] https://launchpad.net/bugs/279824
[18:11] <Goodi> well.. not that :)
[18:13] <Goodi> on debian side -  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=279824
[18:13] <ubottu> Debian bug 279824 in perlftlib "O: perlftlib -- Perl module for the FreeType library" [Normal,Closed]
[18:14] <Goodi> the defoma-hints program is broken since the perlftlib was dropped
[18:19] <slangasek> well, that implies someone's doing a bad job of maintaining it, but doesn't say anything about it being removed
[18:21] <Goodi> slangasek - jep, but it's been like that for a long time... just makes me wonder how we're actually supposed to use defoma if I can't create new font hintfiles...
[18:22] <slangasek> Goodi: hmm, I'm afraid I don't know, I'd never heard of defoma-hints before and didn't recall that this was something that had to be run as part of setting up defoma
[18:22] <Goodi> and what's the big deal with the hintfiles anyway... it's not needed in fedora/rhel.
[18:23] <Goodi> all the *ttf* fontpackages seem to use defoma
[18:23] <Goodi> slangasek - then there might be some other way ... but what it would be
[18:23] <NCommander> Nice codeblocks got rejected
[18:23] <NCommander> -_-;
[18:25] <StevenK> NCommander: "U looz"
[18:25]  * NCommander whacks StevenK with his ARM board
[18:25] <StevenK> Which is currently, 11,000 km from me
[18:25] <NCommander> o_o?
[18:25] <Nafallo> ...details
[18:26] <StevenK> It's in Sydney, and I'm not.
[18:26] <lifeless> WTB: 1 suborbital arm whacking launcher
[18:27] <Goodi> and the defoma-hints segfaults with OTF (opentype) fonts on gutsy (which do have the perlftlib)
=== azeem_ is now known as azeem
[19:19] <wasabi> heh. wow. i can't eject this CD from the drive.
[19:19] <wasabi> it keeps trying to remount itself.
[19:21] <slangasek> with or without the tray opening?
[19:21] <jdong> lol isn't this a known bug?
[19:21] <jdong> press the eject button like there's no tomorrow, you'll get the timing right eventually :D
[19:22] <slangasek> there was a known, release-noted bug in Ubuntu 8.10 about this, yes; the fix is in intrepid-updates
[19:23] <slangasek> I wasn't sure if he was describing the same bug or a different one, though
[19:24] <wasabi> tray doesn't open
[19:24] <wasabi> 'eject' won't do it either. i guess it's being mounted quicker than eject can umount and eject
[19:24] <wasabi> s/mounted/remounted/
[19:25] <slangasek> that doesn't really sound like the same bug to me, but ICBW
[19:28] <calc> pitti: i'll just talk to you when i get to the hotel tonight (if i see you), should be there around 7pm
[19:28] <calc> pitti: i was going to ask you a question about the email you sent out, but dont have time right now, since i have to catch my flight
[19:28] <pitti> calc: ah, fine; I guess we'll arrive around the same time, maybe a little later
[19:28]  * calc bbl
[19:29] <pitti> calc: safe travels!
[19:29] <calc> pitti: my flight gets in at 5:40pm
[19:29] <calc> pitti: so i should be the hotel by 7pm i am guessing
[19:29]  * calc throws his stuff together to head to the airport, heh
[19:30]  * calc probably bbia 8hr or so
[19:38]  * slangasek waves to calc 
[20:18] <apachelogger> james_w: we just did our first release from a bzr branch :D
[20:24] <wasabi> while true; do eject /dev/cdrom10; done
[20:24] <wasabi> That got it!
[20:24] <wasabi> of coruse now it's opening and closing repeatidly.
[20:30] <Company> wasabi: try while true; do eject /dev/cdrom`seq 1 100 | shuf | head -1`; done next time
[20:30] <wasabi> heh.
[20:30] <wasabi> so now there's no cd, but it's stuck closed
[20:30] <ion_> Brute force for the win.
[20:30] <Company> is there a better way to get random numbers in the shell?
[20:30] <wasabi> and kernel is spewing out drive timeouts.
[20:31] <wasabi> i wonder if it's still processign my ejects.
[20:31] <n1lo> How to active the kernel framebuffer?
[20:31]  * ion_ hadn’t noticed shuf before. Thanks. I had used ‘ruby -e 'print ARGF.sort_by { rand }'’ in the past.
[20:32] <Company> ion_: it's pretty new
[20:32] <n1lo> ?
[20:33]  * Company uses it for looking for mp3s to play with ls -l | shuf
[20:36] <Philip5> don't know how offtopic this is but does anyone here know if it's possible to make pbuilder to halt if the the build breaks and if so i would like to login to the pbuilder session and look around.
[20:36] <Philip5> can it be done?
[20:36] <directhex> preserve buildplace, something like that?
[20:37] <Nafallo> Philip5: -motu is probably more correct, and I believe the pbuilder package includes example hooks.
[20:37] <Nafallo> :-)
[20:37] <Philip5> oki
[20:37] <Philip5> :)
[20:58] <mohbana>  if i install via jreu11 via update-alternatives --config java does the webplugin get installed as well
[20:59] <tkamppeter> pitti, hi
[21:00] <tkamppeter> pitti, can you have a look at https://blueprints.edge.launchpad.net/ubuntu/+spec/printer-driver-auto-download-service? Who else from Ubuntu I should invite to that meeting?
[21:12] <pitti> tkamppeter: hey! greetings from San Francisco
[21:12] <pitti> tkamppeter: I think we should have mvo, he's a key person for signed archives
[21:16] <dublpaws> is there a transition team working on python 3.x source updates?
[21:22] <persia> dublpaws, There's at least some interested parties in making the necessary preparations.  I'm a little out of date, but last I heard the plan was to still target 2.x for Jaunty, while trying to get as much of the source 3.0-acceptable as possible.
[21:23] <dublpaws> I see.  a daunting task no doubt.
[21:23] <persia> From the little I understand, yes :)
[21:23] <exarkun> What kind of source updates are you thinking of?
[21:24] <directhex> to the debian/patchesmobile!
[21:25] <persia> exarkun, Aren't there at least some small syntax changes from 2.5 to 3.0?
[21:25] <exarkun> Yes, indeed
[21:25] <dublpaws> I guess I'm worried about the packages that are more or less collecting dust, "just work"ing.
[21:26] <Treenaks> persia: that, and standard library changes
[21:26] <exarkun> But I'm wonder if dublpaws wants someone to start patching upstream code
[21:26] <exarkun> Or what
[21:26] <Treenaks> persia: python 2.6 has a 'warnings' mode
[21:26] <persia> dublpaws, If you'd like to test and fix, I'm sure the python team would appreciate patches to adjust to work 3.0, as long as it still works with 2.x (I think 2.6, but I could be mistaken)
[21:27] <ScottK-laptop> We need to get stuff working with 2.6 first and doko hasn't uploaded 2.6 yet.
[21:27] <exarkun> Most programs cannot be expressed such that they are both valid 2.6 and 3.0 programs.
[21:27] <ScottK-laptop> exarkun: Isn't that 2.5/3.0.
[21:27] <exarkun> ScottK-laptop: Nope.
[21:27] <ScottK-laptop> exarkun: I thought the point of 2.6 was to support transition?
[21:27] <exarkun> I mean, _more_ programs can't be expressed as valid 2.5 and 3.0 source. :)
[21:27] <Treenaks> ScottK-laptop: that's waht the warning mode is for
[21:28] <exarkun> But most also cannot be valid 2.6 and 3.0.
[21:28] <Treenaks> ScottK-laptop: "This wouldn't work in 3"
[21:28] <ScottK-laptop> I see.
[21:28]  * ScottK-laptop anticipates a LONG transition
[21:28] <exarkun> The best the Python development team thinks you can hope for is to be able to express a program as valid 2.6 source which will be warning free in the "3.0 warnings" mode
[21:28] <Treenaks> ScottK-laptop: so does the python foundation.. at least a decade
[21:28] <exarkun> And then run an automatic source translation tool over it to produce the 3.0 source
[21:28] <persia> But adjusting that which wouldn't work in 3 might not work in 2.6?
[21:29] <Treenaks> persia: exactly
[21:29] <exarkun> For a project I'm a developer on, the tool generates a megabyte of diff.
[21:29] <lifeless> py3 is a new language that happens to look similar :)
[21:29] <ScottK-laptop> lifeless: It's not that different.
[21:29] <Treenaks> lifeless: and work similar, too
[21:29] <persia> Ah.
[21:29] <exarkun> So "long transition" is a good way to think about it, yea :)
[21:29] <tkamppeter> pitti, you are already in SF?
[21:30] <lifeless> ScottK-laptop: for the purpose of this discussion it is different enough
[21:30] <ScottK-laptop> I suppose.
[21:30] <tkamppeter> pitt, so I will add mvo.
[21:30] <lifeless> ScottK-laptop: its not as close as two editions of the C language spec
[21:30] <persia> lifeless, Is it as different as e.g. C and ObjC ?
[21:31] <exarkun> aren't all valid C programs also valid ObjC programs?
[21:31] <ScottK-laptop> persia: No.
[21:31] <tkamppeter> pitti, added.
[21:31] <persia> exarkun, No, although I believe that is true for C++
[21:31] <exarkun> it's not true of C++ because of new keywords at least
[21:31] <exarkun> Why isn't it true of ObjC?
[21:32] <exarkun> wikipedia says "Objective-C is a strict superset of C. That is, it is possible to compile any C program with an Objective-C compiler."
[21:32] <exarkun> if we trust wikipedia :)
[21:32]  * exarkun checks to see if it also says that about C++
[21:32] <persia> I seem to remember some issue with treatment of structures, although it's been a decade since I spent much time with ObjC, so my memory is a bit fuzzy.
[21:32] <exarkun> ah no, it says "C++ is often considered to be a superset of C, but this is not strictly true."
[21:33] <persia> exarkun, From http://objc.toodarkpark.net/grammar.html it appears ObjC suffers from keyword issues as well.
[21:35] <lifeless> persia: all C programs are not all valid C++ programs; in that their behaviour may change too
[21:35] <lifeless> OTOH, stat.st_time added a C keyword by fiat, so I'm sure comparing standards is enough anyhow :)
[21:35] <exarkun> stat.st_time?
[21:35] <persia> heh
[21:36] <lifeless> yes
[21:36] <jcastro> lifeless: are you here yet? (hotel?)
[21:36] <lifeless> jcastro: kindof :) - I'm on leave today
[21:36] <jcastro> no worries
[21:36] <lifeless> jcastro: I will be swinging by to the hotel a bit later, couple of hours from now
[21:37] <jcastro> sweet
[21:38] <lifeless> exarkun: st_*time is now a macro
[21:38] <lifeless> #ifdef __USE_MISC
[21:38] <lifeless> ...
[21:38] <lifeless> # define st_atime st_atim.tv_sec        /* Backward compatibility.  */
[21:38] <lifeless> ...
[21:38] <lifeless> #else
[21:38] <lifeless>     __time_t st_atime;                  /* Time of last access.  */
[21:38] <lifeless> ...
[21:38] <lifeless> #endif
[21:39] <lifeless> this means that if you use st_atime for *anything* other than accessing the contents of a struct stat's st_atime field... it will blow up
[21:39] <exarkun> ow
[21:39] <lifeless> and doing #undef st_atime will make people look at you weirdly
[21:40] <guille_> hi all
[21:41] <guille_> i'm installing ModPerl in Apache2, and they use the namespace ModPerl for everything, but in cpan it's Apache? (from the start to the end of, am i wrong?)
[21:41] <ScottK-laptop> guille_: #ubuntu-server is probably a  better place to ask.
[21:58] <lifeless> exarkun: the particular joy through which I found that out btw - pyrex, writing an attribute on a class, called st_atime
[21:58] <exarkun> hah, I bet that was fun.
[21:58] <lifeless> turns out you can't have a C function called _py_2_st_atim.tv_sec
[21:59] <lifeless> (or whatever the exact pyrex mangling gave, I don't recall)
[22:03] <NCommander> Can a buildd admin please rescore kde4libs on armel?
[22:51] <kirkland> pitti: i'm wondering if you might review the adduser patch i attached to https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/302870 and sponsor?
[22:51] <ubottu> Ubuntu bug 302870 in adduser "add support for setting up encrypted home directory on user creation" [High,In progress]
[22:56] <mohbana> has anyone installed java 6 update 11, i'm stuck with installing the plugin
[23:05] <pitti> kirkland: can you please sub me? still @ conf
[23:05] <kirkland> pitti: already did, "pitti", right?
[23:06] <pitti> kirkland: right
[23:06] <kirkland> pitti: awesome, thanks, i'm heading for a plane soon
[23:06] <kirkland> pitti: be there later tonight ;-)
[23:06] <pitti> kirkland: looking forward to seeing your again
[23:06] <kirkland> pitti: likewise!
[23:22] <mohbana> hello ....
=== TheMuso_ is now known as TheMuso