[01:00] kees: random thought of the day [01:00] swap-on-RAID1 is insane, right? :p [01:01] insane? no, it's a good idea. [01:01] really, why? [01:01] because if you lose a drive you don't eat your system? [01:01] doesn't md have a performance penalty though? [01:02] people using raid1 generally either have a raid1 swap partition or put swap in a file in the raid'd root fs [01:02] *shrug* [01:02] if you're swapping that much, who cares? :) [01:02] lol [01:02] a fair point [01:03] what's insane is swap over network block device. but then lots of things are insane about LTSP. ;) [01:03] I'm being creative [01:03] I'm setting this machine up so that its 1TB drive is divided into three RAID-1s [01:03] a 256MB for /boot, a 2GB for swap and the rest for LVM [01:03] but no second drive ;) [01:03] for testing, I assume? [01:04] that and future proofing [01:04] if you don't intend to ever hibernate, just but your swap in the LVM [01:04] s/but/put [01:04] it's a file server, so I might want to put a second disk in later and actually do RAID-1 [01:04] thus it's most logical to set it up as LVM-on-MD rather than just plain LVM [01:04] aaah, you're doing a degraded raid1? [01:04] is it degraded? [01:05] if you only have 1 drive it is. :P [01:05] why? [01:05] uhm... because... there's... no mirror? :P [01:05] RAID-1 can be anything from 1..n drives [01:05] it just happens that most people use 2 :p [01:06] well, I've never tried mdadm --grow -n 2 on a -n 1 array before [01:07] it works [01:07] hah -n: Setting a value of 1 is prob‐ [01:07] ably a mistake and so requires that --force be specified first. [01:07] cool, yeah, that'll fly. I've never used it myself. [01:07] I actually saw it on someone else's system [01:08] anyway, in that case, use 2 MDs, one for boot, one for LVM [01:08] and though "damn, that's a _good_ default setup" [01:08] just make swap another lv within the LVM [01:08] Keybuk: swap-on-raid is not only sane, but really the only way to go for the magical five-nines. [01:08] I tend to buy drives in pairs, so I can add/remove protected md arrays as pvs to my VGs [01:09] kees: why swap-on-LV instead of swap-on-MD ? [01:09] Keybuk: If your have non-raid swap, when a drive dies, your kernel panics. [01:09] Keybuk: because then it's easier to move around [01:09] kees: but impossible to resume from? [01:09] (in fact, why is it impossible to hibernate to/from it?) [01:09] well, you said file-server. [01:10] I said "if you never hibernate..." earlier somewhere [01:10] Keybuk: Impossible to restore from an MD/LV swap because the kernel goes looking for hibernate signatures on swap partitions long before we load any MD/LV drivers. [01:10] it is possible, but you have to specify the allocation map [01:10] if we did MD and LVM by default [01:10] Keybuk: This isn't an unsurmountable problem. [01:10] would you do swap-on-MD or swap-on-LV ? [01:11] infinity: I didn't think the kernel looked at all these days? we resume by hand in initramfs [01:11] or is it the actual going down bit? [01:11] (Likewise, hibernating to a swap file is just as doable, we just... Don't) [01:11] I would do swap-on-MD to handle the easy suspend/hibernate case. [01:11] I usually have boot on raid1, then the rest of space on LV on raidN, including swap, but then I don't hibernate such multi-disk servers [01:11] Robot101: yeah, that's my case for all the desktop machines in my house [01:12] * kees needs to find a cheap laptop with 2 harddrives. :) [01:12] and by boot, I usually just take 10GB for / and anything like /var or /home that gets big goes onto the LV [01:13] Robot101: you have / rather than /boot ? [01:13] Keybuk: Oh, indeed, we do go looking ourselves these days. So it's more a question of load order and such. [01:13] Keybuk: No reason we couldn't support resuming from crazy MD/LV setups, as well as from swapfiles read from a readonly root. [01:13] Keybuk: Just would take a bit of code and thought. [01:13] infinity: I'm not entirely sure it would require code anymore :p [01:14] it might just require a busy loop [01:14] or, better yet, a rethink of initramfs so that "mountroot" and "resume" aren't totally separate ways to go [01:14] Keybuk: At the very least, we need a way for resume= to be slightly smarter than just "a partition identifier". [01:15] (For the "suspend to swapfile" option, especially) [01:15] And swap files tend to be the more elegant solution for a lot of interesting use-cases. [01:16] (No one tell Microsoft I said that, though...) [01:17] agree [01:17] but then I'd say the same for root= ;) [01:20] Keybuk: Well, given the amount of crazy logic we can stuff in initramfs, I suppose there's no reason root= couldn't be a pointer to a file on $random_filesystem. [01:20] Keybuk: Not sure how often I'd use that feature, but if we write the code for resume-from-swapfile, we kinda get root-on-file for free. [01:20] (ish) [01:20] you should be able to say root= some magic string that defines a unionfs of two loop-mounted filesystems on a partition named by uuid [01:20] then we wouldn't need to special case things like the live cd and wubi [01:21] Voobee! [01:21] Is it wrong that the only thing I took home from that presentation was the pronounciation? [01:24] so the platform meeting will be tomorrow at 5pm? [01:24] er 2200 UTC [01:25] calc: If there is anything worth discussing. Your question is the first mention of it I've seen outside of what Colin said. [01:25] I hate d-i [01:25] "Failed to determine the codename for the release." [01:25] Keybuk: why? [01:25] W. T. F. [01:25] heh [01:25] sometimes bugs happend [01:25] TheMuso: ok [01:27] nxvl: this is the hardy release! [01:27] on a hardy instalation you mean? [01:27] i thought it was on intrepid tests [01:27] :S [01:29] yeah hardy server i386 [01:32] it's probably my error [01:40] in fact, I really can't see why [01:41] others have reported it [01:41] and cjwatson told them to follow the docs :-/ [01:41] which is what I thought I'd done [01:42] evand: any ideas? [01:49] * Keybuk cheats [01:49] when in doubt, live edit the installer code to work around the issue [02:04] popey: ping [02:05] Keybuk: yeah I just take 10GB for /. once you split mail, home and service data out of /, the actual amount of space you need for the actual software on a server is very small [02:06] (unless it's a game server) [02:07] well, obviously anything you expect to be large you can allocate out of the LVs [02:07] like make a spacious /srv or something [02:07] I just have / 1TB so I don't have to worry about it ;) [02:14] Keybuk: well, this pattern is flexible for varying workloads - hosting VMs whose root FSes are LVs anyway [02:15] Keybuk: and changing the RAID stuff around, adding more disks etc, growing with LVM is always easier [02:15] Keybuk: also I like the way I can shuffle the disks, or take any one of them, and boot the system still [02:39] bryce: sorry for the delay, I've posted a comment to bug 213191 [02:39] Launchpad bug 213191 in xserver-xorg-video-intel "855GME system freezes when switching to external monitor" [Unknown,In progress] https://launchpad.net/bugs/213191 [02:39] ogasawara: thanks === evalles_ is now known as recover === recover is now known as effie_jayx [03:26] Hi. Can someone tell me why using Install New Language to install french-language support in Kubuntu downloads the Thunderbird package? Why would a language pack require you to download a mail client? [03:27] Erk, something went wrong in a dependency resolver somewhere. [03:28] language-support-fr pulls in thunderbird-locale-fr, which shouldn't need thunderbird unless language-support-fr isn't installed, which it is about to be. [03:29] well, it downloaded the full thunderbird-2.0.0.14 etc, took forever too :) [03:29] I guess the locale had the main program listed as a dependency? [03:30] thunderbird-locale-fr has a 'thunderbird | language-support-fr' dependency. [03:30] cody-somerville: ping [03:30] So the fact that you're installing language-support-fr should satisfy it. [03:30] cody-somerville: not sure if you saw my response about the xubuntu OOo bug [03:30] But it apparently decides it needs thunderbird too. [03:30] calc, link? [03:30] I see, thanks for the info [03:30] i forgot the bug number already [03:31] you responded to it a few hours ago its the one about openoffice.org-gtk needing to be installed under xubuntu [03:31] Yes [03:31] That isn't a Xubuntu-meta bug [03:31] i reassigned it to xubuntu-meta since xubuntu needs to seed that if it wants it [03:31] its not something wrong with OOo [03:31] That isn't the bug [03:31] oh? [03:31] He was installing from add/remove [03:31] You should read the bug description not just the bug title ;] === asac_ is now known as asac [03:32] * cody-somerville goes back to watching House. :) [03:32] ah he manually installed OOo [03:32] ok its not a bug at all then [03:32] i just marked it invalid [03:33] I wouldn't be so quick to dismiss it. [03:33] You should really mark it as a bug of the add/remove app [03:33] and mark it wishlist [03:34] the add/remove app autoinstalls things you don't request it to, that aren't depends? [03:35] It doesn't (although it will support Recommends: as well at some point) [03:35] i was under the impression it was just a slightly prettier package manager that lists per applications folder [03:35] so it would probably need some kind of ugly hack to support installing packages based on the flavor of *buntu [03:35] calc, It wouln't be the flavour of ubuntu [03:35] It would be based on the desktop environment [03:36] true, it is just normally they are linked :) [03:36] That's even harder to determine than the flavour. [03:36] persia, Lets let the add/remove folks figure it out [03:36] s/lot/worry [03:36] erm [03:36] * calc thinks the user should just install what they want [03:36] It isn't clear [03:36] cody-somerville: Erm. I've been looking at that code. [03:37] The user shouldn't have to install open office writer and then some other package to make it look integrated. [03:37] What's the bug number? [03:41] * calc already deleted the email :-\ [03:43] One second. [03:45] https://bugs.edge.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/236265 [03:45] Launchpad bug 236265 in xubuntu-meta "[hardy] openoffice.org-gtk should be automatically installed in Xubuntu" [Undecided,Invalid] [03:45] calc, It is not a bug in xubuntu-meta and not a bug in "xubuntu in general" [03:46] It's an issue with the data contained in app-install-data. Where that data comes from is different. [03:47] It's not a bug in xubuntu-meta, as it's not installed by default, so it oughtn't be seeded. [03:47] It may be a bug in OO.o, but only in the syntax of some of the .desktop files. [03:47] * cody-somerville nods. [03:47] persia, My thoughts exactly. [03:47] Also, there likely ought to be a gtk-app-install, for xubuntu, as otherwise the gnome hints will apply. [03:47] I filed it against app-install-data-ubuntu since calc keeps removing it from OpenOffice [03:48] cody-somerville: I'm still looking, but I'm very much leaning towards the problem being a lack of a specialised app-install for Xubuntu, rather than an issue with OO.o. [03:48] Anyway, without such an app, it's *really* hard for calc to fix it. [03:49] Ah, no, it's not a bug in OO.o at all. [03:49] The OO.o install hints are hardcoded in app-install-data, because there are so many ,desktop entries. [03:49] ah. [03:50] So, there are two bugs: the lack of a gtk-app-install, and a minor patch to menu-data-additional in app-install-data once there is such a program. [03:50] Generating gtk-app-install ought be fairly easy, given gnome-app-install as an example. [03:51] Once that's in place, opening a bug against app-install-data to provide the right hints ought be fine (or they can be overridden in gtk-app-install, depending on the complexity of each task) [03:52] Bug 236265 is likely best set WontFix, unless Xubuntu plans to seek openoffice.org-gtk [03:52] Launchpad bug 236265 in app-install-data-ubuntu "[hardy] openoffice.org-gtk should be automatically installed in Xubuntu" [Undecided,New] https://launchpad.net/bugs/236265 [03:52] s/seek/seed/ [03:53] cody-somerville: Does that give you a roadmap, or do you need more information? [03:54] Plain rebuild was enough for vim to get linked to libperl5.10. [04:02] Afternoon all [04:02] greetings [04:02] Howdy [04:02] Evening. [04:02] wgrant: no, it's not evening. [04:02] Yes, it is. [04:02] It's close enough. [04:04] sorry for bouncing the bug around so much, but i'm glad someone who knew how it works saw it :) [04:04] * calc hugs persia [04:05] wgrant: yet certain people in your timezone probably just woke up [04:05] sigh, chroot problems. [04:06] ajmitch: Perhaps so. [04:06] calc: Mind you, I'm not happy about the fact that OO.o assumes it will be seeded. Around half our derivatives don't, and it can be confusing when optimising for Ubuntu :) === RadiantFire_ is now known as RadiantFire [04:57] persia: well the other option is to just force people to install everything, but then people complain it takes too much space, etc [04:57] because if you ask enough people they want all the features in OOo [04:58] but that is really large and definitely wouldn't fit on an install cd [04:58] calc: For those people who want OOo, I agree. [04:58] On the other hand, for mythbuntu or Ubuntu Studio, I'm less sure it makes sense. [04:59] it shouldn't be getting installed on ubuntu studio at all, there is a bug in the lang packs stuff though [04:59] I think it's a hard problem, and that it will take a while to find something that works. [04:59] but for users that want to install it on ubuntu studio they would currently have to know what to install for what they want of it [04:59] calc: Right, which is the hard problem. app-install-data only provides a single hint, as OOo doesn't expose one cleanly. [05:00] eg you could install openoffice.org metapackage and it would recommend (depends on the package manager) ooo-kde and ooo-gnome, etc [05:00] As a result, it's tricky to later install OOo-kde or OOo-gtk, rather than OOo-gnome. [05:00] is there a way to expose a hint without forcing it to be installed eg a depends? [05:00] That gets into the parts of Add/Remove I don't know so well :) [05:00] if so i can modify OOo packaging to give hints, if there is a clear way to do this [05:00] ok [05:00] It has to do with special tags in the .desktop files. [05:01] well to use gtk/gnome/kde integration wouldn't be specific to a desktop file at least aiui [05:01] You might ask mvo later, if you have time. On the other hand, right now it only really affects Xubuntu, and a hack in gtk-app-install might be good enough. [05:01] ok [05:02] calc: Well, it's the .desktop file for the app installer vs. the .desktop file for the application itself. In many cases, these are the same. It may not be possible to have these be the same for OOo. [05:03] oh ok [05:06] calc: If you want to dig, compare /usr/share/app-install/desktop/ooo-meta.desktop as an example of such a hint [06:25] Good morning [06:27] hi pitti [06:43] Keybuk: oh, no Vcs-Bzr: for upstart? you do keep it in bzr, I take it? I'd like to fix the Pre-Depends: for sysvutils -> sysvinit-utils; or do you want to do that yourself? [07:14] good morning [07:25] <\sh> hey dholbach [07:28] hi \sh [08:11] <\sh> hmmm.wtf? temp removal of sysvutils during dist-upgrade...which breaks the upgrade path...was it a wish? :) [08:21] \sh: I think we need to fix upstart's Pre-Depends: on sysvutils; see my ping to Keybuk earlier on [08:21] <\sh> pitti, no backlog...but if it's known everything is fine :) [08:57] Keybuk: ping? :) [08:57] Keybuk: wait. you're techboard. unping. [08:59] ah, darn, and htere was no CC quorum. [10:12] hi people, could it be that AppArmor on 8.04 forbids to write to /sys with sudo command? [10:12] PecisDarbs: not by default [10:12] munckfish: I'll be fine thanks. I don't know yet, I haven't contributed to Ubuntu for a while now [10:12] damn then [10:12] PecisDarbs: look at the output of 'dmesg' to see the AppArmor erros [10:12] ok [10:15] arthur-: hi, glad to hear it, so you're primarily a debian guy? [10:16] munckfish: definitely yes [10:18] arthur-: ok cool. Well I'm happy to be responsible for these sorts of packages in Ubuntu it would be good if we could work together to make sure there's no wasted effort between the two projects [10:19] munckfish: sure, do you like git ? [10:21] arthur-: I love git. But I'm still at Git kindergarten really :D [10:26] munckfish: cool, we'll talk about all that later ;-) [10:30] arthur-: ok grab me whenever [10:39] hi [10:40] tseliot: do you know what DEST_MODULE_LOCATION in dkms.conf is for? it seems to be ignored, and all .kos actually land in /lib/modules/`uname -r`/updates/dkms/ ? [10:41] hi i've got a question about fonts in unbutu [10:45] pitti: let me quote the man page "Currently, DKMS searches [10:45] for these original modules with first preference going to modules [10:45] located in /lib/modules//updates/ followed by $DEST_MOD‐ [10:45] ULE_LOCATION (as specified in dkms.conf ). If one cannot be found in [10:45] either location, a find will be used to locate one for that kernel. If [10:45] none are found, then during a later uninstall, your kernel will not [10:45] have that module replaced." [10:46] If more than one is found, then the first one located (by preference [10:46] indicated above) will be considered the "original_module". [10:48] pitti: the one in updates is what will be loaded [10:49] anyone here/ [10:49] tseliot: ah, so it is not actually the path for the kmod to be installed, but the older kmod to be *replaced* [10:50] pitti: yes, exactly. In this way DKMS knows where's the original [10:50] and can make a backup [10:50] tseliot: aah; that might explain something; thanks! [10:51] pitt: I know that the fact that it's called "DEST" might suggest that it refers to the destination of the new module ;) [10:52] right, that's what confused me; the man page section about this parameter isn't very helpful [10:52] pitti: I'll be your human man page :-P [10:52] * pitti updates his dkms.conf autogeneration script for that [10:53] what exactly does ubuntu do to it's fonts to make them look so good? [10:55] i am getting totally ignored [10:57] pitti: have you seen #237276 ? I haven't investigated yet what the problem is exactly, I'm curious if you have seen it before? [10:58] mvo: I can only guess that it is due to upstart's Pre-Depends: [10:59] mvo: I pinged Keybuk about it (need to coordinate with him for bzr0 === ryu2 is now known as ryu [11:00] hi people, where I can find patches for Ubuntu kernel? in debian directory of source? [11:00] PecisDarbs: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=summary [11:05] pitti: ok, I milestoned it for alpha-1 [11:05] mvo: assigned to me, thanks [11:05] i take it David Turner himself is maintaining freetype on the ubuntu repos? [11:05] :) [11:05] * mvo hugs pitti [11:12] hey would i be ill-advised to use xorgconfig.py ? [11:14] /usr/share/python-support/guidance-backends/xorgconfig.py to be specific [11:15] Ademan: it's Guidance. What are you trying to do with it? [11:15] tseliot: not have to write my own code to parse xorg.conf [11:15] what do you mean it's guidance? i see it being used by displayconfig-gtk [11:16] seb128: how many gnome point releases are usually done? [11:16] Ademan: that file is part of Guidance i.e. a backend. I don't think it's maintained any longer. [11:17] Ademan: displayconfig-gtk is a gtk frontend to kde-guidance's displayconfig [11:17] Ademan: it's shipped in guidance-backends, and used by other packages as well [11:17] Ademan: it works, but the API is not very convenient nor robust [11:18] Ademan: these days you should probably be using xrandr rather than reading xorg.conf === cprov is now known as cprov-lunch [11:18] pitti: hrm, well, considering i'd rather not get friendly with flex and bison right now... i think i'll use it [11:18] Riddell: not for display actually, for input [11:18] Ademan: oh, yeah, it's miles ahead of writing your own :) [11:18] gonna see if i can't cook up something convenient for lots-o-button-mice [11:31] Riddell: you mean during the unstable cycle? or stable updates? [11:32] well thanks guys, later [11:36] seb128: stable [11:38] Riddell: 3 [11:38] until .3 rather [11:38] seb128: right, and those are monthly? [11:39] * pitti fixes SpecTemplate to have a standard header again (UbuntuSpec:, contributors, affected packages, etc.) [11:40] that's not a fixed monthly schedule but roughly yet [11:40] yes [11:40] 2.22.1 to 2.22.2 was 6 weeks [11:41] mm, interesting, thanks seb128 [11:41] they avoid having new stable and unstable in the same weeks so there is some flexibility [11:41] you are welcome === thekorn_ is now known as thekorn === elky is now known as elkbuntu [12:35] pitti: fix to what? [12:46] Keybuk: sysvutils to sysvinit-utils [12:51] pitti: did you get any explanation from Debian why they renamed the package? [12:51] Keybuk: they didn't rename it within Debian; it has always been called like this in D [12:51] * pitti goes to reproduce the bug in vmware, and test fixes [12:52] pitti: they renamed it when they took the patch to separate it from us though [12:52] we split it out first [12:52] right [12:53] I never understood why they didn't use our name? [12:53] neither have I [12:53] just cosmetical reasons, I guess [12:53] "Not Named Here" :) [12:54] "detlef@MD97600:~/gnome$ apt-get source apport" obtains 191kB but complains: "gpg: Signatur am Sa 17 Mai 2008 14:07:51 CEST mit DSA Schlüssel, ID 5E0577F2, erfolgt; gpg: Unterschrift kann nicht geprüft werden: Öffentlicher Schlüssel nicht gefunden." How can I make gpg to find the public key? [12:54] ugh, apt-get source verifies signatures? [12:54] pitti: what's the right way to do a XS-VCS-Bzr ? [12:55] Keybuk: Vcs-Bzr: https://code.launchpad.net/~ubuntu-core-dev/upstart/ubuntu [12:55] or so [12:55] Keybuk: no XS- any more [12:55] Keybuk: http://bazaar. works as well (that's the code browser) [12:55] bzr get works with either [12:57] hmm [12:57] weirdly, the header is in bzr [12:57] but doesn't show up in the source package [12:58] Keybuk: I don't see it in the apt-get source'd upstart [12:59] no, that's what I mean [13:00] pitti: bug# for the sysvutils issue? [13:00] Keybuk: bug 237276 [13:00] Launchpad bug 237276 in sysvinit "hardy->intrepid upgrade fails because of sysvinit pre-depends loop" [High,In progress] https://launchpad.net/bugs/237276 [13:01] Keybuk: my vmware is still upgrading (ugh, 130 MB to download) [13:03] ok, done [13:04] Keybuk: cheers [13:05] hopefully the bzr header should show up now [13:05] OOI, how do you manage it? [13:05] do you apt-get source the package, then checkout the debian directory wiping what's there? [13:05] Keybuk: just debuild -S it and check the .dsc [13:06] FYI, bzr-builddeb 0.95 is able to do this: `bzr bd -S https://code.launchpad.net/~ubuntu-core-dev/upstart/ubuntu` [13:06] no, I mean, how do you handle debian-in-bzr ? [13:06] Keybuk: usually debcheckout -a, and then unpack the orig.tar.gz, yes [13:06] ah, and you put debian one-level-down ? [13:07] learning bzr-builddeb is a long-standing TODO item of mine... [13:07] Keybuk: just add the --merge option. done. [13:07] Keybuk: right, I have .bzr/ in the top level dir [13:07] my current recipe is: [13:07] apt-get source upstart [13:07] cd upstart-0.3.9 [13:07] Keybuk: erm, s/right,/no/ [13:07] bzr checkout ~/co/upstart/debian [13:07] (common practice on alioth) [13:08] (for no readily apparent reason, if you checkout, it puts the .bzr into an existing working copy :p) [13:09] I'd rather just put the whole source in, but bzr doesn't like that much [13:10] in what way? [13:10] siretart: it thinks it doesn't have to care about timestamps [13:10] first time I tried it, it upset automake [13:10] interesting [13:11] I've proposed that bzr applies the same timestamp to all files modified by any operation [13:11] ie. after checkout, the entire tree would have the same timestamp [13:11] and after an update, only the changed files would have a new timestamp (and the same as each other) [13:14] ?! [13:14] now dpkg-buildpackage is randomly exiting on me [13:44] tkamppeter_: interesting, on a completely fresh Hardy install, I just ran hp-setup and my printer appears to work [13:44] it must be something left behind by it working on gutsy and before that's breaking it on hardy? [13:45] bryce: can you also make x11-common available in your people dir? (iirc dexconf is in there, at least not in the both .debs that are in your dir) [13:46] bryce: oh, and maybe you shouldn't publish the signed .changes file right next to the source package (that way everyone can upload that to ubuntu proper) [13:54] tkamppeter_: hah! it works right up to the point I try and print from another machine [13:58] sistpoty|work: ha, just upload it! :-) [13:59] tststs ;) [14:32] * Keybuk considers adding -Werror to package flags [14:32] it'd be kinda nice to not even allow the buildds to accept warnings [14:34] For sufficiently mind-numbing interpretations of "nice", yes. [14:34] This ought be selectable, as the number of new FTBFS cases in universe may be large [14:35] * soren thinks "large" is an understatement [14:36] Keybuk: You wouldn't happen to have any idea about the scale of the percentage of packages that would ftbfs with -Werror, would you? [14:36] soren: too many [14:37] I'm guessing at least 90%. [14:37] not that bad [14:37] Well, maybe 80%. Lots of code isn't actually C. [14:37] No? [14:37] rather 10% I would say [14:37] Because they don't actually have warning, or because they'd override -Werror? [14:37] but maybe I'm biaised and GNOME is much better than the rest of the world ;-) [14:37] That's still 1500 packages that need fixing: about the total size of maintained universe. [14:38] * ogra is on the 10% side [14:38] soren: I was just thinking of doing it for one package [14:38] soren: because they don't have warnings, I think many GNOME component have -Werror set when building from svn, they just turn it off for tarballs [14:39] Keybuk: Oh. :) [14:39] One package is a good idea :) [14:39] (Maybe even 10 or so) [14:40] seb128: I just picked two completely random gnome packages. Both have warnings (gnome-panel and libgnomeui). [14:41] soren: weird, the libgnomeui build on my disk has no warning [14:41] http://launchpadlibrarian.net/13285398/buildlog_ubuntu-hardy-i386.libgnomeui_2.22.1.0-0ubuntu1_FULLYBUILT.txt.gz [14:42] Not a lot, though. [14:42] weird === ember_ is now known as ember [15:03] calc: hm, no SRU bug in the OO.o changelog [15:03] calc: where is it tracked? [15:03] on very small fragments of post-it notes [15:04] hence the lack of numbers [15:06] Keybuk: hm, seems amd64 didn't like your PIC changes in upstart [15:07] pitti: indeed [15:07] I saw that [15:07] I'll let kees cry about that when he wakes up ;) [15:07] since it works fine on my amd64 here [15:16] <\sh> asac, bug #131793 -> why invalid when there is no real solution for gutsy users? :) [15:16] Launchpad bug 131793 in firefox "firefox crashed" [Medium,Invalid] https://launchpad.net/bugs/131793 [15:19] is it just me or there is somethign wrong with libglib2.0-data? [15:21] \sh: i did a batch closing a bunch of crashers that had no dupes and appeared to not be reproducible anymore [15:21] \sh: you can reopen it if oyu provide a backtrace [15:21] is it just gutsy? [15:21] <\sh> asac, hardies ff3 crashing too... [15:21] <\sh> just tested [15:22] => update bug ... attach backtrace, reopen, confirm :) [15:23] <\sh> asac, you want apport stuff or just plain gdb bt full? [15:24] its probably because spiegel wants you to buy the paper version :) [15:24] <\sh> ogra, lol [15:24] secret intrigue between ff and spiegel ;) [15:26]