[03:53] <Mirv> Qt 5.7.1 published, autopkgtest infra might be busy again for a day or two
[09:39] <mantiena-baltix> Hi seb128
[09:39] <seb128> hey mantiena-baltix
[09:41] <mantiena-baltix> seb128: please tell me who could help accept 1 patch from Debian LibreOffice packages to fix bug #1635847
[09:41] <seb128> mantiena-baltix, try sweetshark on #ubuntu-desktop
[09:41] <mantiena-baltix> seb128: thanks
[09:42] <seb128> yw
[09:42] <mantiena-baltix> seb128: Sweet5hark ?
[09:42] <seb128> yes
[12:58] <mabkenar> Hi everybody. I have just sent my first pull request to Ubuntu. It is a typo-fix to ubuntu-system-settings (just getting ready for my next substantial merge request).
[12:58] <mabkenar> Do you know if I have to sign a CLA before it gets merged?
[12:58] <mabkenar> PR is here: https://code.launchpad.net/~mabkenar/ubuntu-system-settings/typo-fix/+merge/314416
[13:15] <ackk> cjwatson, hi, I hit another strange behavior between the python-apt lib in trusty and xenial. If I load trusty lists with the xenial version, some packages don't get a description. it seems those are the ones that don't appear in the translations file. but with the python-apt version in trusty it works
[13:15] <ackk> cjwatson, do you know if there has been some backwards-incompatible change?
[13:16] <cjwatson> ackk: I don't, sorry
[13:16] <ginggs> does anyone know why completed builds are stuck showing 'uploading build'? e.g. https://launchpad.net/ubuntu/+source/sagemath/7.4-6ubuntu1 amd64
[13:16] <ackk> cjwatson, notably with that same package:
[13:16] <ackk> >>> cache['touchegg'].versions[0].description
[13:16] <ackk>     ''
[13:17] <ackk> cjwatson, is there anyone else that might have insight on this?
[13:22] <cjwatson> ackk: juliank might know when they're around
[13:23] <ackk> cjwatson, thanks
[13:25] <cjwatson> ginggs: ouch - https://bugs.launchpad.net/launchpad/+bug/1655334
[13:26] <cjwatson> ginggs: let me see if we can work around this
[13:26] <ginggs> cjwatson: thanks
[13:48] <pete-woods> hi guys
[13:48] <pete-woods> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2339/+packages
[13:48] <pete-woods> in that PPA, my packages have been stuck "uploading" for at least an hour
[13:49] <pete-woods> never seen that happen before
[13:49] <pete-woods> could it be related to the snappy builds that are stuck, that you're talking about, above?
[13:52] <ginggs> pete-woods: looks the same to me
[13:55] <pete-woods> cjwatson: asac
[13:55] <pete-woods> whoops
[13:55] <pete-woods> cjwatson: ^ thought that above PPA was showing the same symptoms
[13:56] <pete-woods> (IRC client went mad there)
[13:56] <pete-woods> (sorry for the wrong ping)
[14:01] <cjwatson> pete-woods: same problem, gradually working on clearing it out
[14:02] <cjwatson> no need for further reports at this time, thanks
[14:02] <pete-woods> okay, will let you guys fix it up then :-)
[15:08] <cjwatson> ginggs,pete-woods: still catching up a bit, but it's mostly better now
[15:08] <pete-woods> cjwatson: cool, thanks for the update :)
[15:08] <ginggs> cjwatson: thanks!
[15:13] <gQuigs> was looking at some bugs for evolution and noticed that there is a -proposed package in xenial without an associated bug - https://launchpad.net/ubuntu/+source/evolution/3.18.5.2-0ubuntu3.1 - http://people.canonical.com/~ubuntu-archive/pending-sru.html
[15:13] <gQuigs> seb128: ^is that revert still needed?
[15:15] <seb128> gQuigs, yes, we should go back to use the langpack .mo since the bug were those were missing has been fixed
[15:15] <seb128> which is what this update is doing
[15:19] <elopio> barry: ping. Are you now in charge of the autopkgtest infrastructure?
[15:20] <barry> elopio: we're still splitting up the pitti horcruxes.  i don't have access to the infra yet, but Laney does.  i'm working on the software for right now
[15:21] <ackk> juliank, hi, around?
[15:22] <juliank> ackk: Yep
[15:23] <ackk> juliank, do you know if there was some backwards-incompatible change in python-apt in xenial wrt "Description" parsing? I'm using the python-apt from xenial with lists from trusty, and some packages report an empty description
[15:23] <juliank> ackk: I don't think so.
[15:24] <ackk> juliank, http://paste.ubuntu.com/23776610/ is an example
[15:25] <juliank> ackk: Well, what does apt-cache -o Dir=/home/ack/Desktop/apt show touchegg tell you (and showpkg)
[15:26] <ackk> juliank, that doesn't show the full description, though?
[15:26] <juliank> Maybe also add -o Dir::State::status=/home/ack/Desktop/apt/var/lib/dpkg/status
[15:26] <juliank> ackk: hmm?
[15:27] <ackk> juliank, the full description is in the Translations file, not in the Description field
[15:27] <juliank> and?
[15:28] <juliank> I'm not sure what you're trying to say. show will lookup a translated description, and showpkg shows all files containing descriptions
[15:28] <ackk> juliank, version.description should show the full description, and it does on trusty
[15:28] <juliank> And it does.
[15:28] <ackk> juliank, https://pastebin.canonical.com/175488/
[15:29] <ackk> juliank, or rather http://paste.ubuntu.com/23776635/
[15:29]  * ogra_ recommends using a public pastebin instead :)
[15:29] <ogra_> heh, *snap*
[15:29] <ackk> heh
[15:29] <juliank> ackk: Right, you do not have the translations
[15:30] <juliank> showpkg should tell you that
[15:30] <ackk> juliank, I do have them
[15:30] <juliank> ackk: Apparently not.
[15:31] <juliank> Please look at showpkg output
[15:31] <ackk> juliank, it doesn't report them
[15:31] <ackk> juliank, but I do have /home/ack/Desktop/apt/var/lib/apt/lists/it.archive.ubuntu.com_ubuntu_dists_trusty-proposed_universe_i18n_Translation-en
[15:32] <ackk> juliank, uhm, wait you're right. I don't have them for the release pocket
[15:32] <ackk> juliank, not sure why apt didn't download them
[15:34] <ackk> juliank, are there any tweaks to tell apt to download or not translation files?
[15:37] <juliank> ackk: Tons
[15:37] <juliank> But by default it should download them
[15:40] <juliank> ackk: maybe retry downloading?
[15:41] <elopio> barry: I'm asking because I would like to help, with the software. If you have any simple tasks to help me getting started, feel free to assign them to me.
[15:42] <sladen> elopio: a good place, is you find a piece of software you already use
[15:42] <barry> elopio: cool.  i'm also advocating a (virtual or irl) sprint to work on both the s/w and infra so we can get better timezone coverage, etc.  would you like to be involved in that if it happens?
[15:42] <sladen> elopio: and look for something really simple, (like a spelling mistake)
[15:45] <ackk> juliank, fwiw I was downloading them with passing a config file to apt with just the "Dir" option set
[15:47] <juliank> ackk: If you use apt with a chroot style without using the hosts settings, you need to specify a config file via APT_CONFIG and set Dir in that one. Otherwise it first loads all configuration from the host and then applies the settings from your file.
[15:48] <juliank> Because command-line parsing happens after configuration initialization.
[15:49]  * juliank just had the same issue, wondering why his "chroot" was downloading contents files...
[15:54] <ackk> juliank, right, that's what I did, basically
[15:54] <ackk> juliank, oh you mean using an actual chroot?
[15:54] <juliank> Nah
[15:55] <juliank> That's why I put quotes around it :D
[15:55] <ackk> juliank, I mean, if I pass -c it still loads stuff from /etc ?
[15:55] <juliank> Yes
[15:55] <ackk> I see
[15:55] <juliank> In fact, if you pass -c Dir=<foo>, it will not load any configuration from <foo>
[15:55] <juliank> because config file loading is done before that
[15:55] <ackk> juliank, )
[15:56] <ackk> juliank, I'm not passing any -o fwiw, just "apt -c apt.conf" where apt.conf contains Dir "/my/dir"
[15:56] <juliank> Yes
[15:56] <ackk> juliank, is there a way to properly isolate it from the system?
[15:56] <juliank> fIle loading happens before argument parsing.
[15:57] <juliank> With the APT_CONFIG variable
[15:57] <juliank> Set APT_CONFIG to the name of the file containing your "Dir" setting
[15:58] <juliank> apt first loads defaults, then APT_CONFIG, and then Dir::Etc::parts and Dir::Etc::main; and then parses arguments
[15:59] <barry> elopio: one thing that's hitting me right now is that autopkgtest-buildvm-ubuntu-cloud is timing out pulling down and running a zesty image.  i think it's not that script so much as it is cloud-init.  i haven't had time to dig into that in detail, but that's the next thing on my list when i clear some backlog (and yes, this is yak shaving because i'm trying to see why network-manager won't promote due to systemd autopkgtest regressions)
[16:04] <nacc> rbasak: fyi, using d/s/f as a fallback for `dpkg-source --print-format` works for util-linux, at leat
[16:04] <nacc> *least
[16:06] <ackk> juliank, it seems they're only downloaded for trusty-updates, not trusty: https://pastebin.canonical.com/175493/
[16:06] <juliank> ackk: pastebin!
[16:07] <ackk> aah, crap
[16:07] <ackk> sorry
[16:07] <ackk> juliank, http://paste.ubuntu.com/23776767/
[16:08] <juliank> ackk: that's no really useful to look at, we know that stuff already
[16:08] <juliank> how about update --print-uris
[16:09] <juliank> (this tells us if it is even trying to fetch it - I think)
[16:09] <ackk> juliank, http://paste.ubuntu.com/23776774/
[16:10] <juliank> Then look at the real update output and check if it mentions anything about that
[16:10] <ackk> juliank, (I also switched to the main mirror, just to be sure)
[16:11] <ackk> juliank, it does not: http://paste.ubuntu.com/23776780/
[16:11] <juliank> ackk: I can definitely reporduce this
[16:12] <ackk> juliank, apparently this is only happening with trusty on xenial, it seems to work with  precise and xenial repos
[16:12] <ackk> (always from xenial)
[16:14] <juliank> ackk: Right. I believe apt now requires Translation-en to be listed in the Release file - which it is not on trusty
[16:15] <ackk> juliank, I see. this seems like a regression though?
[16:15] <juliank> It's a feature!
[16:15] <ackk> lol
[16:15] <ackk> no more annoying trusty!
[16:16] <juliank> No seriously. It avoids one GET for the i18n/Index on systems that don't have other languages configured
[16:17] <juliank> In fact, I don't think we use the translation index at all
[16:18] <juliank> I just special cased -en in my description because that's the only one in trusty-updates AFAICT
[16:18] <ackk> juliank, is there a way to force it?
[16:18] <juliank> Not sure
[16:18] <juliank> I'd just use an older apt to download it...
[16:19] <juliank> In fact, Debian does not have an i18n/Index
[16:19] <ackk> juliank, so the problem is that we have one script that we use to build a package db dump for all supported releases, using python-apt. so on xenial I get empty descriptions for packages in trusty
[16:20] <juliank> You can download the translation file manually and place it at the correct spot to work around this
[16:21] <ackk> juliank, yeah I guess I'll have to do something like that.
[16:21] <ackk> juliank, thanks a lot for the help
[16:24] <juliank> ackk: BTW requiring files to be in the Release file happened because (1) it's more secure (2) we can be relatively sure how much we'll download [progress] (3) less load on servers by useless queries
[16:25] <ackk> juliank, yeah I understand, it totally makes sense. it's just unfortunate that it leaves the trusty case unconvered
[16:26] <juliank> Maybe someone could update the Release file there to include those things (and do a manual diff to ensure it's sane)? It's a bit weird thing to do, but it'd help prevent further problems like that.
[16:27] <juliank> That said, missing descriptions is not a huge issue normally.
[16:27] <juliank> So it might not be worth it
[16:27] <cjwatson> unfortunately updating the Release file for trusty causes huge load
[16:27] <cjwatson> we can in theory do it but we have to be very selective indeed about timing
[16:28] <juliank> cjwatson: Hmm - why does it cause huge load?
[16:28] <cjwatson> ddos from ubuntu clients
[16:28] <cjwatson> effectively
[16:28] <cjwatson> a few million machines wake up in cron and go "ooh, I have stuff to update"
[16:29] <juliank> Well, they do already with -updates and stuff
[16:29] <juliank> not sure how that would be different
[16:29] <cjwatson> I think there may be a bug somewhere where they redownload too much
[16:29] <elopio> barry: I have zesty! Let me give it a try.
[16:29] <cjwatson> and the trusty Packages file is much bigger
[16:30] <juliank> Right. But they shouldn't (TM) redownload Packages files and stuff if all you change is the Release file (not sure if that's feasible)
[16:30] <juliank> :D
[16:30] <cjwatson> I don't have fully accurate information here because any time we try something like this it causes sysadmins to run around with heads on fire
[16:30] <juliank> That said, might be a bug
[16:30] <barry> elopio: cool thanks.  note that it will still try to download a zesty image by default on yakkety (i have one machine on zesty and another on yakkety).  but i'd love confirmation -or not- of the problem
[16:30] <cjwatson> (it's also possible I'm conflating trusty with an older release)
[16:31] <juliank> trusty is **old** so anything is possible
[16:32] <juliank> Heck, ld segfaults there on arm64
[16:33] <cjwatson> juliank: so, slightly more detail, this happened to us on 2015-10-07 when we tried to add InRelease files to precise and trusty
[16:33] <cjwatson> that appeared to force a redownload
[16:34] <juliank> cjwatson: Oh well, Release -> InRelease is (or was) a slightly more nasty transition
[16:34] <cjwatson> in fact it seemed to do so as far up as wily, at least
[16:34] <juliank> Right, it should be fixed in xenial when that crap was reworked.
[16:37] <cjwatson> so it may be that it was only due to Release -> InRelease, but I'm still wary because that pegged our bandwidth for quite some time
[17:03] <elopio> barry: http://paste.ubuntu.com/23777013/
[17:23] <barry> elopio: huh.  okay, thanks
[17:40] <nacc> infinity: so i got a request for php-gearman to be made available to 16.04 (it's in 16.10 and on); which we had removed at the time because src:php5-gearman was the only available and upstream had no php7 support. Given that we are sync'ing the package from debian currently, couple of questions: 1) is it best to SRU the 16.10 version back (also means that 16.04 <= 16.10 that way, for upgrades); 2) can
[17:40] <nacc> we simply sync the debian version in 16.10 to 16.04? Or do I need to submit a proper ubuntu-ized version for SRU purposes?
[18:08] <elopio> barry: running the command with -v, it worked. The bug doesn't want to be seen.
[18:08] <elopio> I'll keep running it a few more times. Do you have a bug reported that I can follow?
[18:09] <barry> elopio: i haven't filed a bug report yet.  just got back from lunch and now i'm trying it on a zesty host
[18:09] <barry> it's also possible there's a new cloud-init or image or some such today
[18:10] <jbicha> nacc: I suggest
[18:10] <barry> elopio: worked beautifully on zesty host.  trying again on yakkety host
[18:10] <jbicha> backportpackage -s yakkety -d xenial -r -u ubuntu -c 1556460 php-gearman
[18:10] <jbicha> that's if you want it in xenial-updates, otherwise you can leave out the "-r"
[18:11] <jbicha> replace 1556460 with the real bug number
[18:13] <barry> elopio: interesting.  hangs on yakkety host
[18:15] <barry> elopio: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783202
[18:18] <infinity> nacc: We can't "sync" it, since the version can't be the same as yakkety.
[18:19] <infinity> nacc: But I have no issues with you SRUing a no-change backport.  Hard to regress a package that isn't there.
[19:47] <tzero> is there a convention for naming PPAs? like username/package and username/package-testing ?
[20:11] <pdeee> rbasak, gentle ping :)
[20:48] <nacc> infinity: ack, thanks!
[20:49] <nacc> jbicha: thanks!
[21:18] <tarpman> hi all. I guess package imports into bzr aren't really happening any more - is there a new place I can browse package contents online? does ubuntu have a debsources instance or anything like that?
[21:21] <nacc> tarpman: i am working on the server team's git importer, I can import a package for you (or you can od it yourself), but it just reflects the launchpad publishing information.
[21:21] <nacc> tarpman: do you need the most recnet version, or do you want history?
[21:21] <tarpman> nacc: basically I'd like to be able to paste links to lines in the openldap source in xenial
[21:22] <tarpman> not worried about history, I have git for that
[21:23] <nacc> tarpman: ah, there's not anything generic for that, you're right. The git importer (when pushed to a lp git tree), does let you browse the source
[21:26] <tarpman> nacc: ok, thanks. we have the upstream source in git.lp.net, but not the packaging. I'll take some time later and try to figure that out
[21:26] <nacc> tarpman: ah ok, you can also run the importer against your own git tree just to see what it will produce (or --no-push and examine locally)
[21:27] <tarpman> nacc: "the importer" being https://code.launchpad.net/+code-imports/ or something to that effect, is that right?
[21:27] <nacc> tarpman: err, no
[21:28] <nacc> tarpman: that was the old thing, i think
[21:28] <nacc> or noe of them
[21:28] <nacc> *one
[21:28] <nacc> let me get you a link
[21:28] <nacc> https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer
[21:28] <nacc> that creates trees that are 'rich history', like https://code.launchpad.net/~usd-import-team/ubuntu/+source/whois/+git/whois
[21:29] <tarpman> ooh. this looks nifty
[21:29] <nacc> tarpman: i'm starting to run it autamated in testing for server packages, but we're still working on a few things (like dgit compatibility), etc
[21:30] <nacc> tarpman: but, generally, it should never fail and can be used completely independent of any 'official' tree
[21:31] <tarpman> nacc: cool, I'll play with that later. thanks a lot!
[21:31] <nacc> tarpman: np, if you find issues, feel free to file bugs!
[21:31] <tarpman> oh, I will >:)
[21:43] <cjwatson> +code-imports is not "the old thing"
[21:44] <cjwatson> that's a separate thing - it's Launchpad's system for importing VCS trees from external sources into Launchpad, not specifically about packaging
[21:52] <elopio> cjwatson: hey, it seems the armhf machines for autopkgtest are returning again armv8l instead of armv7l. Any idea what might be going on there?
[21:55] <cjwatson> elopio: check the command line and see if compat_uts_machine=armv7l or whatever it is is still there
[21:55] <cjwatson> elopio: (I have no access to autopkgtest stuff)
[21:57] <elopio> cjwatson: ok, I will see how to check that. Laney you are hanlding the autopkgtest machines, right?
[22:03] <ginggs> elopio: the autopkgtest machines are autonomous now
[22:28] <juliank> Bah, now we're getting multiple duplicates per day for the whole  ttf-mscorefonts-installer faisl to install thingy.
[22:28] <juliank> That is so seriously annoying.
[22:30] <dobey> that's what happens when the files disappear from the server for things that have to pull stuff off a server
[22:30] <juliank> No.
[22:31] <juliank> It's a redirect with a space in it, apt decoding the URI in the redirect response, and not reencoding it before sending it to the next server.
[22:31] <dobey> oh? for me i saw it getting 404s from sourceforge
[22:31] <dobey> oh
[22:32] <juliank> And this might go on for a few months once fixed, given the speed at which SRUs are accepted.
[22:33] <juliank> * a few months after a fix was rolled out for zesty, that is
[22:33] <dobey> well, spin it as a denial of service attack performed by sourceforge on debian/ubuntu users :)
[22:34] <juliank> dobey: "https://netcologne.dl.sourceforge.net/project/corefonts/the fonts/final/andale32.exe" is a really stupid url
[22:34] <juliank> github is worse, though
[22:35] <juliank> It has some weird script thingy with parameters "; filename=" (notice the space after ;)
[22:35] <dobey> could be worse
[22:36] <juliank> dobey: AWS which hosts the github downloads responds with "505 HTTP Version not supported" because it things that ;filename=.... is the HTTP version string
[22:36] <juliank> The others give more sensible errors...
[22:45] <juliank> Anyone knows if I should quote user and password too?
[22:45] <juliank> I think host is not to be quoted
[23:00] <elopio> ginggs: that's the dream :)
[23:01] <juliank> I fear this might also affect trusty, but not sure.
[23:02] <juliank> The workaround now only URL-encodes the path of the URL and is currently running test suite.
[23:03] <juliank> If someone feels like we need to URL encode the rest too, let me know
[23:22] <juliank> Eww, I accidentally uploaded apt 1.4~beta3ubuntu1 without a copyright file. I should really fix that once and for all (it's a symlink to COPYING which syncs fine, but you can't do direct uploads because Launchpad rejects symlinks there)
[23:22] <juliank> Oh well, it's going to be fixed next week with 1.4~rc1
[23:31] <nacc> tarpman: fyi, src:openldap is on the server list, so i'm importing it :)
[23:32] <tarpman> nacc: excellent, so in a while it'll show up under ~usd-import-team's repositories?
[23:36] <nacc> tarpman: yep, should be at https://code.launchpad.net/~usd-import-team/ubuntu/+source/openldap/+git/openldap, once it's done importing
[23:36] <nacc> tarpman: do you need any of the other versions (openldap2, openldap2.3)?
[23:36] <tarpman> nacc: just openldap, thanks
[23:37] <nacc> tarpman: np!
[23:45] <jbicha> I looked at bug 1607535 but the Ubuntu merge looked more complicated than I wanted to work with so I hoped someone that had worked on it before would do it
[23:45] <tzero> is anyone familiar with dh_python3? I think it's screwing with dependencies when I add install_requires=[] to setuptools
[23:48] <juliank> jbicha: Not that problematic. I think there is a redirect for the old URI but that fails due to bug 1651923
[23:49] <juliank> (Fix for that one is in -proposed waiting for autopkgtests)
[23:57] <bdmurray> nacc: what additional testing did you do in bug 1645431?