[00:19] <Unit193> Just curious at this point, but how would Ubuntu handle a request from a Debian maintainer to blacklist his package from autosync?  Is there already a process for this?
[00:25] <bryyce> Unit193, dunno if there is a process for Debian specifically, but it is possible to prevent packages from automatically syncing.  I might suggest filing a launchpad bug against the package in question, and subscribing the appropriate admin team (maybe ubuntu-archive?)
[00:28] <Unit193> OK, thanks.
=== guiverc2 is now known as guiverc
[09:02] <seb128> xnox, ddstreet, other people who might have a clue about that, could you check https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1880258 and see if it makes sense to you?
[09:02] <ubottu> Launchpad bug 1880258 in systemd (Ubuntu) "Add trailing dot to make connectivity-check.ubuntu.com. absolute and reduce NXDOMAIN warning noise" [Undecided,New]
[09:02] <seb128>  [connectivity]
[09:02] <seb128> -uri=http://connectivity-check.ubuntu.com/
[09:02] <seb128> +uri=http://connectivity-check.ubuntu.com./
[09:03] <seb128> I'm happy to merge the change but I don't understand enough the issue to know if it's the right fix
[09:27] <seb128> juliank, hey, is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958960 something you can review/fix?
[09:27] <ubottu> Debian bug 958960 in src:synaptic "synaptic: FTBFS in Ubuntu" [Normal,Open]
=== Wryhder is now known as Lucas_Gray
[10:06] <juliank> seb128: Don't really care, nothing new there
[10:07] <juliank> I've done an NMU to make it build, it works fine in Debian, and we have no need to merge it in Ubuntu, so why bother?
[10:11] <seb128> juliank, you mean by "no need to merge it in Ubuntu'?
[10:11] <seb128> juliank, sure we can ship outdated software but that's not great
[10:12] <seb128> juliank, we usually do merge on Debian at least once by cycle
[10:18] <xnox> seb128:  https://serverfault.com/questions/803033/should-i-append-a-dot-at-the-end-of-my-dns-urls so adding the dot means "lookup on the real internet, do not try to do local network lookups"
[10:18] <xnox> seb128:  in some ways it is correct, and will make the connectivity check quicker.
[10:18] <xnox> seb128:  the NXDOMAIN stuff, fedora gave up on it, i wonder if we should too.
[10:19] <xnox> seb128:  i think the '.' will prevent doing those lookups with warnings, when there is no default route anywhere.
[10:19] <xnox> thus UX wise is good.
[10:21] <seb128> xnox, k, and no expected drawback right? said differently no reason to not do it?
[10:24] <xnox> seb128:  drawbacks => it is http url, if it's ever switched to https, it would need multiple domains in the cert.
[10:24] <xnox> seb128:  but i guess it is intentionally http, to catch captive portals, which cannot be https.
[10:24] <xnox> seb128: but interestingly enough http://start.ubuntu.com./connectivity-check does not work =(
[10:24] <xnox> and gives me 503
[10:25] <xnox> seb128:  do test that our deployment is correct and/or check with IS if they are happy for us to hit it with trailing dot by default.
[10:25] <xnox> from client point of view it's fine, but IS might not like it from endpoint point of view.
[10:25] <xnox> i.e. it will make it harder in corporate environments to fake that dns name i think.
[10:26] <xnox> (cause some do that)
[10:27] <seb128> xnox, right, I will check with IS, thanks
[10:41] <juliank> seb128: you do know that basically the only change in there is that it's now saving the column width?
[10:42] <seb128> juliank, does it matter? still having a package in sync and uptodate is a win compared to having it outdated and showing on the merge report and having users bothering us
[10:42] <juliank> But I just noticed it seems to be missing the 0.84.6ubuntu5 change in debian
[10:43] <juliank> seb128: yes it does, we only do manual work if there are meaningful changes
[10:43] <seb128> juliank, the angle I was coming from is bug #1870900 in the sponsoring queue
[10:43] <ubottu> bug 1870900 in synaptic (Ubuntu) "Sync synaptic 0.90+nmu1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1870900
[10:44] <seb128> so it bothered some contributor enough that they went to file a bug and subscribe sponsors
[10:44] <seb128> anyway,  feel free to keep an ubuntu delta if you wish, I argue enough on the topic
[10:52] <juliank> seb128: It's tough. We need to remove the patches series in Debian to comply with new rules there, but we still need to keep 01_ubuntu_changelog.dpatch effectively, or well, rework it
[10:52] <juliank> It's quite some work
[10:53] <seb128> juliank, the debian reports stated the patch isn't needed anymore, is that wrong?
[10:54] <seb128> 'I suspect this file can simply be dropped, as synaptic
[10:54] <seb128> builds fine in Ubuntu without it, and is still able to retrieve
[10:54] <seb128> changelogs due to PR #45.'
[10:54] <seb128> https://github.com/mvo5/synaptic/pull/45
[10:55] <seb128> juliank, without removing the patch series we could at least update the patch so it applies as a first step
[10:55] <juliank> seb128: Yes of course it's wrong ,the patch is mostly not about changelogs.
[10:56] <juliank> well, half of it is
[10:57] <juliank> seb128: Half of the patch is about showing you correct supported or not status
[10:57] <juliank> :D
[10:57] <juliank> Though that's also missing ESM
[10:57] <juliank> We should add ESM to list of supported origins
[10:58] <seb128> juliank, k, I'm not familiar with that patch, I was just trying to clean some of the sponsoring queue. Thanks for responding. Ideally we would still refresh that patch in Debian so it applies then we can sync :)
[10:58] <juliank> and then there's code telling you to look at launchpad if changelog could not be found, which does not work for ESM
[10:59] <juliank> seb128: Refreshing the patch would not be a valid NMU reason IMO, and just an annoying useless download Debian users.
[10:59] <juliank> Gotta merge it I guess
[11:00] <seb128> juliank,you are afraid that mvo would freak out about you updating the ubuntu patch in Debian?!
[11:01] <seb128> mvo, how angry would you be in juliank NMU synaptic in Debian to update 01_ubuntu_changelog.dpatch to correctly apply to the current version?
[11:01] <juliank> seb128: Oh I'm sure mvo is fine with that, but other Debian people will look funny and disapprovingly :)
[11:01] <seb128> juliank, the missing fix from 0ubuntu5 might be enough of a reason for an upload
[11:02] <juliank> seb128: It's actually not missing it seems
[11:02] <seb128> juliank, I don't think other Debian people care about who a maintainer authorize to NMU that package
[11:02] <seb128> that discussion is ridiulous...
[11:02] <juliank> In any case, I should rework this properly so we don't need all that dpatch stuff and become compliant with the TC ruling on distro-specific patch series
[11:09] <xnox> seb128:  ubuntu first..... derivatives can cherrypick our patches.
[11:10] <seb128> xnox, yes, that discussion started out by me mentioning a sync request we have for synaptic in the sponsoring queue
[11:11] <seb128> xnox, it drifted to juliank ask why we need to merge packages and saying Debian maintainers wouldn't approve him including Ubuntu patch refreshes in a NMU even if the maintainer is fine with it
[11:11] <seb128> weird world
[11:12] <juliank> seb128: You do know there are quite a few people in Debian who hate Canonical, Ubuntu, and I don't want to give them more cannon fodder
[11:13] <juliank> because in the end we end up with a heated discussion that "Canonical NMUs packages with ubuntu-only changes" and I'm not interested in that.
[11:14] <juliank> Ugh, and I found a synaptic memory leak
[11:25] <juliank> OTOH, they do have a story to tell about how an ubuntu person uploaded an NMU that doesn't even build on Ubuntu
[11:25] <juliank> fun!
[11:26] <seb128> :)
[11:29] <xnox> seb128:  just RM synaptic from Ubuntu Archive
[11:29] <xnox> =)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
[11:29] <xnox> Fix Released
[11:29] <seb128> wfm
[11:30] <seb128> really I just saw an opportunity to have one more package in sync which means less work from our side
[12:39] <mvo> juliank, seb128 sorry, only now saw the discussion, let me know how I can help
[12:41] <seb128> mvo, I guess it would help if you could refresh 01_ubuntu_changelog.dpatch to apply and do an nonNMU upload of synaptic at some point, juliank believe that if he does that as not being the maintainer the Debian people who hate Ubuntu are going to be after him
[12:41] <mvo> seb128: sure thing, I cna do that
[12:41] <seb128> mvo, thanks :)
[12:42] <seb128> we should be able to sync back again then
[12:42] <mvo> seb128: yeah, I need to check why it's not, it was at some point
[12:42] <seb128> mvo, some new apt fixes that have been NMUed since
[12:43] <seb128> mvo, we could sync, but it 0.90 doesn't build on Ubuntu due to the Ubuntu patch not applying (which isn't impacting Debian/didn't get noticed when building there)
[12:43] <mvo> seb128: aha, ok
[12:43] <mvo> seb128: so it's just this refresh, I will see what I can do, today is a bit busy but maybe tonight or tomorrow
[12:47] <seb128> mvo, thanks!
[12:47] <seb128> mvo, no hurry, it's a minor thing
[12:47] <seb128> so whenever you will have free cycles (if ever ;)
[12:48] <juliank> mvo: also debian wants us to get rid of the per-distro patch series entirely, which is why I was thinking to do like if dpkg-vendor --derives-from ubuntu; then CPFFLAGS+=-DVENDOR_DERIVED_UBUNTU; and put stuff inside #ifdef
[12:49] <juliank> Or even better, if () ...
[12:49] <juliank> so that we build the same code on debian and ubuntu
[12:58]  * mvo nods
[14:54] <ahasenack> hi, anyone aware of this error that I just started seeing with tdb /i386 dep8 tests:  libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed
[14:54] <ahasenack> http://autopkgtest.ubuntu.com/packages/t/tdb/groovy/i386
[14:59] <ahasenack> ah, an ftbfs in latest gcc10
[15:00] <LocutusOfBorg> wgrant, just FYI according to this page: https://buildd.debian.org/status/logs.php?pkg=util-linux&arch=riscv64 the logs from 2020-06-21 02:10:59 (failed) and 2020-06-21 11:05:43 (good) differs in kernel change from 5.0 to 5.7
[15:00] <LocutusOfBorg> considering Ubuntu has 5.4, I would say that something in kernel changes between 5.4 and 5.7 "fixed it"
[15:56] <LocutusOfBorg> jamespage, hello, FYI I'm syncing python-rfc3986
[16:25] <ricotz> might be good to remove gcc-10 from -proposed?
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
[18:10] <ricotz> LocutusOfBorg, hi, is libmount-dev missing a dep on libcryptsetup-dev?
[18:12] <ricotz> https://launchpad.net/ubuntu/+source/util-linux/2.35.2-5ubuntu2
[18:20] <bdmurray> vorlon: I'm looking at the gkrellm2-cpufreq ftbfs and it depends on licpupower-dev which is provided by linux in debian. What's the way forward here?
[18:21] <vorlon> bdmurray: ask the kernel team if they can provide libcpupower-dev; if not, blacklist the package?
=== luisp is now known as luisp_
=== luisp_ is now known as luisp
[20:11] <LocutusOfBorg> ricab_, already fixed thanks :D
[20:11] <LocutusOfBorg> sed s/ricab_/ricotz/
[21:11] <bryyce> seb128, teward nginx 1.18.0-3ubuntu1 is in proposed now, if it helps for that focal version string sru.
[21:12] <teward> it should since it's now lower than Groovy
[21:12] <teward> i think anyways
[21:12] <teward> seb128: i'll just leave this in your hands while I go get drunk.  'tis booze o-clock here :)
[21:51] <bdmurray> well that was some honesty there
[21:58] <bdmurray> vorlon: looking at gajim in update_output.txt it added a break on gajim-rostertweaks so then that package becomes uninstallable. Oh and there is a debian request to remove it.
[21:59] <bdmurray> vorlon: So do I just need to ping an AA about removing it?
[21:59] <bdmurray> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963604
[21:59] <ubottu> Debian bug 963604 in ftp.debian.org "RM: gajim-rostertweaks -- ROM; not maintained upstream" [Normal,Open]
[23:48] <sarnold> Laney: oh yes, polite reminder that eoan support ends in a month or so, we usually send a message like https://lists.ubuntu.com/archives/ubuntu-announce/2019-July/000246.html to give folks a heads-up
[23:48] <sarnold> Laney: (where "we" means "someone on behalf of the release team" :)