| SpamapS | argggh | 00:09 |
|---|---|---|
| === Ursinha is now known as Ursinha-lunch | ||
| SpamapS | Packaging branch version: 2.88dsf-13.10ubuntu5 | 00:09 |
| SpamapS | Packaging branch status: OUT-OF-DATE | 00:09 |
| SpamapS | >: | 00:09 |
| === Ursinha-lunch is now known as Ursinha | ||
| slangasek | jibel: ping | 00:16 |
| slangasek | SpamapS: thanks - would you like me to go ahead and merge / upload that branch, provided I'm happy with it? | 00:17 |
| SpamapS | 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 | |
| slangasek | 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 |
| slangasek | SpamapS: no objections provided it's correct ;) | 00:18 |
| SpamapS | 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 |
| SpamapS | I imported them w/ import-dsc .. is that sufficient? | 00:19 |
| slangasek | SpamapS: I don't see it failed here | 00:19 |
| slangasek | SpamapS: you might want to bzr pull | 00:19 |
| SpamapS | http://package-import.ubuntu.com/status/sysvinit.html#2011-11-30 14:42:44.885244 | 00:19 |
| slangasek | oh, no, those are your commits ;) | 00:19 |
| slangasek | yeah, that's perfect then | 00:19 |
| SpamapS | slangasek: I just fixed it already ;) | 00:20 |
| SpamapS | slangasek: like my namesake, Mr. Eastwood, I feel lucky.. ;) | 00:20 |
| slangasek | heh | 00:20 |
| SpamapS | http://paste.ubuntu.com/768502/ | 00:21 |
| SpamapS | Thats the output of debdiff sysvinit_2.88dsf-13.10ubuntu7.dsc sysvinit_2.88dsf-13.10ubuntu8.dsc | 00:21 |
| SpamapS | slangasek: I'd also like to backport that debdiff to oneiric-proposed as I believe both bugs need fixing in oneiric | 00:21 |
| slangasek | 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 |
| micahg | SpamapS: can I ask you an upstart question regarding when to start a certain app? | 00:23 |
| SpamapS | micahg: sure.. can I make a bet that it will be "start on runlevel [2345]" ? ;-) | 00:25 |
| micahg | SpamapS: no, it's about pppconfig starting on gdm | 00:25 |
| SpamapS | slangasek: ok, uploading in couple minutes | 00:25 |
| micahg | I think keybuk was trying to speed up boot, but I'm wondering if we need something like that anymore | 00:25 |
| slangasek | we still care about boot speed | 00:26 |
| SpamapS | micahg: pppconfig would seem to me to be in the realm of NetworkManager.. or do I misunderstand what it does? | 00:26 |
| micahg | slangasek: obviously or I wouldn't be asking at all :) | 00:26 |
| slangasek | heh :) | 00:26 |
| slangasek | 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 |
| micahg | SpamapS: well, I could defer it until the login manager, but it seems to be a console app, so that seems wrong | 00:27 |
| slangasek | but I don't know anything about pppconfig in particular | 00:27 |
| micahg | slangasek: it seems to be a console app, so depending on the GUI to start seems wrong | 00:27 |
| micahg | but I'm not aware of any other way to defer startup | 00:28 |
| micahg | any ideas? | 00:28 |
| SpamapS | micahg: why do you want to defer its startup? | 00:28 |
| slangasek | micahg: hmmm, it looks like this isn't even an upstart job? | 00:28 |
| micahg | SpamapS: I don't personally, the goal was to improve boot speed though | 00:28 |
| slangasek | that's weird | 00:29 |
| slangasek | are you trying to convert it to one? | 00:29 |
| micahg | slangasek: oh, is it not? | 00:29 |
| slangasek | micahg: it's an init script with 'Required-Start: gdm' | 00:29 |
| slangasek | that change is a no-op currently in Ubuntu | 00:29 |
| micahg | slangasek: is Required-Start ignored or specifically the gdm part? | 00:30 |
| slangasek | micahg: required-start is hinting for insserv, which we don't use | 00:30 |
| slangasek | oh wow, the pppconfig package contains no changelo | 00:31 |
| slangasek | g | 00:31 |
| micahg | then I'm confused about bug 671308 | 00:31 |
| ubottu | Launchpad bug 671308 in pppconfig (Ubuntu) "unnecessary init script dependency upon gdm" [Undecided,New] https://launchpad.net/bugs/671308 | 00:31 |
| slangasek | that's special | 00:31 |
| slangasek | micahg: we don't use insserv; Q-FUNK may be using it at his peril. :) | 00:31 |
| micahg | slangasek: since it's a diff with Debian, I can drop it then I guess, right :) | 00:32 |
| slangasek | (in fact, I'm pretty sure I've seen other bugs on his systems caused by use of insserv) | 00:32 |
| slangasek | sure | 00:32 |
| micahg | great, solves my problem | 00:32 |
| * micahg isn't sure why he assumed it was upstart | 00:33 | |
| SpamapS | slangasek: at this point, would it make sense to make running insserv a noop/warning ? | 00:36 |
| slangasek | SpamapS: yes, we very much need to | 00:36 |
| SpamapS | It really does seem to bugger the system | 00:36 |
| micahg | 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 |
| slangasek | micahg: it could very well be related to language pack handling | 00:53 |
| slangasek | it depends | 00:54 |
| micahg | :(, ok, I'll wait for pitti then | 00:54 |
| micahg | it's not a diff we have, but dropping it lowers our diff | 00:54 |
| * micahg is trying hard not to break precise :) | 00:57 | |
| * SpamapS is appreciating micahg's trying | 01:11 | |
| broder | bdrung, tumbleweed, Laney: can i sponsor syncs with syncpackage yet? possibly from the dailies? | 01:13 |
| === bladernr_afk is now known as bladernr_ | ||
| === dendro-afk is now known as dendrobates | ||
| === bladernr_ is now known as bladernr_afk | ||
| ScottK | 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. | 04:17 |
| === bladernr_afk is now known as bladernr_ | ||
| pitti | 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 | 06:32 |
| === allison_ is now known as wendar | ||
| pitti | micahg: what's up? | 06:32 |
| pitti | micahg: po update rules on clean are indeed evil and should be removed, yes | 06:33 |
| === JackyAlcine is now known as VirgilHawkins | ||
| pitti | (evil because of pointless VCS noise) | 06:33 |
| pitti | erkh, the new vte is missing some more patches apparently | 06:33 |
| RAOF | Orly? gnome-terminals now actually start for me :) | 06:35 |
| pitti | RAOF: bug 903401; dist-upgrade again | 06:36 |
| ubottu | 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 |
| pitti | RAOF: hit me this morning as well, pretty big WTF | 06:36 |
| pitti | but apparently we are still missing the patch for unbreaking Alt | 06:36 |
| RAOF | Ah, I might just have not noticed it. | 06:37 |
| pitti | or it is because we had a different workaround | 06:37 |
| TheMuso | pitti: Just update and all is fine, I got the same symbol look up error. | 06:41 |
| pitti | TheMuso: yes, so I discovered; I updated above bug accordingly | 06:41 |
| TheMuso | And alt stuff is still working ok for me. | 06:41 |
| pitti | 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 |
| micahg | pitti: thanks, I managed to drop 50 lines of po diff with a 2 line debian/rules change :) | 06:41 |
| pitti | apparently our workaoround was slightly broken, the current one is better | 06:41 |
| TheMuso | Yeah, I am still subscirbed to the bug, nothing committed upstream as of yet. | 06:42 |
| pitti | micahg: the only important thing is that the package either has, or even better builds a current *.pot file during package build | 06:42 |
| micahg | pitti: I don't think it does that, but it does seem to generate .mo files | 06:43 |
| pitti | that's fine of course; these are the ones that are actually being used at runtime | 06:44 |
| pitti | TheMuso: yeah, just lots of CCs :) (I'm subbed as well) | 06:45 |
| micahg | pitti: got a minute to discuss Firefox Lucid and Maverick rapid release WRT langpacks? | 06:46 |
| pitti | micahg: sure | 06:47 |
| micahg | pitti: so how much time do you need before the new packages are in -proposed (I guess before the langpacks are built) | 06:47 |
| pitti | 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 |
| pitti | micahg: hm, but on second thought we should perhaps not update to a new LP export | 06:50 |
| micahg | pitti: ok, can you start an export and I'll make sure the packages are in -proposed by next Wed? | 06:50 |
| pitti | 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 |
| micahg | pitti: ok, whichever you like, I just want to create a timetable of sorts for this | 06:51 |
| pitti | yes, I'd like a timetable, too | 06:51 |
| micahg | pitti: yes, that would be preferable | 06:51 |
| pitti | micahg: ok, would this work: | 06:51 |
| pitti | micahg: I'll see to preparing both by Friday, so that they can build in -proposed over the weekend? | 06:51 |
| pitti | micahg: it's about 1200 packages or so | 06:52 |
| micahg | pitti: you need firefox in there first, right? | 06:52 |
| pitti | micahg: if we want to avoid breaking translations for users of -proposed, then yes | 06:52 |
| pitti | 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 |
| pitti | the buildds are still catching up on those, although i386 is done | 06:53 |
| micahg | 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:53 |
| pitti | micahg: you mean you can have firefox in -proposed by Friday, too? | 06:54 |
| pitti | that would be ideal buildd wise | 06:54 |
| micahg | pitti: wait, you want Firefox by Monday or Friday in -proposeD? | 06:54 |
| pitti | micahg: it doesn't matter much, but of course <= time of langpack upload would be nicer | 06:55 |
| micahg | I should be getting a final tag around Thursday, so it'll be tight | 06:55 |
| pitti | micahg: anyway, I'll prepare the packs by Friday, and then wait for your "go" | 06:55 |
| pitti | micahg: I can also do the actual upload/firefox accepting on Sat | 06:55 |
| micahg | 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 |
| pitti | micahg: if firefox is not in -proposed, I need a PPA with it in order to build the langpacks | 06:56 |
| pitti | u-s-p sounds fine | 06:56 |
| pitti | as the langpack builder needs to check which languages have a firefox-l10n-XX | 06:57 |
| micahg | either way, there should be a version of firefox in ubuntu-security-proposed by then, it might not be fina; | 06:57 |
| micahg | *fina; | 06:57 |
| micahg | *final | 06:57 |
| * micahg is using ubuntu-mozilla-security for the 3.6 updates :) | 06:57 | |
| pitti | micahg: that's fine; as long as the set of translations doesn't change, it doesn't matter | 06:58 |
| pitti | micahg: and if it really does, I can just add the recommends: manually before upload | 06:59 |
| micahg | 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 |
| pitti | micahg: https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages ? | 06:59 |
| micahg | pitti: no, that'll have 3.6 | 06:59 |
| micahg | pitti: https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages | 07:00 |
| pitti | ack | 07:00 |
| micahg | 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 |
| pitti | infinity: can we borrow some armhf builders to help out with the severe armel backlog? | 07:01 |
| micahg | pitti: there's an RT to restart the 2 stalled armel builders this morning | 07:02 |
| pitti | slangasek: uploaded unixodbc revert now (sorry, just fell to bed after last night's TB meeting) | 07:08 |
| pitti | slangasek: what is the newer version of libiodbc2? odbcinst1debian2? | 07:08 |
| pitti | i. e. unixodbc-dev? | 07:09 |
| micahg | 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:15 |
| pitti | micahg: sure; it's hardly a question of "if", just "how" :) | 07:16 |
| pitti | micahg: parallel installable sounds fine, and it's not the kind of package which gets lots of security vulns | 07:16 |
| === VirgilHawkins is now known as JackyAlcine | ||
| tumbleweed | broder: yes, latest version in precise | 07:28 |
| broder | just pass -s? | 07:28 |
| tumbleweed | yes | 07:30 |
| micahg | 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:30 | |
| tumbleweed | micahg: I don't quite understand that, so yes please :) | 07:31 |
| tumbleweed | oh right | 07:31 |
| tumbleweed | why would you need to? | 07:32 |
| micahg | tumbleweed: if for some silly reason people upload a subsequent Ubuntu revision as native | 07:32 |
| tumbleweed | i didn't think people were that crazy :P | 07:33 |
| infinity | pitti: I already gave armel a few of the armhf builders. Should settle shortly. | 07:33 |
| pitti | infinity: ah, thanks | 07:33 |
| pitti | well, where "shortly" is 10 hours | 07:33 |
| infinity | Well, where "shortly" is .... Yeah. | 07:34 |
| micahg | tumbleweed: I'm still not sure if it happened in Debian or Ubuntu, but someone did it :) | 07:34 |
| pitti | armhf is going to finish earlier than armel :) | 07:34 |
| pitti | but I guess at some point armhf becomes the preferred arch anyway | 07:34 |
| infinity | pitti: The armhf estimate is a blatant lie. :P | 07:34 |
| micahg | yes, it was 16 hours Friday afternoon :) | 07:34 |
| pitti | infinity: ... based clearly on previous build times of packages on armhf? :-) | 07:35 |
| infinity | 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 |
| micahg | 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:35 |
| infinity | 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 |
| infinity | (The whole mess could be replaced with a single 4U box from HP/Calxeda...) | 07:36 |
| infinity | pitti: I'll give armel one more Panda for overnight and steal if back in the morning. | 07:38 |
| === CrazyThinker` is now known as CrazyThinker | ||
| micahg | 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 |
| pitti | micahg: yes | 07:41 |
| micahg | ok, hoping that was yes to the second question :) | 07:41 |
| pitti | micahg: whoops :) it is perfectly fine to copy them from -proposed to -updates, yes | 07:43 |
| pitti | it's just a bunch of data files | 07:43 |
| micahg | pitti: well, I'm wondering about -security :) | 07:43 |
| pitti | micahg: same thing | 07:43 |
| micahg | ok | 07:43 |
| lardman | 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 |
| lardman | and any ideas how I could find out in the latter case what might be starting it? | 08:03 |
| * lardman goes to look at the upstart docs for the former case | 08:04 | |
| lardman | I wonder if I'd be better just replacing the exec line's binary to do something that will work, like echo? | 08:07 |
| pitti | I don't see how it would get auto-started without the "start" line | 08:09 |
| pitti | lardman: I believe there's something like touch /etc/init/alsa-restore.conf.disable or similar | 08:10 |
| pitti | i. e. a tag file to ignore a job file, without having to touch the job file itself | 08:10 |
| pitti | I just don't remember the actual naming convention | 08:10 |
| slangasek | pitti: there is no "newer version" of libiodbc2. There's libodbc1, which is the UnixODBC version instead of the iODBC version | 08:26 |
| slangasek | pitti: so it's a question of consolidation | 08:26 |
| infinity | pitti: That PNG optimising business seems to take longer than the actual build in some/many cases. :/ | 08:28 |
| infinity | pitti: (See the mrpt build on kitalpha that's been in optimisation land all day) | 08:28 |
| infinity | pitti: Can we optimise the optimiser? :P | 08:28 |
| pitti | 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:28 |
| pitti | other than that, you could just disable it entirely with globally exporting NO_PNG_PKG_MANGLE=1 | 08:29 |
| infinity | Yeah, that's a non-option to do on the buildd as a whole. :P | 08:29 |
| pitti | but it still sounds wrong for non-i386 builds to build -doc .debs | 08:29 |
| infinity | pitti: When was the disabling of touching -doc bits? | 08:29 |
| pitti | infinity: around 20 hours ago | 08:30 |
| infinity | pitti: Ahh, kay, so after this build started. | 08:30 |
| pitti | https://launchpad.net/ubuntu/+source/pkgbinarymangler/110 | 08:30 |
| infinity | pitti: As for wrong or right, talk to the mrpt maintainer. | 08:30 |
| cjwatson | micahg: OK, I guess you're luckier than me as I think I'd tried a manual fakesync and failed :-) | 08:30 |
| pitti | Package: mrpt-doc | 08:30 |
| pitti | Architecture: all | 08:30 |
| pitti | *shrug* | 08:30 |
| infinity | 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 |
| cjwatson | micahg: but that's great, thanks | 08:30 |
| === smb` is now known as smb | ||
| pitti | infinity: it's nothing to do with building stuff | 08:31 |
| infinity | pitti: It's operating on ./usr/share/doc/mrpt-doc/html/inherit_graph_1030.png right now. | 08:31 |
| pitti | infinity: it's about calling dpkg-deb to really _build_ the -doc .deb | 08:31 |
| pitti | which is what triggers optipng | 08:31 |
| micahg | cjwatson: it took a lot of hacking to get the tarball to line up and make a source package | 08:31 |
| infinity | pitti: ... that can't possibly be happening here... | 08:31 |
| * infinity looks. | 08:31 | |
| pitti | infinity: so I figure this build did call dh_builddeb on mrpt-doc? | 08:31 |
| micahg | cjwatson: and I just successfully sync'd a package through LP for someone else, so another thing to save you some time with :) | 08:32 |
| infinity | pitti: FFS. Yeah, it looks like mrpt has no binary-arch/-indep split. They're living a decade in the past. | 08:33 |
| pitti | will the buildd just discard any built _all debs? | 08:33 |
| infinity | pitti: And it took 6 hours (!) to build on amd64, most of which was PNG optimising. | 08:34 |
| pitti | trying to upload them will be ... not funny | 08:34 |
| pitti | infinity: pkgbinarymangler 110 will greatly help there | 08:34 |
| pitti | infinity: it might actually be faster to cancel the build and build it again? | 08:34 |
| infinity | pitti: Yeah, dpkg-buildpackages calls dpkg-genchanges -B, so any arch:all stuff just gets dumped. | 08:34 |
| infinity | buildpackage, even. | 08:34 |
| speakman | When installing dev packages using "apt-get builddep package", how do I remove them after finished build? | 08:34 |
| infinity | speakman: Copy and paste the apt output and feed it back to "apt-get purge"? :) | 08:35 |
| pitti | speakman: my approach is to copy&paste the "newly installed packages:" output from apt-get into a file | 08:35 |
| pitti | and then ... yes, what infinity says | 08:35 |
| speakman | oh, I'll just keep doing it that way :p | 08:35 |
| pitti | sudo dpkg -P $(< purge.txt) | 08:35 |
| micahg | speakman: you might want to use mk-build-deps -i -r instead so you get a single package to remove everything | 08:35 |
| speakman | micahg: didn't know of that | 08:36 |
| micahg | you can run it in a source dir to get the new build-deps as well | 08:36 |
| pitti | kees: FYI: https://wiki.ubuntu.com/TechnicalBoard/BrainstormReview | 08:37 |
| infinity | pitti: Also, I'm giggling at anything that takes 7 hours to build on roseapple. | 08:37 |
| infinity | pitti: Is there a way you can leverage DEB_BUILD_OPTIONS="parallel=N" to parallelize your optipng stuff? | 08:37 |
| micahg | infinity: I had a build fail on roseapple and build fine a few minutes later on vernadsky, I think roseapple is troubled | 08:37 |
| pitti | infinity: yes, should be possible; care to file a bug for this? | 08:38 |
| pitti | infinity: (can't get to it right now, have lots of OMGurgent stuff on my plate today) | 08:38 |
| infinity | micahg: In this case, not troubled. Same build was over 6 hours on allspice. Both crazy fast machines. | 08:38 |
| speakman | micahg: hm, how do I install that .deb file using apt? dpkg won't download any dependencies by itself. | 08:38 |
| infinity | 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 |
| cjwatson | micahg: yay. next thing is to implement mass-sync that way ... | 08:38 |
| micahg | speakman: if you run it with sudo, it should install it as well I thought | 08:40 |
| pitti | infinity: is "implement cancel button for builds" on that plate by any chance? :-) | 08:40 |
| speakman | micahg: sorry, adding --install to mk-build-deps did the trick :) Very nice thing! | 08:40 |
| micahg | pitti: PPAs have cancel buttons already :) | 08:41 |
| pitti | right, I know | 08:41 |
| micahg | speakman: -i is install | 08:41 |
| infinity | pitti: It is. | 08:41 |
| pitti | \o/ | 08:41 |
| infinity | micahg: And by "PPAs", you mean "Xen machines". | 08:41 |
| micahg | infinity: umm, yes, that's what I mean :) | 08:42 |
| infinity | micahg: And it's an awful hack. | 08:42 |
| infinity | (Since it generates no build log, etc) | 08:42 |
| micahg | infinity: same think with killing a native build | 08:42 |
| micahg | *thing | 08:42 |
| infinity | micahg: Err, lolwut? | 08:42 |
| infinity | micahg: If you kill a process in a native build, you definitely get a log. | 08:43 |
| micahg | infinity: ah, well, then someone should document how to do that for the people who do the killing :) | 08:43 |
| infinity | micahg: But, anyway. Going to fix it the way it should have been fixed years ago. | 08:43 |
| infinity | micahg: Then we can stop with the madness. | 08:43 |
| * micahg always gets the rug pulled out way of killing | 08:43 | |
| infinity | Man, that ubiquity "checking if your hostname's taken" thing is great on a slow machine. | 08:45 |
| infinity | I get a couple of seconds of red "YOU CAN'T USE THAT HOSTNAME!!" before it realises "oh wait, that's us." | 08:45 |
| speakman | how do I tell debuild how many jobs it should pass to "make"? | 08:58 |
| speakman | oh, -j13... surprising.. sorry for not checking first :) | 08:58 |
| infinity | speakman: export DEB_BUILD_OPTIONS="parallel=3" (where "3" is the number you want) | 08:58 |
| infinity | (Oh, that would be if using dpkg-buildpackage, you're probably right about debuild wrapping it more pleasantly) | 08:59 |
| broder | -j is a dpkg-buildpackage option, but i think it only parallelizes the debian/rules file, not the actual build | 09:00 |
| speakman | ok, I'll go with the env var option | 09:00 |
| infinity | And hey, look at that. Our first successful armhf+omap4 install from official images. | 09:00 |
| speakman | how do I do a complete "make distclean" with debuild? | 09:01 |
| speakman | armhf? | 09:01 |
| speakman | hard float? | 09:01 |
| infinity | speakman: debuild just calls debian/rules clean, it's up to the package if that does anything useful. | 09:01 |
| infinity | speakman: (And usually distclean isn't the right option in a package build...) | 09:01 |
| infinity | And yeah, armhf = hard float. | 09:02 |
| speakman | ok, I'm trying to compile unity-2d but it's stuck complaining about a binary file has changed | 09:02 |
| infinity | Because you changed a binary file? | 09:02 |
| speakman | dpkg-source: error: cannot represent change to unity-2d-4.12.0/data/gschemas.compiled: binary file contents changed | 09:02 |
| infinity | And you're trying to build a new source package? | 09:02 |
| speakman | infinity: nope, apt-get source libunity-2d-private0 and then trying to build it | 09:03 |
| infinity | If you're just building locally, you don't need to make a source package. | 09:03 |
| broder | i think you can still just delete the file and it'll get cleaned up | 09:03 |
| infinity | -B or -b will prevent building source. | 09:03 |
| infinity | broder: That works if the goal was to build a source package, fails miserably if the goal was to build binaries. ;) | 09:03 |
| infinity | broder: Since the original won't "come back" until the new source package is unpacked again. | 09:04 |
| speakman | 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 |
| broder | infinity: hmm..for some reason i had it in my head that dpkg-source will clean that up | 09:04 |
| infinity | speakman: The package itself may not be set up for parallel building. Can't magically change that. | 09:04 |
| infinity | broder: Err. It just ignores the deletion of the file. So, on the next unpack, it's there again. | 09:04 |
| pitti | debuild -j4 usually helps, though | 09:05 |
| infinity | broder: But it won't magically restore things to your working tree. | 09:05 |
| pitti | it exports MAKEVARS=-j4 or so which at least speeds up the compilation stage | 09:05 |
| broder | infinity: ok. i believe you. certainly makes more sense than my theory | 09:05 |
| infinity | pitti: Eww, does it really? | 09:05 |
| infinity | pitti: It doesn't export DEB_BUILD_OPTIONS=parallel? | 09:05 |
| pitti | -jjobs Number of jobs allowed to be run simultaneously, equivalent to the make(1) option of the same | 09:06 |
| pitti | name. Will add itself to the MAKEFLAGS environment variable, which should cause all subsequent | 09:06 |
| pitti | make invocations to inherit the option. | 09:06 |
| infinity | 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 |
| pitti | infinity: yes, it also does that | 09:06 |
| infinity | pitti: Yeah, okay. That's just icky. | 09:06 |
| pitti | but it means that you can locally build all packages with make -j4 easily | 09:06 |
| pitti | but having the dh_* stuff done serially | 09:07 |
| speakman | wasn't there a helper script for adding new entries in changelog? | 09:09 |
| === nhandler_ is now known as nhandler | ||
| seb128 | speakman, dch? | 09:10 |
| speakman | Are there any "conventions" regarding which version to set when just testing patches? | 09:13 |
| * apw tends to append ~lpNNNNvN to the end of the 'next' version | 09:14 | |
| speakman | where NNNN is revno and N is patch no? | 09:15 |
| infinity | lpNNN would imply a bug number, I'm guessing. | 09:15 |
| infinity | speakman: But for local testing, it really doesn't matter. It's local. :P | 09:16 |
| apw | 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 |
| infinity | speakman: I get such wonderful versions as 1.2.3-1arghfuckkill, and such. | 09:16 |
| speakman | lol :) | 09:16 |
| infinity | arghfuckkill >> arghfuck >> argh, obviously. The more iterations through a bug fix, the more entertaining my changelogs. | 09:17 |
| pitti | I usually use 1pitti1, 1pitti2, etc. until release, as "pitti" << "ubuntu" | 09:17 |
| pitti | or ubuntu3pitti1 etc. | 09:17 |
| pitti | just to stay in the habit of always staying below the next official version number | 09:18 |
| infinity | (In other words, it doesn't matter, just don't upload a local revision) | 09:18 |
| infinity | 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 |
| infinity | (Common convention is "UNRELEASED") | 09:18 |
| speakman | 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 |
| pitti | speakman: you don't need to touch it at all for local rebuilds | 09:19 |
| cjwatson | doesn't matter; adding another entry only matters if you're uploading it somewhere | 09:19 |
| pitti | just keep fixing stuff, then do the changelog | 09:19 |
| infinity | Both dch and manually. And what Colin said. | 09:19 |
| infinity | (I do my changelog as I go so I don't lose track of what I changed, but whatever) | 09:19 |
| speakman | oh - I could just use the entries already in there? | 09:20 |
| pitti | bzr FTW :) | 09:20 |
| micahg | speakman: backportpackage can help with a suffix for a local rebuild | 09:20 |
| infinity | 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 |
| pitti | infinity: right, I do commit for every separate fix | 09:20 |
| infinity | pitti: Unless I was committing every few tweaks, which is about the same documentation as a changelog. | 09:20 |
| pitti | 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 | |
| pitti | "debcommit" also FTW | 09:21 |
| infinity | Yeah, debcommit's nice. | 09:21 |
| infinity | debcommit being completely VCS agnostic is even nicer. | 09:22 |
| speakman | micahg: reading the man of packportpackage, I don't really see how it will help me :/ | 09:23 |
| pitti | 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 |
| ubottu | 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 |
| pitti | jibel: the desktop bugs haven't changed in ages, I'm afraid something might be wrong there | 09:23 |
| micahg | speakman: ah, sorry, nevermind :) | 09:23 |
| * micahg needs sleep anyways | 09:23 | |
| speakman | micahg: :D | 09:23 |
| jibel | pitti, lat update of this page "Tuesday, 06. December 2011 18:03 UTC " | 09:23 |
| jibel | pitti, I'll ping skaet | 09:23 |
| pitti | oh, that'd be it | 09:24 |
| jibel | s/lat/last | 09:24 |
| pitti | skaet: ^ is that cronned? | 09:24 |
| pitti | actually, it's under /kernel-bugs/ | 09:24 |
| pitti | apw: do you know who maintains this? ^ | 09:24 |
| apw | pitti, almost cirtainly going to be one of bjf's, it has his options droppy | 09:25 |
| jibel | pitti, right it's bjf | 09:26 |
| speakman | 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 | |
| pitti | speakman: debian/rules might overwrite MAKEVARS? | 09:26 |
| apw | speakman, make can only parallelise things which are parallelisable too | 09:26 |
| apw | speakman, if it has linear dependancy you lose | 09:26 |
| speakman | 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 |
| pitti | qmake might not look at MAKEVARS indeed | 09:27 |
| infinity | 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:27 |
| speakman | YES!! The patch works perfectly! :) (bug 880698) | 09:28 |
| ubottu | 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 |
| pitti | so debian/rules needs to be fixed to respect parallel=n and translate that into whatever qmake understands | 09:28 |
| speakman | 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:30 | |
| cjwatson | 'man dh', follow references from there; a good habit is doing lots of reading :) | 09:31 |
| infinity | cjwatson: Oh, hey. Did you still have "check grub2 with gcc-4.6" on your TODO for the vaguely nearish future? | 09:32 |
| infinity | cjwatson: We're down to MySQL, grub, and u-boot being the only things keeping 4.5 in main. | 09:33 |
| cjwatson | yeah | 09:33 |
| speakman | cjwatson: I'm actually pretty used to RTFineM but I don't have the time right now :( | 09:33 |
| ogra_ | why u-boot ? | 09:33 |
| cjwatson | I'll give it a try this week | 09:33 |
| ogra_ | that should seriously be ported to 4.6, shouldnt it ? | 09:33 |
| infinity | 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 |
| ogra_ | ah,k | 09:34 |
| ogra_ | as long as he's aware all is fine :) | 09:34 |
| infinity | He is. | 09:34 |
| infinity | And I might spend some time with MySQL later. | 09:34 |
| cjwatson | GCC 4.6 did break GRUB Legacy until I worked around it, so it's not implausible | 09:34 |
| cjwatson | (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:35 |
| speakman | 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:36 |
| speakman | And looking at the original source, there's no way this bug won't affect anyone with >1 monitors with different resolutions. | 09:37 |
| speakman | In other words; what can I do to help get this patch applied officially and released? | 09:38 |
| speakman | bug 880698 if you missed it above | 09:38 |
| ubottu | Launchpad bug 880698 in unity-2d "panel 2D uses wrong width on multi monitor setup (Xinerama)" [High,Confirmed] https://launchpad.net/bugs/880698 | 09:38 |
| pitti | debfx, ScottK, Riddell: so turns out bug 901638 is now a pretty major blocker | 09:40 |
| ubottu | 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 |
| pitti | 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 |
| pitti | debfx, ScottK, Riddell: failing that, I'm making some experiments now, but I'll need some hints how to test soprano | 09:41 |
| * 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:43 | |
| iceroot | !info unity-2d | 09:44 |
| ubottu | 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 |
| speakman | iceroot: are you looking at the bug/patch? | 09:44 |
| iceroot | speakman: yes | 09:45 |
| jibel | 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 | |
| iceroot | speakman: ubuntu-devel-discuss@lists.ubuntu.com | 09:45 |
| jibel | now we have: green=pass, red=failed to upgrade, yellow=post-upgrade tests failed | 09:45 |
| speakman | iceroot: great! :) | 09:45 |
| iceroot | speakman: that is the maintainer-adress of that package | 09:45 |
| pitti | jibel: ah, nice! less red there | 09:45 |
| iceroot | speakman: i also added the tag "patch" to that bug | 09:46 |
| cjwatson | iceroot: that's a placeholder and unlikely to be useful | 09:46 |
| pitti | jibel: so main-all is broken by bug 901638, the rest are now conffile prompts? | 09:46 |
| ubottu | 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 |
| speakman | iceroot: hm, ok? not really sure what that means (maintainer-address)... | 09:46 |
| iceroot | speakman: olivier.tilloy@canonical.com | 09:46 |
| iceroot | speakman: that is the unity-2d maintainer | 09:46 |
| speakman | ok, great :) | 09:46 |
| cjwatson | http://unity.ubuntu.com/getinvolved/ has a collection of links which might be more useful | 09:46 |
| cjwatson | assuming this is an upstream bug | 09:47 |
| pitti | jibel: test-xserver_test.py.FAIL sounds scary | 09:47 |
| iceroot | cjwatson: i dont think that unity-bug are upstream-bugs :) | 09:47 |
| jibel | 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 |
| cjwatson | iceroot: upstream for unity | 09:47 |
| speakman | cjwatson: thanks! :) | 09:47 |
| cjwatson | iceroot: as in the unity developers | 09:48 |
| iceroot | cjwatson: hm ok | 09:48 |
| jibel | pitti, I'll look at the "xserver failed to start" error today | 09:48 |
| iceroot | speakman: i would suggest to contact olivier.tilloy@canonical.com by putting him on cc on launchpad or write directly a mail with an info about that bug and patch | 09:48 |
| * speakman just found Canonical looking for passionate C/C++ coder. Maybe one should do this on full time... :P | 09:49 | |
| pitti | jibel: I suppose you have access to the machine after the upgrade is done, and we can collect package status and Xorg.log? | 09:49 |
| speakman | iceroot: great, I fix that! | 09:49 |
| jibel | pitti, yes, we keep the upgraded image until next run. | 09:49 |
| mvo | jibel: yeah, thanks a bunch for this! I saw the merge request, but did not manage yet to process it | 09:51 |
| * mvo hugs jibel - the new page looks *much* better | 09:51 | |
| * jibel hugs mvo back | 09:53 | |
| jibel | mvo, did you had a fix or know how to fix main-all-amd64 ? basically it installs both amd64 and i386 on the image. Is it just a matter of blacklisting the right packages ? | 09:54 |
| === asac is now known as asacengineer | ||
| === asacengineer is now known as asac | ||
| mvo | jibel: I think I fixed this in the install_all.py - does the server carry the latest u-m bzr revision? | 09:56 |
| pitti | jibel: https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade/ doesn't have main-all-amd64? | 09:56 |
| pitti | jibel: is that bug 850264, or somethign different? | 09:56 |
| ubottu | Launchpad bug 850264 in apt (Ubuntu Precise) "given a foreign architecture of i386 on amd64 machine, and an outdated libc, apt tries to remove libc-bin" [High,Triaged] https://launchpad.net/bugs/850264 | 09:56 |
| pitti | mvo: ^ speaking of which, do you need a hand with backporting a fix there? | 09:56 |
| apw | pitti, does that report look any better | 09:58 |
| pitti | apw: yay, thanks! | 09:59 |
| pitti | apw: what was it? | 09:59 |
| iceroot | speakman: great | 09:59 |
| jibel | pitti, I removed the profile because it runs for hours and fails | 09:59 |
| jibel | mvo, yes it does, I'll double-check | 09:59 |
| apw | pitti, there is some deeper bug in the the report that some cached data is missing a field, i've made it ignore that for now, brad will have to figure out how it got in there; looks impossible | 09:59 |
| jibel | pitti, it's different. the test tools doesn't even build the base image | 10:00 |
| mvo | pitti: unfortunately the changes are pretty invasive, but I expect a new apt in precise soon | 10:02 |
| apw | pitti, are you aware of the per team breakout on that page, for example: http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-mgr-p-tracking-desktop-bugs.html | 10:02 |
| pitti | apw: not of that html page, but as the main page is already sectioned, that's good enough | 10:02 |
| speakman | pitti: apw: Just adding "dh $@ --parallel" to the "%"-rule with do the trick... :) | 10:09 |
| pitti | speakman: but not to convince cmake, I suppose? that'll only run the dh_* stuff in parallel? | 10:09 |
| pitti | debfx, ScottK, Riddell: hm, soprano FTBFSes even with iodbc ATM | 10:10 |
| * pitti looks into this | 10:10 | |
| speakman | pitti: It's compiling at 100% CPU ;) | 10:10 |
| pitti | nice | 10:11 |
| speakman | It's running dh_* stuff serially afaict. Will it even work doing it in parallel? | 10:11 |
| speakman | pitti: However; can I make a "commit" with this change and push it to my local lp repo and then post a merge request? | 10:12 |
| pitti | sure | 10:14 |
| pitti | ScottK, Riddell, debfx: filed as bug 903638 FYI | 10:19 |
| ubottu | Launchpad bug 903638 in soprano (Ubuntu Precise) "FTBFS: cannot find backends/sesame2/openrdf-sesame-2.2.4-onejar.jar" [High,Triaged] https://launchpad.net/bugs/903638 | 10:20 |
| pitti | not sure how to fix that | 10:20 |
| debfx | pitti: probably by merging http://packages.qa.debian.org/s/soprano/news/20111204T164452Z.html | 10:22 |
| debfx | pitti: virtuoso is the backend that KDE actually uses so I don't think we can drop it | 10:23 |
| pitti | * Pass -DSOPRANO_DISABLE_SESAME2_BACKEND=ON to cmake. (Closes: #649443) | 10:23 |
| pitti | ah, that sounds promising | 10:23 |
| pitti | debfx: ok | 10:23 |
| pitti | debfx: that upstream bug report was from 2009, so it might be worth another try to build it against unixodbc and test it, I think | 10:24 |
| pitti | debfx: thanks, that helped; I'll commit that to ubuntu:soprano | 10:26 |
| === jibel_ is now known as jibel | ||
| pitti | debfx: I have a test package now which builds soprano against unixodbc; do you know how to test soprano? | 10:48 |
| pitti | debfx: it's building in my PPA now | 10:48 |
| === PaulW2U_ is now known as PaulW2U | ||
| === bladernr_ is now known as bladernr_afk | ||
| debfx | pitti: not really. maybe enable indexing and see if it throws any error messages. | 10:57 |
| pitti | debfx: so that thing is used for indexing files and finding contents? | 11:00 |
| * pitti has absolutely no idea about what virtuoso, soprano, or nepomuk are, sorry | 11:00 | |
| debfx | pitti: yes, it's used for indexing and tagging files/mails | 11:03 |
| debfx | though Riddell is probably better qualified to answer nepomuk questions | 11:05 |
| debfx | nepomuk is the first thing I turn off on a new kubuntu installation :) | 11:06 |
| Riddell | pitti: where is the build failure for soprano? | 11:12 |
| pitti | Riddell: that's already fixed; well, it's "in precise" | 11:12 |
| pitti | Riddell: but I committed the patch to lp:ubuntu/soprano | 11:12 |
| pitti | s/patch/fix/ (it's just a debian/rules option, mirroring what Debian did) | 11:13 |
| pitti | Riddell: I'm currently downloading teh current kubuntu desktop to give some testing to soprano in https://launchpad.net/~pitti/+archive/ppa, but I'd appreciate some guidance there | 11:13 |
| pitti | Riddell: in short, we need to drop the old libiodbc and move to unixodbc | 11:13 |
| pitti | in theory these are just implementations for the very same thing, but iodbc is dead and unixodbc is maintained upstream | 11:14 |
| pitti | Riddell: so, I have kubuntu live system running in kvm now; I guess I need to enable indexing now? (first want to test with the current soprano) | 11:17 |
| Riddell | pitti: it's disabled by default on a live system, I think that enabling it will work but not sure | 11:18 |
| pitti | Riddell: is that "desktop search" in control center? it says nepomuk is active, but strigi disabled | 11:19 |
| Riddell | right, so that should be fine | 11:19 |
| Riddell | tagging and rating in dolphin should work | 11:19 |
| pitti | Riddell: I created a hello.txt, but I don't see how to tag/rate it | 11:20 |
| Riddell | pitti: do you have /usr/share/autostart/nepomukserver.desktop ? | 11:20 |
| pitti | no, just nepomukcontroller.desktop | 11:21 |
| Riddell | so it's disabled for the live session | 11:21 |
| pitti | "nepomukcontroller" is running | 11:21 |
| Riddell | maybe try running nepomukserver | 11:21 |
| === _salem is now known as salem_ | ||
| jibel | pitti, mvo the test-xserver_test.py.FAIL error is a false positive | 11:22 |
| pitti | jibel: *phew* | 11:22 |
| jibel | pitti, the test starts too fast | 11:22 |
| jibel | pitti, and X is not started when it runs | 11:22 |
| pitti | Riddell: hm, the "nepomukcontroller" package isn't installed, otherwise I don't find nepomukserver anywhere | 11:22 |
| Riddell | pitti: you should have kde-runtime: /usr/bin/nepomukserver ? | 11:24 |
| pitti | Riddell: I have the package isntalled, but it's not in there | 11:25 |
| pitti | oh, ignore me | 11:26 |
| pitti | apparently I typoed | 11:26 |
| mvo | jibel: aha, thnaks for this, I will add a delay then - or did you do that already? | 11:26 |
| pitti | Riddell: ok, tagging works now, thanks; testing that with my soprano package now | 11:27 |
| jibel | mvo, go for it. I think we also need another post-upgrade test if the upgraded system fails to start in less than 60s (TBD). That would catch services timeout. | 11:29 |
| pitti | Riddell: ok, so that doesn't work :( | 11:35 |
| mvo | jibel: I made it wait up to 100s now | 11:35 |
| pitti | Riddell: I updated the bug with the error message | 11:36 |
| debfx | I wrote a script for kubuntu that shows the package differences between the image of the last release and the current daily image: http://felix.fobos.de/kubuntu/kubuntu-precise-cd-amd64-diff.htm | 11:38 |
| debfx | it might be interesting for other flavors as well so maybe it should be moved to ubuntuwire? who should I talk to about that? | 11:39 |
| pitti | jibel: so, I'm afraid that main-all failure will stay around for a bit; I'm out of ideas how else to fix it, the soprano package isn't that easy to convert to unixodbc apparently | 11:39 |
| pitti | Daviey: would it be ok to comment out keystone from the server seeds until bug 881464 and its dependencies are sorted out? | 11:47 |
| ubottu | Launchpad bug 881464 in keystone (Ubuntu) "[MIR] keystone" [High,New] https://launchpad.net/bugs/881464 | 11:47 |
| pitti | Daviey: well, it doesn't actually break images right now, so I guess it's ok to leave it there as a reminder | 11:48 |
| Daviey | pitti: yeah, would rather leave it in place, if that is ok. | 12:07 |
| pitti | sladen: the "fonts-ubuntu-font-family-console" binary package wants to go to universe; is that ok, or should that be seeded somewhere? | 12:12 |
| pitti | sladen: the description sounds a bit misleading; I don't have that package installed, but I do have Ubuntu Mono in active use | 12:13 |
| pitti | oh, for *that* console | 12:13 |
| pitti | sladen: so I figure we should seed it into some "supported", so that it's in main for people to install? | 12:13 |
| lool | Sweetshark: Hey, I couldn't find a branch for precise in the pkg-openoffice/libreoffice.git Vcs; perhaps you didn't push it explicitly? | 12:15 |
| Sweetshark | lool: its not there yet. I have been mostly working on fixing up the debian 3.5 branch so that ubuntu can be easily based on it/ | 12:20 |
| === MacSlow is now known as MacSlow|lunch | ||
| lool | Sweetshark: Ok | 12:26 |
| lool | Sweetshark: I am looking at armhf support and have a debdiff and one question | 12:26 |
| === akher0n is now known as akheron | ||
| lool | Sweetshark: http://paste.ubuntu.com/768900/ but I suspect the platform_id thing wont work; would you think we could use the same as armel? ISTR oo.o/lo have bridges which might break with the new sub-ABI :-/ | 12:32 |
| jibel | pitti, ok, I'll blacklist this package and its rdepends to unblock the test. | 12:49 |
| Sweetshark | lool: I have pushed the patch on my todo list. loic.minier@ubuntu.com <- thats the correct author entry ? | 12:54 |
| doko_ | infinity, so you did decide against killing mrpt? | 12:59 |
| ogra_ | hmm, where is $(RM) defined if thats used in debian/rules ? | 13:05 |
| lool | Sweetshark: Sure | 13:05 |
| lool | ogra_: make sets it by default | 13:05 |
| ogra_ | lool, well, then it sets it wrong :P | 13:06 |
| ogra_ | defaulting to -d | 13:06 |
| lool | ogra_: it's set to rm -f by default | 13:06 |
| lool | See Implicit Variables in make.info | 13:06 |
| ogra_ | not for the package i look at atm | 13:06 |
| lool | ogra_: I'm just speaking from the context you gave :-) | 13:06 |
| ogra_ | rm: invalid option -- 'd' | 13:06 |
| ogra_ | Try `rm --help' for more information. | 13:06 |
| ogra_ | thats the ftbfs of emelfm2 | 13:07 |
| ogra_ | and rules just uses $(RM) | 13:07 |
| lool | this makefile http://paste.ubuntu.com/768925/ if run gives "echo rm -f" | 13:07 |
| lool | rm -f | 13:07 |
| lool | ogra_: this is not in rules, it's in Makefile | 13:08 |
| lool | clean: in Makefile has: @rm -rfd $(OBJECTS_DIR) | 13:08 |
| ogra_ | aaah | 13:09 |
| ogra_ | thanks | 13:09 |
| ogra_ | grepping for rm didnt revel that somehow ... weird | 13:09 |
| ogra_ | grepping for rm -r does now though | 13:09 |
| lool | that's because grep rm -r is a recursive grep ;-) | 13:10 |
| ogra_ | well, properly quoted indeed :P | 13:10 |
| ogra_ | fun, no patch system or anything in this package | 13:11 |
| ScottK | debfx: For Ubuntuwire, try on #ubuntuwire. | 13:46 |
| geser | pitti: do you remember how the gnome-shell SRU in oneiric was done? onkarshinde found out that gnome-shell on powerpc got copied from precise to oneiric (see https://launchpad.net/ubuntu/oneiric/powerpc/gnome-shell/ ; bug #903382) | 13:48 |
| ubottu | Launchpad bug 903382 in gnome-shell (Ubuntu) "[powerpc] Unsatisfiable dependency in oneiric" [Undecided,New] https://launchpad.net/bugs/903382 | 13:48 |
| pitti | geser: uh? no, we don't normally do that direction, and I don't remember that we ever had a case where this was justified | 13:53 |
| pitti | geser: we did have some cases where oneiric was copied to precise, and powerpc only got built in precise | 13:53 |
| pitti | geser: but perhaps LP grabbed that precise build into oneiric somehow then | 13:53 |
| tumbleweed | this is one of those cases | 13:54 |
| pitti | geser: so I guess we'll need a no-change upload | 13:54 |
| pitti | powerpc had been broken in oneiric-proposed for quite a long time | 13:54 |
| geser | "Copied from ubuntu precise-release powerpc in Primary Archive for Ubuntu" from the binary publishing entry for gnome-shell on powerpc for oneiric-updates | 13:55 |
| Laney | so it was copied to precise before ppc built? and then somehow the ppc binaries were copied back | 13:55 |
| pitti | ppc failed to build there, but I noticed too late | 13:56 |
| debfx | ScottK: thanks | 13:56 |
| onkarshinde | Just to add one point to discussion, powerpc FTBFS was just temporary. I retried the build yesterday and it built but failed to upload (because of same existing version). | 13:58 |
| Laney | the down-copying is the bigger problem - could the tools catch this? | 13:59 |
| geser | onkarshinde: upload a new version to oneiric-proposed and a new version to precise to get the versions and the debs right | 14:00 |
| geser | and thanks for spotting this | 14:01 |
| pitti | yes, powerpc builds work again | 14:03 |
| onkarshinde | geser: Do I need to make upload to 'precise'? Or will the source be coped from 'oneiric-proposed/updates' | 14:05 |
| pitti | please do upload to precise | 14:05 |
| pitti | no, we can't copy the source only | 14:05 |
| pitti | not uploading to dev release first was the reason which caused this kind of trouble in the first place :) | 14:06 |
| pitti | well, I guess in that particular case precise is actually fine, isn't it? | 14:06 |
| onkarshinde | yes | 14:06 |
| onkarshinde | that is why I am wondering how exactly to approach the issue. | 14:07 |
| pitti | ah, but we still need a precise upload | 14:07 |
| pitti | as precise never got a gnome-shell upload | 14:07 |
| pitti | onkarshinde: upload 3.2.1-0ubuntu2 into precise, so that it gets a precise build | 14:07 |
| pitti | and then 3.2.1-0ubuntu1.1 into o-proposed | 14:07 |
| onkarshinde | Fine. | 14:08 |
| onkarshinde | pitti: oh wait. Isn't that wrong order? I will need to upload 1.1 first and then 2 | 14:08 |
| pitti | well, it doesn't matter much | 14:08 |
| Laney | doesn't matter | 14:08 |
| pitti | technically | 14:08 |
| pitti | but policy wise, "precise first" is always correct :) | 14:09 |
| onkarshinde | ok | 14:09 |
| pitti | these days we don't even accept SRUs unless they are already fixed in the dev release | 14:09 |
| onkarshinde | and in this case, there is nothing to fix in dev release. :-) | 14:09 |
| pitti | except the rebuild, yes | 14:09 |
| tkamppeter | pitti, hi | 14:11 |
| pitti | tkamppeter: o/ | 14:11 |
| pitti | mysql-common | 5.1.58-1ubuntu3 | precise | all | 14:12 |
| pitti | mysql-common | 5.5.17-4ubuntu6 | precise | all | 14:12 |
| pitti | mysql-common | 5.5.17-4ubuntu6 | precise/universe | all | 14:12 |
| pitti | how the heck could that happen? | 14:12 |
| pitti | cjwatson: ^ did you ever happen to see this? it's causing all the madness in http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html | 14:13 |
| pitti | apparently triggered by the mysql-5.1 upload from an hour or two ago | 14:13 |
| pitti | wgrant: ^ perhaps you have an idea | 14:14 |
| tkamppeter | pitti, it is about the USB backend of CUPS. See bug 902535. | 14:14 |
| ubottu | Launchpad bug 902535 in cups (Ubuntu) "Unable to print to Lexmark S405 since upgrade to 11.10" [Undecided,Incomplete] https://launchpad.net/bugs/902535 | 14:14 |
| * onkarshinde leaves | 14:15 | |
| cjwatson | pitti: the BPPHs will be arch-specific even if the actual .deb isn't; so if somebody processed the binary uploads through NEW with the overrides that way, it would cause that duplication | 14:16 |
| cjwatson | pitti: change-override.py -c main should fix it, anyway | 14:16 |
| pitti | cjwatson: I promoted it back to main now, it just seemed like a bug | 14:16 |
| cjwatson | kindasorta | 14:16 |
| pitti | tkamppeter: hm, it doesn't seem to say it's a regression from the recent -proposed, is it? | 14:17 |
| tkamppeter | Some manufacturer drivers need bi-directional communication with the printer. Formerly we had a USB backend which worked with both libusb and usblp and I wanted to get it upstream (http://www.cups.org/str.php?L3357) but Mike Sweet did not accept it, he told me I should better deprecate the usblp kernel module and compile the upstream backend in libusb mode. Now after several SRUs this works at least for uni-directional printing but bi-d | 14:18 |
| tkamppeter | irectional is not implemented at all in it (http://www.cups.org/str.php?L2890). | 14:18 |
| geser | https://launchpad.net/ubuntu/precise/i386/mysql-common shows the main version as superseded by the universe one (demotion?) for 5.5.17-4ubuntu6 and also 5.1.58-1ubuntu3 as published? | 14:19 |
| tkamppeter | pitti, I do not want to say that we have a regression caused by an SRU but we have a regression against Natty, as bi-directional USB printer access stopped working for all non-HP printers due to the new CUPS USB backend not supporting it. The SRUs did only fixes for unidirectional printing and have no influence on this. | 14:19 |
| geser | cjwatson: will the change-override also "fix" the published state for 5.1.58-1ubuntu3? (see https://launchpad.net/ubuntu/precise/i386/mysql-common) | 14:21 |
| * ogra_ glares at the eukleides ftbfs and wonders how geser got it to build in natty ... it has -lncurses set in LIBS but no build dep on anything that includes ncurses | 14:21 | |
| pitti | geser: I can only hope so | 14:24 |
| geser | ogra_: it looks like one of the build-deps pulled it in, at least the buildlog mentions that libncurses5-dev go also installed | 14:24 |
| ogra_ | geser, hmm, funny, that doesnt seem to be the case in precise anymore ... at least on armhf ... i'll just add it then, thanks | 14:25 |
| geser | ogra_: libreadline-dev (direct build-dep) -> libreadline6-dev -> libncurses5-dev (at least in natty) | 14:25 |
| ogra_ | hmm, yeah, its the same in precise here | 14:26 |
| ogra_ | weird | 14:26 |
| ogra_ | probably a buildd hiccup, i also see its using unauthenticated packages | 14:26 |
| cjwatson | pitti,slangasek: I've added uninstallable output for -updates now - see e.g. http://people.canonical.com/~ubuntu-archive/testing/lucid-updates_probs.html | 14:27 |
| ogra_ | i'll just give back and will see if it survives | 14:27 |
| cjwatson | geser: should do | 14:27 |
| pitti | cjwatson: oh, great! thanks | 14:27 |
| pitti | cjwatson: I'll fix the langpack stuff | 14:27 |
| ogra_ | fun ! | 14:28 |
| ogra_ | same issue on the next package in the ftbfs list | 14:28 |
| geser | ogra_: in precise libreadline6-dev depends on libtinfo-dev instead of libncurses5-dev | 14:28 |
| ogra_ | not here | 14:28 |
| ogra_ | ogra@horus:~/devel$ apt-cache show libreadline6-dev|grep ncurses | 14:29 |
| ogra_ | Depends: libreadline6 (= 6.2-2ubuntu1), libncurses5-dev, dpkg (>= 1.15.4) | install-info | 14:29 |
| ogra_ | argh | 14:29 |
| ogra_ | crap, i shoudl use my precise chroot instead of checking on the oneiric host ... ignore me | 14:29 |
| ScottK | /ignore ogra_ | 14:31 |
| ogra_ | heh | 14:31 |
| * ogra_ digs a hole and hides in it | 14:31 | |
| tkamppeter | pitti, should we return with our USB CUPS backend until upstream make the libusb-based backend bi-directional? | 14:33 |
| pitti | tkamppeter: I don't have a strong opinion, but it seems we already reverted half of cups 1.5 back to 1.4 at that point? | 14:34 |
| psusi | say, doesn't the pae kernel run on a non pae cpu? just disables pae if it isn't supported doesn't it? | 14:35 |
| pitti | psusi: as far as I heared yesterday, no | 14:36 |
| pitti | it will just immediately fail to boot | 14:37 |
| pitti | if it did that, we wouldn't need to have an extra flavour | 14:37 |
| psusi | I was wondering... odd... I could have sworn it would just disable pae | 14:38 |
| psusi | or did at one point... maybe it broke? | 14:39 |
| tkamppeter | pitti, not with the USB backend. We reverted the IPP backend. The SRUs on the USB backend are small patches to fix some problems but not reverting to 1.4.x. | 14:39 |
| tkamppeter | pitti, and the USB backend we will not actually revert but re-apply a dropped distro patch. | 14:40 |
| pitti | tkamppeter: ah, that sounds fine | 14:40 |
| mterry | pitti, what code looks to see if pkgbinarymangler is installed and runs it if so? | 14:42 |
| pitti | mterry: how do you mean? | 14:42 |
| pitti | mterry: oh -- it diverts dpkg-deb | 14:43 |
| pitti | and replaces it with a wrapper | 14:43 |
| mterry | pitti, oh! interesting. that doesn't show up in a dpkg -L natch, didn't think of it | 14:43 |
| tkamppeter | pitti, problem of the patch is that upstream does not accept it and suggested me to go libusb-only instead. With the lack of bi-directional support of the libusb-based USB backend it seems to be pre-mature to deprecate usblp. | 14:43 |
| pitti | tkamppeter: is it so important to have a bidir communication? | 14:44 |
| tkamppeter | pitti, it seems only to be needed by some proprietary drivers like Lexmark's. | 14:45 |
| tkamppeter | pitti, I got only aware of that via bug 902535. | 14:46 |
| ubottu | Launchpad bug 902535 in cups (Ubuntu) "Unable to print to Lexmark S405 since upgrade to 11.10" [Undecided,Incomplete] https://launchpad.net/bugs/902535 | 14:46 |
| tkamppeter | pitti, one problem is also that Mike Sweet concentrates on the stuff which is needed by Mac OS X and drops everything which is not needed by Mac OS X. The Linux/Unix parts of the USB backends are formally continued in CUPS 1.6, but the feature request for bi-di support in the libusb-based part of the backend is not worked on for years. | 14:49 |
| pitti | tkamppeter: so even if we have a patch he doesn't apply it, even though he doesn't want to maintain it by himself any more? | 14:49 |
| tkamppeter | pitti, yes, http://www.cups.org/str.php?L3357 stays untouched and in personal mail he told me to drop usblp support and http://www.cups.org/str.php?L2890 also stays untouched, Mike has reported this one by himself but probably before he got to Apple. | 14:52 |
| === yofel_ is now known as yofel | ||
| geser | pitti: the reason for the two mysql-common versions is that armhf is still waiting on building mysql-5.1 (which build mysql-common in the past (and still list it)) | 14:55 |
| tkamppeter | pitti, perhaps one must also look into the "hp" backend from HPLIP whether one could perhaps get some bi-di libusb code out of it into the standard CUPS USB backend. | 14:56 |
| === Ursinha is now known as Ursinha-nom | ||
| kees | pitti: cool, thanks! | 15:10 |
| === mterry is now known as mterry_sprinting | ||
| apw | is there a simple way to ask if it is possible to install a .deb without installing it. ie if the deps it requires are installed | 15:21 |
| pitti | apw: apt-get install foo --simulate | 15:22 |
| apw | pitti, and if it is a local .deb ? | 15:22 |
| pitti | apw: or say "no" if it does have dependencies, then apt will ask (but not if it's only a single package) | 15:22 |
| pitti | apw: sudo dpkg -i --simulate foo.deb ? | 15:23 |
| cjwatson | something with gdebi --apt-line maybe | 15:23 |
| apw | pitti, :) | 15:23 |
| cjwatson | or DIY with python-apt | 15:23 |
| * pitti waves good night, have to run | 15:23 | |
| pitti | apw: this works for me with a local deb | 15:23 |
| sladen | pitti: f-u-f-f-console. That wants to be seeded for the server + UEC images | 15:35 |
| sladen | pitti: so that the setfont stuff can be tied into it | 15:35 |
| === Ursinha-nom is now known as Ursinha | ||
| infinity | doko_: I got distracted by illness, and forgot to get it killed. :P | 16:03 |
| bdmurray | pitti: is this a new feature of the retrace? https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/898756/comments/5 | 16:53 |
| ubottu | Ubuntu bug 898756 in aptdaemon (Ubuntu) "<type 'exceptions.NameError'>: global name 'resolver' is not defined" [High,Fix committed] | 16:53 |
| === ampelbein_ is now known as Ampelbein | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| broder | i have to run, but if somebody on ubuntu-branches could mark https://code.launchpad.net/~veger/ubuntu/oneiric/xvba-video/fix-for-871615/+merge/85452 as merged, i'd appreciate it | 17:47 |
| SpamapS | hmmm | 18:03 |
| SpamapS | https://launchpadlibrarian.net/87383267/buildlog_ubuntu-precise-i386.charm-tools_0.3%2B91-0ubuntu1_FAILEDTOBUILD.txt.gz .. I just realized this tries to listen on 0.0.0.0:8999 ... might buildds prevent that? | 18:04 |
| janimo | ev, do you know which parts of ubiquity stack should I look at if I do not get an external disk as a viable install target alternative? | 18:20 |
| janimo | on an arm pandaboard I only get the option of the MMC I booted from but not the USB external drive | 18:20 |
| === nxvl_ is now known as nxvl | ||
| cjwatson | janimo: partman-base, probably | 18:28 |
| janimo | cjwatson, thanks | 18:28 |
| cjwatson | janimo: specifically parted_devices would be a good start | 18:28 |
| cjwatson | then init.d/partman and work up from there | 18:28 |
| apw | i have just had a report of a machine ending up a ton of package being deleted during update | 18:47 |
| apw | is there anything bad known about right now ? | 18:47 |
| apw | and /me has just asked for an upgrade and its threatening to remove a ton of packages including gnome-* | 18:48 |
| apw | is this just transistional or did the world just end | 18:48 |
| seb128 | apw, do you have details on what got uninstalled? I did a new gtk serie upload, those can create installability issues on !i386 during a publisher cycle because -common is built on i386 | 18:49 |
| infinity | apw: Just that one should read the output of dist-upgrade when running a devel release. | 18:49 |
| infinity | apw: And don't do it when it says scary things. | 18:49 |
| infinity | apw: (It's transitional) | 18:49 |
| apw | infinity, oh indeed. i have said no :) | 18:49 |
| seb128 | apw, does it want to remove a libgtk-3-<something>? | 18:49 |
| infinity | apw: "upgrade" will work fine. | 18:49 |
| seb128 | apw, what arch are you on? | 18:49 |
| apw | t | 18:49 |
| apw | this is amd64 | 18:50 |
| infinity | seb128: It wants to upgrade -3-common, and pull out, well. Everything. Not an uncommon scenario for GTK skew. | 18:50 |
| infinity | It'll pass in a few hours. | 18:50 |
| seb128 | apw, ok, wait the next publisher run (i.e ~1h) | 18:50 |
| apw | yes it is asking to remove gtk3 yes | 18:50 |
| seb128 | it just built on amd64 so it will catch the next run | 18:50 |
| apw | ok will do | 18:50 |
| ogra_ | glade will also need a give back on armhf | 18:50 |
| ogra_ | seems it ran directly into that issue | 18:50 |
| seb128 | ogra_, on all !i386 yes | 18:50 |
| infinity | ogra_: I know. Watching it. | 18:50 |
| ogra_ | with wide open eyes :) | 18:51 |
| apw | as long as it is transitional, life is good | 18:51 |
| seb128 | yeah, it should be fixed in one hour | 18:51 |
| seb128 | if not please tell me | 18:51 |
| ogra_ | yeah, its the usual gtk upload freeze | 18:51 |
| seb128 | be aware that I just uploaded a new gtk2 and new glib as well | 18:52 |
| ogra_ | yay | 18:52 |
| seb128 | so those might hit next and take another publisher run to sort | 18:52 |
| ogra_ | double the fun :) | 18:52 |
| seb128 | ogra_, indeed ;-) | 18:52 |
| seb128 | well, I will be nice until holidays now :p | 18:52 |
| infinity | Heh. | 18:52 |
| apw | infinity, so i have been told that apt-get update is bad as it doesn't install depends | 18:52 |
| seb128 | that was the non trivial stuff I had left to do | 18:52 |
| ogra_ | :) | 18:53 |
| infinity | apw: It won't pull in new packages. But it also refuses to remove anything. | 18:53 |
| infinity | apw: Also, s/update/upgrade/ :P | 18:53 |
| apw | seb128, so why don't we build this kind of exploding thingy in a PPA and copy it out when its complete | 18:53 |
| ogra_ | its the safer way to keep your system up to date | 18:53 |
| seb128 | can we do that? | 18:53 |
| infinity | seb128: Yup. | 18:53 |
| seb128 | well nobody told me we can | 18:53 |
| apw | seb128, we do our kernels that way for SRUs so i'd say so | 18:53 |
| ScottK | It's technically possible. I'm not sure it's allowed by policy. | 18:54 |
| ogra_ | that will need an upload to the archive for ppc, no ? | 18:54 |
| infinity | ScottK: It's definitely allowed, we do it for toolchain stuff. | 18:54 |
| ogra_ | ordo we have any ppc PPAs | 18:54 |
| infinity | ogra_: non-virt PPA. | 18:54 |
| apw | ogra_, a de-virt PPA | 18:54 |
| ScottK | infinity: I think toolchain and kernel SRUs are an exception. | 18:54 |
| ogra_ | so there are some | 18:54 |
| * ogra_ didnt know | 18:54 | |
| infinity | ScottK: It was discussed at UDS as a more general solution for disruptive uploads, and I'm pretty sure the plan was to go ahead with using PPAs as staging. | 18:55 |
| infinity | But maybe it never made it from talk to real-world use. :P | 18:55 |
| ScottK | infinity: OK. It would be nice then to have this documented so people would know when it's appropriate. | 18:55 |
| tgardner | I just managed to toast a laptop, which makes me kind of cranky. | 18:56 |
| ogra_ | there are surely UDS notes somewhere | 18:56 |
| infinity | tgardner: Well done? | 18:56 |
| ogra_ | if it was actually discussed in a session | 18:56 |
| ScottK | ogra_: Yes, but random UDS notes really don't help for people that weren't in the room. | 18:56 |
| ogra_ | no, someone who was should surely write them up properly :) | 18:56 |
| seb128 | well they agreed at UDS in settings a staging ppa that anyone could use | 18:57 |
| ogra_ | (i wasnt mind you) | 18:57 |
| seb128 | or maybe use -proposed for that during the unstable cycle | 18:57 |
| seb128 | but I don't think anyone worked on actually moving that forward yet | 18:57 |
| infinity | Obviously, this needs more effort. Yeah. | 18:57 |
| seb128 | so I guess it will be discussed,announced when that happens | 18:57 |
| SpamapS | is there somewhere that the limits of what you can do on a buildd are documented? | 19:04 |
| SpamapS | the unit tests for what I uploaded to the charm-tools package work fine in my local sbuild.. but fail on the buildds for seemlingly unknown reasons. :-/ | 19:04 |
| ogra_ | you can do everything it allows :) | 19:04 |
| SpamapS | ogra_: your succinct explanation is perfectly cromulent | 19:05 |
| infinity | SpamapS: Without looking, I'm going to assume it tried to talk to teh interwebs. | 19:05 |
| ogra_ | which it wouldnt allow :) | 19:05 |
| infinity | SpamapS: Buildds have no external routing (or even forwarding DNS) outside their little world. | 19:06 |
| SpamapS | infinity: I took steps to prevent that, but I'll try tcpdumping during my sbuild.. | 19:06 |
| SpamapS | Hmm, I wonder | 19:06 |
| infinity | SpamapS: Lemme look at your log and see if something jumps out. | 19:06 |
| SpamapS | infinity: you'll want to look at the test script really.. the log isn't super helpful w/o it | 19:07 |
| ScottK | FSVO 'want' | 19:07 |
| infinity | SpamapS: Yeah, I just saw that. That's one super-uninformative log. | 19:07 |
| SpamapS | http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/charm-tools/precise/files/head:/tests/helpers/ | 19:08 |
| SpamapS | infinity: I think I may need to favor output over beauty in that test script.. | 19:08 |
| SpamapS | suppressing too many things has caused it to be unhelpful | 19:08 |
| elmo | *blink* | 19:09 |
| elmo | SpamapS: you're doing all sorts of DNS + internet access attempts in there? | 19:10 |
| infinity | Yeah, I'm assuming it's the ch_is_ip or ch_is_url stuff attempting to whack the outside world. | 19:10 |
| elmo | like infinity said, other than selective in-DC resources, the buildds can't see *anything* including doing DNS resolution | 19:10 |
| ogra_ | you even run a webserver | 19:10 |
| SpamapS | elmo: I aliased host/dig to my own little functions which mock them.. but its possible that just didn't work | 19:10 |
| elmo | ogra_: that part is fine, it's local | 19:10 |
| infinity | ogra_: Running a server is fine. | 19:10 |
| ogra_ | sure | 19:10 |
| infinity | SpamapS: Well, it build fast, abuse a PPA to test iterations. Or set your nameserver in resolv.conf to something you can't route, and test harder. ;) | 19:12 |
| infinity | (The latter is how I tend to track down external-DNS/access oopses in builds) | 19:12 |
| SpamapS | yeah i think I'll re-run with -x if there are failures too | 19:13 |
| SpamapS | well tcpdump didn't pick anything up.. but caching could be preventing that | 19:14 |
| infinity | SpamapS: Seriously, just set nameserver to 192.168.33.33 (ie: something both non-routable and not actually running a nameserver) in resolv.conf in your chroot and try again. | 19:17 |
| SpamapS | Yeah I'm actually doing that right now while I also try something in a PPA. :) | 19:18 |
| infinity | Heh. | 19:19 |
| broder | infinity: i thought we actually decided that we should use -proposed for staging invasive changes | 19:21 |
| infinity | broder: I may have missed the last discussion on the matter, but that also sounds sane. | 19:22 |
| * broder looks for the blueprint/etherpad | 19:22 | |
| infinity | broder: Implementation details are less important to me than having it done. But yeah, we obviously need to publicise this wider, if no one's aware of it (and some of us are aware of it, but potentially incorrectly). | 19:23 |
| broder | https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-upload-intermediary and http://pad.ubuntu.com/uds-p-foundations-p-upload-intermediary | 19:23 |
| broder | ev was more interested in how we could hook testing into the migration path, but we definitely talked about using -proposed to stage things that might create skew/uninstallability/etc | 19:24 |
| SpamapS | infinity: works fine w/ an unroutable DNS server | 19:29 |
| * infinity blinks. | 19:29 | |
| infinity | Okay, I'm now interested enough to try. | 19:29 |
| SpamapS | PPA builds are 2 hours wait right now.. so I'm stracing. ;) | 19:30 |
| SpamapS | Actually | 19:30 |
| SpamapS | could it be as simple as it taking the server more than 1 second to listen() ? | 19:31 |
| infinity | It could be. You don't give it more time? | 19:31 |
| * SpamapS could be more correct and loop netstat till it listens. :p | 19:31 | |
| SpamapS | no. I should actually loop wget until it responds once rather than just being lazy and doing sleep 1 | 19:32 |
| SpamapS | I think doing that, and also exposing the server's log rather than throwing it into /dev/null should help | 19:33 |
| infinity | I'm going to grab a quick bite to eat. Do I get a prize if I can reproduce this locally? | 19:34 |
| SpamapS | infinity: satisfaction is its own prize. :) | 19:38 |
| === Quintasan_ is now known as Quintasan | ||
| kirkland | tyhicks: jjohansen: hey guys...what did y'all decide on the ecryptfs long-filename work for 12.04? | 19:41 |
| jtaylor | SpamapS: I probably have similar problems with a package I just synced, pyzmq can't bind to 127.0.0.1 | 19:42 |
| jtaylor | works fine locally | 19:42 |
| SpamapS | this binds to 0.0.0.0:8999 | 19:42 |
| SpamapS | but yeah maybe similar issue | 19:42 |
| tyhicks | kirkland: I'm going to fix ecryptfs_statfs() to return an appropriate f_namelen and then lean on applications to properly check that | 19:43 |
| kirkland | tyhicks: and we'll file and fix bugs against each broken app? | 19:43 |
| tyhicks | kirkland: The patch should go upstream sometime this week. I'm trying to work out a way to get as close to the maximum allowed filename length as possible, but it isn't straightforward due to the encrypting and encoding that the filename goes through. | 19:44 |
| tyhicks | kirkland: Right, I'll file bugs | 19:44 |
| kirkland | tyhicks: coolio | 19:46 |
| ScottK | kirkland: Congratulations on your new gig. | 19:48 |
| kirkland | ScottK: thanks! | 19:48 |
| tgardner | tyhicks, how about picking a constant to begin with? keep it simple. there has to be a valid floor value. | 19:49 |
| tyhicks | tgardner: It can change based upon cipher block size | 19:50 |
| tyhicks | tgardner: What I'm about to do is pre-calculate a small lookup table | 19:51 |
| tgardner | tyhicks, so figure out what the largest cipher block size is, subtract that from the underlying FS name length, and advertise taht. | 19:51 |
| tyhicks | tgardner: There's quite a bit of metadata that gets stuffed in the filename, along with an encoding process (to make the ciphertext printable) that has a somewhat variable expansion size | 19:52 |
| tyhicks | tgardner: I'm going to take one more look at coming up with an accurate equation and then probably do the lookup table | 19:53 |
| tyhicks | One of the metadata fields can vary between 1 and 3 bytes | 19:53 |
| tyhicks | It is a pain... | 19:54 |
| tgardner | tyhicks, I think I'm a bit confused. you can only return one name length per underlying FS type, right ? | 19:54 |
| tyhicks | tgardner: right | 19:54 |
| tgardner | one *maximum* name length | 19:54 |
| tyhicks | right | 19:54 |
| tyhicks | tgardner: You're suggesting to hardcode a set of maximum eCryptfs filename lengths based on what the underlying FS is? | 19:56 |
| tgardner | tyhicks, so, you're trying to calculate that value based on the FS type. a static table does seem simpler. | 19:56 |
| tgardner | its not like its gonna change. | 19:56 |
| tyhicks | tgardner: Actually, I'm trying to calculate that value based on what the lower filesystem reports its max filename size is | 19:56 |
| tgardner | do any of the FS types have variable max lengths ? | 19:57 |
| tyhicks | tgardner: But, a static table still works the same | 19:57 |
| tgardner | I'm just thinking expediency. it'll be a lot easier to debug. | 19:57 |
| tgardner | one could always optimize later | 19:58 |
| tyhicks | tgardner: I think that ntfs (or is it fat?) does have a variable length. Also, who knows what we'll see when stacked on top of a FUSE filesystem | 19:58 |
| tyhicks | tgardner: But I'm with you, optimize for the common case and worry about the corner cases later | 19:58 |
| tgardner | tyhicks, yeah, we need to start finding which apps are gonna croak | 19:59 |
| infinity | SpamapS: FTR, exactly the same failure locally, using an upgraded buildd chroot and an invalid resolv.conf. | 19:59 |
| SpamapS | infinity: hrm | 19:59 |
| infinity | SpamapS: And fails with a valid resolv.conf too. | 20:00 |
| infinity | SpamapS: So, it's probably the timeout thing. | 20:00 |
| SpamapS | infinity: I think its the 1 second pause | 20:00 |
| infinity | (Or something) | 20:00 |
| SpamapS | I have a new version of helper.sh that loops wgetting / until it succeds or reaches 5 fails | 20:00 |
| SpamapS | I've noticed PPA builds have been really really delayed the last 3 weeks.. are we just hammering the buildds w/ distro stuff? | 20:01 |
| SpamapS | like, 2 hours is the shortest I've had in a while | 20:01 |
| infinity | SpamapS: Changing the sleep 1 to a sleep 5, it still fails. | 20:01 |
| infinity | SpamapS: So, it's something a bit wonkier than macihne speed... | 20:01 |
| infinity | (This is a 2.6G Core2...) | 20:02 |
| iceroot | SpamapS: for my last build i had 13 hours | 20:02 |
| infinity | SpamapS: PPA and distro don't (often) relate. Just looks like a lot of people doing daily recipe builds and such. :/ | 20:02 |
| SpamapS | infinity: I was thinking it was trying to do a reverse lookup then failing. | 20:02 |
| SpamapS | or something like that | 20:03 |
| SpamapS | haven't dug through SimpleHTTPServer yet to see how it does its magic | 20:03 |
| infinity | SpamapS: Give me a command line to run just the testserver? | 20:03 |
| JanC | SpamapS: I have had my PPA builds start in 10-30 minutes I think? | 20:03 |
| SpamapS | infinity: is there something different about a buildd chroot than one made with 'mk-sbuild' ? | 20:03 |
| infinity | SpamapS: Probably. | 20:04 |
| infinity | http://launchpadlibrarian.net/85129991/chroot-ubuntu-precise-i386.tar.bz2 | 20:04 |
| infinity | Grab the real thing and try? | 20:04 |
| JanC | SpamapS: but you are probably building for precise? | 20:05 |
| SpamapS | JanC: I am | 20:05 |
| JanC | I guess that might be the difference then | 20:05 |
| SpamapS | heh and now my build went up to 3 hours. :-/ | 20:06 |
| infinity | /usr/bin/python: No module named SimpleHTTPServer | 20:06 |
| infinity | SpamapS: Missing build-dep? :P | 20:06 |
| SpamapS | infinity: I was afraid of that. IIRC, its part of python2.7-minimal .. :-/ | 20:06 |
| SpamapS | but that doesn't sound right at all | 20:06 |
| infinity | Why would minimap have an HTTP server? | 20:07 |
| infinity | minimal... | 20:07 |
| SpamapS | I know | 20:07 |
| SpamapS | bigger question, why does sbuild bring in python2.7 where buildd does not? | 20:07 |
| infinity | SpamapS: Boom. Installing python, and it works. | 20:08 |
| SpamapS | yeah | 20:08 |
| infinity | SpamapS: And I have no idea why your chroot had python, but it shouldn't. | 20:08 |
| SpamapS | all my precise chroots do | 20:08 |
| seb128 | lamont, is there any way to get a stacktrace of an hanging build on the buildds? | 20:08 |
| lamont | seb128: ppa or otherwise? | 20:08 |
| seb128 | lamont, well, main archive in that case but ppa have the same issue | 20:09 |
| seb128 | upstream blames it on our old kernel | 20:09 |
| lamont | seb128: archive is easier | 20:09 |
| seb128 | lamont, https://launchpad.net/ubuntu/precise/+source/glib2.0/2.31.4.tested-0ubuntu1 | 20:09 |
| seb128 | the i386 or amd64 builds | 20:09 |
| lamont | just grab the victim of the shift and have him do that for you... | 20:09 |
| * lamont just EODed and needs to run | 20:09 | |
| seb128 | they are stucked again | 20:09 |
| seb128 | ok | 20:09 |
| SpamapS | infinity: thanks for finding that. I'm adding stuff to print out the server's logs/errors now | 20:10 |
| seb128 | who is in the victims' club? ;-) | 20:10 |
| seb128 | infinity, ? | 20:10 |
| * jtaylor is | 20:10 | |
| seb128 | jtaylor, hey! | 20:10 |
| jtaylor | I mean i too have a hanging build ._. | 20:10 |
| infinity | seb128: deej. | 20:10 |
| seb128 | infinity, thanks | 20:12 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| SpamapS | hmmm.. so mk-sbuild installs devscripts | 20:45 |
| SpamapS | that seems to be the issue | 20:45 |
| === salem_ is now known as _salem | ||
| tumbleweed | hrm, we probably shouldn't do that in mk-sbuild. People can configure to to do that if they want devscripts in their chroots | 20:54 |
| SpamapS | its helpful when you need it, but so is vim, and we don't put that in.. | 20:57 |
| tumbleweed | yeah, I add vim-tiny in my own config | 21:01 |
| === doko_ is now known as doko | ||
| doko | seb128, the `tested' in the glibc2.0 version didn't prevent the package failing to build ;-P | 22:09 |
| seb128 | doko, right, I hate the builders, it doesn't happen on non-buildds environment, desrt and other upstreams think it might be a kernel bug on the old buildds kernels | 22:10 |
| seb128 | doko, I'm about to do an update with a second testcase commented... | 22:10 |
| hallyn | hey - i notice the autosync daemon synced spice-protocol 12 hours ago. is it likely just a matter of time before it does spice, or can something be done to kick it? | 22:21 |
| slangasek | hallyn: according to https://launchpad.net/ubuntu/+source/spice-protocol/0.10.0-1, it already built | 22:30 |
| slangasek | oh, you're asking about a separate package | 22:30 |
| slangasek | no, it's not a matter of time :) | 22:30 |
| slangasek | that is, any given autosync run should be complete | 22:31 |
| slangasek | hallyn: spice 0.10.0-1 isn't in Debian testing yet - if you need it sooner, you should probably run syncpackage for it | 22:31 |
| doko | wendar, your magics++ patch looks very strange (and ftbfs on arm* which doesn't have quadmath) | 22:47 |
| bdrung | broder: and sponsor-patch uses the new syncpackage sponsoring feature in the latest dailies version. | 22:54 |
| hallyn | slangasek: i see, thx - didn't realize autosync came from testing | 23:16 |
| hallyn | alas i don't have upload rights to syncpackage | 23:17 |
| broder | is there any way to get precise-{security,updates} pockets created on ddebs.ubuntu.com so that update-manager isn't as whiny? | 23:28 |
| infinity | pitti: ^ | 23:30 |
| broder | ok, i wasn't sure if that was a pitti thing or a canonical IS thing or something else entirely thing | 23:31 |
| infinity | broder: It's mostly pitti's baby right now. | 23:31 |
| * broder nods | 23:31 | |
| mdeslaur | slangasek: is it normal that ia32-libs is uninstallable on precise? | 23:36 |
| === dendrobates is now known as dendro-afk | ||
| slangasek | mdeslaur: until the conversion is done, yes | 23:36 |
| mdeslaur | slangasek: ok, thanks | 23:37 |
| slangasek | hallyn: testing> usually it's from unstable; LTSes tend to be a special case | 23:37 |
| mdeslaur | slangasek: conversion to what, btw? | 23:37 |
| slangasek | mdeslaur: all the previous contents have been moved to be dependencies of ia32-libs-multiarch:i386; those libs all need to be fixed up for multiarch coinstallability | 23:37 |
| slangasek | we're getting closer, but it's a deep hole | 23:37 |
| mdeslaur | slangasek: ah! I see, thanks for the explanation | 23:38 |
| slangasek | it's very likely that I will feel compelled to plow through the remainder between now and the end of the year | 23:39 |
| broder | slangasek: is there a comprehensive list of the ones that still need help somewhere? | 23:39 |
| infinity | broder: "apt-get install ia32-libs-multiarch" should probably give a fine list of complaints. ;) | 23:40 |
| broder | indeed it does | 23:40 |
| slangasek | broder: better is this: | 23:44 |
| slangasek | $ for pkg in $(apt-cache show ia32-libs-multiarch \ |sed -n -e'/^Depends: / { s/Depends://; s/, /\n/g; p }'); do echo $pkg $pkg:i386; done | xargs sudo apt-get install -y | sed -n -e'/The following packages have unmet dependencies/,$p' | 23:44 |
| doko | barry, are you familiar with nosetests? they seem to hang on armhf at least, see https://launchpad.net/ubuntu/+source/mpi4py/1.2.2-3/+build/3003368 | 23:47 |
| broder | slangasek: man, there aren't any fun ones left, are there? | 23:47 |
| ScottK | doko: I think lifeless knows a lot about those. | 23:47 |
| slangasek | broder: what kind of fun were you looking for, exactly? :) there's libpam-ldap... :) | 23:49 |
| broder | that's certainly one some kind of fun :) | 23:49 |
| infinity | doko: The build's only been going for 20 minutes, are you sure it's hung? | 23:50 |
| doko | infinity, yes, killed the last one after 20h | 23:50 |
| infinity | doko: Oh. Special. :/ | 23:50 |
| doko | sorry, 12h | 23:51 |
| doko | see https://launchpad.net/ubuntu/precise/+source/mpi4py/1.2.2-2 | 23:51 |
| infinity | doko: Ahh, not armhf-specific. Same hang on armel. | 23:52 |
| infinity | doko: That's mildly comforting, at least. | 23:52 |
| slangasek | broder: alternatively, gconf2 unblocks gstreamer-plugins-good? | 23:52 |
| slangasek | and has some fun interdependencies :) | 23:52 |
| broder | i can take a look at that | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!