=== BrAsS_mOnKeY is now known as william
[05:44] <doko> nacc: are you handling php and the 7.2 transition? if not. please point somebody else to it ... looking at component mismatches proposed: libsodium needs a bug subscriber, dh-php a MIR, argon2 as well
[05:47] <doko> plus xml2
[05:49] <doko> rbalint: flash-kernel merge: mtd-utils probably needs a MIR
[05:51] <doko> jamespage: pycryptodome and pysmi need a MIR (dep of python-pysnmp4, openstack maintained)
[05:53] <doko> juliank: lvm2 merge: thin-provisioning-tools needs a MIR, or recommends dropped to suggests
[05:55] <doko> xnox: libzstd needs a MIR (for new btrfs-progs)
[06:20] <doko> juliank: please see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html for cryptsetup (unsatisfiable Depends)
[06:46] <doko> tsimonq2: libindi is stuck in proposed
[06:50] <Unit193> doko: I'd presume you saw Debian #888531 and https://wiki.debian.org/Teams/Ruby/ruby2.5?  (Including the test rebuild results.)
[06:50] <ubottu> Debian bug 888531 in release.debian.org "transition: ruby2.5" [Normal,Open] http://bugs.debian.org/888531
[06:51] <doko> Unit193: and?
[06:52] <Unit193> You expressed interest.  Good then.
[06:58] <doko> Unit193: it's scheduled for demotion
[06:58] <Unit193> Ah, that works too.
[07:10] <doko> ginggs: gazebo ftbfs (unstable as well)
[07:14] <juliank> doko: lvm2 ok, well, britney does not care, so I did not see that. cryptsetup hopefully sorts itself out once argon2 is MIRed and lvm2 is migrated.
[07:15] <doko> juliank: you see that in component mismatches proposed
[07:15] <doko> somebody has to write the argon2 MIR, either foundations, or server
[07:16] <juliank> doko: The argon2 MIR is at security review already :)
[07:16] <doko> ahh, ok. do they know? ubuntu-mir is not subscribed to the bug
[07:17] <juliank> Sure they are
[07:17] <juliank> https://bugs.launchpad.net/ubuntu/+source/argon2/+bug/1746047
[07:17] <ubottu> Launchpad bug 1746047 in argon2 (Ubuntu) "[MIR] argon2" [Undecided,In progress]
[07:17] <juliank> "Notified of all changes MIR approval team"
[07:18] <doko> hmm, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt doesn't show the subscription
[07:18] <juliank> and cyphermox did the review and reassigned to ubuntu-security
[07:18] <juliank> doko: It's older than the MIR I think
[07:20] <juliank> bug is 17:16, mismatches 12:24
[07:20] <doko> looks like it's out-of-date
[07:35] <ginggs> doko: ok, i'll look
[07:40] <juliank> doko: fixed lvm2. (I think it might be worth considering MIRing thin-provisioning-tools given that missing it could make your system unbootable if you use a cache LV, but um, let's worry about that later)
[07:43] <juliank> maybe it should just be made a bit smarter and refuse to generate cache LVs without them installed.
[08:24] <cpaelzer> xnox: we talked about lp 1744328 / debian 888764 - I'm kind of blocked on this, but unless Debian says yes I'd at least have a 2nd opinion to take it as Ubuntu Delta
[08:24] <ubottu> Launchpad bug 1744328 in nss (Ubuntu) "libfreebl3.so should be public, not in the nss subdir" [Undecided,New] https://launchpad.net/bugs/1744328
[08:24] <ubottu> Debian bug 888764 in nss "libfreebl3.so should be public, not in the nss subdir" [Normal,Open] http://bugs.debian.org/888764
[08:28] <xnox> doko, tah
[08:35] <tjaalton> cpaelzer: mike won't accept anything that upstream hasn't marked public :/
[08:35] <tjaalton> i've fought things like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855879 for years
[08:35] <ubottu> Debian bug 855879 in libnss3-dev "Please add blapi.h to libnss3-dev" [Normal,Open]
[08:36] <tjaalton> which I need for nss-pam which is needed for certmonger to be useful
[08:36] <cpaelzer> thanks for the info tjaalton
[08:36] <tjaalton> even looped in redhat folks
[08:36] <cpaelzer> I'm leaning towards adding that as a delta then, but would be pleased if a few people could ack on it
[08:37] <cpaelzer> I might prepare a proper MP for an Ubuntu Delta on it and add you and xnox to comment there
[08:37]  * cpaelzer is fully reading tjaalton's example bug now ...
[08:38] <tjaalton> was thinking if bringing this up on CTTE would be warranted or not
[08:42] <cpaelzer> sorry tjaalton - abbreviation overload - CTTE ?
[08:42] <tjaalton> debian technical committee
[08:43] <cpaelzer> I like your patch to 855879
[08:44] <cpaelzer> although reading all that makes me feel bad
[08:44] <tjaalton> crickets..
[08:46] <cpaelzer> maybe a combined version that would make the .so's accesible (for cases like mine) and the .a files (as suggested by you) would be the best
[08:59] <xnox> cpaelzer, hm..... surely all you need is a one line to create a symlink in like debian/libfoo.links and that's it, no?
[08:59] <xnox> cpaelzer, and just upload that into ubuntu direct.
[08:59] <cpaelzer> I know what I need :-) I just want to have a few acks on the way I do it :-)
[08:59] <xnox> cpaelzer, (possibly with dh-exec if you need DEB_HOST_MULTIARCH location)
[09:00] <cpaelzer> and after reading into all of tjaalton it might be the time to do a more generic overhaul
[09:00] <cpaelzer> xnox: but I hear you are not opposed to making the libs accessible - that was the important pre-check
[09:00] <cpaelzer> slangasek: pointed me to "talk to xnox on this" - that is what I'm doing :-)
[09:01] <tjaalton> the new pkg for nss-pem can be added later
[09:02] <cpaelzer> tjaalton: ok so you have time to escalate this to Debian and back for nss-pem then?
[09:02] <cpaelzer> ok then I might really only change the .so's being a less invasive change
[09:02] <tjaalton> yes
[09:02] <tjaalton> filed the ITP for nss-pem
[09:02] <tjaalton> see what happens
[09:03] <cpaelzer> thanks, it still was very very sueful to get all that context on this
[09:03] <cpaelzer> useful even
[09:03] <xnox> cpaelzer, i don't think it is a good idea to create a new package, i don't think changing library location is ok, i think symlink is fine to satisfy everything you want, there is no need for new source or binary packages.
[09:04] <cpaelzer> yep, after the last few minutes of discussion here I'm agreeing to that xnox
[09:44] <xnox> tsimonq2, i made a huge mistake of uploading nodejs tweak =/ the amount of autopkgtests is humongous
[09:48] <doko> tsimonq2: does kubuntu care about qdigidoc? https://launchpad.net/ubuntu/+source/qdigidoc/0.4.1-0ubuntu2
[09:48] <doko> that seems to be out-of-date since 2012
[09:50] <doko> cjwatson: are you ok with temoting tickcount?
[09:51] <cjwatson> doko: yes
[09:51] <cjwatson> doko: I have a todo item to remove our use of it entirely (we need a sort of partial replacement, but can't continue using interpreter ticks)
[09:52] <doko> ok, unseeding then
[09:53] <cjwatson> doko: in general it doesn't make sense for python-* to be seeded on Launchpad's behalf any more.  Since ~2009 we've only used a relatively small number of system-packaged Python packages, and mostly use buildout (until end of last year) / pip (now)
[09:54] <cjwatson> doko: python-tickcount was an exception to that, but as I think I mentioned on the bug, if necessary we could keep it in our deployment PPA anyway
[09:59] <doko> ok. I'll just demote, don't remove it yet
[10:03] <xnox> doko, do we have a place to document / record 32-bit only issues that I have to dig/hunt to solve? e.g. I'm currently looking at i386 and i386+armhf only adt failures triggered by openssl upload.
[10:04] <doko> xnox: no, not afaik
[10:04] <doko> besides the i386 float stuff probably
[11:40] <cpaelzer> links/dh-exec doesn't like me :-/
[11:40] <cpaelzer> has someone an example of dh-exec in .links to create multiarch links?
=== zyga-ubu1tu is now known as zyga
[11:43] <xnox> cpaelzer, is the .links file executable?
[11:43] <xnox> cpaelzer, does it have dh-exec shebang?
[11:44] <xnox> cpaelzer, or can you push your repository somewhere for me to check it?
[11:44] <cpaelzer> it is just me never using it that way - I iterated a bit but it keeps failing with
[11:44] <cpaelzer> dh_link: symlink(nss/libfreebl3.so, debian/libnss3/usr/lib/${DEB_HOST_MULTIARCH}/) failed: No such file or directory
[11:45] <cpaelzer> I'm sure I do something wrong, but without an example to check against it is stupid iterating through trial-and-error
[11:45] <cpaelzer> I'm in a chroot of an sbuild and can tweak it
[11:45] <cpaelzer> atm it is like
[11:46] <cpaelzer> http://paste.ubuntu.com/26488822/
[11:46] <cpaelzer> and files relative to the build are like
[11:46] <cpaelzer> http://paste.ubuntu.com/26488823/
[11:46] <cpaelzer> I (currently) assume it doesn't have the variable exported or something like it
[11:46] <xnox> cpaelzer, there should never be leading '/' in any of these files
[11:46] <xnox> it should be executable
[11:46] <cpaelzer> I tihnk I had all variations of this :-/
[11:46] <xnox> thus something like:
[11:47] <xnox> horum =/
[11:48] <xnox> cpaelzer, and it should be full paths before and after....
[11:48] <cpaelzer> oh that I never tried
[11:48] <cpaelzer> ..
[11:48] <xnox> usr/lib/${DEB_HOST_MULTIARCH}/nss/libfreebl3.so usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so
[11:48] <xnox> i think, yet manual has leading slashes in examples.
[11:48] <cpaelzer> it also is the variable
[11:49] <cpaelzer> only when I drop the var I get to the "is a directory" error
[11:49] <cpaelzer> which is about the filename on the second argument as you just said
[11:49] <xnox> fun
[11:50] <cpaelzer> so "usr/lib/x86_64-linux-gnu/nss/libfreebl3.so usr/lib/x86_64-linux-gnu/libfreebl3.so" works
[11:50] <cpaelzer> now I need to find what I miss to get the variable resolved
[11:50] <cpaelzer> I had $() and ${} and tried on exporting the variable
[11:50] <xnox> include /usr/share/dpkg/default.mk on top of debian/rules?
[11:51] <cpaelzer> have it working now
[11:51] <cpaelzer> interesting
[11:51] <cpaelzer> it was the full path incl file on the second argument
[11:51] <cpaelzer> just when variables are used the error without it is way off
[11:51] <xnox> whoop whoop
[11:51] <cpaelzer> thanks xnox, now all that back into proper packaging for another full try :-)
[11:52] <cpaelzer> xnox++
[11:52] <cpaelzer> (we should have more of you)
[11:54] <doko> ohh no, I can't stand more noise ;p
[12:15] <cpaelzer> xnox: grml - we only made it 75% - it now links to a literal ./debian/libnss3/usr/lib/${DEB_HOST_MULTIARCH}/libfreebl3.so :-)
[12:17] <xnox> cpaelzer, as per $ man dh-exec-subst it says ${DEB_HOST_MULTIARCH} will be substituited....
[12:18] <cpaelzer> yes, but it is not :-/
[12:18] <cpaelzer> mabye it only calls plain dh-links in my case
[12:18] <cpaelzer> that is how it seems to me atm
[12:19] <cjwatson> cpaelzer: what's your debhelper compat level?
[12:19] <cpaelzer> 9
[12:19] <cjwatson> ok, 9 should work
[12:19] <cjwatson> cpaelzer: how about your source format?
[12:19] <cpaelzer> 3.0 (quilt)
[12:20] <cpaelzer> nothing too special on any of that
[12:20] <cjwatson> can I see the source package?
[12:21] <cpaelzer> sure it is essentially pull-lp-source nss + experimenting with debian/libnss3.links as http://paste.ubuntu.com/26488955/
[12:21] <xnox> cpaelzer, you have dh-exec as build-dependency right?
[12:21] <cpaelzer> I've had it
[12:21] <cjwatson> ideally I'd like to see your actual .dsc + extra files
[12:21] <cjwatson> especially the .debian.tar.*
[12:22] <xnox> cpaelzer, scp it to people.canonical.com?
[12:22] <Laney> the file is executable?
[12:22] <cpaelzer> executable - yes
[12:22] <cpaelzer> I'll upload and share a link
[12:29] <cpaelzer> I put all in a tarball at http://people.canonical.com/~paelzer/nss-links-multiarch.tgz
[12:30] <cpaelzer> I realized I had it not executable in the packaging yet (only per chmod in the sbuild chroot)
[12:30] <cpaelzer> so I cahnged that as well and am currently rebuilding
[12:30] <cpaelzer> I'll ping if this (as in the tarball) is still failing me on the rebuild
[12:39] <cpaelzer> nice - it really was the +x permissions before buildpackage
[12:39] <cpaelzer> I'll save all that as big learning experience
[12:39] <cpaelzer> thanks for your patience Laney, cjwatson and xnox
[12:40] <cpaelzer> it now worked (breaking things post dh_link due to that, but worked)
[12:40] <cjwatson> executable in the packaging> yep, that was why I wanted to check the .debian.tar.* :-)
[12:42] <cpaelzer> the follow on fallout is interesting
[12:42] <cpaelzer> dh-exec creates debian/tmp (as th emanpages tells me)
[12:42]  * Laney has been there before
[12:42] <cpaelzer> and until now the d/rules had mkdir debian/tmp (without -p)
[12:42] <Laney> forgetting to commit the mode change and being surprised when it didn't survive gbp buildpackage -S or something like that
[13:21] <jbicha> doko: LP: #1745634 would make it easier for me to try to demote xterm to universe
[13:21] <ubottu> Launchpad bug 1745634 in ubuntu-meta (Ubuntu) "Demote idle to universe" [Undecided,New] https://launchpad.net/bugs/1745634
[13:28] <doko> jbicha: yeah, probably worth doing that
[13:45] <jbicha> doko: cool. Could you unseed it or comment on the bug if you'd prefer I do it?
[13:51] <tjaalton> slangasek: hi, finally wrote a small patch to pam-auth-update to fix https://bugs.launchpad.net/ubuntu/+source/pam/+bug/1192719
[13:51] <ubottu> Launchpad bug 1192719 in pam (Ubuntu) "[pam-auth-update] add support for enabling non-default configs" [Wishlist,Confirmed]
[15:00] <doko> xnox: are you undoing my libp11 no-change uploads?
[15:01] <xnox> doko, ..... libp11 was not rebuild against openssl1.1.0 because we don't have that... thus p11 3 abi is a lie.
[15:02] <xnox> doko, we need to redo those uploads, properly, to rebuild that 3 abi, against the right openssl.
[15:05] <doko> yes, seen that now. will you do, or should I?
[15:08] <xnox> doko, either or. as you wish. I was planning to do the unwind.
[15:08] <doko> xnox: ok, please do
=== zyga_ is now known as zyga
[16:19] <nacc> doko: yes
[16:22] <nacc> doko: (re: php7.2)
[16:23] <nacc> doko: i'll be promoting it to main once i get it all fixed up, just like we did 7.1 previously, and removing 7.1 from the archive
[16:24] <doko> ta
[16:24] <doko> nacc: well, write the MIRs first ...
[16:25] <nacc> doko: yep
[16:28] <nacc> doko: to be clear the dh-php one is already resolved, just hasn't been caught up it seems (dh-php is only a suggests)
[17:22] <tsimonq2> doko: I'm aware.
[17:23] <tsimonq2> xnox: nodejs> ack :( thanks for telling me
[17:27] <nacc> doko: afaict, argon2 is not related to php?
[17:27] <tsimonq2> doko: I think at this point if it's KDE 4 or Qt 4 and you can handle rdeps, take it out
[17:53] <tsimonq2> I wonder if Bileto access could be reconsidered now that all PPA arches are unblocked.
[17:53] <tsimonq2> Maybe allow ~ubuntu-dev access or something :)
[17:54] <tsimonq2> I have access to do Qt transitions but I know it would be really useful to use with other Ubuntu Developers (with upload access)
[17:56] <tsimonq2> I might start a discussion on ubuntu-devel unless it's decided here :)
[17:57] <nacc> doko: ok, we've subscribed ubuntu-server to libsodium; is that enough to re-main it, once necessary?
[17:57] <ginggs> doko: gazebo and cyphesis-cpp uploaded, i think tinyxml2 will migrate if you rm openmw:arm64
[18:43] <doko> mwhudson: why is golang-1.8-go still in main?
[18:47] <doko> ginggs: done
[18:49] <ginggs> flexiondotorg: would you add Conflicts: telegram-desktop to your telegram PPA packages please?  It would prevent future bugs like LP: #1740708
[18:49] <ubottu> Launchpad bug 1740708 in telegram-desktop (Ubuntu) "package telegram-desktop 1.1.23-1 failed to install/upgrade: trying to overwrite '/usr/share/applications/telegramdesktop.desktop', which is also in package telegram 1.1.23-1~artful1.0" [Undecided,Invalid] https://launchpad.net/bugs/1740708
[18:49] <ginggs> doko: ta!
[18:49] <flexiondotorg> ginggs: OK
[18:50] <ginggs> flexiondotorg: ta!
[19:53] <slangasek> infinity, kees, mdeslaur, stgraber: TB meeting in 7?
[19:53] <mdeslaur> ack
[20:04] <mwhudson> doko: dunno, shouldn't be afaik
[20:16] <juliank> cjwatson: I'm looking at archivepublisher now to see where changes would be needed for valid-until support. It does not seem _that_ difficult. Basically we add the field for all -updates, -security releases; and add the release files to the set that needs updates if it's older than a week.
[20:17] <juliank> (and make validity 2 weeks)
[20:18] <juliank> old releases might be tricky
[20:18] <juliank> not sure
[20:19] <juliank> or, rather then looking at the age of the release file, we open it and check that valid-until does not expire for more than a week
[20:20] <juliank> I guess it needs a flag in the model somewhere that tells it "Valid-Until" is allowed
[20:21] <juliank> well "needs"
[20:50] <juliank> LP takes a while to branch :D
[21:17] <juliank> cjwatson: That is, https://paste.ubuntu.com/26491551/ or https://code.launchpad.net/~juliank/launchpad/valid-until
[21:17] <juliank> I have not run any tests yet...
[21:22] <juliank> update: http://paste.ubuntu.com/26491574/
[21:25] <juliank> forgot initialize...: http://paste.ubuntu.com/26491591/
[21:26] <juliank> now it needs tests and some testing
[21:26] <juliank> but I think the idea is clear.
[21:26] <juliank> ugh, should have posted in #launchpad
[21:27]  * juliank moves to #launchpad-dev
[21:32]  * tsimonq2 is curious about what Valid-Until support means and what the use case would be
[21:40] <cjwatson> juliank: something like that is probably a good start (note that when the bug was just filed it would have been a *lot* harder, because the ability to write just the Release file wasn't really there), but it'll need extensive tests
[21:40] <juliank> yeah
[21:41] <juliank> cjwatson: I also posted in #launchpad-dev now, so we can follow up there if needed :)
[22:18] <slangasek> tsimonq2: if you know that your archive is periodically republished, then including in the signed data that a given archive state is invalid after a given date prevents a silent replay attack
[22:23] <cjwatson> (assuming reasonably synced clocks etc.)
[22:36] <juliank> tsimonq2: To further comment, you can prevent what you could call update starvation. That is, for -updates, currently you can feed apt an old archive state all the time, and it says "oh fine, no updates".
[22:42] <tsimonq2> slangasek: Hm ok, interesting.
[22:42] <tsimonq2> juliank: So then what will apt do in the case of an old archive state?
[22:43] <juliank> tsimonq2: If the archive is not valid anymore it will give you an error if you update
[22:43] <juliank> tsimonq2: You can easily try that yourself in a Debian chroot, just set the clock backward :D
[22:43] <tsimonq2> juliank: heh OK :)
[22:44] <tsimonq2> juliank: What if I just have an outdated archive mirror that's *purposely* set that way for some reason? (obviously not in prod but for testing) Will I be able to override this in sources.list the same sort of way I override untrusted entries?
[22:45] <juliank> tsimonq2: You can set check-valid-until to no
[22:45] <juliank> you can also configure valid-until-{min,max}
[22:46] <juliank> these are in seconds, BTW
[22:46] <tsimonq2> Could you give an example (or a manual I can RTFM on)?
[22:47] <juliank> tsimonq2: It's all documented in sources.list, but no excamples in there I guess
[22:47] <juliank> tsimonq2: in the manpage, that is
[22:47] <juliank> tsimonq2: This feature is over 6 years old already
[22:47] <tsimonq2> juliank: oh hah, TIL
[22:48] <juliank> tsimonq2: Here's the LP bug from 2011: https://bugs.launchpad.net/launchpad/+bug/716535
[22:48] <ubottu> Launchpad bug 716535 in Launchpad itself "Please support Valid-Until in release files for security.ubuntu.com" [Low,In progress]
[22:49] <tsimonq2> juliank: subbed, thanks
[22:50] <Unit193> http://snapshot.debian.org/ also notes the use of check-valid-until.
[22:54] <tsimonq2> Oh, right. Interesting.
[23:03] <juliank> tsimonq2: It's a bit inconvenient in some use cases with historical distros, but it's a huge security improvement IMO
[23:03] <juliank> :D
[23:15] <tsimonq2> :D right