=== BrAsS_mO- is now known as BrAss_mOnKeY
=== BrAss_mOnKeY is now known as BrAsS_mOnKeY
[03:38] <velho> Good morning! Trying to get Gnome-Shell to build from the package manager but JHBuild wants to pull newest dependencies. How can I just build the one package with the dependencies it requries?
[03:39] <velho> From package manager means apt source..
[03:41] <sarnold> if you want to build it locally then something like sbuild or pbuilder is worth doing
[03:41] <tsimonq2> https://wiki.ubuntu.com/SimpleSbuild
[03:42] <sarnold> apt-get build-dep gnome-shell ought to install everything needed for building gnome-shell, though, i fyou just don't care about the clean reproducable thing and just want to build :)
[03:43] <tsimonq2> s/apt-get/apt/ ;)
[03:44] <sarnold> I've been typing apt-get for ~20 years now.. I'm not sure that habit is possible to break at this point
[03:45] <tsimonq2> hehe
[03:52] <velho> I'll get an error message due to libtasn1-3-bin not available, replaced by libtasn1-bin:i386 libtasn1-bin
[03:53] <velho> Is it not gnome-shell what is running as defualt in Ubuntu nowdays ?
[04:08] <velho> Screwing around
[04:08] <velho> It was meson build
[04:08] <velho> Lol
[04:29] <velho> IDE / Editor choices?
[04:42] <tsimonq2> Vim :P
[07:41] <apw> i have just tried a cosmic dist-upgrade and am getting errors for the libperl5.26 changelog
[07:41] <apw> anyone seen this ?  i am guessing it is because i have :amd64 and :i386 installed and it would need to upgrade _both_ together
[07:52] <LocutusOfBorg> apw, nice
[07:53] <LocutusOfBorg> you remember me this bug https://bugs.launchpad.net/ubuntu/+source/libpng1.6/+bug/1737309
[07:53] <ubottu> Launchpad bug 1737309 in libpng1.6 (Ubuntu) "package libpng16-16 1.6.20-2 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libpng16-16/ANNOUNCE', which is different from other instances of package libpng16-16:amd64" [Undecided,Incomplete]
[07:53] <LocutusOfBorg> that announce file changes on each release
[07:58] <LocutusOfBorg> juliank, ^^ does this ring a bell?
[08:00] <juliank> LocutusOfBorg: well, artful seems fine
[08:01] <juliank> But there's a bug somewhere
[08:01] <juliank> I mean, he had libpng16-16:i386 in 1.6.34-1 installed with libpng16-16:amd64 in 1.6.20-2 according to the log
[08:02] <juliank> Probably dpkg --force-$something  -i it
[08:02] <LocutusOfBorg> so should I reassign the bug too.... dpkg?
[08:02] <LocutusOfBorg> I was going to stop shipping that file :)
[08:02] <juliank> I don't think there is a bug, but user going crazy
[08:03] <juliank> LocutusOfBorg: the file is fine
[08:03] <juliank> LocutusOfBorg: I basically think he ran dpkg --force-depends -i libpng16-16 from xenial
[08:04] <juliank> Because he's running apt-get install -f
[08:04] <juliank> so he messed something up
[08:04] <juliank> And that's not in the log, so he ran dpkg himself
[08:05] <juliank> The first mention in the log of libpng16-16 is libpng16-16:i386 (1.6.34-1, automatic) being installed
[08:05] <juliank> then a few transactions later it's Upgrade: libpng16-16:amd64 (1.6.20-2, 1.6.34-1)
[08:05] <juliank> which is not possible, as apt would not allow amd64 1.6.20-2 to be co-installed with i386 1.6.34-1
[08:06] <apw> juliank, i cirtainly didn't do that for my perl case
[08:06] <juliank> apw: perl changelog is compressed non-reproducibly, that's a different problem
[08:07] <juliank> apw: And it's committed to be fixed
[08:07] <juliank> apw: Um, it's a symlink on i386, and a file on amd64
[08:07] <juliank> apw: Just keep an eye on bug https://bugs.launchpad.net/ubuntu/+source/perl/+bug/1574351
[08:07] <ubottu> Launchpad bug 1574351 in perl (Ubuntu) "package libperl5.22 5.22.1-9 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libperl5.22/changelog.Debian.gz', which is different from other instances of package libperl5.22:i386" [High,Triaged]
[08:08] <LocutusOfBorg> dpkg: error processing package libpng16-16:i386 (--install):
[08:08] <LocutusOfBorg>  package libpng16-16:i386 1.6.20-2 cannot be configured because libpng16-16:amd64 is at a different version (1.6.34-2)
[08:08] <LocutusOfBorg> juliank, ^^ I confirm thanks
[08:09] <juliank> LocutusOfBorg: I really like bug reports from users who do low-level dpkg stuff and then write bug reports if stuff fails with "i don't know any shit"
[08:09] <LocutusOfBorg> looooooooooooool
[08:10] <LocutusOfBorg> I didn't even think about that possibility
[08:11] <juliank> I've seen quite a few of these cases.
[08:13] <apw> juliank, so what does someone with that installed now do
[08:13] <apw> as it is broken early enough i can't ask to get rid of it
[08:14] <apw> and now i can't complete an update because it is broken
[08:16] <juliank> apw: I don't really know
[08:17] <juliank> apw: Perhaps you can install one of them with dpkg --path-exclude=/usr/share/doc/libperl5.26/changelog.Debian.gz?
[08:17] <juliank> apw: or deleting the file seems to "work"
[08:19] <apw> juliank, will give that a go, ta
=== BrAsS_mO- is now known as BrAsS_mOnKeY
[08:45] <rbasak> juliank: what's the regression risk on your python-apt data changes? Have you done this without an SRU tracking bug before?
[08:48] <juliank> rbasak: There is none. CI changes don't affect us at all, it's purely upstream; and fixing the Vcs URIs to be correct or the debian/gbp.conf to have the correct branch name in it is needed for tools to work properly.
[08:48] <rbasak> juliank: what about changes to data/templates/Debian.mirrors etc?
[08:49] <juliank> rbasak: These are automated, and just keep the mirror list up to date
[08:49] <rbasak> What's the regression risk of changing the mirror list on users?
[08:49] <rbasak> eg. could a user be behind a firewall with explicit rules, and now we're hitting somewhere else?
[08:50] <juliank> rbasak: If you look at xenial-updates, the last upload did just that change without any tracking bug at all
[08:50] <rbasak> That only answers half my question.
[08:50] <juliank> rbasak: It just shows them a different list of mirrors in software-properties that reflects the reality
[08:51] <rbasak> juliank: will it cause any functional runtime change without user interaction in choosing a new mirror?
[08:51] <juliank> There were previous SRUs of python-apt like 1.6.1 that also updated mirror lists, but did not mention it in the changelog.
[08:51] <juliank> rbasak: no
[08:51] <rbasak> That sounds fine then, t hanks
[08:52] <rbasak> Your choice not to use a tracking bug. But that's information that isn't obvious!
[08:55] <juliank> rbasak: Well, good you asked :)
[08:56] <juliank> rbasak: BTW, you probably want to ignore uploads in the queues mentioning bug trigger conversion 1780996 atm, the SRU bug likely needs a few more detaisl
[08:56] <juliank> It's a stupid ~30 package SRU
[08:57] <rbasak> OK, so you want me to leave them for now? IIRC I've accepted a few from you in the past, so have some background.
[08:57] <juliank> rbasak: Well, if you feel that they are self-explanatory enough. There was some concern that the bug does not show how safe the conversions are
[08:58] <rbasak> I get the impression that each one needs reviewing individually to make sure that await isn't actually needed.
[08:59] <juliank> Which is what we do when uploading, but I have not recorded the reasoning so far
[09:00] <juliank> It's a bit unusual since there's no verification that can be done here and it's highly unlikely that someone discovers a regression while in proposed
[09:00] <juliank> that said, regression potential in practice is really low IMO
[09:01] <juliank> There is the theoretical regression
[09:01] <juliank> where your package is configured, but not usabl
[09:01] <juliank> e
[09:01] <rbasak> I'm interested in you documenting the reason if you're reasoning is something beyond "I looked and didn't see any reason for package A; I looked and didn't see any reason for package B, ..." :)
[09:01] <juliank> But then you have apt that tells you your system is not configured yet
[09:01] <rbasak> if your reasoning
[09:02] <rbasak> But otherwise a general reasoning and "I looked and didn't see any reason for all these packages" is fine I think.
[09:02] <juliank> qUm, appstream went wrong
[09:02] <juliank> it only has the changelog entry, but not the change
[09:03] <juliank> odd
[09:04] <juliank> rbasak: So for glib2.0, the reason would be: "schemas" needs to be -await because tools might crash otherwise; but modules don't have to be, because they provide optional "filesystems"
[09:04] <juliank> I think stuff like +interest-noawait /usr/share/icons/hicolor is obvious
[09:04] <rbasak> That sort of thing would be useful to document in the bug please
[09:05] <rbasak> /usr/share/icons/hicolor - agreed. Don't bother with those apart from "here's the list I reviewed that I think are obvious"
[09:06] <juliank> Actually, modules would be fine to keep await
[09:07] <juliank> Since modules for gio link against glib, you always get correct ordering, so converting those to noawait is not neccessary
[09:08] <juliank> I think it's just a performance optimization there, as it avoids some caching runs
[09:16] <rbasak> juliank: data/templates/Ubuntu.mirrors is different between your python-apt uploads in Trusty and Xenial. Intentional?
[09:17] <juliank> rbasak: I think trusty is a day newer
[09:18] <juliank> And one mirror went away in that time and a new one popped up at utexas
[09:19] <juliank> The mirror list always reflects what launchpad reports at the time the package was uploaded
[09:19] <rbasak> OK. So happy to leave as-is?
[09:19] <juliank> yeah
[09:21] <rbasak> juliank: nearly there :-/
[09:22] <rbasak> juliank: in Xenial, "python/tag.cc: Fix invalid read in TagFileNext" and I see the corresponding diff hunk. Shouldn't that have a separate SRU tracking bug?
[09:22] <rbasak> (and get SRU verification, etc)
[09:22] <juliank> rbasak: It probably should have had one, but I did not have anything to verify :/
[09:23] <juliank> We just saw some weird crash reports in the error tracker some time ago
[09:23] <juliank> but it's not really reprodubible
[09:23] <rbasak> I think that's OK, but should be documented.
[09:24] <rbasak> Maybe just put that explanation in the one bug we have for this time, please?
[09:24] <juliank> rbasak: yes
[09:28] <juliank> rbasak: Added
[09:30] <rbasak> Thanks!
[09:54] <rbasak> LocutusOfBorg: around? Your virtualbox upload seems unreviewable (huge diff) and doesn't appear to meet the criteria under https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
[09:56] <LocutusOfBorg> rbasak, I already did the microreleases 4 times for vbox, should I copy-paste the same?
[09:57] <LocutusOfBorg> we upgraded from 5.0 to 5.1, the diff was around 10MB :D
[09:59] <rbasak> LocutusOfBorg: looks like you run into this every time? Eg. https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1746316/comments/5
[09:59] <ubottu> Launchpad bug 1746316 in virtualbox-guest-additions-iso (Ubuntu Artful) "[SRU] VirtualBox needs Security Patches" [Undecided,Fix released]
[09:59] <rbasak> LocutusOfBorg: what we expect is all the SRU information already in the bug before you upload.
[09:59] <rbasak> LocutusOfBorg: and sure, copying and pasting it is fine.
[09:59] <LocutusOfBorg> ack wilco
[10:07] <LocutusOfBorg> done I guess, I have many people reporting that the version in unapproved fixes the issue
[10:08] <LocutusOfBorg> even if the diff looks big, it is really a couple of changes and lots of autogenerated stuff :)
[10:39] <rbasak> LocutusOfBorg: was this a previous SRU regression?
[10:40] <rbasak> LocutusOfBorg: I'm still not seeing "The upstream QA process must be documented/demonstrated and linked from the SRU tracking bug" from https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
[10:40] <rbasak> If you want to push this as a wholesale microrelease update then please review that part of the policy.
[11:03] <LocutusOfBorg> rbasak, yes, probably an SRU regression due to the new feature being enabled incorrectly
[11:03] <LocutusOfBorg> unfortunately it fixed lots but not all the issues
[11:04] <LocutusOfBorg> (the enabling of the feature was to fix the 3d guest, due to the new mesa drivers -hwe, something I have been forced to enabled because of new mesa)
[11:04] <LocutusOfBorg> so, a regression due to somebody else I would say :p
[11:30] <mapreri> hey, I've tried to trigger an autopkgtest against my own PPA, with request.cgi/?release=cosmic&arch=amd64&package=dgit&ppa=mapreri%2Fppa&trigger=dgit%2F5.8%2B0ppa0 - but now the result url keeps returning me 401, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic-mapreri-ppa/?format=plain - The test finished nearly 2 hours ago, so I guess everything ought to be already updated
[11:30] <mapreri> what am I doing wrong?
[11:39] <mapreri> (feel free to redirect me to any better fora if there are any)
=== apw_ is now known as ap
=== ap is now known as Guest79801
=== Guest79801 is now known as apw
[12:13] <velho> Who
[12:14] <velho> is responsible for gnome-shell dev for ubuntu?
[12:16] <rbasak> velho: I suggest you ask your real question as nobody is going to volunteer for you like that. Also try #ubuntu-desktop depending on what your question is.
[12:21] <velho> rbasak: Yea was too lazy to open launchpad
[12:22] <rbasak> LocutusOfBorg: please sort out the SRU information according to https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases. Separately, what in the SRU verification process do we need to change to catch this kind of regression in future?
[12:40] <LocutusOfBorg> rbasak, changes were done by mesa folks, and one other incompatibility was in kernel hwe
[12:43] <LocutusOfBorg> my suggestion is: add virtualbox and vagrant to the list of stuff that needs testing when new kernel or mesa are -hwe added
[12:43] <LocutusOfBorg> see e.g. LP: #1736116
[12:43] <ubottu> Launchpad bug 1736116 in virtualbox-guest-additions-iso (Ubuntu Artful) "[SRU] Host with kernel 4.13 freezes when starting a VM with VirtualBox" [High,Fix released] https://launchpad.net/bugs/1736116
[14:32] <seb128> cjwatson, wgrant, is cosmic open for translations yet? I can see the strings/translate them but some other translators apparently get a msg telling them that the serie is not open
[14:35] <cjwatson> seb128: We should probably do the rest of https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings, yes
[14:37] <seb128> cjwatson, I guess that means the opening is not fully done yet and I see the UI because I'm part of a team that has early access?
[14:37] <cjwatson> You're a translation admin
[14:38] <seb128> k, I didn't know that had an impact on the UI
[14:38] <seb128> cjwatson, thanks
[14:39] <cjwatson> Let me see if I can at least sort out the cron schedule ...
[14:39] <seb128> thx
[14:44] <LocutusOfBorg> rbasak, I think I updated it
[14:56] <cjwatson> seb128: langpack cron job exists now and is 30 10 * * 2 for cosmic (i.e. previously the zesty schedule).  The next step on the checklist says that you (i.e. ~ubuntu-langpack) should adjust the langpack build scripts crontab to match
[15:33] <seb128> cjwatson, k, I can do that, thx
[15:37] <seb128> cjwatson, done
[15:39] <cjwatson> seb128: Thanks.  Now I think we wait until early next week for the first export to happen, and if it looks sensible we can open translations
[15:40] <seb128> cjwatson, sounds good, thx
[16:40] <bdmurray> juliank: I ran another search for cosmic triggers and noticed bumblebee changed from its activate update-initramfs to activate-noawait. Is that worth fixing too?
[16:41] <juliank> bdmurray: Yes, I think sdo
[16:42] <bdmurray> juliank: Okay, doing so.
[16:43] <bdmurray> Hrm, I've added a bumble task but there are no distro-series tasks.
[16:44] <juliank> Launchpad bug!
[16:45] <bdmurray> Looking at bug 1750465 there should be a budgie-artwork xenial task too but there isn't.
[16:45] <ubottu> bug 1750465 in ubuntu-mate-artwork (Ubuntu Xenial) "upgrade attempting to process triggers out of order (package plymouth-theme-ubuntu-text 0.9.2-3ubuntu17 failed to install/upgrade: dependency problems - leaving triggers unprocessed)" [High,Confirmed] https://launchpad.net/bugs/1750465
[16:45] <juliank> cjwatson: ^ 1780996 is missing tasks for xenial, bionic
[16:45] <juliank> for bumblebee
[16:45] <juliank> bug in launchpad?
[16:46] <juliank> and that other thing
[16:46] <cjwatson> bdmurray: Not sure, did you add this using the API?
[16:47] <cjwatson> Can't really look right now, but these sorts of giant bugs affecting a bazillion packages are usually a bad idea
[16:47] <bdmurray> cjwatson: No, I just added the bumblebee task via the web interface.
[16:48] <juliank> bdmurray: in the other bug, the xenial task was removed by fossfreedom
[16:48] <juliank> no longer affects: budgie-artwork (Ubuntu Xenial)
[16:50] <bdmurray> Ah, that package doesn't exist in Xenial - okay.
=== led_ir23 is now known as led_ir22