[00:01] <LaserJock> cjwatson: filed
[00:05] <TheMuso> Hrm. Even more weird, it seems that the cd images I get from rsync are different to the ones I get via http, or at least thats what the MD5sums suggest.
[00:06] <cjwatson> cdimage@antimony:~/cdimage/www/full/daily/current$ md5sum -c MD5SUMS
[00:06] <cjwatson> jaunty-alternate-amd64.iso: OK
[00:06] <cjwatson> jaunty-alternate-i386.iso: OK
[00:06] <cjwatson> I've fixed LaserJock's DVD tasksel preseeding thing
[00:07] <TheMuso> cjwatson: Hrm ok, I'll sync again and th en compare once more.
[00:10] <TheMuso> Well, there is certainly an inconsistancy somewhere, as I have pulled the MD5sums file via rsync after syncing images from rsync, and an md5sum check still fails.
[00:12] <TheMuso> No matter, I'll do a netboot install.
[00:13] <cjwatson> I did just do a sync to mirrors, but it shouldn't have affected image contents or MD5SUMS file contents
[00:13] <TheMuso> hm ok.
[00:13] <cjwatson> are we talking about the same images? the above is for the Ubuntu alternate CDs
[00:13] <TheMuso> Yes I am talking about those as well.
[00:14] <cjwatson> it might clear up tomorrow once they're auto-built properly ... I hope
[00:21] <wasabi> odd. getting a lot of kernel dumps since latest kernel in intrepid-updates. That's suprising.
[00:26] <StevenK> TheMuso: Looks like sparc for linux-ports wants makedumpfile too
[00:26] <TheMuso> StevenK: Yes, because I forgot to turn it off for sparc.
[00:27] <StevenK> TheMuso: Ah!
[00:27] <StevenK> TheMuso: The hppa failure looks damn strange, too
[00:27] <TheMuso> StevenK: But easily fixable I am pretty sure, not worrying about it now though.
[00:55] <ScottK> TheMuso: mesa built on powerpc and so did qt4-x11, so it's some real progress.
[00:55] <ScottK> I'm going to see how far I can get on getting all of KDE built.
[00:56] <TheMuso> ScottK: Ok, I should have other arches for ports sorted out after work today.
[00:56] <StevenK> TheMuso: The ia64 failure looked simple-ish, too
[00:56] <ScottK> Great.
[00:56] <TheMuso> StevenK: Yeah it is.
[00:56] <TheMuso> StevenK: I'll be able to get it to build at least.
[00:57] <TheMuso> Looks like libdrm was also given back
[00:58] <TheMuso> Or was mesa the only issue?
[00:58] <ScottK> mesa was the issue.  It couldn't build because libdrm-dev was uninstallable.
[00:58] <TheMuso> Right.
[00:59] <ScottK> So due to that it's mesa -> qt4-x11 -> soprano -> and then I can start to build KDE.
[00:59] <TheMuso> Interesting actually since there is no linux-libc-dev listed for libdrm-dev for ports arches, I am surprised it worked.
[01:00] <ScottK> It built.  I've got no way to test if it works or not ....
[01:00] <TheMuso> Right, once I get ports sorted, I'll check for myself,.
[01:03] <ScottK> So soprano went from estimated build start in 7 hours to currently building started 4 minutes ago in less than 10 minutes ...
[01:03] <TheMuso> wow
[01:09] <kees> anyone know of the dash-equivalent to bash's -o pipefail?
[01:20] <ion_> kees: sh -c '(cat /foo || kill $$) | cat; echo bar' ;-)
[01:21] <ion_> Not equivalent to pipefail, more like set -e + pipefail
[01:25] <kees> ion_: hrm...
[01:27] <kees> ion_:    find /fail | cpio --quiet -o | gzip >/dev/null      I want that to fail...
[01:28] <ion_> Is (find /fail || kill $$) | cpio | gzip enough?
[01:28] <kees> nope
[01:30] <kees> I'm gonna just cheat and use pipefail.  :)
[01:33] <cjwatson> there really isn't a good portable version of pipefail
[01:33] <cjwatson> the best you can do is to echo return codes out on some spare file descriptor, and catch them at the top level
[01:35] <cjwatson> if [ "$( ((find /fail || echo $? >&3) | cpio --quiet -o | gzip >/dev/null) 3>&1 )" ]; then kill myself horribly; fi
[01:35] <cjwatson> or words to that effect
[01:35] <cjwatson> but it always ends up being horribly gross and you want to hang yourself with a dangling file descriptor
[01:36] <cjwatson> I do it occasionally when I have no other choice and usually have to fight redirections for a while before it actually works
[01:42] <IntuitiveNipple> Which package to file this bug against? Start-up drops to shell when fsck runs because two crypto-volumes haven't been unlocked by cryptdisks-early. They aren't unlocked since the custom script that unlocks them via a key-file is in /usr/local/sbin/, and /usr/local/ is on a separate mount :)
[02:03] <maxb> Is there any page like SyncRequestProcess but for merges? Or are merges just like any other change following SponsorshipProcess?
[02:18] <nhandler> maxb: There is https://wiki.ubuntu.com/UbuntuDevelopment/Merging
[02:46] <ScottK> maxb: On merges.ubuntu.com there's a pointer to the grab-merge.sh script, but once you make the debdiff it's just like any other.
[03:47] <kees> cjwatson: yikes, that's sick.  any chance we can just use pipefail and bash for mkinitramfs?
[03:50] <lifeless> cjwatson: how much to stop you pasting shell fragments like that ? :)
[03:57] <kees> lifeless: ieeee  http://cfaj.freeshell.org/shell/cus-faq-2.html
[03:58] <lifeless> 4 years without updates
[03:58] <lifeless> tsk
[03:59] <kees> no mention of pipefail.  I want to pluck out my eyes after reading the POSIX solution
[04:00] <lifeless> yay single letter variable names
[04:03] <calc> jcastro: hmm will look into the dialogs when i get home, there hasn't been any commits regarding KDE 4 dialogs recently
[04:03] <calc> jcastro: its possible the user just read the release notes and assumed the kde support it talks about is for kde4, heh
[04:05] <ScottK> calc: There was someone in #kubuntu-devel a few hours ago claimin OOo KDE4 patches, but Riddell looked and they were KDE3.
[04:05] <ScottK> Dunno if it's the same someone.
[04:06] <calc> ScottK: yea that is what i was talking about, jcastro sent me the log and i looked and i didn't see anything to indicate there were kde4 patches
[04:09] <calc> well i'm about to head to the airport, headed home from Hamburg today :)
[04:10] <LaserJock> calc: did you eat a hamburger there?!
[04:12] <calc> McD :)
[04:12] <calc> i ate snitzel most of the time though
[04:12] <calc> lol
[04:13] <LaserJock> calc: you went all that way for McDs?
[04:13] <LaserJock> that's about as bad as highvoltage and I at UDS-Paris
[04:13] <calc> its very cold outside and McD was the closest restaurant i saw
[04:13] <StevenK> LaserJock: What did you and highvoltage do at UDS Paris?
[04:13] <LaserJock> we had Subway across from Notre Dame and a street full of cafes
[04:14] <calc> well very cold for me anyway, ~ -5 - -10 and snowing most days
[04:14] <LaserJock> but it was the weirdest Subway I've ever been too, no cheese!
[04:15] <LaserJock> how do you make a sandwich in Paris of all places without cheese
[04:15] <LaserJock> so for UDS Sevilla we did Burger King
[04:15] <StevenK> I ate at Subway in Prague, since it was right by the metro station
[04:16] <LaserJock> I was so starved in Paris, first time outside the US
[04:16] <LaserJock> all the French food was pretty weird for my American senses
[04:16] <ajmitch> LaserJock: you poor fellow
[04:17] <LaserJock> I really started to think that their kitchen had no ovens/burners
[04:18] <LaserJock> but the 16 euro ride into Paris proved much more succesful
[04:18] <StevenK> LaserJock: The food was cold or uncooked?
[04:18] <LaserJock> uncooked mostly
[04:18] <LaserJock> raw, thin sliced beef
[04:18] <LaserJock> with a little lettece and a rock hard roll
[04:19] <jldugger> haute cuisine indeed!
[04:19] <LaserJock> I was an interesting experience
[04:20] <stgraber> LaserJock: sounds expensive :) though usually really good
[04:20] <LaserJock> jbailey tried 3 times to get a vegan meal at the dinner on the last day
[04:21] <LaserJock> I think there was bacon in the salad or potatoes
[04:21] <stgraber> hehe
[04:21] <LaserJock> must have been the potatoes
[04:21] <LaserJock> because then there was a honey-mustard dressing for the salad
[04:22] <LaserJock> it was a lot of fun anyway
[04:22] <stgraber> you really didn't take the less expensive meal you can find :)
[04:22] <LaserJock> but I was coming down with monster ubuflu by that time
[04:23] <calc> so far i didn't get sick this trip, still have 14hr of plane air to survive today though
[04:23] <stgraber> calc: usually I get sick a day or two after :) worked for all UDSes so far.
[04:23] <calc> fun
[04:23] <LaserJock> one of the times I was sick and people were trying to teach me Mao
[04:23] <LaserJock> baaaaad combo
[04:24] <StevenK> I bet they weren't, I bet you were playing
[04:24] <jldugger> you dont teach mao
[04:25] <ScottK> Sure you do.  It'd just done in an unorthodox manner.
[04:25] <LaserJock> well, by the end they were so fed up with me there was some definate coaching
[04:25] <LaserJock> I just couldn't think at all
[04:25] <jldugger> ScottK: if they're learning, you're doing it wrong
[04:26] <ScottK> I didn't say what was being taught.
[04:26] <jldugger> im pretty sure you did
[04:29] <LaserJock> heh, the first line on the History of Mao on wikipedia says "(This Game is Cruel and Unusual)"
[04:29] <LaserJock> man, it sure felt it at the time
[04:31] <ScottK> Heh.
[04:31] <ScottK> First time I didn't find it cruel and unusual.  I thought it was interesting.
[04:31] <ScottK> That probably says more about me than the game though.
[04:33] <LaserJock> yeah, I've just got no patience for games usually
[04:35] <StevenK> You two need to have Phase 10 inflicted on you
[04:35]  * calc bbia 18hr probably
[05:01] <Amaranth> LaserJock: Once time playing with vuntz he made us name a module in GNOME he maintained (in a certain order) every time we changed the suit
[05:02] <Amaranth> Took like 20 minutes to figure that one out
[05:05] <lifeless> ScottK: it may say more about who introduced you
[05:05] <lifeless> ScottK: it can be very collaborative and fun, or plain evil
[05:05] <ScottK> True.
[05:07] <LaserJock> lifeless: you might have been involved in my torture
[05:08] <LaserJock> I remember colin and soren being there
[05:08] <lifeless> LaserJock: I try very hard to play an entertaining game not a cruel one ;)
[05:08] <LaserJock> oh, I'm sure it was entertaining ... :-)
[05:14] <Amaranth> I was playing with plain evil guys
[05:14] <Amaranth> I think they were all GNOME devs
[07:13] <dholbach> good morning
[07:17] <pitti> Good morning
[07:19] <ion_> ing
[07:24] <doko> hurray for the new autoconf \o/
[07:31] <StevenK> doko: That is so the first time I've seen someone proclaiming "hurray for autoconf"
[07:32] <doko> just sarcastic about the gcc build failures
[07:32] <StevenK> Haha. Okay, sarcasm makes it better. :-)
[07:33] <ion_> Such a phrase is inevitably either sarcasm or evidence of a psychosis.
[07:33] <StevenK> It's *doko*, so it's both
[07:38] <Koon> pitti: Archive question : I have three new packages to import from debian to universe, one is in sync and the other two require a small diff. What's the best way to proceed ? Ask you for the sync and upload the merges myself ?
[07:39] <Koon> hm. in fact it's just two packages. The last one is just a merge of an existing one.
[07:42] <persia> Koon, The typical answer to such questions is: request the syncs and upload the merges (once build-dependencies are published).
[07:43] <Koon> persia: thx.
[07:43] <dholbach> doko: are you going to work on python today? might be worth checking out bug 324708
[07:44] <dholbach> bug 324708
[07:47] <doko> dholbach: not python2.5
[07:48] <dholbach> ok
[08:12] <savvas> is the mount type ntfs using ntfs-3g driver?
[08:43] <oskar-> hi, who is the right one to address with a question regarding NM and wpa_supplicant?
[09:06] <cjwatson> kees: I think it'd be fine to use bash for mkinitramfs as long as you don't try to use it for the initramfs itself :-)
[09:06] <cjwatson> savvas: ntfs-3g> yes
[09:06] <cjwatson> oskar-: asac
[09:06] <savvas> thanks :)
[09:20] <primes2h> pitti: Hi, BTW did you have a look at the patch for this bug #172353 ?
[09:24] <oskar-> asac, is there a way provided to tell NM which configuration options to pass to wpa_supplicant (for example "fast_reauth=0")?
[09:37] <asac> oskar-: not that i know.
[09:43] <ogra> cjwatson, wrt compcache, i saw some users in ubuntu-users@ for which the compcache initrmfs hook seems to persist in the installed system, can we make ubiquitey care that it goes away after install ?
[09:44] <oskar-> thanks
[09:44] <cjwatson> ogra: if it fails to go away, then I think something has already gone wrong in ubiquity - i.e. casper has failed to be removed
[09:44]  * ogra glares at hs fingers ... need some type training again :P
[09:44] <cjwatson> ogra: in other words, ubiquity is already trying to make sure of this
[09:45] <ogra> hmm, intresting
[09:45] <cjwatson> it's possible for the installer to crash before removing casper, though, and for the user to think "oh well, I'll try rebooting anyway"
[09:45] <ogra> right
[09:45] <cjwatson> ogra: the hook itself should still be there, of course, since it's in initramfs-tools, just not its configuration
[09:47] <ogra> well, the hook wont create the script if COMPCACHE_SIZE isnt set
[09:47] <ogra> which isnt the case by default ... the user definately has a conf.d file left behind
[09:48]  * ogra looks up the mail
[09:48] <ogra> https://lists.ubuntu.com/archives/ubuntu-users/2009-February/174405.html
[09:49] <directhex> which virtualization system do the ubuntu buildds use?
[09:49] <Mithrandir> directhex: xen, I believe.
[09:49] <StevenK> The distro buildds are bare-metal, the PPAs are Xen
[09:50] <directhex> gotchA
[09:50] <StevenK> directhex: Are Mono assemblies arch independant?
[09:50] <cjwatson> ogra: unless the initramfs is created in /target before removing packages, I guess
[09:50] <cjwatson> which is possible ...
[09:51] <ogra> oh, really ?
[09:51] <cjwatson> blast. Yes, it is.
[09:51]  * ogra wasnt aware ubiquity installs the kernel separately
[09:51] <directhex> StevenK, in most cases, yes. there are exceptions when badly marshalling arch-specific libraries using arch-specific type lengths
[09:52] <cjwatson> err, it doesn't
[09:52] <ogra> but still, that file comes from casper
[09:52] <cjwatson> but it does need to regenerate the initramfs
[09:52] <cjwatson> and remember that ubiquity (1) copies the live filesystem, then (2) removes the bits that are unnecessary
[09:53] <cjwatson> unfortunately, it generates the initramfs between (1) and (2)
[09:53] <ogra> /usr/share/initramfs-tools/conf.d/compcache is only in casper ... and i would assume an initramfs generation only hapens after casper was removed
[09:53] <ogra>  *happens
[09:53] <cjwatson> sadly that is not currently the case
[09:53] <ogra> ah
[09:53] <cjwatson> is there a bug filed about this?
[09:53] <cjwatson> that's actually kind of bad
[09:53] <ogra> i asked him several times, but he only pointed at the upgarde bug over and over, i'll file it
[09:54] <ogra> what should it be, ubiquity or casper ?
[09:54] <directhex> StevenK, a bunch of mono packages include C libs as well as mono assemblies, so those are usually arch:any
[09:54] <cjwatson> ogra: ubiquity, please
[09:54] <cjwatson> it isn't casper's fault at all
[09:54] <cjwatson> ogra: please mark it importance high
[09:57] <StevenK> directhex: Right, there's a package in the binary NEW queue which includes a Mono .dll and it's arch:all
[09:57] <StevenK> directhex: Wasn't sure if it was grounds for rejection or not
[09:58] <cjwatson> can anyone think of a "human-friendly" way to say "Building initramfs..."?
[09:58] <directhex> StevenK, arch:all is correct more often than not
[09:58] <directhex> StevenK, what's the package?
[09:59] <cjwatson> that step can easily take 30 seconds, so I think it's worth describing separately; however following ogra's bug it can't just be subsumed into the description of the steps on either side of it
[09:59] <cjwatson> (it used to be part of "Configuring hardware..."
[09:59] <ogra> cjwatson, bug 328437 for you
[10:00] <cjwatson> thanks
[10:01] <cjwatson> perhaps "Preparing startup files..."
[10:01] <cjwatson> ogra: s/can happen/unconditionally happens/ :-P
[10:01] <pitti> cjwatson: that's for d-i? (I assume in ubiquity we just copy it from the live system?)
[10:01] <cjwatson> pitti: wrong on both counts :)
[10:01] <directhex> hm, tomboy-blogposter
[10:02] <ogra> cjwatson, updated :)
[10:03] <pitti> cjwatson: I thought rebuilding was only necessary once we start supporting raid/lvm/cryptroot in ubiquity.. but oh well :)
[10:03] <cjwatson> there is an argument that casper should rebuild the initramfs when it's removed
[10:04] <cjwatson> pitti: well, rebuilding is necessary for exactly the reason ogra quotes - the live CD initramfs contains casper, and we don't want that on the installed system
[10:04] <pitti> ah
[10:04] <StevenK> directhex: Right, tomboy-blogposter
[10:05] <cjwatson> ogra: the good news is that this will go away with the first kernel upgrade
[10:06] <ogra> will it ? i wonder how the file can persist at all ... the conf.d file is as i said owned by casper ... its shouldnt be there after casper removal
[10:06] <ogra> i suspect we have two different bugs here
[10:06] <ogra> now that i think about it
[10:07] <cjwatson> no
[10:07] <cjwatson> the conf.d file is *copied* into the initramfs
[10:07] <ogra> oh, right !
[10:07] <cjwatson> ok, admittedly that user reported that /usr/share/initramfs-tools/conf.d/compcache was still there
[10:08] <cjwatson> so I suppose that is technically a separate problem, and I wouldn't mind seeing his installer syslog
[10:08] <directhex> StevenK, something like that is very highly likely to be arch:all. i can verify if you like
[10:08] <cjwatson> but I'm a lot more interested in the bug that seems to affect everyone :)
[10:09] <ogra> indeed, well i asked him to comment on the bug in -users
[10:09] <ogra> lets hope he does :)
[10:09] <cjwatson> gar
[10:09] <cjwatson> no, can you ask him to file a separate bug if he has problems not described by the one you filed
[10:09] <cjwatson> otherwise we'll just get a multiple-problems bug which won't help anyway
[10:09] <cjwatson> anyone
[10:09] <ogra> ok
[10:10] <cjwatson> thanks
[10:10] <directhex> StevenK, just checked. no modulerefs so nowhere for arch-specific issues to appear
[10:56] <StevenK> directhex: Okay, I'll accept it.
[10:59] <cjwatson> nhandler: regarding the Replaces vs. Conflicts+Replaces point from the other day, I just read the relevant section of the policy manual and it is in fact quite clear about this
[10:59] <cjwatson> For Replaces alone, it says:
[10:59] <cjwatson>             Furthermore, this usage of <tt>Replaces</tt> only takes
[10:59] <cjwatson>             effect when both packages are at least partially on the
[10:59] <cjwatson>             system at once, so that it can only happen if they do not
[10:59] <cjwatson>             conflict or if the conflict has been overridden.
[10:59] <cjwatson> and for Conflicts+Replaces, it says:
[10:59] <cjwatson>             Secondly, <tt>Replaces</tt> allows the packaging system to
[10:59] <cjwatson>             resolve which package should be removed when there is a
[10:59] <cjwatson>             conflict - see <ref id="conflicts">.  This usage only
[10:59] <cjwatson>             takes effect when the two packages do conflict,
[10:59] <cjwatson>             so that the two usages of this field do not interfere with
[10:59] <cjwatson>             each other.
[11:10] <ScottK> If there's a buildd admin around, I'd appreciate it if you would rescore kdepimlibs to start sooner.  I've got a large pile of further rebuilds that are dependent on that being done.
[11:10] <ScottK> Sorry, on power pc.
[11:11] <pitti> ScottK: nudged
[11:12] <ScottK> pitti: Thanks.
[11:40] <tjaalton> mvo: typo in /etc/update-motd.d/daily/10_releae_upgrade :)
[11:51] <mvo> tjaalton: let me have a look
[11:52] <tjaalton> mvo: the filename should have an 's'
[12:00] <mvo> tjaalton: thanks, fixed
[12:02] <tjaalton> mvo: thanks :)
[12:06] <petski> mvo, asac: I was just reading the apturl RFC. I was wondering if PPA's could also be added in the policy. Within launchpad, you quite often see "could you please add my PPA to see if this resolves the issue", it would be super to simplify adding PPA's to the apt sources.
[12:06] <asac> petski: its not ment to be constrained to any particular archive. if your PPA fulfills the requirements it can be whitelisted too
[12:07] <asac> (now that we have signed PPAs)
[12:07] <asac> petski: actually iirc PPAs are even explicitly mentioned somewhere, arent they?
[12:07] <mvo> petski: now that ppas got singnatures we can support ppas as well
[12:09] <asac> petski: seems they are not mentioned in the current version, but there is nothing in it that would exclude PPAs
[12:09] <petski> well, I use my PPA only for bug-fixing, and some bugfixes might not work as expected. I don't think my PPA will pass the 'quality'-test.
[12:10] <asac> heh.
[12:10] <mvo> evand: I think I killed my syslinux boot record on my freshly created usb stick, is there a easy way to get it back without having to run the usb-creator again ?
[12:10] <evand> yes...
[12:12] <evand> dd if=/usr/lib/syslinux/mbr.bin of=/dev/sdb bs=446 count=1 conv=sync
[12:12] <petski> Talking about PPA's ... mvo, already had some time to review https://code.launchpad.net/~petski/update-manager/ppa-support/+merge/3390 ? :)
[12:12] <evand> mvo: ^
[12:12] <mvo> petski: oh, right, I did briefly and commented somewhere too I think
[12:13] <evand> might also want to run syslinux /dev/sdb1 - but the former command will dump a bootloader to your MBR
[12:13] <mvo> evand: thanks! I try it out now
[12:13] <petski> mvo, I haven't received it, I'm afraid
[12:13] <mvo> petski: strange, I wonder where my comment got to
[12:14] <petski> maybe you added it on staging.l.c ?
[12:14] <mvo> petski: https://code.edge.launchpad.net/~petski/update-manager/ppa-support/ <- I put it into the whiteboard - looks like I clicked onthe wrong LP link or something
[12:14] <petski> ah :)
[12:15] <petski> Thanks for your comment. Anything I can do?
[12:16] <mvo> petski: not question :) I wonder if we should just add it nevertheless
[12:16] <mvo> petski: lets jump to #launchpad and ask how they feel about the added load
[12:17] <petski> mvo: the "patch" contains a bugfix as well. IMHO that should be added whatever the launchpad guys say
[12:19] <Adri2000> petski: has this feature been discussed somewhere already? I don't think it's a good idea to integrate ppa like official archive in update-manager. people will think ppa are like official packages and will trust them like official packages...
[12:19] <petski> Adri2000, please take a look at https://code.launchpad.net/~petski/update-manager/ppa-support/+merge/3390
[12:19] <mvo> petski: I have a look again. the problem with the merge was that it is based against the intrpid branch afaics and the jaunty branch changed a bit
[12:20] <Adri2000> petski: I did already
[12:20] <petski> mvo: https://code.launchpad.net/~ubuntu-core-dev/update-manager/jaunty gives 404
[12:21] <mvo> petski: sorry for that, please try https://code.edge.launchpad.net/~ubuntu-core-dev/update-manager/main
[12:21] <mvo> petski: I will see if I can get LP to have a alias so that at least "ubuntu" works
[12:21] <Adri2000> petski: but a comment from Scott and an answer from you is not enough. has it been discussed on a mailing-list for example?
[12:21] <petski> Adri2000, scott shares your thought, my suggestion was to prefix that changelog with something like '[This package originates from a Personal Package Archive]'
[12:23] <cjwatson> I don't see why update-manager is controversial. If the user has already added the archive to sources.list, and has already added the key or acknowledged the warning (we can assume this, otherwise the package won't be eligible for installation), then update-manager should not obstruct matters by refusing to display the changelog
[12:24] <cjwatson> the user has already said that that PPA is OK as far as they're concerned
[12:24] <Adri2000> petski: average user won't consider such a statement as a warning that the package may break their system or steal their private data
[12:24] <IntuitiveNipple> fooey! Evolution 2.25.90 has just duplicated every email in all the folders (more than 10,000), a result, I think, of the import into sqlite db from the mail folders
[12:24] <cjwatson> Adri2000: that warning belongs earlier, not in update-manager
[12:25] <cjwatson> update-manager is not the place where you add the PPA
[12:25] <Adri2000> cjwatson: if update-manager behaves the same way for official trusted packages and ppa packages it will confuse people
[12:25] <cjwatson> Adri2000: this makes no sense. If I have added a PPA to my sources.list then that's because I want to install packages from it
[12:25] <mvo> Adri2000: adding changelog information sounds not too bad to me, a different heading for ppa updates should be used I guess
[12:26] <cjwatson> once somebody has already acknowledged that the archive is untrusted, which I repeat is something that happens earlier when you're adding the PPA in the first place, it doesn't make sense to continue to complain about it
[12:26] <cjwatson> note that if you've added the archive to sources.list, and the key to apt-key, then apt itself will behave the same way for both
[12:27] <DktrKranz> mmh... is http://people.ubuntu.com/~ubuntu-archive/NBS/ running for main only? I cÃ
[12:27] <pitti> DktrKranz: no, it should cover everything
[12:27] <mvo> lool: I *think* I might have a backtrace now for the xine-list ugprade trigger crash
[12:28] <DktrKranz> pitti: I'll have a deeper look, but it seems it doesn't keep track of universe
[12:28] <Adri2000> cjwatson, mvo: I think the average user will think that ppa is somewhat trusted as it is integrated in update-manager, whereas actually ppas are not trusted more than any other thid party repository which is not integrated in update-manager
[12:29] <Adri2000> when I say integrated in update-manager, I mean update-manager will put a special heading "Personal Package Archive", will fetch changelog, etc.
[12:29] <cjwatson> Adri2000: they won't see it in update-manager *at all* unless they have already added the PPA to sources.list and added the key to apt-key, which involves acknowledging warnings about it being untrusted
[12:29] <cjwatson> Adri2000: how many times do you want to warn them?!
[12:30] <cjwatson> integration in update-manager isn't a matter of trust, it's a matter of convenience due to the fact that we know how the archive is laid out, that's all
[12:30] <Adri2000> I just want ppas to be treated like any third party repository. them being hosted on launchpad doesn't change anything
[12:30] <cjwatson> trust is handled separately, and I think it's very important to separate that
[12:30] <cjwatson> I see no reason why we wouldn't fetch changelogs for other third party repositories if we knew how
[12:30] <mvo> Adri2000: I understand your concerns, but I think cjwatson is right here, if we warn them too often peple will just blindly click away the warnings without bothering (and then miss one warning that actually was important)
[12:31] <cjwatson> it's an inconvenience of the archive layout that this requires special knowledge
[12:31] <Adri2000> because people will say "ah, update-manager knows repository X, so ubuntu people should know it, it should be safe to use"
[12:31] <geser> adding more warnings won't help. either they know what they are doing or not (following just a howto which tells them what commands to run and where to click)
[12:31]  * mvo wonders if we should have a "X-Changelog-URI" in the packages file so that it could be supported for other archives as well
[12:31] <cjwatson> you're talking as if update-manager is the first place people will see PPAs
[12:31] <cjwatson> it isn't
[12:32] <petski> mvo: I like the idea
[12:32] <cjwatson> if they see it in update-manager, they have already taken the decision to use that PPA
[12:32] <Adri2000> actually I was speaking of warning in case we really want update-manager to show ppa packages in the special section. I'd very much prefer them to stay in the third party repo section
[12:32] <cjwatson> being concerned about its presentation in update-manager seems precisely backwards to me
[12:33] <cjwatson> software-properties and the like is where people take decisions about whether an archive is safe to use
[12:33] <Adri2000> mvo: if that X-Changelog-URI is implemented, so any third party repository could use it, then I wouldn't be against update-manager fetch changelogs from there, being for ppa repo or any other third party repo
[12:34] <cody-somerville> My NetworkManager keeps crashing but apport keeps failing to report it because when it tries to open Firefox a popup comes up and says firefox is already running, blah blah blah
[12:35] <cody-somerville> There appears to be some sort of bug in nm_connection_clear_secrets()
[12:35] <cody-somerville> asac, ^^
[12:38] <Adri2000> I'm under the impression that people generally trust more ppa packages than other third party packages because they are hosted on launchpad. that kind of features will just confirm that idea to them
[12:39] <cjwatson> it doesn't matter by that point
[12:39] <cjwatson> they've already signed on the dotted line
[12:44] <Adri2000> well, I'd be interested to see if I'm the only one thinking that way
[12:48] <kirkland> mdz: do you have a work around for https://bugs.edge.launchpad.net/ubuntu/+source/openssh/+bug/328445 yet?
[12:48] <kirkland> mdz: i'm uploading a new key to launchpad every time i reboot
[12:48] <mvo> lool: I have a theory about the xine-list-1.1 crash, it might be something with nvidia not setting the libGL links corretly during a upgrade (or something equally crazy). the crash seems to be happening inside libgl
[12:49] <lool> mvo: In a meeting, coming back to you soon
[12:49] <asac> cody-somerville: is that with vpn?
[12:49] <cody-somerville> asac, aye
[12:49] <kirkland> mdz: and simply unable to use people.ubuntu.com and chinstrap, etc.
[12:50] <asac> cody-somerville:  i think i saw that too ... can you get a backtrace manually from the .crash file or run nm in gdb?
[12:50] <cody-somerville> asac, Where are the .crash files kept?
[12:50] <cody-somerville> oh
[12:50] <cody-somerville> found them
[12:50] <asac> cody-somerville: /var/crash ... you need to use apport-unpack first and then use gdb on the Core
[12:51] <asac> with dbgsym installed and so on...
[12:51] <asac> cody-somerville: not sure about the firefox already running thing. is there a ffox already running? does it open if you try to open it manually?
[12:52] <cody-somerville> asac, Yes it is and yes it does
[12:53] <asac> cody-somerville: sounds a bit like an apport bug then
[12:54] <asac> jaunty?
[12:54] <cody-somerville> yup
[12:54] <asac> cody-somerville: when it says that can you look what command line you see in ps?
[12:54] <asac> (e.g. before closing that dialog)
[12:54] <cody-somerville> sure
[12:56] <lool> mvo: So, backtrace?  :)
[12:56] <cody-somerville> asac, I've marked two bugs as duplicate of bug #318554
[12:56] <lool> mvo: Oh libGL, ugly
[12:57] <lool> Sounds like absolute fun
[12:57] <asac> cody-somerville: thanks for the cleanup ;)
[12:57] <mvo> lool: yeah :) I wait for the retracer before I make further conclusions, need to debug some compiz stuff
[12:58] <lool> mvo: compiz uses GL, it's all clear to me now: compiz broke intrepid
[12:58] <lool> I knew it
[12:58] <mvo> lool: haha
[12:59] <mvo> lool: the crash happend for me in a text console, no X running ;)
[12:59] <asac> cody-somerville: ok the dupes had bt
[12:59] <mvo> lool: don't be a seb128 and try to push all the blame to compiz, we all know its a gtk bug in the end anyway :P
[12:59] <cody-somerville> asac, I attached my stacktrace too
[12:59]  * mvo hugs seb128
[13:00]  * seb128 hugs mvo
[13:00] <lool> mvo: I bet that compiz was installed and had been run at least once before on these computers; that kind of voids your Gtk+2.0 warranty I'm afraid
[13:01] <mvo> haha
[13:01] <asac> cody-somerville: what type of vpn do you use?
[13:01] <cody-somerville> asac, OpenVPN
[13:06] <cody-somerville> asac, Also, you wouldn't know how to get flash working again in Jaunty do you? The package is installed but Firefox doesn't recognize it.
[13:07] <davmor2> cody-somerville: voodoo
[13:11] <asac> cody-somerville: what does it recognize in about:plugins
[13:12] <cody-somerville> QuickTime,Windows Media Player Plug-in 10, DivX® Web Player, Default Plugin, Demo Print Plugin for unix/linux, and Java(TM) Plug-in 1.6.0_12-b04
[13:13] <asac> ok check whether the xulrunner-addons-flashplugin alternative is correct
[13:15] <cody-somerville> sudo update-alternatives --config xulrunner-addons-flashplugin
[13:15] <cody-somerville> No alternatives for xulrunner-addons-flashplugin.
[13:15]  * cody-somerville can never remember how to correctly use update-alternatives
[13:19] <cody-somerville> asac, There is no xulrunner-addons-flashplugin alternative
[13:22] <cody-somerville> seb128, Is there something wrong with rhythmbox's shuffle? I seem to always get the same ol' songs out of the 710 songs I have.
[13:22] <broonie>  21
[13:23] <cody-somerville> asac, Maybe I want to install adobe-flashplugin instead of what Firefox tried to get me to install?
[13:24] <cody-somerville> asac, that worked
[13:24] <seb128> cody-somerville: not that I know
[13:26] <cody-somerville> seb128, Its a rather serious bug. Its affecting my sanity. I can only listen to so much ABBA in one day ;]
[13:26] <seb128> cody-somerville: there is a gconf key to change the shuffle algorhythm try another one?
[13:26] <cody-somerville> oh, neat
[13:26] <cody-somerville> seb128, I'll do that. Thanks.
[13:27] <cody-somerville> seb128, Whats the key's name?
[13:29] <seb128> cody-somerville: there is not so many rhythmbox key is it? let me have a look for you
[13:29] <seb128> that's /apps/rhythmbox/something
[13:30] <cody-somerville> Is it maybe /apps/rhythmbox/state/play_order ?
[13:30] <cody-somerville> oh no wonder!
[13:30] <cody-somerville> random-by-age-and-rating
[13:30] <seb128> right
[13:30] <cody-somerville> No wonder I get so much ABBA! Its ancient!
[13:30] <seb128> the default is linear
[13:32] <cody-somerville> seb128, Thank you so much. You're a life saver.
[13:33] <seb128> you're welcome
[13:33] <seb128> you did change the key or used a software which changed it btw
[13:33] <seb128> because that value is not the stock one
[13:33] <emgent> calc: ping
[13:33] <ScottK> TheMuso: I see I need to add sparc to my list of ports with working kernels.
[13:33] <cody-somerville> seb128, Weird. I've never opened gconf-editor before
[13:34] <seb128> you perhaps used some tweakit tool which did it
[13:34] <emgent> calc: when you come back please take a look and vote http://marketing.openoffice.org/ooocon2009/cfl/orvieto.html :)
[13:37] <cody-somerville> seb128, no
[13:37] <seb128> dunno why it changed then
[13:37] <cody-somerville> seb128, IF you enable shuffle and repeat, it goes to "random-by-age-and-rating"
[13:38] <seb128> ah
[13:40] <cody-somerville> seb128, a rather unintended consequence ;]
[13:43] <asac> cody-somerville: you sure you had flashplugin-nonfree installed?
[13:43] <mdz> kirkland: no, I don't
[13:44] <mdz> kirkland: well, apart from disabling the agent
[13:44] <cody-somerville> asac, Yes. It got removed when I installed adobe-flashplugin
[13:44] <mdz> env -u SSH_AUTH_SOCK ssh ...
[13:45] <mdz> kirkland: could you add a link to the new bug to that old bug which was similar but said to be unrelated?
[13:45] <mdz> I've lost track of it
[13:45] <cody-somerville> asac, https://pastebin.canonical.com/13783/
[13:45] <kirkland> mdz: i already did
[13:45] <seb128> kirkland, mdz: what was the question?
[13:45] <mdz> seb128: workaround
[13:45] <mdz> kirkland: great, thanks
[13:46] <kirkland> mdz: the old bug was https://bugs.launchpad.net/bugs/201786
[13:46] <seb128> mdz: what is the issue?
[13:46] <seb128> kirkland: I doubt it's it
[13:46] <mdz> seb128: bug 328445
[13:46] <kirkland> seb128: the new bug is https://bugs.launchpad.net/bugs/328445
[13:46] <seb128> gnome bug #571060
[13:46] <seb128> and
[13:46] <mdz> seb128: I filed a new bug as you said it was unrelated to that old one
[13:46] <seb128> gnome bug #571422
[13:46] <seb128> mdz: right
[13:47] <seb128> one issue is due to dsa keys, the other one not sure
[13:47] <kirkland> i'm using rsa
[13:47] <seb128> so that's the second one
[13:48] <seb128> mdz: bug #328127
[13:50] <kirkland> mdz: aha, mdeslaur's workaround works for me
[13:50] <kirkland> unset SSH_AUTH_SOCK
[13:51] <mdz> kirkland: <mdz> env -u SSH_AUTH_SOCK ssh ...
[13:51] <seb128> kirkland: set it to /tmp/ssh-... and run ssh-add
[13:51] <seb128> so you have an agent again
[13:52] <kirkland> mdz: sorry missed that one
[13:52] <mdz> kirkland: it doesn't get the agent working again, so it's only a partial workaround
[13:52] <mdz> sounds like seb128 may have a better one
[13:58] <kirkland> seb128: Could not open a connection to your authentication agent.
[13:59] <seb128> kirkland: do you have a socket in /tmp/ssh-.......
[13:59] <seb128> and did you set SSH_AUTH_SOCK to this one?
[14:00] <kirkland> seb128: export SSH_AUTH_SOCK=/tmp/ssh-ilNHaf4279/agent.4279
[14:00] <kirkland> seb128: ssh-add
[14:00] <kirkland> Could not open a connection to your authentication agent.
[14:00] <seb128> ok, I don't know then, that's working on my box
[14:02] <maxb> I think the x11 startup scripts decline to start a ssh-agent if one is already running (e.g. gnome-keyring's one) ?
[14:02] <maxb> Workaround: gconftool -s /apps/gnome-keyring/daemon-components/ssh -t bool false
[14:08] <cody-somerville> seb128, Also, I dunno if you say my bug report, but gedit in jaunty double frees right now when you quit
[14:09] <seb128> cody-somerville: I did, there is nothing really useful in the log and it doesn't do it for me either
[14:09] <cody-somerville> seb128, maybe its a plugin?
[14:09] <seb128> could be
[14:10] <seb128> try disabling those and see if it still crash
[14:32] <DktrKranz> pitti, I checked some NBS results. i.e. http://people.ubuntu.com/~ubuntu-archive/NBS/libgconf2.0-cil, it lists only a couple of main packages but there are several packages in universe still b-d on old libgconf2.0-cil. This happens with several other packages listed.
[14:37] <ember> DktrKranz i will update tomboy as it was blocked due to gnome-desktop-sharp2
[14:39] <Laney> ember: did you forward the patch?
[14:41] <ember> Laney to slomo?
[14:41] <Laney> ye
[14:41] <DktrKranz> ember: cool. If you're interested in that, there are several packages which need love (bug #314516)
[14:42] <ember> Laney sure.
[14:42] <Laney> goodo
[14:44] <Keybuk> pitti: http://people.ubuntu.com/~pitti/tmp/bootchart-parallel-readahead/jaunty-20090212-sync-readahead.png
[14:45] <Keybuk> your machine is not a happy one
[14:52] <seb128> cody-somerville: do you use the seahorse gedit plugin? see bug #327252
[14:54] <cody-somerville> seb128, yup
[14:54] <seb128> cody-somerville: bug dupped then
[14:54] <cody-somerville> thanks
[14:54] <seb128> you're welcome
[15:00] <doko> ubuntu-archive: please accept mpfr in NEW
[15:07] <primes2h> pitti: Hi, BTW did you have a look at the patch for this bug #172353 ?
[15:10] <primes2h> pitti: I mean, at the debdiif.
[15:35] <pitti> Keybuk: any idea how to make it more happy?
[15:35] <seb128> in which way it's unhappy?
[15:35] <pitti> primes2h: high on my list
[15:36] <primes2h> pitti: Thank you :-)
[15:36] <Keybuk> well, your disk IO is high all the way through the boot
[15:37] <Keybuk> one CPU is spent almost entirely in I/O wait
[15:37] <Keybuk> I know this sounds like a bad thing, but have you run memtest and badblocks on that?
[15:38] <seb128> Keybuk: that's because it uses a real disk and not a fast sdcard or whatever you are using? ;-)
[15:38] <Keybuk> seb128: pitti's laptop and mine are near-identical
[15:38] <seb128> Keybuk: my bootchart are IO high almost during the whole boot too
[15:38] <Keybuk> and my bootchart doesn't look like that
[15:38] <pitti> Keybuk: what does sudo hdparm -tT /dev/sda show for you?
[15:39] <pitti> Keybuk: this is a clean jaunty install from three days ago..
[15:39] <seb128> Keybuk: do you have a chart from your laptop online somewhere?
[15:39] <pitti> plus some extra packages, of course, but nothing particular that affects booting
[15:39] <seb128> Keybuk: I'm just curious to see the difference
[15:39] <Keybuk> no, I've actually not put bootchart on here yet
[15:39] <Keybuk> the disk failed during the sprint!
[15:40] <Keybuk> pitti: 1600 MB in 2.00s seconds = 800.53 MB/sec
[15:40] <Keybuk> 50 MB in 3.12 seconds = 16.03 MB/sec
[15:41] <Keybuk> pitti: what's odd is that there's no process to account for all that I/O
[15:41] <pitti> Keybuk: I have 660 MB/s cached and 25 MB/s uncached, so that shouldn't be so much different
[15:41] <pitti> (even looks faster than your's..)
[15:41] <Keybuk> you have an entire CPU in I/O wait, that should show up like a sore thumb!
[15:43] <pitti> Keybuk: how long does it take from grub->gdm and gdm->desktop on your d430?
[15:43] <davmor2> guys strange question.  If I were to hit ctrl-l in nautilus and type in an sftp://user@machine after it's asked for the password should it goto /home/user on the machine or just / ?
[15:43] <Keybuk> davmor2: yes
[15:44] <davmor2> Keybuk: yes to what sorry?
[15:44] <pitti> Keybuk: it goes to / for me, too
[15:44] <davmor2> it should go to /home/user
[15:44] <Keybuk> davmor2: yes, it should go to /home/user or /
[15:44] <Keybuk> I think the current trend is /
[15:44] <seb128> davmor2: it should not go to your user directory
[15:45] <Keybuk> pitti: 15-17s or so I think
[15:45] <pitti> Keybuk: !
[15:45] <Keybuk> pitti: just doing an upgrade to see if it's something recent that's broke it
[15:46] <davmor2> Keybuk: seb128: Okay thanks it's just in others it goes to /home/user and I thought I'd better check
[15:46] <pitti> Keybuk: that's grub->gdm?
[15:46] <Keybuk> pitti: right
[15:46] <Keybuk> davmor2: sftp urls are a bit wishy-washy, I think the current trend is that sftp://user@machine/ means /
[15:46] <davmor2> thanks guys
[15:47] <seb128> Keybuk: my current desktop is weird, http://people.ubuntu.com/~seb128/jaunty-20090212-7.png
[15:48] <seb128> Keybuk: do you have any idea why it's sitting there for 10 seconds before booting?
[15:48] <Keybuk> weird
[15:48] <seb128> indeed
[15:48] <Keybuk> corrupt swap partition?
[15:48] <Keybuk> cat /proc/swaps
[15:48] <seb128> I think it's just display the Loading information ... line during that time
[15:49] <Keybuk> no, it's in "resume"
[15:49] <seb128>  cat /proc/swaps
[15:49] <seb128> Filename				Type		Size	Used	Priorit
[15:49] <seb128> no swap
[15:49] <Keybuk> your swap has been corrupted by a bad hibernate
[15:49] <Keybuk> that probably explains all that I/O too - your computer is paging like mad
[15:49] <seb128> how do I fix that now?
[15:49] <Keybuk> grep swap /etc/fstab
[15:49] <seb128> UUID=10539512-374f-4517-8998-e550a1ebc4b3 none            swap    sw              0       0
[15:50] <pitti> Keybuk: indeed it currently takes about 15 seconds until usplash even starts
[15:50] <Keybuk> mkswap -U 10539512-374f-4517-8998-e550a1ebc4b3 /dev/sdXY
[15:50] <pitti> Keybuk: there's a possiblity that the new kernel did something different, or that it's ext4 specific
[15:50] <Keybuk> pitti: ext4 is kinda interesting, I've had several problems with it
[15:54] <majeru> hello, are there any serious reasons why desktop x86 kernel lacks PAE support?
[15:54] <Keybuk> majeru: it breaks old computers
[15:54] <Keybuk> those with valves in them
[15:55] <majeru> Keybuk: what kind of computers?
[15:55] <Keybuk> majeru: 486s, etc.
[15:55] <majeru> okay
[15:55] <MacSlow> What's needed after "bzr revert -r n" to really touch and alter the files?
[15:56] <majeru> but there could be an extra kernel package compiled with PAE, i guess
[15:57] <Keybuk> I tend to believe the opposite; our default distribution should be built for i686 with PAE, etc.
[15:57] <majeru> i agree
[15:57] <Keybuk> and if we really need support for older machines, we could have a different architecture or something
[15:57] <Keybuk> others disagree with me ;)
[15:57] <majeru> anyway, ubuntu is damn slow on 486 boxes
[15:57] <majeru> so we should move on
[15:58] <Keybuk> ubuntu is slow on 686 boxes because we support 486 boxes
[15:59] <cjwatson> majeru: there *is* such an extra kernel package with PAE: -server
[15:59] <majeru> IMHO, ubuntu should target currently-produced hardware
[15:59] <cjwatson> and PAE has problems on more than just 486s AFAIK
[16:00] <cjwatson> but I can't remember where the bug about that is right now
[16:00] <majeru> cjwatson: but the server one is incompatible with some drivers
[16:00] <Keybuk> cjwatson: every other major distribution uses PAE without problem
[16:00] <Keybuk> they use -march=686 too
[16:00] <Keybuk> (note: very annoyed about this :p)
[16:00] <cjwatson> you seem to have an astonishing familiarity with every other major distribution's complete list of bugs ;-)
[16:01] <cjwatson> I get bug reports about systems that fail server installations due to PAE
[16:01] <cjwatson> they aren't 486s either
[16:01] <Keybuk> cjwatson: they just don't consider old hardware not being supported a bug
[16:02]  * Keybuk files a bug that the kernel doesn't boot on an IBM XT
[16:02] <Keybuk> can we fix that?
[16:02] <cjwatson> don't be ridiculous
[16:02] <Keybuk> we have honest, true, benchmark comparisons with other Linux distributions that show that Ubuntu is generally slower
[16:02] <cjwatson> bug 151942, bug 227869
[16:02] <Ng> aren't there some VIA CPUs that don't work with full 686 build stuff? istr the C3 in my mini-ITX box is such a thing
[16:02] <majeru> well, computers older than pentium3 can barely run Ubuntu with GUI
[16:02] <Keybuk> and this can generally be attributed to the fact we don't use -march=686
[16:03] <Keybuk> modprobe being the higher profile case recently
[16:03] <Ng> it's almost a 686, but not quite, or something
[16:03] <cjwatson> ridiculous hyperbole doesn't remotely help your case, though
[16:03] <Keybuk> my case has already been thrown out
[16:03] <Keybuk> ridiculous hyperbole is all I have left
[16:04] <majeru> please calm down the flames
[16:04] <majeru> :)
[16:04] <cjwatson> if the kernel could switch at run-time between PAE and non-PAE using alternatives, I'd be all for us supporting PAE by default
[16:04] <majeru> so there are CPUs that don't support PAE
[16:04] <Keybuk> it cannot switch at runtime
[16:05] <majeru> what if the bootloader choses the best ?
[16:05] <cjwatson> majeru: unfortunately we don't have space on the Ubuntu CDs for more than one kernel
[16:05] <cjwatson> hence my comment about alternatives
[16:05] <majeru> when installing the system
[16:05] <majeru> okay
[16:06] <cjwatson> Ng: yes, VIA C3 systems are mentioned in at least one of the bugs I quoted above
[16:06] <cjwatson> they are (AFAIK) currently-manufactured hardware on which PAE breaks
[16:06] <Ng> carry a non-PAE kernel on the installer, have some magic that bumps you up to a better kernel if your hardware supports it? horrible hackery \o/
[16:06] <Keybuk> cjwatson: and there's currently manufactured hardware that requires PAE to operate as intended
[16:07] <Keybuk> Ng: nobody has ever come up with a way to do that
[16:07] <cjwatson> Ng: needs either (a) two kernels on the CD (b) alternatives (see above)
[16:07] <Ng> cjwatson: sorry, bu "bumps you", I meant "downloads it post-install". doesn't help with the case of requiring PAE, so it's not a useful suggestion other than improving post-install performance, I guess
[16:08] <majeru> i wonder how hard would it be to make the kernel support both and be able to choose at runtime
[16:08] <cjwatson> I have never heard of hardware that actually requires it to function - only for performance
[16:08] <cjwatson> well, and high memory
[16:08] <Keybuk> cjwatson: it's required to access all memory
[16:08] <majeru> i'm interested about the memory side of it
[16:08] <cjwatson> but we do install a PAE kernel by default on server installations
[16:09] <cjwatson> which I suspect are the majority of cases requiring high memory at the moment
[16:09] <majeru> nowadays desktops tend to get closer to the 4gig limit
[16:09] <Keybuk> not true, desktops increasingly come with more memory
[16:09] <cjwatson> "majority" "at the moment"
[16:09] <Keybuk> you can't even boot Windows XP on non-PAE machines
[16:09] <cjwatson> oh and "suspect"
[16:09] <Keybuk> thus my belief that if we really must support older hardware, it should be done in a different CD - and our desktop CD should support current hardware
[16:10] <cody-somerville> 0_o
[16:10] <cjwatson> StevenK: I figured out the UMPC syslinux/gfxboot bug
[16:10] <majeru> Keybuk: amd64 does that, most of the current cpus are 64bit :p
[16:11] <Keybuk> majeru: but most users still avoid the 64bit CD because of issues with things like flash
[16:11] <cjwatson> StevenK: turns out it's because your cdimage code uses the build system's syslinux, which is hardy; I fixed this syslinux bug in intrepid ...
[16:11] <majeru> Keybuk: yes
[16:11] <majeru> Keybuk: but why not make it like sparc64 did it
[16:11] <majeru> 64bit kernel and 32bit userland
[16:12] <cjwatson> StevenK: install a *current* syslinux on it and it works perfectly
[16:12] <majeru> and make 64bit apps only for the apps that really need large integers
[16:12] <cjwatson> majeru: last I checked, several of the 32->64bit thunks didn't actually work properly
[16:12] <cjwatson> majeru: in fairly important areas - USB or printing or something like that
[16:12] <majeru> i agree
[16:13] <cjwatson> you asked why; if you agree, why did you ask? :-)
[16:13] <majeru> but as the hardware is evolving in this direction, they will also evolve
[16:19] <seb128> Keybuk: ok, that fixed the 5 seconds resume call, but still not the 5 first seconds where it's doing nothing
[16:19] <Keybuk> seb128: got an updated chart?
[16:20] <seb128> Keybuk: http://people.ubuntu.com/~seb128/jaunty-20090212-8.png
[16:23] <Keybuk> seb128: got a copy of /var/log/dmesg as well?
[16:23] <Keybuk> and kern.log
[16:24] <seb128> Keybuk: http://people.ubuntu.com/~seb128/dmesg http://people.ubuntu.com/~seb128/kern.log
[16:25] <Keybuk> hmm, your missing 5s are somewhere between kernel init and initramfs
[16:25] <Keybuk> if you do break=top, how long does it take (stopwatch) after grub to get there?
[16:26] <seb128> let me try
[16:34] <seb128> Keybuk: 5 seconds
[16:35] <Keybuk> ok, so it's somewhere in the kernel :-/
[16:35] <Keybuk> if you boot without quiet, does anything show up in the waiting time?
[16:35] <Keybuk> (I doubt it, since there's nothing in dmesg)
[16:35] <seb128> no
[16:37] <seb128> ok, not a big issue anyway, I get that only on my desktop box
[16:43] <cjwatson> StevenK: getting the right syslinux content in place is a bit non-trivial. Could you take care of that please?
[16:47] <cjwatson> slangasek: re grub2, looks like we need to get at least grub-common promoted to main anyway; the XFS handling in grub-install now depends on it (currently undeclared)
[16:48] <slangasek> sounds reasonable
[16:48] <cjwatson> I think I might just file a bug though
[16:58] <Keybuk> bryce, tjaalton: how much do you know about xkbcomp?
[17:00] <wasabi> Hmm. Latest console-setup package is... locking up during configure.
[17:00] <wasabi> From SSH anyways.
[17:00] <bryce> Keybuk: not deeply, just that it's useful for getting certain kbd debug info upstream always wants
[17:00] <wasabi> The console stuff is one aspect of this system I seem to have never figured out much about.
[17:00] <bryce> Keybuk: but I can find out more if there's an issue in it
[17:03] <Keybuk> bryce: so our X server always runs xkbcomp on startup to compile its keymap-of-the-day
[17:04] <bryce> o_O
[17:04] <Keybuk> instead of us just precompiling them in the package
[17:04] <bdmurray> jdstrand: I added the ufw package bug guidelines thanks!
[17:04] <wasabi> setupcon --force is stopping.
[17:05] <jdstrand> bdmurray: np :)
[17:05] <bryce> Keybuk: sounds... inefficient.  can we change that?
[17:05] <Keybuk> bryce: I have a patch to change it
[17:05] <Keybuk> but I can't figure out the xkbcomp invocations I need to precompile them ;P
[17:07] <bryce> Keybuk: looking at the man page there is a -xkm flag - did you already test that?
[17:08] <Keybuk> oh, no, I'm just being silly
[17:08] <Keybuk> the patch actually still invokes xkbcomp, it just doesn't delete the output after so it can reuse it next time
[17:08] <bryce> ahh
[17:08] <Keybuk> the reason my keyboard map is "wrong" is that I've never set it, lol
[17:09] <Keybuk> function keys, etc. work which implies X isn't lobotomised
[17:20] <cjwatson> wasabi: a sh -x trace of what setupcon is doing would help
[17:22] <ScottK> bdmurray: Thanks for taking care of ubuntu-qa-tools bugmail.
[17:22] <wasabi> + /bin/echo -n -e \033%G
[17:22] <wasabi> that's the last line
[17:23] <wasabi> not sure where that's heading to
[17:23] <wasabi> need to understand the script first. :)
[17:23] <bdmurray> ScottK: no problem, I didn't realize LP behaved that way
[17:23] <tritium> kirkland: does ecryptfs meet FIPS 140-2?
[17:24] <Keybuk> pitti: hmm, after the latest update to jaunty I see the continuous IO too
[17:24] <wasabi> /bin/echo -n -e '\033%G' >$console    that's probably it
[17:24] <Keybuk> also my keyboard has gone uppity ;)
[17:24] <ScottK> bdmurray: Every week it seems to find a new way to send me stuff I don't care about ...
[17:24] <cjwatson> wasabi: it's supposed to go to the console, indeed
[17:24] <cjwatson> wasabi: do you *have* a working console on this system?
[17:24] <kirkland> tritium: ecryptfs has not been certified against anything
[17:24] <wasabi> As in true console or pseudo?
[17:25] <wasabi> machine seems to be normal to me. :0
[17:25] <tritium> kirkland: ok, does it rely on anything such as openssl that hsa been?
[17:25] <cjwatson> wasabi: as in a device that won't block when you write to it :P
[17:25] <tritium> has*
[17:25] <cjwatson> wasabi: it's writing to one of /dev/tty[1-6]
[17:25] <wasabi> Ahh. Those should be fine.
[17:25] <cjwatson> wasabi: maybe an strace
[17:25] <cjwatson> ?
[17:25] <wasabi> Looks like tty5 blocks
[17:25] <kirkland> tritium: for the filesystem and filename encryption, it uses the encryption algorithms in the linux kernel
[17:26] <wasabi> sysadmin tty5     -                27Aug08 169days  0.42s  0.01s /bin/login --
[17:26] <wasabi> Just sitting at a login prompt.
[17:26] <kirkland> tritium: i don't think those have been certified (matter of cost, and changing too much over time)
[17:26] <kirkland> tritium: but they are well vetted
[17:26] <tritium> kirkland: hmm, ok.  Thank you.  I do appreciate the quick reply.
[17:26] <kirkland> tritium: there is an openssl key module, however
[17:26] <wasabi> on another machine both 1 and 4 block.
[17:27] <cjwatson> maybe we should only do the UTF-8 setup at boot. not sure
[17:27] <tritium> kirkland: :)
[17:27] <cjwatson> or at least not when running the thing from postinst
[17:28] <kirkland> tritium: i've never used it
[17:28] <wasabi> I am ignorant about what could block up a tty
[17:28] <wasabi> But I find it odd that 3 servers have various ones blocked up here.
[17:29] <tritium> kirkland: nor have I.  I'll do some more research.  I'm working on a proposal that would use jaunty with ecrypfs, but one of my external requirements is that it meet FIPS 140-2.
[17:29] <kirkland> tritium: nice ;-)  good luck with that
[17:30] <tritium> kirkland: thanks!
[17:30] <kirkland> tritium: the few things in Linux that have been FIPS-certified were mostly done by RH + IBM
[17:30] <kirkland> tritium: and it's always a year+ after release
[17:31] <tjaalton> Keybuk, bryce: that has been discussed upstream, but AIUI it's not trivial to fix
[17:31]  * kirkland has worked on EAL certifications of RHEL/SLES in lives past ;-)  (blah)
[17:31] <tritium> kirkland: ah, ok
[17:31] <Keybuk> tjaalton: http://people.ubuntu.com/~scott/xkbcomp.patch
[17:32] <tjaalton> Keybuk: oh, quite fresh too :)
[17:35] <awsoonn> where would I look to add functionality to the Fn keys on my laptop?
[17:36] <tjaalton> Keybuk: doesn't seem to be applied upstream
[17:36] <awsoonn> I suppose I should be more specific: the touchpad enable/disable button.
[17:36] <Keybuk> tjaalton: Intel in only applying patches in their own packages shocker ;)
[17:36] <tjaalton> Keybuk: bah :)
[17:36]  * Keybuk found it in the Moblin packages
[17:39] <tjaalton> Keybuk: so it speeds up starting X clients?
[17:40] <Keybuk> it speeds up starting the X server
[17:40] <tjaalton> it takes less than two seconds here
[17:40] <Keybuk> I envy you, it takes over 5s here without the patch
[17:40] <tjaalton> heh
[17:41] <tjaalton> but hot-starting gnome takes a long time, with practically no disk activity
[17:41] <awsoonn> tjaalton: what patch are you guys talking about /me is interested
[17:41] <pochu> awsoonn: 18:31 <    Keybuk> tjaalton: http://people.ubuntu.com/~scott/xkbcomp.patch
[17:41] <awsoonn> pochu: thanks
[17:43] <bryce> awsoonn: regarding your earlier question, see http://wiki.ubuntu.com/Hotkeys
[17:45] <slangasek> awsoonn: FWIW, touchpad enable/disable is a known bug on acpi-support, which I'm going to work on next week
[17:54] <LaserJock> asac: I'm a bit confused by the apturl RFC
[17:54] <LaserJock> asac: do you have any example packages/repos ?
[17:55] <LaserJock> If a 3rd-party repo can't be in Ubuntu due to licensing, I would think it would fail the LP requirements for FLOSS projects as well
[17:58] <ScottK> LaserJock: I had the same thought.
[17:58] <awsoonn> slangasek: feel free to e-mail me for testing/assistance. So you wold around the touchpad area much? I might have a -semi-related question for you. :)
[17:59] <ScottK> LaserJock: Alternatively, if there is a contractual arrangement between Canonical and the third party to allow it, then I don't see why Partner wouldn't serve just as well.
[17:59] <cjwatson> LaserJock: I fixed the way DVDs preseed tasksel, I think - just after you left last night
[18:01] <slangasek> awsoonn: I'm working on hotkey-related issues; I don't do a lot with touchpads specifically, that's more tjaalton's domain I think
[18:01]  * awsoonn is learning a lot today
[18:02] <tjaalton> slangasek: I'll toss that ball to wgrant, I don't even have a touchpad :)
[18:02] <slangasek> oh. :)
[18:03] <awsoonn> ironicly enough, the touchpad I'm trying to fix belongs to someone named grant
[18:05] <LaserJock> cjwatson: oh yeah, so when will a DVD show up I can test? are they dailies?
[18:06] <cjwatson> LaserJock: twice-weekly or something like that
[18:06] <LaserJock> cjwatson: ok, cool, thanks for that
[18:06] <cjwatson> LaserJock: 17 12 * * 2,6   buildlive ubuntu-dvd; for-project ubuntu cron.dvd
[18:07] <cjwatson> so Tue/Sat
[18:07] <LaserJock> great, I try it out next week
[18:07] <LaserJock> *I'll
[18:15] <mr_pouit> superm1: the patch is missing from your branch (at least it was when I quickly looked this afternoon).
[18:25] <slytherin> can anyone please give back xorg-server on powerpc?
[18:25] <pitti> slytherin: poked
[18:26] <superm1> mr_pouit, oh did i forget a bzr add :S?  i'll poke it in a little bit
[18:28] <ebroder> Any backporters around that could take a look at bug #323546?
[18:29] <tjaalton> slytherin: why? it doesn't build until the ports are running 2.6.28
[18:30] <jdong> ebroder: looking
[18:30] <slytherin> tjaalton: ports now have 2.6.28 kernel.
[18:31] <tjaalton> slytherin: so libdrm needs to be fixed next
[18:31] <LaserJock> can I assume that a package that cannot reinstall after a failed install is a bug?
[18:31] <asac> LaserJock: i dont think launchpad prevents that. most likely they need to get explicitly permission, which should be ok.
[18:32] <jdong> ebroder: seems a bit hacky... this doesn't stop (likely nonfunctional) mixes of 3.2/3.3 alt deps, right?
[18:32] <slytherin> tjaalton: the failure I saw in build log was because of libgl1-mesa-dev installation problem. This problem should not exist now so I thought it was good idea to give bacl xorg-server
[18:32] <LaserJock> asac: well, I think you have to pay for non-FLOSS LP projects
[18:32] <LaserJock> or something like that
[18:32] <LaserJock> so I'm just wondering how common of a use case this is
[18:33] <tjaalton> slytherin: mesa doesn't build either, that's why
[18:33] <ebroder> jdong: Correct. I can try to come up with a packaging that splits things off into, e.g., ubuntu-xen-server-3.2 and ubuntu-xen-server-3.3 and then has ubuntu-xen-server depend on ubuntu-xen-server-3.2|ubuntu-xen-server-3.3, but I'm not sure how that looks when you upgrade into Intrepid
[18:34] <jdong> ebroder: how often is it that one would want both 3.2 and 3.3 installed on the same system?
[18:34] <tjaalton> slytherin: they both need the drm headers from linux-libc-dev (>2.6.28-foo)
[18:34] <ebroder> jdong: You can't mix and match. For that matter, you can't really mix. A few of those packages conflict with their differently-versioned counterparts
[18:35] <slytherin> tjaalton: It has built, at least on powerpc. https://edge.launchpad.net/ubuntu/jaunty/+source/mesa/+builds
[18:35] <LaserJock> asac: when you consider Multiverse + Partner, I'm not sure what the use of these "trusted 3rd party" repos are? especially considering how much process your proposal is adding
[18:35] <jdong> ebroder: ok, then would it be reasonable to simply offer xen-meta that depends on pure 3.3 in backports, and if one chooses to upgrade (in fact, dist-upgrade) to the backports version they will be forced onto -3.3?
[18:35] <asac> LaserJock: partner is not enabled by default
[18:35] <slytherin> tjaalton: http://ports.ubuntu.com/pool/main/l/linux-ports/linux-libc-dev_2.6.28-1.4_powerpc.deb
[18:35] <asac> it has a good placement in the software sources dialog afaik
[18:36] <LaserJock> asac: neither is a 3rd-party apt-url repo, right?
[18:36] <ebroder> jdong: That's plausible. Having -backports turned on does already break Xen 3.2 if you're not careful (see bug #297077)
[18:36] <tjaalton> slytherin: ok, nice
[18:37] <asac> LaserJock: no, but you can enable it through apturl ;)
[18:37] <asac> LaserJock: if it got whitelisted
[18:37] <jdong> ebroder: yay accurate abinum bumping :). I think pure-3.3 in backports is the best approach for this; would  you like to put on a debdiff for this?
[18:38] <LaserJock> asac: but it could just as well make Partner more prominent in Software Sources
[18:38] <ebroder> jdong: Sure, I can do that. I've got to go AFK for a bit, but I'll put it up later. Thanks for the help
[18:38] <LaserJock> like with -proposed and -backports or something
[18:38] <jdong> ebroder: yeah I shoudl go back to listening to 6.004 lecture too; ping me after you attach it :)
[18:39] <kees> LaserJock: okay, so, what's the state of moodle?  I wanted to start digging into all the recent updates so we can get them into the stable releases.
[18:40] <LaserJock> kees: well, I've apparently joined the Debian maintanence team
[18:40] <kees> sweet
[18:40] <LaserJock> kees: I'm working on the merge
[18:40] <LaserJock> I filed a MIR for smarty
[18:40] <asac> LaserJock: prominently hidden in some config dialog is still different from putting a link on your website.
[18:40] <LaserJock> asac: but why would Partner be on a website somewhere when it's already in sources.list
[18:40] <kees> LaserJock: cool, yeah, the jaunty packaging will be improved by getting more of the embedded stuff out.
[18:41] <LaserJock> kees: yui was split out as well in Debian, *but* it deps on wwwconfig-common
[18:41] <kees> LaserJock: I guess I will start collecting all the CVE patches from the latest releases
[18:41] <LaserJock> kees: I could perhaps see if I can strip out the wwwconfig-common stuff (it wasn't there in Intrepid)
[18:42] <LaserJock> or I could keep yui embedded for Jaunty and deal with it again for Jaunty+1
[18:42] <kees> LaserJock: probably a good idea to check with the server team about wwwconfig-common.  it's been discussed several times before.
[18:42] <asac> LaserJock: its not in sources.list by default
[18:42] <LaserJock> asac: partner is
[18:42] <kees> dbconfig-common got into main, I can't imagine it'd take much for wwwconfig-common too
[18:42] <LaserJock> just not enabled by default
[18:42] <asac> yes. so its not ;)
[18:43] <LaserJock> but it *is* there, unlike other 3rd party repos
[18:43] <LaserJock> so the system already has access to it, unlike something that's not there at all
[18:43] <asac> LaserJock: commented in source.list is the same as prominently hidden in a preference dialog ;)
[18:43] <LaserJock> well, then deal with it
[18:43] <LaserJock> that's not my point
[18:44] <asac> LaserJock: yes. of course we could have treated partner different for apturl, but wanted to come up with something in general
[18:44] <LaserJock> I'm simply saying, what's the use case for these whitelists as in your RFC when Multiverse and Partner exists
[18:44] <LaserJock> do we have examples repos?
[18:44] <LaserJock> *example
[18:45] <cody-somerville> LaserJock, the bzr repo?
[18:45] <LaserJock> I wouldn't think that'd make it
[18:45] <kwah> hi, everyone
[18:46] <kwah> is there a way to find out how many memory linux graphics driver uses?
[18:46] <LaserJock> it's commonly uninstallable and I don't think I'd want it whitelisted
[18:46] <asac> LaserJock: well. there could be valid use for free software too.
[18:46] <LaserJock> asac: like?
[18:46] <asac> LaserJock: the idea was to make it hard to get whitelisted and learn from the experiences
[18:47] <LaserJock> right
[18:47] <kwah> I mean for various buffers and related staff
[18:47] <asac> what we dont want is that we get hundreds of applications that we cant review
[18:47] <LaserJock> but if they can get whitelisted, why can't the be in the regular repos?
[18:47] <LaserJock> I just don't see a very good use case that wouldn't be covered by existing Ubuntu repos
[18:48] <LaserJock> I could totally be wrong, I'm just not seeing it right now
[18:48] <asac> LaserJock: we will see. initial discussion we things like wine in mind
[18:48] <LaserJock> wine itself?
[18:48] <asac> LaserJock: if it turns out that all this is not required, but we should just whitelist partner, then thats good too. its just that we need feedback
[18:49] <asac> and want to learn ... before doing that.
[18:49] <LaserJock> I don't know why you'd whitelist partner
[18:49] <LaserJock> in the sense that, the repo information is already on the users machine, and where would they click on to enable it?
[18:50] <asac> LaserJock: whitelisting is about providing a way to enable repos through apturl.
[18:50] <LaserJock> right
[18:50] <asac> LaserJock: there are different kind of users
[18:50] <asac> we have ubuntu hardcores, but also "normal" users that might even not know how to use synaptic
[18:50] <LaserJock> ok, so this is for people who can find the clicky link somewhere on canonical.com but can't use Software Sources?
[18:50] <asac> i think you question the use of apturl at all
[18:50] <LaserJock> no, not at all
[18:50] <LaserJock> I love apturl
[18:51] <asac> why would you want to place a link that installs a package if you alreawdy have the repo on your machine ;)
[18:51] <asac> thats the question i get.
[18:51] <LaserJock> you do have it there
[18:51] <LaserJock> so if Partner is important, let's make it easier to get at in Add/Remove and/or Software Sources
[18:52] <LaserJock> I just don't imagine that the use case for enabling Partner via apturl is very large
[18:52] <LaserJock> as the person needs to find the webpage in the first place
[18:53] <asac> LaserJock: well. so you say that installing packages through apturl has its use
[18:54] <asac> LaserJock: but then you say that its ok that you need to add instructions next to the link for partner
[18:54] <asac> saying: "take care: this link is broken until you go to software sources and check this"
[18:54] <LaserJock> no, I'm saying you shouldn't need to do that
[18:55] <asac> LaserJock: that means that we enable partner by default
[18:55] <LaserJock> if Canonical is using apturl then they can whitelist it if they want, i don't care
[18:55] <asac> or index the packages, which is equivalent imo
[18:55] <asac> LaserJock: right. but is it bad to have a process to get whitelisted?
[18:56] <LaserJock> it could be
[18:56] <asac> why?
[18:56] <LaserJock> it's adding a whole new category of stuff people have to look at
[18:56] <LaserJock> you're proposing new teams, new applications that have to be reviewed, etc.
[18:57] <LaserJock> so I'd want to make sure that we don't:
[18:57] <LaserJock> 1) add process for processes sake
[18:57] <LaserJock> 2) add a process for 1 use case (Partner)
[18:58] <LaserJock> so my question was, how often are we going to be whitelisting? what use cases? are there example packages/repos?
[18:58] <slangasek> well, "partner" are Canonical's partners; surely we want an open, symmetric process that lets other service providers participate on the same footing?
[18:58] <ScottK-laptop> asac: I think it's a problem to write a process that can only ever apply to Canonical.
[18:58] <ScottK-laptop> slangasek: But the proposed process doesn't do that.
[18:58] <LaserJock> slangasek: right, but would imagine the TB could do that
[18:58] <slangasek> hmm, doesn't it?
[18:59] <slangasek> I haven't read the draft; that was just my impression from the UDS session
[18:59] <ScottK-laptop> slangasek: Nope.  The only projects that could benifit can't be hosted on LP without paying for it and they have to be on LP.
[18:59] <slangasek> hmm
[18:59] <ScottK-laptop> It's a catch 22.
[18:59] <ScottK-laptop> The only projects that could use the current process can either go in Multiverse or Partner.
[19:00] <ScottK-laptop> I don't think it's reasonable for Ubuntu to write a policy based on the assumption that Launchpad's terms of service can be ignored.
[19:01] <mvo> is anyone else bitten by the compiz problem that alt-f2,f1 does no longer work after the recent upgrade? if so, I would like to ask for " gconftool --get /apps/compiz/general/allscreens/options/active_plugins" (via /msg) please
[19:01] <ScottK-laptop> I think a reasonable goal of this process would be to change what third party commercial providers can be whitelisted from an exclusively Canonical decision to an Ubuntu one.
[19:01] <ScottK-laptop> This doesn't to that.
[19:02] <LaserJock> well, I guess it could
[19:02] <LaserJock> but it's sort of oddly done
[19:02] <asac> ScottK-laptop: how is that?
[19:02] <ScottK-laptop> The only people who could benifit from it would need Canonical's special permission to be on Launchpad.
[19:03] <asac> ScottK-laptop: i have to admit that the launchpad point is quite a valid one
[19:03] <LaserJock> yeah, but Canonical's unlikely to interfer I'd think
[19:03] <asac> ScottK-laptop: otoh, i dont think that canonical would decide whether to allow a launchpad project depending on wehether they want that 3rd party repo
[19:03] <LaserJock> but I don't know why the TB wouldn't make the decision on a case-by-case basis
[19:03] <LaserJock> how often are we going to get these that we need a whole team/process for thit?
[19:03] <asac> especially since you need to get the project before you can submit your application with details
[19:04] <ScottK-laptop> So it moves the control point to a different part of Canonical, but that's it.
[19:04] <ScottK-laptop> asac: That's my only issue really.
[19:04] <asac> right. but the control point is before we even know whats going on.
[19:04] <asac> but then, i also dont know about any official terms for non-free projects and launchpad
[19:04] <ScottK-laptop> asac: True, but it doesn't change the fact that the proposed process can only benifit projects with some kind of special permission to use LP.
[19:05] <asac> nobody raised that point during discussion ;)
[19:05] <ScottK-laptop> The public terms say FOSS only.
[19:05] <ScottK-laptop> Obviously there are exceptions since Launchpad is hosted on Launchpad.
[19:05] <mvo> hm, that sounds like a valid point
[19:05]  * mvo scratches his head
[19:05] <asac> ScottK-laptop: well, maybe a project that gets permission should automatically get a launchpad permission or something
[19:05] <asac> so we dont make it a prerequisites. but in the end i would think its not a real problem
[19:05] <ScottK-laptop> Then Canonical would have to publish revised TOS for LP I think.
[19:06] <asac> ScottK-laptop: where is the public term?
[19:06] <asac> ScottK-laptop: from what i see it just says that its free if your are foss
[19:06] <asac> nothing else
[19:06]  * ScottK-laptop digs
[19:06] <asac> but i might look at the wrong page
[19:07] <LaserJock> right, so if you're not FLOSS you have to talk to Canonical and pay for it
[19:08] <LaserJock> which is fine, but in the end you're always going through Canonical anyway
[19:09] <mvo> the requirement for launchpad was really just so that we can ensure that there is one central place where we can find bugreports
[19:09] <ScottK-laptop> On the project registration page, it says, "Launchpad.net is free to use for software projects that share their source code and comply with these  licensing policies.   Contact us if your project uses a proprietary license."
[19:09] <LaserJock> mvo: what if it's a private LP project?
[19:09] <mvo> the "it needs to go through canonical" is something we tried to avoid
[19:10] <mvo> LaserJock: I don't think that would work out, in order to be a third party repo it would have to have a public bugtracker
[19:10] <ScottK-laptop> Right, I'm not saying there was any ill intent, I just think this got missed in the previous discussion.
[19:10] <ScottK-laptop> The licensing policies are https://help.launchpad.net/Legal/ProjectLicensing
[19:10] <mvo> I see little point otherwise, how could we ensure the quality otherwise
[19:10] <LaserJock> of course
[19:10] <mvo> indeed
[19:10] <mvo> its a good point, maybe as asac pointed out, some sort of exception or something
[19:10] <LaserJock> but I belive that a lot of the people using LP for proprietary stuff are private
[19:11] <LaserJock> so ...
[19:11] <asac> LaserJock: right. but what we want - and why we said launchpad - is that users on ubuntu can file their issues public so that we can review the state of apackage and so on
[19:11] <mvo> sorry, I don't really get it, if its private on LP it can not qualify as a trusted third party repository
[19:11] <LaserJock> obviously
[19:12] <asac> and having those bugs spread around the net would make it really hard to make a review on 3rd party stuff from within ubuntu
[19:12] <LaserJock> but your use case for the whitelisting is precicesly the people who hav private LP projects
[19:12] <asac> LaserJock: no.
[19:12] <asac> LaserJock: where did we say private?
[19:12] <LaserJock> the primary users of private LP projects are proprietary
[19:13] <asac> private usually even menas that you need password to access repo
[19:13] <LaserJock> the primary usage of this whitelisting is proprietary
[19:13] <asac> LaserJock: but its wrong to make deduce from that that proprietary projects cannot have a public bug tracker
[19:13] <LaserJock> I agree
[19:13] <LaserJock> but it's a consideration
[19:13] <ScottK-laptop> asac: I would suggest abstracting the characteristics of LP that caused you to say it has to be on LP and change it to must be hosted in an infrastructure that provides ...
[19:14] <ScottK-laptop> If LP is an easy was for people to meet that requirement, that's fine, but I don't think that it can require LP be used.
[19:14] <LaserJock> I dont' think you can just assume it's easy for them to have a public bug tracker on LP
[19:14] <asac> LaserJock: this process was not designed with "easiness" for the 3rd party folks in mind
[19:14] <ScottK-laptop> Also in a proprietary bug tracker there is no way to know that if there is a public bug tracker it is the only one or even the primary one.
[19:14] <asac> LaserJock: we firmly believe that the right approach is to distribute in archive.
[19:15] <LaserJock> but further, if the point of the proposal is to make a neutral place for 3rd parties to creat Partner-like repos I would think that the TB would be the right place
[19:15] <asac> ScottK-laptop: we tried to address that in the document too
[19:15] <asac> ScottK-laptop: we require that the repo folks that place a link should also post a link to bugtracker there
[19:16] <ScottK-laptop> asac: I think if you focus on the hosting requirements and don't require LP, it's basically OK.
[19:16] <LaserJock> I just can't imagine that there will be a lot of people who are going to meet the requirements, so I'd rather see it be case-by-case approval by the TB
[19:16] <mvo> I guess we should change it so that it encourages LP (becuase it makes our life easer) but does not require it stricly
[19:24] <LaserJock> how big do you imagine ~ubuntu-tpr will be?
[19:24] <ScottK-laptop> The process should also define how that group is selected (don't recall if it does).
[19:25] <superm1> mr_pouit, repushed
[19:38] <rohan> https://wiki.ubuntu.com/KernelTeam/SuspendResumeTesting --> the script provided here for stress testing suspend/resume is meant to be run on which distribution?
[19:38] <rohan> or is it distro agnostic?
[19:39] <asac> LaserJock: i wouldnt expect too many volunteers for the review work.
[19:46] <Keybuk> thought for the day
[19:46] <soren> StevenK: Hey. I've fixed the missing copyright stuff in the eucalpytus package, so if that was the only issue you had with the package, it would be lovely if you could accept it (instead of getting one of the other AA's to start from scratch reviewing it).
[19:46] <Keybuk> WHY is facebook mirroring my git repository?
[19:46] <Keybuk> http://mirror.facebook.com/kernel.org/scm/linux/hotplug/keybuk/
[19:46] <soren> Keybuk: I noticed almost the same thing yesterday.
[19:46] <soren> (for a kvm repo)
[19:47] <soren> Perhaps they're mirroring all of kernel.org. Yikes.
[19:47] <LaserJock> asac: I dont' know, I'd probably volunteer :-)
[19:48] <Keybuk> it does look like they mirror kernel.org
[19:54] <Keybuk> pitti: what's most baffling about this never-ending-I/O is that it's *not* usplash
[19:54] <Keybuk> which is what I traditionally blame for everything
[19:54] <pitti> Keybuk: no, I started a boot without splash and quiet
[19:54] <pitti> there wasn't one event which took 10 seconds, just several which took quite a while
[19:55] <pitti> [    0.943156] pnp 00:03: io resource (0x1010-0x102f) overlaps 0000:00:1f.0 BAR 7 (0x1000-0x107f), disabling
[19:55] <pitti> [    1.774255] Clocksource tsc unstable (delta =<PHONE_NUMBER> ns)
[19:55] <Keybuk> it just seems like the entire system is on lithium
[19:55] <pitti> [    1.832291] checking if image is initramfs... it is
[19:55] <pitti> [    2.923320] Freeing initrd memory: 7756k freed
[19:55] <pitti> ^ initramfs uncomression, I guess
[19:55] <pitti> [    2.945129] pci 0000:00:02.0: Boot video device
[19:55] <pitti> [    4.477063] pcieport-driver 0000:00:1c.0: setting latency timer to 64
[19:55] <pitti> no idea about that one
[19:55] <pitti> and so one
[19:55] <pitti> it's just sluggish :/ (and so far it isn't ext4 related at all, I think)
[19:57] <pitti> Keybuk: at least I don't remember earlier releases booting significantly faster, so it isn't a recent regression
[19:57] <pitti> the initial 15 second lag until usplash is, though
[19:57]  * pitti chuckles at apw's rejected apport upload
[19:58] <apw> pitti, heh where did i upload it to that you'd have seen it?
[19:58] <apw> i almost always forget to update the UNRELEASED to jaunty
[19:58] <pitti> apw: it gets sent to Maintainer: and the uploader
[19:58] <pitti> apw: and you apparently forgot to push your branch :)
[19:59] <apw> oh thats silly given i sent it to a PPA
[19:59] <pitti> apw: also, I made another commit this afternoon
[19:59] <apw> yeah not pushed it with the last change yet
[19:59] <apw> bah
[19:59] <pitti> apw: ppa> please don't commit the unreleased->jaunty change then
[19:59] <pitti> just do it, upload to ppa, and revert
[19:59] <apw> i guess you'll merge it anyhow
[19:59] <apw> right not commited
[19:59] <pitti> apw: ah, right, or push it to a branch, and I'll review it
[20:00] <pitti> apw: I might want to do some extra test suite checks for that, and so on
[20:00] <apw> i am trying to test it before pushing it to you for merge
[20:00] <apw> but the new keys seem to be stopping me installing it
[20:00] <apw> grrr
[20:01] <apw> pitti, when i do a change in bzr is it correct to use dch on its own to change the changelog?
[20:02] <pitti> apw: no, not really; you should always commit the changelog together with the actual change
[20:02] <apw> yeah i am doing that
[20:02] <apw> doing a dch then a debcommit
[20:02] <pitti> apw: if you already committed the change, then either uncommit, or commit it afterwards (more ugly, but works)
[20:02] <pitti> apw: right, debcommit is ♥ :)
[20:02] <apw> _but_ is the dch bit right?
[20:02] <pitti> apw: thanks for workign on it
[20:02] <pitti> apw: yes, dch is fine, I'm using that all the time
[20:03] <apw> its a good way to learn the other stuff as i go
[20:03] <apw> how bzr and deb packaging work together etc
[20:03] <apw> and i want to fix apport as its making my life hard as it is
[20:03] <pitti> apw: dch for changes, and dch -r/debcommit -r for an upload
[20:03] <Lure> pitti, asac: any way to get lensfun & opencv packages get through MIR review before FF? Kubuntu would love to have these in main in jaunty...
[20:03] <apw> and it knows things and should do it right
[20:03] <apw> pitti, cool.  i want to end up a core-dev so i'll need to know
[20:05] <apw> pitti, anyhow, i'll ping you when the branch is up, and you can tell me all the things i've done wrong
[20:06] <pitti> apw: heh; thanks
[20:07] <Keybuk> pitti: I don't think it's bootchart itself doing the IO :p
[20:08] <asac> Lure: i will get them now
[20:08] <Lure> asac: great! thanks in advance!
[20:08] <pitti> Keybuk: no, all the times I mentioned in the mail were done with a stopwatch, without bootchart
[20:08] <pitti> Keybuk: anyhow, if it just affects my laptop, but in general is very fast nowadays, then I won't complain :)
[20:08] <Keybuk> plus bootchart=1hz still shows the I/O - albeit very imprecisely :p
[20:09] <Keybuk> it seems to affect mine too ;)
[20:09] <pitti> Keybuk: I already checked the acoustic setting in the bios, it's set to "performance"
[20:09] <pitti> (FSVO "performance"...)
[20:10] <pitti> [X] slow and silent [X] even slower and just a whisper
[20:15] <apw> pitti, does your other fix change the url to which we send things?
[20:15] <pitti> apw: no
[20:16] <pitti> apw: if you push to your own branch, it doesn't affect commits to the ubuntu one
[20:16] <apw> well its trying to send to file:://ubuntu/+source ...
[20:16] <apw> right so what i am saying is the current apport with just my changes is sending to the wrong URL it appears
[20:17] <apw> and i think i saw someone on one of my bugs reporting the same thing
[20:17] <Keybuk> pitti: what's dellWirelessCtl?
[20:18] <apw> pitti, i get the separation of branches.  what i am talking about is the submit side of apport has broken and i don't think i broke it
[20:18] <pitti> Keybuk: something from libsmbios-bin, but I don't know -- /me eyes at superm1
[20:19] <apw> yeah your changes are all docstrings and stuff
[20:19] <pitti> wow, that package has a lot of stuff
[20:20] <pitti> apw: don't worry, I can easily merge that
[20:20] <pitti> Keybuk: tons of programs, but not /usr/sbin/makeItBootFast :(
[20:20] <apw> yeah should merge fine.  but why is submit going to a mad place
[20:21] <apw> pitti, the hostname has gone missing in the push part here
[20:21] <apw> its going to file:///ubuntu/.... instead of to launchpad
[20:21] <apw> waht defines that
[20:21] <pitti> apw: push lp:~apw/apport/suspend-gui or so?
[20:21] <apw> no no not bzr
[20:22] <apw> i am generating a bug, and it all works until it says "send report" then it fires up
[20:22] <pitti> oh
[20:22] <pitti> apw: that has recently been fixed in glib; are you running current jaunty?
[20:22] <apw> firefox with the wrong url, its a local file url not an http url
[20:22] <pitti> or restarted your session in the last week?
[20:22] <apw> its newish
[20:22] <apw> i'll go update
[20:22] <pitti> bug 314263
[20:22]  * pitti pokes ubottu
[20:23] <tobi> which package contains the debugging symbols for: xserver-xorg-video-nv?
[20:23] <pitti> apw: suspend/resume testing to the max, eh? :-)
[20:23] <apw> yeah gotta test ones changes before actually asking you to merge them
[20:23] <pitti> tobi: xserver-xorg-video-nv-dbgsym, if you have ddebs.u.c. enabled
[20:23] <apw> we had a case of someone not doing that recently and its not cool
[20:23] <pitti> apw: I meant, never restarting your session :)
[20:24] <apw> hehe. actually a just logged in
[20:24] <apw> but tere are some 22MB of jaunty updates
[20:24] <apw> which i should put on before i say "its still borked'
[20:24] <superm1> pitti, for jaunty all of that stuff is now in smbios-utils instead of libsmbios-bin.  most of it has been rewritten in C with python bindings
[20:26] <tobi> pitti, not until now. thank you!
[20:27] <pitti> superm1: oh, I still have libsmbios-bin installed
[20:27] <superm1> pitti, yeah smbios-utils is marked as a replaces for libsmbios-bin
[20:27] <pitti> at least dellWirelessCtl is already an ELF file, not python
[20:28] <pitti> superm1: should I flip the Recommends: in hal then? it still says libsmbios-bin
[20:28] <superm1> pitti, yeah i was going to do that after smbios-utils cleared NEW.  I guess it has by now, so go ahead
[20:28] <pitti> superm1: shoudln't it also Conflicts:libsmbios-bin then, to make sure it gets uninstalled?
[20:29] <pitti> superm1: oh, you mean that the new smbios-utils is Python now, and the old one was C?
[20:30] <superm1> pitti, well I was quite on edge about whether to mark it as conflicts, because there are still a few legacy binaries in it that are not part of the new libsmbios that someone "could" use if they wanted, but that weren't necessarily going to be supported going forward
[20:30] <pitti> superm1: ah, I see
[20:30] <superm1> pitti, no, libsmbios itself was C++ as well as all it's binaries.  now libsmbios is C based, and smbios-utils are all python
[20:30] <pitti> that'll make Keybuk happy, more python in the boot processs :)
[20:31] <superm1> pitti, if you think setting a conflicts: too is worthwhile, I can make that change too, just a little wary about it.
[20:31] <Keybuk> pitti: Python is going to be banned from the boot process ;)
[20:31] <pitti> superm1: as long as having both installed wont wreak havoc...
[20:32] <pitti> superm1: we just have to assume that everyone has libsmbios-bin installed, and an upgrade will then have both
[20:33] <apw> are we expecting any more fixes for pulse audio?  or what i have on my machines 'it'
[20:34] <Keybuk> apw: I blame the kernel ;)
[20:34] <apw> heh ... but i know if i disable pulse it will be better
[20:35] <apw> i have not see 1 system which has good sound right now, they all break up
[20:35] <apw> and i've had the oppotunity to see a large number in the last two weeks
[20:35] <apw> and with FF a week away i am getting twitchy
[20:36] <Keybuk> it's probably an I/O problem ;)
[20:36] <superm1> pitti, well at least if someone wants to, they can write C apps that link to libsmbios_c instead of the python though.
[20:36] <superm1> pitti, yeah having both installed will be okay.  I'll think more about if conflicts is appropriate though.
[20:37] <Keybuk> apw: seriously, I/O performance in 2.6.28 is absolutely terrible right now
[20:37] <Keybuk> my boot is 12s longer after a kernel upgrade
[20:38] <apw> great... any clues?
[20:38] <Keybuk> none
[20:38] <Keybuk> stat shows that there's a lot of IO going on, but not attributed to any particular process
[20:38] <Keybuk> one entire core is maxed out at I/O wait
[20:38] <Keybuk> which tends to imply it's a kernel thread
[20:39] <apw> pitti, my system is fully up to date now and still sending to the file:///ubuntu thing
[20:41] <cody-somerville> pitti, mine did that too but often times I get "Firefox is already running but not responding..."
[20:41] <cody-somerville> pitti, I mentioned the problem to asac this morning
[20:41] <pitti> apw: eww; you restarted your session after the update?
[20:41] <apw> i updated and rebooted
[20:41] <apw> then i triped the susped
[20:42] <apw> and rebooted again
[20:42] <apw> and i have the supposedly fixed glib2
[20:42] <apw> i'll test again
[20:42] <pitti> apw: there were two patches
[20:42] <pitti> apw: one hack, which reportedly worked, but got rejected upstream
[20:42] <apw> both to glib2?
[20:43] <pitti> and one "good" solution, where I didn't see feedback on
[20:43] <apw> i got the version in the last comment in the bug
[20:43] <apw> and i'd say its balls from my testing
[20:43] <apw> will feeback there and then frig it in the next one
[20:43] <apw> to get my testnig done
[20:45] <pitti> apw: you could try to download https://edge.launchpad.net/ubuntu/+source/glib2.0/2.19.5-0ubuntu3 and build/install it locally
[20:45] <pitti> that's with the previous patch
[20:45] <pitti> if that works, we need to discuss the current patch upstream again
[20:46] <apw> deffo does not work here
[20:46] <apw> balls, why is there alway someone elses bug in your way
[20:47] <apw> crap i can't frig it either as changing the url loses the post
[20:47] <apw> GRRRR
[20:47] <apw> pitti, is there an incantation to get that source there and expand it automatically
[20:48] <pitti> apw: you click on that link and can get dsc/diff.gz/orig.tar.gz from there
[20:48] <apw> nothing simpler than 3 downloads and a manual resostructc?
[20:48] <pitti> apw: anyway, didn't you just change the UI? the submission part shouldn't have changed at all surely?
[20:49] <apw> no, but it would be nice to test it all the way through
[20:49] <pitti> apw: s/resostructc?/dpkg-source -x and debuild -b/
[20:49] <apw> i am a pedant
[20:49] <pitti> apw: sure, but just replace file:///ubuntu/ with https://launchpad/
[20:49] <pitti> in the browser
[20:49] <pitti> then it should be all good
[20:49] <apw> no cause that loses the POST info
[20:49] <apw> so you get a fesh virgin bug
[20:49] <pitti> ?
[20:50] <pitti> apport doesn't use POST
[20:50] <apw> so how does the rest of the info get in to the bug
[20:50] <apw> oh magic occurs
[20:50]  * apw takes it back
[20:50] <pitti> it first uploads the blob to lp, gets the ticket for it, and then uses /+filebug?DEADBEEF_ticketnumber
[20:51] <pitti> apw: yeah, ♪ it's a kind of magic ♫ ♬
[20:51] <apw> though it looses the title setting
[20:51] <apw> and the tags
[20:51] <apw> just the title, the tags are there
[20:51] <apw> when did you add the arch to the tags?
[20:52] <apw> pitti, ok it looks good.  i'll request my branch is merged
[20:53] <pitti> apw: arch> committed last week, per request of bdmurray
[20:53] <apw> yeah its good
[20:54] <pitti> apw: hm, the title should have been a GET argument; I might misremember, though
[20:55] <apw> pitti, ok officially requested merge: https://code.launchpad.net/~apw/apport/suspend-resume-pt3/+merge/3584
[20:56] <pitti> apw: thanks; will look at it ASAP
[20:59] <bardyr> apw, btw those vanilla kernels builds are great :) thanks for that
[20:59] <apw> bardyr, they are getting a little out of date, as we are mid trying to convert them to central builds
[20:59] <apw> so expect something more automatic soon
[20:59] <jcastro> directhex: do you have anyone looking at monodevelop? I have a volunteer but I need to send him someplace. :)
[21:01] <directhex> jcastro, upstream were releasing beta 1 todayish, meebey should be taking a look imminently
[21:01] <apw> bardyr, what you using them for?  help me justify the effort to maintain them if i know
[21:01] <jcastro> directhex: yeah mhutch told me has them ready. Where shall I send this new person, do you guys have a channel?
[21:01] <bardyr> apw, trying out some kernel hacking and 2.6.29 kernel (which is great )
[21:02] <apw> cool
[21:02] <directhex> jcastro, all work tends to happen in oftc #debian-mono
[21:02] <directhex> jcastro, in fact we seem to be accumulating non-debbuntu people now. we have a gentoo mono packager in residence, and a couple of upstream people
[21:02] <jcastro> directhex: perfect, I'll send him along your way
[21:07] <pitti> apw: oh, so this doesn't actually change the UI presentation, which still says "critical kernel problem encountered blabla"
[21:08] <apw> no not yet.  this is just to stop it being a pain for us to handle the bugs
[21:08] <apw> steve just sent me the bones of that bit, which is next
[21:08] <apw> i will try and integrate and push that tommorrow
[21:09] <pitti> apw: so, current changes look fine; I'll merge/commit/upload
[21:09] <apw> i just spent half a day going through them and had to update the titles on them all
[21:09] <apw> which was stupid as apport knows
[21:10] <apw> pitti, thanks
[21:13] <pitti> apw: [done]
[21:13] <apw> pitti, top man
[21:13] <pitti> apw: you should pull lp:~ubuntu-core-dev/apport/ubuntu/ into your branch, to get the conflicts resolved, etc.
[21:14] <pitti> (if you plan to continue to use this branch)
[21:14] <apw> will make a new one for the new topic
[21:16] <ScottK> pitti: Would you please rescore qt4-x11 on sparc and if it's not too hard, could you at least rescore kde* on powerpc ahead of the Universe packages (if that's a lot of work, it'll get done eventually).
[21:19] <pitti> ScottK: kde* expands to what?
[21:19] <pitti> ScottK: qt4-x11 bumped
[21:20] <ScottK> pitti: About 18 of the 24 source packages that make up KDE core.
[21:20] <pitti> ScottK: ah, http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_outdate.txt FTW :)
[21:21] <ScottK> pitti: Yeah.  I was about to hand you https://wiki.kubuntu.org/Kubuntu/Ninjas/DependencyGraph?action=AttachFile&do=get&target=kde-dep-graph.png
[21:21] <ScottK> It's all but one of the leaf packages.
[21:21] <kirkland> slangasek: kees said you had some udev/cryptsetup issues?
[21:22] <kirkland> slangasek: i was having some trouble last night setting up encrypted swap, using the same steps i've been using for years
[21:23] <kirkland> slangasek: what problem were you seeing, and has it been cleaned up yet?
[21:23] <apw> pitti, just downgrading glib2.0 to the version you suggested has fixed apport.  writing it up in the bug and moving it back to BROKEN
[21:23] <pitti> apw: thanks
[22:01] <ebroder> Hey jdong: I've updated my xen-meta debdiff (LP bug #323546)
[22:01] <jdong> ebroder: thanks much; I'll review and upload
[22:01] <ebroder> Awesome. Thanks
[22:02] <jdong> sure thing
[22:09] <jdong> ebroder: ok it's sitting in the queue.
[22:23] <slangasek> kirkland: there's a udev bug, it's in the errata for alpha-4
[22:23] <kirkland> slangasek: i'm experiencing https://bugs.edge.launchpad.net/ubuntu/+source/cryptsetup/+bug/316607
[22:23] <kirkland> slangasek: there's a patch attached to that one, i'm looking at it now
[22:25] <slangasek> kirkland: ah, I haven't seen that one.
[22:26] <slangasek> kirkland: mine was "initramfs missing the cryptsetup hooks"
[22:28] <kirkland> slangasek: gotcha, that's different
[22:28] <kirkland> slangasek: mine, too, however, appears to actually be a udev problem
[22:36] <ogra> bryce, is the xrandr systray thingie your work ?
[22:37] <ogra> (i mean the little applet you can enable in the screen settings)
[22:48] <arthur-> doko: bootstrap finished on mips64, now running the testsuite
[22:49] <bryce> ogra: it's from RedHat
[22:49] <TheMuso> cjwatson: I still have reason to believe that the cd images obtained via rsync are older than the ones on http. I just built an i386 alternate image from jigdo, and it has the md5sum 736f5d628fc5a1894baaf1585baebb94
[22:50] <bryce> ogra: I only put a few patches in it but don't maintain it regularly or anything
[22:50] <ogra> bryce, ah ... would it be possible to package the sytray applet eparately ?
[22:50] <TheMuso> cjwatson: in addition, the CD images I get via rsync still have the -6-generic kernel for d-i.
[22:50] <bryce> ogra: that'd be a seb128 question
[22:50] <ogra> bryce, the systray only would implement https://blueprints.launchpad.net/ubuntu/+spec/mid-screen-rotation immediately :)
[22:51] <bryce> ogra: well it has kind of involved dependencies with gnome-desktop and gnome-settings-daemon, so don't think it'd be a trivial packaging task
[22:52] <ogra> ah, sad
[22:52] <bryce> ogra: fwiw, tseliot has been working on the side on another randr tool, that has a cleaner set of dependencies
[22:52] <ogra> well, the spec is obsoleted for jaunty anyway, i just thought it would be a cheap way to get it implemented anyway
[22:52] <TheMuso> cjwatson: no, its my screw up, thought the isos were in a particular dir on my machine, but they are somewhere else. Don't mind me.
[22:53] <bryce> ogra: it's not in the archive yet, and probably needs more work before it's ready for prime time, but it'd probably be a simpler path, if you want to avoid the overhead of all the gnome-* dependencies
[22:54] <ogra> i'll talk to him
[22:54] <seb128_> re
[22:55] <seb128_> got disconnected
[22:55] <seb128_> I was saying that I didn't try recently and I don't want to do it now because previous time I tried xrandr rotation xorg screwed, that was in hardy or intrepid though, but we got no bug about it
[22:56] <bryce> yeah I'd save my work before testing rotation
[22:56] <ogra> heh
[22:57] <bryce> but I think a lot of the issues have improved.  Used to crash/freeze more often than not this time last year.
[22:57] <ogra> works for me, just trashes my panel setup every time
[22:57] <ogra> it gets the applets out of order
[22:57] <bryce> yeah, panel does that for screen resizes too
[22:57] <bryce> my laptop's icons are always messed up
[22:58] <cjwatson> TheMuso: ... ok, glad you sorted it out before I saw and got confused :-)
[22:59] <StevenK> cjwatson: Ahhhhh! That makes perfect sense.
[23:00] <StevenK> TheMuso: So, it appears you can have a maximum of 3 arches build from linux-ports
[23:01] <TheMuso> StevenK: no, not quite, I'll have all of them built next time around, which will be tonight.
[23:01] <StevenK> Famous last words
[23:01] <StevenK> TheMuso: Should I rescue i386 and ia64 -1.5 from NEW?
[23:02] <cjwatson> gar, and I was so close to declaring my partman-auto-lvm project complete
[23:02] <cjwatson> oh well, three known bugs
[23:02] <TheMuso> StevenK: No, because I'll be rebasing against mainline jaunty's new upload, which will likely bring about an ABI bump.
[23:03] <TheMuso> As for now, onto dmraid matters...
[23:04] <StevenK> cjwatson: Hmmm. ./usr/lib/syslinux/isolinux.bin shows itself as the "isolinux Loader", whereas I can't see anything similar in /usr/lib/syslinux for syslinux itself
[23:05] <StevenK> cjwatson: And /usr/bin/syslinux is a linked binary, which means I need to worry about arch and libc6 compatibility
[23:09] <cjwatson> StevenK: /usr/bin/syslinux writes /usr/lib/syslinux/ldlinux.sys, approximately, but it does it with some funky FAT-patching stuff that looks decidedly non-trivial to do in shell
[23:09] <cjwatson> StevenK: your concern is pretty much the same as mine
[23:09] <cjwatson> StevenK: see mtools/syslinux.c in the syslinux source if you want to have a look at what it's doing
[23:10] <cjwatson> maybe it could be reimplemented in perl - not sure
[23:11] <StevenK> cjwatson: Oh, so you don't actually run isolinux at all on the host
[23:12] <cjwatson> right, mkisofs knows how to stick it in the right place in the ISO image
[23:12] <cjwatson> anyway, bedtime
[23:27] <klasikahl> howdy. it appears yesterday there were some changes made in jaunty that have changed the way gnome authenticates ssh-agent.  i suspect maybe a change in ssh-agent.  either way, i am also getting buffer_get_int errors when trying to ssh to servers using pub/priv key auth.
[23:27] <klasikahl> thought i should pop in and let someone know since it appears pub/priv key auth is completely broken now in jaunty
[23:39] <klasikahl> cjwatson: ping