=== salem_ is now known as _salem === scottt is now known as Guest30268 === feliks_ is now known as longboy [03:53] Qt 5.7.1 published, autopkgtest infra might be busy again for a day or two === longboy is now known as felikswhite [09:39] Hi seb128 [09:39] hey mantiena-baltix [09:41] seb128: please tell me who could help accept 1 patch from Debian LibreOffice packages to fix bug #1635847 [09:41] bug 1635847 in libreoffice (Ubuntu) "Please build libreoffice-systray package (re-enable quickstarter) - sync with Debian LibreOffice packaging" [Low,Confirmed] https://launchpad.net/bugs/1635847 [09:41] mantiena-baltix, try sweetshark on #ubuntu-desktop [09:41] seb128: thanks [09:42] yw [09:42] seb128: Sweet5hark ? [09:42] yes === thegodfather is now known as fabbione === _salem is now known as salem_ [12:58] 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] Do you know if I have to sign a CLA before it gets merged? [12:58] PR is here: https://code.launchpad.net/~mabkenar/ubuntu-system-settings/typo-fix/+merge/314416 [13:15] 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] cjwatson, do you know if there has been some backwards-incompatible change? [13:16] ackk: I don't, sorry [13:16] 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] cjwatson, notably with that same package: [13:16] >>> cache['touchegg'].versions[0].description [13:16] '' [13:17] cjwatson, is there anyone else that might have insight on this? [13:22] ackk: juliank might know when they're around [13:23] cjwatson, thanks [13:25] ginggs: ouch - https://bugs.launchpad.net/launchpad/+bug/1655334 [13:25] Launchpad bug 1655334 in Launchpad itself "process-upload oopses if snap was deleted after build completed" [Critical,Triaged] [13:26] ginggs: let me see if we can work around this [13:26] cjwatson: thanks [13:48] hi guys [13:48] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2339/+packages [13:48] in that PPA, my packages have been stuck "uploading" for at least an hour [13:49] never seen that happen before [13:49] could it be related to the snappy builds that are stuck, that you're talking about, above? [13:52] pete-woods: looks the same to me [13:55] cjwatson: asac [13:55] whoops [13:55] cjwatson: ^ thought that above PPA was showing the same symptoms [13:56] (IRC client went mad there) [13:56] (sorry for the wrong ping) [14:01] pete-woods: same problem, gradually working on clearing it out [14:02] no need for further reports at this time, thanks [14:02] okay, will let you guys fix it up then :-) [15:08] ginggs,pete-woods: still catching up a bit, but it's mostly better now [15:08] cjwatson: cool, thanks for the update :) [15:08] cjwatson: thanks! [15:13] 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] seb128: ^is that revert still needed? [15:15] gQuigs, yes, we should go back to use the langpack .mo since the bug were those were missing has been fixed [15:15] which is what this update is doing [15:19] barry: ping. Are you now in charge of the autopkgtest infrastructure? [15:20] 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] juliank, hi, around? [15:22] ackk: Yep [15:23] 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] ackk: I don't think so. [15:24] juliank, http://paste.ubuntu.com/23776610/ is an example [15:25] ackk: Well, what does apt-cache -o Dir=/home/ack/Desktop/apt show touchegg tell you (and showpkg) [15:26] juliank, that doesn't show the full description, though? [15:26] Maybe also add -o Dir::State::status=/home/ack/Desktop/apt/var/lib/dpkg/status [15:26] ackk: hmm? [15:27] juliank, the full description is in the Translations file, not in the Description field [15:27] and? [15:28] 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] juliank, version.description should show the full description, and it does on trusty [15:28] And it does. [15:28] juliank, https://pastebin.canonical.com/175488/ [15:29] juliank, or rather http://paste.ubuntu.com/23776635/ [15:29] * ogra_ recommends using a public pastebin instead :) [15:29] heh, *snap* [15:29] heh [15:29] ackk: Right, you do not have the translations [15:30] showpkg should tell you that [15:30] juliank, I do have them === dannf` is now known as dannf [15:30] ackk: Apparently not. [15:31] Please look at showpkg output [15:31] juliank, it doesn't report them [15:31] 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] juliank, uhm, wait you're right. I don't have them for the release pocket [15:32] juliank, not sure why apt didn't download them [15:34] juliank, are there any tweaks to tell apt to download or not translation files? [15:37] ackk: Tons [15:37] But by default it should download them [15:40] ackk: maybe retry downloading? [15:41] 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] elopio: a good place, is you find a piece of software you already use [15:42] 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] elopio: and look for something really simple, (like a spelling mistake) [15:45] juliank, fwiw I was downloading them with passing a config file to apt with just the "Dir" option set [15:47] 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] 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] juliank, right, that's what I did, basically [15:54] juliank, oh you mean using an actual chroot? [15:54] Nah [15:55] That's why I put quotes around it :D [15:55] juliank, I mean, if I pass -c it still loads stuff from /etc ? [15:55] Yes [15:55] I see [15:55] In fact, if you pass -c Dir=, it will not load any configuration from [15:55] because config file loading is done before that [15:55] juliank, ) [15:56] juliank, I'm not passing any -o fwiw, just "apt -c apt.conf" where apt.conf contains Dir "/my/dir" [15:56] Yes [15:56] juliank, is there a way to properly isolate it from the system? [15:56] fIle loading happens before argument parsing. [15:57] With the APT_CONFIG variable [15:57] Set APT_CONFIG to the name of the file containing your "Dir" setting [15:58] apt first loads defaults, then APT_CONFIG, and then Dir::Etc::parts and Dir::Etc::main; and then parses arguments [15:59] 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] rbasak: fyi, using d/s/f as a fallback for `dpkg-source --print-format` works for util-linux, at leat [16:04] *least [16:06] juliank, it seems they're only downloaded for trusty-updates, not trusty: https://pastebin.canonical.com/175493/ [16:06] ackk: pastebin! [16:07] aah, crap [16:07] sorry [16:07] juliank, http://paste.ubuntu.com/23776767/ [16:08] ackk: that's no really useful to look at, we know that stuff already [16:08] how about update --print-uris [16:09] (this tells us if it is even trying to fetch it - I think) [16:09] juliank, http://paste.ubuntu.com/23776774/ [16:10] Then look at the real update output and check if it mentions anything about that [16:10] juliank, (I also switched to the main mirror, just to be sure) [16:11] juliank, it does not: http://paste.ubuntu.com/23776780/ [16:11] ackk: I can definitely reporduce this [16:12] juliank, apparently this is only happening with trusty on xenial, it seems to work with precise and xenial repos [16:12] (always from xenial) [16:14] ackk: Right. I believe apt now requires Translation-en to be listed in the Release file - which it is not on trusty [16:15] juliank, I see. this seems like a regression though? [16:15] It's a feature! [16:15] lol [16:15] no more annoying trusty! [16:16] No seriously. It avoids one GET for the i18n/Index on systems that don't have other languages configured [16:17] In fact, I don't think we use the translation index at all [16:18] I just special cased -en in my description because that's the only one in trusty-updates AFAICT [16:18] juliank, is there a way to force it? [16:18] Not sure [16:18] I'd just use an older apt to download it... [16:19] In fact, Debian does not have an i18n/Index [16:19] 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] You can download the translation file manually and place it at the correct spot to work around this [16:21] juliank, yeah I guess I'll have to do something like that. [16:21] juliank, thanks a lot for the help [16:24] 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] juliank, yeah I understand, it totally makes sense. it's just unfortunate that it leaves the trusty case unconvered [16:26] 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] That said, missing descriptions is not a huge issue normally. [16:27] So it might not be worth it [16:27] unfortunately updating the Release file for trusty causes huge load [16:27] we can in theory do it but we have to be very selective indeed about timing [16:28] cjwatson: Hmm - why does it cause huge load? [16:28] ddos from ubuntu clients [16:28] effectively [16:28] a few million machines wake up in cron and go "ooh, I have stuff to update" [16:29] Well, they do already with -updates and stuff [16:29] not sure how that would be different [16:29] I think there may be a bug somewhere where they redownload too much [16:29] barry: I have zesty! Let me give it a try. [16:29] and the trusty Packages file is much bigger [16:30] 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] :D [16:30] 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] That said, might be a bug [16:30] 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] (it's also possible I'm conflating trusty with an older release) [16:31] trusty is **old** so anything is possible [16:32] Heck, ld segfaults there on arm64 [16:33] 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] that appeared to force a redownload [16:34] cjwatson: Oh well, Release -> InRelease is (or was) a slightly more nasty transition [16:34] in fact it seemed to do so as far up as wily, at least [16:34] Right, it should be fixed in xenial when that crap was reworked. [16:37] 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] barry: http://paste.ubuntu.com/23777013/ [17:23] elopio: huh. okay, thanks === JanC_ is now known as JanC [17:40] 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] 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] barry: running the command with -v, it worked. The bug doesn't want to be seen. [18:08] I'll keep running it a few more times. Do you have a bug reported that I can follow? [18:09] 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] it's also possible there's a new cloud-init or image or some such today [18:10] nacc: I suggest [18:10] elopio: worked beautifully on zesty host. trying again on yakkety host [18:10] backportpackage -s yakkety -d xenial -r -u ubuntu -c 1556460 php-gearman [18:10] that's if you want it in xenial-updates, otherwise you can leave out the "-r" [18:11] replace 1556460 with the real bug number [18:13] elopio: interesting. hangs on yakkety host [18:15] elopio: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783202 [18:15] Debian bug 783202 in autopkgtest "[adt-buildvm-ubuntu-cloud] timeout nearly after display "Net device info"" [Normal,Open] [18:18] nacc: We can't "sync" it, since the version can't be the same as yakkety. [18:19] nacc: But I have no issues with you SRUing a no-change backport. Hard to regress a package that isn't there. === mbiebl_ is now known as mbiebl [19:47] is there a convention for naming PPAs? like username/package and username/package-testing ? [20:11] rbasak, gentle ping :) [20:48] infinity: ack, thanks! [20:49] jbicha: thanks! [21:18] 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] 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] tarpman: do you need the most recnet version, or do you want history? [21:21] nacc: basically I'd like to be able to paste links to lines in the openldap source in xenial [21:22] not worried about history, I have git for that === roaksoax_ is now known as roaksoax [21:23] 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 === salem_ is now known as _salem [21:26] 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] 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] nacc: "the importer" being https://code.launchpad.net/+code-imports/ or something to that effect, is that right? [21:27] tarpman: err, no [21:28] tarpman: that was the old thing, i think [21:28] or noe of them [21:28] *one [21:28] let me get you a link [21:28] https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer [21:28] that creates trees that are 'rich history', like https://code.launchpad.net/~usd-import-team/ubuntu/+source/whois/+git/whois [21:29] ooh. this looks nifty [21:29] 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] tarpman: but, generally, it should never fail and can be used completely independent of any 'official' tree [21:31] nacc: cool, I'll play with that later. thanks a lot! [21:31] tarpman: np, if you find issues, feel free to file bugs! [21:31] oh, I will >:) [21:43] +code-imports is not "the old thing" [21:44] 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] 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] elopio: check the command line and see if compat_uts_machine=armv7l or whatever it is is still there [21:55] elopio: (I have no access to autopkgtest stuff) [21:57] cjwatson: ok, I will see how to check that. Laney you are hanlding the autopkgtest machines, right? [22:03] elopio: the autopkgtest machines are autonomous now [22:28] Bah, now we're getting multiple duplicates per day for the whole ttf-mscorefonts-installer faisl to install thingy. [22:28] That is so seriously annoying. [22:30] that's what happens when the files disappear from the server for things that have to pull stuff off a server [22:30] No. [22:31] 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] oh? for me i saw it getting 404s from sourceforge [22:31] oh [22:32] And this might go on for a few months once fixed, given the speed at which SRUs are accepted. [22:33] * a few months after a fix was rolled out for zesty, that is [22:33] well, spin it as a denial of service attack performed by sourceforge on debian/ubuntu users :) [22:34] dobey: "https://netcologne.dl.sourceforge.net/project/corefonts/the fonts/final/andale32.exe" is a really stupid url [22:34] github is worse, though [22:35] It has some weird script thingy with parameters "; filename=" (notice the space after ;) [22:35] could be worse [22:36] 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] The others give more sensible errors... [22:45] Anyone knows if I should quote user and password too? [22:45] I think host is not to be quoted [23:00] ginggs: that's the dream :) [23:01] I fear this might also affect trusty, but not sure. [23:02] The workaround now only URL-encodes the path of the URL and is currently running test suite. [23:03] If someone feels like we need to URL encode the rest too, let me know [23:22] 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] Oh well, it's going to be fixed next week with 1.4~rc1 [23:31] tarpman: fyi, src:openldap is on the server list, so i'm importing it :) [23:32] nacc: excellent, so in a while it'll show up under ~usd-import-team's repositories? [23:36] tarpman: yep, should be at https://code.launchpad.net/~usd-import-team/ubuntu/+source/openldap/+git/openldap, once it's done importing [23:36] tarpman: do you need any of the other versions (openldap2, openldap2.3)? [23:36] nacc: just openldap, thanks [23:37] tarpman: np! [23:45] 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] bug 1607535 in msttcorefonts (Ubuntu) "ttf-mscorefonts-installer 3.4+nmu1ubuntu2 fails to install core fonts and should be updated to version 3.6 from Debian" [Medium,Confirmed] https://launchpad.net/bugs/1607535 [23:45] is anyone familiar with dh_python3? I think it's screwing with dependencies when I add install_requires=[] to setuptools [23:48] jbicha: Not that problematic. I think there is a redirect for the old URI but that fails due to bug 1651923 [23:48] bug 1651923 in apt (Ubuntu Yakkety) "apt https method decodes redirect locations and sends them to the destination undecoded." [Undecided,Triaged] https://launchpad.net/bugs/1651923 [23:49] (Fix for that one is in -proposed waiting for autopkgtests) [23:57] nacc: what additional testing did you do in bug 1645431? [23:57] bug 1645431 in php7.0 (Ubuntu Yakkety) "[SRU] microrelease exception for src:php7.0 (7.0.13)" [Medium,Fix committed] https://launchpad.net/bugs/1645431