=== anthonyf is now known as Guest33778 | ||
=== salem_ is now known as _salem | ||
=== marcusto_ is now known as marcustomlinson_ | ||
=== marcustomlinson_ is now known as marcustomlinson | ||
pitti | mhall119: that sounds a bit like our merge-o-matic? | 05:09 |
---|---|---|
pitti | Good morning | 05:09 |
pitti | infinity, Laney: can we please ignore the broken tests for linux 4.0.0-2.4 as well? | 05:10 |
infinity | pitti: It's broken for other reasons, we're not letting it migrate right now. | 05:12 |
infinity | pitti: But if you want to ignore it for something waiting on it, sure. | 05:13 |
pitti | infinity: ok; but it blocks other packages | 05:13 |
infinity | pitti: Fixing. | 05:13 |
pitti | infinity: cheers! | 05:13 |
pitti | jdstrand: I'm merging libseccomp2 again (it's rather trivial), I need Debian's -2 to unbreak separate /usr; I hope you don't mind? | 05:33 |
sarnold | pitti: that's almost certainly fine, the last changelog entry looks like there's not many local changes remaining | 05:38 |
pitti | sarnold: no, just adding the autopkgtest | 05:39 |
pitti | and the only change in -2 is to move the library from /usr to /lib | 05:39 |
sarnold | pitti: at least, jdstrand's usually good about keeping his changelogs precise and accurate :) | 05:39 |
pitti | sarnold: yes, and the patches.u.c. diff agrees with him :) | 05:39 |
sarnold | pitti: are the 'new' library paths still covered by the apparmor <abstractions/base> file? | 05:40 |
pitti | sarnold: oh, do we do per-library paths in apparmor? /me checks | 05:40 |
pitti | grep -r seccomp /etc/apparmor* → no hits | 05:40 |
sarnold | pitti: not usually.. I ust wanted to make sure that these weren't going someplace unexpected :) | 05:40 |
pitti | no, just the standard /lib/x86_64-linux-gnu/ (or whatever the architecture is) | 05:41 |
sarnold | pitti: how have I been here nearly three years and never seen patches.ubuntu.com??? this is awesome. thanks. :) | 05:41 |
pitti | like libc.so.6 or libdbus and stuff | 05:41 |
pitti | sarnold: heh -- it's a by-product of MoM (merges.ubuntu.com) | 05:41 |
sarnold | this is cool, I've thought before that relying upon the changelog to keep track of the ubuntu/debian delta was prone to mistakes. this is great :) | 05:43 |
pitti | sarnold: but you did see MoM, I hope? that also gives you both diffs | 05:44 |
sarnold | pitti: I think I've only ever seen the summary universe.html and so on there.. | 05:44 |
dholbach | good morning | 07:11 |
dkessel | good morning dholbach | 07:13 |
dholbach | hey dkessel | 07:16 |
dholbach | mitya57, did you upload ubuntu-packaging-guide already? | 07:22 |
mitya57 | dholbach, oops, I forgot :/ | 07:23 |
mitya57 | Will do now :) | 07:23 |
dholbach | awesome, thanks! | 07:23 |
mitya57 | dholbach, uploaded (will be in NEW queue though) | 07:51 |
dholbach | thanks a lot mitya57! | 07:52 |
mitya57 | Sorry for forgetting :) | 07:52 |
dholbach | no worries :) | 07:52 |
infinity | pitti: What's the state of the art on reproducing adt failures locally? | 08:05 |
pitti | infinity: hasn't changed in a long time -- easiest is to use the qemu runner | 08:05 |
pitti | infinity: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test | 08:05 |
pitti | infinity: the biggest difference is the internet proxy that we (have to) use in production | 08:06 |
pitti | otherwise it's pretty much exactly the same | 08:06 |
infinity | pitti: Kay. Can I run a single test there, or will it just run everything in debian/tests/control unconditionally? | 08:06 |
pitti | infinity: you can use --testname to run a single test | 08:06 |
infinity | pitti: Shiny. Thanks. | 08:06 |
pitti | adt-run --testname mytest1 mysrc | 08:06 |
pitti | infinity: and usually you want -s too | 08:07 |
pitti | (--shell-on-failure) | 08:07 |
infinity | pitti: I think I had all this going at one point, then new laptop happened. | 08:07 |
pitti | infinity: well, it's really just one "adt-buildvm-ubuntu-cloud" command away :) | 08:07 |
pitti | infinity: and yeah, getting new laptop beats destroying a throwaway VM any time :) | 08:08 |
infinity | Apparently, cloud-images.ubuntu.com is connected to the internet with a bendy straw. | 08:08 |
pitti | oh, is it slow for you? | 08:09 |
infinity | pitti: Around 1MB/s, looks like. | 08:09 |
infinity | pitti: So, slow for me. | 08:09 |
pitti | up to vivid it was reasonably fast here, then in April/May it was ridiculously slow, and now it magically fixed itself again to be as moderately-fast as before | 08:09 |
pitti | infinity: so, best not to look at it :) | 08:09 |
infinity | A watched image never downloads? | 08:10 |
Odd_Bloke | infinity: Are you connected to the VPN; I've sometimes seen image downloads routed through that. | 08:17 |
Odd_Bloke | s/the VPN/the Canonical VPN/ | 08:17 |
Odd_Bloke | Which is obviously sloooow. | 08:17 |
infinity | pitti: If I'm just experimenting with debian/tests, I assume I want something like '--unbuilt-tree foo-1.2.3-1 -B'? | 08:17 |
infinity | Odd_Bloke: Yeah. Until we fix it to allow me to be connected to both endpoints, that's probably my issue. | 08:18 |
infinity | Odd_Bloke: I do occasionally forget I have that issue, though. :P | 08:18 |
pitti | infinity: put the -B before (it only applies to the next test argument), but in principle yes | 08:19 |
pitti | infinity: I usually use something like "adt-run ./ --- qemu ...", typing laziness | 08:19 |
pitti | infinity: <dir>/ is an abbreviation for --built-tree <dir> | 08:19 |
pitti | and <dir>// for --unbuilt-tree <dir> | 08:19 |
pitti | greetings from iwj from 9 years ago :) | 08:20 |
infinity | pitti: Hahaha. | 08:23 |
infinity | pitti: FWIW, --testname isn't documented in the manpage. | 08:28 |
infinity | pitti: Erm, and my first derp. Clearly this isn't performing exactly how prod does... | 08:31 |
infinity | Source Package Version: 4.0.0-2.4 | 08:31 |
infinity | Running Kernel Version: 3.19.0-20.20 | 08:31 |
infinity | ERROR: running version does not match source package | 08:31 |
pitti | infinity: man> thanks, fixed in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=16eb56eac | 08:32 |
pitti | infinity: well, production gets called on a source package; I assume your test that does this comparison is newer than the binaries in wily? | 08:33 |
pitti | infinity: i. e. if your --built-tree is newer, you also need to include the newer .debs in the adt-run to run against those instead of wily's binaries | 08:33 |
infinity | pitti: I'm running against a source package that matches the binaries in wily-proposed. Which means the testbed needs to upgrade and reboot. Which I assume it does in prod. | 08:33 |
pitti | infinity: or enable proposed | 08:34 |
infinity | pitti: proposed is enabled on the commandline. | 08:34 |
pitti | infinity: yes, that's mentioned on http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test | 08:34 |
infinity | Oh, wait, maybe I missed -U | 08:34 |
infinity | Let's see if that fixes it. | 08:34 |
pitti | infinity: yes, --apt-pocket only adds the apt source, doesn't run apt-get | 08:35 |
infinity | pitti: Yeah, bad copy-pasta on my part. | 08:36 |
infinity | Ahh, lovely. | 08:36 |
infinity | adt-run [02:36:44]: rebooting testbed after setup commands that affected boot | 08:36 |
infinity | That looks more promising. | 08:36 |
mardy | mvo: hi! Do you have some minutes to help me investigate bug 1454210? | 09:20 |
ubottu | bug 1454210 in webapps-sprint "accounts are lost each time the app is updated from the store or run on the device from qtc" [High,Triaged] https://launchpad.net/bugs/1454210 | 09:20 |
mvo | mardy: let me have a look | 09:23 |
mvo | mardy: that bug is confusing, so it only removes evernote accounts but nothing else? click does not touch userdata (yet) on upgrade. it will stop the app though | 09:27 |
mardy | mvo: so, we have a click hook in OA, which has a pattern to copy some files to ~/.local/share/online-accounts-hooks/ | 09:29 |
mardy | mvo: then we have a hook processor which reads these files and generates a more elaborated version under ~/.local/share/accounts/providers/ | 09:30 |
mardy | mvo: this hook processor also takes care of removing stale files and accounts, when the corresponding app gets removed | 09:30 |
mardy | mvo: the way it works, is that it scans ~/.local/share/accounts/providers/, and then it tries to find the corresponding originating file in ~/.local/share/online-accounts-hooks/ | 09:31 |
mardy | if it doesn't find it, then it deduces that the app has been removed, and therefore removes the file in ~/.local/share/accounts/providers/ and any created accounts | 09:31 |
mardy | mvo: does this sound correct to you? ^ | 09:32 |
mardy | mvo_: did you miss some lines? | 09:32 |
mvo_ | mardy: sorry, network issues, the last I got was "seconds) | 09:32 |
mvo_ | <mardy> mvo: this hook processor also takes care of removing stale files and accounts, when the corresponding app gets removed" | 09:32 |
mardy | mvo_: ok, I'll repaste | 09:32 |
mardy | mvo_: the way it works, is that it scans ~/.local/share/accounts/providers/, and then it tries to find the corresponding originating file in ~/.local/share/online-accounts-hooks/ | 09:32 |
mardy | mvo_: if it doesn't find it, then it deduces that the app has been removed, and therefore removes the file in ~/.local/share/accounts/providers/ and any created accounts | 09:33 |
mardy | mvo_: does this sound correct to you? ^ | 09:33 |
mardy | mvo_: the files are named after the short app id (that is, without the version number) | 09:33 |
mvo_ | mardy: yes, makes sense | 09:34 |
mvo_ | mardy: so one fix would be for click to behave differently I guess - I need to look first why its doing what its doing | 09:34 |
mardy | mvo_: mmm... actually, wait... the hook pattern we use keeps the version number | 09:34 |
mardy | mvo_: ok, I guess that I have something to fix there, I should try to match the unversioned file | 09:35 |
mvo_ | mardy: ok, thanks. let me know how it goes and good luck :) | 09:35 |
mardy | mvo_: ok, if you don't here from me, then all it's good on your side :-) | 09:35 |
mvo_ | :) | 09:36 |
mvo_ | ok | 09:36 |
jamespage | please could an archive-admin merge lp:~james-page/+junk/sync-backlist-openstack into the sync backlist - some updates for openstack projects | 09:46 |
jamespage | thanks | 09:47 |
cjwatson | jamespage: I remain confused why we're blacklisting these at all. | 09:51 |
cjwatson | jamespage: Surely we have "ubuntu" substrings in our versions. | 09:51 |
jamespage | cjwatson, I'm happy just to drop them all tbh - I just tripped on trying to sync a client package from debian | 09:52 |
jamespage | cjwatson, you are quite correct - they would always show as a merge | 09:52 |
jamespage | cjwatson, ok I've dropped all openstack packages from my branch - ok to go with that? | 09:54 |
cjwatson | jamespage: The only one there might be any justification for would be openstack-meta-packages | 09:54 |
cjwatson | jamespage: Do you want that to pop into wily? | 09:54 |
jamespage | cjwatson, let me check on openstack-meta-packages | 09:55 |
infinity | jamespage: openstack-meta-packages probably conflicts conceptually with the "openstack" package that I'm waiting on stokachu to reupload. | 10:24 |
infinity | jamespage: It doesn't actually conflict, but I imagine confusion if we ship both. | 10:25 |
jamespage | infinity, ok - lets leave that blacklisted still - I think it relies on a load of features in the debian versions of those packages we don't support in ubuntu | 10:38 |
jamespage | infinity, cjwatson: lp:~james-page/+junk/sync-backlist-openstack updated | 10:40 |
caribou | Q: When adding an upstart job to an existing package, does the sysVinit script get automatically inhibited or we need to add the 'init_is_upstart' override ? | 10:43 |
ogra_ | caribou, for what release ? | 10:44 |
caribou | ogra_: Trusty | 10:44 |
ogra_ | upstart is gone (for system statup) | 10:44 |
ogra_ | ah | 10:44 |
caribou | ogra_: yeah, I know it's for a Trusty SRU | 10:44 |
caribou | ok, I think I found the answer : | 10:45 |
caribou | when the package is installed with an upstart job, the sysVinit script is installed but not enabled | 10:46 |
caribou | I'll put the override, in case someone enable the script by accident | 10:47 |
cjwatson | jamespage: merged; give it 5min or so to propagate before you try syncpackage again | 10:47 |
cjwatson | caribou: You should follow https://wiki.ubuntu.com/UpstartCompatibleInitScripts | 10:47 |
caribou | cjwatson: thanks for the URL | 10:48 |
jamespage | cjwatson, thankyou | 10:52 |
=== soee_ is now known as soee | ||
=== MacSlow is now known as MacSlow|lunch | ||
=== _salem is now known as salem_ | ||
=== MacSlow|lunch is now known as MacSlow | ||
rbasak | infinity: around? docker.io backports incoming. Preview in https://launchpad.net/~docker-maint/+archive/ubuntu/staging/+packages - do you want me to just throw all of this at the SRU queues? | 12:42 |
rbasak | infinity: bug is https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1454719 - shall I create a task for each package being backported? | 12:42 |
ubottu | Ubuntu bug 1454719 in docker.io (Ubuntu Vivid) "docker.io update to 1.6.1" [Wishlist,Triaged] | 12:42 |
=== anthonyf is now known as Guest64410 | ||
infinity | rbasak: Should be tasks for everything, yes. | 12:48 |
rbasak | infinity: OK bug updated and everything is in the queue now | 13:12 |
infinity | rbasak: Ta. | 13:13 |
LocutusOfBorg1 | Hi Folks, I see libjsoncpp still in universe pocket, is it normal? | 13:32 |
LocutusOfBorg1 | talking about bug 1461517 and comment #3 | 13:32 |
ubottu | bug 1461517 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Fix committed] https://launchpad.net/bugs/1461517 | 13:32 |
LocutusOfBorg1 | there is a serious bug against libjsoncpp and I merged in Debian the relevant delta | 13:33 |
LocutusOfBorg1 | so I would like to ask a plain sync ASAP | 13:33 |
LocutusOfBorg1 | but I don't know how this deals with the MIR request | 13:33 |
infinity | LocutusOfBorg1: I'll have a look at both. | 13:34 |
LocutusOfBorg1 | infinity, it's almost dinstall time in debian | 13:34 |
LocutusOfBorg1 | so the sync is not possible (yet) I guess ;) | 13:34 |
LocutusOfBorg1 | thanks! | 13:34 |
doko | wgrant, stealing your ustr merge | 13:34 |
mhall119 | pitti: I'm not familiar with merge-o-matic | 13:35 |
infinity | LocutusOfBorg1: Where's this new cmake that the MIR talks about? | 13:35 |
LocutusOfBorg1 | -proposed I guess | 13:35 |
infinity | Oh, so it is. | 13:36 |
LocutusOfBorg1 | https://launchpad.net/ubuntu/+source/cmake/3.2.2-2ubuntu1 | 13:36 |
infinity | component-mismatches-proposed isn't showing the promotion. Grr. | 13:36 |
LocutusOfBorg1 | (I feel guilty for the cmake merge, this is why I'm bothering so much :p ) | 13:36 |
infinity | LocutusOfBorg1: Guilt is a good motivator. | 13:37 |
LocutusOfBorg1 | :) | 13:37 |
LocutusOfBorg1 | and the love for cmake is a good motivator for a merge | 13:37 |
infinity | LocutusOfBorg1: Tell me more about this "broken shlibs file" fixed in -4... | 13:38 |
infinity | LocutusOfBorg1: Is it so broken that we don't want things building against -3? | 13:38 |
infinity | LocutusOfBorg1: Should I remove it from -proposed? | 13:39 |
LocutusOfBorg1 | yes, exactly | 13:39 |
LocutusOfBorg1 | that would be awesome | 13:39 |
LocutusOfBorg1 | it isn't generating the shlibs:depends correctly, so packages built against libjsoncpp-dev won't depend on libjsoncpp0 | 13:39 |
infinity | LocutusOfBorg1: Oh, that's quite unfortunate. Do we know if anything's been built with that breakage so far? :/ | 13:40 |
LocutusOfBorg1 | please look at the debian bug in -release | 13:40 |
LocutusOfBorg1 | I can do something similar for ubuntu | 13:40 |
LocutusOfBorg1 | anyway I guess the answer is "nothing" | 13:41 |
infinity | LocutusOfBorg1: If you could check the rdeps and see if anything was built against the broken version, that would be great. | 13:42 |
infinity | LocutusOfBorg1: Hopefully, the answer is no, but best to know. | 13:42 |
infinity | LocutusOfBorg1: And I've removed it from -proposed for now. -4 can be synced when LP learns about it. | 13:42 |
LocutusOfBorg1 | sysdig is built against the old jsoncpp | 13:43 |
LocutusOfBorg1 | thanks | 13:43 |
=== rickspencer3_ is now known as rickspencer3 | ||
infinity | LocutusOfBorg1: sysdig is broken on ARM anyway, can kill two birds with one stone by just deleting it and waiting for a new Debian sync that fixes that. :P | 13:46 |
infinity | LocutusOfBorg1: Anything else? | 13:48 |
LocutusOfBorg1 | much stuff built against the old version | 13:50 |
LocutusOfBorg1 | kopete was a lucky case, uploaded the day before libjsoncpp, but I looked at all the build logs and they are fine (picked up the old one everywhere) | 13:50 |
infinity | LocutusOfBorg1: Just so I'm sure I'm parsing that correctly: the only broken package was sysdig, then? | 13:52 |
LocutusOfBorg1 | no | 13:52 |
infinity | LocutusOfBorg1: Which I've just removed wholesale, since it was FTBFS on ARM anyway, so meh. No need to rebuild it. | 13:52 |
LocutusOfBorg1 | broken is anything depending on 0.10.2-1+ | 13:53 |
LocutusOfBorg1 | and nothing is built against it | 13:54 |
LocutusOfBorg1 | many packages are built against the old 0.6 who was fine | 13:54 |
infinity | LocutusOfBorg1: Okay, that's what I said. :) | 13:54 |
LocutusOfBorg1 | I just had a trouble for kopete, uploaded on the day before, but it built quickly | 13:55 |
LocutusOfBorg1 | and with the old version | 13:55 |
LocutusOfBorg1 | so I guess syncing it, and MIRing it would be fine | 13:55 |
infinity | LocutusOfBorg1: MIR already sorted. | 13:55 |
infinity | LocutusOfBorg1: Can sync when LP knows what's up. | 13:55 |
LocutusOfBorg1 | so now cmake starts building? | 13:56 |
infinity | Should do soon, yeah. | 13:56 |
infinity | Assuming it can build against 0.6 | 13:56 |
infinity | (If it can't, it should have a versioned build-dep, which it doesn't, so...) | 13:56 |
LocutusOfBorg1 | wow, yes, actually I built and tested against 0.6 | 13:57 |
LocutusOfBorg1 | I got the trouble because my ppa had universe enabled | 13:57 |
LocutusOfBorg1 | the only problem is actually than the old jsoncpp wasn't versioning correctly | 14:00 |
LocutusOfBorg1 | infinity, is that a problem? | 14:00 |
LocutusOfBorg1 | bug 1218220 | 14:01 |
ubottu | bug 1218220 in libjsoncpp (Ubuntu) "[MIR] libjsoncpp" [Undecided,Won't fix] https://launchpad.net/bugs/1218220 | 14:01 |
LocutusOfBorg1 | this is why I was trying to merge the new one | 14:01 |
pitti | Laney: in case you are interested, the udisks2 regression is tracked in bug 1466081 | 14:02 |
ubottu | bug 1466081 in systemd (Ubuntu) "[udev] no uevent when block devices change" [High,Triaged] https://launchpad.net/bugs/1466081 | 14:02 |
infinity | LocutusOfBorg1: I don't recall what I meant by that, since it was two years ago... | 14:02 |
LocutusOfBorg1 | it was lacking of a sane versioning ABI | 14:03 |
infinity | LocutusOfBorg1: Okay, well, it's still libjsoncpp0, I don't see how that solved the problem. :P | 14:03 |
LocutusOfBorg1 | and this is fixed with the new one, I would like to cancel cmake builds and wait for the new jsoncpp, but you are the boss, not me :) | 14:03 |
LocutusOfBorg1 | this is "fixed" because upstream tracks ABI changes closely now | 14:04 |
LocutusOfBorg1 | http://upstream.rosalinux.ru/versions/jsoncpp.html | 14:04 |
doko | tracking ABI changes closely and keeping the soversion? | 14:07 |
LocutusOfBorg1 | yes, I should bother them to bump the soversion | 14:10 |
doko | infinity, can you do the dpkg merge? | 14:10 |
jdstrand | pitti: re seccomp, I don't mind at all. merge away :) | 14:11 |
pitti | jdstrand: ack :) | 14:13 |
jdstrand | pitti: fyi, I also did submittodebian on the autopkgtests and I'm discussing that with Debian | 14:13 |
pitti | jdstrand: yes; I asked kees yesterday and he seemed to think the nature of these tests is more like "upstream test suite", not a package integration one | 14:14 |
infinity | doko: Yeah, I think 1.18.1 has probably cooked enough by now. | 14:15 |
jdstrand | yes, he does. I think he is right about some but not all :) we'll figure it out | 14:15 |
LocutusOfBorg1 | is cmake https://launchpad.net/ubuntu/+source/cmake/3.2.2-2ubuntu1 still building on armhf? | 14:17 |
LocutusOfBorg1 | I'm getting oops | 14:17 |
infinity | LocutusOfBorg1: LP bug. Under investigation. :P | 14:20 |
infinity | LocutusOfBorg1: I might have hit a button too hard. | 14:20 |
LocutusOfBorg1 | is that your hand? http://ecx.images-amazon.com/images/I/41fXAZENBZL.jpg | 14:22 |
doko | pitti, could you have a look at https://bugs.launchpad.net/ubuntu/+source/sessioninstaller/+bug/1440368 ? or find somebody from desktop (although this is foundations) | 14:43 |
ubottu | Ubuntu bug 1440368 in sessioninstaller (Ubuntu) "sessioninstaller should be ported to Python3" [Undecided,New] | 14:43 |
Laney | pitti: thanks for looking, seems like a real real regression - yay for tests | 14:48 |
cjwatson | LocutusOfBorg1: DB row fixed, that build is (I'm told) intentionally cancelled. | 15:27 |
barry | slangasek: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1324391/comments/19 (thanks bdmurray!) | 15:35 |
ubottu | Ubuntu bug 1324391 in python-pip (Ubuntu Trusty) "pip 1.5.4 import an invalid dependencies " [High,Fix committed] | 15:35 |
hyperair | hi. could someone let banshee into vivid-updates please? the bug has been marked verified-done for a while now | 15:36 |
bdmurray | looking | 15:37 |
LocutusOfBorg1 | yes cjwatson it should be cancelled, thanks! | 15:41 |
bdmurray | hyperair: its been released | 15:43 |
hyperair | yay thanks | 15:43 |
=== zumbi_ is now known as zumbi | ||
hyperair | bdmurray: launchpad doesn't seem to have updated yet though | 15:44 |
cjwatson | hyperair: https://launchpad.net/ubuntu/+source/banshee/+publishinghistory -> pending publication | 15:48 |
hyperair | ah, thanks | 15:48 |
LocutusOfBorg1 | infinity, syncpackage libjsoncpp ? | 16:13 |
LocutusOfBorg1 | still not good | 16:14 |
infinity | syncpackage: Error: Debian version 0.10.2-4 has not been picked up by LP yet. Please try again later. | 16:14 |
LocutusOfBorg1 | requestsync doesn't show the error | 16:14 |
LocutusOfBorg1 | but syncpackage does | 16:14 |
infinity | LocutusOfBorg1: It does if you pass -V | 16:14 |
LocutusOfBorg1 | strange | 16:14 |
infinity | Oh, requestsync. I never use that, for obvious reasons. | 16:14 |
infinity | And it might be buggy with rmadison returning multiple versions in unstable. | 16:15 |
infinity | I was just knee-deep in that code a couple of days ago, perhaps I should dive back in. | 16:15 |
LocutusOfBorg1 | infinity, some hours ago it was failing at the begin with "ubuntu has an higher version", now seems to go a little after | 16:16 |
LocutusOfBorg1 | syncpackage: D: Source package libjsoncpp is temporarily blacklisted (blacklisted_current). Ubuntu ignores these for now. See also LP: #841372 | 16:16 |
LocutusOfBorg1 | syncpackage: Source libjsoncpp -> wily/Proposed: current version 0.6.0~rc2-3.1ubuntu1, new version 0.10.2-4 | 16:16 |
ubottu | Launchpad bug 841372 in Launchpad itself "Incorrect auto-blacklisting in DSD?" [Low,Triaged] https://launchpad.net/bugs/841372 | 16:16 |
LocutusOfBorg1 | I see it there https://launchpad.net/debian/+source/libjsoncpp/0.10.2-4 | 16:16 |
LocutusOfBorg1 | lol I asked at the same time | 16:17 |
LocutusOfBorg1 | now should be fine | 16:17 |
infinity | synced. | 16:18 |
LocutusOfBorg1 | <3 | 16:18 |
LocutusOfBorg1 | the whole borg community thanks you | 16:19 |
ogra_ | LocutusOfBorg1, i thinnk he'd be happy with only 7of9 :) | 16:20 |
infinity | ogra_: But why rule out 1 through 6? | 16:20 |
LocutusOfBorg1 | ogra_, I would be happy too :D | 16:20 |
ogra_ | haha | 16:23 |
pitti | arges: oh, you are doing SRU today? | 16:28 |
arges | pitti: yes... why? : ) | 16:28 |
pitti | arges: could we release utopic/vivid for bug 1461425 today? there's already the next round of updates in bug 1464669 | 16:29 |
ubottu | bug 1461425 in postgresql-9.4 (Ubuntu Vivid) "New upstream microreleases 9.1.17, 9.3.8, 9.4.3 - fixes regression in previous update" [Undecided,Fix committed] https://launchpad.net/bugs/1461425 | 16:29 |
ubottu | bug 1464669 in postgresql-9.4 (Ubuntu Vivid) "New upstream microreleases 9.1.18, 9.3.9, 9.4.4" [Undecided,In progress] https://launchpad.net/bugs/1464669 | 16:29 |
pitti | sorry about that, this was a bit crazy | 16:29 |
pitti | shold be back to one update every 3 months now | 16:29 |
arges | pitti: ah perfect i see you went through the jenkins 'failures'. I'll work on releasing that then reviewing the next round | 16:30 |
=== Elimin8r is now known as Elimin8er | ||
=== tarpman_ is now known as tarpman | ||
pitti | arges: cheers! | 16:54 |
LocutusOfBorg1 | pitti, do you think libjsoncpp is good for a cmake rebuild? | 17:00 |
LocutusOfBorg1 | I mean, rebuilding cmake should pick the proposed one, right? | 17:00 |
cjwatson | I don't think the new binaries are entirely published yet; at least rmadison doesn't show them | 17:01 |
cjwatson | But once they are, a rebuild will pick them up | 17:01 |
LocutusOfBorg1 | automagically? | 17:03 |
LocutusOfBorg1 | seems it is restarted | 17:03 |
seb128 | stgraber, hey http://iso.qa.ubuntu.com/user/register?destination=qatracker "Have you forgotten your password?" points to http://iso.qa.ubuntu.com/user/password which is invalid | 17:04 |
cjwatson | LocutusOfBorg1: I don't know what you mean by automagically. Builds in -proposed fetch build-dependencies from -proposed. | 17:04 |
seb128 | stgraber, do you know what would be the right url to use? | 17:05 |
seb128 | also I'm trying to log through sso and it tells me that a seb128 user already exist | 17:05 |
cjwatson | Hopefully whoever retried those builds checked. | 17:05 |
LocutusOfBorg1 | it was on "build cancelled" state, do the retry happen automatically? | 17:05 |
cjwatson | LocutusOfBorg1: No, only manually. | 17:05 |
LocutusOfBorg1 | ack thanks | 17:06 |
stgraber | seb128: it's all Ubuntu SSO, no local accounts | 17:06 |
stgraber | seb128: and yeah, we can't disable those links, the best we can do is make them fail | 17:07 |
cjwatson | LocutusOfBorg1: The master site has the new versions at the moment, so it's hopefully OK. | 17:07 |
seb128 | stgraber, well, sso fails telling me that "The name seb128 is already taken." | 17:08 |
stgraber | seb128: ok. We had that happen ocasionally with old accounts, I can nuke your account in the DB which will solve that, just need to reown the data you have in the DB first | 17:08 |
seb128 | stgraber, I guess I've an account from the before sso time but I don't remember the password | 17:08 |
seb128 | stgraber, thanks | 17:08 |
stgraber | manually doing the SSO link is something I haven't figured out yet, so nuking the old account is easier :) | 17:09 |
stgraber | well, I could also rename the old account, that should work | 17:09 |
=== salem_ is now known as _salem | ||
seb128 | you can nuke it as far as I'm concerned | 17:09 |
stgraber | seb128: try now | 17:10 |
Laney | stgraber: after you fix his account, can you see why the rebuild I just requested failed? :) | 17:10 |
Laney | (see the email) | 17:10 |
Laney | perhaps it needs tweaking to do a cron.preinstalled build or something | 17:10 |
seb128 | stgraber, " | 17:10 |
seb128 | Error message | 17:10 |
seb128 | The e-mail address seb128@ubuntu.com is already registered. Have you forgotten your password?" | 17:10 |
stgraber | damn, let me change that too :) | 17:11 |
seb128 | ;-) | 17:11 |
* Laney screams at the rain - washing is out | 17:11 | |
* Laney runs | 17:11 | |
stgraber | seb128: try now | 17:11 |
seb128 | stgraber, works! thanks ;-) | 17:12 |
stgraber | Laney: looking | 17:12 |
stgraber | Laney: desktop next I assume? | 17:14 |
Laney | oui | 17:14 |
* Laney is damp | 17:14 | |
stgraber | ok, so I see 3 requests (one for each product) 10min ago | 17:15 |
stgraber | DB state is 3 which means, built according to nusakan but not published yet | 17:16 |
Laney | I got failure emails | 17:16 |
stgraber | ah, must have removed them without reading them, can you bounce them back to me? | 17:16 |
infinity | LocutusOfBorg1: cmake seems to have happily built against the new libjsoncpp. Cheers. | 17:17 |
LocutusOfBorg1 | cheers! | 17:17 |
Laney | stgraber: It needs to have SUBPROJECT=system-image and run cron.daily-preinstalled | 17:17 |
Laney | (bounced) | 17:18 |
infinity | Curiously, it tried to build them on the old livefs builders instead of on LP. | 17:19 |
infinity | Didn't even know that codepath still existed. | 17:19 |
stgraber | infinity: yeah, still happens when there's no LP project setup in the config | 17:30 |
stgraber | likely to fail horribly as we drop those old builders though :) | 17:30 |
=== _salem is now known as salem_ | ||
=== tlyu_ is now known as tlyu | ||
dobey | does anyone know how to do the equivalent of "python3 -m testtools.run discover" using python3-covearge? | 18:18 |
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== TheMaster is now known as Unit193 | ||
pitti | LocutusOfBorg1: sorry, what about libjsoncpp? (I have no idea about C++ or cmake, what was the problem there?) | 20:25 |
infinity | pitti: It's all sorted. | 20:59 |
infinity | pitti: Also, I fixed the linux autopkgtests. Merry Christmas. | 21:01 |
pitti | infinity: I saw, great job! | 21:01 |
infinity | pitti: The best part was that after I fixed it all, I noticed Brad had (most of) the same changes staged in another branch he just hadn't gotten around to merging. | 21:02 |
infinity | pitti: So, yay for duplicated work. ;) | 21:02 |
pitti | erk | 21:02 |
infinity | (This is really, really, really not our week for kernel stuff) | 21:02 |
pitti | utlemming: wrt. bug 1262951, I noticed that this is incompatible with what Debian's ifupdown now does: they include all files in /etc/network/interfaces.d/ which *don't* have a suffix, and that cloud specific change only includes *.cfg files | 21:03 |
ubottu | bug 1262951 in Ubuntu "cloud-images /etc/network/interfaces shoud source-directory interfaces.d" [Medium,Fix released] https://launchpad.net/bugs/1262951 | 21:03 |
pitti | utlemming: what would I report this against? | 21:03 |
infinity | pitti: I'd guess cloud-init and curtin, at least, probably use that facility. | 21:04 |
infinity | pitti: And the only sane way forward would be to merge the two behaviours, including no-suffix and *.cfg, but nothing else. | 21:04 |
infinity | pitti: IMO. | 21:04 |
pitti | yeah, I guess so; I. e. additionally have the source-directory /etc/network/interfaces.d/ which Debian does | 21:05 |
infinity | Cause trying to mangle things on upgrade might end in tears. | 21:05 |
pitti | one doesn't usually dist-upgrade cloud instances, so that shouldn't be such a big deal | 21:06 |
pitti | (i. e. mangling /etc/network/interfaces) | 21:07 |
infinity | pitti: Lots of people dist-upgrade cloud instances. | 21:07 |
infinity | pitti: If you're not a hip and cool "my whole life is ephemeral" cat, starting with a cloud image and dist-upgrading is perfectly reasonable. | 21:08 |
infinity | pitti: But also, I'd be willing to bet curtin uses the same bits (maybe not, but worth a check), and maas+curtin for base installs is generally less cloudy. | 21:08 |
pitti | well, at least appending that line to /e/n/i on upgrade is not that big of a deal, but as it isn't really owned by any package it still bears the question where to put that | 21:09 |
pitti | (ifupdown presumably) | 21:09 |
infinity | pitti: Oh, if it's only included in the config file, not a default include in the source, it might be just as valid to just start doing this on new installs only. | 21:10 |
infinity | pitti: It's not like old installs will (as a general rule, anyway) start growing new interfaces that people expect to configure that way? | 21:10 |
infinity | pitti: But, YMMV, I dunno. | 21:11 |
pitti | yeah, hence my original question what to report this against -- is that cloud-init? or some cloud-image-builder-thingy? | 21:11 |
pitti | the bug above is against "Ubuntu" | 21:11 |
infinity | pitti: Probably cloud-init has the affected code. | 21:11 |
infinity | pitti: And maybe curtin, like I said. And who knows what else. | 21:11 |
infinity | d-i uses interfaces snippets now too, I thought. | 21:11 |
infinity | Yeah, d-i does, and also writes out 'source /etc/network/interfaces.d/*' | 21:13 |
infinity | Which seems like neither of the behaviours you described... | 21:13 |
infinity | netcfg (1.127) unstable; urgency=medium | 21:14 |
infinity | * Add support for /etc/network/interfaces.d/ by adding a "source" | 21:14 |
infinity | directive (Closes: #770078). It can be replaced with a | 21:14 |
infinity | "source-directory" one during the next release cycle. | 21:14 |
infinity | netcfg (1.127) unstable; urgency=medium | 21:14 |
infinity | * Add support for /etc/network/interfaces.d/ by adding a "source" | 21:14 |
infinity | directive (Closes: #770078). It can be replaced with a | 21:14 |
infinity | "source-directory" one during the next release cycle. | 21:14 |
infinity | -- Cyril Brulebois <kibi@debian.org> Sun, 04 Jan 2015 22:48:47 +0100 | 21:14 |
infinity | Oops, stutter paste. | 21:14 |
infinity | pitti: So, netcfg in Debian hasn't caught up to the new world order. d-i still sources *, rather than source-directory. | 21:16 |
infinity | pitti: In conclusion, this is all a bit of a mess right now. | 21:16 |
pitti | yay consistency | 21:17 |
infinity | pitti: So, I think the right answer here is "hunt down all installers, and change what they do"... What ifupdown does is irrelevant, since 99% of the time, it's not writing interfaces(5) | 21:18 |
infinity | pitti: And if it's trying to change any old config files on upgrade, that would be massively wrong. | 21:18 |
infinity | Also, yes, yay consistency. | 21:19 |
infinity | netcfg still appears to write everything to interfaces(5) too. It could really use a rewrite to write per-interface to the .d directory. | 21:21 |
=== salem_ is now known as _salem | ||
=== _salem is now known as salem_ | ||
=== sergiusens_ is now known as sergiusens | ||
=== pgraner is now known as pgraner-afk | ||
hallyn | do-release-upgrade -d -f noninteractive. should work? | 23:29 |
sarnold | hallyn: are you hitting this? https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1452238 | 23:32 |
ubottu | Ubuntu bug 1452238 in apt (Ubuntu) "Failed to upgrade system from 14.04" [Medium,Confirmed] | 23:32 |
hallyn | sarnold: nah, nothing so drastic. it just isn't being noninteractive, sits and waits for me to hit y/enter/ several times. | 23:33 |
sarnold | ahhhhh | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!