| mwhudson | what is the expected time between verification being done on an sru bug and it hitting -updates? | 03:16 |
|---|---|---|
| mwhudson | it's only been 3-4 days for the ones i care about but i want to calibrate my expectations :-) | 03:16 |
| stgraber | mwhudson: it's usually at least 7 days after the package was accepted in -proposed | 03:34 |
| mwhudson | stgraber: ah ok | 03:34 |
| mwhudson | i had a memory of something like that but i couldn't find it written down anywhere | 03:34 |
| pitti | Good morning | 04:55 |
| pitti | infinity: yeah, it was on Friday; we are still missing lcy01, and I had about 500 kernel tests queued up | 04:56 |
| pitti | infinity: it seems ppc64el has a problem (lots of in progress), looking | 04:57 |
| pitti | infinity: nodejs built everywhere and all of its tests pass (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#nodejs) | 06:24 |
| pitti | infinity: 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 | ||
| seb128 | cyphermox, hey, could you review https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1482851 ? | 07:14 |
| ubottu | Launchpad bug 1482851 in os-prober (Ubuntu) "Windows 10 is detected as Windows 8" [Medium,Triaged] | 07:14 |
| === athairus is now known as afkthairus | ||
| cjwatson | pitti: 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 |
| pitti | cjwatson: oh, I will, thanks | 08:57 |
| pitti | cjwatson: webops> that's filing an RT? or the IS IRC channeL? | 08:58 |
| cjwatson | pitti: I was thinking #webops, but indeed you'll probably want to file an RT | 08:58 |
| pitti | cjwatson: /me files, thanks | 08:59 |
| pitti | cjwatson: btw, all bos* builders having this "permission denied (public key)" / Cleaning error is known? | 09:11 |
| cjwatson | wgrant: ^- | 09:11 |
| cjwatson | pitti: Oh, I think IS are just in the middle of moving that over to a different firewall | 09:19 |
| cjwatson | wgrant: ignore | 09:20 |
| cjwatson | pitti: happier now | 09:23 |
| pitti | yay | 09:23 |
| === vrruiz_ is now known as rvr | ||
| === nudtrobert1 is now known as nudtrobert | ||
| Odd_Bloke | cjwatson: Did you have a chance to play with that build I pasted to you on Friday? | 10:11 |
| cjwatson | Odd_Bloke: Oh, not yet, let me finish up my current branch and then try that. | 10:12 |
| Odd_Bloke | cjwatson: Cheers. :) | 10:13 |
| cjwatson | Odd_Bloke: Sigh, I need to bite the bullet and set up a VM buildd rather than relying on lxc | 12:06 |
| Odd_Bloke | cjwatson: :( | 12:07 |
| pitti | stgraber: FYI, i386 regression on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#lxd | 12:42 |
| pitti | stgraber: 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 |
| pitti | PSA: I need to take down and rebuild autopkgtest.ubuntu.com (just the debci web UI, not the machiner) | 12:55 |
| pitti | machinery | 12:55 |
| === mfisch is now known as Guest61243 | ||
| ogra_ | woah ... | 14:50 |
| stgraber | pitti: 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-0ubuntu2 | 14: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 old | 14:51 | |
| pitti | stgraber: yeah, that's the reason why I had to rebuild autopkgtest.u.c., it ran out of space | 14:51 |
| seb128 | cyphermox, hey, did you see my os-propber ping earlier? | 14:52 |
| cyphermox | seb128: I did, I just committed this in Debian | 14:52 |
| cyphermox | I'm about to apply the changes here now | 14:52 |
| cyphermox | just doing a few things at a time :) | 14:52 |
| seb128 | cyphermox, that's ok, you didn't pong so I was unsure, thanks! | 14:53 |
| cyphermox | yeah, sorry :) | 14:53 |
| * pitti needs to run, cu tomorrow | 14:54 | |
| Saviq | pitti, hey, if I wanted to test adt-run on packages as built in a silo/PPA, is something like the following correct? | 15:13 |
| Saviq | adt-run --no-built-binaries --binary *.deb --source unity8_*.dsc --- schroot wily-amd64-shm | 15:13 |
| Saviq | it does complain about broken deps :/ | 15:13 |
| tdaitx | infinity, 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 approach | 15:33 |
| rbasak | tdaitx: 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 |
| rbasak | I wonder if we should migrate libecap2 to the new ABI? | 15:35 |
| rbasak | IIRC the only libecap2 consumer is squid3. | 15:35 |
| tdaitx | rbasak, you are right, reverse-depends (-b) list only squid3 as a dependency, so rebuilding it should work | 15:39 |
| tdaitx | rbasak, are you able to trigger a rebuild? | 15:39 |
| tdaitx | rbasak, and thanks, I was wondering why we were still at 3.3.8 while debian is at 3.5.7 =) | 15:44 |
| tdaitx | anyway, I have been able to fix squid3 FTBFS locally | 15:45 |
| sil2100 | cjwatson: 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 |
| infinity | rbasak: 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 |
| infinity | rbasak: We're behind by years. | 15:48 |
| cjwatson | sil2100: jfdi, I expect it's just your change | 15:49 |
| cjwatson | sil2100: I normally pull immediately | 15:49 |
| === kickinz1 is now known as kickinz1|afk | ||
| rbasak | infinity: 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 |
| seb128 | cyphermox, is there any chance you could review https://code.launchpad.net/~binli/ubuntu/wily/modemmanager/lp1441095/+merge/271088 ? | 15:53 |
| rbasak | tdaitx: 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 |
| infinity | rbasak: 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 |
| cyphermox | seb128: yes, it's on my list for today | 15:56 |
| seb128 | cyphermox, excellent, thanks ;-) | 15:56 |
| hallyn | pitti: do you have a candidate pkg source for systemd 226 for ubuntu? should i just use the debian pkg verbatim? | 15:58 |
| tdaitx | rbasak, oh, btw, I said libecap2 only required a rebuild, but since a few symbols will change, debian/libecap2.symbols does require a few changes | 16:04 |
| tdaitx | infinity, 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 |
| infinity | tdaitx: It would need the package name changed, per the C++ transition. | 16:23 |
| === juliank0 is now known as juliank | ||
| tdaitx | infinity, 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 |
| infinity | tdaitx: Does it link to any other C++ libraries? | 16:24 |
| infinity | tdaitx: Links to libicuuc.so.55, that looks C++ish as well, and I assume has transitioned. | 16:26 |
| infinity | tdaitx: So you'd be mixing ABIs. | 16:26 |
| infinity | tdaitx: Well, except that ICU probably didn't actually change. Most libraries didn't. | 16:27 |
| infinity | tdaitx: Anyhow, if libecap *does* change on rebuild, it should be transitioned, IMO. | 16:27 |
| infinity | tdaitx: Cause a security update would cause a post-release explosion. | 16:27 |
| tdaitx | ouch, indeed | 16:28 |
| Laney | xnox: I'm going to upload what we have there, can tweak later on | 16:30 |
| infinity | tdaitx: When you speak of libecap3, is that only in Debian? | 16:30 |
| tdaitx | it seems to be better to get the squid3 merge in and avoid all that | 16:31 |
| tdaitx | infinity, no, it is in wily-proposed as well | 16:31 |
| infinity | tdaitx: Oh. So. From the same source package. That *completely* changes this conversation. | 16:31 |
| infinity | tdaitx: Because we're also talking about removing libecap from proposed, and any rdeps (does it have any?) | 16:31 |
| infinity | Oh, it really is *just* squid. :P | 16:32 |
| infinity | tdaitx: 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 |
| infinity | tdaitx: I'm really more in favour of the latter, but either workd. | 16:33 |
| infinity | s/workd/works/ | 16:33 |
| tdaitx | right, I also believe getting squid up to date is better | 16:35 |
| infinity | tdaitx: Well, and I assume this is why libecap2 never transitioned, because the new version is already "transitioned". | 16:36 |
| rbasak | tdaitx: I have some pieces of a merge from a previous merging tutorial I can use. Let me take a look tomorrow. | 16:37 |
| tdaitx | rbasak, would you mind if I give that merge a try? | 16:38 |
| infinity | Willing to bet most of our delta goes away on a merge anyway. | 16:41 |
| infinity | Security updates, etc. | 16:41 |
| rbasak | tdaitx: 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 |
| rbasak | tdaitx: I use http://www.justgohome.co.uk/blog/2014/08/ubuntu-git-merge-workflow.html | 16:46 |
| tdaitx | rbasak, in that case, keep up the good work =) | 16:46 |
| rbasak | tdaitx: you can take it if you really want it, but it'd be duplicating some effort I think. | 16:46 |
| tdaitx | yeah, agreed | 16:46 |
| rbasak | tdaitx: OK. OTOH if I don't get to it tomorrow then I don't want to block anyone. | 16:46 |
| tdaitx | rbasak, 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 package | 16:56 |
| tdaitx | rbasak, and thanks for that link ;-) | 16:58 |
| === alai` is now known as adlai | ||
| === adlai is now known as alai8 | ||
| ScottK | FYI, 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 | ||
| hjd | How 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 |
| sarnold | hjd: it does look like it exists... https://launchpad.net/ubuntu/+source/automake-1.14 | 18:00 |
| hjd | When 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 |
| xclaesse | mardy, signond not giving token to apps happens again | 18:15 |
| xclaesse | mardy, sending you syslog in mp (redacted tokens, but in case it still contains something sensing better not post in public chan) | 18:15 |
| xclaesse | mardy, 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 |
| xclaesse | mardy, if I kill signond it works again | 18:20 |
| xclaesse | mardy, 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 app | 18: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 |
| pitti | Saviq: this looks ok in principle, but you should add a -B before the dsc, otherwise it'll build the .dsc again | 18:31 |
| Saviq | pitti, --no-built-binaries is there | 18:32 |
| pitti | Saviq: does wily satisfy all of its dependencies? | 18:32 |
| Saviq | pitti, no, the --binaries do | 18:32 |
| pitti | Saviq: perhaps you rather want to add the PPA? | 18:32 |
| pitti | hallyn: yes, you can use https://launchpad.net/~pitti/+archive/ubuntu/systemd | 18:32 |
| Saviq | pitti, 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 archive | 18:33 |
| pitti | hallyn: this contains the output of the "trunk CI" builds, I regularly run them and they get uploaded if they pass all tests | 18:33 |
| Saviq | pitti, but thought it's possible to do locally | 18:33 |
| pitti | hallyn: 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 enough | 18:33 |
| pitti | Saviq: 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 |
| Saviq | pitti, just a sec | 18:34 |
| hallyn | pitti: 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 journald | 18:34 |
| Saviq | pitti, ah, I think I found my issue... my *.deb included armhf and i386 packages... | 18:35 |
| Saviq | doh | 18:36 |
| pitti | Saviq: :) | 18:37 |
| stgraber | pitti: 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 environment | 18:58 |
| stgraber | pitti: I'm assuming it's some kind of race, possibly happening on slow storage (all my systems are on SSD) | 18:58 |
| stgraber | pitti: 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 somehow | 18:59 |
| stgraber | (we also run the testsuite on every commit and have never seen that particular failure outside of adt) | 19:00 |
| cjwatson | hjd: Virtual packages are things which appear in the Provides field of another package. | 19:12 |
| cjwatson | hjd: 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 |
| sarnold | cjwatson: 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 |
| sarnold | I 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 did | 19:22 |
| cjwatson | sarnold: 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.15 | 19:23 |
| cjwatson | So the fact that the automake-1.14 source is still present is cruft, but essentially irrelevant | 19:23 |
| cjwatson | We don't have good reports for that kind of thing so they sometimes aren't cleared up very promptly | 19:23 |
| cjwatson | In this case, probably partly because the source doesn't seem to have been removed from Debian unstable yet | 19:24 |
| sarnold | cjwatson: aha, thanks for the explanation | 19:24 |
| hjd | cjwatson: sarnold: Ok, I see. | 19:27 |
| hjd | Btw, what's the story on libjpeg vs libjpeg-turbo? | 19:27 |
| cjwatson | The TB decided to go for libjpeg-turbo some time ago | 19:28 |
| cjwatson | The Debian technical committee agreed, more recently | 19:28 |
| cjwatson | I have absolutely no idea why libjpeg9 is being introduced into wily now | 19:28 |
| hjd | cjwatson: Ok, thanks. | 19:33 |
| mterry | ogra_, do you know much about system loggers? Like how one registers as one? And how /dev/log connects to it? | 21:07 |
| mterry | Or anyone else, if anyone knows. :) | 21:09 |
| mterry | slangasek, maybe you know? ^ | 21:11 |
| cyphermox | mterry: slangasek is on vacation | 21:13 |
| * cyphermox looks | 21:13 | |
| sarnold | mterry: 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 calls | 21:15 |
| cyphermox | yep | 21:16 |
| sarnold | mterry: 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 |
| cyphermox | mterry: my reaction was to dig in src/journal in systemd source | 21:17 |
| mterry | cyphermox, 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 |
| mterry | This is on the phone, so no systemd. But true that it may be instructive | 21:19 |
| sarnold | mterry: syslog() _freezes_? that's odd. can you reproduce it with e.g. logger(1)? | 21:19 |
| mterry | sarnold, yes. I can reproduce it with a one-line main() call to syslog | 21:20 |
| mterry | (and logger(1)) | 21:20 |
| mterry | If I 'restart rsyslog', it no longer freezes | 21:21 |
| mterry | But it also doesn't write to syslog | 21:21 |
| mterry | So I think rsyslog is having troubles 'registering' as the logger? first time it gets broken. and can't do it subsequent times | 21:21 |
| mterry | If I gdb into rsyslog, it's waiting on a select, which would seem to be normal rsyslog behavior | 21:22 |
| cyphermox | mterry: 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 device | 21:22 |
| sarnold | mterry: 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 |
| mterry | cyphermox, that's possible | 21:22 |
| cyphermox | mterry: unlikely though :) | 21:23 |
| cjwatson | it'll be openLogSocket in rsyslog, I expect | 21:23 |
| sarnold | mterry: odd that it would be just sitting in select(); I'd expect rsyslog to really be free of select() bugs by now | 21:23 |
| mterry | cjwatson, it seemed to be the same place a well-behaved rsyslog was waiting, but I don't recall at the moment. let me check | 21:23 |
| cjwatson | you 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/log | 21:23 |
| cjwatson | (I don't know how to do that OTTOMH) | 21:23 |
| cjwatson | the process of opening the log is basically socket+bind | 21:24 |
| cjwatson | see createLogSocket | 21:24 |
| mterry | Yeah, rsyslog is selecting inside of realMain. Presumably doing its normal looping? | 21:24 |
| cjwatson | and bind(2) + unix(7) | 21:24 |
| mterry | cjwatson, ok | 21:24 |
| mterry | cjwatson, I remember it being awkward to get debug info out of rsyslog... will see what I can do | 21:25 |
| cjwatson | bind() can fail if something else is already bound to the same filesystem socket object | 21:25 |
| cjwatson | if I were investigating this I would probably just hack it to spew debug to some hardcoded file under /run | 21:25 |
| cjwatson | debugging early boot stuff got a lot easier when /run was devised :) | 21:26 |
| mterry | cjwatson, heh | 21:26 |
| cjwatson | alternatively you could just hack the upstart job to run it under strace | 21:26 |
| cjwatson | and likewise dump the trace to /run | 21:26 |
| cjwatson | that would probably be my first resort | 21:27 |
| cjwatson | then you can look for it trying to bind to /dev/log, which should be pretty early, and see if it worked | 21:27 |
| mterry | cjwatson, great points, thank you. I'm about to go EOD; I'll try them tomorrow | 21:28 |
| mterry | Rsyslog may have won the battle, but it will not win the war :) | 21:29 |
| hallyn | pitti: oh, nm, i see it must be in your bzr or git tree - sorry for the noise | 21:32 |
| sarnold | mterry: 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 fifo | 21:32 |
| sarnold | mterry: 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 |
| mterry | sarnold, agreed :) thanks | 21:35 |
| mterry | sarnold, lsof only shows rsyslog on the broken device | 21:39 |
| sarnold | mterry: does it have the same inode number as e.g. the blocking logger() or one-liner syslog() program? | 21:40 |
| mterry | sarnold, oh, right. I had run it without the syslog program up :-/ | 21:41 |
| mterry | sarnold, with that up, I see: | 21:41 |
| mterry | dpmd 2197 root 12u unix 0xffffffc0675ba000 0t0 19440 /dev/socket/qmux_radio/qmux_client_socket | 21:41 |
| mterry | which is unexpected by me | 21:42 |
| mterry | Which is some android thing | 21:43 |
| mterry | I think I need to talk to the android-side people | 21:43 |
| sarnold | qmux radio? o_O | 21:43 |
| * mterry shrugs | 21:44 | |
| mterry | sarnold et al: thanks for the help. I'm going to knock off soon, but will try digging further with your awesome suggestions tomorrow | 21:44 |
| sarnold | have a good evening :) | 21:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!