=== bluesmoke_ is now known as Amaranth === asac_ is now known as asac === ScriptRipper_ is now known as ScriptRipper === bluesmoke_ is now known as Amaranth [05:07] Is kvm known to be broken in Karmic with linux-image-2.6.30-X? [05:25] is mktemp going to be included in the new coreutils or something? [05:25] ah yes it is [05:26] either way all the PPA buildds are broken =( [05:28] So are the distro buildds [05:28] i can imagine. [05:33] That issue's been fixed upstream, right? When are we gonna see the fix hit the repos? [05:34] when one of the buildd admins has a chance to manually build the fixed coreutils package === bluesmoke_ is now known as Amaranth [06:06] Good morningt [06:06] Morning pitti [06:15] good morning [06:15] slangasek: for https://answers.edge.launchpad.net/launchpad-code/+question/72999, do you still need your lp:~vorlon/hal/lp.277589 branch? If not, would you mind deleting it? [06:15] hey dholbach [06:15] hiya pitti [06:17] eww, new coreutils removes essential package mktemp [06:17] which is most probably intended, but apt still doesn't like it [06:18] pitti: The fix is uploaded, but needs manual building... [06:18] wgrant: manual building? [06:19] dholbach: The buildds are broken because of this, so a buildd admin will need to manually build coreutils. [06:19] argh :-( [06:20] pitti: I guess it's been merged already, so deleting now [06:20] slangasek: yes, it is; unfortunately branches have to be set to "merged" manually [06:20] pitti: Not any more they don't. [06:21] But I suppose the target branch wasn't the development focus. [06:21] So it wouldn't have set it. [06:21] Because it wouldn't make sense. [06:23] I guess package branches will fix that. [06:31] tkamppeter_: https://bugs.freedesktop.org/show_bug.cgi?id=19777 -> good work! [06:31] Freedesktop bug 19777 in general "pdftops command line utility does not convert multiple-page-size documents correctly" [Normal,Resolved: fixed] === mcasadevall is now known as NCommander [07:30] tjaalton, bryce: I just filed bug 383837 against compiz, then I realized that it is most likely a regression in xorg-edgers mesa; should I still keep the bug in LP, or report it somewhere else? [07:30] Launchpad bug 383837 in mesa "crash on workspace change in intel_tex_validate.c:99 assertion" [Undecided,New] https://launchpad.net/bugs/383837 === thekorn_ is now known as thekorn [07:36] cjwatson: live system> you rock! boots fine in kvm here [08:50] . o O { gosh, my city is freaking out; and just because some American president is in town... } === MooKow is now known as LordKow [09:04] seb128: FYI, current retracer failure is due to mktemp failed dist-upgrade; let's just leave it until the archive gets fixed [09:05] pitti: the bug has been fixed in debian I was going to do a sync now [09:05] seb128: it's already synced, but it doesn't build [09:06] pitti: right, just noticed, let's wait for infinity or something to sort that then [09:07] can doko do it too? [09:07] dunno [09:47] All builds fail right now due to coreutils, being worked on | Archive: Open for development | Karmic alpha 1 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for [09:47] http://wiki.ubuntu.com/HelpingWithBugs [09:47] * Hobbsee hands pitti a /topic === pitti changed the topic of #ubuntu-devel to: All builds fail right now due to coreutils, being worked on | Archive: Open for development | Karmic alpha 1 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [09:47] Hobbsee: meh, thanks [09:47] :) [09:48] pitti: Do you want some more two-weeks-notice timezone change fun? === cjwatson_ is now known as cjwatson [09:54] pitti: live> yay [09:54] dholbach: no, he can't [09:54] cjwatson: gracias [09:54] wgrant: I just got poked about bug 383444, anything else? [09:54] Launchpad bug 383444 in tzdata "Timezone change for Bangladesh" [Undecided,New] https://launchpad.net/bugs/383444 [09:55] pitti: That's the one. [09:55] doing manual builds requires, basically, shutting down the buildds, constructing a faked-up chroot which will do what you want, poking that into the buildds, letting through the one package you want, and then setting the chroots back the way they were and restarting builds [09:55] the actual technical privileges required are in the intersection of ubuntu-archive and launchpad-buildd-admins, but in the general case you need direct shell access to the buildds too in order to construct proper chroots [09:56] in theory (e.g.) I could probably manage it, but I much prefer to leave it to Adam [09:58] cjwatson: infinity's on holiday till Tuesday [09:59] cjwatson: if this broken-distro rather than single-package-bootstrap, I'd better have someone else do it for you? [10:01] elmo: right now all builds fail due to it, and Alpha-2 is due on Thursday, so it would be great if it could be fixed before Tuesday [10:01] pitti: ok [10:01] elmo: many thanks! [10:20] elmo: oh, right - yes, please, thanks [10:21] hmmh, a question about old releases, I had /dev/scd0 in fstab from old install for cdrom - I guess this was added there by some older version of ubuntu? [10:22] I don't think I have added these myself, anyway there is a problem starting with jaunty with this [10:23] problem is that sound-juicer and some other CD applications process this line and fail to eject the cdrom, because now my /dev/cdrom symlink really points to /dev/sr0 [10:23] changing the device name to sr0 fixed the problem... [10:24] so, is ubuntu supposed to fix this line during upgrades? maybe I have re-indented it or something and broken the change in upgrade if it's supposed to be done... [10:31] update-manager probably ought to adjust it, but I didn't think the device name was meant to be sr0 [10:31] 50-udev-default.rules:SUBSYSTEM=="block", KERNEL=="sr[0-9]*", SYMLINK+="scd%n", GROUP="cdrom" [10:31] pitti: upstream would probably want to know about the bug [10:31] (so actually ignore my comment about update-manager, I typed that before checking the udev rules) [10:31] pitti: so, bugs.fd.o [10:32] I think you should investigate why /dev/scd0 is not present on your system. Have you changed udev rules? [10:32] tjaalton: good, will forward it there then; thanks [10:32] pitti: yep, thanks [10:33] or is it just that applications refuse to handle it if it doesn't match the /dev/cdrom symlink? in which case perhaps it is a bug in those applications [10:36] I have scd0, but /dev/cdrom points directly to /dev/sr0 [10:37] I was getting errors from gvfs regarding this, it was quite hard to track it the fstab :) [10:38] I'd venture to suggest that it's an application bug if they don't like that then [10:38] if it's the same device ... [10:38] basically gvfs was saying (without the device name) error 'this is not a volume' [10:38] linux/Documentation/devices.txt says "The prefix /dev/sr (instead of /dev/scd) has been deprecated." [10:38] so I don't think we should use it [10:39] but /dev/cdrom points to /dev/sr0 anyway [10:40] and yeah, nautilus and gnome-mount were happy to unmount /dev/cdrom, sound-juicer and brasero do not work [10:41] Any idea when this might be fixed? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/350695 [10:41] Launchpad bug 350695 in linux "Linksys WUSB100 not enabled by rt2870 driver." [Undecided,Confirmed] [10:41] I looked on the kernel bugzilla, couldn't find a bug there for it, so I added one. [10:42] i guess it really is application problem, just wondering how sound-juicer/brasero use gvfs differently from nautilus [10:43] hile: sure, but it's all the same device (and it's probably much easier to write udev rules so that the symlinks come out that way). If I were you I'd be filing bugs on sound-juicer and brasero. [10:44] sure, I'll do that, just wanted to make sure it's not a screwup I have caused somehow myself [10:45] hile: doesn't look like it, on the face of it [10:46] That bug I posted also han't been fixed in the karmic kernel either [10:54] pitti: could you please not have https://code.launchpad.net/~ubuntu-core-dev/ubuntu/karmic/hal/ubuntu in the source package branch namespace? I pretty firmly believe that only full-tree branches should be in that namespace [10:54] (and I said this yesterday and I didn't see you objecting then ...) [10:55] pitti: if you give us some time, we may be able to come up with a way to glue your history into a full-tree branch; we discussed this at UDS [10:55] cjwatson: okay, I'll move it back then [10:56] thanks [10:56] (not that it would be any more appropriate against the upstream project FWIW) [10:56] no, but at least it's existing inappropriateness [10:57] deleted [10:57] once we have source package branches for everything I want it to be an invariant that we can point people at those branches and they can see all the code we ship [10:57] even if those aren't the branches we actually develop against for the time being [10:58] obviously it will take some shuffling to get there ... [10:59] pushed to old location and updated Vcs-Bzr in bzr [11:06] pitti: u around? [11:06] rcmorano: hi [11:06] yo :] [11:06] im looking into a gdm-guest-session bug [11:07] ive found that it applies a apparmor profile which disallows the guest user to execute files in /tmp/** [11:08] so, for example, in my case, .desktops in Desktop/ [11:08] are not rendered (no icon, not trusted -> can not be executed) [11:09] rcmorano: right [11:09] well, i forgot to mention that guest user homedir is created in /tmp [11:09] although i think u already know hehe [11:09] so... i wanted to know if that's a security issue [11:09] or just a deeper bug [11:09] (guest user could not execute anything inside of his home) [11:10] rcmorano: when I wrote the AA profile, I just included the minimum privs to get the session up and running, and use the installed programs [11:10] running guests' own code wasn't amongst those [11:10] aha [11:11] but I guess it's easy to circumvent anyway, and guest doesn't have many privs, so I wouldn't mind adding /tmp/** x [11:12] yeh, ive tried 'ix' and worked right [11:12] just wanted to know if i should file a bug from the point of view of ".desktops are not rendered" or "guest user can not execute a shit" [11:12] hehe [11:13] if you think it's ok to allow guest user to execute things i can open a bug about this issue [11:14] rcmorano: if you change /etc/apparmor.d/gdm-guest-session [11:14] /tmp/** rwlkm, [11:14] to [11:14] /tmp/** rwlkmx, [11:14] rcmorano: does it work then? [11:14] rcmorano: right, please report a bug [11:14] there is no 'x' flag [11:14] ive tried 'ix' [11:15] and 'ux' (which threw me a warning about security risks) [11:15] im not very familiar to apparmor [11:15] i just tried to add any +x permissions [11:15] :] [11:15] rcmorano: right, sorry; ix is fine [11:15] oke :D [11:15] ux is a no-no [11:16] yeh i supposed hehe [11:16] many thanks mate [11:16] gonna report it :]! [11:18] mmm, kms is noce :) [11:18] *nice [11:18] ogra: pure love, isn't it? :-) [11:19] yeah, finally my gdm comes up in the right resolution on the external monitor [11:19] it's so beatiful :] [11:19] though i didnt see any change in usplash [11:25] hmm, dropping the resolution settings from usplash.conf gets it right on shutdown, but not during boot [11:25] i guess it first detects the internal display ... [11:26] right, I was just about to try something similar [11:26] I just disabled usplash, we can't start it in the initramfs any more anyway with KMS [11:26] surely one needs to ensure that i915 is there before usplash starts - and that, I think, is sort of conditional on Keybuk's plans to move usplash out of the initramfs [11:26] or at least sometimes out of the initramfs. I think we still need it in the initramfs for live CD boots [11:27] my initramfs is still around for more than 10s [11:27] well, considering that Keybuk hasn't started uploading work to slim it down yet ... :) [11:27] there is no kernel driver for the builtin touchscreen, it always takes a while to notice [11:29] which means udev hangs scanning for a while, i think we'll see that on other unknown devices too and should have a fallback for that case [11:30] we are going to have a fallback for cases where a bigger initramfs with usplash is necessary [11:30] that's already been discussed and agreed [11:30] ah, good [11:30] exactly when we do that fallback is I think less critical [11:30] i sadly missed that session [11:30] but we know that we need it for things like dm-crypt [11:30] yeah [11:31] hmm, /me thought Bug 365053 was fixed [11:31] Launchpad bug 365053 in initramfs-tools "On armel (Babbage platform), kernel image upgrading breaks if Ubiquity is instructed not to install a bootloader" [Undecided,New] https://launchpad.net/bugs/365053 [11:33] ah, no, we only discussed the fix [11:58] g;morning [12:01] cjwatson: can you please revert the oo.o-l10n cdimage hack from alpha-1? [12:01] hey lamont [12:02] pitti: I already did [12:02] timestamp: Mon 2009-05-18 10:36:18 +0100 [12:02] cjwatson: cheers [12:05] Riddell: is someone working on bug 376396 by next Tuesday? (alpha-2 blocker) [12:05] Launchpad bug 376396 in kdebase "pulls in phonon-backend-null" [High,In progress] https://launchpad.net/bugs/376396 [12:06] pitti: yeah I'll look at it [12:06] cool, thanks === statik` is now known as statik [12:15] directhex: hi, is there anything blocking us to update the gtk# stack to 2.4? [12:16] seb128, mono you mean? i'd been holding off on requesting an update until an ourtstanding bug in -2 is fixed which forces user acknowledgement to upgrade using aptitude [12:16] siretart: hi. how are you? what do you think about opening up scanResults member to "default" in wpasupplicant dbus config? === cjwatson changed the topic of #ubuntu-devel to: buildds on manual while coreutils is fixed | Archive: Open for development | Karmic alpha 1 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs [12:16] directhex: ok thanks [12:16] seb128, there's a bugfix release, 2.4.2, due from upstream on monday, so we were gonna -1 that rather than -3 2.4.0 [12:17] directhex: ok, I was just wondering if we would get the new version before alpha2 next week [12:17] seb128, if you're happy enough with the minor upgrade issue which only affects a non-default upgrade tool, then it's fine to pull it in [12:18] the issue is only for aptitude? [12:18] seb128, indeed. tested with update-manager and apt-get and synaptic as fine [12:19] ok, so we can update, unstable users should not care about such details [12:19] seb128, aptitude's super-advanced resolver fails to work out that an old package should be removed without the user agreeing to the proposed removal [12:24] TheMuso: would like to talk a bit about bluetooth + pulse in karmic, let me know when there/back. [12:31] asac: hey there, I'm more or less fine, but caught a cold [12:32] asac: regarding wpasupplicant, sorry, I have to admit that I haven't looked in that package for some month, and didn't look into the dbus interface at all [12:35] siretart: yeah. the idea is to allow user apps to look at current scanResults; afaik they can do that using iwlist anyway - but iwlist is more unreliable. [12:36] example: firefox 3.5 uses iw to get scan results for its geolocation stuff [12:36] feels like wpasupplicant could help to make this better === akgraner_ is now known as akgraner === dashua_ is now known as dashua [12:50] pitti: who should be approver for kubuntu specs I write? [12:51] Riddell: someone else in the Kubuntu community, like ScottK, or me, as you wish [13:11] asac: isn't that exposed already anyways by nm-tool? [13:17] * wgrant is glad to see the buildds in manual mode. [13:17] yeah, we probably ought to have done that earlier, sorry [13:17] I'll do a mass give-back once this is all done [13:18] No, not really - it blocks all PPA builds too... [13:18] yeah, but those were failing too (at least the ones for karmic) [13:18] Which isn't most of them. [13:18] true, I guess [13:18] Last time this happened, a lot of PPA users were veeery confused. [13:19] though we could have taken down all the distro builders and left the PPA ones up [13:19] That's true. [13:19] buildds have to be down while chroots are being mangled manually, though [13:19] them's the rules [13:19] Right. [13:20] I guess it could be a bit bad if a PPA Karmic build gets dispatched with the hacked up chroot. === korn_ is now known as c_korn === azeem_ is now known as azeem === agateau_ is now known as agateau [13:59] pitti: how do we get our specs series goal to be accepted for katmic? [13:59] karmic [14:00] Riddell: I can accept them for you [14:00] just toss me the links === cprov1 is now known as cprov [14:01] pitti: all the ones on https://wiki.kubuntu.org/KubuntuKarmicSpecs [14:03] Riddell: done [15:01] Under what circumstances does a give-back just fix stuff? I've got a FTBFS that looks like that's all it needs (builds in my chroot), but I can't figure out why it failed in first place. The buildd couldn't find dependencies that seem like they should have been built and ready for a month beforehand. bug 383921 [15:01] Launchpad bug 383921 in taglib "FTBFS in Karmic because of a broken librcc-dev dependency" [Undecided,In progress] https://launchpad.net/bugs/383921 [15:05] mterry: if a no-change upload would fix a FTBFS, a give-back is good. [15:05] mterry: apt isn't always very detailed about its uninstallability messages [15:05] mterry: it probably wasn't actually the fault of the packages listed there, but rather of one of their dependencies [15:05] mterry: if they're installable in karmic right now, I'd recommend a give-back [15:06] cjwatson: OK. Who do I ping about that? Or subscribe to the bug? main-sponsors? [15:06] https://edge.launchpad.net/ubuntu/+source/librcc/+publishinghistory [15:06] mterry: hardly seems worth the sponsorship queue, I'll just do it now [15:06] it was the ogre model [15:06] the package has been promoted in the meantime [15:06] mterry: anyone who can upload the package can give it back [15:07] james_w: I don't get that from your link [15:07] cjwatson: OK, thanks [15:08] the link shows that the same version of the package has been published twice in karmic, once in universe, and then later in main [15:08] it's not very clear from the link, but when you see two publishing records for the same version like that, it's because its overrides changed [15:08] also, bug 374997 [15:08] Launchpad bug 374997 in librcc "main inclusion report librcc/enca" [Undecided,Fix released] https://launchpad.net/bugs/374997 [15:09] james_w: I see. I did look at that link before, but the inclusion was on May 12, and the build failed on May 28 [15:09] but enca was never promoted [15:09] Ah.. [15:09] so, actually, those builds might well still fail ... [15:09] what you need to do to reproduce this is to try the build in a chroot with only main enabled, not universe [15:10] anybody know anything about libgnet ? [15:10] cjwatson: Ah! That makes sense === yofel_ is now known as yofel [15:12] it looks like gnet was in Main through Hardy and then got demoted for Intrepid [15:13] cjwatson: does ubuntu-archive keep track of why things are demoted? [15:14] LaserJock: no, it's basically always just because nothing depends on it any more so there's not much to keep track of [15:15] right, the record is kept either in the seed commit log or in the changelog of the package that stopped depending on it [15:15] cjwatson: right, makes sense. So do I need a full MIR to get it back in or is a simple bug enough? [15:16] or can I just upload something that deps on it [15:17] the latest Debian version of gcompris depends on libgnet-dev so I wasn't sure if I should just merge and fix the FTBFS later or try to get gnet promoted first [15:18] I think a simple bug's probably enough, with a note that it used to be in main [15:18] LaserJock: that's for the MIR team to decide anyway, so simplest is to open a bug that just says "it was in main before and we want to bring it back", then subscribe ubuntu-mir and see what they say [15:18] (subscribe ~ubuntu-archive) [15:18] oh, opposite viewpoints :) [15:18] well, we agree on "simple bug" :) [15:18] subscribing ~ubuntu-mir is the conservative approach and is definitely fine [15:19] ok, cool, thanks guys === robbiew1 is now known as robbiew [15:28] cjwatson: can we turn the world back on? [15:29] my karmic chroot upgraded to 7.4-2 without whining [15:29] yep, mine too [15:30] * ion_ tests... yeah, works [15:32] Do buildds have to do such automatic upgrades that may put them into a broken state? How about aptitude safe-upgrade, with an admin running a manual full-upgrade every once in a while? I’m sure there are reasons that wouldn’t work, though. [15:32] I think it's best overall for them to be current, yes [15:33] instances such as this are rare [15:33] Yeah, that’s true [15:33] and in fact the last case where we had to recover manually wouldn't have been prevented by your scheme [15:33] A snapshotting filesystem and automatic rollback if things break? :-) [15:34] mvo: ^ tell ion_ about your new idea :) [15:35] james_w: around? [15:35] Couldn't 7.4-1 have been removed, the previous version copied back in, 7.4-2 uploaded, and everything resolved pretty quickly without nasty chroot mangling? [15:35] LaserJock: yup [15:36] ion_: I'd like to keep the buildds simple :) [15:37] wgrant: maybe, but we'd have to circumvent strict rules about going backwards [15:37] A snapshotting filesystem, an automatic snapshot before each upgrade, and a *manual* rollback by admin if things break? :-P [15:38] ion_: you know that the buildd filesystem is unpacked afresh from a tarball for every build, right? [15:38] cjwatson: And you didn't have to circumvent strict rules about changing buildds to manual, altering chroots, and manually dispatching builds (assuming that the exception wasn't already made for this sort of case)? [15:38] wgrant: the rules are in different places [15:38] cjwatson: i figured it was too late in our cycle to jump to eglibc...since I also don't recall any decision being made [15:38] and anyway, that wouldn't change the fact that the resulting snapshotted buildd would have other stale packages, which is something we want to avoid [15:39] wgrant: the procedure for this sort of thing is pretty well-established [15:39] cjwatson: Ah, ok. [15:39] cjwatson: I guess so. [15:39] robbiew: hmm, ok [15:39] cjwatson: i'm happy to...if we feel it's reasonably safe, though [15:40] well, I do, but I know there is disagreement [15:40] if maintainers wouldn't upload Essential packages in a broken state, we wouldn't have to worry about broken chroots so much anyway ;) [15:40] cjwatson: right...and I can't recall where that thread ended up [15:40] robbiew: down a rathole, as usual :) [15:41] stalled, I think. I do have some sympathy for the view that with doko doing other things this cycle maybe it isn't the ideal time to switch over; I would like to make sure that we have some practical way to merge bug-fixes from Debian when we need to though [15:41] right....and doing it now, versus a potential LTS release makes sense [15:42] if the switch is what it's supposed to be, I don't see any reason release-wise to consider it "too late" to switch [15:42] hmmm [15:42] since it's effectively a packaging change, not pulling in a major new upstream version of a toolchain package or anything [15:42] I see it much more likely to be a PR issue than an operational one, myself [15:43] well...hmm [15:43] a lot of people are worried about things that (on investigation) I think have been accounted for [15:43] but the eglibc upstream folks aren't great at describing what they're doing [15:45] certainly being able to remove large parts of glibc for the installer might be nice [15:46] but yeah, the way Debian communicated it wasn't perfect, combined with a low-profile upstream [15:48] azeem: I'm not even bothered about that [15:49] I mean, I don't hugely object, although I shudder slightly at the idea of some of the bug reports it might generate so actually I'd sort of rather the C library weren't stripped down for the installer [15:51] pitti: does using apport-collect on a bug append a bug tag 'apport-package' or something like that to it? [15:51] cjwatson: slangasek: we have the release meeting coming up...should we discuss the eglibc there? or is that just making the rat hole bigger? [15:52] pitti: i'm trying to write a script that can automatically process my bug queue :) [15:52] I thought Ubuntu sets the toolchain one release in advance; is this about karmic or karmic+1? [15:52] robbiew: I think that's just going to lead to bikeshedding [15:52] azeem: karmic [15:52] k [15:53] as I said, I dispute that this constitutes a "toolchain" change that we need to worry about the impact of :) [15:54] it might get some media attention though - even the Debian move got much more attention than aurel32 would've dreamt about [15:54] (or wanted) [15:54] like Canonical vs. RedHat or something [15:56] slangasek: yeah...figured [15:56] azeem: how naive of him ;) [15:57] * robbiew considers making "the call"... [15:57] calc: it doesn't right now, since it can't know what the problem is all about (crash, package failure, bug report, etc.) [15:58] pitti: ah ok [15:59] * calc has 400 bug mail to process today, yuck [16:05] NCommander, lool, seb128: there, an armel apport retracer! [16:05] YAY !!!! [16:05] elmo: thanks for fixing the firewall [16:05] * ogra hugs elmo [16:05] processing the huuuuge (erm, "3") backlog now [16:05] heh [16:05] * robbiew hits elmo...again :P [16:14] pitti: bug reports about xorg-edgers are fine in x lp; just be sure the versions used are listed in the report so it's clear [16:14] do we have Section: debug in karmic? [16:14] bryce, happy to report that youtube fullscreen works again with the latest fix [16:14] bryce: yes, I did an apport-collect for mesa again [16:15] bryce: didn't upstream it yet (release meeting, and then I need to run), will do later/monday [17:12] cjwatson, do you bump debian-cd alongside (tools/boot-arm) the installer ? [17:13] ogra: yeah, will do that now [17:13] thanks [17:13] asac: xulrunner-1.9 seems to have grown by a megabyte from .0.8 to .0.10 - do you know why? [17:17] I looked at the coreutils growth when I noticed it; turns out each of the umpteen million utilities grew in size by a block :P [17:18] I can probably do something about man-d [17:18] b [17:18] though it's well down the list [17:18] bah, why is openoffice.org-l10n-en-za now 8.8MB instead of 384K? [17:19] I was just about to say! [17:19] calc: ^- [17:19] Changed: openoffice.org-l10n-en-za 8564K [17:19] 3.0.1-9ubuntu2 378K [17:19] 3.1.0-3ubuntu2 8942K [17:43] ah crap, looking into that now [17:45] looks like en-za has more stuff localized now, looking to see what was in 3.0.1 now [17:49] is there an easy way to do a file size comparison for a whole deb? [17:49] er side by side file size comparison [17:50] so en-za was installed size 5488 size 387750 for jaunty and is now installed size 16080 size 9157472 for karmic, the installed size roughly doubled but the compressed size went way up [17:51] for other langs such as -de it was already huge for the compressed size, so i am not sure what was going on with it being so tiny for the en-za on jaunty [17:52] calc: easy way> if you find one let me know :-) [17:53] cjwatson: heh ok [17:53] calc: there aren't any extra files in there then? it's just extra translations? [17:53] cjwatson: i think so, not quite sure what happened [17:53] calc: how many of the localisations are just identical to the original text? [17:53] cjwatson: it doesn't look like there are things that shouldn't be there from just looking at dpkg -L [17:53] calc: we had that problem for en_US once and instituted some specialised filtering [17:54] other languages like -de were already roughly the size en-za is now for compressed size [17:54] already in jaunty i mean [17:54] specifically http://bazaar.launchpad.net/~ubuntu-langpack/langpack-o-matic/main/annotate/head%3A/bin/msgequal.c [17:55] for 8MB, it might be worth trying to see if e.g. it could depend on en-us and symlink ... [17:56] or something like that [17:56] ah i think i see what the issue is [17:56] in fact, the en-us stuff appears to be in -common [17:56] yea i think whatever was doing the symlinks went away [17:57] so the templates caused the file size explosion [17:57] aha [18:03] it probably got dropped due to the directory name changing, i'll have to dig around in the rules and see what happened [18:04] with each new release ooo changes its basis dir name [18:04] there is a link dir that i might be able to use to link to instead which if that is problem with cause it not to recur [18:06] * calc bbl, lumch [18:06] er lunch [18:22] Does bug 384012 need an InclusionReport wiki page too or is it self-obvious enough? [18:22] Launchpad bug 384012 in gnome-python-extras "Include all binary packages in Main" [Undecided,New] https://launchpad.net/bugs/384012 [18:28] cjwatson: does en-za hit the cd? i assume this is an alpha 2 blocker? [18:28] it does hit the CD [18:28] cjwatson: if so i can try to get it done by monday night for a2 freeze [18:28] slangasek: ok [18:28] it may not be an a2 blocker, but it would be nice to have this done [18:28] slangasek: i'll get it done, if you haven't seen an upload by monday ping me again [18:28] ok, cheers :) [18:28] * calc will be out most of the day tomorrow, but should have time to work on it on sunday [18:29] i can turn on l10n export to rosetta finally as well (i think), upstream fixed that issue shortly after my last upload [18:29] i'll make sure to actually test it works before uploading though, heh [18:30] it takes 2hr to do a build without l10n export vs ~ 6hr with it so i normally don't do l10n export testing [18:30] mterry: binary packages should not generally need MIRs at all; my understanding is that the MIR review is done source-wise === thekorn_ is now known as thekorn [18:31] slangasek: I asked in #ubuntu-motu and superm1 indicated that it is per-binary [18:31] hmm [18:31] as an archive admin, I don't believe that's true in practice :) [18:32] slangasek: He gave lirc as an example. And I'm giving python-gnome2-extras as an example. :) [18:33] mterry: well, *especially* in this case, it's clear to me that no MIR is needed [18:33] since it's simply a binary package split of stuff already in main [18:33] Right [18:34] Sometimes ya'll like your formality though :) [18:34] so this is already on the component-mismatches report under "binary only promotions", which I routinely act on without even looking for an MIR bug [18:35] as for the referenced build failure, I think deskbar-applet should be updated to not rely on the transitional dummy package [18:35] Guh! So you have a special "binary only promotions" page and you weren't sure if inclusion was per-binary? [18:35] slangasek: Agreed [18:35] mterry: "weren't sure if"? [18:36] slangasek: Ah. You were talking about the *review* being source-wise [18:36] yes [18:37] so if the source is in main, as an archive admin I don't look for other paperwork before resolving the binaries on components-mismatches [18:37] Alright, I'll see about filing a debian bug about the deskbar-applet thing I guess [18:37] slangasek: Sure. So I won't file binary-only inclusion bugs in future, I'll just poke you if it's urgent. [18:37] sounds good :) [18:37] binaries promoted, in this case [18:37] so I think you can close that bug [18:38] k [18:40] mterry: poke the archive admin of the day for preference, though; http://wiki.ubuntu.com/ArchiveAdministration [18:41]