=== salem_ is now known as _salem | ||
=== scottt is now known as Guest30268 | ||
=== feliks_ is now known as longboy | ||
Mirv | Qt 5.7.1 published, autopkgtest infra might be busy again for a day or two | 03:53 |
---|---|---|
=== longboy is now known as felikswhite | ||
mantiena-baltix | Hi seb128 | 09:39 |
seb128 | hey mantiena-baltix | 09:39 |
mantiena-baltix | seb128: please tell me who could help accept 1 patch from Debian LibreOffice packages to fix bug #1635847 | 09:41 |
ubottu | 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 |
seb128 | mantiena-baltix, try sweetshark on #ubuntu-desktop | 09:41 |
mantiena-baltix | seb128: thanks | 09:41 |
seb128 | yw | 09:42 |
mantiena-baltix | seb128: Sweet5hark ? | 09:42 |
seb128 | yes | 09:42 |
=== thegodfather is now known as fabbione | ||
=== _salem is now known as salem_ | ||
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 | 12:58 |
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:15 |
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:16 |
ackk | cjwatson, is there anyone else that might have insight on this? | 13:17 |
cjwatson | ackk: juliank might know when they're around | 13:22 |
ackk | cjwatson, thanks | 13:23 |
cjwatson | ginggs: ouch - https://bugs.launchpad.net/launchpad/+bug/1655334 | 13:25 |
ubottu | Launchpad bug 1655334 in Launchpad itself "process-upload oopses if snap was deleted after build completed" [Critical,Triaged] | 13:25 |
cjwatson | ginggs: let me see if we can work around this | 13:26 |
ginggs | cjwatson: thanks | 13:26 |
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:48 |
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:49 |
ginggs | pete-woods: looks the same to me | 13:52 |
pete-woods | cjwatson: asac | 13:55 |
pete-woods | whoops | 13:55 |
pete-woods | cjwatson: ^ thought that above PPA was showing the same symptoms | 13:55 |
pete-woods | (IRC client went mad there) | 13:56 |
pete-woods | (sorry for the wrong ping) | 13:56 |
cjwatson | pete-woods: same problem, gradually working on clearing it out | 14:01 |
cjwatson | no need for further reports at this time, thanks | 14:02 |
pete-woods | okay, will let you guys fix it up then :-) | 14:02 |
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:08 |
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:13 |
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:15 |
elopio | barry: ping. Are you now in charge of the autopkgtest infrastructure? | 15:19 |
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:20 |
ackk | juliank, hi, around? | 15:21 |
juliank | ackk: Yep | 15:22 |
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:23 |
ackk | juliank, http://paste.ubuntu.com/23776610/ is an example | 15:24 |
juliank | ackk: Well, what does apt-cache -o Dir=/home/ack/Desktop/apt show touchegg tell you (and showpkg) | 15:25 |
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:26 |
ackk | juliank, the full description is in the Translations file, not in the Description field | 15:27 |
juliank | and? | 15:27 |
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:28 |
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:29 |
juliank | showpkg should tell you that | 15:30 |
ackk | juliank, I do have them | 15:30 |
=== dannf` is now known as dannf | ||
juliank | ackk: Apparently not. | 15:30 |
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:31 |
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:32 |
ackk | juliank, are there any tweaks to tell apt to download or not translation files? | 15:34 |
juliank | ackk: Tons | 15:37 |
juliank | But by default it should download them | 15:37 |
juliank | ackk: maybe retry downloading? | 15:40 |
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:41 |
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:42 |
ackk | juliank, fwiw I was downloading them with passing a config file to apt with just the "Dir" option set | 15:45 |
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:47 |
juliank | Because command-line parsing happens after configuration initialization. | 15:48 |
* juliank just had the same issue, wondering why his "chroot" was downloading contents files... | 15:49 | |
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:54 |
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:55 |
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:56 |
juliank | With the APT_CONFIG variable | 15:57 |
juliank | Set APT_CONFIG to the name of the file containing your "Dir" setting | 15:57 |
juliank | apt first loads defaults, then APT_CONFIG, and then Dir::Etc::parts and Dir::Etc::main; and then parses arguments | 15:58 |
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) | 15:59 |
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:04 |
ackk | juliank, it seems they're only downloaded for trusty-updates, not trusty: https://pastebin.canonical.com/175493/ | 16:06 |
juliank | ackk: pastebin! | 16:06 |
ackk | aah, crap | 16:07 |
ackk | sorry | 16:07 |
ackk | juliank, http://paste.ubuntu.com/23776767/ | 16:07 |
juliank | ackk: that's no really useful to look at, we know that stuff already | 16:08 |
juliank | how about update --print-uris | 16:08 |
juliank | (this tells us if it is even trying to fetch it - I think) | 16:09 |
ackk | juliank, http://paste.ubuntu.com/23776774/ | 16:09 |
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:10 |
ackk | juliank, it does not: http://paste.ubuntu.com/23776780/ | 16:11 |
juliank | ackk: I can definitely reporduce this | 16:11 |
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:12 |
juliank | ackk: Right. I believe apt now requires Translation-en to be listed in the Release file - which it is not on trusty | 16:14 |
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:15 |
juliank | No seriously. It avoids one GET for the i18n/Index on systems that don't have other languages configured | 16:16 |
juliank | In fact, I don't think we use the translation index at all | 16:17 |
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:18 |
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:19 |
juliank | You can download the translation file manually and place it at the correct spot to work around this | 16:20 |
ackk | juliank, yeah I guess I'll have to do something like that. | 16:21 |
ackk | juliank, thanks a lot for the help | 16:21 |
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:24 |
ackk | juliank, yeah I understand, it totally makes sense. it's just unfortunate that it leaves the trusty case unconvered | 16:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
juliank | trusty is **old** so anything is possible | 16:31 |
juliank | Heck, ld segfaults there on arm64 | 16:32 |
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:33 |
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:34 |
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 | 16:37 |
elopio | barry: http://paste.ubuntu.com/23777013/ | 17:03 |
barry | elopio: huh. okay, thanks | 17:23 |
=== JanC_ is now known as JanC | ||
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? | 17:40 |
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:08 |
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:09 |
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:10 |
jbicha | replace 1556460 with the real bug number | 18:11 |
barry | elopio: interesting. hangs on yakkety host | 18:13 |
barry | elopio: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783202 | 18:15 |
ubottu | Debian bug 783202 in autopkgtest "[adt-buildvm-ubuntu-cloud] timeout nearly after display "Net device info"" [Normal,Open] | 18:15 |
infinity | nacc: We can't "sync" it, since the version can't be the same as yakkety. | 18:18 |
infinity | nacc: But I have no issues with you SRUing a no-change backport. Hard to regress a package that isn't there. | 18:19 |
=== mbiebl_ is now known as mbiebl | ||
tzero | is there a convention for naming PPAs? like username/package and username/package-testing ? | 19:47 |
pdeee | rbasak, gentle ping :) | 20:11 |
nacc | infinity: ack, thanks! | 20:48 |
nacc | jbicha: thanks! | 20:49 |
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:18 |
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:21 |
tarpman | not worried about history, I have git for that | 21:22 |
=== roaksoax_ is now known as roaksoax | ||
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:23 |
=== salem_ is now known as _salem | ||
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:26 |
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:27 |
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:28 |
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:29 |
nacc | tarpman: but, generally, it should never fail and can be used completely independent of any 'official' tree | 21:30 |
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:31 |
cjwatson | +code-imports is not "the old thing" | 21:43 |
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:44 |
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:52 |
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:55 |
elopio | cjwatson: ok, I will see how to check that. Laney you are hanlding the autopkgtest machines, right? | 21:57 |
ginggs | elopio: the autopkgtest machines are autonomous now | 22:03 |
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:28 |
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:30 |
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:31 |
juliank | And this might go on for a few months once fixed, given the speed at which SRUs are accepted. | 22:32 |
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:33 |
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:34 |
juliank | It has some weird script thingy with parameters "; filename=" (notice the space after ;) | 22:35 |
dobey | could be worse | 22:35 |
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:36 |
juliank | Anyone knows if I should quote user and password too? | 22:45 |
juliank | I think host is not to be quoted | 22:45 |
elopio | ginggs: that's the dream :) | 23:00 |
juliank | I fear this might also affect trusty, but not sure. | 23:01 |
juliank | The workaround now only URL-encodes the path of the URL and is currently running test suite. | 23:02 |
juliank | If someone feels like we need to URL encode the rest too, let me know | 23:03 |
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:22 |
nacc | tarpman: fyi, src:openldap is on the server list, so i'm importing it :) | 23:31 |
tarpman | nacc: excellent, so in a while it'll show up under ~usd-import-team's repositories? | 23:32 |
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:36 |
nacc | tarpman: np! | 23:37 |
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 |
ubottu | 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 |
tzero | is anyone familiar with dh_python3? I think it's screwing with dependencies when I add install_requires=[] to setuptools | 23:45 |
juliank | jbicha: Not that problematic. I think there is a redirect for the old URI but that fails due to bug 1651923 | 23:48 |
ubottu | 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:48 |
juliank | (Fix for that one is in -proposed waiting for autopkgtests) | 23:49 |
bdmurray | nacc: what additional testing did you do in bug 1645431? | 23:57 |
ubottu | 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 | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!