| TheMuso | @pilot in | 00:07 |
|---|---|---|
| === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso | ||
| cjwatson | shadeslayer: http://qa.ubuntuwire.com/ftbfs/#kubuntu is probably simplest | 00:07 |
| === emma_ is now known as em | ||
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| TheMuso | @pilot out | 03:06 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| darkxst | TheMuso, Thanks! | 03:26 |
| TheMuso | darkxst: np | 03:34 |
| === timrc is now known as timrc-afk | ||
| === kirb_ is now known as Guest94590 | ||
| === LoganCloud is now known as Logan__ | ||
| pitti | Good morning | 05:44 |
| pitti | doko_: do you happen to have an idea about bug 1270025? i. e. is calling "dot -c" in postinst the right thing to do? | 06:01 |
| ubottu | bug 1270025 in graphviz (Ubuntu) "graphviz package does not configure plugins" [Undecided,New] https://launchpad.net/bugs/1270025 | 06:02 |
| pitti | vila: FTR, I can reliably reproduce bug 1269886 locally; you can't? | 06:03 |
| ubottu | bug 1269886 in bzr (Ubuntu) "autopkgtest fails in trusty: TestSmartTCPServer.test_graceful_shutdown_waits_for_clients_to_stop" [Undecided,Confirmed] https://launchpad.net/bugs/1269886 | 06:04 |
| darkxst | hey pitti | 06:04 |
| darkxst | would autopilot work with gnome-shell? | 06:05 |
| Noskcaj | darkxst, Should do. Check "autopilot launch gnome-shell" | 06:07 |
| Noskcaj | Since it's gtk3 it should introspect | 06:07 |
| darkxst | Noskcaj, gnome-shell doesnt really use standard gtk3 widgets though | 06:08 |
| Noskcaj | darkxst, good point. As long as it will launch without error via autopilot, it should work. It might be a bit more complex though | 06:09 |
| pitti | darkxst: yes, I don't see why not | 06:11 |
| pitti | Noskcaj: hey | 06:11 |
| Noskcaj | hey pitti | 06:11 |
| pitti | Noskcaj: wrt. the libgweather transition: don't worry; some bits were done yesterday, and the two remaining ones are new versions of evolution and evolution-data-server which are prepared (but blocked by the "don't change the phone" ban ATM) | 06:11 |
| Noskcaj | ok | 06:12 |
| darkxst | well It launches but getting a ton of unsupported type warnings | 06:13 |
| darkxst | although they seem to be standard GTK bits, | 06:14 |
| Noskcaj | darkxst, Provided it's nothing like Gtk-Message: Failed to load module "autopilot", you're good | 06:14 |
| pitti | darkxst: yes; that warning is already silenced in trunk, but it's been a while since we released AP | 06:15 |
| wolter | Is unity launcher api on topic in this channel? | 06:15 |
| pitti | darkxst: in fact we are trying to, currently held up by bug 1270025 | 06:15 |
| ubottu | bug 1270025 in graphviz (Ubuntu) "graphviz package does not configure plugins" [Undecided,New] https://launchpad.net/bugs/1270025 | 06:15 |
| pitti | darkxst: FTR, autopilot can only introspect simple property types (int, string, float, flags, enums, etc.); it has some special cases for GtkTextBuffer, but for properties of other class types it can't do introspection | 06:16 |
| pitti | darkxst: btw, if you need a particular property and there is a sensible way to represent it as a string, please file a bug against autopilot-gtk | 06:17 |
| darkxst | pitti, I really just want a test to make sure gnome-shell has loaded properly | 06:17 |
| pitti | darkxst: so I guess you just want to check that you can find a few representative widgets and ensure that they are visible? | 06:17 |
| darkxst | yes | 06:18 |
| pitti | you can also check their globalRect for plausible values | 06:18 |
| pitti | darkxst: does gnome-shell run in xvfb? (i. e. with software rendering) | 06:18 |
| pitti | darkxst: then this could become an autopkgtest, and we'd immediately know when it breaks due to a new upload | 06:19 |
| darkxst | it certainly runs with software rendering | 06:19 |
| darkxst | and yes that would be better, because once gnome-shell breaks, so does gdm ;( | 06:20 |
| pitti | darkxst: note you need to run xvfb like that: xvfb-run -s "-screen 0 1024x768x24" <program> | 06:20 |
| pitti | (without that it runs in 8bpp which doesn't work with rendering) | 06:20 |
| pitti | that's a common trap, in case you don't know | 06:21 |
| darkxst | pitti, that gives XRANR missing | 06:21 |
| darkxst | which makes gnome-shell unhappy | 06:22 |
| pitti | ah :/ | 06:22 |
| pitti | darkxst: the other day there was a patch floating on the upstream ML for adding xrandr support to Xvfb; but it seems it never got accepted :/ | 06:22 |
| pitti | https://launchpad.net/~pitti/+archive/ppa/ still has an xorg-server package with that patch | 06:22 |
| pitti | but that was for raring | 06:23 |
| pitti | darkxst: X.org with the dummy driver does know xrandr, that might work better | 06:23 |
| darkxst | how do I run that? | 06:23 |
| pitti | darkxst: https://git.gnome.org/browse/gnome-settings-daemon/tree/tests/gsdtestcase.py#n202 | 06:24 |
| pitti | darkxst: you can skip the copy part | 06:25 |
| pitti | $ Xorg -config xorg-dummy.conf -logfile /tmp/log :5 | 06:26 |
| pitti | $ DISPLAY=:5 xrandr | 06:26 |
| pitti | Screen 0: minimum 320 x 240, current 1024 x 768, maximum 1024 x 768 | 06:26 |
| pitti | darkxst: ^ something like that | 06:26 |
| pitti | the rest of that code just does the synchronization and error handling | 06:27 |
| pitti | tjaalton, mlankhorst, RAOF: would you happen to know anything about the fate of http://lists.x.org/archives/xorg-devel/2013-January/035114.html ? it works nicely, but it seems it got zero replies | 06:28 |
| pitti | (in a year) | 06:28 |
| RAOF | My guess: nobody X-ish cares enough about xvfb. | 06:29 |
| RAOF | Particularly since the dummy drivers exist. | 06:29 |
| pitti | yeah, see above, but it's two magnitudes harder to set up than xvfb-run | 06:29 |
| pitti | Xvfb is still the #1 tool to run tests during project and package build, or is there something better these days? | 06:30 |
| RAOF | pitti: Really, we should just add a wrapper script that implements xvfb-ish | 06:31 |
| RAOF | As a regular server + dummy conf. | 06:32 |
| pitti | RAOF: I guess that would look similar to above gsdtestcase.py function | 06:32 |
| RAOF | Note: Not volunteering to implement said server :) | 06:32 |
| pitti | I'm happy to do that, it's not particularly difficult | 06:32 |
| RAOF | Right. | 06:33 |
| pitti | but again, if it stays Debian/Ubuntu specific it's still not something you could put into upstream test suites | 06:33 |
| pitti | like in gnome-settings-daemon and the like | 06:33 |
| RAOF | Ideally you'd do it in something that you can do signals and fd passing in; if you pass in a fd X will write the display it's found and if you set SIGUSR1 to ignore the server will raise that once it's ready. | 06:34 |
| RAOF | That's something that could be either upstreamed to xorg or as a trivial extra project. | 06:35 |
| RAOF | It's probably just big enough to be a project you could get everyone to depend upon for their unittests :) | 06:35 |
| pitti | hm; all that instead of applying this rather small patch.. | 06:35 |
| pitti | xvfb-run already implements all that logic, after all (and it's far from trivial) | 06:36 |
| RAOF | Mostly. | 06:36 |
| pitti | perhaps I should temporarily subscribe, and poke on the list for a review? | 06:36 |
| RAOF | Could work. | 06:37 |
| darkxst | hmm, xorg segfaulted when I launched xrandr ;( | 06:39 |
| wolter | Is there a complete Unity Launcher API somewhere? | 07:06 |
| wolter | I want to do a Pomodoro timer but I can't find stuff on connecting actions to dbusmenu items | 07:06 |
| pitti | doko_: ah no, the *.postinst/*.postrm scripts just weren't updated for libgvc5-config-update -> libgvc6-config-update, doing | 07:09 |
| tjaalton | pitti: yeah, I don't see why it couldn't be accepted upstream, and master is open again | 07:12 |
| === tkamppeter_ is now known as tkamppeter | ||
| vila | pitti: haven't tried reproducing locally yet, my hands are full :-( I strongly suspect this bug to be a test-only issue given the past similar test transient failures caused by that MP. I.e. I'm a bit afraid about spending time diagnosing more precisely and ending up with the same conclusion :-/ So if you have a way to just skip this test for the time being, that sounds like the most pragmatic thing to do | 07:59 |
| pitti | vila: bzr selftest has an -x, that should work? | 08:03 |
| vila | pitti: yup | 08:03 |
| vila | pitti: you can add that thanks to dep8 right ? | 08:03 |
| pitti | yes, in debian/tests/testsuite | 08:04 |
| vila | pitti: I dislike excluding tests instead of turning them into expected failures, but again, that's the most pragmatic here :-/ | 08:04 |
| dholbach | good morning | 08:05 |
| pitti | vila: well, the next upload can't be done without fixing it, as the package will fail to build, so that's ok | 08:05 |
| pitti | hey dholbach | 08:05 |
| dholbach | hey pitti | 08:05 |
| vila | pitti: ionce I get to the point where I can add a trusty chroot to http://babune.ladeuil.net:24842/ it will show up again anyway | 08:05 |
| vila | pitti: so nothing will be lost | 08:05 |
| pitti | vila: ack, thanks | 08:05 |
| vila | pitti: FTR, it pisses me off to not be able to look at that more closely. On a more positive side, is there a way to have bazaar@lists.canonical.com mailed when such a failure happens ? (Don't worry about not being subscribed, I'll white list when it'll happen) | 08:10 |
| pitti | vila: hm, after I hit dput it occurred to me that this probalby won't work -- the test will fail during package build so that never gets into trusty; I'll have to ignore it during package build as well | 08:11 |
| pitti | vila: usually the last uploader gets mailed for them | 08:11 |
| pitti | plus jibel and me for all of them | 08:12 |
| pitti | we don't currently have a more flexible way of subscribing, sorry | 08:12 |
| vila | pitti: no idea who the uploader is this way, ha, too bad, never mind | 08:12 |
| pitti | vila: so for now I do the "ping vila" approach if I see a failure :) | 08:12 |
| vila | s/way/day/ | 08:12 |
| vila | pitti: ok ;-D | 08:12 |
| === schmidtm_ is now known as schmidtm | ||
| zyga | good morning | 08:14 |
| doko_ | pitti, thanks | 08:15 |
| === doko_ is now known as doko | ||
| doko | slangasek, I assume the qt5 update will still take a while? | 08:16 |
| mlankhorst | morning | 08:24 |
| === frobware is now known as zz_frobware | ||
| === zz_frobware is now known as frobware | ||
| === mwhudson is now known as zz_mwhudson | ||
| zyga | can anyone confirm that python3.3-coverage program from python3-coverage package crashes on import | 09:45 |
| darkxst | oh gah, what will happen with modemmanager 1.0 in -proprosed, pretty sure there are rdepends that are non-trivial to port to the new api;( | 09:45 |
| zyga | what? | 09:49 |
| zyga | barry, doko: is python3.4 the default python now? | 09:49 |
| seb128 | doko, e-d-s failing to build ... you commented saying it uses hardening without the corresponding build-depends, but even with hardening-wrapper installed the configure hits the same "Error in `/usr/bin/ld.bfd.real': corrupted double-linked list" | 09:49 |
| zyga | python3-coverage has shebang of python3.4 | 09:49 |
| doko | seb128, can you sbeattie how to properly build with hardening-wrapper and pie? the problem is that configure calls gcc with -static -fpie | 09:50 |
| doko | in the past this did work by chance | 09:51 |
| seb128 | sbeattie, hey | 09:51 |
| doko | zyga, you can answer this question yourself by building in a trusty chroot | 09:51 |
| zyga | doko: I am running trusty and I actually followed your test rebuild archive | 09:52 |
| zyga | doko: I'm trying to understand if this is a bug or is it expected | 09:52 |
| doko | zyga, depends on what the build-dependencies are. in general, we do not want to have version specific shebangs. python3 should it be | 09:53 |
| zyga | doko: python3 is still 3.3 for me, so it seems the coverage package is broken | 09:53 |
| zyga | doko: I think coverage might be a bit special there as you want to use specific coverage if invoked as specific pythonX.Y-coverage script, it just seems those scripts are generated incorrectly (or patched incorrectly, maybe) | 09:54 |
| zyga | (specific python version, not coverage version, sorry) | 09:54 |
| doko | zyga, I'll have a look later, or I'll ask barry to have a look | 09:54 |
| pitti | barry: would you mind looking into the mailman autopkgtest failures? there are a lot of failed tests (reproducible with run-adt-test locally, so it's not a DC/networking issue) | 10:24 |
| apachelogger | how do I find out why a package is being held in trusty-proposed? | 10:33 |
| Laney | apachelogger: https://wiki.ubuntu.com/ProposedMigration is useful | 10:35 |
| Laney | there's two links at the end of the first section which contain the output | 10:35 |
| apachelogger | thanks | 10:36 |
| doko | jamespage, b-d golang-go [amd64 armhf i386] | 10:38 |
| jamespage | doko, for juju-core? not just yet | 10:38 |
| doko | ? | 10:38 |
| doko | it's dep-wait on the other archs ... | 10:38 |
| jamespage | doko, yes - and it will continue to be until I have done the work to package a separate go tool for use with gccgo | 10:39 |
| doko | ahh, ok | 10:39 |
| jamespage | doko, davecheney has something working from mainline golang with gccgo - once he's happy with that I'll package and upload | 10:39 |
| jamespage | doko, for now I'm building with both for existing archs so people can test it out and compare/contrast | 10:40 |
| === _salem is now known as salem_ | ||
| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| barry | pitti: i can look | 14:15 |
| barry | zyga: what's up? | 14:15 |
| zyga | barry: hey | 14:19 |
| zyga | barry: I think python3-coverage is busted | 14:19 |
| zyga | barry: first off, python3-coverage is running python3.4 | 14:19 |
| zyga | barry: then python3.3-coverage throws ImportError that is really odd | 14:19 |
| zyga | barry: this is on 3.7+dfsg.1-4 | 14:20 |
| barry | zyga: yep, looks like they are. can you file bugs and send me the #s | 14:20 |
| zyga | barry: certainly, filing now | 14:20 |
| zyga | barry: https://bugs.launchpad.net/ubuntu/+source/python-coverage/+bug/1270167 | 14:25 |
| ubottu | Ubuntu bug 1270167 in python-coverage (Ubuntu) "python3-coverage uses python3.4 as interpreter " [Undecided,New] | 14:25 |
| seb128 | cjwatson, hey, what determines if the grub menu should be open on boot (out of the grub config)? (I guess it writes a file somewhere that is cleaned after a successful boot to do the "open on next boot in the previous boot didnt work") | 14:26 |
| seb128 | cjwatson, I'm asking because playing with your new grub I managed to land in a position where it displays the menu at every boot now | 14:26 |
| barry | zyga: subscribed. i'll double check on debian - i'm in regular contact with the maintainer | 14:26 |
| cjwatson | seb128: right, it sets a flag using save_env before booting, which is cleared by /etc/init.d/grub-common when we get to the end of rc2 | 14:27 |
| cjwatson | using grub-editenv | 14:27 |
| seb128 | cjwatson, the only thing I did is to hammer ctrl/shift to open the menu and ctrl-alt-suppr some of the boots on plymouth beause I didn't manage to open the menu | 14:27 |
| cjwatson | seb128: check whether /etc/init.d/grub-common is actually being called at boot | 14:27 |
| seb128 | what's the easiest way to see that? logs? | 14:28 |
| cjwatson | hack it to write to some file of your choice | 14:28 |
| zyga | barry: https://bugs.launchpad.net/ubuntu/+source/python-coverage/+bug/1270168 | 14:28 |
| ubottu | Ubuntu bug 1270168 in python-coverage (Ubuntu) "python3.3-coverage crashes with ImportError on startup" [Undecided,New] | 14:28 |
| zyga | barry: thanks a lot | 14:28 |
| seb128 | ok | 14:28 |
| zyga | barry: looks like some of the multi-version magic went wrong, I read the debian packaging but it was pretty comples for what is otherwise setup.py install | 14:29 |
| zyga | complex | 14:29 |
| seb128 | cjwatson, otherwise, if that's me pressing shift that leads to open the menu, I think that it opens with the 10s timeout on manual trigger when it used to open without timeout | 14:29 |
| seb128 | cjwatson, or my testing/setup might just be buggy | 14:29 |
| cjwatson | seb128: you might also try "grub-editenv /boot/grub/grubenv list" after boot to see what that says | 14:29 |
| seb128 | cjwatson, on the good news side, boots works fine, as do recovery mode etc (my setup is a "boring" 1 disk, 1 OS, no uefi though) | 14:29 |
| seb128 | $ grub-editenv /boot/grub/grubenv list | 14:30 |
| seb128 | $ | 14:30 |
| cjwatson | seb128: timeout handling has changed around a bit, I may have to double-check that. wouldn't be a blocker though | 14:30 |
| cjwatson | seb128: pastebin /boot/grub/grub.cfg? | 14:30 |
| seb128 | cjwatson, http://paste.ubuntu.com/6768202/ | 14:31 |
| zyga | stgraber: hey, pastebinit *stilL* uses /usr/bin/env python shebang, it will still be broken in every python3 virtualenv :-( | 14:31 |
| cjwatson | seb128: and /etc/default/grub please? | 14:32 |
| seb128 | cjwatson, http://paste.ubuntu.com/6768212/ | 14:32 |
| cjwatson | seb128: Hmm, looks like 569766e4 broke this | 14:36 |
| cjwatson | seb128: Could you mention this in the bug? I'll have to try to chase this down upstream | 14:36 |
| seb128 | cjwatson, done, I'm not sure what details are useful but I guess you will fill those? | 14:39 |
| seb128 | cjwatson, let me know if you need more debug infos from my system | 14:40 |
| cjwatson | Nope, I basically just need to think very hard about the timeout stuff, again | 14:40 |
| barry | 5ols | 14:52 |
| seb128 | cjwatson, was your "commit id creating the issue" comment about the 10s timeout on manual opening or about the menu opening on boot? | 14:53 |
| seb128 | cjwatson, the grub-common script is correctly called and it seems the flag is not set from a "list" call, so I guess the menu is opening for another reason (doesn't happen anymore after downgrading to the trusty version) | 14:53 |
| seb128 | on that note, time for some exercice, be back in 1h | 14:56 |
| cjwatson | seb128: they're the same thing | 15:07 |
| === catbus is now known as Guest6323 | ||
| cjwatson | seb128: (Looking at it, I think I'm not quite correct in blaming upstream - the upstream change is trying to preserve previous upstream behaviour, and I dropped a little bit too much of the Ubuntu patch set) | 15:33 |
| stgraber | zyga: I'm pretty sure the release I made yesterday uses /usr/bin/python3 | 15:40 |
| zyga | stgraber: ah, sorry then, it's probably not on my development box yet | 15:41 |
| stgraber | zyga: yeah, I don't take care of the packaging myself, I'm just the upstream for that one. I notified the Debian maintainer but it hasn't been uploaded yet. | 15:42 |
| === awe_ is now known as awe|afk | ||
| cjwatson | seb128: OK, figured it out, fixed for the next upload | 16:34 |
| seb128 | cjwatson, great, thank you! | 16:34 |
| cjwatson | thanks for the testing | 16:36 |
| brendand | doko, my packages build is failing seemingly because python3.4 is in py3versions, but python3.4 is not there | 16:47 |
| brendand | doko, in trusty | 16:47 |
| doko | brendand, is the package b-d on the python3-all / python3-all-dev package? | 16:47 |
| brendand | doko, no - python3 (>= 3.2), | 16:48 |
| doko | brendand, which package? | 16:48 |
| brendand | doko, it's checkbox-certification. it's only in a PPA | 16:49 |
| brendand | doko, so it should b-d on python3-all? | 16:49 |
| doko | brendand, yes | 16:50 |
| rbasak | chiluk: please could you see if bug 1270151 is a possible -proposed regression on mysql-server-5.5 5.5.34-0ubuntu0.12.04.2, or just user error? | 16:52 |
| ubottu | bug 1270151 in mysql-5.5 (Ubuntu) "package mysql-server-5.5 5.5.34-0ubuntu0.12.04.2 failed to install/upgrade: le sous-processus script post-installation installé a retourné une erreur de sortie d'état 1" [Undecided,New] https://launchpad.net/bugs/1270151 | 16:52 |
| chiluk | rbasak ... sure | 16:52 |
| chiluk | rbasak doesn't look like it. | 16:54 |
| rbasak | chiluk: thanks. Often users misconfigure mysql and then apport files postinst failure bugs because the service doesn't start. So it could be that. I just noticed that it's from -proposed. | 16:54 |
| chiluk | I'll verify the upload now though. | 16:54 |
| rbasak | Thanks! | 16:54 |
| chiluk | rbasak, sure thing... I was pretty careful with that upload... so I don't have much faith that this is a regression. | 16:55 |
| cjwatson | Grr. Why does https://launchpad.net/ubuntu/+source/ruby-gettext/3.0.3-2/+build/5470350 fail but https://launchpad.net/~cjwatson/+archive/ppa/+build/5473079 (identical build in a PPA, identical set of build-dependencies installed, same version of launchpad-buildd) succeed? | 16:55 |
| cjwatson | Kernels differ but the chances of that affecting locale-ish tests seem fairly remote | 16:55 |
| cjwatson | I guess I can try hitting it with LC_ALL=C.UTF-8 but I'm a bit reluctant to do that without some way to reproduce the problem | 16:55 |
| cjwatson | Maybe if I try a devirt PPA ... | 16:57 |
| chiluk | rbasak I was able to install 12.04.1 and upgrade to 12.04.2 without issue. | 17:06 |
| rbasak | chiluk: thank you for verifying, and for doing the work! | 17:06 |
| chiluk | rbasak it is entirely possible that he does not have enough free disk space | 17:07 |
| chiluk | and the post script is failing due to the new check for free space. | 17:07 |
| chiluk | rbasak.. I also don't speek french.. so I'm not entirely sure what the error messages are saying. | 17:07 |
| rbasak | chiluk: it's a postinst failure. | 17:08 |
| rbasak | chiluk: postinst returned error status 1 | 17:08 |
| chiluk | rbasak.. I gathered that much.. I was more curious what MySQLConf.etc.mysql.my.cnf: Error: [Errno 2] Aucun fichier ou dossier de ce type: '/etc/mysql/my.cnf' | 17:08 |
| chiluk | means | 17:08 |
| rbasak | Oh | 17:09 |
| rbasak | Hmm | 17:09 |
| tarpman | chiluk: no such file or directory | 17:09 |
| chiluk | well there's your problem. | 17:09 |
| tarpman | ENOENT | 17:09 |
| rbasak | OK so that's the user. | 17:09 |
| rbasak | Thanks | 17:09 |
| * rbasak learns a little more French | 17:09 | |
| chiluk | I wouldn't expect it to function before the upgrade either. | 17:10 |
| rbasak | That seems likely. I just wanted to be sure. That makes it clear, and I'm now confident it's not a regression. Thanks! | 17:10 |
| chiluk | Google translate = "Any file or folder of this type:" ... not as helpful | 17:10 |
| rbasak | (and thanks tarpman) | 17:11 |
| tarpman | :) | 17:11 |
| rbasak | Usually I guess the translations but I didn't spot that one. | 17:11 |
| infinity | cjwatson: devirts are far more likely to have, as some point, had lp-buildd restarted or upgraded by hand, rather than started by init. | 17:12 |
| infinity | cjwatson: Which leads to the locale environment leak issue you fixed in bzr but we haven't rolled out. | 17:12 |
| cjwatson | Yeah, I was half-thinking that | 17:12 |
| cjwatson | The failure reproduces in a devirt PPA | 17:12 |
| cjwatson | So I should maybe just try to get that lp-buildd rolled out early next week rather than bothering with an upload. | 17:13 |
| infinity | cjwatson: Well, I think a package that fails its testsuite due to locale issues is still buggy. | 17:13 |
| infinity | cjwatson: It's nice for buildds to provide a consistently sane environemnt, but that's no excuse for shoddy packaging either. :P | 17:13 |
| infinity | (And easy enough to test locally by just building in C, C.UTF-8 and en_US.UTF-8 and seeing what explodes) | 17:14 |
| cjwatson | I'd be more worried about that if the failure reproduced with sbuild locally | 17:14 |
| cjwatson | But let's try it if I force LC_ALL=C | 17:14 |
| infinity | I'd be inclined to test locally in a chroot I can control and know the state of, rather than throwing random hammers at buildds who's environment I'm guessing at. | 17:15 |
| infinity | whose* | 17:15 |
| cjwatson | I'm only throwing random hammers out of desperation at being unable to reproduce the failure locally | 17:16 |
| infinity | I ran into one of these a while back that was confusing as all heck to track down. | 17:16 |
| infinity | cjwatson: I bet I can reproduce. Lemme look. | 17:16 |
| cjwatson | That's obviously where I started | 17:16 |
| cjwatson | OK. Note that you need to have a bootstrap ruby-gettext in the chroot | 17:16 |
| cjwatson | (Or available via apt sources) | 17:16 |
| infinity | Check. The one from your PPA should do, I guess. | 17:16 |
| cjwatson | Yeah, or the one from Debian | 17:18 |
| infinity | cjwatson: Okay, I apologize for questioning your science. Not only can I not reproduce, but I'm officially confused. | 17:24 |
| cjwatson | infinity: I wonder what lp-buildd's env on the builders in question actually says | 17:29 |
| infinity | Throw something at a devirt with "printenv" and "locale" in debian/rules, and aim it at toyol, so we're debugging the same machine? | 17:30 |
| cjwatson | Or I could ask a webop | 17:31 |
| infinity | Well, that doesn't get you the env during a package build. | 17:31 |
| cjwatson | Finding the env of lp-buildd would probably do | 17:32 |
| infinity | Probably. | 17:32 |
| stgraber | infinity: pushing procenv to that buildd should do the trick | 17:32 |
| cjwatson | Let me do that quickly then | 17:33 |
| infinity | Already done. | 17:34 |
| cjwatson | k | 17:34 |
| infinity | Well, once process-upload hears me. | 17:34 |
| cjwatson | Copies are usually a bit quicker :) | 17:35 |
| infinity | Yeah, I wasn't thinking. | 17:35 |
| infinity | https://launchpad.net/~adconrad/+archive/ppa/+build/5473272 | 17:39 |
| infinity | And in case i386ness matters: | 17:40 |
| infinity | https://launchpad.net/~adconrad/+archive/ppa/+build/5473275 | 17:40 |
| infinity | Hrm, and can't reproduce when mirroring that env either. | 17:44 |
| infinity | Double-U Tee Eff. | 17:44 |
| cjwatson | infinity: I can | 17:46 |
| cjwatson | - dh_auto_install | 17:46 |
| cjwatson | + LANG=C LANGUAGE=en_GB: LC_ALL=C dh_auto_install | 17:46 |
| cjwatson | reproduces it in sbuild | 17:46 |
| infinity | cjwatson: Huh. Didn't seem to break it here when I just set that in my chroot env. But yay. | 17:46 |
| infinity | Oh. Balls. My science was probably crap. | 17:47 |
| infinity | I used debuild, which I bet cleanses. | 17:47 |
| cjwatson | changing LC_ALL to C.UTF-8 is indeed sufficient | 17:49 |
| infinity | cjwatson: Or unsetting LANGUAGE would probably also do. | 17:49 |
| cjwatson | Still fails one test if I do that | 17:50 |
| infinity | Fun. | 17:50 |
| * cjwatson uploads, let's see | 17:51 | |
| === frobware is now known as zz_frobware | ||
| infinity | cjwatson: It would appear that you don't win. | 18:05 |
| cjwatson | https://launchpad.net/ubuntu/+source/ruby-gettext/3.0.3-2ubuntu1/+build/5473400 argh | 18:05 |
| cjwatson | I give up, it's dinnertime anyway. Feel free to continue beating on it if you get a chance ... | 18:05 |
| === bfiller is now known as bfiller_afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| jtaylor | can one force push scipy out of proposed? | 20:06 |
| jtaylor | its a minor test failure, and a new upstream release is due in a few days where I will skip it | 20:06 |
| jtaylor | but py3.4 scipy helps for rdepends | 20:06 |
| jtaylor | oh wait builds are against proposed anyway | 20:07 |
| jtaylor | so nevermind, didn'T think about that | 20:07 |
| === bfiller_afk is now known as bfiller | ||
| hallyn | all right this sandbox-upgrade-testing script is getting on my nerves. It's killing my nested kvm with copying host to destination... | 20:30 |
| === salem_ is now known as _salem | ||
| infinity | cjwatson: ruby-gettext hammer applied and forwarded to Debian. | 22:16 |
| === _salem is now known as salem_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!