[02:26] Riddell: I'm afraid not. That would result into inconsistencies in Rosetta and duplicate files in two packages (-base and the updates). [03:10] ArneGoetje: the changes in question were made to the -kde-base langpacks, uploaded, and accepted; what are the consequences of this? [03:22] 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. === TheMuso_ is now known as TheMuso [03:23] slangasek: until the next round of full exports resulting in new -base packages being built. [03:27] http://uploads.ungrounded.net/257000/257818_SuperMarioLand2foreal.swf [03:27] If you're using gnash, watch this [03:27] it's funny, but more funny when it doesn't get 40-60 seconds out of sync [03:30] ArneGoetje: yes, which means that the packages will have unnecessary duplication; but will anything break? [03:30] slangasek: I don't think anything will break. Just the duplications. [03:59] slangasek: shouldn't we then not patch all the -kde-base packs? [04:11] 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] I am wondering if this is a direction that the official Ubuntu would like to explore. [04:12] 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] AndyTim: that's probably something you want to ask in ~6 hours, FYI. Most of Europe is asleep now. [04:12] Hobbsee: I see. Thank you very much. [04:13] AndyTim: you're welcome [04:13] * TheMuso can only think of one thing, nelss the livefs was on a local server. lag. [04:13] unless [04:15] 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] AndyTim: how much bigger would that make the livecd? [04:17] ArneGoetje: sorry, I'm not following your double-negative [04:17] AndyTim: vfs caching doesn't help with latency much [04:18] pwnguin: The mere addition of the FUSE module and httpfs binary into the compressed initrd. [04:18] pwnguin: But the Ubuntu web-site could offer a gPXE floppy image for people to try Ubuntu out. [04:18] lifeless: That's too bad. [04:19] AndyTim: well if you want it in the official livecd, there's rigid constraints on the size of a CD [04:19] AndyTim: do some quick figures - 512 bytes a sector, 200ms latency (say, which is actually very optimistic for cross-world latency) [04:19] pwnguin: I'm talking probably a couple of megabytes. [04:19] there's also the requirement that the livecd continues to have an initrd. [04:20] 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] 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] 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] AndyTim: hundreds of thousands [04:23] lifeless: I'm not suggesting transferring the entire squashfs into the client's RAM, but maybe you know that. [04:23] thats hundres of thousands of round trips, no? [04:24] pwnguin: I don't think so. [04:25] Well, people install via HTTP, so it can't be that bad. [04:25] 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] AndyTim: install is radically different [04:25] anyways, if you think its worth pursuing, subscribe to ubuntu-devel, write up a blueprint and attend uds if you can [04:25] AndyTim: install is one round trip per package to download [04:26] ArneGoetje: AIUI, he patched all the ones for which desktop files were actually missing; is that not the case? [04:26] slangasek: I don't know [04:26] i dont see a substantial reason this couldn't be done if someone's willing to actually do it and test it [04:27] Well I'm at it right now. I wanted to gather some devel feedback, and I have some now. [04:27] AndyTim: the ubuntu-devel mailling list is a better place for peer review [04:27] pwnguin: I see. [04:28] it's a asynchronous communication channel, if you will [04:28] 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] slangasek: ah, ok, according to the bug report he did. [04:30] 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] 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] AndyTim: its very much going to depend on how effective request coalescing is [04:34] AndyTim: A first approximation would be to add latency to your http server and just boot off it [04:34] lifeless: I wonder if it's also possible to optimize the squashfs for booting at all. Maybe not. [04:34] lifeless: Yes. [04:41] pwnguin: The contraints you mentioned are due to trying to pack the squashfs as fully as possible? [04:41] pwnguin: Or is it more about RAM in-use by the initrd? [04:47] AndyTim: the main constraint I'm aware of is that the liveCD .iso can only be so big [04:48] pwnguin: Yes. Thanks. [04:48] AndyTim: we already exceed the physical limits of a cdrom [04:48] lifeless: Pushing .ISO? Heheh. Good for you folks. [04:48] (CD, I mean) [04:48] AndyTim: squashfs is one tool to get an iso that fits on a cd people can burn [04:48] AndyTim: so all changes get pressured to fit [04:49] 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] Heh. [04:50] However I can appreciate not wanting to manage initrds for use cases. [04:50] you want to duplicate all of initrd for this? [04:51] I was simply going to add to scripts/casper, for example, and add any needed binaries. [04:51] Minimally, that would be wget or curl or something [04:52] By the way, it appears that a flavour of Knoppix does all this already. [04:55] 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] is httpfs packaged in ubuntu? [04:57] Not that I know of, unfortunately. I tried to apt-get it earlier... [04:57] that might be a good starting point for you then [04:57] But it's compatible; I've tested the downloaded binary [04:57] pwnguin: You mean packaging it? [04:58] yea [04:58] 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] well it'd be a significant hurdle to get core devel to accept a initrd script that wgets a binary [04:59] (As clearly users could benefit from Ubuntu-via-NIC-ROM/floppy/128 MB USB stick, etc. if it all works) [05:00] pwnguin: Oh? This would only happen if NETBOOT= some URI. [05:00] on the otherhand, im not sure they'd go for apt-get either [05:00] pwnguin: Goes against some policy? [05:01] pwnguin: Well if the initrd is separated from the installer CD case, the size constraint disappears. [05:02] AndyTim: perhaps you should write the mailing lists and get a wider audience than whoever's paying attention [05:02] Heheheh. Yes, first I will have one hosted for folks to try. Then I will e-mail. [05:03] Hmm, that reminds me, gotta make sure that jives with Ubuntu. Hosting it publicly, that is. [05:03] hosting what? [05:03] Hosting folks booting Ubuntu from me. [05:04] It's little different than a mirror, I'd imagine [05:04] i think the main problem is yours [05:04] how does the gpl source requirement work in that situation? [05:05] Yeah I just mean I will have to perform the diligence and be sure Ubuntu doesn't say not to anywhere. [05:05] AndyTim: its the same as a mirror of the binary debs [05:05] AndyTim: you can definitely do it, you just need to meet the source distribution requirement too [05:06] lifeless: Thanks for that. With fortune, this can be the same referral that the CD would use, I imagine. [05:07] AndyTim: CD's we ship (physical ones) have a written offer [05:07] AndyTim: .iso files people can download have the source available from the same site, no external referring [05:07] There's the catch, then. [05:08] http://www.fsf.org/licensing/licenses/gpl-faq.html#UnchangedJustBinary [05:09] http://www.fsf.org/licensing/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites is better actually [05:09] lifeless: I thought mdz said that people could point to Ubuntu [05:09] LaserJock: i think the project in mind requires some modifications [05:09] * AndyTim reviews both. [05:09] 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] pwnguin: hmmm, yeah, you would have to have the source for the modifications [05:10] lifeless: yep [05:10] LaserJock: consider tracking kinky, binaries you mirror will have their sources garbage collected quite frequently [05:10] Ideally this would be a success and the Ubuntu community would enjoy hosting it. :) [05:12] AndyTim: well, thats one of the nice things package management offers: source packages [05:13] 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] 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] pwnguin: A graphics one? One could possibly parse the output of another tool... What is _it_ called again, though... [05:14] bootchart? [05:17] aha [05:17] http://oss.oracle.com/~mason/seekwatcher/ [05:17] Nice. [05:38] As a matter of fact, the initrd's BusyBox has wget already. We're talking text compression, then. [05:40] 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] 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] AndyTim: I made http://tinyurl.com/intrepid-netinst some time ago after getting tired of Googling [06:14] I assume you found it by now, but hopefully this is helpful in the future :) [06:15] No, actually, I didn't. [06:16] geofft: So thanks. Is that a simple conversion of the ISOLINUX stuff? Looks like it's not quite as full. [06:18] No gfxboot, it seems. [06:20] I'm not sure... my limited understanding is that it's smaller than the alternate CD [06:20] personally, I only use that directory to boot linux+initrd.gz via GRUB [06:21] geofft: Ok. Thanks. [07:08] Good morning [07:08] pitti: And to you. [07:09] Morning pitti [07:12] good morning [07:12] * pitti hugs dholbach [07:13] * dholbach hugs pitti back [07:27] zul: how does bug 362691 look to you? [07:27] Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Medium,Triaged] https://launchpad.net/bugs/362691 === tkamppeter_ is now known as tkamppeter [07:53] 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] LILO isn't suppose to get installed on upgrade to Jaunty, is it? [07:56] slangasek: remaining langpacks NEWed, that should clean up component-mismatches further [07:56] ah, yes [07:56] thanks [08:01] cody-somerville: no, but that bug should have been fixed - did you dist-upgrade, or use the upgrade manager? [08:01] dist-upgrade [08:01] that would probably be why, then. [08:02] why would dist-upgrade install lilo? [08:04] cody-somerville: that would be https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/314004 [08:04] Ubuntu bug 314004 in ubiquity "Lilo gets installed on dist-upgrades, due to the kernel image recommending it. Is this intentional?" [Critical,Fix released] [08:04] (i think) [08:04] ah bad dependency eh [08:05] but if that bug is fixed, shouldn't dist-upgrade not pull lilo any more? [08:05] it doesn't pull it in; it's already thee [08:05] there [08:06] indeed [08:06] hyperair, You should have read the bug report Hobbsee pasted if you're so interested [08:08] cody-somerville: did. [08:08] jsut did [08:09] doko: how does bug 362691 look to you? [08:09] Launchpad bug 362691 in xen-3.3 "XEN depends on Python 2.5" [Medium,Triaged] https://launchpad.net/bugs/362691 [08:09] but i'm running x86 intrepid and don't see lilo [08:11] hyperair: installed by desktop or alternate? [08:11] Hobbsee: desktop [08:11] strange [08:11] indeed. [08:12] pitti: hi! [08:12] hey robert_ancell, how are you? [08:12] had a good weekend? [08:13] 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] nice [08:13] Hobbsee: oh right, i installed using the hardy desktop cd, and then used update-manager to upgrade to intrepid. [08:14] hyperair: that would be why, then. [08:15] err... [08:15] superm1: mesa->SRU? [08:15] 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] cody-somerville, Does sysrq(alt+printscreen)+r print anything to the screen? [08:17] 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:17] Launchpad bug 286450 in xen-3.3 "libxen3 and libxen3-dev have bogus Replaces: versions" [Undecided,Triaged] https://launchpad.net/bugs/286450 [08:18] Jordan_U, the machine doesn't have keyboard or mouse [08:20] 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] I have crash in gdmsetup in ubuntu.. how do I install the debug symbols so I can give a useful backtrace? [09:10] lesshaste: Work out what package that's in (I'd guess 'gdm'), add the dbgsym repository (wiki.ubuntu.com/DebuggingHowto), and install gdm-dbgsym. === azeem_ is now known as azeem [09:10] Sorry. https://wiki.ubuntu.com/DebuggingProgramCrash/ [09:12] gdm-dbgsym doesn't exist [09:12] Have you added the dbgsym repository, and updated your package lists? [09:13] dholbach: looks fine [09:14] RAOF: I need main restricted universe multiverse right? [09:14] Well, only main for this, but there's no harm in including everything. [09:15] geofft: http://cdimage.ubuntu.com/netboot/intrepid/ isn't too bad as URLs go ... [09:16] cjwatson: ooh, thanks. So, uh, where's that documented? :) [09:16] geofft: *waves hands* [09:16] geofft: where would you like it to be documented? [09:17] cjwatson: preferably, as a result of google(ubuntu netboot). I guess in the text of the first result would work too [09:17] hm, and I guess I can edit that? [09:19] geofft: yup - if you just link to http://cdimage.ubuntu.com/netboot/, that has links for other releases [09:20] I should probably create a directory there for dapper [09:20] Installation/NetbootInstallFromInternet claims the kernel needs to be chmod +x. Is that actually true? [09:21] news to me if it is [09:21] slangasek: could you please give me a quick heads-up for bug 277589? (is that something for jaunty final?) [09:21] Launchpad bug 277589 in hotkey-setup "sony brighness on a geforce series older than 8 (nvclock works fine)" [Undecided,Fix released] https://launchpad.net/bugs/277589 [09:23] pitti: thanks for dovecot-postfix thing; i'll rewrite 'echo' part for karmic [09:25] geofft: ok, http://cdimage.ubuntu.com/netboot/ prettified a bit, and I've added dapper [09:26] RAOF: hm... I installed the debug symbols for gdm but... http://www.pastebin.ca/1397160 [09:26] :) [09:26] cjwatson: :( I don't like to be reminded that dapper still exists [09:26] I mean... :( [09:26] pitti, slangasek: hi, bug #363169 is a change for a sru I guess? [09:26] Launchpad bug 363169 in libxklavier "libxklavier is built without XInput support" [Low,Confirmed] https://launchpad.net/bugs/363169 [09:26] cjwatson: Ah! that's where I saw the orion5x! [09:26] http://cdimage.ubuntu.com/netboot/jaunty/ [09:26] RAOF: do I need some other debug symbols do you think? [09:27] lesshaste: Looks like you probably want... the glib, gtk, and gio dbgsyms. === evand1 is now known as evand [09:29] lool: ah yes. removed and added imx51. [09:30] Thanks [09:33] RAOF: ok :) Just finding the right debug package names is hard.apt-cache search dbgsym|grep gio returns nothing [09:33] 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] 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] 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] slangasek: right, that's what I figured as well, and why I asked for the hal debug output [09:35] so I wasn't completely stupid then [09:36] cjwatson: /netboot/jaunty/ says "alpha", but it looks like the RC now... [09:36] 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] slangasek: agreed; thanks [09:36] 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] pitti: hello ;-) [09:37] 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] bonjour seb128! [09:37] 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] geofft: fixed, thanks [09:38] slangasek, i uploaded the fix for irda-tilus for bug 340873 ... its not on the CD, please let it through [09:38] Launchpad bug 340873 in sane-backends "[Jaunty] modprobe requires .conf filenames now" [Medium,Fix released] https://launchpad.net/bugs/340873 [09:39] cjwatson, will there be a d-i upload before final ? [09:39] there already was one [09:39] oh, when ? [09:39] 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] Launchpad bug 353196 in linux "ixp4xx hwclock command stopped to work since beta release" [Medium,Invalid] https://launchpad.net/bugs/353196 [09:39] I am trying to complete this bug report http://bugzilla.gnome.org/show_bug.cgi?id=556458 [09:40] Gnome bug 556458 in gio "crash in IA__g_file_load_partial_contents_finish (with X forwarding or "su")" [Critical,New] [09:40] ogra: three days ago [09:40] ah [09:41] well, a workaround is described in the bug so i guess users will have to live with it [09:41] (unles we suddenly SRU d-i :) ) [09:43] ogra: er, what component of d-i creates /etc/modprobe.d/local? [09:44] "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] likely, yes [09:44] 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] RAOF: well.. :) That was awkward.. [09:45] lesshaste: ? [09:45] turns out I needed to install gvfs-dbgsym and libglib2.0-0-dbg [09:45] 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] hooray for uniform naming schemes :) [09:46] but i need to take a look [09:46] (he says sarcastically) [09:47] 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] Not very useful now, though. [09:47] RAOF: that's what I did for each one in the end more or less [09:48] lesshaste: you have binary-dbgsym for everything which is a consistant naming [09:48] lesshaste: the -dbg are usually coming from debian which doesn't have -dbgsym for everything and add those randomly [09:48] 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] seb128: libglib2.0-0-dbg was the odd one out [09:49] ogra: which is good, it means you have a better chance of getting a fix in [09:49] lesshaste: you have libglib2.0-0-dbgsym too [09:49] lesshaste: libglib2.0-0-dbg is coming from debian as said before [09:49] slangasek, well, the cmdline gets created by d-i during the apex image building [09:49] IIRC, Debian might be getting a -dbgsym equivalent from this year's GSoC. [09:49] seb128: I don't have libglib2.0-0-dbgsym on my system.. are you sure it exists? [09:50] ogra: what's an apex image? [09:50] seb128: a little script that finds the debug packages from the gdb output would be lovely :) [09:50] ogra: actually, no - this particular command-line argument comes from the apex package [09:50] ./src/mach-ixp42x/debian-nslu2-armeb_config:148:CONFIG_ENV_DEFAULT_CMDLINE="console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug" [09:50] ./src/mach-ixp42x/debian-nslu2-armeb_config:150:CONFIG_ENV_DEFAULT_CMDLINE_ALT="console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug" [09:50] ./src/mach-ixp42x/debian-nslu2-arm_config:148:CONFIG_ENV_DEFAULT_CMDLINE="console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug" [09:50] ./src/mach-ixp42x/debian-nslu2-arm_config:150:CONFIG_ENV_DEFAULT_CMDLINE_ALT="console=ttyS0,115200 rtc-x1205.probe=0,0x6f noirqdebug" [09:50] lesshaste: yes, do you have a ddebs.ubuntu.com source? [09:50] (took me a while to track it down) [09:50] lesshaste: use apport, apport-retrace install all the dbgsym required to get a debug stacktrace [09:50] ah, i was looking at the wrong place [09:50] 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] ...build/config/armel/ixp4xx/netboot.cfg [09:51] reassigned the bug [09:51] seb128: I don't think I have a ddebs.ubuntu.com source.. let me check [09:51] deb http://ddebs.ubuntu.com hardy-updates main restricted universe multiverse [09:51] deb http://ddebs.ubuntu.com hardy-security main restricted universe multiverse [09:51] that's all I got [09:51] lesshaste: that would be your issue though [09:51] lesshaste: you should add the same some for hardy if you use hardy, right now you have ddebs only for updates [09:52] apport does nothing for me [09:52] that let me to try to run gdmsetup.. which crashes :) [09:52] that led.. [09:52] did you enable it? [09:52] slangasek: in order to fix this for jaunty, yes [09:52] it's not enabled by default on stable [09:52] seb128: fixing sources... [09:52] cjwatson: I'd argue for release notes then [09:52] ogra: ^^ [09:53] slangasek, yes, the fix isnt to hard [09:53] no idea how this could have broken since beta though [09:53] I'm looking at apex source from December, and the option is there [09:53] though we should SRU apex to not make it reappear [09:53] cjwatson, it didnt show any issues before [09:53] seb128: do I need one sources line for hardy and one for updates and one for security? [09:54] ogra: yes, I read that in the bug; that doesn't mean I understand why [09:54] lesshaste: right [09:54] cjwatson, me neither [09:56] 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] cjwatson, the apex source doesnt contain the modprobe.d file though [09:56] (or better yet, move the existing file to the new name...) [09:56] slangasek, so a simple mv ? [09:57] 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] ogra: guarded by appropriate version checks [09:57] slangasek, note that the file isnt shipped by the package, its always been created in the postinst [09:57] yep [09:57] it's still a config file by virtue of being in /etc [09:57] lesshaste: what about reading the documentation? [09:58] so you don't get to twiddle it indiscriminately [09:58] tseliot: can you please have a look at #363500 and eyeball the nvidia-common diff [09:58] lesshaste: https://wiki.ubuntu.com/DebuggingProgramCrash for example [09:58] mvo: sure, let me have a look at it [09:58] slangasek: is bug #363500 something we can consider for -final or rather a sru ? [09:59] seb128: :) always a smart move... I have been looking for something that looks definitive without much l [09:59] seb128: uck... that page doesn't have anything about source packages does it? [09:59] lesshaste: why do you need sources now? I though you wanted debug variants [10:00] 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] seb128: sorry I have clearly misunderstood. lesshaste: yes, do you have a ddebs.ubuntu.com source? [10:00] seb128: that just means the standard lines like deb http://ddebs.ubuntu.com hardy main restricted universe multiverse ? [10:00] ogra: (specifically, the source package that does what it's told here is debian-installer-utils) [10:00] ah [10:01] seb128: in sources.list and not the src version of those lines? [10:01] well, i guess there is no value in fixing d-i-utils now, but i'll prepare an apex SRU [10:01] mvo: hmm; requires rebuilding all ISOs; let me have a closer look [10:01] lesshaste: I don't understand the question [10:02] lesshaste: those dbgsym are debug for the normal jaunty binaries, their is no specific sources [10:02] Why does dash use stat() instead of access() for [ -r foo ]? [10:02] seb128: I thought you were telling me how to find libglib2.0-0-dbgsym [10:02] 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] lesshaste: ok, I've discussed that enough, what about you read the wikipage? [10:03] slangasek: it breaks all partial upgrades in u-m, but those should rare on stable and we can easily SRU nvidia-common [10:03] 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] ogra: I repeat, no fix is needed in debian-installer-utils [10:03] 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] ogra: it is *just doing what it's told* by the kernel command-line arguments [10:03] is this a legit bug in dash? [10:03] 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] slangasek: thanks, much appreciated. I will wait for tseliot to have a second look and then upload [10:03] seb128: that the talk of source was just to confuse me :) [10:03] cjwatson, oh, ok [10:04] seb128: thanks for your help [10:04] you're welcome [10:04] mvo: don't wait too long, please [10:04] i wasnt aware it was that clever :) [10:04] bug report now updated [10:04] slangasek: sure, some minutes only, I tested it already here locally and it works fine [10:05] slangasek, i assume you dont want uploads for SRUs in the queue yet ? [10:05] 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] it is [10:06] I've uploaded some already [10:06] ok, great :) [10:06] (in case anything enfoces a d-i rebuild having the fixed apex hand might help) [10:06] there's no reason we would rebuild d-i in SRU [10:07] Excuse me, what is the state of grub2, is it ready for a production machine?Will it be included in 9.10? [10:07] so if that's what you're planning to SRU, I don't think you should bother [10:07] i mean before release indeed [10:07] now I look at the bug report it starts [10:07] 5253 /build/buildd/glib2.0-2.16.6/gio/gfile.c: No such file or directory. [10:07] in /build/buildd/glib2.0-2.16.6/gio/gfile.c [10:07] slangasek: (we do rebuild d-i in SRUs for kernel updates ...) [10:07] which is a little mysterious [10:07] cjwatson: hmm, really? [10:07] slangasek: especially ABI changers [10:08] well, ok [10:08] there's a debian-installer upload on http://people.ubuntu.com/~ubuntu-archive/pending-sru.html right now, in fact [10:08] 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] mvo: please proceed with the upload [10:09] ogra: no - that only affects one build on one architecture, so that's trivial to accomodate, please upload [10:09] ogra: my concern there is that we could easily end up shipping binaries that don't match the source we provide [10:09] if we do that, I think we should commit to rebuilding d-i :-/ [10:09] anyone know if there is a gnome devel channel around? [10:09] ah [10:09] cjwatson, yes, that was the reason why i asked [10:09] lesshaste: that means you don't have the glib source on disk so it can't match the codeline to some source [10:09] apex bits are copied into the image? === mkorn is now known as thekorn [10:09] slangasek: via a twisty path, but yes [10:09] slangasek, yes, its the part of the netinstall that boots the device [10:09] ok [10:10] then yeah, we ought either do them both in final, or both in SRU [10:10] (and my preference is SRU) [10:10] ok, so i'll keep that back [10:10] a release note for this is reasonably straightforward to write, isn't it? I mean, users have a feasible workaround? [10:10] yes [10:10] seb128: thanks.. I am slowly learning how to do this stuff... [10:11] 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] i just dont want to lose out if there is a d-i rebuild and i'm afk [10:11] ogra: then I recommend uploading apex to jaunty-proposed as if it were an SRU [10:11] ok [10:11] 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] goo [10:13] d [10:15] 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] lesshaste: [10:15] gdb software [10:15] (gdb) break g_log [10:15] (gdb) run [10:16]