[02:00] <twb> apt-spy is a Debian package that looks at the Debian mirror list, tries each one in turn, and puts the fastest ones in sources.list.d.  Is there an equivalent list of primary *and secondary* mirrors for Ubuntu?
[02:01] <twb> The mirror list would also need to specify which arches and categories (and if deb-src was available) for each mirror.
[02:09] <Viper550> Okay, little question, did support for any older graphics cards get dropped from any drivers?
[02:09] <twb> Viper550: for an Xorg GPU driver "foo", you can usually say "man foo" to read about it.
[02:09] <Viper550> like, ati
[02:10] <twb> In particular, the proprietary drivers seem to regularly drop support for older models.
[02:10] <Viper550> I have to switch it to vesa or I get a blank screen with my computer. It worked ok on Breezy
[02:10] <twb> However, this thread is probably better directed to #ubuntu or similar.
[02:15] <olmari> hello, it seems that 9.04 installation trough netboot / mini-installer is somewhat broken at least on this one computer
[02:15] <olmari> will explain further if anyone interested
[04:15] <jscinoz> hi
[04:15] <jscinoz> Is there a reason that the tor package was removed from jaunty?
[04:22] <StevenK> jscinoz: Deleted in jaunty-release on 2009-04-17  (Reason: unmaintained, see LP #328442)
[04:24] <jscinoz> StevenK: ah i see, thanks
[06:30] <dholbach> good morning
[07:05] <pitti> Good morning
[07:05] <pitti> NCommander: if we still have a porter box, it's possible
[07:11] <StevenK> Morning pitti!
[07:12] <StevenK> I wonder if the dist-upgrader stores what it wants to remove in a tempfile
[07:20] <liw> StevenK, /var/log/dist-upgrade?
[07:21] <StevenK> Oooh
[08:53] <kklimonda> Is any Ubuntu Python developer/maintainer present?
[11:56] <jpds> pitti: Sorry for not pushing the disable-existing-groups-creation up to upstream, have been moving, will do this evening.
[11:57] <pitti> jpds: no need to be, was just a reminder
[11:57] <pitti> jpds: just dput'ed the package, it works wonderfully!
[11:57]  * pitti backports them
[11:57] <jpds> \o/
[11:57] <pitti> jpds: thank you for working on this; it explains a lot of weird bug reports I've seen
[11:57] <jpds> No problem at all.
[11:59] <pitti> jpds: how was the moving, everythign settled now?
[12:00] <jpds> pitti: Still no place to live, sleeping on office floor.
[12:01] <jpds> So yeah, it's been an interesting week. :)
[12:06] <NCommander> pitti, we do have a porters box :-)
[12:07] <NCommander> pitti, an armel retracer though would be extremely useful
[12:09] <pitti> NCommander: which machine is that?
[12:10] <NCommander> pitti, the armel porter is rimu, I'm trying to remember what the SPARC porter box is (I've used it once, and my brain has gone to mush)
[12:11]  * pitti wonders whether putting something as heavy as the apport retracer on that would completely blow the machine
[12:11] <NCommander> pitti, how demanding is the retracer?
[12:12] <pitti> NCommander: mostly I/O; lots of chroot unpacking, package installing, running gdb, and communicating with LP
[12:12] <pitti> pitti@rimu:~$
[12:12] <pitti> ah, taht works
[12:12]  * NCommander is looking for the SPARC box
[12:12] <pitti> NCommander: well, I'll set it up, and we can run it on demand
[12:13] <pitti> added to my TODO
[12:15] <NCommander> pitti, my laptop sucks :-/
[12:18] <NCommander> pitti, I won't think the retracer would be that bad, considering there wouldn't be THAT many things it needs to retrace
[12:18] <pitti> true that
[12:18] <NCommander> apport will likely need a patch though to tag things retrace-armel-needed
[12:18] <pitti> NCommander: as I said, I'm happy to set it up, then we can run it on demand
[12:19]  * NCommander is trying to find the SPARC porter
[12:19] <pitti> NCommander: patch> unlikely, unless apt reports somethign else than "armel" as architecture
[12:20] <pitti> NCommander: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=need-armel-retrace
[12:20]  * NCommander hasn't really poked apport guts all that much
[12:20] <pitti> seems to work
[12:27] <cjwatson> NCommander: faure
[12:28] <NCommander> cjwatson, thanks. I was going nuts to try and find it.
[12:28]  * ogra thinks update-initramfs should be able to use a --sourcedir option ...
[12:29] <NCommander> cjwatson, I have lpia-wrapper prepped for upload (it needs to approved via REVU, but that should get done to day). Can I fire an upload to karmic, or should it wait for general archive open
[12:29] <ogra> its all scripts, totally arch independent, theoretically i should be able to bootstrap a stage one system, dpkg -x a kernel packge in that dir and let update-initramfs roll an initrd.gz from that, no ?
[12:31] <cjwatson> NCommander: feel free to upload any time, although I understand it's already on the buildds so it's not urgent to accept
[12:31] <cjwatson> ogra: hooks can do anything; they could quite reasonably do architecture-dependent things. I wouldn't want to support --sourcedir.
[12:32] <ogra> oh, hooks ... i didnt think of them ...
[12:33] <ogra> i was just wondering ... my redboot-install script will need an initrd.gz and i have no idea how to get one without using qemu which is a bit heavy imho
[12:36] <ogra> i guess i'll have to strike the cross arch idea for now :/
[12:42] <NCommander> ogra, ?
[12:42] <ogra> NCommander, ?
[12:43] <NCommander> ogra, what are you doing?
[12:43] <ogra> writing redboot-install
[12:46] <NCommander> ogra, oh
[12:46] <directhex> you know, sabdfl1's oh-so-soft mono t-shirt would have come in handy yesterday
[12:47] <ogra> dont you have you own ?
[12:47] <ogra> *your
[12:47] <directhex> no!
[12:47] <directhex> closes i have is a visual studio t-shirt i snagged as an undergrad
[12:47] <ogra> really ? you are the mono guy, arent you ?
[12:47] <NCommander> ogra, argh, I just realized, we never wrote an installation manual for ARM :-/
[12:47] <directhex> ogra, yeah
[12:48] <ogra> make them send you one instead of trying to borrow sabdfl1's :P
[12:49] <ogra> NCommander, installation manual ?
[12:49] <cjwatson> installation-guide-armel
[12:49] <ogra> the ubiquity docs should do
[12:49] <NCommander> ogasawara, https://help.ubuntu.com/9.04/installation-guide/powerpc/index.html
[12:49] <NCommander> Granted, the PowerPC one probably needs a refresh ...
[12:49] <ogra> hm, but we dont have an official alternate image
[12:49] <NCommander> although its still mostly revelent for 9.04
[12:50] <cjwatson> I did consider enabling armel in installation-guide (it's quite straightforward to turn that on), but (a) it's primarily for d-i and (b) I suspected that the hardware sections would need some work
[12:50] <directhex> i wonder if the mono team still have any Rupert plushies
[12:50] <ogra> well, it would anyway only make sense for the netinst images
[12:50] <NCommander> ogra, we have babbage alternates
[12:50] <NCommander> I don't know anyone using them
[12:50] <NCommander> But we do have them.
[12:50] <cjwatson> it would make sense for netboot, yes
[12:51] <directhex> does jaunty work on ps3? does anyone know off the top of their heads?
[12:51] <NCommander> directhex, works great
[12:51] <directhex> NCommander, excellent
[12:51] <cjwatson> there was a bug this morning about it being totally broken (usplash?)
[12:51] <NCommander> directhex, using a Xubuntu alternate, and your set to go.
[12:51] <cjwatson> but it could be system-specific
[12:51] <NCommander> cjwatson, on PS3? I filed a bunch on usplash on powerpc in general
[12:51] <cjwatson> bug 365711
[12:52] <NCommander> The live images are broken, the alternates are known to work.
[12:52] <cjwatson> ah
[12:52] <cjwatson> what's wrong with the desktop images? just RAM constraints?
[12:52] <directhex> NCommander, will those be respun with a fix, or release-noted as coasters?
[12:52] <cjwatson> in that case we should perhaps unpublish the desktop images ...
[12:52] <NCommander> directhex, we release noted it in the Kubuntu release notes
[12:53] <NCommander> directhex, I'm tempted to buy a PS3, there are so many users of it it would be nice if a powerpc dev had one :-/
[12:53] <directhex> NCommander, i still think ps3 linux has been largely a missed opportunity. only one company is sinking significant resources into it, but they haven't cured it of inherent suckitude
[12:54] <directhex> NCommander, but it's a year or two since i took a look. it might all be great nowadays
[12:54] <NCommander> directhex, blame sony. Although there are only two distros with native PS3 support
[12:54] <NCommander> directhex, YDL and Ubuntu
[12:54] <NCommander> (Fedora has an unofficial port last I checked)
[12:54] <directhex> NCommander, define "native"
[12:55] <NCommander> directhex, installer CDs for PS3 that you just pop in and go
[12:55] <directhex> NCommander, ah, you'#re missing one little detail then
[12:55] <NCommander> directhex, ?
[12:56]  * NCommander is currently sucking down the SPARC karmic tree
[12:56] <directhex> NCommander, opensuse has no ps3 image - opensuse ppc has all ps3 specific files on the generic ppc media
[12:56] <directhex> including otheros.bld
[12:56] <NCommander> directhex, wow, nifty
[12:56]  * NCommander is still kinda amazed Ubuntu PS3 exists
[12:56] <directhex> hm, yeah, 2007 is when i last looked at ps3 linux
[12:57]  * NCommander is currently investigating the sparc d-i issues
[12:58] <directhex> NCommander, what seems to be missing from ps3 linux distros IME is ps3-specific polish. i don't know how much polish is possible given the hypervisor constraints, but things like changing resolution ought to be possible in an "easy" way, even if it's just something wrapping the crap way
[12:59] <NCommander> directhex, last I checked, 9.04 properly autodetects resolution based on the output usage on the PS3
[12:59] <directhex> <3
[12:59] <directhex> wait, we live in an age of utf-8
[13:00] <directhex> ♥
[13:00] <NCommander> lol
[13:00] <directhex> THAT's the kind of thing i'm talking about though. if it does that, then that's awesome
[13:00] <directhex> how about networking? is it still a plate of doodie & chips to use wifi through the nasty gelic kernel module?
[13:01] <NCommander> cjwatson, is there a good place we can note the existence of lpia-wrapper? Anyone building packages on lpia in a chroot will not get the wrapper installed automatically so we probably should document its existence somewhere :-/
[13:02] <ogra> NCommander, blog it :)
[13:02] <NCommander> ogra, planned to, but I was thinking something more attractive
[13:03] <NCommander> ogra, Kubuntu started pushed lpia for Atom in their release annoucement since they have users who are seeing better performance on it, which means the lpia usebase is going to go up
[13:03] <NCommander> and a specification idea just hit me
[13:04] <cjwatson> NCommander: err. I'm honestly not sure. Somewhere linked off UbuntuDevelopment?
[13:04] <NCommander> cjwatson, yeah, but most people aren't likely to check that :-/. Maybe we should place it in build-essential for lpia (I dunno if thats a good idea or not, but at least if you build a pbuilder chroot, you get a setup that matches the build daemons)
[13:23] <dholbach> NCommander:  https://wiki.ubuntu.com/UbuntuPackagingChanges ?
[13:24] <dholbach> NCommander: that page is linekd from a couple of places already
[13:24] <NCommander> dholbach, indeed
[14:13] <cjwatson> Riddell,ScottK: bug 349066 (from the 9.04 release notes) is still open on kubuntu-default-settings. Is it still possible/reasonable to fix it there (e.g. for upgrades from 8.04 to 10.04)? If so, it ought to be targeted to karmic
[14:13] <cjwatson> (I haven't done that myself since I don't know whether it should just be closed or not)
[14:22] <Riddell> cjwatson: I don't think there's any way to do the right thing so it should probably just be closed
[14:27] <cjwatson> Riddell: ok, please go ahead then
[14:31] <cjwatson> doko,kees: I've promoted autoconf2.59 to main, since gcc-4.4 build-depends on it, I'm sure that's better than it having an internal copy, and the security support implications seem likely to be minimal. Do you know if there's any work being done to port gcc forward to current autoconf?
[14:34] <cjwatson> doko,kees: hmm, and also promoted cloog-ppl while I was there
[14:35] <doko> cjwatson: and ppl
[14:36] <doko> cjwatson: autoconf. no, afaik the pain is not yet big enough, and this always seems to be a major effort, as this is kept in sync with gcc, binutils, gdb, ...
[14:36] <cjwatson> doko: any particular binaries from ppl, or everything?
[14:37] <pitti> wrt toolchainish packages, anyone already working on debhelper?
[14:37] <doko> cjwatson: libpwl4, libpwl-dev could be kept in universe
[14:37] <cjwatson> pitti: not I
[14:37] <pitti> I'm currently tracking down a python install regression in debian's cdbs while merging that
[14:37] <cjwatson> pitti: I'm planning to deal with dpkg though
[14:37] <pitti> but I'm fine to merge debhelper later on
[14:38] <cjwatson> (need to decide whether to use the one from experimental, which is likely to involve many fewer changes but is missing a version from unstable)
[14:38] <cjwatson> doko: ok, ppl promoted, thanks
[14:47] <directhex> has slangasek been sighted lately?
[14:48] <danbhfive> anyone here know where to report a problem with the UNR image?  I think the image is bad, and should be pulled/rebuilt/whatever.  Seems like a critical bug.  I've reported under bug 366086
[14:49] <james_w> debian-installer probably isn't the place
[14:49] <danbhfive> I know, I know, but thats what someone in #ubuntu-bugs suggested
[14:50] <danbhfive> but what _is_ the right place?
[14:50] <james_w> that's checking the md5sums of the packages on the CD against the Packages.gz file?
[14:51] <danbhfive> james_w: no, it uses the md5sums.txt file, and checks the packages directly I think
[14:53] <james_w> is there anything in ./pool/main/p/ppp/ ?
[14:53] <danbhfive> james_w: ie, I mounted the image, cd'd into the root directory, and ran md5sum -c md5sum.txt
[15:00] <danbhfive> james_w: I attached the file in the bug report
[15:00] <james_w> http://releases.ubuntu.com/jaunty/ubuntu-9.04-netbook-remix-i386.list lists something similar
[15:01] <NCommander> danbhfive: what's wrong with the UNR image specifically?
[15:01] <james_w> can you confirm the filename?
[15:02] <james_w> and the deb you attached is valid, and is the right version of the ppp package
[15:03] <james_w> danbhfive: what's the md5sum of the package supposed to be according to md5sums.txt?
[15:03] <cjwatson> danbhfive: actually sounds more likely to be a localised hardware problem
[15:04] <danbhfive> james_w: its valid?  It looks like junk on my computer...
[15:05] <james_w> danbhfive: depends what you are doing with it
[15:05] <danbhfive> lets move to #ubuntu-bugs?
[15:05] <james_w> bug 360925 and bug 365795 found by thekorn
[15:05] <james_w> danbhfive: no, here's better
[15:05] <danbhfive> ok
[15:06] <james_w> danbhfive: what's the md5sum supposed to be?
[15:06] <danbhfive> from md5sum.txt?
[15:06] <james_w> yeah
[15:08] <danbhfive> ff0358bc3eb43e9420a7f009482c278a  ./pool/main/p/ppp/ppp_2.4.5~git20081126t100229-0ubuntu2_i386.deb
[15:10] <james_w> ok, so the file is there and just under the wrong name
[15:10] <ogra> james_w, the filename is cut
[15:10] <ogra> very likely because its to long for vfat
[15:11] <ogra> ogra@osiris:/var/build/images$ md5sum /mnt/pool/main/p/ppp/ppp_245~.d
[15:11] <ogra> ff0358bc3eb43e9420a7f009482c278a  /mnt/pool/main/p/ppp/ppp_245~.d
[15:11] <ogra> md5 actually matches
[15:11] <james_w> it's certainly not the longest filename there
[15:12] <danbhfive> ogra: I actually ran a fsck, and it complained of that
[15:12] <ogra> danbhfive, yes, but the file isnt corrupted, the name simply doesnt match the name in md5sum.txt
[15:14] <ogra> i would think it has to do something with the amount of chars behind the tilde but thats only a guess
[15:16] <ogra> if it is being truncated during copying to vfat that should have created a message somewhere in the buildlogs though
[15:19] <danbhfive> ogra: I attached the error message from the fsck to the bug report.  It says its a bad checksum on the filename
[15:19] <ogra> right
[15:19] <ogra> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu-netbook-remix/jaunty/daily-live-20090421.log shows its intact on the buildd during the build ...
[15:24]  * NCommander grabs it from releases.u.c
[15:28] <cjwatson> I'm guessing the ~ is causing problems due to VFAT's long file name rules. In any case this is no cause to pull the image; at most perhaps a release note that the check will fail harmlessly due to this
[15:29] <ogra> well, it makes ppp uninstallble too from ship i guess
[15:29] <ogra> *uninstallable
[15:30] <cjwatson> I suppose it would do, yes, but you can always get it from the archive; it's not needed during installation
[15:30] <cjwatson> I can confirm that the actual file has the correct contents in the image
[15:30] <ogra> http://paste.ubuntu.com/157258/
[15:31] <ogra> so seems like vfat
[15:31] <cjwatson> yes, of course it's vfat :)
[15:31] <cjwatson> I mean, of course it's a problem with vfat
[15:31] <ogra> well, i wanted to be sure by verifying :)
[15:31] <cjwatson> you don't get this kind of problem on proper filesystems ;)
[15:32] <cjwatson> I'll dup the bugs and put them in the right place
[15:46] <superm1> mvo, this is the second one of bugs showing up like this: bug 366118 . I'm really not too sure what can be causing something like that however.  have you seen this kind of stuff before?
[15:47] <mvo> superm1: I have seen when triggers fail before, the dpkg status file would be good to have
[15:48] <superm1> mvo, hm, well i wish i'd reproduced it myself then :(
[15:49] <kees> cjwatson: promotions> sounds fine to my MIR persona :)
[15:56] <NCommander> any archive admins around?
[16:00] <cjwatson> NCommander: yes?
[16:01] <NCommander> cjwatson: its not a high priority thing, but I uploaded lpia-wrapper to the NEW queue as per the instructions you gave in the RT ticket. Feel free to look at it whenever you get a moment :-)
[16:02] <ogra> is the toolchain already there ?
[16:02] <ogra> i thought we'd be waiting for that
[16:02] <NCommander> ogra: toolchain already went, the wrapper in the chroots
[16:02] <NCommander> ogra: so far no boom.
[16:03] <ogra> ah, i thought we'd have to wait until the rebuild is done
[16:04] <NCommander> ogra: I didn't hear anything about waiting for that for the upload. If thats the case, it can just sit in the unapproved queue until general archive open
[16:05] <ogra> yeah, wont affect the queue indeed
[16:05] <NCommander> ogra: either way, its more or less done until this start exploding in piles of sparks.
[16:05] <ogra> its just that i didnt get any mail from karmic-changes yet so i assumed its still waiting for the toolchain to be done
[16:05] <NCommander> ogra: I see the toolchain packages in karmic as accepted
[16:06] <NCommander> Maybe Launchpad isn't sending mail, or someone misset the changes email when they created the distro series
[16:06] <ogra> that i doubt
[16:06]  * NCommander shrugs
[16:07]  * NCommander is looking into what voodoo it takes to build an add-on CD
[16:07] <cjwatson> NCommander: I think it's fine to sit until general open
[16:07] <cjwatson> but thanks
[16:07] <cjwatson> karmic-changes has its moderation settings wrong; I'll sort that out
[16:08] <NCommander> cjwatson: np, I just didn't want it to get forgotton, I still need to note it somewhere. I guess the other thing to decide is if we want it in build-essential on lpia once it goes through (its strictly speaking not essential, but to get the same compiler output it is ...)
[16:09] <cjwatson> it won't get forgotten once it's in the queue
[16:09] <NCommander> ... stupid question, is it going to move from Unapproved to New at general open?
[16:09] <cjwatson> it's already in new
[16:09] <NCommander> oh
[16:09]  * NCommander has a MIR to write
[16:10] <cjwatson> build-essential> I don't really care; your team's decision. If you want it there then edit the build-essential seed
[16:10] <NCommander> cjwatson: I'll bring it up with the team. Thanks
[16:12] <cjwatson> hmm, I can't find the relevant moderation bit, I'll ask IS
[16:12] <kirkland> pitti: howdy
[16:12] <kirkland> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/313330
[16:12] <kirkland> pitti: thanks for nudging that over to ecryptfs-utils
[16:12] <kirkland> pitti: were you able to reproduce this?
[16:13] <pitti> kirkland: no, I just stumbled over this when triaging my ubuntu-bugs mailbox
[16:13] <kirkland> pitti: gotcha
[16:13] <pitti> kirkland: and good morning :)
[16:13] <kirkland> pitti: hiya!
[16:13] <kirkland> pitti: i think this is a combination of a couple of issues
[16:13] <ogra> cjwatson, gcc-defaults just got through
[16:13] <kirkland> pitti: the "slow" part of the login process he describes, I *bet* he's on a netbook, arm, or atom machine
[16:14] <kirkland> pitti: and he's experiencing his cpu "strengthening" his key
[16:14] <cjwatson> ogra: yeah, but I had to moderate two messages earlier
[16:14] <ogra> ah
[16:14] <kirkland> pitti: which is ecryptfs iteratively sha512'ing his key 64K times
[16:14] <pitti> kirkland: hm, these aren't really so slow, though, are they? they are usually > 1 GHz?
[16:14] <kirkland> pitti: they're slow for mathematical computation
[16:14] <kirkland> pitti: stuff they can't offload like sound/video/networking
[16:14] <pitti> oh
[16:15] <kirkland> pitti: i have an idea about how we can 'fix' that in Karmic
[16:15] <kirkland> pitti: jdstrand made a couple of interesting suggestions
[16:15] <directhex> is slangasek taking a day off post-release?
[16:16] <kirkland> pitti: with respect to the error messages, i have some new code upstream that short-circuits the pam_ecryptfs parts for users (like root) who don't have an ecryptfs setup
[16:16] <cjwatson> it's kinda early for him *anyway*, given that I saw mail from him a mere five hours or so ago
[16:16] <kirkland> pitti: so i think this, again, will be fixed as soon as we merge for karmic
[16:16] <directhex> is it? hm, i suppose i didn't think about which TZ he's in
[16:17] <pitti> kirkland: nice
[16:17] <pitti> kirkland: my own computer is pretty slow as well (2x 1.2 GHz), so perhaps the slow session start affects me as well :)
[16:18] <kirkland> pitti: time sudo /bin/true
[16:18] <pitti> real0m0.075s
[16:18] <pitti> user0m0.016s
[16:18] <pitti> sys0m0.000s
[16:18] <kirkland> pitti: doesn't look like it to me
[16:18] <kirkland> pitti: do you have an atom or arm?
[16:18] <pitti> but that doesn't do password shuffling certainly?
[16:19] <kirkland> pitti: here's a better test ...
[16:19] <pitti> kirkland: no, Core2 Duo
[16:19] <kirkland> pitti: oh, that's a powerful processor
[16:19] <kirkland> pitti: time printf "foo" | ecryptfs-add-passphrase
[16:20] <kirkland> real	0m0.369s
[16:20] <pitti> real0m0.530s
[16:20] <pitti> user0m0.476s
[16:20] <kirkland> pitti: if i peg my cpu at 800MHz: 0m0.675s
[16:20] <kirkland> pitti: at 2.4Ghz: 0m0.216s
[16:21] <kirkland> pitti: my Dell Mini9 is about 10x slower
[16:21] <pitti> kirkland: btw, did that command change anything in my ecryptfs keyring?
[16:21] <pitti> i. e. can people now login with "foo"? :-)
[16:21] <kirkland> pitti: keyctl show
[16:21] <kirkland> pitti: no :-)
[16:22] <kirkland> pitti: cat $HOME/.ecryptfs/Private.sig
[16:22] <pitti> (nice trick, though!)
[16:22] <kirkland> pitti: that'll show your two "real" keys
[16:22] <kirkland> pitti: keyctl show
[16:22] <kirkland> pitti: that'll show you 3 keys (with your new one)
[16:22] <kirkland> pitti: you can prune it out with ...
[16:24] <kirkland> pitti: it's keyctl unlink
[16:24] <kirkland> pitti: i'm trying to get the syntax right, one moment :-)
[16:25] <kirkland> pitti: okay, keyctl show
[16:25] <kirkland> pitti: find the key that does not belong
[16:25] <kirkland> pitti: the first column is the key id
[16:25] <kirkland> pitti: then unlink it from your user keyring with something like:
[16:26] <kirkland> pitti: keyctl unlink 284027678 @u
[16:26] <kirkland> pitti: where 284027678 is the key id
[16:26] <pitti> hm, that's confusing
[16:26] <pitti> keyctl show is just gibberish
[16:26] <pitti> kirkland: anyway, if it's all good after next boot, I'm fine
[16:27] <kirkland> pitti: :-)  it's not that bad
[16:27] <kirkland> pitti: do you have an entry in your keyring with sig 253ca7e88811d184
[16:27] <kirkland> pitti: that's the one that matches "foo" for me
[16:27] <pitti> kirkland: Private.sig only has one id
[16:27] <kirkland> pitti: since we used the same salt and number of iterations, i'd expect it to be the same for you
[16:27] <kirkland> pitti: ah, you're not using filename encryption then!
[16:27] <pitti> no, I'm not
[16:27] <kirkland> pitti: okay
[16:27] <pitti> this is a pretty old /home
[16:28] <cjwatson> ogra,NCommander: ok, Ng has fixed karmic-changes moderation
[16:28] <kirkland> pitti: (btw, it's fairly easy to migrate to using filename encryption, if you want)
[16:28] <ogra> great :)
[16:28] <kirkland> pitti: do you have an entry in keyctl show that matches sig 253ca7e88811d184?
[16:28] <pitti> kirkland: yes, I do
[16:29] <kirkland> pitti: cool, take the int in column 1 for that sig
[16:29] <kirkland> pitti: that's the key id
[16:29] <kirkland> pitti: and do keyctl unlink <that key id> @u
[16:29] <pitti> kirkland: that worked, thanks
[16:29] <kirkland> pitti: \o/
[16:32] <andy_js> is update-manager tied to ubuntu?
[16:32] <andy_js> i'd like to use it with StormOS
[16:33] <maco> kirkland: "GA"?
[16:33] <mvo> andy_js: I don't know about stormos, but update-manager should work on anything that supported python-apt
[16:33] <kirkland> maco: Generally Available
[16:33] <andy_js> mvo: thanks
[16:33] <maco> ah...haven't tried since last time i said i couldn't reproduce
[16:34] <nijaba> mvo: regarding https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-repository-management/, you know about the https://wiki.ubuntu.com/WebMirrorManager spec we started last UDS?
[16:35] <mvo> nijaba: thanks, I have a look
[16:35] <nijaba> np
[16:40] <maco> kirkland: im going with saying its not reproducible since last time i did two installs in a row and neither hit it
[16:40] <kirkland> maco: cool
[16:40] <kirkland> maco: would you update the bug?
[16:41] <kirkland> cjwatson: hiya ...
[16:42] <kirkland> cjwatson: there have been a few error reports about ecryptfs-utils being removed during installation
[16:42] <kirkland> cjwatson: i thought i saw something from you come across that fixed this
[16:42] <kirkland> cjwatson: as i recall, it wasn't in ecryptfs, but in user-setup or something, perhaps?
[16:43] <kirkland> cjwatson: i have two very similar bug reports that i'm trying to wrap my head around
[16:43] <kirkland> https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/365895 and https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/365905
[16:46] <cjwatson> kirkland: bug 361627
[16:47] <kirkland> cjwatson: did this make it onto the install media?
[16:47] <cjwatson> yes, and those reports are both from after this change, so it's something else
[16:48] <cjwatson> I need /var/log/syslog from the installation environment
[16:48] <cjwatson> or 'apport-collect -p ubiquity <bug number>' from the installation environment
[16:49] <kirkland> cjwatson: MediaBuild: Ubuntu 9.04 "Jaunty Jackalope" - Release i386 (20090420.1)
[16:49] <cjwatson> it does look pretty similar, so maybe I screwed up the fix
[16:49] <kirkland> cjwatson: just confirming, that build is "new enough", right ?
[16:49] <cjwatson> yes, that's final.
[16:49] <kirkland> k
[16:50] <cjwatson> the intent of the fix I applied was to iterate over /target/home/*, and if any of those directories have a .ecryptfs subdirectory, then to keep ecryptfs-utils installed
[16:51] <cjwatson> bug 365905 is an upgrade log, though, not an installation log
[16:51] <cjwatson> oh, err, I'm wrong there, sorry
[16:51] <cjwatson> it's confusing because we don't clear out the dpkg terminal log from building the live filesystem
[16:52] <maco> kirkland: done
[16:52] <kirkland> maco: thanks
[16:52] <kirkland> cjwatson: hmm, why is ecryptfs-utils installed, and then uninstalled?
[16:52] <cjwatson> kirkland: that's how the live filesystem works
[16:52] <cjwatson> that's irrelevant. ignore it.
[16:52] <kirkland> cjwatson: ah
[16:52] <kirkland> cjwatson: okay
[16:53] <kirkland> cjwatson: i'm beginning to regret the prerm script
[16:53] <cjwatson> oh, bah, I see the problem; /target isn't mounted yet when the code runs in which I added this logic
[16:53] <cjwatson> so I didn't actually manage to fix bug 361627 at all, and it should be reopened and these two new bugs duplicated against it
[16:53] <cjwatson> sorry about that :(
[16:54] <kirkland> cjwatson: bummer
[16:54] <kirkland> cjwatson: i'm going to mark these duplicates of the user-setup bug
[16:55] <cjwatson> there are some hooks available in which I can fix this instead, for karmic
[16:55] <kirkland> cjwatson: are there some post-release notes where we can document this?
[16:55] <cjwatson> http://wiki.ubuntu.com/JauntyJackalope/ReleaseNotes
[16:55] <kirkland> cjwatson: it seems to mostly affect people installing where their /home pre-exists on a separate partition, right?
[16:56] <cjwatson> no, I don't think it matters whether /home is separate
[16:56] <cjwatson> it affects people installing over an existing system, without reformatting, where they were previously using ecryptfs
[16:57] <kirkland> cjwatson: specifically from the livecd
[16:57] <cjwatson> yes
[16:57] <kirkland> cjwatson: b/c i've tested upgrading via the update-manager
[16:57] <kirkland> cjwatson: from intrepid to jaunty
[16:57] <cjwatson> yes, upgrades will be fine
[16:57] <kirkland> cjwatson: though i never tested with the livecd
[16:58] <kirkland> cjwatson: okay, so we'll need to release note something about recommending upgrading via update-manager, rather than a livecd for users with existing encrypted-private setups
[16:58] <cjwatson> yes
[16:58] <kirkland> cjwatson: can i add that release note myself, or do i need to go through slangasek ?
[17:00] <incorrect> I don't know if this is off topic, but I am looking for some documentation about how the netboot.tar.gz is created
[17:06] <josephpiche> hi. i was wondering if someone could point me in the right direction for getting the source for the "Services" control panel--I'm looking to develop a simple UFW control panel
[17:07] <josephpiche> I actually wrote a blueprint for it too, but i figured i'd start working on it anyway
[17:11] <nijaba> josephpiche: dpkg -S services-admin -> gnome-system-tools, so 'apt-get source gnome-system-tools' should give you the source.
[17:12] <slytherin> Hi, need help please. I did a fresh install of jaunty today. The first user created is not in sudoers list. Hence I am not able to do any administrative operations.
[17:15] <josephpiche> nijaba: thank you
[17:15] <cjwatson> kirkland: feel free to add it yourself
[17:16] <cjwatson> incorrect: it's created as part of the build process of the debian-installer source package
[17:16] <Ampelbein> slytherin: are you in the admin-group? also, please use #ubuntu for general support.
[17:16] <nijaba> slytherin: the appropriate chan for this is #ubuntu, but the user should be part of the admin group, which is in the sudoers
[17:16] <slytherin> anyone have any idea what could be the problem? Is it related to encrypted home directory anyway?
[17:16] <cjwatson> incorrect: there's documentation in the doc/ directory of that source package
[17:16] <cjwatson> slytherin: dunno, need syslog
[17:16] <cjwatson> /var/log/installer/syslog specifically
[17:17] <slytherin> Ampelbein: nijaba: I can't even check that since I have no access to any admin GUI tools.
[17:17] <slytherin> cjwatson: let me look
[17:17] <cjwatson> you'll need to be root to read that, so boot in recovery mode
[17:17] <cjwatson> from which you can add yourself to the admin group, too
[17:17] <incorrect> thank you cjwatson
[17:17] <slytherin> cjwatson: how to I boot in recovery mode with yaboot? This is a powerpc machine
[17:18] <cjwatson> slytherin: 'Linux single'
[17:18] <slytherin> cjwatson: will be back in 5 minutes
[17:41] <tclineks> shouldn't linux-image-virtual make a /boot/vmlinuz-2.6.28-11-virtual, not /boot/vmlinuz-2.6.28-11-server ?
[17:41] <tclineks> i can't have both -server and -virtual installed
[17:42] <cjwatson> maybe it should, but -virtual is literally just -server with some files removed
[17:42] <cjwatson> there's no point installing both
[17:42] <tclineks> i was goign to perf test
[17:43] <cjwatson> don't see how the performance would differ in any way; it's literally the same bits in the kernel image
[17:43] <tclineks> really
[17:43] <cjwatson> the only purpose of the -virtual package is to be smaller
[17:43] <tclineks> oh
[17:43] <tclineks> i thought there were kernel config differences
[17:44] <cjwatson> nope
[17:44] <slytherin> cjwatson: here is my installer log - http://paste.ubuntu.com/157356/ I used powerpc alternate CD and choose encrypted home directory option.
[17:45] <slytherin> cjwatson: I have to rush to catch a bus. If you need any more info I will be available around same time tomorrow.
[17:45] <cjwatson> Apr 24 05:37:40 user-setup: Setting up encryption ...
[17:45] <cjwatson> Apr 24 05:37:40 user-setup: ERROR: Can't get ecryptfs version, ecryptfs kernel module not loaded?
[17:45] <cjwatson> Apr 24 05:37:40 user-setup: adduser: `/usr/bin/ecryptfs-setup-private -b -u onkar' returned error code 1. Exiting.
[17:45] <cjwatson> kirkland: ^- from a d-i installation with encryption
[17:45] <cjwatson> kirkland: powerpc-specific maybe?
[17:46] <cjwatson> mm, I bet ecryptfs is modular on powerpc
[17:46] <slytherin> I saw two similar bugs but in that case home directory already existed. In my case it was complete clean install.
[17:46] <cjwatson> your bug is entirely different
[17:46] <slytherin> got to go. Bye. And thanks for help. At least I now know a workaround.
[17:49] <cjwatson> NCommander: http://paste.ubuntu.com/157364/ look OK to you assuming that you fix linux-ports to build -generic not -ia64-generic?
[17:50] <NCommander> cjwatson: yeah, that looks good, I need to create a git tree for karmic though
[17:51] <cjwatson> no problem, it doesn't seem much of an issue for -meta so I didn't bother
[17:51]  * NCommander sees if he can remember how do to it
[17:51] <NCommander> git branches are freaking evil
[17:52] <infinity> NCommander: lpia-wrapper accepted, BTW.  And seeding now.
[17:52] <NCommander> infinity: yay, my first karmic upload
[17:53] <infinity> NCommander: We won't discuss that, by my recent actions, you won't actually be able to update it...
[17:53] <infinity> NCommander: Congrats on the end-run around ACLs.
[17:53] <NCommander> woo, MOTU uploading to main :-P *shot*
[17:56] <NCommander> cjwatson: branch made, committing
[17:59]  * NCommander fixes cjwatson's patch to apply against git vs. the uploaded package
[18:04] <pitti> cjwatson: doing debhelper merge now
[18:15] <jcole> per seb128: "Could somebody having the issue open the bug on http://bugzilla.gnome.org where exchange hackers will read it too and can work on it? The ubuntu bug triagers have no access to exchange server"
[18:16] <jcole> seb128: there is no bug for them to fix, its just a matter of ubuntu jaunty not having the latest
[18:21] <seb128> jcole: dunno what you are speaking about, I commented that on quite some evolution-mapi bugs
[18:21] <seb128> jcole: and that has to be proved
[18:23] <jcole> seb128: wouldnt the best way to prove/test it is to have a ppa populated with the svn snapshot of evolution-mapi/samba4/openchange and have people install that
[18:24] <seb128> jcole: ok, worded different bugs sitting in launchpad helps nobody
[18:24] <seb128> jcole: we don't have access to exchange server so better to open those bugs upstream and close them if they reply it's fixed in new versions
[18:24] <jcole> seb128: i donwloaded the sources for all those packages, but i am not familiar of the reorganization the debian/ubuntu maintainer has done to those packages
[18:24] <seb128> jcole: you can work on ppa snapshots if you want
[18:24] <jcole> heh
[18:29] <jcole> seb128: oh, i submitted a bug using apport and approt created a new bug... should i delete/close the original bug i opened?
[18:30] <seb128> jcole: what do you mean?
[18:30] <seb128> jcole: you use apport to open a bug and it opened a bug
[18:30] <seb128> seems normal to me?
[18:31] <jcole> seb128: oh, i thought you were saying i opened 2 of the same bugs that were worded differently... you must be referring to everyone
[18:32] <seb128> jcole: right, I just mean that we have nobody working on exchange since nobody has access to exchange servers
[18:32] <seb128> jcole: so it's better to get all those bugs sent by submitter to GNOME
[18:32] <seb128> jcole: there people having access to exchange and having a clue about the code can read those, fix issues and reply
[18:34] <jcole> seb128: one can also install an openchange server in jaunty (which also speaks the libmapi protocol)... but the openchange server in jaunty is old, so you go in a circle, lol
[18:34] <jcole> seb128: uill see what i can do on making some ppa packages
[18:34] <jcole> ill*
[18:43] <pitti> cjwatson: (FYI, the dh_installudev merge is pretty hairy conffile black magic, I'll finish this on Monday
[19:00] <infinity> cjwatson: Oh, hah.  Right.  I was all excited about having livefs stuff setup earlier than in any previous release opener... And then E: No such script: /usr/share/debootstrap/scripts/karmic
[19:00] <infinity> cjwatson: Go me. ;)
[19:11] <G__81> congrats to everyone for a successful 9.04 release
[19:11] <G__81> keep up the great work
[20:06] <cjwatson> infinity: yeah, committed to Debian already but need to upload :)
[20:07] <infinity> cjwatson: No big deal.  Was just looking forward to testing and making sure I didn't mess anything up. ;)
[20:09] <NCommander> cjwatson: is the live rootfs stuff available publicly? (I'm curious to see how it works)
[20:12] <infinity> NCommander: livecd-rootfs, in the archive.
[20:12] <infinity> NCommander: Also a ~core-dev branch on LP.
[20:12] <NCommander> Ah, very cool
[20:12]  * NCommander now works on his plan to build HPPA liveCDs
[20:13] <NCommander> bahahahahaha
[20:13] <infinity> NCommander: There's no real rocket science involved, just a hideous shell script that's evolved over the years to work around various "issues" with automatically installing a working system.
[20:13] <NCommander> infinity: which architectures historically have had liveCDs, i386, amd64, powerpc, and ia64, right?
[20:14] <infinity> NCommander: All arches have livefs builders, and CAN produce livecds.
[20:14] <infinity> NCommander: The only arches anyone's ever deeply cared about were the typically "desktop" ones (i386, amd64, powerpc, lpia, and now armel)
[20:15] <NCommander> infinity: the cdimage system seems to only care about the ones I listed (plus MID on lpia)
[20:15] <infinity> NCommander: antimony's perfectly capable of buildin for all arches.  Some have been disabled for a while, mind you  *shrug*
[20:16] <infinity> NCommander: But we've built them all in the past.
[20:16]  * NCommander wonders how badly the cdimage team would slaughter me if I asked for them to be turned back on ...
[20:17] <infinity> NCommander: Prove to me that you can actually get a livefs build to complete on each arch, and we'll talk about turning them into bootable ISOs. :P
[20:17] <infinity> NCommander: Baby steps.
[20:17] <NCommander> infinity: where are the livefs logs?
[20:17]  * NCommander will do it for every machine he has :-)
[20:18] <infinity> NCommander: people/~ubuntu-archive somewhere.
[20:18] <NCommander> thanks
[20:18]  * NCommander returns to his kernel hacking
[20:18] <infinity> NCommander: But the trick, of course, is that there are no logs for arches that antimony's not triggering.
[20:18] <NCommander> so I have to run the script on a machine by hand?
[20:18] <infinity> NCommander: I could, of course, manually trigger builds on all of them sometime, when you're in the mood to fiddle.
[20:18] <NCommander> I don't really liket o bug you on my pet projects :-/
[20:18] <infinity> NCommander: (We'll talk after karmic's a bit more open?)
[20:19] <NCommander> Sure, I still have to de**** the ia64 kernel (my upload to halley just finished)
[20:23] <guest__> on behalf of my IDOL RANDALL I c0me in here to c0me on all your faces & fuck you all & you're FUCK you all & your Jaunty Jackalope shitty 0s & as long as you'll piss him off i'll piss on your 0s
[20:23] <ScottK> !ops
[20:49] <lamont> i wonder.  is it faster to go disk -> USB ... USB -> disk, or disk -> LAN -> disk
[20:51] <jpds> lamont: Network is always faster.
[20:52] <lamont> yeah - was coming to that conclusion, 45 min and 20% of the way through... :-)
[20:52] <lamont> time to find a couple patchcoords
[22:09] <kirkland> anyone here using Jaunty with an encrypted home directory and KDE?
[22:17] <ScottK> I think your odds are better in #kubuntu-devel
[22:20] <NCommander> kirkland: no, bu I can setup such a beast
[22:24] <YokoZar> hah http://www.ubuntu.com/files/countdown/static.png  went from "it's here" back to "coming soon"
[22:24] <kirkland> NCommander: if you can, can you try to lock the screen, and then unlock it?
[22:24] <LaserJock> YokoZar: in 179 days :-)
[22:24] <YokoZar> says 9.04 though
[22:25] <NCommander> kirkland: sure, but I probably won't get to it soonish :-/
[22:25] <LaserJock> YokoZar: must be talking about the SRU flood :-)
[22:25] <kirkland> NCommander: no problem.  i'll subscribe you to the bug
[22:27] <kirkland> NCommander: https://bugs.edge.launchpad.net/ecryptfs/+bug/336303
[22:33] <mrooney> kirkland: I've been meaning to try Kubuntu, should it duplicate fine in a VM?
[22:36] <mrooney> kirkland: do I need to use the alternate installer for that?
[22:37] <mrooney> I'll just hope the preseed value works in Kubuntu as well
[22:39] <kirkland> mr_pouit: yeah, totally
[22:39] <kirkland> mrooney: ^
[22:39] <kirkland> mrooney: you should be able to do it in a vm
[22:40] <kirkland> mrooney: you can use the alt installer, or the livecd installer with the preseed option on the kernel line
[22:41] <mrooney> kirkland: okay excellent thanks. by the way I've been doing a bit of work on the ecryptfs-ui and hope to have something which can install, setup, and manage a private directory
[22:41] <mrooney> ...to show at UDS
[22:41] <kirkland> mrooney: cool, can't wait ;-)
[22:41] <mrooney> and hopefully allow key retrieval in either home or private, as that seems pretty important
[22:42] <mrooney> yeah I want to set up a ~/Private but am not going to do it until I can do it with the app, so as to force me to work on it :)
[22:53] <mrooney> kirkland: hm either I typed that value wrong or it doesn't work in kubuntu, I can try again
[22:53] <mrooney> I don't see that third option in the installer on step 5
[22:57] <kirkland> mrooney: did you enter the preseed value correctly?
[22:58] <mrooney> kirkland: that's what I meant, maybe I did that incorrectly, I put it right before the --
[22:58] <mrooney> I'll try again :)
[23:09] <nixternal> james_w: lol, I thought you were core-dev already? what has taken you so stinkin' long?
[23:10] <directhex> huh? james_w is climbing the ladder?
[23:10] <mrooney> kirkland: does this look right? http://img411.imageshack.us/img411/5117/screenshotc.png
[23:54] <LordMetroid> Anyone been to the UDS at sometime?
[23:54] <cody-somerville> I have
[23:54] <yoasif> where is UDS this year
[23:54] <LordMetroid> Barcelona
[23:54] <yoasif> nice
[23:55] <LordMetroid> All I've done for Ubuntu so far has been to file bug reports
[23:55] <LordMetroid> But I thought it might be fun to go down with car from Sweden and attend
[23:55] <LordMetroid> (okay that sounded crazy!)
[23:57] <yoasif> if they had transatlantic ryanair flights, id do it
[23:58] <LaserJock> UDS is loads of fun
[23:59] <LaserJock> I especially liked the last Spanish UDS
[23:59] <LordMetroid> But me, I've never been much involved in the Ubuntu development, how would it be for me?
[23:59] <LordMetroid> Can I contribute anything?
[23:59] <LaserJock> you could certainly learn a lot