=== ubott2 is now known as ubottu
[08:02] <acheronuk> tianon: do you happen to know when cosmic docker images are next likely to be updated?
[08:05] <mwhudson> acheronuk: when either he or i get around to clicking the button
[08:05] <mwhudson> acheronuk: is there some change you are after?
[08:06] <mwhudson> ah i guess the new glibc is probably a good reason to update
[08:07] <acheronuk> mwhudson: Yeah. I have an issue with building Kubuntu CI cosmic container, which could be because glibc mismatch
[08:08] <acheronuk> 07:04:10 /usr/bin/ruby: relocation error: /lib/x86_64-linux-gnu/libnss_files.so.2: symbol __libc_readline_unlocked version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
[08:08] <acheronuk> if I start with glibc all up to date, then hoping that goes away!
[08:08] <mwhudson> hmm
[08:08] <mwhudson> still sounds like something that shouldn't be happening...
[08:10] <acheronuk> mwhudson: yeah, but I did not write the .rake and I'm not up to speed enough on docker/ruby to debug. so as said, rather hoping it goes away with upgraded images
[08:11] <acheronuk> bionic and xenial container still build/deploy fine
[08:11] <mwhudson> well i've started the process of updating
[08:12] <mwhudson> will probably have to wait until tianon wakes up to finish though
[08:13] <acheronuk> mwhudson: thanks. no problem. I'm busy with other stuff a lot of today, so won't look at this again until tonight or tomorrow anyway
[08:19] <mwhudson> acheronuk: https://github.com/docker-library/official-images/pull/4809
[08:19]  * mwhudson puts the laptop away
[08:21] <acheronuk> thanks :)
[08:32] <abeato> sil2100, hey, so what do you think of https://github.com/CanonicalLtd/ubuntu-image/pull/160 ? regardless of any redesign on how to handle grub.cfg on classic, would you be happy if I change it to remote /boot/grub/* instead of the whole folder?
[08:32] <abeato> s/remote/remove/
[10:49] <ricotz> xnox, hi :), meson 0.47.2-1 seems an important package to merge
[15:03] <LargePrime> Hi, i got a weird question.  it is possible to modify a key mapping of a device at the driver level?  on my own system
[15:04] <ahasenack> no idea what you mean, nor how it relates to ubuntu development
[15:05] <LargePrime> ya, i dont know where to ask.  this is my first guess
[15:05] <LargePrime> ahasenack, I have a mouse and i want to remap its buttons
[15:06] <LargePrime> the tools and guides I find give remaps that do not survive rebboots, or even replugging the usb device
[15:07] <LargePrime> So i was thinking to goto a lower level hack
[15:33] <sladen> LargePrime: use 'udev' to make the change each time the mouse is inserted
[15:33] <LargePrime> sladen, ya.  I was hoping to hack something at a lower leve, so as to not have to do it each time
[15:34] <sladen> LargePrime: udev does it for you, every time!
[15:35] <sladen> LargePrime: much much easier than hacking and recompiling drivers...
[15:35] <LargePrime> sladen, thanks.  I missunderstood
[15:35] <sladen> LargePrime: see https://unix.stackexchange.com/questions/65891/how-to-execute-a-shellscript-when-i-plug-in-a-usb-device replies
[17:37] <ahasenack> tjaalton: hey, is this something you could review? https://salsa.debian.org/sssd-team/sssd/merge_requests/2
[17:37] <tjaalton> ahasenack: there's noone else either, so..
[17:38] <ahasenack> tjaalton: you are the sole debian maintainer?
[17:38] <tjaalton> yes
[17:38] <ahasenack> happy to help whenever I can
[17:39] <tjaalton> cool
[17:44] <tjaalton> cyphermox: hi, there's a patch for grub2 that I need in cosmic for bug 1785033, do you want to handle it or can I?
[17:44] <ubottu> bug 1785033 in HWE Next "GRUB needs to support 64-bit efi linear frame buffer address" [High,In progress] https://launchpad.net/bugs/1785033
[18:09] <cyphermox> tjaalton: I'll do it
[18:11] <tjaalton> cyphermox: thanks. I've uploaded the patch to the t/x/b queue
[18:35] <cyphermox> tjaalton: if you've already uploaded to the queues, please make sure you also upload grub2-signed.
[19:24] <seb128> slangasek, I don't remember what you said about the netplan.io autopkgtest regression that is blocking network-manager in cosmic-proposed ... is anyone looking at it? likely this week?
[19:26] <slangasek> seb128: more likely this week than last
[19:26] <slangasek> cyphermox: ^^ is the netplan.io autopkgtest failure on your list for this week?
[20:08] <tjaalton> cyphermox: oh, ok
[20:27] <cyphermox> slangasek: ok
[20:28] <cyphermox> tjaalton: change of plans, I'll reupload grub2 in bionic along with grub2-signed
[20:39] <cyphermox> seb128: won't be done today, but I'm cutting a release I'll address that.
[20:43] <slangasek> cyphermox: does that mean the current tests are bad, rather than identifying a regression in network-manager, and I should hint around it?
[20:43] <cyphermox> slangasek: there's a difference in how Networkmanager reports DNS, you can hint around it
[20:44] <slangasek> ok
[20:44] <cyphermox> it's not a bad test, it's watching for NM's output, and NM did like systemd-resolved and grew this stupid ~. domain.
[20:44] <seb128> cyphermox, great, thanks
[20:45] <cyphermox> AFAICT there's no regression there, the expected "real"  domain is still there.
[21:16] <dadada> hi
[21:16] <dadada> please package github.com/browsh-org/browsh/   --- www.brow.sh  --- for Fedora. It's a text-based internet browser using Firefox as the backend.
[21:16] <dadada> sorry, I mean for Ubuntu :D
[21:18] <TJ-> dadada: we don't work like that. You'd need to find a package maintainer first, who would do the packaging. Ubuntu imports from Debian so if the package gets into Debian it'll percolate to Ubuntu later
[21:19] <dadada> TJ-: okay, I think they already tried to get it into Debian, thanks...
[21:19] <ginggs> dadada: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages#NEW_packages_through_Debian
[21:19] <ahasenack> a snap could be another option, although the firefox dependency might make that difficult to bundle
[21:20] <TJ-> yeah, it'd have to contain Firefox as well I guess. I like the idea though!
=== giraffe is now known as Guest22183
[21:34] <blackboxsw> sorry for the general/basic question here. I'm about to sponsor my first upload to cloud-init package for rharper. I have upload rights, but I'd like to sponsor He  generated the changeset into cosmic for cloud-init (and is the documented author of record in the most recent debian/changelog that I'll be uploading).    My understanding is that I don't need to do anything special in addition to just reviewing the
[21:34] <blackboxsw> changeset/approving it and uploading it as is.   Is this correct?
[21:51] <seb128> slangasek, cyphermox, thanks for unblocking the n-m update!
[21:53] <blackboxsw> looking over a previously sponsored change of mine. it seems that the changes email generated catalogs who signed the upload (the sponsor) and the author of the changeset (me)  https://lists.ubuntu.com/archives/cosmic-changes/2018-May/002547.html   so I *think* that sponsorship tracking is automatically handled when signed-by != Changed-by
[22:19] <nacc> blackboxsw: you will need to sign it, to upload it
[22:26] <blackboxsw> nacc: thanks I actually typed a message to you and nearly submitted as you had sponsored one of my uploads. Thanks will do!
[22:27] <Unit193> Right, so is it possible to "stage" a sync from Debian, such that it's not yet in proposed but it does trigger autopkgtests?
[22:28] <nacc> blackboxsw: :)
[22:28] <nacc> blackboxsw: so often, I will build the unsigned source package locally, then use debsign to sign it before upload.
[22:37] <blackboxsw> nacc: getting out for any pickup lately ?
[22:37] <blackboxsw> ultimate that is