[02:26] <ArneGoetje> Riddell: I'm afraid not. That would result into inconsistencies in Rosetta and duplicate files in two packages (-base and the updates).
[03:10] <slangasek> ArneGoetje: the changes in question were made to the -kde-base langpacks, uploaded, and accepted; what are the consequences of this?
[03:22] <ArneGoetje> slangasek: the future l-p updates are deltas to the original -base packages. The files which have been added manually to the -base packages would then also be in the l-p updates.
[03:23] <ArneGoetje> slangasek: until the next round of full exports resulting in new -base packages being built.
[03:27] <bluefoxicy> http://uploads.ungrounded.net/257000/257818_SuperMarioLand2foreal.swf
[03:27] <bluefoxicy> If you're using gnash, watch this
[03:27] <bluefoxicy> it's funny, but more funny when it doesn't get 40-60 seconds out of sync
[03:30] <slangasek> ArneGoetje: yes, which means that the packages will have unnecessary duplication; but will anything break?
[03:30] <ArneGoetje> slangasek: I don't think anything will break. Just the duplications.
[03:59] <ArneGoetje> slangasek: shouldn't we then not patch all the -kde-base packs?
[04:11] <AndyTim> Hello again devels.  So I'm strongly considering adding the httpfs FUSE binary to the Ubuntu live CD initrd so that one could obtain the live CD environment entirely via HTTP.
[04:11] <AndyTim> I am wondering if this is a direction that the official Ubuntu would like to explore.
[04:12] <AndyTim> A publicly hosted web-server with the entire squashfs in RAM should be able to serve on-demand sectors to clients, who could easily boot via gPXE on even a floppy.
[04:12] <Hobbsee> AndyTim: that's probably something you want to ask in ~6 hours, FYI.  Most of Europe is asleep now.
[04:12] <AndyTim> Hobbsee: I see.  Thank you very much.
[04:13] <Hobbsee> AndyTim: you're welcome
[04:13]  * TheMuso can only think of one thing, nelss the livefs was on a local server. lag.
[04:13] <TheMuso> unless
[04:15] <AndyTim> TheMuso: Well, the support would be there for both cases, I suppose.  I guess anyone using a public would have to make the best of it. :)  Here's hoping VFS caching could help a smidgeon.
[04:17] <pwnguin> AndyTim: how much bigger would that make the livecd?
[04:17] <slangasek> ArneGoetje: sorry, I'm not following your double-negative
[04:17] <lifeless> AndyTim: vfs caching doesn't help with latency much
[04:18] <AndyTim> pwnguin: The mere addition of the FUSE module and httpfs binary into the compressed initrd.
[04:18] <AndyTim> pwnguin: But the Ubuntu web-site could offer a gPXE floppy image for people to try Ubuntu out.
[04:18] <AndyTim> lifeless: That's too bad.
[04:19] <pwnguin> AndyTim: well if you want it in the official livecd, there's rigid constraints on the size of a CD
[04:19] <lifeless> AndyTim: do some quick figures - 512 bytes a sector, 200ms latency (say, which is actually very optimistic for cross-world latency)
[04:19] <AndyTim> pwnguin: I'm talking probably a couple of megabytes.
[04:19] <pwnguin> there's also the requirement that the livecd continues to have an initrd.
[04:20] <pwnguin> AndyTim: thats more substantial than i thought, and you may want to ask for some stories of the pain "a couple of megabytes" induces :)
[04:21] <AndyTim> pwnguin: Ok, I take it back.  The module can be download as-needed.  So I'm then talking a couple of lines in the script.
[04:22] <AndyTim> lifeless: Not sure I get what you're saying.  I don't know how many sectors need loading until one gets desktop.  Any idea?
[04:22] <lifeless> AndyTim: hundreds of thousands
[04:23] <AndyTim> lifeless: I'm not suggesting transferring the entire squashfs into the client's RAM, but maybe you know that.
[04:23] <pwnguin> thats hundres of thousands of round trips, no?
[04:24] <AndyTim> pwnguin: I don't think so.
[04:25] <AndyTim> Well, people install via HTTP, so it can't be that bad.
[04:25] <ArneGoetje> slangasek: If you patch one -kde-base package to include the missing desktop_* files, why not patch all -kde-base packages with the missing desktop_* files?
[04:25] <lifeless> AndyTim: install is radically different
[04:25] <pwnguin> anyways, if you think its worth pursuing, subscribe to ubuntu-devel, write up a blueprint and attend uds if you can
[04:25] <lifeless> AndyTim: install is one round trip per package to download
[04:26] <slangasek> ArneGoetje: AIUI, he patched all the ones for which desktop files were actually missing; is that not the case?
[04:26] <ArneGoetje> slangasek: I don't know
[04:26] <pwnguin> i dont see a substantial reason this couldn't be done if someone's willing to actually do it and test it
[04:27] <AndyTim> Well I'm at it right now.  I wanted to gather some devel feedback, and I have some now.
[04:27] <pwnguin> AndyTim: the ubuntu-devel mailling list is a better place for peer review
[04:27] <AndyTim> pwnguin: I see.
[04:28] <pwnguin> it's a asynchronous communication channel, if you will
[04:28] <AndyTim> lifeless: So is a request for contiguous sectors.  Would we be jumping all over the squashfs in loading to a desktop, do you think?
[04:29] <ArneGoetje> slangasek: ah, ok, according to the bug report he did.
[04:30] <pwnguin> AndyTim: you know, there's an awesome tool out there to draw access patterns into movies. doubt it'll work for this question though
[04:31] <AndyTim> pwnguin: Never heard of it, but I'm certainly going to be using Wireshark to take a look at access patterns during testing.
[04:33] <lifeless> AndyTim: its very much going to depend on how effective request coalescing is
[04:34] <lifeless> AndyTim: A first approximation would be to add latency to your http server and just boot off it
[04:34] <AndyTim> lifeless: I wonder if it's also possible to optimize the squashfs for booting at all.  Maybe not.
[04:34] <AndyTim> lifeless: Yes.
[04:41] <AndyTim> pwnguin: The contraints you mentioned are due to trying to pack the squashfs as fully as possible?
[04:41] <AndyTim> pwnguin: Or is it more about RAM in-use by the initrd?
[04:47] <pwnguin> AndyTim: the main constraint I'm aware of is that the liveCD .iso can only be so big
[04:48] <AndyTim> pwnguin: Yes.  Thanks.
[04:48] <lifeless> AndyTim: we already exceed the physical limits of a cdrom
[04:48] <AndyTim> lifeless: Pushing .ISO?  Heheh.  Good for you folks.
[04:48] <AndyTim> (CD, I mean)
[04:48] <lifeless> AndyTim: squashfs is one tool to get an iso that fits on a cd people can burn
[04:48] <lifeless> AndyTim: so all changes get pressured to fit
[04:49] <AndyTim> lifeless: Well this needn't be on the installer CD at all.  It's a modified initrd for use with PXE/gPXE clients, I'd say.  Anyone with the CD should use it!
[04:49] <AndyTim> Heh.
[04:50] <AndyTim> However I can appreciate not wanting to manage initrds for use cases.
[04:50] <pwnguin> you want to duplicate all of initrd for this?
[04:51] <AndyTim> I was simply going to add to scripts/casper, for example, and add any needed binaries.
[04:51] <AndyTim> Minimally, that would be wget or curl or something
[04:52] <AndyTim> By the way, it appears that a flavour of Knoppix does all this already.
[04:55] <AndyTim> http://httpfs.sourceforge.net/net_boot.htm   and http://unit.aist.go.jp/itri/knoppix/http-fuse/index-en.html   for anyone that's interested.
[04:56] <pwnguin> is httpfs packaged in ubuntu?
[04:57] <AndyTim> Not that I know of, unfortunately.  I tried to apt-get it earlier...
[04:57] <pwnguin> that might be a good starting point for you then
[04:57] <AndyTim> But it's compatible; I've tested the downloaded binary
[04:57] <AndyTim> pwnguin: You mean packaging it?
[04:58] <pwnguin> yea
[04:58] <AndyTim> pwnguin: Hee hee; I'm afraid I'm not a big package management fan.  Sorry.  :(  This is more for a gPXE showcase, to tell true.  I thought this community could benefit, though.
[04:59] <pwnguin> well it'd be a significant hurdle to get core devel to accept a initrd script that wgets a binary
[04:59] <AndyTim> (As clearly users could benefit from Ubuntu-via-NIC-ROM/floppy/128 MB USB stick, etc. if it all works)
[05:00] <AndyTim> pwnguin: Oh?  This would only happen if NETBOOT= some URI.
[05:00] <pwnguin> on the otherhand, im not sure they'd go for apt-get either
[05:00] <AndyTim> pwnguin: Goes against some policy?
[05:01] <AndyTim> pwnguin: Well if the initrd is separated from the installer CD case, the size constraint disappears.
[05:02] <pwnguin> AndyTim: perhaps you should write the mailing lists and get a wider audience than whoever's paying attention
[05:02] <AndyTim> Heheheh.  Yes, first I will have one hosted for folks to try.  Then I will e-mail.
[05:03] <AndyTim> Hmm, that reminds me, gotta make sure that jives with Ubuntu.  Hosting it publicly, that is.
[05:03] <pwnguin> hosting what?
[05:03] <AndyTim> Hosting folks booting Ubuntu from me.
[05:04] <AndyTim> It's little different than a mirror, I'd imagine
[05:04] <pwnguin> i think the main problem is yours
[05:04] <pwnguin> how does the gpl source requirement work in that situation?
[05:05] <AndyTim> Yeah I just mean I will have to perform the diligence and be sure Ubuntu doesn't say not to anywhere.
[05:05] <lifeless> AndyTim: its the same as a mirror of the binary debs
[05:05] <lifeless> AndyTim: you can definitely do it, you just need to meet the source distribution requirement too
[05:06] <AndyTim> lifeless: Thanks for that.  With fortune, this can be the same referral that the CD would use, I imagine.
[05:07] <lifeless> AndyTim: CD's we ship (physical ones) have a written offer
[05:07] <lifeless> AndyTim: .iso files people can download have the source available from the same site, no external referring
[05:07] <AndyTim> There's the catch, then.
[05:08] <lifeless> http://www.fsf.org/licensing/licenses/gpl-faq.html#UnchangedJustBinary
[05:09] <lifeless> http://www.fsf.org/licensing/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites is better actually
[05:09] <LaserJock> lifeless: I thought mdz said that people could point to Ubuntu
[05:09] <pwnguin> LaserJock: i think the project in mind requires some modifications
[05:09]  * AndyTim reviews both.
[05:09] <lifeless> LaserJock: hmm, I'll need to check. I'm sure we're happy for people to point at us; but you still need to make sure you point at things that still exist
[05:10] <LaserJock> pwnguin: hmmm, yeah, you would have to have the source for the modifications
[05:10] <LaserJock> lifeless: yep
[05:10] <lifeless> LaserJock: consider tracking kinky, binaries you mirror will have their sources garbage collected quite frequently
[05:10] <AndyTim> Ideally this would be a success and the Ubuntu community would enjoy hosting it. :)
[05:12] <pwnguin> AndyTim: well, thats one of the nice things package management offers: source packages
[05:13] <AndyTim> As a matter of fact, you already do.  One could mount the Ubuntu-hosted .ISO and then open it up for the squashfs.
[05:13] <pwnguin> this is driving me crazy though. what's the name of that program that watches fs activity and draws out the access patterns over time...
[05:14] <AndyTim> pwnguin: A graphics one?  One could possibly parse the output of another tool...  What is _it_ called again, though...
[05:14] <lifeless> bootchart?
[05:17] <pwnguin> aha
[05:17] <pwnguin> http://oss.oracle.com/~mason/seekwatcher/
[05:17] <AndyTim> Nice.
[05:38] <AndyTim> As a matter of fact, the initrd's BusyBox has wget already.  We're talking text compression, then.
[05:40] <AndyTim> Adding some lines to the scripts/casper script and recompressing with gzip -9 yields a smaller file size than the original initrd.  I love it when that happens.
[05:49] <AndyTim> Anyone know off the top of their head where I can find the Ubuntu 8.10 pxelinux.cfg/ directory for a network install before I search the web for it?
[06:13] <geofft> AndyTim: I made http://tinyurl.com/intrepid-netinst some time ago after getting tired of Googling
[06:14] <geofft> I assume you found it by now, but hopefully this is helpful in the future :)
[06:15] <AndyTim> No, actually, I didn't.
[06:16] <AndyTim> geofft: So thanks.  Is that a simple conversion of the ISOLINUX stuff?  Looks like it's not quite as full.
[06:18] <AndyTim> No gfxboot, it seems.
[06:20] <geofft> I'm not sure... my limited understanding is that it's smaller than the alternate CD
[06:20] <geofft> personally, I only use that directory to boot linux+initrd.gz via GRUB
[06:21] <AndyTim> geofft: Ok.  Thanks.
[07:08] <pitti> Good morning
[07:08] <AndyTim> pitti: And to you.
[07:09] <StevenK> Morning pitti
[07:12] <dholbach> good morning
[07:12]  * pitti hugs dholbach
[07:13]  * dholbach hugs pitti back
[07:27] <dholbach> zul: how does bug 362691 look to you?
[07:53] <cody-somerville> Thats odd. I'm upgrading to Jaunty from Intrepid and I just got a debconf question saying "It seems to be your first LILO installation. It is...".
[07:53] <cody-somerville> LILO isn't suppose to get installed on upgrade to Jaunty, is it?
[07:56] <pitti> slangasek: remaining langpacks NEWed, that should clean up component-mismatches further
[07:56] <slangasek> ah, yes
[07:56] <slangasek> thanks
[08:01] <Hobbsee> cody-somerville: no, but that bug should have been fixed - did you dist-upgrade, or use the upgrade manager?
[08:01] <cody-somerville> dist-upgrade
[08:01] <Hobbsee> that would probably be why, then.
[08:02] <hyperair> why would dist-upgrade install lilo?
[08:04] <Hobbsee> cody-somerville: that would be https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/314004
[08:04] <Hobbsee> (i think)
[08:04] <hyperair> ah bad dependency eh
[08:05] <hyperair> but if that bug is fixed, shouldn't dist-upgrade not pull lilo any more?
[08:05] <slangasek> it doesn't pull it in; it's already thee
[08:05] <slangasek> there
[08:06] <cody-somerville> indeed
[08:06] <cody-somerville> hyperair, You should have read the bug report Hobbsee pasted if you're so interested
[08:08] <hyperair> cody-somerville: did.
[08:08] <hyperair> jsut did
[08:09] <dholbach> doko: how does bug 362691 look to you?
[08:09] <hyperair> but i'm running x86 intrepid and don't see lilo
[08:11] <Hobbsee> hyperair: installed by desktop or alternate?
[08:11] <hyperair> Hobbsee: desktop
[08:11] <Hobbsee> strange
[08:11] <hyperair> indeed.
[08:12] <robert_ancell> pitti: hi!
[08:12] <pitti> hey robert_ancell, how are you?
[08:12] <pitti> had a good weekend?
[08:13] <robert_ancell> pitti: yeah, I had the last week off in a long-planned holiday so had a great time catching up with people in New Zealand
[08:13] <pitti> nice
[08:13] <hyperair> Hobbsee: oh right, i installed using the hardy desktop cd, and then used update-manager to upgrade to intrepid.
[08:14] <Hobbsee> hyperair: that would be why, then.
[08:15] <cody-somerville> err...
[08:15] <slangasek> superm1: mesa->SRU?
[08:15] <cody-somerville> the box I was upgrading just... crashed? Screen is now black, doesn't respond to pings, but I can hear that the computer is still running :/
[08:17] <Jordan_U> cody-somerville, Does sysrq(alt+printscreen)+r print anything to the screen?
[08:17] <geser> whoever looks at xen now, could the person also look at bug 286450. it was found during the freeze for interpid, but is still not fixed :( Luckily it doesn't cause any upgrade problems
[08:18] <cody-somerville> Jordan_U, the machine doesn't have keyboard or mouse
[08:20] <cody-somerville> Hopefully the logs will shed some light once fsck is done. I guess it likes to be checked more regularly than every 200 days.
[09:08] <lesshaste>  I have crash in gdmsetup in ubuntu.. how do I install the debug symbols so I can give a useful backtrace?
[09:10] <RAOF> lesshaste: Work out what package that's in (I'd guess 'gdm'), add the dbgsym repository (wiki.ubuntu.com/DebuggingHowto), and install gdm-dbgsym.
[09:10] <RAOF> Sorry.  https://wiki.ubuntu.com/DebuggingProgramCrash/
[09:12] <lesshaste> gdm-dbgsym doesn't exist
[09:12] <RAOF> Have you added the dbgsym repository, and updated your package lists?
[09:13] <doko> dholbach: looks fine
[09:14] <lesshaste> RAOF: I need main restricted universe multiverse right?
[09:14] <RAOF> Well, only main for this, but there's no harm in including everything.
[09:15] <cjwatson> geofft: http://cdimage.ubuntu.com/netboot/intrepid/ isn't too bad as URLs go ...
[09:16] <geofft> cjwatson: ooh, thanks. So, uh, where's that documented? :)
[09:16] <cjwatson> geofft: *waves hands*
[09:16] <cjwatson> geofft: where would you like it to be documented?
[09:17] <geofft> cjwatson: preferably, as a result of google(ubuntu netboot). I guess in the text of the first result would work too
[09:17] <geofft> hm, and I guess I can edit that?
[09:19] <cjwatson> geofft: yup - if you just link to http://cdimage.ubuntu.com/netboot/, that has links for other releases
[09:20] <cjwatson> I should probably create a directory there for dapper
[09:20] <geofft> Installation/NetbootInstallFromInternet claims the kernel needs to be chmod +x. Is that actually true?
[09:21] <cjwatson> news to me if it is
[09:21] <pitti> slangasek: could you please give me a quick heads-up for bug 277589? (is that something for jaunty final?)
[09:23] <ivoks> pitti: thanks for dovecot-postfix thing; i'll rewrite 'echo' part for karmic
[09:25] <cjwatson> geofft: ok, http://cdimage.ubuntu.com/netboot/ prettified a bit, and I've added dapper
[09:26] <lesshaste> RAOF: hm... I installed the debug symbols for gdm but... http://www.pastebin.ca/1397160
[09:26] <lesshaste> :)
[09:26] <geofft> cjwatson: :( I don't like to be reminded that dapper still exists
[09:26] <lesshaste> I mean... :(
[09:26] <seb128> pitti, slangasek: hi, bug #363169 is a change for a sru I guess?
[09:26] <lool> cjwatson: Ah!  that's where I saw the orion5x!
[09:26] <lool> http://cdimage.ubuntu.com/netboot/jaunty/
[09:26] <lesshaste> RAOF: do I need some other debug symbols do you think?
[09:27] <RAOF> lesshaste: Looks like you probably want... the glib, gtk, and gio dbgsyms.
[09:29] <cjwatson> lool: ah yes. removed and added imx51.
[09:30] <lool> Thanks
[09:33] <lesshaste> RAOF: ok :)  Just finding the right debug package names is hard.apt-cache search dbgsym|grep gio returns nothing
[09:33] <slangasek> pitti: 277589> I think that's pretty clearly SRU material at this point; I don't think we even have a good patch yet?
[09:34] <pitti> slangasek: SRU> ack; I just don't even know what's going on with this bug in the first place, but you seemed to indicate that it's just a small packaging issue about putting fdi files somewhere?
[09:34] <slangasek> pitti: we put an fdi file in, but it didn't have the intended effect because the systems in question do have a sysfs path set for the backlight - it's just not usable
[09:35] <pitti> slangasek: right, that's what I figured as well, and why I asked for the hal debug output
[09:35] <pitti> so I wasn't completely stupid then
[09:36] <geofft> cjwatson: /netboot/jaunty/ says "alpha", but it looks like the RC now...
[09:36] <slangasek> pitti: I believe there's already enough information there to sort out a correct solution, but it's not at the top of my priority list to discuss this today :)
[09:36] <pitti> slangasek: agreed; thanks
[09:36] <pitti> slangasek: I just seemed to remember that it was something like "where should I put this file" or so, that's why I asked
[09:37] <seb128> pitti: hello ;-)
[09:37] <lesshaste> I am a little mystified.. what do I have to install the get the debug symbols for a gdmsetup crash?  I can't see debug packages for glib or gio
[09:37] <pitti> bonjour seb128!
[09:37] <slangasek> seb128: 363169 - ah, hmm; well, definitely not for final - I guess it should be ok for an SRU, but we'll want to verify it heavily
[09:37] <cjwatson> geofft: fixed, thanks
[09:38] <ogra> slangasek, i uploaded the fix for irda-tilus for bug 340873 ... its not on the CD, please let it through
[09:39] <ogra> cjwatson, will there be a d-i upload before final ?
[09:39] <slangasek> there already was one
[09:39] <ogra> oh, when ?
[09:39] <seb128> slangasek: ok, the code difference is basically a 8 lines function to do updates on changes, let's discuss that for a sru
[09:39]  * ogra discovered yesterday that bug 353196 is a d-i issue, not a kernel one
[09:39] <lesshaste> I am trying to complete this bug report http://bugzilla.gnome.org/show_bug.cgi?id=556458
[09:40] <slangasek> ogra: three days ago
[09:40] <ogra> ah
[09:41] <ogra> well, a workaround is described in the bug so i guess users will have to live with it
[09:41] <ogra> (unles we suddenly SRU d-i :) )
[09:43] <slangasek> ogra: er, what component of d-i creates /etc/modprobe.d/local?
[09:44] <slangasek> "Created by the Debian installer" - this doesn't mean the d-i package, and may not mean a udeb that's in the initramfs
[09:44] <ogra> likely, yes
[09:44] <slangasek> so this bug certainly isn't triaged yet to the point where we could even consider doing a d-i upload for it
[09:45] <lesshaste> RAOF: well.. :) That was awkward..
[09:45] <RAOF> lesshaste: ?
[09:45] <lesshaste> turns out I needed to install gvfs-dbgsym and libglib2.0-0-dbg
[09:45] <ogra> ok, i'll find it out though all pieces needed to boot the slug are in the d-i image ... i would expect the piece that created the cmdline to reside inside the initramfs
[09:46] <lesshaste> hooray for uniform naming schemes :)
[09:46] <ogra> but i need to take a look
[09:46] <lesshaste> (he says sarcastically)
[09:47] <RAOF> lesshaste: If I'd thought of it, I would have suggested "apt-file search $whateverlib.so.2" to find the name of the package to install.
[09:47] <RAOF> Not very useful now, though.
[09:47] <lesshaste> RAOF: that's what I did for each one in the end more or less
[09:48] <seb128> lesshaste: you have binary-dbgsym for everything which is a consistant naming
[09:48] <seb128> lesshaste: the -dbg are usually coming from debian which doesn't have -dbgsym for everything and add those randomly
[09:48] <slangasek> ogra: I've looked in the ixp4xx initramfs and I don't find any references at all to the rtc-x1205 module; so it's not a d-i problem...
[09:49] <lesshaste> seb128: libglib2.0-0-dbg was the odd one out
[09:49] <slangasek> ogra: which is good, it means you have a better chance of getting a fix in
[09:49] <seb128> lesshaste: you have libglib2.0-0-dbgsym too
[09:49] <seb128> lesshaste: libglib2.0-0-dbg is coming from debian as said before
[09:49] <ogra> slangasek, well, the cmdline gets created by d-i during the apex image building
[09:49] <RAOF> IIRC, Debian might be getting a -dbgsym equivalent from this year's GSoC.
[09:49] <lesshaste> seb128: I don't have libglib2.0-0-dbgsym on my system.. are you sure it exists?
[09:50] <slangasek> ogra: what's an apex image?
[09:50] <lesshaste> seb128:  a little script that finds the debug packages from the gdb output would be lovely :)
[09:50] <cjwatson> ogra: actually, no - this particular command-line argument comes from the apex package
[09:50] <cjwatson> ./src/mach-ixp42x/debian-nslu2-armeb_config:148:CONFIG_ENV_DEFAULT_CMDLINE="console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug"
[09:50] <cjwatson> ./src/mach-ixp42x/debian-nslu2-armeb_config:150:CONFIG_ENV_DEFAULT_CMDLINE_ALT="console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug"
[09:50] <cjwatson> ./src/mach-ixp42x/debian-nslu2-arm_config:148:CONFIG_ENV_DEFAULT_CMDLINE="console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug"
[09:50] <cjwatson> ./src/mach-ixp42x/debian-nslu2-arm_config:150:CONFIG_ENV_DEFAULT_CMDLINE_ALT="console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug"
[09:50] <seb128> lesshaste: yes, do you have a ddebs.ubuntu.com source?
[09:50] <cjwatson> (took me a while to track it down)
[09:50] <seb128> lesshaste: use apport, apport-retrace install all the dbgsym required to get a debug stacktrace
[09:50] <ogra> ah, i was looking at the wrong place
[09:50] <slangasek> cjwatson: hmm, though d-i b-d's on apex-nslu2; does that mean d-i does have to rebuild after fixing the apex package?
[09:51] <ogra> ...build/config/armel/ixp4xx/netboot.cfg
[09:51] <cjwatson> reassigned the bug
[09:51] <lesshaste> seb128: I don't think I have a ddebs.ubuntu.com source.. let me check
[09:51] <lesshaste> deb http://ddebs.ubuntu.com hardy-updates main restricted universe multiverse
[09:51] <lesshaste> deb http://ddebs.ubuntu.com hardy-security main restricted universe multiverse
[09:51] <lesshaste> that's all I got
[09:51] <seb128> lesshaste: that would be your issue though
[09:51] <seb128> lesshaste: you should add the same some for hardy if you use hardy, right now you have ddebs only for updates
[09:52] <lesshaste> apport does nothing for me
[09:52] <lesshaste> that let me to try to run gdmsetup.. which crashes :)
[09:52] <lesshaste> that led..
[09:52] <seb128> did you enable it?
[09:52] <cjwatson> slangasek: in order to fix this for jaunty, yes
[09:52] <seb128> it's not enabled by default on stable
[09:52] <lesshaste> seb128: fixing sources...
[09:52] <slangasek> cjwatson: <nod> I'd argue for release notes then
[09:52] <slangasek> ogra: ^^
[09:53] <ogra> slangasek, yes, the fix isnt to hard
[09:53] <cjwatson> no idea how this could have broken since beta though
[09:53] <cjwatson> I'm looking at apex source from December, and the option is there
[09:53] <ogra> though we should SRU apex to not make it reappear
[09:53] <ogra> cjwatson, it didnt show any issues before
[09:53] <lesshaste> seb128: do I need one sources line for hardy and one for updates and one for security?
[09:54] <cjwatson> ogra: yes, I read that in the bug; that doesn't mean I understand why
[09:54] <seb128> lesshaste: right
[09:54] <ogra> cjwatson, me neither
[09:56] <slangasek> ogra: nack on irda-utils; this is a warning only with the current version of udev, and the removal should be guarded by appropriate checks to make sure the file you're removing is actually the one generated by the package
[09:56] <ogra> cjwatson, the apex source doesnt contain the modprobe.d file though
[09:56] <slangasek> (or better yet, move the existing file to the new name...)
[09:56] <ogra> slangasek, so a simple mv ?
[09:57] <lesshaste> seb128: I am sorry about this.. I don't think I am getting these sources lines right... deb-src http://ddebs.ubuntu.com hardy main restricted universe multiverse ?
[09:57] <slangasek> ogra: guarded by appropriate version checks
[09:57] <ogra> slangasek, note that the file isnt shipped by the package, its always been created in the postinst
[09:57] <slangasek> yep
[09:57] <slangasek> it's still a config file by virtue of being in /etc
[09:57] <seb128> lesshaste: what about reading the documentation?
[09:58] <slangasek> so you don't get to twiddle it indiscriminately
[09:58] <mvo> tseliot: can you please have a look at #363500 and eyeball the nvidia-common diff
[09:58] <seb128> lesshaste: https://wiki.ubuntu.com/DebuggingProgramCrash for example
[09:58] <tseliot> mvo: sure, let me have a look at it
[09:58] <mvo> slangasek: is bug #363500 something we can consider for -final or rather a sru ?
[09:59] <lesshaste> seb128: :) always a smart move... I have been looking for something that looks definitive without much l
[09:59] <lesshaste> seb128: uck... that page doesn't have anything about source packages does it?
[09:59] <seb128> lesshaste: why do you need sources now? I though you wanted debug variants
[10:00] <cjwatson> ogra: no, of course it doesn't, that *is* created by d-i, but d-i is just doing what it's told
[10:00] <lesshaste> seb128: sorry I have clearly misunderstood. <seb128> lesshaste: yes, do you have a ddebs.ubuntu.com source?
[10:00] <lesshaste> seb128: that just means the standard lines like deb http://ddebs.ubuntu.com hardy main restricted universe multiverse ?
[10:00] <cjwatson> ogra: (specifically, the source package that does what it's told here is debian-installer-utils)
[10:00] <ogra> ah
[10:01] <lesshaste> seb128: in sources.list and not the src version of those lines?
[10:01] <ogra> well, i guess there is no value in fixing d-i-utils now, but i'll prepare an apex SRU
[10:01] <slangasek> mvo: hmm; requires rebuilding all ISOs; let me have a closer look
[10:01] <seb128> lesshaste: I don't understand the question
[10:02] <seb128> lesshaste: those dbgsym are debug for the normal jaunty binaries, their is no specific sources
[10:02] <geofft> Why does dash use stat() instead of access() for [ -r foo ]?
[10:02] <lesshaste> seb128: I thought you were telling me how to find libglib2.0-0-dbgsym
[10:02] <mvo> slangasek: I can work-around it in u-m, but I guess its the same problem. if we don't have to rebuild for something else its probably not worth it
[10:02] <seb128> lesshaste: ok, I've discussed that enough, what about you read the wikipage?
[10:03] <mvo> slangasek: it breaks all partial upgrades in u-m, but those should rare on stable and we can easily SRU nvidia-common
[10:03] <slangasek> mvo: go ahead and upload; since nvidia-common 0.2.10 was already an exception to try to fix this, I think we should follow hrough
[10:03] <cjwatson> ogra: I repeat, no fix is needed in debian-installer-utils
[10:03] <geofft> I'm running into a bug with a networked filesystem where stat and access aren't the same, and #!/bin/bash seems like the wrong way to fix [
[10:03] <cjwatson> ogra: it is *just doing what it's told* by the kernel command-line arguments
[10:03] <geofft> is this a legit bug in dash?
[10:03] <lesshaste> seb128:  In fact reading the web pages is irrelevant.. the problem was that just misunderstood you.. turns out you just meant add deb http://ddebs.ubuntu.com hardy main restricted universe multiverse
[10:03] <mvo> slangasek: thanks, much appreciated. I will wait for tseliot to have a second look and then upload
[10:03] <lesshaste> seb128: that the talk of source was just to confuse me :)
[10:03] <ogra> cjwatson, oh, ok
[10:04] <lesshaste> seb128: thanks for your help
[10:04] <seb128> you're welcome
[10:04] <slangasek> mvo: don't wait too long, please
[10:04] <ogra> i wasnt aware it was that clever :)
[10:04] <lesshaste> bug report now updated
[10:04] <mvo> slangasek: sure, some minutes only, I tested it already here locally and it works fine
[10:05] <ogra> slangasek, i assume you dont want uploads for SRUs in the queue yet ?
[10:05] <slangasek> ogra: I have no objections at all to SRUs in the queue; the only doubt is whether it's possible to upload them yet
[10:06] <seb128> it is
[10:06] <seb128> I've uploaded some already
[10:06] <slangasek> ok, great :)
[10:06] <ogra> (in case anything enfoces a d-i rebuild having the fixed apex hand might help)
[10:06] <slangasek> there's no reason we would rebuild d-i in SRU
[10:07] <mophiax> Excuse me, what is the state of grub2, is it ready for a production machine?Will it be included in 9.10?
[10:07] <slangasek> so if that's what you're planning to SRU, I don't think you should bother
[10:07] <ogra> i mean before release indeed
[10:07] <lesshaste> now I look at the bug report it starts
[10:07] <lesshaste> 5253	/build/buildd/glib2.0-2.16.6/gio/gfile.c: No such file or directory.
[10:07] <lesshaste> 	in /build/buildd/glib2.0-2.16.6/gio/gfile.c
[10:07] <cjwatson> slangasek: (we do rebuild d-i in SRUs for kernel updates ...)
[10:07] <lesshaste> which is a little mysterious
[10:07] <slangasek> cjwatson: hmm, really?
[10:07] <cjwatson> slangasek: especially ABI changers
[10:08] <slangasek> well, ok
[10:08] <cjwatson> there's a debian-installer upload on http://people.ubuntu.com/~ubuntu-archive/pending-sru.html right now, in fact
[10:08] <ogra> slangasek, let me rephrase ... would you object an apex upload to the archive so in case we have to rebuild d-i before release the fix gets picked up ?
[10:08] <tseliot> mvo: please proceed with the upload
[10:09] <slangasek> ogra: no - that only affects one build on one architecture, so that's trivial to accomodate, please upload
[10:09] <cjwatson> ogra: my concern there is that we could easily end up shipping binaries that don't match the source we provide
[10:09] <cjwatson> if we do that, I think we should commit to rebuilding d-i :-/
[10:09] <lesshaste> anyone know if there is a gnome devel channel around?
[10:09] <slangasek> ah
[10:09] <ogra> cjwatson, yes, that was the reason why i asked
[10:09] <seb128> lesshaste: that means you don't have the glib source on disk so it can't match the codeline to some source
[10:09] <slangasek> apex bits are copied into the image?
[10:09] <cjwatson> slangasek: via a twisty path, but yes
[10:09] <ogra> slangasek, yes, its the part of the netinstall that boots the device
[10:09] <slangasek> ok
[10:10] <slangasek> then yeah, we ought either do them both in final, or both in SRU
[10:10] <slangasek> (and my preference is SRU)
[10:10] <ogra> ok, so i'll keep that back
[10:10] <cjwatson> a release note for this is reasonably straightforward to write, isn't it? I mean, users have a feasible workaround?
[10:10] <ogra> yes
[10:10] <lesshaste> seb128: thanks.. I am slowly learning how to do this stuff...
[10:11] <cjwatson> then I agree, open a task on ubuntu-release-notes with some sample text for the release notes, and let's fix it in an SRU
[10:11] <ogra> i just dont want to lose out if there is a d-i rebuild and i'm afk
[10:11] <cjwatson> ogra: then I recommend uploading apex to jaunty-proposed as if it were an SRU
[10:11] <ogra> ok
[10:11] <cjwatson> ogra: if we need to rebuild d-i when you're away, we can snag the diff from that and push it into jaunty
[10:11]  * slangasek nods
[10:12] <ogra> goo
[10:13] <ogra> d
[10:15] <lesshaste> seb128: ah.. looks like I am stuck at the end of my knowledge.. they want me to "put a breakpoint in g_log and re-run"
[10:15] <seb128> lesshaste:
[10:15] <seb128> gdb software
[10:15] <seb128> (gdb) break g_log
[10:15] <seb128> (gdb) run
[10:16] <seb128> you can do "bt" and "continue" when it stops
[10:16] <seb128> bt gives you a stacktrace, continue resume normal code run until the next break
[10:19] <lesshaste> seb128: thanks! continue oddly just reports the same breakpoint exactly
[10:20] <seb128> the same function can be called several time
[10:20] <lesshaste> http://pastebin.ca/1397184
[10:20] <seb128> it will stop on it each time it's called
[10:20] <lesshaste> seb128: ok... so that seems to go on forever
[10:20] <lesshaste> I just repeated continue 20 times :)
[10:20] <seb128> g_log is called a lot, I'm not sure what you are trying to do
[10:23] <lesshaste> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=556458 I'll wait for the next request from that :)
[10:23] <lesshaste> seb128: you get a thank you
[10:24] <seb128> lesshaste: alex is on #nautilus on irc.gnome.org, could be easier to speak to him there
[10:25] <lesshaste> seb128: I am trying to contact him/her now
[10:29] <mok0> Does anyone know where the file /etc/X11/rgb.txt comes from?
[10:31] <ogra> mok0, x11-common
[10:33] <robert_ancell> seb128: good morning
[10:33] <seb128> hello robert_ancell
[10:33] <seb128> robert_ancell: how are you?
[10:34] <robert_ancell> seb128: good.  anything major happen while I was away (spent all morning catching up on email)
[10:35] <seb128> robert_ancell: no, jaunty is pretty frozen now so it's mainly keeping up with coming bugs and scheduling some stable updates for fixing extra bugs in jaunty
[10:35] <mok0> ogra, no, it's gone from jaunty
[10:36] <ogra> ogra@osiris:~$ dpkg -S /etc/X11/rgb.txt
[10:36] <ogra> x11-common: /etc/X11/rgb.txt
[10:36] <robert_ancell> seb128: yeah, too late for gcalctool update :)  Nothing too major in 5.26.1 though
[10:36] <mok0> ogra, but why??
[10:36] <seb128> robert_ancell: right, I see that you cleaned the gcalctool bugs today ;-)
[10:39] <robert_ancell> seb128: I had a go at some of the rhythmbox ones.  Next week I want to work on a plan on how to tackle compiz
[10:39] <robert_ancell> seb128: I think it is going to need some ruthless bug management to make it more manageable
[10:42] <robert_ancell> seb128: anyway, I'm finished for the day, any requests for tomorrow?
[10:56] <mok0> ogra, what version? I have  x11-common     1:7.4~5ubuntu1
[10:57] <ogra> 1:7.4~5ubuntu18
[10:59] <mok0> orga, that's just weird. I have the same version as you
[10:59] <mok0> dpkg -S /etc/X11/rgb.txt
[10:59] <ogra> well, the file is here
[10:59] <mok0> dpkg: /etc/X11/rgb.txt not found.
[11:00] <mok0> ogra, what arch?
[11:00] <ogra> i386
[11:00] <mok0> ogra, ah, I have amd64
[11:00] <ogra> intresting
[11:01] <ogra> i dont see the file on ARM
[11:01] <geofft> ogra, I bet you upgraded from an older release?
[11:01] <ogra> geofft, doesnt matter, dpkg knows the file
[11:01] <ogra> so it is in the package
[11:01] <ogra> but i can confirm its not on the armel RC image either
[11:01] <geofft> ogra, if I understand how this works... dpkg knows about it because it's a conffile
[11:02] <geofft> and if you ever purge x11-common, it needs to go away.
[11:02] <geofft> that file isn't installed any more, but it sticks around
[11:03] <mok0> geofft: It's on my system too
[11:03] <ogra> ogra@osiris:~$ dpkg -c /var/cache/apt/archives/x11-common_1%3a7.4~5ubuntu18_all.deb |grep rgb
[11:03] <ogra> ogra@osiris:~$
[11:03] <ogra> right, its not in the package
[11:04] <ogra> tjaalton, ^^^^
[11:04] <geofft> I have 1:7.4~5ubuntu3, and don't have the file (this is a fresh install)
[11:04] <tjaalton> bug 300935
[11:05] <mok0> geofft: p.u.c tells you that the file is gone after intrepid
[11:05] <mok0> tjaalton: I was investigating the FTBFS of sng (last comment)
[11:06] <mok0> Somewhere in changelog it says that rgb.txt is obsolete :-)
[11:06] <tjaalton> it is, to the server
[11:06] <cjwatson> upgrades don't necessarily remove obsolete conffiles
[11:06] <mok0> tjaalton: heh
[11:06] <cjwatson> maintainer scripts typically have to frob that by hand (unfortunately)
[11:06] <tjaalton> some clients seem to want it still
[11:07] <mok0> tjaalton: indeed
[11:07] <ogra> tjaalton, yeah, i agree thats unfortunate, legacy apps you build from source might rely on its availablity as well
[11:07] <mok0> Is there a problem putting it back?
[11:07] <tjaalton> mok0: not really
[11:08] <mok0> Perhaps for karmic the file could go in a "legacy-files" package
[11:08] <tjaalton> nah, debian added it back
[11:08] <tjaalton> recently
[11:08] <mok0> ah
[11:09] <cjwatson> moving conffiles between packages is just as painful as removing them, anyway
[11:09]  * ogra thinks glade uses rgb.txt extensively if you use color names for widgets
[11:09] <mok0> tjaalton: are you in a position to push this through?
[11:09] <tjaalton> when will the archive get frozen for release?
[11:09] <ogra> today
[11:09] <tjaalton> mok0: yes
[11:10] <tjaalton> ogra: what time :)
[11:10] <cjwatson> tjaalton: please don't make any decisions on that basis
[11:10] <tjaalton> mok0: well, as in get it ready, but the release manager would have to accept it
[11:10] <cjwatson> tjaalton: if you have a bug fix, get it into the queue ASAP and we'll discuss it
[11:10] <mok0> tjaalton: ok
[11:11] <cjwatson> but we're already in the process of doing hopefully-final CD builds
[11:11] <tjaalton> cjwatson: I was just thinking that would it be too late 9h from now
[11:11] <cjwatson> so this has to be pretty critical
[11:11] <mok0> If it's fixed, it will solve to FTBFS's
[11:11] <mok0> s/to/some/
[11:11] <cjwatson> it's a bit late for that
[11:12] <cjwatson> I'm more worried about application breakage, but we could fix that in an SRU too
[11:12] <cjwatson> tjaalton: it's already "too late" in the sense that we have to delay preparation for any fix
[11:13] <tjaalton> it's pretty trivial to do this one, so I'll prepare it
[11:13] <tjaalton> would un-break a couple of X clients..
[11:13] <cjwatson> tjaalton: that doesn't necessarily mean it's "too late" in the sense of impossible, but it has to be critical
[11:13] <cjwatson> tjaalton: if that's all it is, it should be an SRU, I think
[11:15] <tjaalton> cjwatson: ok, let's do it that way then
[11:15] <mok0> rgb.txt has been in X11 for as long as I remember.
[11:16] <mok0> Apparently it will remain in the file system if you do an upgrade
[11:16] <mok0> So not all installations will break
[11:16] <slangasek> pitti: 277589 is *not* fixed; please leave the bug state as-is until we have a chance to discuss it
[11:17] <pitti> slangasek: oh, ok
[11:26] <ogra> slangasek, does http://paste.ubuntu.com/154599/ suit you better (though note that the file is newly created anyway by "cat <<EOF > $MODFILE_26" so i dont think the moving is actually needed)
[11:27] <slangasek> ogra: given that we're still hammering out a correct solution three days before release, I don't think this change belongs in final
[11:27] <ogra> os SRU ?
[11:27] <ogra> *so
[11:27] <slangasek> yes, please
[11:27] <ogra> ok
[11:28] <liw> wait, what? it's only three days until release? I'd better get working on my kernel rewrite in Python, then
[11:28] <slangasek> (I'm honestly not sure it warrants an SRU either, but that's better than shoving it through the freeze right now)
[11:28] <ogra> right
[11:29] <ogra> my prob is that i cant test anything if it actually works even if the packaging is right ...
[11:29] <ogra> i dont own any IR devices at all
[11:30] <ogra> liw, huh ? i thought we went for mono
[11:30] <liw> ogra, nah, turns out mono begins with m, and microsoft has a trademark on all names beginning with an m
[11:31] <ogra> ahh and i thought they only owned the patent for the single speaker sound output here
[11:45] <cjwatson> evand: could you look at bug 363661?
[11:45] <evand> gah, will do
[11:45] <emgent> uhmm.
[11:45] <emgent> it`s possible make an udev hack for manage the kernel module product keys and id ?
[11:45] <emgent> for example A module have: { USB_DEVICE(0x0c88, 0x17da) },
[11:46] <emgent> it`s possible make an alias from it to { USB_DEVICE(0x19d2, 0x0001) }, ?
[11:51] <soren> emgent: You can make a simple modialias to make it load, but that doesn't mean that the module will attempt to handle the given device.
[11:51] <soren> emgent: If you want to force it to do that, you can poke the relevant vendor/device ID's in the the module's new_id file under /sys
[11:52] <soren> emgent: (found under /sys/bus/{usb,pci,isa,virtio,whatever}/drivers/<name of the driver as known by the kernel>/new_id)
[11:53] <emgent> ok thanks
[11:53] <emgent> looking
[12:35] <hyperair> has anyone heard of the corrupted /home partitions when suspending with jaunty with /home on a SD card?
[12:38] <amitk> hyperair: are you running ext4?
[12:38] <hyperair> amitk: no i am not.
[12:38] <hyperair> amitk: but the problem is not ext4, it's the sd card.
[12:39] <hyperair> amitk: there isn't a single filesystem that will survive attempting to suspend with a USB stick or SD card mounted as /home
[12:39] <soren> hyperair: That really depends.
[12:39] <hyperair> soren: ?
[12:39] <hyperair> really?
[12:40] <soren> hyperair: The suspend magic could sync and remount read-only, etc., etc.
[12:40] <soren> Resuming again is the difficult part.
[12:40] <hyperair> soren: that's bound to fail.
[12:40] <soren> What is?
[12:40] <hyperair> remount ro
[12:41] <soren> hyperair: because?
[12:41] <hyperair> you cannot remount ro any filesystem as long as there are rw filehandles open
[12:41] <hyperair> it'll fail.
[12:41] <hyperair> remount rw while resuming is no big deal
[12:41] <hyperair> that's almost bound to succeed, as long as the filesystem isn't already crapped up
[12:42] <soren> Except the block devices is likely to have disappeared in between.
[12:43] <soren> ..so it's a new block device that is turning up and needs to be mounted in place of the old one.
[12:43] <hyperair> right.
[12:43] <hyperair> you're right.
[12:43] <hyperair> that's very problematic.
[12:43] <hyperair> but the safe way would be to just disable it completely
[12:43] <hyperair> can't we do that for jaunty?
[12:43] <soren> "it"?
[12:43] <soren> suspend/resume?
[12:43] <hyperair> suspending for people with SD cards
[12:44] <hyperair> yes
[12:44] <hyperair> suspend and hibernate
[12:44] <hyperair> disable both of them if you have a SD card mounted as /home
[12:44] <hyperair> i think /media stuff are automatically dismounted
[12:44] <hyperair> but then again i'm not sure
[12:45] <soren> Dunno.
[12:48] <amitk> hyperair: aah, you need to enable usb persist if your usb device contains /
[12:48] <ogra> can someone let usb-imagewriter out of unapproved (was acked by StevenK (mobile universe RM))
[12:48] <hyperair> amitk: usb persist? is that available in the current jaunty kernel?
[12:49] <amitk> hyperair: it should be. It is a file in /sys corresponding to your usb device
[12:49] <hyperair> ah!
[12:49] <hyperair> i see
[12:49] <ogra> amitk, well, depends how his SD is attached :)
[12:49] <hyperair> amitk: whichi file though?
[12:50] <ogra> does usb persistence apply to native MMC devices that are not attached through USB ?
[12:50] <amitk> hyperair: find /sys -name persist
[12:50] <hyperair> amitk: i don't have a jaunty system. acn you do that please?
[12:50] <amitk> ogra: he did say his SD was attached via USB
[12:50] <ogra> hyperair, he doesnt have your devices :)
[12:51] <hyperair> ogra: it isn't my device.
[12:51] <amitk> hyperair: it is machine-dependent :)
[12:51] <hyperair> amitk: just stick a random USB in. i'd like to see what the naming convention is like
[12:51] <amitk> ./devices/pci0000:00/0000:00:1d.3/usb4/4-2/power/persist
[12:51] <amitk> ./devices/pci0000:00/0000:00:1d.7/usb5/5-6/5-6.4/power/persist
[12:51] <amitk> ./devices/pci0000:00/0000:00:1d.7/usb5/5-6/5-6.1/5-6.1.1/power/persist
[12:51] <amitk> ./devices/pci0000:00/0000:00:1d.7/usb5/5-6/5-6.1/5-6.1.3/power/persist
[12:51] <amitk> ./devices/pci0000:00/0000:00:1d.7/usb5/5-6/5-6.2/power/persist
[12:51] <hyperair> ogra: it isn't my system failing. it's on bug #342096
[12:51] <hyperair> i think it's a very serious issue.
[12:52] <ogra> hyperair, yes, but if amitk runs the find that wont help the user
[12:52] <ogra> it needs to be run on exactly the system that has the prob
[12:52] <ogra> thats what i pointed out
[12:52] <hyperair> ogra: i _still_ want to know what the output looks like.
[12:52] <hyperair> ogra: because it needs to be turned on for all USB devices.
[12:52] <Chipzz> hyperair: that has always annoyed me. sometimes I just want to remount something ro, and let whatever app that has rw handles and can't deal with them becoming ro just crash and burn
[12:53] <amitk> hyperair: no, it shouldn't be turned on by default.
[12:53] <Chipzz> preferable in big flames
[12:53] <hyperair> Chipzz: yeah i wish i could do that too.
[12:53] <ogra> hyperair, well, that would be a bad idea
[12:53] <hyperair> amitk: why not
[12:53] <hyperair> ogra: why?
[12:53] <amitk> only bad HW has their filesystem hanging off a USB
[12:53] <geofft> hyperair: are you asking for basically bug 197166?
[12:53] <geofft> or this LKML post? http://lkml.indiana.edu/hypermail/linux/kernel/0803.1/0800.html
[12:54] <geofft> signed off by Greg K-H, even. so it can't be such a horrible idea. :)
[12:54] <ogra> it can drain your battery depending on your USB controller for example ...
[12:54] <leshaste> hi seb128 .. it turns out that gdm has had a patch for my problem for a while.. what is the process to get it applied for hardy?
[12:55] <zul> dholbach: looks ok to me
[12:55] <hyperair> ogra: i see. so basically it doesn't power down the usb at all?
[12:55] <amitk> geofft: note the caveat
[12:55] <ogra> hyperair, *some* controllers dont
[12:55] <ogra> some do
[12:55] <amitk> it will be reverted once userspace becomes intelligent
[12:56] <hyperair> ogra: okayy so it's buggy.
[12:56] <ogra> the HW is
[12:56] <hyperair> hmm
[12:57] <hyperair> so we need to just turn on the SD card device's persist
[12:57] <amitk> hyperair: try it
[12:57] <ogra> and leaving it as a manual option gives you the possibility to decide on a case by case basis
[12:57] <hyperair> amitk: don't have a machine i can test on.
[12:57] <amitk> although I can't see what is in /home that should mess up suspend
[12:57] <leshaste> hi
[12:57] <hyperair> amitk: eh wait. i have a SD card reader... but it's so unreliable i don't use it.
[12:58] <leshaste> http://bugzilla.gnome.org/show_bug.cgi?id=545203 says that crashing bug fix was applied for gdm after the current hardy version
[12:58] <hyperair> amitk: and i don't have any remaining SD cards.
[12:58] <leshaste> is that the sort of thing that can be patched now?
[12:58] <hyperair> amitk: most systems suspend with a desktop environment running. i can't imagine the desktop environment not having any read/write handles
[12:59] <ogra> amitk, looking at the logs that doesnt look like an SD attached through usb
[12:59] <ogra> they usually get sdX device names because the usb reader converts them to usb disks
[12:59]  * amitk nods
[12:59] <hyperair> you mean SD reader
[12:59] <ogra> that has a /dev/mmcblkX naming
[13:00] <ogra> looks like natively attached
[13:00] <hyperair> ah yes it does
[13:01] <hyperair> on my system, once an SD card is ejected, the module needs to be reloaded in order for it to detect a new SD card.
[13:01] <ogra> ouch
[13:01] <ogra> did you file a bug ?
[13:01] <hyperair> mmhm
[13:01] <hyperair> no i didn't
[13:01] <ogra> you should :)
[13:01] <hyperair> i should have, but now i no longer have a SD card to test.
[13:02] <ogra> get one, SD is the future ;)
[13:03] <hyperair> it's expensive.
[13:03] <hyperair> i like my hard disk
[13:03] <hyperair> it stores 160GB.
[13:04] <ogra> its cheaper than the same amount of storage on CDRW nowadays i think
[13:04] <liw> ogra, really?
[13:04] <ogra> well
[13:04] <hyperair> then CDRWs are outdated
[13:04] <hyperair> i use usb sticks.
[13:04] <hyperair> hah
[13:04] <hyperair> they're dirt cheap compared to SD cards
[13:04] <hyperair> and don't require a reader.
[13:04] <hyperair> just a USB port
[13:05] <ogra> a 2G Sd costs me 2.50€ at my discounter
[13:05] <ogra> thats 3CDs
[13:05] <hyperair> ...what?
[13:05] <hyperair> that's cheap O_o
[13:05] <hyperair> at least the number's small
[13:05] <hyperair> let me convert that..
[13:05] <hyperair> hmm
[13:05] <ogra> 4G is around 8€
[13:05] <hyperair> euro to MYR..
[13:06] <ogra> and prices are dropping constantly
[13:06] <hyperair> RM11.
[13:06] <hyperair> interesting.
[13:06] <directhex> bah, whose bright idea was to have parties on a _thursday_?
[13:06] <hyperair> and RM37
[13:06] <ogra> i started using SD over CD a while ago alrteady
[13:06] <ogra> *already
[13:07] <hyperair> ogra: i've got multiple USB sticks. none of them cost a cent.
[13:07] <hyperair> ogra: each of them are 2GB.
[13:07] <directhex> parties at bars on a work night @_@
[13:07] <ogra> well, you cant be cheaper than zero indeed :)
[13:07] <hyperair> ogra: ;)
[13:07] <hyperair> i think it's around RM20 for one here.
[13:07] <hyperair> which amounts to...
[13:07] <liw> ogra, the cheapest I can find is about 2 e/gig for SDHC, 0.8 e/gig for CD-R
[13:07] <hyperair> 20/4.7
[13:07] <ogra> directhex, quick, introduce a bug that makes us delay the release by one day :P
[13:08] <directhex> hyperair, i don't think i've ever paid for a flash drive. i have lots though...
[13:08] <hyperair> directhex: yeah same.
[13:08] <directhex> hyperair, that said, my microsoft one broke & died :(
[13:08] <hyperair> directhex: good riddance
[13:08] <directhex> ogra, tempting.....
[13:08] <ogra> liw, hmm, finnish taxes ?
[13:08] <liw> ogra, and 0.3 e/gig for DVD+R
[13:08] <hyperair> directhex: i've got one sandisk (which died) and two pendrives)
[13:08] <directhex> bloo way!
[13:09] <liw> ogra, possibly, we have a cassette tax for empty media, which might not apply to SDHC though
[13:09] <ogra> liw, ok, i'll take that back for finland then :)
[13:09] <liw> ogra, still, it's much closer than I thought, and also I didn't look very hard for the best deals
[13:10] <ogra> i know at my HW discounter around the corner its cheaper ... they even started selling SDs with movies on them
[13:10] <liw> if I was buying optical media anymore, I wouldn't buy them in Finland anyway
[13:10] <ogra> as added value
[13:11] <dholbach> zul: are you going to upload?
[13:11] <zul> sure ill do it right now
[13:14] <dholbach> super, thanks zul
[13:15] <slangasek> TheMuso: for future reference, please don't comment out code in debdiffs, particularly if you're looking for a freeze exception; the removals should already tell us everything we need to know, and having code within a comment just makes the diff longer to review
[13:21] <seb128> leshaste: which one?
[13:34] <ScottK> ogra: Are you around?  I have a question about your usb-imagewriter upload.
[13:36] <ScottK> Nevermind.  I see StevenK already reviewed it.
[13:37] <ScottK> ogra: Accepted.
[13:45] <lool> stgraber: Did you manage to update the ISO tracker to list the proper armel and +UNR - UMPC?
[13:45] <lool> stgraber: I'd really like this to be fixed for final
[13:49] <mantiena-baltix> hi cjwatson
[13:57] <mantiena-baltix> cjwatson , evand: I have one question about ubiquity translations - why you didn't updated translations in latest ubiquity uploads (1.12.11 and 1.12.12) ?
[13:58] <mantiena-baltix> I've tested jaunty's release candidate and noticed, that installer is almost not translated in lithuanian language :(
[13:59] <cjwatson> the non-language-pack translation freeze was before 1.12.10; any translation updates after that were always going to be best-effort.
[14:00] <mantiena-baltix> So, I've fixed this bug 3 days ago, but my work still isn't included in latest ubiquity packages :(
[14:00] <cjwatson> sorry, but you were too late per the release schedule; your work will be included next time round ...
[14:00] <cjwatson> (the actual answer is likely to be that Evan was in a rush)
[14:01] <mantiena-baltix> cjwatson: I forgot, that ubiquity's translations aren't included into language-packs :(
[14:02] <mantiena-baltix> cjwatson , evand: are there any chances to update ubiquity's translations before jaunty release ?
[14:03] <cjwatson> I doubt it, sorry. We've already started rolling final images.
[14:03] <zul_> dholbach: done
[14:04] <dholbach> zul_: rock on!
[14:05] <mantiena-baltix> cjwatson: maybe you can tell me how to update translations from launchpad for my personal ubiquity package ?
[14:05] <cjwatson> basically just download them and msgmerge them into debian/po/lt.po
[14:06] <mantiena-baltix> cjwatson: ok, thanks for help
[14:07] <cjwatson> I do have scripts to do it, but for a single language it boils down to msgmerge -q -N /path/to/new/lt.po debian/po/templates.pot | msgmerge -q -N - debian/po/lt.po > debian/po/lt.po.new
[14:08] <cjwatson> with some extra faffing about to deal with non-UTF-8 .po files (doesn't apply to lt.po) and removing obsolete translations (only necessary for tidying up)
[14:09] <cjwatson> mantiena-baltix: ^-
[14:09] <mantiena-baltix> cjwatson: thank you very much - Lithuanians will be happy to have a posibility to use installer in native lang :)
[14:10] <cjwatson> next time please try to test sufficiently before the translations freeze that there's time to get your translation in; I really do want to have the installer effectively translated as much as possible, but can only do that if translators work in a timely fashion
[14:14] <mantiena-baltix> cjwatson: I understand, that this is our translation team problem - I simply forgot, that ubiquity's strings will be changed so much in Jaunty - there was no problem in Hardy...
[14:20] <cody-somerville> cjwatson, When I use debootstrap in Jaunty and pass --include=apt, the debootstrap process doesn't seem to complete entirely (ie. apt, among other things it seems, isn't installed) but gives no errors. This doesn't occur with 1.0.8 from Hardy. I assume this is a bug but I noticed that some warnings were added about installing packages with --include that have pre-depends. Although apt doesn't appear to have any pre-depends, I
[14:20] <cody-somerville> wanted to ensure I understood the warning correctly.
[14:21] <stgraber> lool: nag IS
[14:21] <stgraber> lool: I sent the update on Thursday or Wednesday
[14:22] <cjwatson> cody-somerville: can I see the debootstrap log, please? should be debootstrap.log in the created filesystem somewhere
[14:22] <lool> stgraber: Ok thanks, what's the RT #?
[14:22] <stgraber> lool: no idea, it hasn't been triaged yet so doesn't appear on rt.ubuntu.com yet
[14:23] <lool> stgraber: You should have gotten an ack no matter what, no?
[14:23] <slangasek> stgraber: so you still don't have direct access to the DB?
[14:24] <stgraber> slangasek: no, there should be a ticket for that too ...
[14:24] <slangasek> hmm, ok
[14:24] <stgraber> lool: nope, maybe I don't have enough rights, I'm using the ubuntu/ubuntu account
[14:25] <slangasek> stgraber: you didn't just file the ticket by email?
[14:25] <stgraber> slangasek: I did but you only get a mail back when it's been fixed
[14:25] <stgraber> no ack or anything
[14:25] <slangasek> no, you should get an email back as soon as the ticket is open
[14:26] <cjwatson> you should also get a mail for any activity on the ticket - unless rt.ubuntu.com is configured radically differently from the internal one
[14:26] <stgraber> ok, so that part doesn't work
[14:27] <cody-somerville> cjwatson, there doesn't appear to be any debootstrap.log file
[14:27] <lool> mvo: are we leaving update-notifier with level DEBUG logs by default in jaunty as accident, or is this the expected behaviro?
[14:28] <cjwatson> cody-somerville: what debootstrap command line exactly can I use to reproduce this, then?
[14:28] <mvo> lool: meh, that sounds like a accident, let me check
[14:28] <cjwatson> (actually, it might be /var/log/bootstrap.log)
[14:29] <lool> mvo: Spotted in .xsession-errors, I get things like "/usr/lib/update-notifier/apt-check returned 0 (security: 0)"
[14:29] <cody-somerville> cjwatson, ah! I was looking for debootstrap.log
[14:29] <lool> gnome-panel is logging DEBUG too
[14:31] <mvo> lool: its just very few messages there, I fix it in bzr, its probably actually a good thing (if there are problems with auto-launch)
[14:32] <lool> mvo: Just wanted to make sure it was no accident, great if it's useful :)
[14:33] <mvo> lool: its sort of a accident still, so thanks for letting me know :)
[14:37] <cody-somerville> cjwatson, Ah, I see the problem. I'm using a custom debootstrap script and it looks like it needs to be updated to use repeatn instead of repeat.
[14:37] <cjwatson> that would do it
[14:37] <cody-somerville> cjwatson, I'm surprised that debootstrap didn't give any indication of an error though
[14:37] <verwilst> how can you make sure that the versions of one repository always get priority?
[14:37] <verwilst> even if a newer version is available in another repo?
[14:37] <verwilst> with pinning probably
[14:38] <cjwatson> debootstrap's error handling is not always quite ideal
[14:38] <cody-somerville> cjwatson, Should I file a bug or is that a known issue?
[14:38] <cjwatson> it's known
[14:38] <cjwatson> e.g. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472704
[15:12] <wgrant> mvo: The release-upgrader seems to accept a source as official even if it is only for multiverse... users of one big unofficial Australian ISP mirror (which doesn't mirror multiverse) mostly have a multiverse-only au.a.u.c line in sources.list. On upgrade to Jaunty, they are left with just multiverse sources uncommented. Fixable?
[15:14] <mvo> wgrant: hm, could I get a main.log of a upgrade like this please? it should already notice that its missing key packages and do somehting about it
[15:14] <wgrant> mvo: This was an upgrade by CD.
[15:14] <mvo> wgrant: I can easiyl add the unofficial mirror to the known mirror lists
[15:14] <wgrant> So it would have had the critical packages.
[15:14] <mvo> wgrant: oh, I see
[15:14] <wgrant> mvo: Actually, this mirror was renamed recently, so that might do it.
[15:15] <mvo> wgrant: if you mail/msg me the name (or main.log) I add it
[15:15] <wgrant> mvo: http://mirror.files.bigpond.com/ubuntu
[15:16] <mvo> thanks
[15:18] <mvo> wgrant: added
[15:18] <wgrant> mvo: This will still hit CD upgrades with other mirrors, though... Could there be a bit more of a check to make sure main is always left enabled?
[15:18] <wgrant> I can't see a situation in which leaving only multiverse and the CD enabled would be right.
[15:19] <wgrant> mvo: Thanks.
[15:21] <mvo> wgrant: I think it needs to become more clever about unofficial mirrors
[15:22] <mvo> wgrant: yes, its hard to image why someone would want multiverse and CD but nothing else :)
[15:22] <wgrant> mvo: Maybe it could even check if they are unofficial but mirror the real archive... that would be very nice.
[15:23]  * ScottK just got his first mail from a Debian person complaining I hadn't sent a useful Ubuntu change back to them.
[15:23] <ScottK> Ironically, I've still got the mail from back in December when we discussed it ...
[15:26] <mvo> ScottK: happend to me a while ago too, a blog post complaining about changes that I sent back ~3 months before
[15:27] <ScottK> I still get confused between all the changes we do are crap and worthless and how come you didn't give me your change.
[15:28] <broonie> Well, it all comes back to a general "keep in touch" - if you're off-base then communication could perhaps lead to a better solution; if it's a good fix it's nice to know about it.
[15:31] <LaserJock> yeah, communication is a toughest part of working with Debian for me
[15:31] <slangasek> I think it more comes down to "perception trumps reality", and some (but certainly not all) maintainers still being predisposed to believing ill of Ubuntu contributors
[15:31] <LaserJock> I mostly get either no replies, flames, or the occasional "you wanna maintain it in Debian?"
[15:32] <broonie> LaserJock: That sounds like you're working on packages that are effectively unmaintained in Debian...
[15:33] <LaserJock> broonie: usually yes
[15:33] <LaserJock> which makes the whole "contribute back" thing a bit frustrating
[15:34] <cjwatson> I've had the same experience as ScottK and mvo; a vicious flame about not having sent back a change I'd sent back a couple of weeks previously and had a discussion about
[15:34] <cjwatson> fortunately I got an apology after clearing it up, but a slightly less knee-jerk reaction would have been nice
[15:35] <LaserJock> cjwatson: how did they find out about the change?
[15:35] <ScottK> The fun part about today's was they quoted the CoC bit about collaboration at me too.
[15:35] <StevenK> ScottK: "The CoC is not a stick to beat people with, kthxbye"
[15:36] <ScottK> That too
[15:36] <cjwatson> LaserJock: oh, actually I misspoke, it was a vicious flame about using a different fix from that implemented by the Debian maintainer; the latter was implemented in response to my bug report, and I'd acknowledged the comment
[15:36] <cjwatson> people do sometimes respond to mails sent by patches.ubuntu.com though
[15:36] <LaserJock> yeah
[15:37] <StevenK> cjwatson: Because how dare we do that? :-(
[15:37] <LaserJock> I wondered it if it was mostly from the PTS links to patches (which can look awfully ugly at times) and BTS bugs
[15:38] <cjwatson> StevenK: in this case the Debian fix was superior but I'd already acknowledged that and said we'd sync with it next time we were doing an upload anyway
[15:40] <lool> stgraber: Your changes were merged (wee!) however the netboots don't appear to have been split in subarches
[15:40] <lool> can't really say whether desktop armel, mid, and unr are all in place yet, will check when these are built
[15:40] <slangasek> weren't those already in place?
[15:41] <lool> slangasek: UNR has a new top level now; desktop armel was under Ubuntu I think
[15:42] <broonie> LaserJock: I'd expect people to be getting this stuff from the PTS, yes.
[15:52] <ogra> lool, i dont see desktop armel yet
[15:52] <lool> me neither
[15:53] <lool> ogra: well it was built a couple of times today
[15:53] <lool> Hmm no, one time; it's another image which was
[15:53] <ogra> right
[15:53] <lool> but it's on cdimage; I'm grabbing it for now and am waiting until it's on the tracker to test it
[15:55] <slangasek> the 20090420 image isn't going to be final
[15:55] <slangasek> so test it if appropriate, but I'll be posting 20090420.1 to the tracker
[15:55] <lool> Okay
[15:55] <lool> ogra: You can start testing the netboots though, these wont move I guess
[15:56] <slangasek> right
[15:56] <lool> NCommander: Do you think you could test the babbage netboot?  I don't want to setup a tftp server, and http was failing for me
[16:03] <tkamppeter> pitti, hi
[16:07] <slangasek> lool, ogra: there, separate netboot arm tracker entries
[16:07] <ogra> slangasek, cute ... now the same for desktop please ;)
[16:08] <slangasek> hrm?
[16:08] <ogra> no armel desktop entry
[16:08] <ogra> for the babbage image
[16:08] <xq> Does anyone have a second to answer a slightly off topic question about why the main python interpret in Ubuntu does not link with libpython (like in some other distros)?
[16:08] <slangasek> because it's not built yet
[16:08] <ogra> oh
[16:08] <ogra> what did i download then ?
[16:08]  * ogra checks
[16:08] <slangasek> an image that's not a candidate :)
[16:08] <ogra> ah, it only lists 20.1
[16:09] <ogra> i got me 20
[16:13] <pitti> hello tkamppeter
[16:17] <stefanlsd> soren: do you know if its possible to run ubuntu as xen guest on a sles host?
[16:26] <soren> stefanlsd: Sure.
[16:26] <tkamppeter> pitti, can you have a look at bug 363522? Changes in HPLIP 3.9.2 made the automatic call of hp-plugin for firmware download by system-config-printer non-functional. I have applied a simple patch to fix it. SRU or Jaunty upload?
[16:29] <pitti> tkamppeter: I saw the bug subscription, no need to ping me :)
[16:29] <pitti> tkamppeter: anyway, please sub ubuntu-sru and prepare this for a SRU
[16:29] <pitti> tkamppeter: jaunty images are ready, I'm afraid there's no time any more
[16:31] <NCommander> lool, sure, but not until later today
[16:32] <tkamppeter> pitti, OK
[16:33] <tkamppeter> pitti, is it already possible to upload into jaunty-proposed?
[16:33] <pitti> tkamppeter: yes, it is
[16:33]  * ogra would appreciate if people testing .img builds from usb media could use usb-imagewriter and report issues if there are any
[16:33] <ogra> (we promote it in the mobile install notes)
[16:33] <ScottK> And we just uploaded a new version ....
[16:34] <ogra> which fixed a bug :)
[16:35] <pitti> ogra: I'll try that then; my previous attempt with dd doesn't boot at all
[16:35] <pitti> ogra: does this something significantly different to dd?
[16:35] <ogra> pitti, great, thanks
[16:35] <ogra> no, its just a frontend to dd
[16:36] <ogra> it calls dd if=<> of=<> bs=1024
[16:36] <ogra> and just fills the if/of args
[16:37] <pitti> hmm
[16:37] <pitti> well, then "it doesn't boot"
[16:37] <pitti> it boots in kvm, but there the graphics is corrupted
[16:37] <ogra> weird
[16:37]  * pitti tries again
[16:37] <ogra> the .img should have a syslinux mbr in it
[16:38] <ogra> (or a redboot partition if you use armel)
[16:38] <pitti> no, the standard i386 image
[16:39] <ogra> right, that uses syslinux
[16:40] <pitti> ogra: btw, how come that the UNR image is so much bigger than the standard ubuntu one?
[16:40] <ogra> pitti, langpacks, ship seed ...
[16:41] <ogra> the .img's are just using the squashfs from the std image but wrap a vfat partition around that
[16:42] <ogra> we keep a bit of a buffer if people want to add stuff and re-roll the squashfs ... you can do that easier if there is spare space in the vfat
[16:42] <leshaste> seb128, sorry are you still here?
[16:42] <ogra> so the bigger size is the sum of these three
[16:42] <seb128> leshaste: yes
[16:42] <leshaste> seb128, were you asking which version of gdm the patch was applied to?
[16:43] <seb128> leshaste: what patch are you speaking about?
[16:43] <ogra> pitti, we actually enjoy the luxury that we are not bound to CD media size and make shameless use of that fact ;)
[16:44] <leshaste> seb128, http://bugzilla.gnome.org/attachment.cgi?id=115443&action=view
[16:44] <leshaste> from http://bugzilla.gnome.org/show_bug.cgi?id=545203
[16:44] <leshaste> which is the patch for the bug we discussed earlier
[16:44] <seb128> leshaste: that's a glib change and not a gdm one and is in the intrepid and jaunty versions
[16:45] <leshaste> seb128, ah right sorry... so is there any chance it would be applied for hardy? Maybe in backports?
[16:45] <leshaste> seb128, it does stop me running gdmsetup completely
[16:45] <tkamppeter> pitti, SRU for s-c-p uploaded to jaunty-proposed.
[16:45] <seb128> leshaste: if you have a bug convincing that it's worth a sru, there has been no complain about that in a year before today so it's not really an annoyance for hardy users apparently
[16:46] <leshaste> seb128, sorry I don't understand.. I have to convince someone called sru?
[16:46]  * leshaste finds his own ignorance exhausting :)
[16:46] <seb128> leshaste: no, you open a bug and you describe your issue on it and try to be convincing that we should do a stable update (sru)
[16:47] <leshaste> seb128, got you.. thanks
[16:47] <seb128> leshaste: I doubt we will though since it seems to happen in really corner cases and there is no easy testcase nor a lot of request for that change
[16:48] <leshaste> seb128, that makes sense although I don't understand what makes my setup a corner case.. i.e. have I configured it in some weird way?
[16:48] <leshaste> It looks pretty standard to me
[16:48] <leshaste> if I could change my setup to fix it that would be a good workaround
[16:49] <leshaste> currently I can't run gdmsetup at all
[16:49] <seb128> leshaste: dunno what trigger the crash for you but you are the first to run into it, we would have noticed if that was crashing for other people too
[16:49] <leshaste> seb128, the fact they fixed the bug before me does imply that someone else noticed it
[16:49] <leshaste> but I take your general point
[16:49] <seb128> leshaste: you can still edit gdm.conf or gdm.conf-custom using a test editor
[16:49] <leshaste> true
[16:50] <seb128> leshaste: the upstream bug suggested they found the issue by looking at compiler warnings and not because somebody had a crash though
[16:50] <leshaste> true..
[16:51] <leshaste> I'll report it and see what happens.. it's a very small patch :)
[16:51] <leshaste> and thanks for spending the time to talk/think about it
[16:51] <leshaste> this sort of interaction is what makes open source software special
[16:51] <leshaste> it's hard to find M$ developers on IRC :)
[16:52] <seb128> you're welcome
[16:54] <stefanlsd> soren: can it do para or only full virt. I got it working with the alternate cd and full virt
[16:54] <soren> stefanlsd: Paravirt should be fine.
[16:54] <soren> stefanlsd: Just use the -server kernel.
[16:58] <stefanlsd> soren: thanks - how would i choose the -server kernel?   additonal options i pass to xen?
[16:59] <soren> stefanlsd: Well, you do it in the exact same way as you'd otherwise choose a kernel with Xen.
[16:59] <soren> stefanlsd: Depends on how you usually manage your Xen guests.
[17:03] <stefanlsd> soren: using virt-manager. and that uses kernel="/usr/lib/xen/boot/hvmloader"
[17:04] <stefanlsd> soren: this may all be sles weirdness
[17:05] <soren> stefanlsd: You can just use whatever kernel you're used. It's likely to just work, really.
[17:07] <hareldvd> Here is the thing. When my laptop boots network is not yet configured since NM didn´t start it yet. Samba however tries to start since it is in S20 on rc2-5.d but it fails immediately because no network is configured yet. What is the official solution for such a conflict?
[17:07] <stefanlsd> soren: ok. thanks. will give it a try :)
[17:18] <stefanlsd> soren: i copied vmlinuz-2.6.24-24-server and i get Error: (2, 'Invalid kernel', 'elf_init: not an ELF binary\n')
[17:36] <soren> stefanlsd: Perhaps you need to ungzip it.
[17:37] <pitti> ogra: is that known? bug 364195
[17:38] <ogra> pitti, hmm, i dont think there is code that writes logs yet
[17:38] <jdong> kees: for entertainment purposes I tried the udev exploit on a SELinux Lenny box under user staff_u: http://paste.ubuntu.com/154808/
[17:39] <jdong> kees: none of the SELinux restricted user types allow the netlink socket type that's needed to send the exploits
[17:39] <ogra> pitti, apart from what you have in the details win
[17:39] <pitti> ogra: there was nothing, just the dd progress, and the single error line without specifics
[17:39] <pitti> I closed it, since it told me about the log file
[17:39] <pitti> anyway, trying to boot it
[17:39] <jdong> kees: to add insult to injury, refpolicy's udev_t datatype does not allow access to write the payload to a place that a user can LD_PRELOAD anyway
[17:42] <jcole> how do set up my own launchpad ppa repo?
[17:42] <cprov> jcole: https://help.launchpad.net/Packaging/PPA
[17:43] <jcole> cprov: thanks!
[17:44] <cprov> jcole: np, ask for help on #launchpad if you have any problem.
[17:47] <kees> jdong: ah-ha, excellent.
[17:48] <jdong> kees: yeah I just tried again with an unconfined user and udev confined; still the problem is udev cannot write to anywhere useful to put the payload
[17:48] <jdong> and it sure generates a hell of a lot of audit noise
[17:48] <kees> heh
[17:48] <ebroder> kees: Do you know when the openafs security patch is going to go out? Is there anything else I can do to help?
[17:50] <kees> ebroder: for which release?  I think mdeslaur was handling stables last week?  I will check with him.
[17:50] <ogra> pitti, does it boot ?
[17:50] <ebroder> kees: I saw some failed builds for weird arches for both Dapper and Hardy, I think. Dapper, Hardy, and Intrepid all need to be patched
[17:51] <mdeslaur> ebroder: they're coming out today
[17:51] <ebroder> mdeslaur: Oh, awesome. Thanks :)
[17:59] <ogra> lool, hmm
[18:00] <pitti> ogra: no, I just get "boot error"
[18:00] <ogra> the same as with dd i assume
[18:01] <pitti> right :(
[18:01] <ogra> weird
[18:03] <ogra> pitti, any special security stuff you played with that could prevent dd from DTRT ?
[18:03] <ogra> (i know you do such stuff :) )
[18:03] <pitti> ogra: no, it was a standard FAT32 formatted Ubuntu wubi installer before (from usb-creator)
[18:03] <ogra> did you try to zero it with dd first ?
[18:04] <ogra> though it should overwrite everything anyway
[18:05] <pitti> ogra: I didn't zero it; bug updated for some more info
[18:06] <pitti> ogra: I can try to zero it again, hang on
[18:06] <pitti> (although that would again be an usb-creator problem)
[18:06] <pitti> also, if "dd < image" does not work, how would "dd < /dev/zero"?
[18:07] <ogra> how do you dd exactly ?
[18:08] <pitti> right now? sudo dd if=/dev/zero of=/dev/sdb bs=1M
[18:08] <ogra> did you try to omit the bs ?
[18:08] <pitti> and back then, with s_/dev/zero_download/ubuntu/jaunty-netbook-remix-i386.img_
[18:08] <pitti> ogra: yes, last time with the .img I didn't specify a bs
[18:08] <pitti> (but it doesn't actually make much of a difference)
[18:09] <ogra> adding bs might use less ram
[18:09] <ogra> but thats all
[18:12] <ogra> ogra@osiris:~/Devel/imagewriter/intrepid/usb-imagewriter-0.1.3$ file /var/build/images/jaunty-netbook-remix-i386.img
[18:12] <ogra> /var/build/images/jaunty-netbook-remix-i386.img: x86 boot sector
[18:12] <ogra> pitti, what does file report for you ?
[18:13] <pitti> $ file download/ubuntu/jaunty-netbook-remix-i386.img
[18:13] <pitti> download/ubuntu/jaunty-netbook-remix-i386.img: x86 boot sector
[18:13] <ogra> looks ok
[18:14] <ogra> its either an issue with your usb key, your usb port or the port on the netbook you test with i'd guess
[18:14] <ogra> given the nonzero exit in usb-imagewriter i would assume one of the former two
[18:14] <ogra> can you try with another usb key ?
[18:16] <pitti> ogra: as I said, I have used this key dozens of times to boot/install standard ubuntu
[18:16] <ogra> strange
[18:16] <pitti> unfortunately my big usb key can't be trashed right now, and my ancient one is too small (64 MB)
[18:17] <pitti> ok, it's zeroed; trying to write again
[18:17] <ogra> i wish i could send you one as mail attachment :)
[18:17] <ogra> i have tons
[18:25] <lool> ogra: hmm?
[18:26] <ogra> lool, sorry, ignore me ... i thought i had tested the netinstall already (dates to april 17th) ... but i was wrong
[18:26] <lool> Bah I don't see any entry for Ubuntu Desktop armel
[18:27] <lool> slangasek: is this the final spin for armel?
[18:27] <lool> (.1)
[18:27] <pitti> ogra: oh, now I know
[18:28] <ogra> pitti, tell me, i'm curious
[18:28] <pitti> ogra: bug updated
[18:28] <pitti> plz give this .img some diet :)
[18:29] <ogra> hmm, it was supposed to fit on 1G
[18:29] <pitti> that would be nice
[18:29] <ogra> lool, ^^^^
[18:30] <ogra> lool, UNR grew beyond 1G
[18:30] <lool> Addition of standard^
[18:30] <lool> Let's fix the instructions quickly
[18:30] <ogra> yes, we should size down the buffer space a bit
[18:30] <ebroder> Anyone from backporters willing to ack bug #216761?
[18:30] <ogra> iirc we still leave 20M spare ... lets make that 10
[18:31] <lool> 1006M   ubuntu-netbook-remix/daily-live/current/jaunty-netbook-remix-i386.img
[18:31] <lool> That's what I see
[18:31] <pitti> right, that's what I have, too
[18:31] <lool> That's less than 1GB!  :)
[18:31] <pitti> that fails with an 1 GB stick
[18:31] <pitti> lool: no, it's not
[18:31] <pitti> it's less than 1 GiB
[18:31] <lool> Yeah well you understood me
[18:32] <pitti> this is where G vs. Gi matters :)
[18:32] <pitti> unfortunately ls still displays MiB/GiB instead of MB/GB
[18:32] <ogra> lool, lest just strip off 10M
[18:32] <hyperair> what's wrong with MiB?
[18:32] <ogra> so it fits in 1G
[18:33] <pitti> hyperair: just about every hw manufacturer uses MB/GB (power of ten, not power of two)
[18:33] <hyperair> ah right.
[18:33] <liw> I've found that a stick that advertises itself as x gigabytes might be anywhere between 3.8 to 4.2 gigabytes (using the base-10 definition of gigabyte for everything)
[18:33] <lool> ogra: I'm not sure
[18:33] <liw> er, make that 4 gigabytes, not x
[18:34] <liw> I tried to move data from a 4 gig usb stick to another 4 gig usb stick, and whoops, it wouldn't fit :(
[18:34] <lool> ogra: Where's the knob for the remaining free space?  in livecd-rootfs or in debian-cd?
[18:34] <ogra> lool, well, its 6M oversized ... we should have enough buffer to cut that off
[18:34] <lool> Hmm debian-cd I guess
[18:34] <ogra> yeah
[18:34] <ogra> it used to be in build-vfat-img
[18:34]  * pitti leaves the prefix flamewar to others and toddles off to Taekwondo; cu tomorrow!
[18:34] <ogra> but that got merged
[18:35] <lool> ogra: Seems to still be there
[18:35] <lool> size=20
[18:35] <ogra> make that 10
[18:35] <lool> That's common to all vfat images
[18:35] <lool> I want an ack from slangasek / cjwatson at least
[18:35] <ogra> its just empty space
[18:35] <lool> It's final rolling time, I'm not messing up with debian-cd without their ack :-)
[18:36] <ogra> was just reserved for the possible modifications people want to do to the squashfs
[18:36] <ogra> indeed
[18:37] <ogra> no armel desktop on the isotracker :/
[18:37] <lool> ogra: 19:26 < lool> Bah I don't see any entry for Ubuntu Desktop armel
[18:37] <lool> ogra: I've poked them on -release
[18:37] <ogra> good
[18:40] <lool> ogra: Netboot was split!
[18:40] <ogra> yes, i saw that when i looked before starting my slug install
[18:40] <lool> stgraber: yeah!  now if we could get a desktop armel that would be nice  :)  (BTW "armel" is the arch name but the netboots are named "arm")
[18:47] <stgraber> lool: well, I basiccally followed what I received by mail :)
[18:48] <stgraber> lool: Ubuntu desktop armel is there, you just need a release manager to add it
[18:48] <stgraber> lool: is a build already available ? if so what version number ? (I can add it)
[18:48] <ogra> 20.1
[18:48] <stgraber> k, 2s
[18:48] <ogra> http://cdimage.ubuntu.com/ports/daily-live/20090420.1/
[18:49] <ogra> note its in the ports subdir
[18:49] <stgraber> done
[18:49] <ogra> yay
[18:49] <stgraber> well, the download url isn't supported as we have a function to determine the URL and it's not port or armel aware
[18:49] <ogra> yes, i noted that in the armel netinst images already
[18:49] <lessshaste> hi
[18:49] <stgraber> that'd require a code change, then a code review, then get it on production. not something we should do on release week
[18:50] <ogra> but at least we have a place to report install feedback now :)
[18:50] <stgraber> though having that in the DB may be easier, will probably do that for karmic (now that we have a new box and a separate DB, development should be easier)
[18:56] <kees> Keybuk: we auto-send patches to Debian for Ubuntu deltas, but what about security updates?  How can we make that happen?
[18:56] <Keybuk> we don't have MoM for -security
[18:58] <kees> Keybuk: how can we set up something so that security patches show up in the Debian BTS automatically?
[18:58] <Keybuk> kees: it's probably quite trivial actually
[18:59] <kees> Keybuk: that's what I like to hear.  :)
[18:59] <jdstrand> oh, that would be excellent :)
[19:04] <stgraber> hmm, something is wrong with the desktop image for armel on the ISO tracker
[19:06] <Keybuk> it might be as simple as adding a couple of lines
[19:06] <defreng> good evening! Does somebody know where I can find more documentation for the new indicator-applet (espacially for the python API)? The examples unfortunately don't deal with email applications...
[19:07] <ScottK> defreng: #ayatana is the upstream channel for that project.
[19:07] <Keybuk> kees: when are you doing your next security upload?
[19:07] <defreng> ScottK: thx - I'll look there
[19:09] <kees> Keybuk: in a few minutes, when a LOSA is found.
[19:09] <kees> Keybuk: openafs is getting published
[19:10] <Keybuk> ok
[19:10] <Keybuk> let me know if you get an e-mail from MoM about it
[19:10] <Keybuk> if you do, I can redirect that to debian
[19:10] <Keybuk> (prob 2-3 hours after :p)
[19:10] <ebroder> Keybuk: Shouldn't need to for this particular patch; Debian has the fix already
[19:11] <Keybuk> not that e-mail specifically
[19:11] <Keybuk> but the fire hose
[19:11] <ebroder> *nods*
[19:11] <kees> ebroder: right, but this is to make the patches available for things where this may not be true.
[19:12] <Keybuk> do they need to go anywhere particular?
[19:12] <kees> Keybuk: erm, I was assuming they would magically appear in the Debian BTS "ubuntu patches" section?
[19:13] <jdstrand> I wonder if sending them to the Debian security team would be ok...
[19:13]  * jdstrand is torn
[19:14] <kees> jdstrand: they have said they want maintainers contacted, so since this is an existing method, it probably makes the most sense.
[19:14] <jdstrand> kees: right, I meant like a 'CC'
[19:14] <kees> ah-ha, interesting
[19:16] <Keybuk> ok
[19:16] <Keybuk> so casey won't expire all of security now ;)
[19:17] <Keybuk> kees: do you want the opposite direction?
[19:17] <Keybuk> all patches from debian-security mailed somewhere?
[19:17] <jdstrand> oh, I like that idea
[19:18] <jdstrand> kees: what do you think of sending them to security@ubuntu.com?
[19:18] <kees> hrm
[19:19] <jdstrand> I think it could do wonders for universe patches
[19:19] <kees> I'd rather they end up in LP, but the logic for that is non-trivial
[19:19] <kees> okay, sure, let's do it.  I can always filter.
[19:19] <jdstrand> kees: filter, and then have a mutt macro to add them to LP :P
[19:19] <kees> :)
[19:21] <kees> Keybuk: ultimately, we'll probably want the Ubuntu patches CC'd to the ubuntu-security-patch ml too
[19:21] <Keybuk> it may or may not work
[19:22] <Keybuk> hmm
[19:23] <Keybuk> yeah it's definitely possible
[19:23] <Keybuk> it's more changes than I thought
[19:23] <Keybuk> at least 3 lines
[19:24] <kees> hehe
[19:29] <Keybuk> kees: ok, it'll make the second -security upload
[19:29] <Keybuk> the first one will require a few lines of code
[19:29] <Keybuk> which I will do after dinner
[19:29] <Keybuk> I'll need a nudge each time we end-of-line or open a release to maintain the subscription
[19:31] <cjwatson> Keybuk: can you edit https://wiki.ubuntu.com/EndOfLifeProcess and https://wiki.ubuntu.com/NewReleaseCycleProcess to say that, please?
[19:33] <elmo> speaking of EOL, gutsy will be dropping off archive.ubuntu.com and it's mirrors over the next few days
[20:34] <directhex> ikonia, ping
[20:38] <Viper550> I know it may sound a bit...strange, but I'm gonna try and add apt-rpm support to packagekit
[20:40] <directhex> yes, that sounds strange
[20:41] <directhex> strange is a delicate term to use
[20:42] <Viper550> directhex, as in - strange to say in a channel about a superior rival
[20:42] <Viper550> since this may primaraly be for them pclinuxos users
[20:43] <Viper550> heck the freakin thing has a all your base joke in it.
[20:45] <directhex> i only know one pclinuxos user. i would charitably describe him as a douche.
[20:47] <pace_t_zulu> does anyone here have experience with interfacing python with gconf?
[20:48] <liw> pace_t_zulu, a little, a long time ago
[20:49] <pace_t_zulu> liw: do you know how to get and set gconf keys? i am having trouble finding documentation
[20:49] <pace_t_zulu> liw: even if you could help me find some sort of documentation that would be extremely helpful
[20:50] <Viper550> and kpackagekit is qt only, right?
[20:50] <Viper550> *qt4
[20:52] <liw> pace_t_zulu, I don't have time to look things up right now (in the middle of Ubuntu ISO testing), but http://files.liw.fi/temp/sex.py.txt has the code I wrote many years ago
[20:53] <pace_t_zulu> liw: thank you for your help
[21:24] <ikonia> directhex: pong
[21:37] <directhex> ikonia, PM
[21:53] <asac> kees: why did you think that the NeedsSecret call is supposed to be allowed for at_console? just trial and error?
[21:53] <asac> kees: looking at the dbus error it doesnt appear that anything different from uid=0 is involved
[21:53] <asac> so how does at_console fix that call?
[21:53] <asac> kees: (re: pptp plugin for NM)
[21:54] <directhex> hm
[22:06] <asac> so is root implicitly at_console nowadays?
[22:06] <LaserJock> does Ubuntu have an EULA?
[22:07] <james_w> asac: I'm not sure, but as the patch just duplicated the stuff explicitly for root to at_console, I'm not sure why that would change anything
[22:08] <kees> asac: I have no idea why my patch worked, but it did.  I don't know enough about either dbus or the pptp module to say why.
[22:08] <asac> seems like dbus doesnt like if root is at_console
[22:08] <kees> asac: but adding the at_console section fixed it.
[22:08] <asac> thats the current straw we are following
[22:08] <kees> hunh
[22:08] <asac> the vpn definitly only talks to the daemon
[22:08] <Viper550> LaserJock, for all intensive purposes
[22:08] <asac> so only root - root communication
[22:09] <Viper550> there is no "one" EULA covering Ubuntu as a whole. But, different components have different licenses
[22:09] <asac> kees: so if we patched consolekit to make root at_console it might have caused this
[22:09] <kees> asac: I can set up a test environment for that again, if you need.
[22:09] <LaserJock> but is a license a EULA?
[22:09] <Viper550> in a way, yeah
[22:09] <kees> asac: I see, yeah, I'm not sure.
[22:09] <asac> no its a not a EULA
[22:09] <directhex> LaserJock, no, there's no EULA
[22:10] <directhex> LaserJock, you don't need to agree to anything as an end user. there are licenses relating to modification and duplication
[22:10] <LaserJock> that's what I was thinking
[22:11] <LaserJock> I get confused when other distros have EULAs
[22:11] <LaserJock> i.e. openSUSE
[22:11] <ScottK> Do they ship proprietary stuff that needs a license accepted?
[22:12] <Viper550> most of them are usually "blablabla most components are under free licenses such as the GPL bla bla bla, we provide no warrenty, we provide no right for you to use our trademarks like this"
[22:12] <LaserJock> ScottK: not sure, but the EULA basically said "yeah, this stuff is mostly GPL, go for it" I thought
[22:12] <LaserJock> what Viper550 said
[22:12] <Viper550> *"...and p.s. have fun :3"
[22:13] <mdke> that appears vaguely somewhere on our website, at the /legal page
[22:13] <ScottK> That's what I vaguely recalled, but it was 10.1 the last time I used opensuse, so I really don't recall.
[22:13] <jdong> it also has a please-don't-benchmark clause IIRC.
[22:13] <LaserJock> I think they redid it recently
[22:13] <jdong> fairly boilerplate legalese
[22:13] <asac> kees: are you sure that we use consolekit for at_console now? and not the pam-foreground thing?
[22:13] <james_w> asac: I'm pretty sure
[22:13] <LaserJock> anyway, I got an email asking for a link to Ubuntu's EULA and I wasn't sure how to respond
[22:14] <kees> asac: I am not 100% sure, but nearly so.  I would look to pitti for that answer.  or james_w :)
[22:14] <james_w> yeah, pitti is the best to ask
[22:14] <LaserJock> "no" or "each package has its own license, but basically ... [link to ubuntu.com goodness]"
[22:14] <mdke> LaserJock: send them to /legal.
[22:15] <james_w>   * Re-add accidentally dropped consolekit dependency. There are still a few
[22:15] <james_w>     programs using "at_console" in their dbus policy.
[22:15] <LaserJock> mdke: that's a pretty poor description
[22:15] <asac> james_w: thats dbus?
[22:15] <james_w> yep
[22:15] <mdke> LaserJock: it's all there is though
[22:16] <lool> kees: Around?  Do you think you'd know what could cause 364290?
[22:16] <lool> bug #364290
[22:16] <lool> Note: not the same warning as /dev/tty on the desktop
[22:16] <LaserJock> mdke: hmm, I'm not sure. I think http://www.ubuntu.com/community/ubuntustory/licensing is much more clear
[22:17] <kees> lool: sounds like the kernel is forcing PROT_EXEC for mmap calls.
[22:17] <LaserJock> mdke: /legal suggests that people read the license of *every* package before installing
[22:17] <LaserJock> mdke: that's rather impractical
[22:17] <lool> kees: Could it be a kernel config?
[22:17] <kees> lool: we faced that on i386 when init was set to have an executable stack
[22:17] <kees> lool: it's likely the way in which you transition to init from the boot process.
[22:17] <mdke> LaserJock: yes, it's nonsense
[22:18] <kees> lool: in normal Ubuntu, we use klibc to exec upstart, how does ARM do it?
[22:18] <lool> kees: In theory in the same way
[22:18] <LaserJock> mdke: perhaps a link to the ubuntustory licensing page would be a better idea
[22:18] <mdke> LaserJock: but the licensing page is really dealing with the distinction between different repositories rather than any obligations that users might have
[22:18] <lool> kees: Not quite sure we use klibc though, it could be regular libc
[22:19] <james_w> asac: it appears as though root is no at_console
[22:19] <kees> what program is pid 1 during the booting phase?
[22:19] <LaserJock> mdke: right, it's not sufficently legalese, but it does give the read an idea of the category of licensing they're dealing with
[22:19] <lool> kees: Checking...
[22:19] <LaserJock> mdke: something like the DFSG would be good
[22:20] <lool> Crap, FS check
[22:20] <mdke> LaserJock: my point is that the page deals with redistribution issues, not use
[22:20] <LaserJock> mdke: hmm, right
[22:20] <lool> kees: Will take a while, will come back to you when it's booted
[22:20] <lool> kees: thanks!
[22:21] <asac> james_w: did you run a test case to see that? or just reading code?
[22:21] <james_w> asac: just from looking at code
[22:21] <kees> lool: okay, in the meantime, I'm hunting the fixes for klibc that I got upstreamed
[22:22] <LaserJock> mdke: well, so basically it's "we don't know, we don't think there are any EULAs but we could be wrong"
[22:22] <mdke> LaserJock: there aren't any - users have unrestricted use of Ubuntu as far as I know. But I could be wrong, I guess
[22:22] <kees> lool: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commitdiff;h=812e2ff7e74e8c495c936981ba0a0372e50b7244
[22:23] <ScottK> Unrestricted use is guaranteed for Main/Universe.
[22:23] <Viper550> "Must allow modification and distribution of modified copies under the same license"
[22:23] <ScottK> Restricted might have use restrictions, but I'd be suprised.  Multiverse is full of them.
[22:24] <Viper550> oh no...so that means licenses that allow licensing under different terms aren't allowed?
[22:24] <asac> ScottK: unrestricted use of code is more accurate i guess. trademarks, icons and stuff ...
[22:24] <ScottK> Right.
[22:24] <kees> lool: what does   sudo cat /proc/1/personality   say ?
[22:24] <ScottK> Viper550: It same .. same license, not .. only the same license.
[22:25] <LaserJock> ScottK: did you find a page that says that unrestricted use is guaranteed?
[22:26] <asac> http://www.ubuntu.com/community/ubuntustory/licensing
[22:26] <ScottK> LaserJock: No, but I know the licensing policy for Main/Universe.  We use DSFG (with some minor differences over interpreation) and that's guaranteed in DFSG.
[22:26] <asac> Viper550: ^^
[22:27] <mdke> I suppose there is also http://www.ubuntu.com/community/ubuntustory/components
[22:27] <asac> i guess the second title should read "multiverse" and not "main". but havent read the content
[22:27] <LaserJock> ScottK: is it? I'm reading the DFSG and I don't see it exactly
[22:28] <LaserJock> the /ubuntusotry/licensing page specifically doesn't meantion Multiverse
[22:28] <ScottK> LaserJock: Between DFSG 5 and 6, I'm not sure what's left.
[22:28] <LaserJock> "The thousands of software packages available for Ubuntu are organised into three key components: main, restricted and universe."
[22:29] <lool> kees: 00c00000
[22:29] <asac> unrestricted is wrong word obviously. its restricted by a free license usually
[22:29] <kees> lool: yeah, looks like READ_IMPLIES_EXEC is getting set (this should not be)
[22:29]  * ScottK looks around for a lawyer and steps out of the discussion.
[22:29] <kees> lool: I would have expected 00000000
[22:30] <kees> lool: /proc/$pid/personality exists because I spent so long debugging this issue on ia32.  ;)
[22:30] <lool> kees: I can confirm that /sbin/init uses libc; /lib/vfp/libc actually
[22:30] <LaserJock> ScottK: well, take something like "by installing this software you agree to name a child,pet,planet, or rock after me"
[22:30] <lool> (lsof -p 1)
[22:30] <LaserJock> ScottK: I'm not sure that 5 & 6 would disallow that, but I could be way off
[22:31] <kees> lool: /sbin/init in the boot setup, right? not upstart itself?
[22:31] <mdke> LaserJock: not to nitpick about your example, but there could only ever be restrictions on the way the software is used; it's not a contract
[22:31] <kees> lool: does your local shell have 00000000 personality?
[22:31] <lool> kees: Sorry, I'm just saying PID 1 uses /lib/vfp/libc
[22:32] <lool> kees: Yes
[22:32] <LaserJock> mdke: "way"? or "use"?
[22:32]  * ScottK notes mdke is a lawyer (IIRC) and defers to his interpretation ...
[22:32] <lool> kees: sudo cat /proc/self/personality returns 00c00000
[22:32] <kees> okay, and the ARM is > CPU_ARCH_ARMv6 ?
[22:32] <lool> No
[22:32] <lool> Well
[22:32] <LaserJock> mdke: can it restrict use or just the way it is used?
[22:32] <lool> It is but, it's built for v5
[22:32] <lool> v5t actually
[22:32] <kees> hrm.
[22:32] <lool> And the /vfp is a VFP version of the lib
[22:32] <mdke> LaserJock: both
[22:32] <kees> I'm looking at arm_elf_read_implies_exec in arch/arm/kernel/elf.c
[22:33] <mdke> ScottK: in my experience free software developers are much more well informed about these issues than lawyers :)
[22:33] <kees> lool: hrm, so all the processes have 00c00000 ?  that would seem to imply that ARM architecture doesn't have NX protections
[22:34] <TheMuso> slangasek: ok, it was taken directly from the debian git packaging branch. Thanks for the heads up
[22:35] <lool> kees: Perhaps it doesn't; how could I check?
[22:35] <lool> kees: In which case we should disable AA?
[22:36] <kees> lool: can you paste /proc/cpuinfo somewhere for me?
[22:36] <LaserJock> mdke: in any case, am I OK to tell this person that the Ubuntu CD doesn't have a EULA, but point to /legal ?
[22:36] <kees> lool: disabling AA on ARM seems unfortunate.
[22:36] <Viper550> Also is it me, or did the ATI drivers on later versions of Ubuntu drop support for older models?
[22:37] <lool> kees: we're moving to v6 next cycle
[22:37] <kees> lool: I was hoping someone could run the regression tester I wrote on an ARM image: http://people.ubuntu.com/~kees/qrt-test-kernel-security.tar.gz
[22:38] <lool> kees: http://pastebin.com/f147ffe7c
[22:39] <kees> hm, nx isn't listed, but that flag (and not the internal kernel routines) may only be x86-specific
[22:43] <kees> lool: what does   readelf -l /sbin/init   show ?
[22:44] <kees> lool: (specifically interested in GNU_STACK item, and if it says "RW" or "RWE")
[22:44] <lool> http://paste.ubuntu.com/154973/
[22:45] <kees> lool: okay, so the executable itself isn't marked as needing an executable stack, so it must be coming from the kernel side
[22:45] <mdke> LaserJock: I don't see why not; after all if we can't find one, then it means that a new user is unlikely to :)
[22:45] <LaserJock> mdke: good point ;-)
[22:47] <mdke> does anyone know if there is a list somewhere of all the applications in the partner repository and their uses?
[22:47] <kees> lool: interesting, the personality flags map to READ_IMPLIES_EXEC and ADDR_LIMIT_32BIT
[22:49] <kees> lool: so, near as I can tell, the kernel's arm_elf_read_implies_exec is returning "1", and the executable_stack is correctly set to EXSTACK_DISABLE_X (via the ELF headers)
[22:50] <kees> lool: the only way that can happen is:
[22:50] <kees>         if (cpu_architecture() < CPU_ARCH_ARMv6)
[22:50] <kees>                 return 1;
[22:52] <mdke> for example, is there any way I can tell what the difference is between adobe-flashplugin (partner) and flashplugin-installer (multiverse)
[22:53] <kees> lool: according to your /proc/cpuinfo, you've got CPU_ARCH_ARMv5TEJ not CPU_ARCH_ARMv7
[22:53] <kees> lool: "CPU architecture: 7" vs arch/arm/include/asm/system.h
[22:54] <kees> lool: though I find it interesting that arch/arm/kernel/setup.c does not have CPU_ARCH_ARMv5TEJ mentioned
[22:55] <LaserJock> mdke: do the descriptions help?
[22:55] <jameswf> kernel folks ?
[22:55] <mdke> LaserJock: not for me, at least
[22:55] <LaserJock> mdke: I know what the difference is but I'm not sure it's obvious to users
[22:55] <mdke> LaserJock: please tell me :)
[22:55] <kees> lool: I take it back, you *do* have CPU_ARCH_ARMv7
[22:56] <kees> lool: the /proc/cpuinfo file would say 5TEJ if that's the type you had.  :)
[22:56] <kees> lool: so, I'm back around to execstack settings.
[22:56] <slangasek> lool: final spin for armel> well, it looks like libxml2 got built for arm since then (which is good), so we'll want to respin again (meh)
[22:56] <LaserJock> mdke: the one in -partner has the actual Flash binary, the one in -multiverse is just a wrapper script that downloads it from Adobe
[22:56] <mdke> LaserJock: are you sure? the description on the partner package says that it downloads it too
[22:56] <kees> lool: let me write a READ_IMPLIES_EXEC test for you, one sec...
[22:57] <LaserJock> mdke: last I looked that's the way it was. Look at the package size
[22:57] <jameswf> KernelPeople: what would be the best way to get files related to Bug: 268502 without cloning the whole git...
[22:58] <mdke> LaserJock: "This package will download the Flash Player from Adobe". Maybe it's just unclear language
[22:58] <LaserJock> mdke: more like they copied it from somewhere ;-)
[22:58] <mdke> LaserJock: possibly. I see the package is a lot bigger.
[22:59] <mdke> LaserJock: so I guess that suggests that we should recommend that package in the documentation ahead of flashplugin-installer
[22:59] <lool> kees: The platform is v7 and the kernel targets that, but the userspace is v5t, sorry for not being clearer
[23:00] <kees> lool: so after you've logged in via gdm, your /proc/self/personality still shows 00c00000 ?
[23:00] <LaserJock> mdke: you might want to get an official word on that. I generally find that the -multiverse version is better
[23:00] <lool> kees: I was logged in via gdm all the time
[23:00]  * kees scratches his head
[23:01] <LaserJock> I guess Canonical would want to push -partner
[23:01] <mdke> LaserJock: interesting. Do you know why?
[23:01] <LaserJock> mdke: because MOTU maintains it better than Adobe/Canonical? I don't know
[23:01] <mdke> LaserJock: maybe the flashplugin gets a more recent version
[23:02] <LaserJock> perhaps the -partner packages have more red-tape
[23:02] <kees> lool: does cups actually run, or is AA fully blocking it?
[23:02] <lool> kees: I see a process at least
[23:03] <kees> lool: did you get a chance to run the qrt script I gave a URL to?
[23:04] <lool> kees: Oh no missed it
[23:04] <mdke> LaserJock: could be. I might try and get some guidance on this from someone involved in partner
[23:04] <mdke> LaserJock: it would be quite useful to have a comprehensive list of packages and their pros/cons
[23:04] <kees> 21:37 < kees> lool: I was hoping someone could run on an ARM image the regression tester I wrote: http://people.ubuntu.com/~kees/qrt-test-kernel-security.tar.gz
[23:05] <kees> lool: you'll need python-unit, lsb-release, and build-essential, and libcap-bin
[23:05] <james_w> LaserJock, mdke: /var/lib/dpkg/info/flashplugin-nonfree.postinst
[23:05] <LaserJock> mdke: for Intrepid there is only 5 packages in -partner, I suppose you could do it by hand
[23:06] <mdke> LaserJock: oh :)
[23:06] <lool> kees: Does it output a log or will you want stdout?
[23:07] <kees> lool: it spews to stdout.  once unpacked:   ./test-kernel-security.py -v
[23:07] <LaserJock> james_w: nifty
[23:07] <mdke> james_w: I don't seem to have that
[23:07] <kees> lool: you can just pastebin it
[23:07] <LaserJock> mdke: it basically says that it's downloading the Flash tarball from -partner
[23:07] <james_w> mdke: ah, you don't have it installed. It indicates that flashplugin-nonfree downloads from partner, so it's probably not a version thing.
[23:08] <james_w> it may be to do with some of the other things that it does though
[23:08] <LaserJock> james_w: that must be recent
[23:08] <james_w> this cycle I think
[23:08] <LaserJock> yeah
[23:08] <LaserJock> it used to be they were totally different versions
[23:09] <LaserJock> mdke: so it looks to me like the -multiverse package is now just legacy
[23:09] <LaserJock> other than if people don't want to enable -partner but have -multiverse enabled
[23:14] <lool> kees: Sorry netsplit http://paste.ubuntu.com/154988/
[23:15] <lool> kees: note that CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR needs to be <= 32768 on arm
[23:15] <kees> lool: correct, though that should be unrelated
[23:16] <lool> Yeah, just a note
[23:17] <kees> lool: holy crap, there are a lot of missing kernel config options.
[23:17] <mdke> damn, netsplut
[23:17] <kees> lool: these should be turned on: CONFIG_DEBUG_RODATA, CONFIG_STRICT_DEVMEM
[23:18] <lool> amitk: ^
[23:18] <lool> kees: See, I knew we were missing some options; it's been a consistent source of bugs, so I had a good change betting on that   ;-)
[23:19] <kees> amitk: I would have expected CONFIG_SECURITY_SELINUX and CONFIG_SECURITY_SMACK too, but I can understand skipping them.  :)
[23:23] <kees> lool: wow, no randomization in the kernel memory either.  that's sad (that's an upstream deficiency)
[23:34] <syke> will gcc-snapshot be updated to GCC 4.4 RC1?
[23:35] <TheMuso> syke: I'd say not at this late stage.
[23:36] <syke> the last snapshot taken was before all the P1 bugs were fixed; it would be nice if that wasn't ignored
[23:37] <TheMuso> syke: considering jaunty releases on Thursday, and we are in release freeze, probably not before Jaunty releases.
[23:37] <syke> ok
[23:37] <syke> what would the process be for getting it updated in jaunty, after the release?
[23:38] <TheMuso> syke: It would have to be a stable release update, and even then will likely not be applicable.
[23:38] <syke> right. and what's the process for nominating such things?
[23:39] <syke> or should I go through canonical support for this?
[23:39] <TheMuso> syke: http://wiki.ubuntu.com/StableReleaseUpdates
[23:51] <Caesar> slangasek: you're problem very busy finishing off Jaunty, but do you know who's a good person to talk to about libxcb problems in Hardy?
[23:52] <slangasek> Caesar: possibly tjaalton, or #ubuntu-x generally
[23:52] <Caesar> okay, thanks
[23:58] <kees> lool: we can have a work-around for the apparmor parser in a moment; I'm rather doubting that READ_IMPLIES_EXEC can be made to go away at such a late day.  though the root cause should be found for ARM during Karmic