mwhudsonwhat is the expected time between verification being done on an sru bug and it hitting -updates?03:16
mwhudsonit's only been 3-4 days for the ones i care about but i want to calibrate my expectations :-)03:16
stgrabermwhudson: it's usually at least 7 days after the package was accepted in -proposed03:34
mwhudsonstgraber: ah ok03:34
mwhudsoni had a memory of something like that but i couldn't find it written down anywhere03:34
pittiGood morning04:55
pittiinfinity: yeah, it was on Friday; we are still missing lcy01, and I had about 500 kernel tests queued up04:56
pittiinfinity: it seems ppc64el has a problem (lots of in progress), looking04:57
pittiinfinity: nodejs built everywhere and all of its tests pass (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nodejs)06:24
pittiinfinity: ok to remove block-proposed, or do you want to do some manual testing too?06:24
=== benonsoftware is now known as bdunn
=== bdunn is now known as benonsoftware
=== benonsoftware is now known as MerryChristmas
=== MerryChristmas is now known as benonsoftware
seb128cyphermox, hey, could you review https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1482851 ?07:14
ubottuLaunchpad bug 1482851 in os-prober (Ubuntu) "Windows 10 is detected as Windows 8" [Medium,Triaged]07:14
=== athairus is now known as afkthairus
cjwatsonpitti: Could you please chase webops about that (lcy01)?  https://rt.admin.canonical.com/Ticket/Display.html?id=84603 has been resolved since Thursday, so if your stuff still doesn't have access to it then that shouldn't be very hard to fix now.08:57
pitticjwatson: oh, I will, thanks08:57
pitticjwatson: webops> that's filing an RT? or the IS IRC channeL?08:58
cjwatsonpitti: I was thinking #webops, but indeed you'll probably want to file an RT08:58
pitticjwatson: /me files, thanks08:59
pitticjwatson: btw, all bos* builders having this "permission denied (public key)" / Cleaning error is known?09:11
cjwatsonwgrant: ^-09:11
cjwatsonpitti: Oh, I think IS are just in the middle of moving that over to a different firewall09:19
cjwatsonwgrant: ignore09:20
cjwatsonpitti: happier now09:23
=== vrruiz_ is now known as rvr
=== nudtrobert1 is now known as nudtrobert
Odd_Blokecjwatson: Did you have a chance to play with that build I pasted to you on Friday?10:11
cjwatsonOdd_Bloke: Oh, not yet, let me finish up my current branch and then try that.10:12
Odd_Blokecjwatson: Cheers. :)10:13
cjwatsonOdd_Bloke: Sigh, I need to bite the bullet and set up a VM buildd rather than relying on lxc12:06
Odd_Blokecjwatson: :(12:07
pittistgraber: FYI, i386 regression on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lxd12:42
pittistgraber: I tried to run this locally in a VM, but there it doesn't even succeed on amd64 (http://paste.ubuntu.com/12514056/)12:43
pittiPSA: I need to take down and rebuild autopkgtest.ubuntu.com (just the debci web UI, not the machiner)12:55
=== mfisch is now known as Guest61243
ogra_woah ...14:50
stgraberpitti: I saw that failure but it confused me a bit, the testsuite never succeeded on i386 (except locally where it passes fine) and the web UI wasn't showing me the actual failure for 0.18-0ubuntu214:51
* ogra_ just accidentially typed "ssh cdimage" instead of "ssh nusakan" ... and i noticed that the cdimage entry in my known_hosts not only predates nusakan but also encryption of known_hosts entries 14:51
* ogra_ feels old14:51
pittistgraber: yeah, that's the reason why I had to rebuild autopkgtest.u.c., it ran out of space14:51
seb128cyphermox, hey, did you see my os-propber ping earlier?14:52
cyphermoxseb128: I did, I just committed this in Debian14:52
cyphermoxI'm about to apply the changes here now14:52
cyphermoxjust doing a few things at a time :)14:52
seb128cyphermox, that's ok, you didn't pong so I was unsure, thanks!14:53
cyphermoxyeah, sorry :)14:53
* pitti needs to run, cu tomorrow14:54
Saviqpitti, hey, if I wanted to test adt-run on packages as built in a silo/PPA, is something like the following correct?15:13
Saviqadt-run --no-built-binaries --binary *.deb --source unity8_*.dsc --- schroot wily-amd64-shm15:13
Saviqit does complain about broken deps :/15:13
tdaitxinfinity, pitti, bdmurray squid3 depends on libecap2, but the build fails because libecap2 is using the old gcc abi while squid3 current build is using the new one, I can get squid3 to build with -D_GLIBCXX_USE_CXX11_ABI=0 but I'm not sure if that is the right approach15:33
rbasaktdaitx: thank you for looking at it and sorry for the mess, I intended to merge squid3 before feature freeze but ran out of time. Let me know if I can help with anything. I'm not sure of the answer to that question.15:35
rbasakI wonder if we should migrate libecap2 to the new ABI?15:35
rbasakIIRC the only libecap2 consumer is squid3.15:35
tdaitxrbasak, you are right, reverse-depends (-b) list only squid3 as a dependency, so rebuilding it should work15:39
tdaitxrbasak, are you able to trigger a rebuild?15:39
tdaitxrbasak, and thanks, I was wondering why we were still at 3.3.8 while debian is at 3.5.7 =)15:44
tdaitxanyway, I have been able to fix squid3 FTBFS locally15:45
sil2100cjwatson: I'll be doing a bzr pull of my latest changes to cdimage on nusakan - in case it breaks something, feel free to revert ;)15:47
infinityrbasak: I wouldn't be against you merging squid3 to be up to date with Debian, if we can test it in any reasonable way.15:48
infinityrbasak: We're behind by years.15:48
cjwatsonsil2100: jfdi, I expect it's just your change15:49
cjwatsonsil2100: I normally pull immediately15:49
=== kickinz1 is now known as kickinz1|afk
rbasakinfinity: the merge will take me at least a day, maybe two, to clean it all up. I think that by the time I get round to it we'll be too close to release :(15:53
seb128cyphermox, is there any chance you could review https://code.launchpad.net/~binli/ubuntu/wily/modemmanager/lp1441095/+merge/271088 ?15:53
rbasaktdaitx: I can upload a no-change rebuild, but I'd prefer to have an uploader more familiar with the GCC 5 ABI transition ack it first since I'm not sure I fully understand the consequences.15:53
infinityrbasak: Well, we definitely should get caught up for 16.04, if you'd rather merge first thing in 16.04, that's fine too, but merging now would get rid of that one old library.15:55
cyphermoxseb128: yes, it's on my list for today15:56
seb128cyphermox, excellent, thanks ;-)15:56
hallynpitti: do you have a candidate pkg source for systemd 226 for ubuntu?  should i just use the debian pkg verbatim?15:58
tdaitxrbasak, oh, btw, I said libecap2 only required a rebuild, but since a few symbols will change, debian/libecap2.symbols does require a few changes16:04
tdaitxinfinity, if we rebuild libecap2 and that changes the symbols, would we need to update its version as well? (libecap3, which, btw, is already being used by ecap 1.0)16:17
infinitytdaitx: It would need the package name changed, per the C++ transition.16:23
=== juliank0 is now known as juliank
tdaitxinfinity, thought so... alright, is it ok to build squid3 with -D_GLIBCXX_USE_CXX11_ABI=0 then? at least until we get the merge in?16:24
infinitytdaitx: Does it link to any other C++ libraries?16:24
infinitytdaitx: Links to libicuuc.so.55, that looks C++ish as well, and I assume has transitioned.16:26
infinitytdaitx: So you'd be mixing ABIs.16:26
infinitytdaitx: Well, except that ICU probably didn't actually change.  Most libraries didn't.16:27
infinitytdaitx: Anyhow, if libecap *does* change on rebuild, it should be transitioned, IMO.16:27
infinitytdaitx: Cause a security update would cause a post-release explosion.16:27
tdaitxouch, indeed16:28
Laneyxnox: I'm going to upload what we have there, can tweak later on16:30
infinitytdaitx: When you speak of libecap3, is that only in Debian?16:30
tdaitxit seems to be better to get the squid3 merge in and avoid all that16:31
tdaitxinfinity, no, it is in wily-proposed as well16:31
infinitytdaitx: Oh. So.  From the same source package.  That *completely* changes this conversation.16:31
infinitytdaitx: Because we're also talking about removing libecap from proposed, and any rdeps (does it have any?)16:31
infinityOh, it really is *just* squid. :P16:32
infinitytdaitx: So, either remove libecap from proposed and rename/transition libecap2.  Or work with rbasak to get a merged squid in and give it a bit of testing.16:33
infinitytdaitx: I'm really more in favour of the latter, but either workd.16:33
tdaitxright, I also believe getting squid up to date is better16:35
infinitytdaitx: Well, and I assume this is why libecap2 never transitioned, because the new version is already "transitioned".16:36
rbasaktdaitx: I have some pieces of a merge from a previous merging tutorial I can use. Let me take a look tomorrow.16:37
tdaitxrbasak, would you mind if I give that merge a try?16:38
infinityWilling to bet most of our delta goes away on a merge anyway.16:41
infinitySecurity updates, etc.16:41
rbasaktdaitx: IIRC it's a complex and messy merge, with tons of delta that needs rationalising and IIRC quite a bit of it needs modifying or dropping. I think quite a bit of it needs to remain, too. I've already done half the work.16:45
rbasaktdaitx: I use http://www.justgohome.co.uk/blog/2014/08/ubuntu-git-merge-workflow.html16:46
tdaitxrbasak, in that case, keep up the good work =)16:46
rbasaktdaitx: you can take it if you really want it, but it'd be duplicating some effort I think.16:46
tdaitxyeah, agreed16:46
rbasaktdaitx: OK. OTOH if I don't get to it tomorrow then I don't want to block anyone.16:46
tdaitxrbasak, don't worry about that, if we can't get a newer squid in, then we only have to transition the current libecap2 and apply a few patches to the current squid3 source package16:56
tdaitxrbasak, and thanks for that link ;-)16:58
=== alai` is now known as adlai
=== adlai is now known as alai8
ScottKFYI, it looks like Ben needs a kick since there's several listings in http://people.canonical.com/~ubuntu-archive/transitions/html/python3.4-5.html that are long out of date.17:11
=== afkthairus is now known as athairus
hjdHow does virtual packages work, or rather, how are they created? libjpeg9 fails to build (https://launchpadlibrarian.net/217954976/buildlog_ubuntu-wily-amd64.libjpeg9_1%3A9a-2_BUILDING.txt.gz) because it is missing automake-1.14. This seems to be a virtual package which is in Debian (https://packages.debian.org/unstable/automake-1.14), but I can't find a trace of it in Ubuntu...17:57
sarnoldhjd: it does look like it exists... https://launchpad.net/ubuntu/+source/automake-1.1418:00
hjdWhen I try to look up the package name I find http://packages.ubuntu.com/wily/automake, which is built from automake-1.15, but has the same binary package name. Perhaps that is confusing it somehow?18:03
xclaessemardy, signond not giving token to apps happens again18:15
xclaessemardy, sending you syslog in mp (redacted tokens, but in case it still contains something sensing better not post in public chan)18:15
xclaessemardy, what I see the first time evo asks for the token signond says "Stored token is expired", then all subsequent retries it says "One request is already active"18:18
xclaessemardy, if I kill signond it works again18:20
xclaessemardy, my understanding is that it tries to refresh the token, for some reason that operation never completes, then it's stuck forever waiting for that operation to finish before giving a token to any app18:20
TJ-hjd it looks like the source claims to be in 'universe' but the copy-from-Utopic applies to 'main' (the .debs are in pool/main/ too)18:31
pittiSaviq: this looks ok in principle, but you should add a -B before the dsc, otherwise it'll build the .dsc again18:31
Saviqpitti, --no-built-binaries is there18:32
pittiSaviq: does wily satisfy all of its dependencies?18:32
Saviqpitti, no, the --binaries do18:32
pittiSaviq: perhaps you rather want to add the PPA?18:32
pittihallyn: yes, you can use https://launchpad.net/~pitti/+archive/ubuntu/systemd18:32
Saviqpitti, that's what I was thinking if I fail to run from dir, just add the PPA to the chroot and run as if it worked from the archive18:33
pittihallyn: this contains the output of the "trunk CI" builds, I regularly run them and they get uploaded if they pass all tests18:33
Saviqpitti, but thought it's possible to do locally18:33
pittihallyn: you can poke me if you want/need a new trunk build; it's just calling a single script, but I need to remember doing it often enough18:33
pittiSaviq: yes, I often run it like that (adt-run *.deb -B foo.dsc), works fine in general; do you have a log of the error?18:34
Saviqpitti, just a sec18:34
hallynpitti: thx, i'll use that.  i just want to build a 226 with some debug added so i can test why sid containers are regressing with journald18:34
Saviqpitti, ah, I think I found my issue... my *.deb included armhf and i386 packages...18:35
pittiSaviq: :)18:37
stgraberpitti: that MAC address test failure is really odd. I'm currently working on our testsuite and I've run it probably about 50 times over this weekend and never saw that one, yet it seems to be easy enough to reproduce in the adt environment18:58
stgraberpitti: I'm assuming it's some kind of race, possibly happening on slow storage (all my systems are on SSD)18:58
stgraberpitti: I pushed a force-skiptest for LXD since it's clearly not a regression and I'll add a bit more context to that test for the next release, so hopefully I can see whether it's an actual race (no MAC at that point or something) or something's actually messing up the MAC address somehow18:59
stgraber(we also run the testsuite on every commit and have never seen that particular failure outside of adt)19:00
cjwatsonhjd: Virtual packages are things which appear in the Provides field of another package.19:12
cjwatsonhjd: wily has automake-1.15, not automake-1.14.  libjpeg9 should really not be build-depending on automake-1.14, but rather on automake (>= 1:1.14) - assuming that it works with 1.15, that is.19:15
cjwatson(If it's even a sensible thing to have in the archive at all, given that I thought libjpeg-turbo was consciously preferred.  Not sure why doko synced it.)19:16
sarnoldcjwatson: why do you say that automake-1.14 isn't in wily? https://launchpad.net/ubuntu/+source/automake-1.14 shows that it is published for wily, expanding the little triangle shows an _all.deb file for it that's just about the same size as the 1.15 _all.deb; I just don't see how it's "not in wily"19:21
sarnoldI mean, the error from the builder looks like it agrees with you :) but I just odn't know how the builder came to the same conclusion you did19:22
cjwatsonsarnold: the automake-1.14 source produced exactly one binary, "automake", which is superseded in the archive by a binary of the same name built by automake-1.1519:23
cjwatsonSo the fact that the automake-1.14 source is still present is cruft, but essentially irrelevant19:23
cjwatsonWe don't have good reports for that kind of thing so they sometimes aren't cleared up very promptly19:23
cjwatsonIn this case, probably partly because the source doesn't seem to have been removed from Debian unstable yet19:24
sarnoldcjwatson: aha, thanks for the explanation19:24
hjdcjwatson: sarnold: Ok, I see.19:27
hjdBtw, what's the story on libjpeg vs libjpeg-turbo?19:27
cjwatsonThe TB decided to go for libjpeg-turbo some time ago19:28
cjwatsonThe Debian technical committee agreed, more recently19:28
cjwatsonI have absolutely no idea why libjpeg9 is being introduced into wily now19:28
hjdcjwatson: Ok, thanks.19:33
mterryogra_, do you know much about system loggers?  Like how one registers as one?  And how /dev/log connects to it?21:07
mterryOr anyone else, if anyone knows.  :)21:09
mterryslangasek, maybe you know?  ^21:11
cyphermoxmterry: slangasek is on vacation21:13
* cyphermox looks21:13
sarnoldmterry: iirc /dev/log is a unix domain socket with a name in the filesystem; it is probably created by a socket(AF_UNIX), bind(s...) series of system calls21:15
sarnoldmterry: if you want to handle some log entries but not others, you probably have to write an rsyslog module; you might also configure rsyslog to forward all entries to a specific tcp or udp port, ip..21:17
cyphermoxmterry: my reaction was to dig in src/journal in systemd source21:17
mterrycyphermox, sarnold: I'm trying to debug a case where syslog() freezes.  Trying to figure out where it's dying before it hits rsyslog.  And there's some evidence that rsyslog isn't correctly being "registered" as the system logger, however that's done (is that simply creating /dev/log?)21:19
mterryThis is on the phone, so no systemd.  But true that it may be instructive21:19
sarnoldmterry: syslog() _freezes_? that's odd. can you reproduce it with e.g. logger(1)?21:19
mterrysarnold, yes.  I can reproduce it with a one-line main() call to syslog21:20
mterry(and logger(1))21:20
mterryIf I 'restart rsyslog', it no longer freezes21:21
mterryBut it also doesn't write to syslog21:21
mterrySo I think rsyslog is having troubles 'registering' as the logger?  first time it gets broken.  and can't do it subsequent times21:21
mterryIf I gdb into rsyslog, it's waiting on a select, which would seem to be normal rsyslog behavior21:22
cyphermoxmterry: maybe you're running in a case where some other android thing is picking things up when it shouldn't, if it's some new device21:22
sarnoldmterry: I think if the file exists, rsyslog ought to be running; if writes into the socket are blocking, that might mean that rsyslog isn't consuming data quickly enough.21:22
mterrycyphermox, that's possible21:22
cyphermoxmterry: unlikely though :)21:23
cjwatsonit'll be openLogSocket in rsyslog, I expect21:23
sarnoldmterry: odd that it would be just sitting in select(); I'd expect rsyslog to really be free of select() bugs by now21:23
mterrycjwatson, it seemed to be the same place a well-behaved rsyslog was waiting, but I don't recall at the moment.  let me check21:23
cjwatsonyou might want to arrange for rsyslog debugging output to go somewhere useful, since I expect it'll at least issue a debug message if it fails to bind /dev/log21:23
cjwatson(I don't know how to do that OTTOMH)21:23
cjwatsonthe process of opening the log is basically socket+bind21:24
cjwatsonsee createLogSocket21:24
mterryYeah, rsyslog is selecting inside of realMain.  Presumably doing its normal looping?21:24
cjwatsonand bind(2) + unix(7)21:24
mterrycjwatson, ok21:24
mterrycjwatson, I remember it being awkward to get debug info out of rsyslog...  will see what I can do21:25
cjwatsonbind() can fail if something else is already bound to the same filesystem socket object21:25
cjwatsonif I were investigating this I would probably just hack it to spew debug to some hardcoded file under /run21:25
cjwatsondebugging early boot stuff got a lot easier when /run was devised :)21:26
mterrycjwatson, heh21:26
cjwatsonalternatively you could just hack the upstart job to run it under strace21:26
cjwatsonand likewise dump the trace to /run21:26
cjwatsonthat would probably be my first resort21:27
cjwatsonthen you can look for it trying to bind to /dev/log, which should be pretty early, and see if it worked21:27
mterrycjwatson, great points, thank you.  I'm about to go EOD; I'll try them tomorrow21:28
mterryRsyslog may have won the battle, but it will not win the war  :)21:29
hallynpitti: oh, nm, i see it must be in your bzr or git tree - sorry for the noise21:32
sarnoldmterry: one possibility is that the /dev/log might have changed underneath you somewhere; I think all it would take to seriously confuse things is for one program to unlink(/dev/log), then create its own socket or fifo21:32
sarnoldmterry: check lsof for inode numbers for both the hanging client and the running rsyslog; perhaps the /dev/log is a holdover from an android logging daemon? (seems unlikely, but worth mentioning, the situation you've got now is confusing)21:33
mterrysarnold, agreed  :)   thanks21:35
mterrysarnold, lsof only shows rsyslog on the broken device21:39
sarnoldmterry: does it have the same inode number as e.g. the blocking logger() or one-liner syslog() program?21:40
mterrysarnold, oh, right.  I had run it without the syslog program up  :-/21:41
mterrysarnold, with that up, I see:21:41
mterrydpmd     2197   root   12u  unix 0xffffffc0675ba000      0t0 19440 /dev/socket/qmux_radio/qmux_client_socket21:41
mterrywhich is unexpected by me21:42
mterryWhich is some android thing21:43
mterryI think I need to talk to the android-side people21:43
sarnoldqmux radio? o_O21:43
* mterry shrugs21:44
mterrysarnold et al: thanks for the help.  I'm going to knock off soon, but will try digging further with your awesome suggestions tomorrow21:44
sarnoldhave a good evening :)21:45

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!