[00:29] Keybuk, last night my testing showed some improvement on ureadahead after the defrag, but still not as good as I think it should be... today I've been working on an idea that I think could punch it up another level... right now it calls readahead() on each file, but this stalls on indirect blocks, and can't be done on the directories, which is where the open() loop waits a lot [00:30] Keybuk, so what if instead when generating the pack file, we first, add the directories on the paths to the files to the list of files, then translate the block addresses to absolute block addresses, use e2fslibs to look up any indirect blocks and add them tot he list, then merge the list into a series of extents of raw block addresses [00:30] then readahead() that list on the raw block device === dendro-afk is now known as dendrobates === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [00:34] in theory that could result in a single massive read === sconklin is now known as sconklin-gone [01:12] ScottK: you're captain backports, aren't you? [01:22] hggdh, you there ? [01:47] Caesar: I'm involved in them. [01:48] hm, LP doesn't like my src-format-3 package.. [01:48] dpkg-source: info: applying networkmanager.patch [01:48] 1 out of 8 hunks FAILED -- saving rejects to file [01:48] policy/modules/services/networkmanager.te.rej] [01:48] this doesn't happen for me locally... [01:51] smoser: I am here [01:57] psusi: no idea, try it :-) [01:57] YokoZar: hello? [01:58] Keybuk: There was some discussion in #ubuntu-motu earlier about using invoke-rc.d procps start || true instead of start procps || true in postinst scripts [01:58] YokoZar: since procps is an Upstart job, that would be wrong [01:59] Keybuk: Well let me link to you what lool said: https://bugs.launchpad.net/ubuntu/+source/wine/+bug/447197/comments/52 [01:59] Ubuntu bug 447197 in wine1.2 "Packages with custom /etc/sysctl.d/30-foo.conf files can fail to install: start procps returns exit status 1" [Undecided,Fix released] [01:59] YokoZar: the "|| true" will fix that. [02:00] kees: the || true fixed that in the bug report, yes, but we're talking about the first part (start procps vs invoke-rc.d procps start) [02:00] YokoZar: it must be "start". [02:01] YokoZar: using invoke-rc.d for an upstart job is wrong. [02:01] lool is wrong [02:01] any new code should be written to use the native Upstart interfaces [02:01] the /etc/init.d/procps symlink is only there to teach humans to use the new interface [02:01] Keybuk: kees: what about policy-rc.d ? [02:02] using that for Upstart jobs is also wrong [02:02] anything *-rc.d is wrong for Upstart [02:02] those are sysvinit tools [02:03] So people who have made one should migrate configuration to upstart? Does upstart cover everything in 10.04 now? [02:03] no, not yet [02:04] So how do we handle the mixed case then? [02:04] we are migrating from one system to another [02:04] YokoZar: procps moved to upstart, therefore it should use "start" instead of the *-rc.d commands [02:04] things migrated to the new system should use the new interfaces [02:04] ok that makes sense [02:04] otherwise what is the point of spending years writing a new init system if everyone carries on pretending it's still the old one?! [02:05] is KDE4 going to spend another year writing an init system abstraction layer wrapper? [02:05] *ducks* [02:06] KDE4 will probably write an abstraction layer to an init system abstraction layer [02:06] :) [02:06] in case they want to change init system abstraction layers later on [02:06] I can totally see that happening though :) [02:06] Keybuk: well one option is to keep using the old one as compatibility until everything is in upstart and then deprecate it [02:07] YokoZar: if we do that, we'll have a great big flag day [02:07] and realise that the Upstart interface isn't up to the job [02:07] Yeah [02:07] on a slightly related note, what's the purpose of the "service" command [02:07] red hat compatibility I think [02:07] YokoZar: so now we'll have wine back in the archive? did you test all the conffile transitions? [02:07] jdong: compatibility with RHEL [02:07] Keybuk: ah. so we're not supposed to use it as the replacement for invoke-rc.d [02:08] * Keybuk wonders whether the RHEL 6 "service" command knows about Upstart [02:08] jdong: no [02:08] *nods* [02:08] kees: Yes that was working before it disappeared from the archive (it's the same as the wine1.2 code too) [02:08] kees: actually technically it didn't disappear so much as have source but no binary [02:09] YokoZar: okay. I guess it's okay to have two binary packages fiddling with the same debconf value. [02:09] YokoZar: Upstart is still being developed [02:09] kees: two conflicting binary packages at that [02:09] and I want it to not just be "good enough" but *perfect* [02:09] so the whole point of using its interfaces now is to discover where they're not good enough, let along not perfect [02:09] something to do with eating dog food ;) [02:09] That's fair [02:09] YokoZar: oh! they conflict? excellent, that makes me worry much less. [02:11] kees: btw, when is Ubuntu planning to issue a patch for that fun reiserfs xattr root exploit? [02:11] +CONFIG_FS_REISERFS=y [02:11] -CONFIG_FS_REISERFS=n [02:11] hahaha :) [02:11] Keybuk: This whole discussion tells me we need to document this somewhere official-sounding, preferably debian-inclusive (policy manual?) [02:11] I was under the impression the point of the service command was to run init scripts under a consistent environment, i.e. with / as the pwd and no crap in environment variables, in case the scripts/daemons are written poorly and shit themselves in the wrong environment. And they are, and they do. [02:12] YokoZar: feel free to include it in the Ubuntu policy manual [02:12] ion: it doesn't really do that though, does it? [02:12] Keybuk: if I do that will you write a lintian test that complains about rc.d? [02:13] YokoZar: no, lintian is written in a programming language I do not write [02:13] jdong: it's in progress; I'm waiting on the kernel team for an update. http://people.canonical.com/~ubuntu-security/cve/2010/CVE-2010-1146.html [02:13] The Linux kernel 2.6.33.2 and earlier, when a ReiserFS filesystem exists, does not restrict read or write access to the .reiserfs_priv directory, which allows local users to gain privileges by modifying (1) extended attributes or (2) ACLs, as demonstrated by deleting a file under .reiserfs_priv/xattrs/. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1146) [02:13] keybuk: It does cd / and env -i ... [02:14] ion: that's nowhere near a "sane environment" [02:14] kees: ah, cool. We don't mount -o user_xattr by default if a user installs onto reiserfs... right? *cringe* [02:14] ion: e.g. where's the code to reset the process mark and clear pending signals currently masked? [02:14] jdong: no, user_xattr is highly non-default [02:14] kees: ok, *whew*, that's at least... better :) [02:14] mark? mask! [02:14] keybuk: I never said sane. ;-) [02:14] kees: while I have your ear can I talk about cautious-launcher? [02:14] YokoZar: sure thing [02:15] kees: If I remember our UDS discussions, it's supposed to permit removable media (CDs, sticks) correct? Is this handled through the gvfs mount options? [02:16] jdong: that's a rather special bug there for reiserfs :) [02:16] in fact [02:16] I'm going to be mean [02:16] YokoZar: it follows the filesystem markings, so if an external device has been mounted without execute, that's a bug with the mounting process. [02:16] ajmitch: oh it's a really fun one. (1) make your own biinary, (2) mark it suid root, (3) profit! [02:16] I'm going to add code to initctl to refuse to run if called from invoke-rc.d ;-) [02:16] ajmitch: let's hope there's no hapless reiserfs+beagle users that decided to mount -o user_xattr ;-) [02:17] Keybuk: please don't do that for lucid. [02:17] first upload to maverick will be upstart with that change? [02:17] agree 100% with kees here ;) [02:17] kees: no, not for lucid [02:17] for maverick [02:17] If you do that we don't need the lintian test since the package will fail to install [02:17] I wonder how many universe packages would need to be updated for that [02:17] ajmitch: I'm guessing it's on the order of 10 [02:18] YokoZar: all ones you've been touching? [02:18] Keybuk: maverick, yes, +1. :) [02:18] ajmitch: I've touched about 3 so far, and they're all "weird" compared with most universe stuff. Init script stuff seems like something main packages are far more likely to deal with [02:19] having lots of nice intentioanl breakage is what maverick's all about, isn't it? [02:20] ajmitch: can't we just rely on a pulseaudio upload to do that? [02:20] Maverick will take the "light" theme to a new level by continually increasing the gamma correction as you use the computer [02:20] YokoZar: and maybe it'll finally be completely impossible to tell which window is in the foreground! [02:20] jdong: it isn't yet? [02:20] ajmitch: it's pretty close to. [02:20] but if you sit around scratching your head and alt-tabbing a few times, you'll eventually figure it out [02:21] or realize it's time for an eye exam [02:21] There will be an innovative solution to that using the empty upper right of the window jdong [02:22] jdong: it will say "I am your window, use me!" [02:22] or the active window title will have [02:22] huh? [02:22] it's easy to tell which one is active [02:22] YokoZar: awesome! Now I can click the magical orb thing when I mean to close the window. [02:22] Keybuk: well maybe Santa needs to buy me an IPS panel but they look like very similar shades of cream to me. [02:22] jdong: I tell by whether the window controls are lit [02:23] I'm going to be at UDS using the Human theme and feel like a total curmudgeon it's gonna be fantastic [02:23] Keybuk: oh I guess that works if I retrain myself to take my cue from there. [02:23] YokoZar: or you could install that scary fvwm95 [02:23] that screenshot just looked ugly on planet [02:23] but I've likekd the ability to just look at the center of the bar where the title is. [02:24] More likely is you were looking at color unless you were using the dark theme [02:24] * ajmitch was using clearlooks with its glorious blue [02:43] ScottK: I'd like to get the latest upstream rsyslog 4.6 into lucid-backports and hardy-backports [02:43] I'll do the legwork [02:50] Caesar: First it needs to be in Maverick. We only backport from later Ubuntu releases. [02:50] But it'll need testing in any case, that can start now. === andrewks_ is now known as andrewks === dendrobates is now known as dendro-afk [04:30] * ccheney sees Jono's post and wonders if he can manage to install his first Linux distro in vmware still [04:31] * ccheney has no idea what it even looked like anymore [04:33] * ccheney isn't sure if ide cdrom even existed back then [04:49] seems even older than bootable cds [04:51] psusi: haha http://jdong.mit.edu/~jdong/fragraph.svg [04:51] psusi: whenever your defragger is ready to have a UI ;-) [04:51] psusi: (we hacked a quick graphing library to output those cliche Windows defragger ring-block graphs) [04:52] yuck installing this in vmware will actually be harder than installing it originally 15+ years ago [04:54] jdong, hrm... I've been wanting a graph like that of the ureadahead pack file lately ;) [04:54] jdong, though defrag already has a super sexy ncurses ascii gui, hehehe [04:54] whee, got the Slackware 2.1.0 bootloader to show up :) [04:55] psusi: haha some perverse part of me wants to quickly hack together a script that visualizes what my current disk looks like. [04:56] jdong, :) [05:28] hmm virtualbox doesn't support old enough either, qemu might be but its only back to ppro [05:46] is there a magical pulseaudio way of redirecting audio output to microphone input? [05:46] i.e. if you're voiceconferencing with someone and want to play a bit of music? [05:47] Yes, but. [05:48] So, pulse operates on the idea of sources and sinks, and you can connect any arbitrary source to any arbitrary sink, at any arbitrary gain, and it does the right thing. [05:48] But this complexity is painfully comfusing to users, so there's no UI for doing it. [05:49] If you're crafty, you can do things with pacat and named pipes. There might be a less baroque way to do it. The API is fairly powerful. [05:50] But you probably don't want to redirect to microphone input anyway (as sending to a source doesn't make sense), but rather to the audio sink for your application. [05:51] right, I guess I meant audio sink for application [05:51] I'll look at pacat then [05:51] If you have a sound file, `pacat -d ${SINK}` should work, assuming you know the sink identifier. [05:52] where can i get the sink identifier? [05:52] If you need to redirect the output of one program into the input of another, that's harder. [05:52] Extra points for a nifty routing tool for complex routing maps that everyone can use :) [05:52] * persia doesn't know pulse well enough to know [05:53] yeah, I'd love to learn more pulse tricks as well [05:59] I think pulse allows you to record what you hear out your speakers, i.e it will directly monitor the output sink. [06:00] That's pamon, isn't it? [06:00] Not sure what paman has to do with it, I have seen the option I talked about in pavucontrol. [06:00] pamon even [06:01] I thought pamon was PulseAudioMonitor [06:01] I may be wrong. [06:01] never used it personally, and I thought it was deprecated. [06:02] You're probably more up-to-date than I. [06:03] The only feature that doesn't "just work" for me is the ability to automatically route different applications to different audio interfaces. I'd like something like patchage for those special times I want to do something fancy, but for now all my fancy stuff can be done with alternate applications. [07:07] Anyone have a PS3? I worry that https://launchpad.net/ubuntu/+source/ps3-kboot/1.6-2build1/+build/1517259 might make it hard to support any issues with PS3 for lucid. Perhaps not as hard as the recent firmware update, but ... [07:12] Has the memory leak problem been solved? [07:24] directhex: right, I checked before that the package was in depwait, so it should have built by now [07:24] good morning [07:25] pitti, it has indeed! [07:25] jdong: SRU versioning> I don't have a strong preference either way; 0.1 style is safer for avoiding future conflicts, but then again we'll just copy lucid-proposed SRUs to maverick, so for those cases it doesn't matter [07:25] And it fixes the bug [07:25] Depends: banshee (>= 1.6.0), banshee-extensions-common (= 1.6.0-1ubuntu4), libappindicator0.0-cil (>= 0.0.19), libglib2.0-cil (>= 2.12.9), libgtk2.0-cil (>= 2.12.9), libmono-addins0.2-cil (>= 0.4), libmono-corlib2.0-cil (>= 1.2.2.1), libnotify0.4-cil (>= 0.4.0~r2998) [07:25] deps! sweet sweet deps! [07:25] just like momma used to make! [07:26] :-) [07:26] * pitti puts some ice cream on top [07:28] cdbs is incredibly poor at dealing with library packages containing both arch and indep pieces, if left to its own devices. the trick is binary-predeb/someindeppackage:: binary-fixup/archpackageitneeds [07:42] slangasek, pitti: uploading final langpacks. [07:53] good morning [07:55] ArneGoetje: thanks, I'll shepherd them through the queue [07:58] apw: linux-headers-2.6.32-21-versatile wants to go back to universe, but I think it would be much easier to have it in main, so that all linux binaries are in main; WDYT? [08:00] apw: it just seems that this should be depended on by some metapackage? [08:07] pitti: Why should it be in main? It's only useful for folks running qemu against armel targets, and isn't used for any images or in any flavours. [08:08] And the armel board it supports fails to match any of the boards for which there are images. [08:08] persia: the source is in main, so that binary might just as well be [08:08] There's a substantial list of packages where source is in main and binary is in universe. [08:09] persia: the entirely selfish concern is that it's about 20 times easier to NEW a package which has all binaries in the same component :) [08:09] and due to changing the ABI very often, NEWing happens frequently in stable updates [08:09] Oh, then stick it in the "supported" seed (or whatever it's called). You guys have to NEW linux *far* too often to fiddle about with it. [08:09] that was my idea, but I was interested in (1) why it doesn't have a metapackage, and (2) whether there are particular reasons why we don't even want to show it in main [08:10] Because archive-admin-convenience is the only decent reason to have that kernel in main, but that's indeed a decent reason. [08:10] It's useless for nearly everyone. [08:10] It works fine, but it's not tested heavily or anything. [08:10] ok, so that explains the lack of an rdepends; thanks [08:10] And I think mostly lool supports it/. [08:11] good morning [08:11] persia: I'm a bit hesitant to seed it, though, again because the ABI changes so often [08:11] hey dholbach! *hug* [08:11] hey pitti [08:11] * dholbach hugs pitti back [08:11] persia: (but there's a trick to catch all binaries of a source, so that's not a big problem) [08:12] Use the trick. A new linux-meta upload to create an rdepends would be annoying :) [08:13] if an archive admin could have a look at bug 567208 I'd appreciate it [08:13] Launchpad bug 567208 in freebsd-buildutils "Please sync freebsd-buildutils 7.2-2 from sid" [Undecided,Triaged] https://launchpad.net/bugs/567208 [08:13] it wouldn't surprise me if all the tools are currently broken in that package [08:19] apw, persia: seed change committed, thanks [08:32] pitti, are you saying that the linux-headers for versatile are not depended on by a meta package? [08:33] apw: right; persia gave some clarification about that above [08:34] pitti, i am a little supprised, i thought i was linked to linux-meta [08:35] pitti, yeah there is a linux-headers-versatile package built by linux-meta ? would that not be the link we are expecting? [08:35] indeed [08:36] Depends: linux-headers-2.6.32-21-versatile [08:36] Depends: linux-headers-2.6.28-18-versatile [08:36] and it does have a dep of the form i was expecting [08:36] oh, I see -- linux-headers-versatile itself is in universe [08:37] so would the thing to be to promote that? [08:37] I don't know [08:37] where is linux-image-versatile ? [08:38] * pitti looks a little confused and points archivewards? [08:38] htm thats is universe too, i wonder why you don't have the same issue with the linux-image [08:39] jdstrand: no, not everything in main is in a seed file; many things are in main as /dependencies/ of things in seeds [08:39] jdstrand: but I see that was already answered :) [08:39] apw: no, linux-image-2.6.32-21-versatile is in main [08:40] indeed, but the metapackage is universe [08:40] ArneGoetje: yay langpacks [08:40] stranger and stranger [08:40] apw: so I guess for any kind of consistency we should either seed linux-{image,headers}-versatile, or drop the entire thing to universe? [08:40] and go back to this kernel-overrides script [08:41] persia: ^ [08:41] pitti, i have often wondered whether the package could supply the defaults ... so once you are happy they are right in the package you can just say 'do what the package says' [08:42] apw: they can: Section: restricted/linux [08:42] or universe, etc. [08:43] so is that the error, that we are not and we should be [08:43] at least they could in the past; not sure if these days soyuz tries to be more clever [08:43] if there is something i can do to make this work without lots of pain [08:43] even if its just so that your script doesn't need a list, just can take the contents of those fields in the packages [08:43] apw: for now I'm primarily interested in where versatile should be; right now it's half-main/universe [08:43] * persia doesn't like the idea of components, but doesn't think there are enough versatile users to justify being in "main" as long as we have them, but prefers to make archive-admins lives easy, making main a reasonable choice. [08:44] apw: we have a "kernel-overrides" script which copies the sections from a previous ABI [08:44] so once we get it right in final, we can just use that for SRUs [08:44] ahh right [08:44] persia: the thing that I'm puzzled about is why linux-image-2.6.32-21-versatile is in main without http://people.canonical.com/~ubuntu-archive/component-mismatches.txt complaining [08:45] (note that versatile just went away due to my explicit seeding) [08:45] * persia tries to find a reason [08:45] but that seeding is still inconsistent [08:46] we have linux-{image,headers}-2.6.32-21-versatile in main, and linux-{image,headers}-versatile metapacakges in universe now [08:46] ooh [08:46] ./platform.lucid/installer: * Kernel-Version: 2.6.31-607-imx51 2.6.32-204-dove 2.6.33-500-omap 2.6.31-800-st1-5 2.6.32-21-iop32x 2.6.32-21-ixp4xx 2.6.32-21-orion5x 2.6.32-21-versatile [08:46] persia: ^ got it [08:46] Right. netboot images. [08:46] heh was just going suggest netboot [08:47] persia, apw: so with that I suggest to just seed the versatile metapackages, too; ok? [08:47] So if that's going to happen anyway, may as well toss the linux-meta versatile stuff in supported to avoid archive-admin work. [08:47] pitti, yeah seems reasonable they should be in the same place to me [08:48] They may have a 2-digit userbase, but it's simply not worth the extra archive-admin work to have them in universe. [08:48] good morning ladies & gentlemen [08:48] persia: it's not that big of a deal, but kernel in main and metapackage in universe doesn't make sense [08:49] ogra: what makes bug #568736 "higH"? [08:49] Launchpad bug 568736 in netbook-meta "Having Evolution installed along with Desktop-Email is pointlessly redundant" [High,Triaged] https://launchpad.net/bugs/568736 [08:50] slangasek, waste of space and ram ? [08:50] asac: Maybe you can help out slangasek there? [08:50] persia: hey, that's one digit more than hppa! *duck* [08:50] slangasek, along with the duplication of apps [08:50] ogra: yeah, I'm not letting you make a seed change a week before release for that [08:50] slangasek, SRU ok ? [08:51] pitti: Right: the only reason we care more about versatile than hppa is that there's like 4 devices anyone can buy that can actually run Ubuntu armel. [08:51] ScottK, Riddell: should kigo just drop the gnugo recommends at this point? [08:51] ogra: SRU is pointless, because it doesn't change images. [08:51] persia, hmm, and u-m wouldnt uninstall the package anyway [08:52] Right. [08:52] right [08:52] So it ought be wontfixed for lucid and opened for maverick. Unfortunately, the UI doesn't actually support that. [09:13] pitti: linux-versatile > we could add it to supported-kernel [09:14] pitti: Just like kexec, it's used in some use cases [09:14] pitti: versatile being mostly for qemu [09:14] lool: ok, thanks; I seeded the metapackages now [09:20] Keybuk, YokoZar, kees: When I uploaded my last qemu-kvm uploads, slangasek noticed the use of "start procps" in the maintainer scripts and requested that I use invoke-rc.d instead to be nicer to the chroot use case (policy-rc.d I assume); he referred to a discussion which had just taken place on #ubuntu-devel; I think we need to have a public discussion on the pros and cons of each approach in the short term, and how to address the concerns in ... [09:20] ... upstart on the long term; there is a bug about chroots support in upstart covering the issues as well; let's move this to ubuntu-devel@ [09:39] asac: HAPPY BIRTHDAY! :) [09:39] YokoZar: contrary to Keybuk's statements, start/stop do not provide a sane interface for use in maintainer scripts (and I believe he knows well what's not sane about this interface, he and I have talked about the problems before and he's said he plans to fix them). It's fine that Keybuk wants to get rid of invoke-rc.d, but there needs to be a robust and publically-vetted interface, with sane error handling, available *first* before mand [09:39] ... people *not* use the thing that actually works. [09:40] slangasek: All right then, I'll leave the invoke-rc.d using packages there ;) === almaisan-away is now known as al-maisan [09:42] dholbach: \o/ [09:43] asac: happy birthday from me too \o/ :D [09:44] alll this public mentioning of a day ;) [09:46] Happy birthday asac! [09:46] asac: happy birthday, man! [09:46] * pitti hugs asac [09:46] man ;) [09:46] * asac hugs all [09:46] * sebner thinks about sending a mail to -ubuntu-devel about asac *hrhrhr* [10:22] * cjwatson scratches head over sbeattie's d-i resizing bug [10:23] AFAICT, tune2fs is just lying [10:24] lol [10:25] cjwatson: I still have that vm up if you want me to grab any more diagnostic info from it. [10:26] it's saying block count 2497791, block size 4096. that's about 10GB - on a partition around 250MB long [10:27] sbeattie: currently trying to work out what I would need, and if I can reproduce it locally instead [10:30] cjwatson: well, tune2fs isn't lying; I just tried manually mounting the partition and the kernel wouldn't mount it, saying the same thing (the block count exceeds the size of the device) [10:31] oh! [10:31] so the fs there is bogus? do you know why? [10:31] if it's genuinely bogus, I can certainly make d-i safe against that [10:31] I just didn't want to do so when the effect would be hiding some other problem [10:32] cjwatson: I don't know why it's bogus. [10:32] pitti: hmm, if gnugo isn't installed kigo just complains that it needs to be installed [10:33] would you agree that it would be best to just guard against this, and otherwise write the underlying problem off as probably transient until reproduced? [10:33] or is the bogus fs reproducible by some sequence of installation steps? [10:33] Riddell: well, we need a MIR or a lowering of the dependency [10:34] Riddell: do you have kigo on the CDs? (gnugo is 1.7 MB) [10:34] pitti: no it's not on the CD [10:34] pitti: let me look into gnugo and see if it's an easy MIR [10:35] cjwatson: writing it off as a transient is fine by me; I don't recall how I got it into this state. [10:40] so then I'll just error out if the size reported by ntfsresize or tune2fs is outside [minsize, cursize] as per the partition constraints [10:40] which would result in that partition just not being resizable, which I think is the correct response here [10:43] cjwatson: that seems sensible. Thanks. [10:57] sbeattie: are you still awake enough to be able to do a test run with a candidate patch for me? [10:58] cjwatson: yes [10:59] sbeattie: so, there are two patches here; I need you to apply http://paste.ubuntu.com/420942/ to /lib/partman/lib/resize.sh, and http://paste.ubuntu.com/420943/ to /lib/partman/automatically_partition/10resize_use_free/choices [10:59] sbeattie: if you like, you can apt-get source partman-partitioning and partman-auto respectively, apply the patch there, and then scp in the result - that's probably quicker than typing it in by hand [10:59] sbeattie: I'd like you to keep the 'set -x' at the top of /lib/partman/lib/resize.sh to speed debugging of further problems, too [11:00] again, best to do all of this while it's sat at the hostname prompt [11:03] cjwatson: sure thing, give me a few minutes. [11:04] sbeattie: np, thanks [11:04] * ogra wonders what we need to make a PAS change take effect ... apparently libx86 was added to PAS for armel but i still see it on http://qa.ubuntuwire.org/ftbfs/ [11:06] ogra: The only thing that clears that is a working build: it's based on the build records from LP. A P-a-s change would make it not build for maverick. [11:06] ah [11:06] i guess an upload/sync/merge would clear it up too, right ? [11:07] well, i'll live with the uglyness on the list then [11:07] ogra: An upload might. I'm not sure. === al-maisan is now known as almaisan-away [11:09] ogra: But I doubt the RMs would accept an upload just to make the FTBFS list look pretty :) [11:09] (actually fixing a FTBFS is another thing) [11:10] you really think so ? :P [11:10] * ogra wasnt planning any upload indeed :) [11:11] i just wanted to know why i still see it on the list ... the explanation was good enough [11:11] it bites my eyes that we still have one red bar ... even though its moot [11:12] its just the german in me :) [11:13] One? [11:13] There's *lots* of red on that page. [11:33] ArneGoetje: I find a certain irony that Hungarian users need the hunspell dictionaries symlinked into the myspell directory === MacSlow is now known as MacSlow|lunch [11:35] cjwatson: okay, with those patches applied, I'm not getting offered the option to resize the partitions (which is probably correct). /var/log/syslog output at http://paste.ubuntu.com/420957/ and /var/log/partman at http://paste.ubuntu.com/420958/ [11:37] cjwatson: note that I have a snapshot of the vm's disk state taken when I initially ran in to this, so I can do destructive things to the image like mke2fs /dev/sda5 (which doesn't appear to currently be a valid partition) if you'd like me to exercise different conditions. [11:37] s/partition/fs/ [11:40] sbeattie: that's fine now - the shell trace is exactly as I'd expect [11:40] and I see it doesn't offer auto-resize because there isn't enough free space [11:40] /lib/partman/automatically_partition/10resize_use_free/choices: Found resizable partition '/var/lib/partman/devices/=dev=sda//5757730816-10462691327' (/dev/sda6), but not offering because only 2299432960 bytes free [11:41] sbeattie: so thanks, I think that's all! I'll go ahead and upload that, with just a correction to the ntfsresize-case error messages [11:43] cjwatson: okay, cool. [11:46] is there is standard way to access package dependancy information in a debian/rules context? [11:46] what sort of information? [11:46] i have a package with a dependancy on linux-source but i would like to know which package linux-source points to [11:47] apt-cache rdepends [11:47] or indeed the version number of linux-source [11:47] ah I misunderstood [11:47] and i can use apt-cache in deban/rules [11:47] what are you trying to do with this information? plug it into some other dependency? [11:47] cjwatson, the build rules need to know the name of the directory whihc will be in existance as a result of installing linux-source [11:47] anyway, Depends is run-time, you can't generally validly analyse it at build time [11:48] which depends on linux-source-2.6.NN and it needs the 2.6.NN information [11:48] sounds like it would need to depend on an explicit linux-source-2.6.NN anyway [11:48] because when linux-source changes to point to a new version, this package will need to be rebuilt [11:49] i was hoping to avoid that, but you are indeed correct [11:49] the other way to do it would require the package detecting things at run-time, rather than in debian/rules [11:49] yeah ... it would, and so this is a bust, thanks for the advice === jussi01 is now known as jussi [12:00] apw: any chance of us getting that kernel-lucid-kernel-config-review report to ubuntu-devel this week? :) [12:00] slangasek, yeah thats on my todo for today (though i has been for two weeks) [12:00] k [12:01] slangasek, i am leaning towards putting all of the configurations on my people page [12:01] and only including the i386 generic one [12:01] hmm [12:01] as to include them all there are about 8 [12:02] I dunno, seems to me that the "lvm support not built in on ports" bug is exactly the kind of thing that could have been caught by having more eyeballs directly on this stuff earlier [12:02] slangasek, well some actual testing of any of the ports kernels before release would have caught that [12:03] I did catch it a couple weeks ago. [12:03] (admittedly not early enough, but) [12:03] apw: only the users who were testing with LVM and knew to look for a kernel problem amid all the reports of mountall being broken [12:05] slangasek, though do you really think that anyone would read the all the ports configs and 1) detect that BLK_DEV_DM was not =y, and 2) realise the significance of that [12:05] apw: I would have looked over the differences in the configs, yes [12:06] slangasek, hrm i had not considered it would be possible to do that kind of comparison [12:06] would probably have taken a bit of work, but it was work I was intending to do :) [12:07] the problem to my eye is that the arch configs are all different so there is masses of delta which is expected and a small nuggest which is [12:07] 64543 101937 1440383 total [12:07] * slangasek nods [12:08] for all the normal and all the ports configs (ie only for master branch) you are talking about 1.4MB of configs [12:08] slangasek, would a delta from karmic make more sense? [12:09] apw: well, if you post them to your people page, that's better than nothing (i.e., better than me trying to dig them out of the git repo) - at least if they're *somewhere* that I can look at them without hunting them down, I can give a good think to the problem of generating meaningful diffs === almaisan-away is now known as al-maisan [12:09] a delta from karmic is probably also useful, but not to the exclusion of the other bit [12:10] slangasek, ok i can cirtainly do that, i'l see if i can get the karmic ones up as well [12:10] so there is a pair to compare that way too [12:10] great, thanks [12:10] and sorry its been on my list for too long really [12:10] for M we'll put an earlier task to get it out [12:10] if you could think about whats actually useful as a reviewer as well that would be great [12:11] will do [12:13] slangasek, one major thing we are doing now, is that when we have an option which has to be set is to record that and enforce it at build time so it is harder for it to become lost [12:14] * slangasek nods [12:14] slangasek, it would probabally make sense to publish these somewhere which is not 'apw', i think i will put them in the kernel-ppa user, which can then persist forever [12:14] ok [12:19] slangasek, is there a release meeting today? i don't see an agenda [12:19] apw: will have it out within the hour [12:20] (it was the agenda that reminded me of the outstanding WI ;) [12:20] yeah i'll get it out today [12:23] sigh, whats up with wiki.u.c ? [12:36] chrisccoulson: reviewing thunderbird - it's not clear to me why the thunderbird-gnome-support maint scripts have been removed without this moving elsewhere [12:37] slangasek - the maintainer scripts were just used to touch /usr/lib/thunderbird-3.0.4/.autoreg [12:37] which is not needed anymore [12:37] chrisccoulson: what's .autoreg for? [12:38] free: the current landscape-client SRU mentions bug 522688 which is for libvirt, and 503384 and 542215 are private; also, since there are two uploads stacked on each other, can you please fix the changelog and reupload one with -v1.4.4-0ubuntu0.9.04 (jaunty), respectively -v1.4.4-0ubuntu0.9.10 (karmic) so that the .changes will have both changelogs? [12:38] Launchpad bug 522688 in libvirt "/etc/init.d/libvirt-bin does not check that libvirtd has terminated on stop" [Undecided,Confirmed] https://launchpad.net/bugs/522688 [12:38] free: I'll sort out the task approval etc. now, and reject the two older uploads [12:38] free: oh, 567515 is private, too [12:38]