=== DrKranz is now known as DktrKranz
=== psivaa_ is now known as psivaa
=== JanC_ is now known as JanC
[09:37] <pitti> Laney: hmm, http://autopkgtest.ubuntu.com/statistics is just "internal server error" .. what happened there?
[09:37] <Laney> hey pitti
[09:37] <Laney> never seen that page before!
[09:38] <pitti> Laney: I don't look at it often either, but I wanted to for preparing my fosdem talk
[09:39] <Laney> jinja2.exceptions.UndefinedError: 'dict object' has no attribute 'numpkgs'
[09:42] <pitti> Laney: hm, any line number? browse.cgi only sets it if there are > 1 results, to avoid showing bogus data for vivid
[09:43] <pitti> but this seemed to work the last time I looked at it, maybe it got confused by some new releases/pockets/
[09:44] <Laney> pitti: https://paste.ubuntu.com/23769432/
[09:45] <pitti> urgh, so numpkgspass exists, but not numpkgs
[09:47] <pitti> Laney: does http://paste.ubuntu.com/23769438/ help? otherwise it should test for both
[09:49] <Laney> pitti: I cowboyed it in, seems to
[09:50] <Laney> oho
[09:50] <Laney> because of arm64/zesty?
[09:51] <pitti> Laney: that sounds like a plausible trigger for this crash indeed
[09:51] <pitti> I covered the "entire release only has one result" case (dummy result for vivid), but not "one architecture only has one"
[09:52] <pitti> Laney: pushed
[09:52] <pitti> ... or not
[09:52] <pitti> $ git push
[09:52] <pitti> fatal: remote error: Permission denied.
[09:52] <Laney> didn't you leave the team?
[09:52] <Laney> :(
[09:53] <pitti> Laney: http://paste.ubuntu.com/23769462/
[09:53] <pitti> erk, and "o missing" → "on missing"
[09:53]  * Laney grumbles for the n+1th time about downloading code from paste.u.c
[09:53] <Laney> :)
[09:54] <Laney> ok, pushed, happy talk writing!
[09:54] <pitti> thanks!
[09:56] <pitti> Laney: I mostly finished it yesterday already, FWIW
[09:57] <Laney> looking forward to seeing it IRL
[09:58] <pitti> Laney: won't have much surprise for you, I'm afraid :)
[10:02] <Laney> pitti: apart from the slide at the end where you reveal the evil backdoor you left in and activate the world-ending virus?
[10:03] <pitti> shhht!
[10:04] <Laney> oh crap, this isn't our encrypted private message
=== G_ is now known as G
[10:50] <Mirv> is there a page with amount of hardware for running autopkgtests? if I counted correctly during the weekend, when just huge items (linux kernels) are being executed, there are 10 parallel x86 runs going on.
[11:04] <pitti> Mirv: we should have a magnitude of 60 parallel x86 runs, 25 ppc64el, and 32 armhf
[11:05] <pitti> (x86 shares amd64 and i386)
[11:11] <Mirv> that's why I was wondering last week if they are all alright
[11:11] <Mirv> so slow, still
[11:11] <pitti> Mirv: right, that's the "should have"; I can't check any more the actual status, that would be Laney now
[11:13] <Laney> There's been a lot of parallel linux runs
[11:13] <pitti> ah, they would take 4 instances each; does linux/i386 still serial-kill workers?
[11:14] <pitti> in December I regularly had to kill/filter the linux/i386 jobs
[11:14] <pitti> and run the maintenance cron often
[11:14] <Laney> Yep, I just pinged apw about that, going to run one in the foreground now
[11:14] <Laney> then get the console-log when it dies
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
=== _salem is now known as salem_
=== henrix_ is now known as henrix
[12:33] <doko> stgraber: about https://bugs.launchpad.net/ubuntu/+source/golang-github-coreos-go-systemd/+bug/1520680 ... this needs seeding, it's again in universe, see component-mismatches
[12:33] <ubottu> Launchpad bug 1520680 in golang-github-coreos-go-systemd (Ubuntu) "[MIR] golang-github-coreos-go-systemd-dev" [High,Fix released]
[12:55] <Mirv> I wonder anyone ever thanked for the nice performance there is nowadays with publisher runs
[12:56] <Mirv> if
[12:56] <cjwatson> that was all wgrant's doing
[12:58] <Mirv> thanks to him, then
[14:45] <stgraber> doko: nah, it doesn't. We were using it for LXD, we don't anymore, fine to have it fall out of main.
[14:46] <stgraber> unless someone else cares about it, but then they should have a dependency to keep it in main
[15:42] <caribou> rbasak: I think I've found how to reproduce LP: #1342580
[15:42] <ubottu> Launchpad bug 1342580 in tftp-hpa (Ubuntu) "tftpd-hpa doesn't start on boot" [High,New] https://launchpad.net/bugs/1342580
[15:44] <caribou> rbasak: since you looked at it a while back, you may want to review my comment that explains the reproducer, the root cause & the potential fix
[15:57] <ackk> Hi, I'm seeing a strange issue with python-apt, both on xenial and trusty, it seems package descriptionsk that contain non-ascii chars are not decoded correctly:
[15:57] <ackk> $ python -c 'import apt; print(apt.Cache()["touchegg"].versions[0].description)'
[15:57] <ackk> Touch?gg is a cross-platform multitouch gesture recognizer that allows associating actions to each gesture.
[15:57] <ackk> am I doing something wrong?
[15:59] <dobey> try python3 instead
[15:59] <dobey> if you're developing new code, you should use python3 not python, generally
[16:00] <ackk> dobey, python3 works on both trusty and xenial, but I'm seeing an issue in exising code, and python3 is not an option for now
[16:02] <ackk> dobey, fwiw I also noticed that python-apt in trusty (0.9.3) always returns unicode for package descriptions, but the new 1.1.0 in xenial returns either str or unicode, based on the package
[16:04] <dobey> so print() decodes to ascii i presume and so non-ascii characters get replaced with ?
[16:05] <ackk> dobey, even a repr shows the '?'
[16:05] <ackk> dobey, u'Touch?gg is a cross-platform multitouch gesture recognizer that allows associating actions to each gesture.'
[16:06] <ackk> dobey, also description[5] == "?" returns True
[16:06] <dobey> well i don't know the details of your environment
[16:06] <ackk> dobey, wdym?
[16:08] <rbasak> caribou: so it'll continue listening on IPv4 and IPv6 as it does right now, but without the race? Sounds good to me, thanks!
[16:08] <dobey> i mean environment is one thing that may affect stirng handling wrt unicode.
[16:08] <rbasak> caribou: I'm not sure an SRU is appropriate though. It'll create conffile prompts, no? Anyone affected could just fix the conffile prompt locally.
[16:08] <ackk> dobey, it wouldn't affect that comparison, though
[16:09] <rbasak> caribou: I'm not completely opposed to it though.
[16:09] <caribou> rbasak: indeed, this is something that can be somewhat annoying
[16:12] <caribou> rbasak: what's better ? a package that may potentially fail to start or a one shot conffile question ?
[16:13] <dobey> ackk: well i don't know what else to tell you if you can't use python3. in python2 you're almost certainly handling unicode wrong (or some library you're using is), because unicode in python2 is inherently broken.
[16:14] <rbasak> caribou: if "[::]:69" is *exactly* equivalent to ":69" except for that bug, and there cannot exist a single user who wouldn't want the change, then perhaps we can do some seddery in preinst to avoid the conffile prompt. "may potentially fail" -> depends on the likelyhood, I think.
[16:14] <rbasak> caribou: this is the kind of case I usually refer to infinity, and do what he says :-)
[16:15] <rbasak> some seddery in preinst to avoid the conffile prompt> I'm not sure that would work, thinking about it.
[16:15] <caribou> rbasak: I don't have the IPv6 expertise to claim that they're both totally identical but I can get confirmation fo that
[16:16] <caribou> rbasak: this is an Ubuntu delta that we introduced. I suppose that if it has been changed, then the seddery would not touch it, otherwise we override our own change
[16:18] <caribou> rbasak: I'll get clarification about the [::]:69 being the same as :69
[16:19] <cjwatson> I think this is just a bug in python-apt regardless of the 2/3 issue; it's returning a unicode object, it clearly ought to be able to manage to have it contain unicode without '?' flattening
[16:21] <ackk> cjwatson, right that's what I thought too. as mentioned I also noticed that in some cases decription is a str, in others unicode. it was always a unicode in trusty
[16:26] <rbasak> caribou: it might be worth asking stgraber about that too.
[16:26] <caribou> rbasak: good idea, I'll add him to the query
[16:27] <cjwatson> ackk: ah, no, it's because apt decodes the description to whatever nl_langinfo(CODESET) says, so you have to have set the locale first
[16:27] <cjwatson> $ python -c 'import locale; import apt; locale.setlocale(locale.LC_ALL, ""); print(apt.Cache()["touchegg"].versions[0].description)'
[16:27] <cjwatson> Touchégg is a cross-platform multitouch gesture recognizer that allows associating actions to each gesture.
[16:28] <cjwatson> can't be bothered working out why it works in python3 anyway :-)
[16:33] <juliank> cjwatson: In python3 the low-level C++ module already decodes all files using utf-8 and passes unicode strings back to Python
[16:35] <juliank> So, there is a slight chance we can get working architecture restrictions lists (stuff like any-arm) for zesty.
[16:36] <juliank> Currently apt and dpkg disagree on some details, like apt accepts any-armel whereas dpkg does not know that and considers armel to match any-arm
[16:37] <juliank> dpkg switched from triplets to quadruplets in 1.18.11 - zesty is still at 1.18.10 (see bug 1654905). My current branch can parse either triplet and quadruplet tables at runtime, but it's a bit hacky.
[16:37] <ubottu> bug 1654905 in dpkg (Ubuntu) "Update dpkg to 1.18.18" [Medium,Triaged] https://launchpad.net/bugs/1654905
=== sarnold_ is now known as sarnold
[16:39] <ackk> cjwatson, OIC. that's weird, I have LC_ALL set to empty in my env
[16:41] <juliank> If anyone has an opinion on any of that, let me know :)
[16:47] <cjwatson> ackk: setlocale(LC_ALL, "") is a special thing that is not actually about what LC_ALL is set to in your environment
[16:47] <ackk> cjwatson, oh ok
[16:47] <cjwatson> ackk: it basically means "import locale information from environment variables into the state of my program", i.e. "activate localisation"
[16:51]  * juliank recommends switching to python3 ASAP
[16:52] <juliank> At some point, python-apt will go away and only python3-apt will remain
[16:53] <juliank> (I'd say not before 18.10, though)
[16:53] <juliank> And only if python-apt work picks up again. It's kind of stagnant
[16:56] <juliank> Oh, if someone wants to look at weird stuff: It looks like lsb_release reports Debian in https://launchpad.net/~deity/+archive/ubuntu/sid/+build/10938767 instead of Ubuntu, despite it even being passed a special in-package lsb-release file that explicitly says ubuntu too.
[17:53] <ignacio> Somehow the lock screen in Lubuntu is not working that good ;-; When I unlock my system (looks like lightdm??) I have to kill lxsession
[17:54] <ignacio> because I see a black screen saying something about it's still locked
=== ignacio is now known as i`
[18:59] <bdmurray> flexiondotorg: Were you working on a better fix for bug 1623856?
[18:59] <ubottu> bug 1623856 in aptdaemon (Ubuntu) "Scrolled Windows in update-manager are too small to read" [Low,In progress] https://launchpad.net/bugs/1623856
[19:18] <fossfreedom> cjwatson: hi - just a bit of advice about our (ubuntu budgie) "fix" to ubiquity.  I think the reason why the changes we made work was because I installed the package first before running ubiquity - I presume it somehow remembered the "sudo" to install the package.  Unfortunately the new package still appears to crash in the same place.  Unfortunately I'm rather out of ideas of how to further debug this.  Any thoughts?
[19:18] <fossfreedom> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1655119
[19:18] <ubottu> Launchpad bug 1655119 in ubiquity (Ubuntu) "ubuntu budgie zesty ubiquity crash when installing locales" [Undecided,New]
[19:38] <debootstrapQuest> Hello there I am wondering if someone can point me in a good direction for creating a iso.  Either with live-build or however Ubuntu iso are created.  Maybe there are some scripts somewhere ?
=== i` is now known as ignacio