| dja | cjwatson: thanks, at some point I'll look that up - I don't do much packaging in my new role | 00:02 |
|---|---|---|
| Guest56578 | Hrm. Someone should do something about the gvfs autopkgtest on s390x. | 00:45 |
| tsimonq2 | This is curious to me: https://launchpad.net/ubuntu/+source/lubuntu-default-settings/19.04.1 - in the changelog and in source.changes there is "Hans P. Möller <EMAIL>" yet Launchpad shows it as "EMAIL (Hans P. Möller)" - what's up here? | 00:46 |
| sarnold | you noticed seconds after it was uploaded, heh :) | 00:50 |
| tsimonq2 | Because I'm the one that uploaded it ;) | 00:52 |
| sarnold | I wondered if the umlaut was the cause, but an é didn't appear to cause the email (name) view on https://launchpad.net/ubuntu/+source/lxd/1:0.4 | 00:53 |
| tsimonq2 | It might be the umlaut, either that or the . | 00:54 |
| tsimonq2 | That's probably something cjwatson would know ;) | 00:55 |
| Unit193 | Someone should really take care of pastebinit and Debian 916372 | 00:56 |
| ubottu | Debian bug 916372 in pastebinit "pastebinit: multiple deprecation warnings under Python 3.7" [Normal,Open] http://bugs.debian.org/916372 | 00:56 |
| tsimonq2 | It's not the umlaut: https://launchpad.net/ubuntu/+source/software-properties/0.97.8 | 00:56 |
| Unit193 | Aka LP 1812232 | 00:56 |
| ubottu | Launchpad bug 1812232 in pastebinit (Ubuntu) "Deprecation warnings" [Undecided,Confirmed] https://launchpad.net/bugs/1812232 | 00:56 |
| tsimonq2 | stgraber: ^ | 00:58 |
| tsimonq2 | Unit193: Would you like to start an NMU process in Debian? | 00:58 |
| tsimonq2 | I will be happy to sponsor if you do the paperwork. | 00:59 |
| sarnold | python :( | 01:03 |
| tsimonq2 | sarnold: That's news? :) | 01:04 |
| sarnold | tsimonq2: just a recurring sadness | 01:04 |
| sarnold | every release breaks *something* | 01:04 |
| tsimonq2 | There's worse packages... | 01:05 |
| * tsimonq2 glares at glibc. | 01:05 | |
| sarnold | most of those are accidents though :) | 01:05 |
| tsimonq2 | HAH | 01:05 |
| tsimonq2 | I mean, you're not exactly *wrong*. | 01:05 |
| Unit193 | tsimonq2: Not really. | 01:13 |
| tsimonq2 | I'll do it then | 01:14 |
| === SuperKaramba is now known as BenderRodriguez | ||
| cjwatson | tsimonq2: It's the dot. See https://git.launchpad.net/launchpad/tree/lib/lp/archiveuploader/utils.py#n229 | 09:13 |
| ogra | wow, so screen *actually* has a fixed list of baud-rates it supports ... adding the 1500000 to the supported list makes it work with my rockchip board | 09:14 |
| ogra | (and oddly enough screen generates it C source from shell scripts dynamically during build ... so weird) | 09:15 |
| andrewsh[m] | hi everyone | 09:50 |
| andrewsh[m] | something’s changed, and when I compile Unity, I get: | 09:50 |
| andrewsh[m] | /usr/local/bin/cc -g -O2 -fdebug-prefix-map=/home/andrewsh/projects/unity=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DCHECK_FUNCTION_EXISTS=pthread_create -Wl,-Bsymbolic-functions -Wl,-z,relro -rdynamic CMakeFiles/cmTC_b30f1.dir/CheckFunctionExists.c.o -o cmTC_b30f1 -lpthreads | 09:50 |
| andrewsh[m] | /usr/bin/ld: cannot find -lpthreads | 09:50 |
| cjwatson | It surely ought to be -lpthread? | 09:51 |
| cjwatson | Even xenial didn't have a libpthreads AFAICS | 09:52 |
| cjwatson | I think this must mean that some bit of configure-time checking is failing to detect the actual pthread machinery and falling back to -lpthreads which really belongs to some other OS | 09:54 |
| cjwatson | So you probably want to debug the configure-time stuff (cmake or whatever) rather than that link line directly | 09:54 |
| cjwatson | (Also it should actually end up being -pthread rather than -lpthread IIRC) | 09:55 |
| cjwatson | It might just be a missing -dev package. Web-searching for "lpthreads" finds e.g. https://stackoverflow.com/questions/31948521/building-error-using-cmake-cannot-find-lpthreads which is a similar sort of tale of woe with that kind of solution | 09:56 |
| andrewsh[m] | strange thing, there's no mention of libpthreads anywhere in the source | 09:58 |
| andrewsh[m] | $ grep pthreads -R * | grep -v obj-x86_64-linux-gnu | wc -l | 09:58 |
| andrewsh[m] | 0 | 09:58 |
| cjwatson | andrewsh[m]: Maybe in some imported cmake module | 10:04 |
| cjwatson | andrewsh[m]: e.g. look at dpkg -L cmake-data | xargs grep -s pthreads | 10:04 |
| cjwatson | Perhaps FindThreads.cmake | 10:06 |
| cjwatson | Anyway it's hopefully somewhat clear from the cmake output ... | 10:06 |
| andrewsh[m] | well, yes, but why does it fail to find pthread | 10:06 |
| andrewsh[m] | weird | 10:06 |
| andrewsh[m] | -- Found Threads: TRUE | 10:10 |
| andrewsh[m] | I guess I need to set up sbuild 😕 | 10:11 |
| andrewsh[m] | right, sbuild-createchroot went just fine | 10:14 |
| cjwatson | rbalint: Please don't use the "Resubmit" vote on merge proposals to mean "I have addressed your comments". It means "this merge proposal needs to be put together completely differently and resubmitted from scratch". | 11:25 |
| ahasenack | doko: hi, could you take a quick look at https://launchpad.net/~ahasenack/+archive/ubuntu/samba-4.10/+packages to see if dependency-wise they match our expectations wrt python2/python3? | 11:58 |
| ahasenack | doko: samba in there only uses python3 now, no py2 dependency as far as I can see | 11:58 |
| ahasenack | the others (tdb, ldb, etc) have a mix, I chose to use both py2 and py3, and each dep is in its own package | 11:58 |
| ahasenack | I will cleanup the d/changelog entries now, some have a few "wip" entries and others I can squash together | 11:59 |
| doko | ahasenack: will do after lunch | 11:59 |
| ahasenack | ok | 11:59 |
| rbasak | jamespage: o/ | 12:05 |
| jamespage | irc proxy dropped off - not clear... | 12:05 |
| rbasak | So on bug 1814911, a few things don't seem right to me, so I wanted to discuss. | 12:05 |
| ubottu | bug 1814911 in python-urllib3 (Ubuntu Xenial) "charm deployment fails, when using self-signed certificate, which has IP address only (SAN)" [High,Triaged] https://launchpad.net/bugs/1814911 | 12:05 |
| jamespage | rbasak: morning | 12:05 |
| rbasak | First, it doesn't feel right to be changing the dependency structure in an SRU for a feature, unless we're specifically trying to add that feature in the SRU directly, which I'm not sure we are? I think you alluded to that feeling in comment 4? Anyway, that's why I have other questions. | 12:06 |
| rbasak | The SRU user impact says that Trusty isn't really affected - is that still true? | 12:07 |
| rbasak | I'm sorry, that Xenial isn't really affected. | 12:07 |
| rbasak | jamespage: also, in comment 11, you tested to see if an upgrade would bring in the recommends, but you used "apt install" which I think could be different from "apt upgrade"? | 12:08 |
| rbasak | So will adding the Recommends really work? | 12:08 |
| rbasak | And then finally, back to my first point - is this something that we really want, or could it be worked around in charms for old releases? | 12:08 |
| doko | oSoMoN: fyi, we are aiming for the openjdk-11 transition at the end of March. so LO may stay a little bit longer in -proposed ... | 12:08 |
| jamespage | rbasak: more than 1 month ago - need to refresh memory | 12:09 |
| doko | oSoMoN: ohh, not sure if you know that: https://hubicka.blogspot.com/2016/03/building-libreoffice-with-gcc-6-and-lto.html | 12:09 |
| oSoMoN | doko, no, I didn't know, reading now, thanks! | 12:10 |
| jamespage | rbasak: the recommends does not exist in xenial BUT python-ipaddress is already installed on a xenial base image I think | 12:11 |
| rbalint | cjwatson, ok, sorry for the wrong vote | 12:11 |
| jamespage | so a happy co-incidence means that stuff works OK on xenial, but not on trusty, where python-ipaddress is not installed | 12:11 |
| jamespage | rbasak: I'm actually OK with marking the xenial task as invalid - I fixed the UCA part with a UCA specific patch which we auto-apply to add the recommends | 12:12 |
| rbasak | jamespage: OK - but it's currently in Xenial unapproved and not in Trusty unapproved. | 12:12 |
| jamespage | rbasak: that's true - but this is a UCA specific issue on trusty, not a general trusty issue | 12:13 |
| === ricab is now known as ricab|lunch | ||
| rbasak | I see, OK. | 12:13 |
| jamespage | rbasak: xenial feeds trusty/mitaka in the UCA | 12:13 |
| rbasak | ah | 12:13 |
| rbasak | I think I understand the situation then, thanks. | 12:14 |
| rbasak | Are we in agreement to drop the Xenial SRU then? I'm still open to it if you want to push for it; I would prefer not to do it though. | 12:14 |
| jamespage | rbasak: updated bug | 12:16 |
| rbasak | Thanks! | 12:16 |
| rbasak | I'll reject from the queue then. | 12:16 |
| jamespage | +! | 12:26 |
| jamespage | 1 rather | 12:26 |
| LocutusOfBorg | seb128, do you think we should reupload a new poppler with this fix? 0.71.0-3 looks like the regression is not fixed... | 12:41 |
| LocutusOfBorg | (in the new upstream release) | 12:42 |
| seb128 | LocutusOfBorg, "this fix"? | 12:42 |
| seb128 | sorry I lack context | 12:42 |
| LocutusOfBorg | https://packages.qa.debian.org/p/poppler/news/20190302T103433Z.html | 12:48 |
| LocutusOfBorg | the new 0.71.0-3 has a fix that is not included in our ubuntu package | 12:49 |
| LocutusOfBorg | while the other patch might be useless | 12:49 |
| doko | LocutusOfBorg: did you see my virtualbox pings? | 12:51 |
| seb128 | LocutusOfBorg, we have 0.74 in proposed, we can't bypass that to land a fix in the disco pocket | 12:53 |
| LocutusOfBorg | doko, nope! where are them? | 12:54 |
| LocutusOfBorg | seb128, I mean, upload a new 0.74 in proposed with that patch | 12:55 |
| LocutusOfBorg | how long will it take to migrate? | 12:55 |
| seb128 | no idea | 12:55 |
| doko | LocutusOfBorg: your virtualbox-hwe (and most likely virtualbox as well) ftbfs in bionic-proposed | 12:55 |
| LocutusOfBorg | why the hell did it work on my ppa | 12:57 |
| LocutusOfBorg | damn | 12:57 |
| LocutusOfBorg | kmk: /usr/lib/jvm/default-java/bin/wsimport: Command not found | 12:57 |
| LocutusOfBorg | kmk: *** [/<<PKGBUILDDIR>>/src/VBox/Main/webservice/Makefile.kmk:468: /<<PKGBUILDDIR>>/out/obj/vboxjws-gen/jwsgen/jwsglue.list.ts] Error 127 | 12:57 |
| LocutusOfBorg | kmk: *** Waiting for unfinished jobs.... | 12:57 |
| LocutusOfBorg | JAVA, what else is to blame? | 12:57 |
| doko | LocutusOfBorg: openjdk-11, please fix | 12:59 |
| seb128 | LocutusOfBorg, I'm going to include that in the new upload, would be nice if upstream reviewed/merged it though | 12:59 |
| tdaitx | LocutusOfBorg: for wsimport please take a look at wsimport.sh from jaxws-ri (https://sources.debian.org/src/jaxws/2.3.0.2-1/jaxws-ri/bundles/jaxws-ri/src/main/resources/bin/wsimport.sh/) | 13:01 |
| LocutusOfBorg | tdaitx, I think we need some backported jaxstuff | 13:02 |
| LocutusOfBorg | yeah | 13:02 |
| LocutusOfBorg | I did that in my ppa already | 13:02 |
| LocutusOfBorg | https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/virtualbox-ppa | 13:02 |
| LocutusOfBorg | but having a fix doesn't make java less ugly | 13:02 |
| doko | LocutusOfBorg: all these are in bionic-proposed | 13:04 |
| LocutusOfBorg | yep | 13:04 |
| LocutusOfBorg | thanks! | 13:05 |
| LocutusOfBorg | seb128, the utf patch might be worse than the upstream already available version https://gitlab.freedesktop.org/poppler/poppler/merge_requests/133/diffs | 13:05 |
| LocutusOfBorg | the other patch is currently proposed upstream https://gitlab.freedesktop.org/poppler/poppler/merge_requests/189 | 13:06 |
| doko | LocutusOfBorg: please prepare packages, then I'll build those against the -security pocket, and binary-copy those to -proposed | 13:06 |
| seb128 | LocutusOfBorg, right | 13:06 |
| === ricab|lunch is now known as ricab | ||
| === Pici` is now known as Pici | ||
| doko | ahasenack: why build 2 and 3 in parallel? I would just remove 2 | 15:17 |
| doko | -rw-r--r-- root/root 353 2019-02-26 20:38 ./usr/lib/x86_64-linux-gnu/pkgconfig/pytalloc-util.cpython-37m-x86_64-linux-gnu.pc | 15:17 |
| doko | please check the pkgconfig files. these are bogus. and I think if you just build with python3 it's called like the python2 one | 15:18 |
| ahasenack | doko: you rather we get rid completely of python2 in these deps too? talloc, tdb, ldb? | 15:54 |
| ahasenack | I would have to check the reverse-depends then, see if they can all use python3, no? | 15:54 |
| xnox | ahasenack, my personal plan for next cycle is to yeah, start killing all the leaf python2 things if python3 exists, and i don't think there are that many reverse-deps for samba stack, as in, isn't it mostly self-contained? | 15:58 |
| ahasenack | it's the deps | 16:02 |
| ahasenack | like ldb, used by sssd | 16:02 |
| ahasenack | tdb I think also is used elsewhere | 16:02 |
| ahasenack | bzr-git pulls in python-tdb | 16:10 |
| ahasenack | and I think that's the only one | 16:13 |
| ahasenack | talloc and ldb are self contained in terms of reverse-depends | 16:13 |
| ahasenack | doko: ^ | 16:14 |
| nacc | ahasenack: and that's a reverse-recommends | 16:14 |
| ahasenack | xnox: ^ | 16:14 |
| nacc | ahasenack: not a depends | 16:14 |
| ahasenack | oh, right | 16:14 |
| ahasenack | so a) drop that to a suggests; b) get rid of python2-*? | 16:14 |
| nacc | python-samba rev-deps on python-tdb, but that's it | 16:14 |
| xnox | drop them. | 16:14 |
| ahasenack | hi nacc, btw :) | 16:14 |
| nacc | ahasenack: hiya :) | 16:15 |
| xnox | plus we probably gonna move to brz-git soon which is python3 | 16:15 |
| nacc | heh | 16:15 |
| ahasenack | brz | 16:15 |
| ahasenack | heh | 16:15 |
| nacc | xnox: whose clever naming is that? | 16:15 |
| ahasenack | xnox: so (a) for bzr-git? | 16:15 |
| xnox | nacc, well they had to fork the name to escale the cla. and it does do a provides alternative bzr | 16:16 |
| xnox | breezy is the name | 16:16 |
| xnox | https://launchpad.net/brz i don't know which one of them came up with the name | 16:16 |
| seb128 | vorlon, can you review fwupd-signed in cosmic SRU queue? the upload from friday failed binary upload because the package compute a binary version that is different from the source, and while 1.2ubuntu > 1.2 ... 1.2ubuntu+fwdupversion < 1.2 +fwdupversion | 16:27 |
| seb128 | vorlon, which I workarounded now by changing to 1.2.0ubuntu... | 16:28 |
| vorlon | seb128: done | 16:34 |
| seb128 | vorlon, thx | 16:34 |
| === led_dark_2 is now known as led_dark_1 | ||
| ahasenack | doko: after ./configure, make, make install, this is the layout with just python3: https://pastebin.ubuntu.com/p/DvrYypz2w5/ | 17:55 |
| ahasenack | the pkgconfig name mangling is there. is that really wrong, or just an annoyance? | 17:55 |
| doko | ahasenack: I would say, this is wrong, but yes it's upstream. so maybe leave that, and provide a symlink pytalloc-util.pc ? | 17:57 |
| ahasenack | sorry, my connection dropped, not sure if you replied | 18:00 |
| sarnold | < doko> ahasenack: I would say, this is wrong, but yes it's upstream. so maybe leave that, and provide a symlink pytalloc-util.pc ? | 18:01 |
| ahasenack | sarnold: thanks | 18:03 |
| ahasenack | doko: the build-depends on python{,3}-talloc-dev seem to come just from samba itself, ldb and tevent, aka, the "samba ecosystem", and they seem to build fine with that pkgconfig | 18:05 |
| ahasenack | how about I leave it as is, make sure I rebuild everything once I got rid of py2 in all these packages, and see if it breaks? | 18:05 |
| doko | ahasenack: fine with me | 18:08 |
| doko | ahasenack: and you can remove me dependency work around for talloc | 18:09 |
| doko | my ... | 18:09 |
| directhex | ok, so if i want to file a kernel bug using `apport-bug linux` I get a small (3K) apport log which basically only contains a list of package dependencies. if i want to append an existing bug with `apport-collect existing-kernel-bug` I get a huge 0.5MB report with loads of info - lspci, dmi info, etc. how can i get apport-bug to make a big log for a new kernel bug? | 18:53 |
| directhex | it's a networking issue, so i can't use apport-collect whilst booted into the bad kernel | 18:53 |
| directhex | aha, cracked it - had to copy the source_linux.py hook to source_linux-hwe.py | 19:33 |
| sarnold | aha :) | 19:34 |
| directhex | sadly not, you can no longer use ubuntu-bug, apport-cli, etc, to attach an apport report to an existing bug. they all tell you you _must_ use apport-collect to do that, but you can't use apport-collect offline | 19:53 |
| directhex | so it's not possible to file attachments to networking bugs 🤷 | 19:54 |
| nacc | directhex: can't you use apport-bug --save ? | 20:27 |
| nacc | directhex: or apport-cli? | 20:27 |
| directhex | apport-cli: error: -u/--update-bug option cannot be used together with options for a new report | 20:28 |
| directhex | apparently not. | 20:28 |
| xnox | popey, i lack powers! give me morrrrre powers please =) | 20:29 |
| mwhudson | good morning | 20:33 |
| ahasenack | hi mwhudson | 20:35 |
| nacc | directhex: what options did you specify? did you read the manpges, etc. | 20:38 |
| nacc | directhex: specifically, you use --save, then file --crash-file with -u, which is specifically mentioned in the manpage for netowrking related issues | 20:38 |
| directhex | $ apport-cli -u 1818294 -c ./apport.linux-image-4.15.0-46-generic.lz35uk5j.apport | 20:39 |
| nacc | directhex: further, i think you want #ubuntu :) | 20:39 |
| infinity | powersj: Yo. | 20:47 |
| powersj | infinity, hey I heard you want rails ownership | 20:48 |
| infinity | Don't make me start kicking people from this channel too. | 20:48 |
| powersj | :D | 20:48 |
| mwhudson | don't believe anything Odd_Bloke says | 20:48 |
| infinity | powersj: Is the "untested" state of the trusty.6 server ISOs accurate, or is the state actually "tested, but we haven't bothered posting results yet"? | 20:49 |
| infinity | powersj: (Asking because I wouldn't mind fixing a small PPC bug, which would trigger a respin of the server world, but I won't bother if it's all tested already) | 20:49 |
| powersj | infinity, the latter paride needs to update it. When we chatted this morning he was a go for release | 20:49 |
| infinity | powersj: Okay, I will just let my buglet live on then. | 20:49 |
| infinity | It was there in .5 too, I just apparently failed to notice, or didn't care enough to fix it. | 20:50 |
| infinity | Turns out this doesn't work so well with 4.4 kernels: | 20:50 |
| infinity | case "$KERNEL_MAJOR" in | 20:50 |
| infinity | 2.6|3.*) | 20:50 |
| infinity | Derp. | 20:50 |
| powersj | heh | 20:50 |
| mwhudson | i wonder how many things are going to break now that disco has 5 | 20:51 |
| mwhudson | you'd hope we'd learn that lesson eventually... | 20:51 |
| infinity | We learned some lessons with 2->3 and learned a lot harder with 3->4. | 20:51 |
| infinity | I don't expect 5 to be much of an event. | 20:51 |
| infinity | mwhudson: But also, doesn't everyone run in the --uname-2.6 personality to just fix all the bugs? :) | 20:53 |
| infinity | nosferatu:~$ linux64 --uname-2.6 uname -r | 20:54 |
| infinity | 2.6.79-13-lowlatency | 20:54 |
| infinity | Problem solved. | 20:54 |
| infinity | LP buildds ran in that personality for years while we hunted down everything that 3.0 broke. | 20:54 |
| mwhudson | infinity: omg what | 21:02 |
| mwhudson | i had no idea that was a thing | 21:02 |
| vorlon | I run in the SCOSVR3 personality to fix all the bugs | 21:07 |
| infinity | 13:48 < infinity> Don't make me start kicking people from this channel too. | 21:07 |
| vorlon | I have legitimately used the OSF4 personality before... but not this decade | 21:08 |
| mwhudson | what does Task-Key: do in seeds? | 21:16 |
| mwhudson | i am confused by the way the cloud-image seed has Task-Key: cloud-init | 21:17 |
| mwhudson | but e.g. open-sshserver has "cloud-image" not "cloud-init" in Task | 21:17 |
| infinity | mwhudson: Task-Key is a hint to tasksel. It's mostly useless these days. | 21:33 |
| infinity | mwhudson: But rgrep 'Key' in the tasksel source if curious. | 21:33 |
| mwhudson | infinity: seed_from_task in livecd-rootfs looks for it | 21:34 |
| mwhudson | but i wonder if it shouldn't | 21:34 |
| mwhudson | uh was that part of the big branch i reviewed | 21:35 |
| mwhudson | seems likely | 21:36 |
| infinity | Yup. | 21:36 |
| infinity | git blame puts it at 1ab78e78 | 21:36 |
| mwhudson | yeah | 21:36 |
| mwhudson | ok time to re-review that bit of that branch :) | 21:36 |
| infinity | For tasks with metapackages, Task-Key should be the metapackage itself, so it probably does what jibel wanted in the cases he wanted it. | 21:37 |
| infinity | But that's more luck than design. | 21:37 |
| mwhudson | the name that ends up in Task: in Packages is just the name of the seed, right? | 21:38 |
| infinity | Yeah. | 21:38 |
| mwhudson | so seed_from_task should probably just be echo $1 | 21:38 |
| infinity | Well, ish. | 21:38 |
| mwhudson | depending on what it's actually used for | 21:38 |
| infinity | If by "seed" he means "the file called 'desktop'", then it's more complicated than you make out. | 21:39 |
| mwhudson | now what about Task-Per-Derivative | 21:39 |
| infinity | Cause ubuntu-desktop == ubuntu/desktop | 21:39 |
| infinity | Task-Per-Derivative is what defines if the "desktop" file is "desktop" or "$flavour-desktop" | 21:42 |
| infinity | bzr+ssh://bazaar.launchpad.net/+branch/ubuntu-archive-publishing/ | 21:42 |
| infinity | lib/scripts/generate_extra_overrides.py | 21:42 |
| infinity | getTaskName() and getTaskSeeds() | 21:42 |
| infinity | That's the definitive UTSL documentation of how this works. | 21:43 |
| mwhudson | hnngh | 21:44 |
| mwhudson | i guess that is the relevant code | 21:44 |
| mwhudson | because when you say | 21:45 |
| mwhudson | add_task install foo | 21:45 |
| mwhudson | that ultimately finds the packages from the foo seed by looking for foo in the Task field in Packages | 21:45 |
| infinity | s/seed/task/ :P | 21:45 |
| mwhudson | yes | 21:46 |
| infinity | We never address anything by seed. Seeds are a backroom implementation detail. | 21:46 |
| infinity | And attempting to refer back to them after the fact might well be the real mistake here. | 21:46 |
| mwhudson | so we want to find the snaps that wouold have the foo in their task field if that was a thing | 21:46 |
| infinity | But I need tacos more than I need opinions. | 21:46 |
| mwhudson | maybe germinate needs to spit some more stuff out? | 21:47 |
| * mwhudson tries to figure out if this worked any less by accident before jibel's branch | 21:47 | |
| mwhudson | hm don't think so | 21:49 |
| mwhudson | oh right, the way to get snaps installed in a layered vs non-layered builds are basically disjoint | 21:53 |
| mwhudson | perrrobably should make that a bit more obvious | 21:53 |
| bdmurray | Why are distro-info-data stable updates also in security? | 23:26 |
| sarnold | it's fair game for folks to run with -security only | 23:27 |
| bdmurray | so if I have an SRU for it then you'd want to put it in -security? | 23:28 |
| sarnold | probably; I | 23:29 |
| sarnold | I've never done one myself so I'm not sure the criteria to use :) but if it's important for upgrading from one distro to the next, then it'd probably be a good candidate | 23:30 |
| bdmurray | Its not so I still wonder why its in -security. The update just added Disco. | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!