[00:09] argggh === Ursinha is now known as Ursinha-lunch [00:09] Packaging branch version: 2.88dsf-13.10ubuntu5 [00:09] Packaging branch status: OUT-OF-DATE [00:09] >: === Ursinha-lunch is now known as Ursinha [00:16] jibel: ping [00:17] SpamapS: thanks - would you like me to go ahead and merge / upload that branch, provided I'm happy with it? [00:18] slangasek: I just finished testing it out on a local VM and an EC2 instance.. any objection to me just uploading it? [00:18] * SpamapS is fixing up the bzr tree .. I think [00:18] ScottK: what do you think about the 1.48 transition question? And how much time does it usually end up taking to manage one of these? [00:18] SpamapS: no objections provided it's correct ;) [00:19] slangasek: Its just that branch, merged into the actual current packaging branch, including the two uploads from the last 24 hours that the package importer failed on.. [00:19] I imported them w/ import-dsc .. is that sufficient? [00:19] SpamapS: I don't see it failed here [00:19] SpamapS: you might want to bzr pull [00:19] http://package-import.ubuntu.com/status/sysvinit.html#2011-11-30 14:42:44.885244 [00:19] oh, no, those are your commits ;) [00:19] yeah, that's perfect then [00:20] slangasek: I just fixed it already ;) [00:20] slangasek: like my namesake, Mr. Eastwood, I feel lucky.. ;) [00:20] heh [00:21] http://paste.ubuntu.com/768502/ [00:21] Thats the output of debdiff sysvinit_2.88dsf-13.10ubuntu7.dsc sysvinit_2.88dsf-13.10ubuntu8.dsc [00:21] slangasek: I'd also like to backport that debdiff to oneiric-proposed as I believe both bugs need fixing in oneiric [00:23] SpamapS: diff looks good to me, aside from my sudden itching to replace grep | sed with a better sed; and yes, I agree these look like SRU candidates [00:23] SpamapS: can I ask you an upstart question regarding when to start a certain app? [00:25] micahg: sure.. can I make a bet that it will be "start on runlevel [2345]" ? ;-) [00:25] SpamapS: no, it's about pppconfig starting on gdm [00:25] slangasek: ok, uploading in couple minutes [00:25] I think keybuk was trying to speed up boot, but I'm wondering if we need something like that anymore [00:26] we still care about boot speed [00:26] micahg: pppconfig would seem to me to be in the realm of NetworkManager.. or do I misunderstand what it does? [00:26] slangasek: obviously or I wouldn't be asking at all :) [00:26] heh :) [00:27] micahg: and we still define boot speed as "time to boot to an interactive desktop", so there's still value in deferred startup of non-essential services [00:27] SpamapS: well, I could defer it until the login manager, but it seems to be a console app, so that seems wrong [00:27] but I don't know anything about pppconfig in particular [00:27] slangasek: it seems to be a console app, so depending on the GUI to start seems wrong [00:28] but I'm not aware of any other way to defer startup [00:28] any ideas? [00:28] micahg: why do you want to defer its startup? [00:28] micahg: hmmm, it looks like this isn't even an upstart job? [00:28] SpamapS: I don't personally, the goal was to improve boot speed though [00:29] that's weird [00:29] are you trying to convert it to one? [00:29] slangasek: oh, is it not? [00:29] micahg: it's an init script with 'Required-Start: gdm' [00:29] that change is a no-op currently in Ubuntu [00:30] slangasek: is Required-Start ignored or specifically the gdm part? [00:30] micahg: required-start is hinting for insserv, which we don't use [00:31] oh wow, the pppconfig package contains no changelo [00:31] g [00:31] then I'm confused about bug 671308 [00:31] Launchpad bug 671308 in pppconfig (Ubuntu) "unnecessary init script dependency upon gdm" [Undecided,New] https://launchpad.net/bugs/671308 [00:31] that's special [00:31] micahg: we don't use insserv; Q-FUNK may be using it at his peril. :) [00:32] slangasek: since it's a diff with Debian, I can drop it then I guess, right :) [00:32] (in fact, I'm pretty sure I've seen other bugs on his systems caused by use of insserv) [00:32] sure [00:32] great, solves my problem [00:33] * micahg isn't sure why he assumed it was upstart [00:36] slangasek: at this point, would it make sense to make running insserv a noop/warning ? [00:36] SpamapS: yes, we very much need to [00:36] It really does seem to bugger the system [00:53] slangasek: before I remove a po update rule on clean, I just wanted to check, we don't need this for anything in main specifically, do we? [00:53] micahg: it could very well be related to language pack handling [00:54] it depends [00:54] :(, ok, I'll wait for pitti then [00:54] it's not a diff we have, but dropping it lowers our diff [00:57] * micahg is trying hard not to break precise :) [01:11] * SpamapS is appreciating micahg's trying [01:13] bdrung, tumbleweed, Laney: can i sponsor syncs with syncpackage yet? possibly from the dailies? === bladernr_afk is now known as bladernr_ === dendro-afk is now known as dendrobates === bladernr_ is now known as bladernr_afk [04:17] slangasek: I would wait and see how the binNMUs go in Debian. Most of the crufty won't build with a newer boost stuff is removed already, but each release is an adventure. === bladernr_afk is now known as bladernr_ [06:32] beuno: there hasn't been a written announcement, but it was discussed/decided at UDS and made it into the blogosphere; also, there is https://wiki.ubuntu.com/PlusOneMaintenanceTeam whose mission that is === allison_ is now known as wendar [06:32] micahg: what's up? [06:33] micahg: po update rules on clean are indeed evil and should be removed, yes === JackyAlcine is now known as VirgilHawkins [06:33] (evil because of pointless VCS noise) [06:33] erkh, the new vte is missing some more patches apparently [06:35] Orly? gnome-terminals now actually start for me :) [06:36] RAOF: bug 903401; dist-upgrade again [06:36] Launchpad bug 903401 in vte3 (Ubuntu Precise) "symbol lookup error: gnome-terminal: undefined symbol: vte_terminal_set_alternate_screen_scrol" [Critical,Fix released] https://launchpad.net/bugs/903401 [06:36] RAOF: hit me this morning as well, pretty big WTF [06:36] but apparently we are still missing the patch for unbreaking Alt [06:37] Ah, I might just have not noticed it. [06:37] or it is because we had a different workaround [06:41] pitti: Just update and all is fine, I got the same symbol look up error. [06:41] TheMuso: yes, so I discovered; I updated above bug accordingly [06:41] And alt stuff is still working ok for me. [06:41] TheMuso: yes, I remember that I had to update my weechat keybindings a few weeks ago, and now they are back to normal [06:41] pitti: thanks, I managed to drop 50 lines of po diff with a 2 line debian/rules change :) [06:41] apparently our workaoround was slightly broken, the current one is better [06:42] Yeah, I am still subscirbed to the bug, nothing committed upstream as of yet. [06:42] micahg: the only important thing is that the package either has, or even better builds a current *.pot file during package build [06:43] pitti: I don't think it does that, but it does seem to generate .mo files [06:44] that's fine of course; these are the ones that are actually being used at runtime [06:45] TheMuso: yeah, just lots of CCs :) (I'm subbed as well) [06:46] pitti: got a minute to discuss Firefox Lucid and Maverick rapid release WRT langpacks? [06:47] micahg: sure [06:47] pitti: so how much time do you need before the new packages are in -proposed (I guess before the langpacks are built) [06:50] micahg: for maverick, about 24 h; for lucid, I'd appreciate having a bit longer to get a current export (while we are at it anyway) [06:50] micahg: hm, but on second thought we should perhaps not update to a new LP export [06:50] pitti: ok, can you start an export and I'll make sure the packages are in -proposed by next Wed? [06:51] micahg: as I suppose we need to release _all_ of the langpacks in a timely manner, not just the ones we got verification for [06:51] pitti: ok, whichever you like, I just want to create a timetable of sorts for this [06:51] yes, I'd like a timetable, too [06:51] pitti: yes, that would be preferable [06:51] micahg: ok, would this work: [06:51] micahg: I'll see to preparing both by Friday, so that they can build in -proposed over the weekend? [06:52] micahg: it's about 1200 packages or so [06:52] pitti: you need firefox in there first, right? [06:52] micahg: if we want to avoid breaking translations for users of -proposed, then yes [06:53] micahg: if we want to do it over the week, we have to cross fingers that we don't get another haskell transition etc. in the meantime [06:53] the buildds are still catching up on those, although i386 is done [06:53] pitti: ok, weekend sounds fine, I'd like to have everything done before we all go on vacation (including a call for testing), that should give us ~2.5 weeks bake time in -proposed [06:54] micahg: you mean you can have firefox in -proposed by Friday, too? [06:54] that would be ideal buildd wise [06:54] pitti: wait, you want Firefox by Monday or Friday in -proposeD? [06:55] micahg: it doesn't matter much, but of course <= time of langpack upload would be nicer [06:55] I should be getting a final tag around Thursday, so it'll be tight [06:55] micahg: anyway, I'll prepare the packs by Friday, and then wait for your "go" [06:55] micahg: I can also do the actual upload/firefox accepting on Sat [06:56] pitti: sounds good thanks, I was actually going to pre-build everything in ubuntu-security-proposed if that's ok (we might need to pocket copy some of these packages come Jan 31) [06:56] micahg: if firefox is not in -proposed, I need a PPA with it in order to build the langpacks [06:56] u-s-p sounds fine [06:57] as the langpack builder needs to check which languages have a firefox-l10n-XX [06:57] either way, there should be a version of firefox in ubuntu-security-proposed by then, it might not be fina; [06:57] *fina; [06:57] *final [06:57] * micahg is using ubuntu-mozilla-security for the 3.6 updates :) [06:58] micahg: that's fine; as long as the set of translations doesn't change, it doesn't matter [06:59] micahg: and if it really does, I can just add the recommends: manually before upload [06:59] cjwatson: BTW, the problem with reiser4progs was that it ended up being uploaded as a native package at some point so syncpackage isn't smart enough to know it needs a fakesync since we had a mismatched tarball previously, I did a manual fakesync and LP seemed happy to accept [06:59] micahg: https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages ? [06:59] pitti: no, that'll have 3.6 [07:00] pitti: https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages [07:00] ack [07:01] pitti: let me check with chrisccoulson about that later, I know there are sometimes differences between the number of languages translated for beta and final [07:01] infinity: can we borrow some armhf builders to help out with the severe armel backlog? [07:02] pitti: there's an RT to restart the 2 stalled armel builders this morning [07:08] slangasek: uploaded unixodbc revert now (sorry, just fell to bed after last night's TB meeting) [07:08] slangasek: what is the newer version of libiodbc2? odbcinst1debian2? [07:09] i. e. unixodbc-dev? [07:15] pitti: one question, we need yasm 1.1.0 for Firefox 9, chrisccoulson prepared a yasm-1 package for lucid that's coinstallable with the current version, are we ok with that as well? [07:16] micahg: sure; it's hardly a question of "if", just "how" :) [07:16] micahg: parallel installable sounds fine, and it's not the kind of package which gets lots of security vulns === VirgilHawkins is now known as JackyAlcine [07:28] broder: yes, latest version in precise [07:28] just pass -s? [07:30] yes [07:30] tumbleweed: I almost got it to work on a fakesync, but syncpackage wasn't smart enough to look past the current record for a mismatched tarball [07:30] * micahg should probably file a bug [07:31] micahg: I don't quite understand that, so yes please :) [07:31] oh right [07:32] why would you need to? [07:32] tumbleweed: if for some silly reason people upload a subsequent Ubuntu revision as native [07:33] i didn't think people were that crazy :P [07:33] pitti: I already gave armel a few of the armhf builders. Should settle shortly. [07:33] infinity: ah, thanks [07:33] well, where "shortly" is 10 hours [07:34] Well, where "shortly" is .... Yeah. [07:34] tumbleweed: I'm still not sure if it happened in Debian or Ubuntu, but someone did it :) [07:34] armhf is going to finish earlier than armel :) [07:34] but I guess at some point armhf becomes the preferred arch anyway [07:34] pitti: The armhf estimate is a blatant lie. :P [07:34] yes, it was 16 hours Friday afternoon :) [07:35] infinity: ... based clearly on previous build times of packages on armhf? :-) [07:35] pitti: But once they both reach 0 (which should be before I leave on vacation), I'll redistrubite the CPU time more evenly between the two. [07:35] also hopefully at some point the old armel builders will go away and be replaced with the faster machines that hopefully have a chance of keeping up [07:36] micahg: The babbages will go away when we get more Pandas or QuickStarts or something to replace them. For now, we have to live with them a bit longer. [07:36] (The whole mess could be replaced with a single 4U box from HP/Calxeda...) [07:38] pitti: I'll give armel one more Panda for overnight and steal if back in the morning. === CrazyThinker` is now known as CrazyThinker [07:41] pitti: the langpacks don't build against anything (packagewise), do they? will we be able to pocket copy them to -security with Firefox 10? [07:41] micahg: yes [07:41] ok, hoping that was yes to the second question :) [07:43] micahg: whoops :) it is perfectly fine to copy them from -proposed to -updates, yes [07:43] it's just a bunch of data files [07:43] pitti: well, I'm wondering about -security :) [07:43] micahg: same thing [07:43] ok [08:03] morning, I'd like to disable the alsa-restore upstart script, so have commented out the start on line, but it still starts. Has my commenting out this line made it autostart or is something depending on it and starting it? [08:03] and any ideas how I could find out in the latter case what might be starting it? [08:04] * lardman goes to look at the upstart docs for the former case [08:07] I wonder if I'd be better just replacing the exec line's binary to do something that will work, like echo? [08:09] I don't see how it would get auto-started without the "start" line [08:10] lardman: I believe there's something like touch /etc/init/alsa-restore.conf.disable or similar [08:10] i. e. a tag file to ignore a job file, without having to touch the job file itself [08:10] I just don't remember the actual naming convention [08:26] pitti: there is no "newer version" of libiodbc2. There's libodbc1, which is the UnixODBC version instead of the iODBC version [08:26] pitti: so it's a question of consolidation [08:28] pitti: That PNG optimising business seems to take longer than the actual build in some/many cases. :/ [08:28] pitti: (See the mrpt build on kitalpha that's been in optimisation land all day) [08:28] pitti: Can we optimise the optimiser? :P [08:28] infinity: doko_ already pinged me about that yesterday; we disabled it now for -doc packages (although it's weird that armhf touches/builds -doc packages in the first place) [08:29] other than that, you could just disable it entirely with globally exporting NO_PNG_PKG_MANGLE=1 [08:29] Yeah, that's a non-option to do on the buildd as a whole. :P [08:29] but it still sounds wrong for non-i386 builds to build -doc .debs [08:29] pitti: When was the disabling of touching -doc bits? [08:30] infinity: around 20 hours ago [08:30] pitti: Ahh, kay, so after this build started. [08:30] https://launchpad.net/ubuntu/+source/pkgbinarymangler/110 [08:30] pitti: As for wrong or right, talk to the mrpt maintainer. [08:30] micahg: OK, I guess you're luckier than me as I think I'd tried a manual fakesync and failed :-) [08:30] Package: mrpt-doc [08:30] Architecture: all [08:30] *shrug* [08:30] pitti: It's not uncommon for people to build arch-indep stuff on all arches, and then only package it in binary-arch. [08:30] micahg: but that's great, thanks === smb` is now known as smb [08:31] infinity: it's nothing to do with building stuff [08:31] pitti: It's operating on ./usr/share/doc/mrpt-doc/html/inherit_graph_1030.png right now. [08:31] infinity: it's about calling dpkg-deb to really _build_ the -doc .deb [08:31] which is what triggers optipng [08:31] cjwatson: it took a lot of hacking to get the tarball to line up and make a source package [08:31] pitti: ... that can't possibly be happening here... [08:31] * infinity looks. [08:31] infinity: so I figure this build did call dh_builddeb on mrpt-doc? [08:32] cjwatson: and I just successfully sync'd a package through LP for someone else, so another thing to save you some time with :) [08:33] pitti: FFS. Yeah, it looks like mrpt has no binary-arch/-indep split. They're living a decade in the past. [08:33] will the buildd just discard any built _all debs? [08:34] pitti: And it took 6 hours (!) to build on amd64, most of which was PNG optimising. [08:34] trying to upload them will be ... not funny [08:34] infinity: pkgbinarymangler 110 will greatly help there [08:34] infinity: it might actually be faster to cancel the build and build it again? [08:34] pitti: Yeah, dpkg-buildpackages calls dpkg-genchanges -B, so any arch:all stuff just gets dumped. [08:34] buildpackage, even. [08:34] When installing dev packages using "apt-get builddep package", how do I remove them after finished build? [08:35] speakman: Copy and paste the apt output and feed it back to "apt-get purge"? :) [08:35] speakman: my approach is to copy&paste the "newly installed packages:" output from apt-get into a file [08:35] and then ... yes, what infinity says [08:35] oh, I'll just keep doing it that way :p [08:35] sudo dpkg -P $(< purge.txt) [08:35] speakman: you might want to use mk-build-deps -i -r instead so you get a single package to remove everything [08:36] micahg: didn't know of that [08:36] you can run it in a source dir to get the new build-deps as well [08:37] kees: FYI: https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview [08:37] pitti: Also, I'm giggling at anything that takes 7 hours to build on roseapple. [08:37] pitti: Is there a way you can leverage DEB_BUILD_OPTIONS="parallel=N" to parallelize your optipng stuff? [08:37] infinity: I had a build fail on roseapple and build fine a few minutes later on vernadsky, I think roseapple is troubled [08:38] infinity: yes, should be possible; care to file a bug for this? [08:38] infinity: (can't get to it right now, have lots of OMGurgent stuff on my plate today) [08:38] micahg: In this case, not troubled. Same build was over 6 hours on allspice. Both crazy fast machines. [08:38] micahg: hm, how do I install that .deb file using apt? dpkg won't download any dependencies by itself. [08:38] pitti: Yeah, my plate's similarly scary, plus a need for sleep. I'll keep these build records open as a reminder to care later. [08:38] micahg: yay. next thing is to implement mass-sync that way ... [08:40] speakman: if you run it with sudo, it should install it as well I thought [08:40] infinity: is "implement cancel button for builds" on that plate by any chance? :-) [08:40] micahg: sorry, adding --install to mk-build-deps did the trick :) Very nice thing! [08:41] pitti: PPAs have cancel buttons already :) [08:41] right, I know [08:41] speakman: -i is install [08:41] pitti: It is. [08:41] \o/ [08:41] micahg: And by "PPAs", you mean "Xen machines". [08:42] infinity: umm, yes, that's what I mean :) [08:42] micahg: And it's an awful hack. [08:42] (Since it generates no build log, etc) [08:42] infinity: same think with killing a native build [08:42] *thing [08:42] micahg: Err, lolwut? [08:43] micahg: If you kill a process in a native build, you definitely get a log. [08:43] infinity: ah, well, then someone should document how to do that for the people who do the killing :) [08:43] micahg: But, anyway. Going to fix it the way it should have been fixed years ago. [08:43] micahg: Then we can stop with the madness. [08:43] * micahg always gets the rug pulled out way of killing [08:45] Man, that ubiquity "checking if your hostname's taken" thing is great on a slow machine. [08:45] I get a couple of seconds of red "YOU CAN'T USE THAT HOSTNAME!!" before it realises "oh wait, that's us." [08:58] how do I tell debuild how many jobs it should pass to "make"? [08:58] oh, -j13... surprising.. sorry for not checking first :) [08:58] speakman: export DEB_BUILD_OPTIONS="parallel=3" (where "3" is the number you want) [08:59] (Oh, that would be if using dpkg-buildpackage, you're probably right about debuild wrapping it more pleasantly) [09:00] -j is a dpkg-buildpackage option, but i think it only parallelizes the debian/rules file, not the actual build [09:00] ok, I'll go with the env var option [09:00] And hey, look at that. Our first successful armhf+omap4 install from official images. [09:01] how do I do a complete "make distclean" with debuild? [09:01] armhf? [09:01] hard float? [09:01] speakman: debuild just calls debian/rules clean, it's up to the package if that does anything useful. [09:01] speakman: (And usually distclean isn't the right option in a package build...) [09:02] And yeah, armhf = hard float. [09:02] ok, I'm trying to compile unity-2d but it's stuck complaining about a binary file has changed [09:02] Because you changed a binary file? [09:02] dpkg-source: error: cannot represent change to unity-2d-4.12.0/data/gschemas.compiled: binary file contents changed [09:02] And you're trying to build a new source package? [09:03] infinity: nope, apt-get source libunity-2d-private0 and then trying to build it [09:03] If you're just building locally, you don't need to make a source package. [09:03] i think you can still just delete the file and it'll get cleaned up [09:03] -B or -b will prevent building source. [09:03] broder: That works if the goal was to build a source package, fails miserably if the goal was to build binaries. ;) [09:04] broder: Since the original won't "come back" until the new source package is unpacked again. [09:04] I interrupted the build at first time since it used only one of 12 cores. Now, dispite the env var "parallel=13" it still uses only one. [09:04] infinity: hmm..for some reason i had it in my head that dpkg-source will clean that up [09:04] speakman: The package itself may not be set up for parallel building. Can't magically change that. [09:04] broder: Err. It just ignores the deletion of the file. So, on the next unpack, it's there again. [09:05] debuild -j4 usually helps, though [09:05] broder: But it won't magically restore things to your working tree. [09:05] it exports MAKEVARS=-j4 or so which at least speeds up the compilation stage [09:05] infinity: ok. i believe you. certainly makes more sense than my theory [09:05] pitti: Eww, does it really? [09:05] pitti: It doesn't export DEB_BUILD_OPTIONS=parallel? [09:06] -jjobs Number of jobs allowed to be run simultaneously, equivalent to the make(1) option of the same [09:06] name. Will add itself to the MAKEFLAGS environment variable, which should cause all subsequent [09:06] make invocations to inherit the option. [09:06] pitti: Cause the whole reason for the latter was because universally forcing the former can break a lot of things. And having a dpkg-specific option meant people had to think about it. [09:06] infinity: yes, it also does that [09:06] pitti: Yeah, okay. That's just icky. [09:06] but it means that you can locally build all packages with make -j4 easily [09:07] but having the dh_* stuff done serially [09:09] wasn't there a helper script for adding new entries in changelog? === nhandler_ is now known as nhandler [09:10] speakman, dch? [09:13] Are there any "conventions" regarding which version to set when just testing patches? [09:14] * apw tends to append ~lpNNNNvN to the end of the 'next' version [09:15] where NNNN is revno and N is patch no? [09:15] lpNNN would imply a bug number, I'm guessing. [09:16] speakman: But for local testing, it really doesn't matter. It's local. :P [09:16] yeah bug number and build number sort of thing, just anything ~ so that when you get the next official package it gets replaced [09:16] speakman: I get such wonderful versions as 1.2.3-1arghfuckkill, and such. [09:16] lol :) [09:17] arghfuckkill >> arghfuck >> argh, obviously. The more iterations through a bug fix, the more entertaining my changelogs. [09:17] I usually use 1pitti1, 1pitti2, etc. until release, as "pitti" << "ubuntu" [09:17] or ubuntu3pitti1 etc. [09:18] just to stay in the habit of always staying below the next official version number [09:18] (In other words, it doesn't matter, just don't upload a local revision) [09:18] Really, the key here (and dch has options to do this automagically) is to make sure the target in the changelog isn't valid. Then the version doesn't matter. :P [09:18] (Common convention is "UNRELEASED") [09:19] do you use dch or do you edit manually? Do you add another entry for each re-build or just increment the latest one? [09:19] speakman: you don't need to touch it at all for local rebuilds [09:19] doesn't matter; adding another entry only matters if you're uploading it somewhere [09:19] just keep fixing stuff, then do the changelog [09:19] Both dch and manually. And what Colin said. [09:19] (I do my changelog as I go so I don't lose track of what I changed, but whatever) [09:20] oh - I could just use the entries already in there? [09:20] bzr FTW :) [09:20] speakman: backportpackage can help with a suffix for a local rebuild [09:20] pitti: In a sufficiently long hacking session, 'bzr diff' without a changelog can be opaque to me by the time I'm done. :P [09:20] infinity: right, I do commit for every separate fix [09:20] pitti: Unless I was committing every few tweaks, which is about the same documentation as a changelog. [09:21] but I tend to fix first, and then write teh changelog and commit [09:21] * apw wishes bzr had a good 'squash all these commits into the fix please' [09:21] "debcommit" also FTW [09:21] Yeah, debcommit's nice. [09:22] debcommit being completely VCS agnostic is even nicer. [09:23] micahg: reading the man of packportpackage, I don't really see how it will help me :/ [09:23] jibel: do you know why bug 902947 doesn't appear on http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-bugs.html ? [09:23] Launchpad bug 902947 in openthesaurus (Ubuntu Precise) "package mythes-de 20110119-2ubuntu2 failed to install/upgrade: update-openoffice-dicts: not found" [High,In progress] https://launchpad.net/bugs/902947 [09:23] jibel: the desktop bugs haven't changed in ages, I'm afraid something might be wrong there [09:23] speakman: ah, sorry, nevermind :) [09:23] * micahg needs sleep anyways [09:23] micahg: :D [09:23] pitti, lat update of this page "Tuesday, 06. December 2011 18:03 UTC " [09:23] pitti, I'll ping skaet [09:24] oh, that'd be it [09:24] s/lat/last [09:24] skaet: ^ is that cronned? [09:24] actually, it's under /kernel-bugs/ [09:24] apw: do you know who maintains this? ^ [09:25] pitti, almost cirtainly going to be one of bjf's, it has his options droppy [09:26] pitti, right it's bjf [09:26] no matter if both "parallel=13" and "-j13" is used, debuild still doesn't utilize more than one core :p [09:26] * apw wonders when the last update to launchpad was ... [09:26] speakman: debian/rules might overwrite MAKEVARS? [09:26] speakman, make can only parallelise things which are parallelisable too [09:26] speakman, if it has linear dependancy you lose [09:27] on the other hand; unity2d seems to be build with Qt, hence using qmake which maybe isn't handled correctly(?) by dpkg_buildpackage? [09:27] qmake might not look at MAKEVARS indeed [09:27] speakman: You're worrying far too much about it. The build would have been done by now if you didn't keep cancelling it. :P [09:28] YES!! The patch works perfectly! :) (bug 880698) [09:28] Launchpad bug 880698 in unity-2d "panel 2D uses wrong width on multi monitor setup (Xinerama)" [High,New] https://launchpad.net/bugs/880698 [09:28] so debian/rules needs to be fixed to respect parallel=n and translate that into whatever qmake understands [09:30] the debian/rules seems to use "default" or something. it "override_dh_install" and "override_dh_auto_test", else it's just passed with "%: \n dh $@ --with translations" [09:30] * speakman is probably too much of a newb to fix it. [09:31] 'man dh', follow references from there; a good habit is doing lots of reading :) [09:32] cjwatson: Oh, hey. Did you still have "check grub2 with gcc-4.6" on your TODO for the vaguely nearish future? [09:33] cjwatson: We're down to MySQL, grub, and u-boot being the only things keeping 4.5 in main. [09:33] yeah [09:33] cjwatson: I'm actually pretty used to RTFineM but I don't have the time right now :( [09:33] why u-boot ? [09:33] I'll give it a try this week [09:33] that should seriously be ported to 4.6, shouldnt it ? [09:34] ogra_: Cause bootloaders are stupid touchy about what gets spit out of the other end of a compiler, so it needs validation. jcrigby is on it. [09:34] ah,k [09:34] as long as he's aware all is fine :) [09:34] He is. [09:34] And I might spend some time with MySQL later. [09:34] GCC 4.6 did break GRUB Legacy until I worked around it, so it's not implausible [09:35] (had to build with -fno-reorder-functions to stop unlikely-to-be-executed functions being reordered before _start which is supposed to have a fixed entry point) [09:36] Another meta question; how do I tell I've tested a good patch on a bug? It's submitted in the comments but I don't see it's getting any attention. I've just changed the bug from "New" to "Confirmed" since we're at least two with different environments both having issues with the bug. [09:37] And looking at the original source, there's no way this bug won't affect anyone with >1 monitors with different resolutions. [09:38] In other words; what can I do to help get this patch applied officially and released? [09:38] bug 880698 if you missed it above [09:38] Launchpad bug 880698 in unity-2d "panel 2D uses wrong width on multi monitor setup (Xinerama)" [High,Confirmed] https://launchpad.net/bugs/880698 [09:40] debfx, ScottK, Riddell: so turns out bug 901638 is now a pretty major blocker [09:41] Launchpad bug 901638 in unixodbc (Ubuntu Precise) "Remove iodbc2 (causes upgrade failure from Oneiric to Precise)" [High,Triaged] https://launchpad.net/bugs/901638 [09:41] debfx, ScottK, Riddell: do you happen to know if it's possible to build soprano without ODBC support (virtuoso) or against unixodbc instead of the obsolete iodbc2? [09:41] debfx, ScottK, Riddell: failing that, I'm making some experiments now, but I'll need some hints how to test soprano [09:43] * pitti remembers the good old days when data was still stored in files and sqlite databases instead of DB frameworks on top of DB frameworks on top of MySQL [09:44] !info unity-2d [09:44] unity-2d (source: unity-2d): Unity interface for non-accelerated graphics cards. In component main, is optional. Version 4.12.0-0ubuntu1.1 (oneiric), package size 4 kB, installed size 140 kB [09:44] iceroot: are you looking at the bug/patch? [09:45] speakman: yes [09:45] pitti, mvo , FYI I modified the auto-upgrade-tester and the jenkins job to report results in junit format. https://jenkins.qa.ubuntu.com/job/precise-upgrade/ [09:45] * speakman wishes Launchpad was getting a code review system one day :) [09:45] speakman: ubuntu-devel-discuss@lists.ubuntu.com [09:45] now we have: green=pass, red=failed to upgrade, yellow=post-upgrade tests failed [09:45] iceroot: great! :) [09:45] speakman: that is the maintainer-adress of that package [09:45] jibel: ah, nice! less red there [09:46] speakman: i also added the tag "patch" to that bug [09:46] iceroot: that's a placeholder and unlikely to be useful [09:46] jibel: so main-all is broken by bug 901638, the rest are now conffile prompts? [09:46] Launchpad bug 901638 in unixodbc (Ubuntu Precise) "Remove iodbc2 (causes upgrade failure from Oneiric to Precise)" [High,Triaged] https://launchpad.net/bugs/901638 [09:46] iceroot: hm, ok? not really sure what that means (maintainer-address)... [09:46] speakman: olivier.tilloy@canonical.com [09:46] speakman: that is the unity-2d maintainer [09:46] ok, great :) [09:46] http://unity.ubuntu.com/getinvolved/ has a collection of links which might be more useful [09:47] assuming this is an upstream bug [09:47] jibel: test-xserver_test.py.FAIL sounds scary [09:47] cjwatson: i dont think that unity-bug are upstream-bugs :) [09:47] pitti, right. main-all-amd64 failed to build a base image and there is another bug on server which the upgrade tester doesn't show. There is a 2 minute timeout on network start after upgrade [09:47]