[04:38] ahasenack: abi-compliance-checker finally got all it's tests passed and migrated [05:04] are livefs builds hard coded to only look at main, or can i influence that somehow? [05:36] Eg, the iso builds? Xubuntu is mainly in universe. [05:51] Unit193: yeah [05:51] it's probably a livecd-rootfs thing [05:51] and how do i turn https://launchpad.net/~canonical-foundations/+livefs/ubuntu/artful/test/+build/107309 into something i can boot? :) [05:55] mwhudson: Hidden in ubuntu-cdimage somewhere is the tooling that powers something like this: http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/artful/daily-live-20170817.log [05:56] * tsimonq2 doesn't know where it's hidden :P [05:58] ubuntu-cdimage, right [05:58] i can never keep these things straight in my head [05:59] mwhudson: Once you find where it's hidden, please share :) [06:00] oh lol this hook is missing set -e [07:13] hmm private bugs are annoying, do we in a changelog list the bug number when an upload closes them? [07:13] and LP can hide (or not) the content depending who looks at them? [07:13] or do we omit them in the changelog completely and manually close? [07:15] if it's not going to be made public at the same time as the package hits the archive, then I'd say manually close [07:16] stgraber: both changes are in the upstream projects pblicly available [07:17] which is why I wonder if I could (I prefer) add them to the changelog [07:17] anyway I hear you saying "to not get in trouble you might manually close" [07:17] on top of the social problem of having a private bug linked to a public upload, we have tools that parse changelogs for LP entries and those don't like private bugs very much either [07:17] oh yeah because without creds they can't read them [07:18] ok reason enough, not listing in changelog [07:18] thanks stgraber [07:20] cpaelzer: Even more annoying? "Public" bugs filed by the automatic bot on behalf of errors.ubuntu.com... [07:26] Unit193: what is the annoying part on them? [07:26] other than causing work and usually being hard to debug? [07:28] cpaelzer: Most information you get out of 'em is in the title, doesn't have any other info. :P [07:30] yeah like "failed to install/upgrade: subprocess installed post-installation script returned error exit" without extra files attached and a comment of "I don't know" [07:30] well, in that case me neither :-) [07:33] (Eg, 1697506) === pstolowski is now known as pstolowski|lunch [12:14] acheronuk: yep, my cyrus-sasl2 migration passed :) [12:14] thx === pstolowski|lunch is now known as pstolowski [13:17] hi, in the ubuntu or debian bag of tricks, is there some sort of copyright file parser? [13:18] ahasenack: I think it's standard "control file" format. So stuff like grep-dctrl will probably work against it. I know lintian does some checks in it so presumably it has a parser. What are you trying to do? [13:19] I need to generate a list with package name, version, and license [13:19] lawyers [13:19] some copyright files are machine readable [13:19] others not [13:19] by "machine readable" I mean they have well identified fields, but still plaintext [13:20] like the control file you mentioned [13:20] https://spdx.org/ might be relevant [13:20] ahasenack: https://wiki.debian.org/CopyrightReviewTools lists a few perhaps [13:21] $ licensecheck /usr/share/doc/binutils [13:21] might work [13:21] /usr/share/doc/binutils/copyright: GPL (v3 or later) [13:22] gets a bit confused with libc6 [13:23] who doesn't [13:23] heh [13:24] I think it's meant to parse the license in source files, not in the copyright file itself [13:24] licensecheck is mainly intended for scanning code rather than copyright files AIUI. But since it searches regexs, it may work. [13:24] $ licensecheck -l 10000 /usr/share/doc/libc6/copyright [13:24] /usr/share/doc/libc6/copyright: BSD (3 clause) ISC GPL (v2) GPL (v2) LGPL (v2) [13:24] still misses a lot [13:25] ahasenack: is grep "^License:" /usr/share/doc/libc6/copyright not enough? [13:25] mdeslaur: not all have that field [13:26] and some times it's a different license for the debian/* stuff [13:26] That particular file is free form text [13:26] there is a DEP for that [13:26] oh heh, I of course used the example that doesn't respect the DEP [13:27] IMHO, there basically isn't the data that can give you conclusive results. You have to do it manually. [13:27] Any automation may give you results for most things but they also be wrong so you can't rely on those results. [13:27] I have a list of 279 packages [13:27] names, that is [13:28] And of course this depends on debian/copyright being correct. I reckon you'll find errors across 279 packages. [13:28] * mdeslaur estimates in about 276 packages [13:28] Depending on the required accuracy of your answer your task is non-trivial. [13:29] it's to be done in 2h, that defines it as trivial [13:30] I could as well just dump the whole copyright file [13:30] instead of a simple abbreviation [13:31] Yeah I'd just extract all copyright files and provide those. [13:31] That's all that's really achievable in 2h. [14:01] hi, is something holding back rustc from transiting out of proposed? https://launchpad.net/ubuntu/+source/rustc/1.18.0+dfsg1-4ubuntu1 === JanC is now known as Guest43740 === JanC_ is now known as JanC [14:41] hiho, what is the usual duration from a package in Debian going to "installed" state until "has not been picked up by LP yet. Please try again later." on syncpackage goes away? [14:42] I expected a 30m or 1h job, but it is 2h now and still not finiding it - so it might be better to ask what to expect [14:57] given a package I downloaded via apt-get, how can I figure out its download url? [14:57] apt-cache doesn't print that out explicitly [14:58] "apt-cache show" shows "Filename", maybe I can use that [15:16] ahasenack: apt-cache policy [15:16] you'll need to mangle that a bit [15:17] oh, apt-cache show too [15:26] cpaelzer: Usuually takes a few hours (well, more like 6?) in my experience [15:27] ahasenack: The correct way to figure out download urls for packages generally is apt download --print-uris [=] [15:29] thanks juliank, that is a target I can wait for and retry [15:29] juliank: nice trick [16:00] juliank: hm, apt download --printuris doesn't seem to work for packages from ppas [16:01] it just prints nothing [18:02] doko: FYI, https://bugs.launchpad.net/ubuntu/+source/python3.6/+bug/1711724 <-- I just uploaded a xenial SRU of python3.5 [18:02] Launchpad bug 1711724 in python3.5 (Ubuntu Xenial) "Segfaults with dict" [High,In progress] [18:31] rharper: replied to your comment on the livecd-rootfs mp; let me know if we need to discuss [18:32] thanks, will read [18:37] slangasek: yes; hrm; I was hoping to avoid exec'ing locale -a or localedef --list to see what's available; I assumed a 1:1 mapping between the /etc/default/lang and what's in /usr/lib/locale/ ; otherwise, if they're not the same, we're including additional locales which won't be used by default (making the image larger)? [18:39] rharper: ok, from my pov that's an awkward assumption for cloud-init to be hard-coding; let me think on it [18:41] slangasek: I'm not sure it's the *right* thing; we previously have always generated en_US.UTF-8 (unless told a different locale); we could now check (locale -a and/or localedef --list); and if the default/or requested lang is already available, avoid calling locale-gen; [18:41] the debian cloud-image, for example doesn't contain a locale-archive file, but has 135MB of locale dirs in /usr/lib/locale/ (one can see the list via locale -a) ; === tacocat is now known as volcano === volcano is now known as tacocat [20:59] LocutusOfBorg: Oh dang, now you are active. Oh well, already filed Bug 1711748. [20:59] bug 1711748 in chef (Ubuntu) "Sync chef 12.14.60-3 (universe) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1711748 [21:00] done, leaving now! cheers [21:21] What's going on with launchpad? [21:24] Works for me [21:25] I uploaded packages almost 6 hours ago and they haven't started building [21:25] The predicted time has been 30 minutes for several hours [21:41] Did someone upload KDE/Qt again?