| === BrAsS_mO- is now known as BrAss_mOnKeY | ||
| === BrAss_mOnKeY is now known as BrAsS_mOnKeY | ||
| 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:38 |
|---|---|---|
| velho | From package manager means apt source.. | 03:39 |
| 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:41 |
| 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:42 |
| tsimonq2 | s/apt-get/apt/ ;) | 03:43 |
| 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:44 |
| tsimonq2 | hehe | 03:45 |
| velho | I'll get an error message due to libtasn1-3-bin not available, replaced by libtasn1-bin:i386 libtasn1-bin | 03:52 |
| velho | Is it not gnome-shell what is running as defualt in Ubuntu nowdays ? | 03:53 |
| velho | Screwing around | 04:08 |
| velho | It was meson build | 04:08 |
| velho | Lol | 04:08 |
| velho | IDE / Editor choices? | 04:29 |
| tsimonq2 | Vim :P | 04:42 |
| 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:41 |
| LocutusOfBorg | apw, nice | 07:52 |
| 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:53 |
| LocutusOfBorg | juliank, ^^ does this ring a bell? | 07:58 |
| juliank | LocutusOfBorg: well, artful seems fine | 08:00 |
| 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:01 |
| 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:02 |
| juliank | LocutusOfBorg: the file is fine | 08:03 |
| juliank | LocutusOfBorg: I basically think he ran dpkg --force-depends -i libpng16-16 from xenial | 08:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| LocutusOfBorg | I didn't even think about that possibility | 08:10 |
| juliank | I've seen quite a few of these cases. | 08:11 |
| 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:13 |
| apw | and now i can't complete an update because it is broken | 08:14 |
| juliank | apw: I don't really know | 08:16 |
| 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:17 |
| apw | juliank, will give that a go, ta | 08:19 |
| === BrAsS_mO- is now known as BrAsS_mOnKeY | ||
| rbasak | juliank: what's the regression risk on your python-apt data changes? Have you done this without an SRU tracking bug before? | 08:45 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| rbasak | Your choice not to use a tracking bug. But that's information that isn't obvious! | 08:52 |
| juliank | rbasak: Well, good you asked :) | 08:55 |
| 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:56 |
| 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:57 |
| rbasak | I get the impression that each one needs reviewing individually to make sure that await isn't actually needed. | 08:58 |
| juliank | Which is what we do when uploading, but I have not recorded the reasoning so far | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| juliank | odd | 09:03 |
| 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:04 |
| 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:05 |
| juliank | Actually, modules would be fine to keep await | 09:06 |
| juliank | Since modules for gio link against glib, you always get correct ordering, so converting those to noawait is not neccessary | 09:07 |
| juliank | I think it's just a performance optimization there, as it avoids some caching runs | 09:08 |
| rbasak | juliank: data/templates/Ubuntu.mirrors is different between your python-apt uploads in Trusty and Xenial. Intentional? | 09:16 |
| juliank | rbasak: I think trusty is a day newer | 09:17 |
| juliank | And one mirror went away in that time and a new one popped up at utexas | 09:18 |
| 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:19 |
| rbasak | juliank: nearly there :-/ | 09:21 |
| 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:22 |
| 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:23 |
| rbasak | Maybe just put that explanation in the one bug we have for this time, please? | 09:24 |
| juliank | rbasak: yes | 09:24 |
| juliank | rbasak: Added | 09:28 |
| rbasak | Thanks! | 09:30 |
| 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:54 |
| LocutusOfBorg | rbasak, I already did the microreleases 4 times for vbox, should I copy-paste the same? | 09:56 |
| LocutusOfBorg | we upgraded from 5.0 to 5.1, the diff was around 10MB :D | 09:57 |
| 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 | 09:59 |
| LocutusOfBorg | done I guess, I have many people reporting that the version in unapproved fixes the issue | 10:07 |
| LocutusOfBorg | even if the diff looks big, it is really a couple of changes and lots of autogenerated stuff :) | 10:08 |
| rbasak | LocutusOfBorg: was this a previous SRU regression? | 10:39 |
| 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. | 10:40 |
| 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:03 |
| 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:04 |
| 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:30 |
| mapreri | (feel free to redirect me to any better fora if there are any) | 11:39 |
| === apw_ is now known as ap | ||
| === ap is now known as Guest79801 | ||
| === Guest79801 is now known as apw | ||
| velho | Who | 12:13 |
| velho | is responsible for gnome-shell dev for ubuntu? | 12:14 |
| 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:16 |
| velho | rbasak: Yea was too lazy to open launchpad | 12:21 |
| 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:22 |
| LocutusOfBorg | rbasak, changes were done by mesa folks, and one other incompatibility was in kernel hwe | 12:40 |
| 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 | 12:43 |
| 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:32 |
| cjwatson | seb128: We should probably do the rest of https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings, yes | 14:35 |
| 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:37 |
| seb128 | k, I didn't know that had an impact on the UI | 14:38 |
| seb128 | cjwatson, thanks | 14:38 |
| cjwatson | Let me see if I can at least sort out the cron schedule ... | 14:39 |
| seb128 | thx | 14:39 |
| LocutusOfBorg | rbasak, I think I updated it | 14:44 |
| 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 | 14:56 |
| seb128 | cjwatson, k, I can do that, thx | 15:33 |
| seb128 | cjwatson, done | 15:37 |
| 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:39 |
| seb128 | cjwatson, sounds good, thx | 15: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:40 |
| juliank | bdmurray: Yes, I think sdo | 16:41 |
| bdmurray | juliank: Okay, doing so. | 16:42 |
| bdmurray | Hrm, I've added a bumble task but there are no distro-series tasks. | 16:43 |
| juliank | Launchpad bug! | 16:44 |
| 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:45 |
| juliank | and that other thing | 16:46 |
| cjwatson | bdmurray: Not sure, did you add this using the API? | 16:46 |
| 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:47 |
| juliank | bdmurray: in the other bug, the xenial task was removed by fossfreedom | 16:48 |
| juliank | no longer affects: budgie-artwork (Ubuntu Xenial) | 16:48 |
| bdmurray | Ah, that package doesn't exist in Xenial - okay. | 16:50 |
| === led_ir23 is now known as led_ir22 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!