| === jhodapp|afk is now known as jhodapp | ||
| === jhodapp is now known as jhodapp|afk | ||
| pitti | cjwatson: I'll have a look now (autopkgtests) | 05:11 |
|---|---|---|
| pitti | infinity, slangasek: looking (ddebs); we keep ddebs for 30 days, they should all still be there | 05:11 |
| pitti | cjwatson: ah yes, seems it's due to python-jenkins and oauth | 05:24 |
| === Ursinha is now known as Ursinha-afk | ||
| pitti | doko_: rails-3.2 now fails with "Could not find gem 'sqlite3 (>= 0) ruby' in the gems available on this machine" | 05:49 |
| doko_ | pitti, I love ruby ... | 05:51 |
| === Ursinha-afk is now known as Ursinha | ||
| pitti | infinity, slangasek: hm, ddeb indexes for trusty-{updates,security} do exist; maybe infinity already poked them? | 05:54 |
| pitti | although I did set up cronjobs for them last week | 05:54 |
| pitti | doko_: don't we all :/ | 05:54 |
| Mirv | regarding autopkg we're waiting most of all for unity8/unity-mir | 06:14 |
| === Ursinha is now known as Ursinha-afk | ||
| jibel | Hi, with the change of authentication in jenkins, autopkgtest are blocked (remote builds are not allowed) I'm on it with the CI team | 06:35 |
| Mirv | thanks jibel | 06:36 |
| doko_ | pitti, jibel: python3.4 autopkg test failed to fetch archive index :-/ | 06:42 |
| pitti | doko_: retrying | 06:42 |
| doko_ | but there was a real error too, | 06:42 |
| pitti | hm, no, not on #9 | 06:43 |
| pitti | doko_: http://paste.ubuntu.com/7364387/ | 06:43 |
| pitti | http://paste.ubuntu.com/7364396/ <- more complete | 06:44 |
| doko_ | pitti, I only see #8 | 06:45 |
| pitti | doko_: yes, i386 for #9 is still running, d-jenkins only copies to public jenkins once both are done | 06:45 |
| doko_ | ahh | 06:45 |
| pitti | http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-python3.4/9/ | 06:45 |
| pitti | (argh jenkins) | 06:46 |
| === maclin_ is now known as maclin | ||
| jamespage | please could someone reject juju-mongodb - still in trusty mode :-( | 07:56 |
| jibel | to unblock autopkgtest I disabled job creation, so only tests that already exist in jenkins will be triggered | 08:04 |
| cjwatson | jamespage: done | 08:18 |
| jamespage | cjwatson, thanks | 08:19 |
| cjwatson | pitti: Do you know what causes things like http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-git-annex/ARCH=i386,label=adt/9/console ? | 09:02 |
| pitti | cjwatson: yes, I do; that's very high on my TODO list | 09:02 |
| * pitti retries test in the meantime | 09:02 | |
| cjwatson | Yeah, I just did and it passed on amd64 but failed on i386 | 09:03 |
| cjwatson | So I guess it's random? | 09:04 |
| pitti | cjwatson: yes, it is | 09:04 |
| pitti | race condition in the copying back and forth of files between host and testbed | 09:04 |
| pitti | I can reproduce it reliably and know how to fix it properly | 09:04 |
| === maclin_ is now known as maclin | ||
| darkxst | infinity, no idea who is working on the cogl transition but it seems to be blocked by your block on rtmpdump? | 09:39 |
| doko | pitti, how did the ruby-defaults enter with the failing rails-3.2 test? | 09:46 |
| pitti | doko: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby-defaults doesn't show rails-3.2, so it looks like another instance of the results examination bug; jibel has a fix for that now, but it's not rolled out yet | 09:49 |
| doko | pitti, well it did show it until recently | 09:49 |
| pitti | right | 09:50 |
| pitti | that's the bug, it makes results disappear | 09:50 |
| doko | and they disappear when a new rebuild is triggered? | 09:51 |
| pitti | sometimes, yes | 09:51 |
| pitti | rather, when new results come in after finishing a new run | 09:52 |
| pitti | we see that very often now as dependencies change very fast | 09:52 |
| pitti | didn't happen all that often during trusty, so it was much harder to trigger | 09:52 |
| doko | yes, but apparently much more often for packages where rebuilds are triggered more often, like gcc ... | 09:54 |
| pitti | exactly | 09:54 |
| pitti | that's why we saw it on libgcc1 last cycle, etc. | 09:54 |
| pitti | and regularly on eglibc uploads | 09:55 |
| doko | who needs to be told about the new ubuntu version for links in http://packages.qa.debian.org/ ? | 10:10 |
| knome | doko, balloons | 10:12 |
| doko | balloons, ^^^ please search the recent version in utopic, not trusty | 10:14 |
| cjwatson | since when was balloons responsible for packages.qa.debian.org? the Ubuntu versions there are a UDD thing | 10:20 |
| knome | oh, oops. | 10:21 |
| * knome facepalms | 10:21 | |
| cjwatson | let me see, I think I can at least change the source | 10:22 |
| doko | or file a bug for qa.debian.org? | 10:23 |
| cjwatson | well, I've pushed the necessary change | 10:23 |
| cjwatson | You could but a bit late :) | 10:23 |
| doko | ok, thanks | 10:23 |
| cjwatson | Laney: Do I need to deploy ubuntu-releases.yaml changes manually, or is it done automatically? | 10:24 |
| * Laney disclaims all knowledge | 10:24 | |
| Laney | wait | 10:24 |
| Laney | that's a change to UDD? | 10:24 |
| Laney | (thought it was to the PTS itself) | 10:24 |
| Laney | you need to pull on ullmann | 10:25 |
| cjwatson | You were the last person to change that files | 10:25 |
| cjwatson | *file | 10:25 |
| cjwatson | OK, let me see if I have access | 10:25 |
| Laney | Can do it if you don't | 10:25 |
| Laney | I don't think I was aware that this is the file the PTS uses | 10:25 |
| cjwatson | The PTS uses UDD for that, yeah | 10:26 |
| cjwatson | Laney: I'm not in uddadm and don't have sudo to udd, so if you could pull that'd be great, thanks | 10:27 |
| Laney | done | 10:28 |
| cjwatson | ta | 10:28 |
| cjwatson | doko: should update itself in about four hours | 10:31 |
| cjwatson | 30 2,8,14,20 * * * cd /srv/packages.qa.debian.org/www && nice -15 flock -n .do_all.lock bin/do_all.sh | 10:31 |
| doko | pitti, should systemd-services be demoted? | 10:50 |
| pitti | doko: it's NBS, can go away | 10:50 |
| pitti | doko: I'll deal with the remaining rdepends | 10:51 |
| cjwatson | NBS won't go away until the rdepends do | 10:51 |
| pitti | yes, that's why I wonder why it's already on c-m | 10:51 |
| pitti | e. g. gnome-settings-daemon still recommends it without alternative | 10:51 |
| pitti | doko: but if you don't mind I'll do that cleanup later, I'm currently working on the various autopkgtest SNAFUs | 10:52 |
| pitti | for now systemd has a C/R/P: systemd-services | 10:52 |
| pitti | ah, that's probably why it's in c-m | 10:52 |
| doko | sure | 10:52 |
| cjwatson | NBS isn't totally accurate of course | 10:53 |
| === jhodapp|afk is now known as jhodapp | ||
| arges | Hi. the package in -proposed for neutron/saucy has the wrong bug number. Do we need to remove from -proposed and reupload? | 12:45 |
| arges | infinity: cjwatson ^^^ | 12:47 |
| pitti | arges: if it's in the unapproved queue, yes; once it got accepted, no; but hopefully it didn't get accepted with a wrong bug ref? | 12:48 |
| arges | pitti: it did get accepted with the wrong bug ref. : ( | 12:48 |
| pitti | arges: https://launchpad.net/ubuntu/saucy/+queue?queue_state=1 doesn't have a neutron package though, so I guess it did get accepted? | 12:48 |
| pitti | arges: so in theory we can also remove it from saucy-proposed, but you need a new upload with a higher version number anyway | 12:49 |
| pitti | as that version number is now used | 12:49 |
| cjwatson | I would probably remove and reupload, although it's possible (just annoying) to avoid that | 12:49 |
| cjwatson | you would need to remove the old entry from the changelog if doing that | 12:50 |
| cjwatson | or retrospectively edit it | 12:50 |
| arges | cjwatson: ok how is that accomplished? I think jamespage would appreciate it since they've already verified all openstack packages | 12:50 |
| cjwatson | how is which accomplished? | 12:51 |
| cjwatson | I gave two options :) | 12:51 |
| arges | Avoiding a removal and re-upload. | 12:51 |
| cjwatson | sru-release and then go around reopening bugs | 12:51 |
| cjwatson | and closing the proper ones | 12:51 |
| cjwatson | but I'd still recommend retrospectively editing the changelog in whatever branch is appropriate, for future uploads | 12:51 |
| cjwatson | so that eventually users can see the right thing | 12:51 |
| arges | cjwatson: ok so the changelog edit would be an SRU on top of the existing one? | 12:52 |
| arges | the retrospective changelog edit that is | 12:52 |
| cjwatson | you wouldn't SRU just for that, just make sure it's in the next upload | 12:53 |
| cjwatson | it being neutron I assume there will eventually be one | 12:53 |
| arges | cjwatson: ok sounds good. Thanks | 12:53 |
| jamespage | cjwatson, arges: OK - I'll do the branch edit now | 12:54 |
| jamespage | arges, done | 12:56 |
| infinity | pitti: I fixed it yesterday, yes. Your crontab lacked -updates. | 13:07 |
| pitti | infinity: ah, thanks | 13:09 |
| infinity | pitti: It was a bit embarassing how long I spend grepping and reading bits of your source before I realised it was just a missing argument to the cron job. :P | 13:11 |
| infinity | s/spend/spent/ | 13:11 |
| pitti | infinity: heh, sorry about that | 13:12 |
| infinity | pitti: And now the crontab is gone? | 13:15 |
| infinity | pitti: Did you just delete it, or am I on crack? | 13:15 |
| infinity | Oh, or I can't type. | 13:16 |
| infinity | La la la. | 13:16 |
| infinity | pitti: Ignore me. Waking up hurts. | 13:16 |
| pitti | infinity: forgot the sudo? :-) | 13:20 |
| infinity | pitti: No, can't type "crontab" and mistook bash's "not found" for crontab telling me there wasn't one. :P | 13:21 |
| infinity | (corntab -l) | 13:21 |
| ogra_ | yummy | 13:21 |
| pitti | infinity: sounds like breakfast cereal to me | 13:22 |
| ogra_ | ++ | 13:22 |
| === Ursinha-afk is now known as Ursinha | ||
| ogra_ | whee ! | 14:58 |
| sil2100 | Yeaaah, needs NEWing still though... o/ | 15:01 |
| === jhodapp is now known as jhodapp|lunch | ||
| === seelaman` is now known as seelaman | ||
| doko | pitti, jibel: please restart the rails-3.2 autopkg test | 16:45 |
| xnox | doko: if you have vpn, you can use launchpad SSO login and restart yourself these days =) | 16:45 |
| doko | xnox, ohh | 16:46 |
| xnox | doko: we've finally migrated to launchpad teams for managements and ~ubuntu-archive & canonical-foundations are part of it. | 16:46 |
| xnox | doko: rails-3.2 rescheduled. | 16:47 |
| xnox | doko: cause it might take a while figuring out vpn/dns/sso first time around =) but the incentives are there. | 16:48 |
| infinity | I don't bother with fancy VPN stuff, I just sshuttle to batuan, and add d-jenkins.ci to /etc/hosts, works well. | 16:50 |
| xnox | infinity: =)))) nice. does sso work with sshuttle? | 16:50 |
| infinity | xnox: Why wouldn't it? | 16:50 |
| xnox | true. | 16:50 |
| xnox | yeah, it just needs dns for callback. | 16:51 |
| xnox | (redirect) | 16:51 |
| xnox | doko: all green now. | 16:51 |
| doko | good, ruby-2.1 is the default. now let's the server team fix puppet ;p | 16:52 |
| dbarth | hello, me again for some SRU requests ;) | 17:33 |
| dbarth | if someone can scan webbrowser-app for this merge/bug: https://bugs.launchpad.net/webbrowser-app/+bug/1302780 | 17:34 |
| ubot2 | Launchpad bug 1302780 in webbrowser-app (Ubuntu Trusty) "[webapp-container] Google Apps For Business support when using an external SSO provider" [High,Fix committed] | 17:34 |
| dbarth | i'd like it to move to -proposed to release further webbrowser-app updates on trusty; thanks in advance | 17:35 |
| === jhodapp|lunch is now known as jhodapp | ||
| robru | infinity, hi, just wondering about gst-plugins-bad1.0. any chance we can get that landed in utopic? | 20:19 |
| infinity | robru: We can look into dropping the blocks and seeing how britney does, yeah. For a while, it was spending ~4h per run just to tell us that some transitions weren't ready yet. | 20:25 |
| robru | infinity, yeah, if you could I'd appreciate it. we got ourselves into another one of those situations where somebody was expecting a silo to be atomic, and then gst-plugins-bad1.0 got stuck in proposed while the rest of the silo didn't, leaving utopic in an inconsistent state. | 20:26 |
| xnox | infinity: won't work. | 20:27 |
| xnox | infinity: so everything would still be blocked on getfem++ not able to launch scilab on powerpc. | 20:27 |
| xnox | infinity: i can upload getfem++ with scilab portion disabled on powerpc for now, and then gremove getfem-scilab on powerpc, and then we can drop all the blocks and everything should be able to migrate. | 20:27 |
| xnox | or like force getfem-scilab to be uninstallable | 20:28 |
| xnox | (demote to proposed?) | 20:28 |
| robru | xnox, oh please, yes | 20:29 |
| infinity | robru: No one should expect silos to migrate atomically. If migration of individual bits breaks, that should be reflected in the dependencies. | 20:29 |
| infinity | robru: Partial upgrades are a fact of life in Debian packaging, ignoring that does no one any favours. | 20:29 |
| robru | infinity, yes, I know that, but we have a hard time coordinating that with upstreams (also we are bad at pridicting what will get stuck in proposed and what will fly right through) | 20:29 |
| infinity | xnox: Hrm, let me see this mess you speak of. | 20:29 |
| infinity | robru: Sure, but even if stuff "flies through", there's no guarantee that users won't upgrade just one bit, and if your deps let them and that breaks, boom. | 20:30 |
| xnox | bug #1314646 | 20:30 |
| ubot2 | Launchpad bug 1314646 in scilab (Ubuntu) "scilab fails to launch on powerpc" [Undecided,New] https://launchpad.net/bugs/1314646 | 20:30 |
| infinity | robru: OOI, what actually breaks? | 20:30 |
| robru | true | 20:30 |
| infinity | robru: It shouldn't be hard for people to know "I'm relying on feature X from Package Y, so I must depend on it". | 20:31 |
| robru | infinity, not actually sure what will break. i just noticed we have a silo with *NINE* different source packages, eight of which made it to the archive. | 20:31 |
| infinity | robru: This sort of thing bites people years later when we're testing lts->lts upgrades, and realise a postinst depends on a new feature, and unpack order isn't what you thought, etc. | 20:31 |
| infinity | robru: If nothing actually breaks, you might be worrying about, well, nothing. :) | 20:31 |
| robru | infinity, the trick I think is predicting ci-train's autogenerated version numbers. Hard to write a dependency against a version number you don't know ahead of time | 20:31 |
| infinity | robru: You know the upstream snapshot date where the new feature happened. | 20:32 |
| infinity | robru: So you can do Breaks/Depends based on those. | 20:32 |
| xnox | infinity: so because of that bug getfem++ FTBFS, and it needs to rebuild to unblock scalapack and cogl transitions i believe, which entangle gpsd & plist, but i think not librtmp1&libraw. | 20:32 |
| infinity | Caused by: java.lang.RuntimeException: Incompatible MachineDescriptions: | 20:32 |
| infinity | Static MachineDescriptionStatic: X86_32_UNIX(1): MachineDescription: runtimeValidated false, littleEndian true, 32Bit true, primitive size / alignment: | 20:32 |
| xnox | infinity: hm, drop the blocks you committed and lets see how long britney grinds for - and whether stuff migrates or not. | 20:32 |
| infinity | xnox: ^ on powerpc, you say? :P | 20:32 |
| robru | infinity, yes it's all true. but all I know is that I woke up this morning and I've got this silo and one of the packages is stuck in proposed. I'm just assuming that the people that started this landing really do want to get this gst-plugins-bad update in ;-) | 20:33 |
| xnox | infinity: yes, on powerpc. I'm failing to trace where X86_32 is coming from - regression in openjdk, scilab, or some components in between. | 20:33 |
| xnox | infinity: it also fails in debian and trusty. | 20:33 |
| infinity | xnox: That's pretty amazingly special. | 20:33 |
| infinity | xnox: I'll try to look at that after this unblock experiment. | 20:34 |
| xnox | infinity: oh, and scilab has it's test-suite disabled, which does catch above failure if enabled.... | 20:34 |
| infinity | xnox: Of course. :( | 20:34 |
| xnox | infinity: if i had root chroot on a powerpc machine, i'm happy to investigate further to see who the real culprit is. | 20:35 |
| infinity | World unblocked. Let's see if britney has a heart attack. | 20:35 |
| infinity | xnox: Why would you need root? | 20:35 |
| xnox | infinity: well ability to either (a) modify sources or (b) install packages with $ sudo dpkg -i -> i'd want to see if downgrading openjdk helps and/or running older scilabs. Cause i can't be bother to run java apps from unpacked debs =) | 20:36 |
| doko | infinity, xnox: this is Sylvestre's go and run strategy :-/ | 20:40 |
| xnox | doko: well, i've tested that late scilab update in trusty. but not on powerpc, evidently. | 20:40 |
| infinity | I'd be amazed if it worked anywhere !x86, based on that output. | 20:41 |
| infinity | Except possibly by sheer luck of matching endian and bitness. | 20:41 |
| doko | yeah, but scilab is plain broken, and I only scratched the worst autotools sins | 20:41 |
| infinity | Or something. | 20:41 |
| xnox | infinity: there is one more option - > hack the hell out of getfem++ build-system to build using CLI scilab (which does work everywhere) without trying to initialise any of the gui components (which fail on powerpc as above) | 20:41 |
| xnox | my baby attempts at hacking scilab scripts did make it run half-way and then eventually fail. | 20:42 |
| doko | well, he was employed as Scilab release manager, now he is employed as firefox release manager ... | 20:43 |
| infinity | ... | 20:43 |
| infinity | Time to switch browsers? | 20:43 |
| xnox | infinity: funny you should say that, apperately oem teams are building images with chromium for some folks. | 20:44 |
| infinity | xnox: Yeah, chrome and I don't even remotely get along. Hopefully Mozilla's current release processes aren't perverted by this hire. :P | 20:45 |
| infinity | xnox: I'll have a quick poke at scilab, but if we must, we can disable the scilab bits on ppc for now. | 20:46 |
| infinity | xnox: Since the getfem++ packaging already allows for that for other arches where scilab sucks^wisn't ported. | 20:47 |
| xnox | infinity: yeap. | 20:47 |
| xnox | infinity: how is britney doing? did you kick off a manual run? | 20:48 |
| infinity | Just started. | 20:49 |
| Laney | AIEEEE | 20:53 |
| infinity | Yeah, that's what I was afraid of. | 20:54 |
| xnox | what happened? | 20:55 |
| xnox | maybe you can unblock on thing at a time? or block all haskell. | 20:55 |
| Laney | watch http://people.canonical.com/~ubuntu-archive/proposed-migration/log/2014-04-30/20:48:14.log | 20:55 |
| xnox | but openjpeg transition is at 100% as per current tracker.... http://people.canonical.com/~ubuntu-archive/transitions/html/openjpeg.html | 20:56 |
| xnox | hint things together? | 20:56 |
| xnox | infinity: hint openjpeg with gst-plugins-bad1.0 and libav? | 20:56 |
| xnox | and calligra? | 20:57 |
| infinity | It would need a lot more than those, surely? | 20:57 |
| xnox | infinity: well, all those from http://people.canonical.com/~ubuntu-archive/transitions/html/openjpeg.html there are only 13 packages that depend on libopenjpeg2 in the archive. | 20:59 |
| infinity | xnox: But if openjpeg is tied to another transition, hinting those 13 won't help. | 20:59 |
| xnox | right. | 21:00 |
| xnox | and it is. | 21:00 |
| Laney | I'm guessing that is why the overflow is happening | 21:01 |
| infinity | Yeah. | 21:01 |
| Laney | looks like the autohinter tried ~xnox's suggestion anyway, and it failed | 21:01 |
| infinity | I might let this run to completion and put together all the autohinter's attempts into one larger hint. | 21:01 |
| xnox | infinity: why doesn't it skip after first counter overflow. | 21:01 |
| xnox | ? | 21:01 |
| infinity | xnox: You're asking my like I wrote it. The code's public, go ask it. :P | 21:02 |
| xnox | =)))))))) | 21:02 |
| infinity | I assume it's walking different dep trees each time to produce a workable graph. | 21:02 |
| xnox | infinity: i don't touch girls. | 21:02 |
| Laney | proposed-migration is a boys name | 21:03 |
| infinity | Seems pretty gender-neutral to me. | 21:03 |
| xnox | fair enough. ooh marble came up from gpsd try. | 21:04 |
| xnox | hm, it was rebuild against gps | 21:05 |
| infinity | Looks like cinnamon still wants a cogl rebuild too. | 21:05 |
| xnox | infinity: cinnamon is in -proposed only. | 21:05 |
| infinity | Sure, just sayin'... | 21:06 |
| xnox | in ftbfs against gjs/gnome3.10 stack, not sure if it is buildable now ( i think we got new gjs) | 21:06 |
| infinity | Oh look, cogl migrated. | 21:06 |
| infinity | But not a whole lot else. | 21:07 |
| xnox | shapelib mini transition. | 21:08 |
| infinity | Anyhow, that runtime was acceptable even with the AIEEEs, so I'll leave things unblocked for now, and we can see about trying to ease the pain. | 21:09 |
| infinity | Well, "acceptable"... It wasn't 4 hours. | 21:09 |
| * infinity goes to find something to eat and/or drink before his head explodes. | 21:10 | |
| === jhodapp is now known as jhodapp|afk | ||
| xnox | arges: on bug #1313712 somehow there is not "verification-needed" tag which should be added when package is accepted into -proposed pocket. | 22:50 |
| ubot2 | Launchpad bug 1313712 in libselinux (Ubuntu Trusty) "Trusty's libselinux1 causes issues with Precise's upstart during dist-upgrade" [High,Fix committed] https://launchpad.net/bugs/1313712 | 22:50 |
| xnox | arges: somebody else verified it already, so i'll just tag it verification-done. | 22:50 |
| infinity | xnox: If you're going to forward that fix to Debian, please use the version from libc6.postinst, not yours. | 22:59 |
| infinity | xnox: Yours isn't other-init-friendly. | 22:59 |
| xnox | infinity: yeah, it needs an extra is_init_upstart guard. | 23:00 |
| infinity | xnox: Or just use my version. :P | 23:00 |
| xnox | infinity: yeah. or that. | 23:00 |
| xnox | gpsd migrated, the rest still generating piles of doom. | 23:40 |
| xnox | shapelib also migrated. | 23:42 |
| infinity | Well, we're getting there. gpsd used to be one of the overflows. | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!