[00:03] <slangasek> yeah, I certainly remember there being ISPs about where you couldn't get online without PPTP.  openvpn, I've not heard of that one being used by an ISP
[04:50] <mr_lou> This bug was never fixed, but was closed anyway. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1737671
[04:50] <mr_lou> Am I the only one in the world in need of a working burner?
[04:54] <valorie> mr_lou: it says expired
[04:54] <valorie> give fresh info and it will reopen, afaik
[04:55] <valorie> I burn DVDs at festivals and such to give away ISOs
[04:55] <valorie> I don't have a blu-ray drive thought
[04:55] <valorie> just a USB one
[05:00] <mr_lou> valorie, There was another dude replying that he had the problem with his DVD burner too.
[05:00] <mr_lou> But obviously not many people use burners these days, so replies will be scarce.
[05:02] <mr_lou> valorie, What burner app do you use?
[05:02] <mr_lou> I use ImgBurn via Wine, because that's the only option I have for burning Blu-ray discs (needs UDF 2.5 which Ubuntu doesn't have).
[05:04] <valorie> I use k3b
[05:04] <valorie> a bit old, but it still works
[05:04] <valorie> no clue if it will do blu-ray
[05:05] <mr_lou> I won't.
[05:05] <mr_lou> Ubuntu doesn't have UDF 2.5
[05:06] <mr_lou> *It won't
[05:07] <mr_lou> k3b does seem to detect the drive. But doesn't give me Blu-ray options of course.
[05:07] <mr_lou> But I find it odd that kernel 97 lets ImgBurn detect the burner, and all following kernels doesn't.
[05:08] <mr_lou> Also tried with wodim and those. Also lets me burn "standard" stuff - but doesn't recognize a Blu-ray disc (of 25 gb). So trying to burn a blu-ray, wodim (and those) complains there's not enough room, which of course there is.
[05:12] <mr_lou> Added more info. Still expired though.
[05:25] <valorie> you might mention the bug number
[05:26] <valorie> perhaps you will catch the interest of a devel who can fix it
[05:26] <valorie> of course what is really wanted is a thorough analysis and a patch
[05:35] <mr_lou> Gotta go to work.
[05:35] <mr_lou> L8r
[09:01] <tjaalton> my desktop is happy even with bind-mounted /home, so I guess something got fixed in the past two years that forced me to use a symlink :)
[10:08] <GunnarHj> cjwatson, wgrant: What's the time frame for upgrading gettext? Doing so was the conclusion from the discussion we had last week with seb128 about bug #1756547.
[10:09] <wgrant> GunnarHj: Not this month unless there's no reasonable workaround. I thought we'd discussed removing the JS declaration?
[10:09] <wgrant> We can upgrade gettext if we really can't drop the JS declaration, but that's a lot easier.
[10:09] <sunweaver> oh well... I just dput ayatana-indicator-power without option from a bionic chroot to $UBUNTU
[10:09] <sunweaver> and I wanted to dput it to my personal PPA instead...
[10:10] <GunnarHj> wgrant: Yes, we discussed that as a plan B. Seb and I hoped for plan A. :)
[10:10] <sunweaver> in case anyone sees the upload, it should be REJECTed.
[10:11] <GunnarHj> wgrant: Please note that even if the bug is about one specific package, this is a general problem. gettext got more permissive, and translators upstream have started to make use of that possibility.
[10:12] <wgrant> sunweaver: 2018-04-06 10:06:10 INFO        GPG verification of /srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20180406-100554-003557/ubuntu/ayatana-indicator-power_2.0.93-2~ppa1_source.changes failed: Verification failed 3 times: ["(7, 58, u'No data')", "(7, 58, u'No data')", "(7, 58, u'No data')"]
[10:12] <wgrant> sunweaver: It wasn't signed, so was summarily rejected :)
[10:13] <wgrant> GunnarHj: I'm somewhat reluctant to do a major gettext upgrade on LP without thorough QA this late in an LTS cycle, but it's possible.
[10:15] <GunnarHj> wgrant: I can't tell anything about the risks. But I understand that translators and users in the affected countries are not impressed.
[10:18] <GunnarHj> wgrant: One way might be to try the workaround for one package to confirm that it works. As a base for decision.
[10:21] <GunnarHj> seb128: I'm talking with wgrant about the gettext upgrade. Can we try the workaround for gnome-shell to check that it works as a base for decision? wgrant stresses that there are risks with upgrading gettext this late.
[10:22] <wgrant> GunnarHj: We can do the gettext upgrade if we need to, but if it's just one or two packages affected I'd vastly prefer that their templates be revised.
[10:23] <wgrant> Much lower risk for regression.
[10:24] <wgrant> The gettext diff between xenial and bionic is one hundred and fifty thousand lines
[10:25] <GunnarHj> wgrant: But it used at runtime...
[10:28] <GunnarHj> wgrant: But let's try out the workaround, and try to figure out which packages are most affected.
[10:31] <wgrant> GunnarHj: The gettext upgrade would certainly unblock gnome-shell, but given the size of the diff I can in no way be confident it won't block unrelated other packages in bionic or other series. I've only seen the javascript format outdatedness be an issue in gnome-shell, so I'm reluctant to risk the other 29124 packages in bionic based on that, but if the workaround isn't trivial and there are other
[10:31] <wgrant> packages affected then I can dig in more depth.
[10:34] <seb128> GunnarHj, it should be possible to override_dh_translations in debian/rules and sed away the javascript comments from the pot
[10:34] <seb128> unsure how wrong that is though if the code is javascript
[10:34] <seb128> and if that can create other issues
[10:36] <wgrant> It's easy enough to validate a POT against xenial's gettext (hi LXD)
[10:37] <wgrant> It's the first time I've run into the JS attribute, but I suppose their may be others.
[10:38] <sunweaver> wgrant: thanks
[10:38] <seb128> wgrant, right, validating is one think, knowing that the result is the one expect is another
[10:38] <seb128> I've no clue what it change to have that format clue or not
[10:38] <wgrant> I've never seen that cause trouble before, but it's possible.
[10:42] <seb128> GunnarHj, well seems that safer approach would be probably at this point to sed those away from the debian/rules
[10:42] <seb128> as it trying to do that and see what's the result
[10:55] <GunnarHj> seb128: Ok. I'll fix a gnome-shell patch later today or Monday to start with.
[12:55] <juliank> I see a weird test suite failure with apt in docker's ubuntu:bionic
[12:56] <juliank> We create a temporary package with a changelog, and isntall it
[12:56] <juliank> (in a different, temporary, rootdir)
[12:57] <juliank> but there's no changelog in ithe installed package apparently
[12:57] <juliank> on my own bionic system it works just fine
[12:57] <juliank> for example, https://travis-ci.org/julian-klode/apt/jobs/363080996
[12:57] <juliank> (APT falls back to HTTP, and thus fails the test)
[13:00] <juliank> I just thought that maybe the docker image ships a dpkg.cfg.d snippet that disables changelog installing?
[13:00] <juliank> I'm not sure if APT's test suite protects against dpkg.cfg files
[13:02] <juliank> let's check, I guess.
[13:02]  * juliank installs docker ... :(
[13:08] <juliank> found /etc/dpkg/dpkg.cfg.d/excludes
[18:16] <tjaalton> ahasenack: halp. I need sssd 1.16.1 for freeipa :P
[18:17] <ahasenack> because of a bug fix?
[18:18] <tjaalton> no, 4.7-pre1 needs it, and that's needed for sqlite nssdb support et al :/
[18:19] <tjaalton> but, 1.16.1 really is worth it
[18:20] <tjaalton> it's been on debian testing for some weeks, it works
[18:20] <ahasenack> I'm not against it. It feels like you have more reasons for an FFe than I do
[18:21] <ahasenack> you are a core dev, much easier for you to do it than I :)
[18:21] <ahasenack> brb
[18:21] <tjaalton> sure
[18:28] <ahasenack> back
[18:30] <ahasenack> tjaalton: you still prefer the newer freeipa version as opposed to revert the previous one, which didn't need nssdb?
[18:30] <ahasenack> er, nss-pem
[18:31] <tjaalton> we have nss-pem, and would need to go to 4.5
[18:32] <tjaalton> even 4.6 doesn't work with current dogtag & certmonger which are needed to support sqlite nssdb's etc
[18:32] <ahasenack> where is nss-pem? I don't see it in bionic
[18:32] <tjaalton> libnsspem
[18:32] <ahasenack> I see, new in bionic
[18:32] <ahasenack> you got that in recently?
[18:32] <tjaalton> yes
[18:33] <ahasenack> it doesn't exist in debian yet, right
[18:33] <ahasenack> I see 0ubuntu
[18:33] <tjaalton> no, probably never will
[18:33] <bdmurray> jbicha: Do you know if libwhoopsie-preferences is used anymore in gnome-control-center?
[18:35] <jbicha> bdmurray: yes, it's used in Privacy > Problem Reporting
[18:36] <jbicha> that's new in 17.10, we used to just use activity-log-manager for that UI
[18:36] <bdmurray> jbicha: okay, but the metrics stuff is not being used right?
[18:37] <jbicha> you mean being able to see old reports sent from your computer? that wasn't implemented in GNOME
[18:39] <bdmurray> jbicha: No I mean in 16.04 there used to be a toggle to "Send occasional system information to Canonical" and I don't see that anymore.
[18:39] <bdmurray> jbicha: Which makes sense because it didn't do anything...
[18:41] <jbicha> oh
[18:42] <jbicha> presumably we need to have a knob for something like that in gnome-control-center to match what we will ask in gnome-initial-setup
[18:42] <jbicha> but I'm not aware of anyone working on that, might not happen for 18.04's release
[18:42] <bdmurray> but that wouldn't use whoopsie correct?
[18:44] <jbicha> um, ubuntu-report I guess (and its included sysmetrics library)
[19:03] <kasper> nacc, thanks for the update! :)
[19:03] <nacc> kasper: yw!
[19:05] <kasper> nacc, would it be available in official bionic repo right away once the decision is made by bionic-proposed folks?
[19:05] <nacc> kasper: right, we're in freeze right now, so it has to be accepted, which it should be as a bugfix
[19:05] <nacc> kasper: but presuming that is the case, it will go in to bionic release. Worst case, bionic-updates
[19:07] <kasper> nacc, hopefully they will recognize the upstream bug and accept it (forgoing the late report)
[19:15] <slangasek> nacc: so I was looking at whether to merge new upstream cryptsetup from Debian; MoM made a hash of it because we had a -0ubuntu1 in Ubuntu for a previous upstream version; so I took a look at using git-ubuntu instead and it leaves me the entire upstream diff to be sifted through as part of the rebase.  Any hints?
[19:16] <nacc> slangasek: looking
[19:16] <slangasek> doesn't seem like it should be a manual thing to piece through which bits of the diff are part of the new upstream tarball and which not
[19:16] <nacc> slangasek: right, we could improve that, in theory
[19:17] <nacc> we don't special-case a new upstream version at all
[19:17] <nacc> so to git-ubuntu, it's just a huge delta added
[19:17] <nacc> (well, to git, via git-ubuntu)
[19:17] <nacc> we would need to do some in-repo tree creation to figure out what is in the orig tarball that is used, etc. but it's doable
[19:18] <slangasek> yeah; if I have to manually reconcile the diff against the upstream tarball, that's basically no different than what I'd already be doing with MoM
[19:18] <nacc> right, it's also ... phrased a bit funny
[19:19] <nacc> it was a merge, but only sort of
[19:19] <nacc> (2:2.0.1-0ubuntu1)
[19:19] <nacc> since there is no merge target there, really
[19:20] <nacc> slangasek: it's certainly a gap, i'd need to think about it a bit to decide what should be done
[19:20] <nacc> now, you *could* do some git-foo locally to help out, i suppose
[19:21] <nacc> slangasek: like save your current state
[19:21] <nacc> go back to the old/debian
[19:21] <nacc> update the orig tarball contents only
[19:21] <nacc> tag that tree/commit
[19:21] <nacc> rebase onto it
[19:22] <nacc> I *believe* git will handle that 'ok', since the tree-wise contents of your 'current state' and the 'orig state' should hash out for all files
[19:23] <nacc> slangasek: but yeah, we're not better than MoM here, you're right; please file a bug
[19:32] <slangasek> nacc: also, if I diff against pkg/upstream/debian/2.0.1.gz it doesn't match, so that's fun
[19:33] <nacc> slangasek: i would diff against pkg/upstream/ubuntu/2.0.1.gz
[19:33] <nacc> slangasek: given that it's an ubuntu upload?
[19:33] <nacc> slangasek: but i'd need to investigate manually to help debug why it doesn't match, if it doesn't
[19:33] <slangasek> nacc: no such tag
[19:33] <slangasek> I looked for that first
[19:33] <nacc> slangasek: hrm
[19:35] <nacc> slangasek: i need to go afk for a bit, but i can try and look in the afternoon
[19:36] <nacc> slangasek: it's possible that, since we import debian first, the debian tarball did end up matching
[19:36] <slangasek> nacc: sure.  anyway, LP: #1761853
[19:37] <nacc> slangasek: thanks
[19:39] <slangasek> nacc: and it looks like the pkg/upstream/debian/2.0.1.gz tag may be missing all the autotools autogenerated files... not sure what to make of that
[19:40] <slangasek> nacc: it's possible that's an indicator the Debian tar.gz did not match the Ubuntu one
[19:41] <nacc> slangasek: right, i'll dig into it
[20:27] <kasper> nacc, does '(Accepted)' mean it is through already: https://lists.ubuntu.com/archives/bionic-changes/2018-April/013233.html ?
[20:34] <nacc> kasper: no, you'll see it in the bug when the fix is through
[20:34] <nacc> kasper: it's currently in bionic-proposed
[20:35] <nacc> slangasek: ok, yeah ther's something wonky with the import, i'm running it manually
[20:36] <nacc> slangasek: the ubuntu upload was 2.0.1.orig.tar.xz
[20:36] <slangasek> ah
[20:36] <nacc> while debian is 2.0.1.orig.tar.gz
[20:36] <nacc> so they definitely wouldn't match
[20:36] <slangasek> right
[20:36] <nacc> but we support that, so i need to reproduce to find out why
[20:36] <slangasek> and indeed the Debian one is generated without any of the autotools bits
[20:36] <nacc> right -- i'll dig intoi the pristine-tar stuff ater my 1x1
[20:38] <nacc> and in fact git ubuntu export-orig notices this and complains and then falls back to pull-lp-source behavior
[20:43] <slangasek> nacc: right, meanwhile I'm uploading a MoM-merged cryptsetup 2.0.2-1ubuntu1, so apologies if this complicates your test case
[20:43] <nacc> slangasek: it's fine, thanks!
[21:24] <nacc> tjaalton: slangasek: pam upload tagged and sponsored [with rich history now]
[21:25] <tjaalton> nacc: thanks!
[21:26] <nacc> tjaalton: ty!
[21:28] <slangasek> sw33t
[21:29] <kasper> nacc, just trying to understand Ubuntu's process during the freeze; is there anything criteria like 'when X number of bionic-proposed testers will say yay', then the fix gets released? Or is there a committee/shiproom that makes the final call?
[21:29] <kasper> s/anything/any
[21:30] <nacc> kasper: bugfixes generally are always allowed in, but when ISOs are being spun, etc, some things are held off (aiui) if they affect the ISO contents
[21:30] <nacc> kasper: we are in a state now, where uploads to seeded things (llvm being one of them) need to be manually accepted
[21:31] <sarnold> -proposed in the devel releases is discouraged for manual testing; autopkgtests migrate packages out of -proposed as they pass tests
[21:31] <nacc> kasper: in this case, it was, so it just needs to migrate https://launchpad.net/ubuntu/+source/llvm-toolchain-6.0
[21:31] <nacc> kasper: err, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#llvm-toolchain-6.0
[21:31] <nacc> which shows we are waiting for some builds to finish
[21:34] <kasper> nacc, great! is this the release build queue?
[21:35] <cjwatson> it's ... just the build queue
[21:35] <nacc> kasper: yeah, not sure what you mean by 'release'?
[21:35] <cjwatson> takes a while to build LLVM, is all
[21:36] <kasper> nacc, the last status on bug page is 'Fix Released', so i thought that's a shared term :)
[21:37] <nacc> kasper: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009 is "Fix Committed"
[21:38] <nacc> kasper: because I have uploaded it and it's in bionic-proposed now ... but it has not been Released yet
[21:38] <kasper> yup, the next one is the last, so my eyes were on that one
[21:39] <nacc> kasper: sorry, I don't parse that, but I think you understand now?
[21:41] <kasper> nacc, totally! the bits you have explained ;)
[21:41] <nacc> kasper: :)
[22:22] <slangasek> nacc: your pam upload was built without -i -I and includes a .git directory; is that intentional?
[23:07] <Unit193> Gah, looks like LP 1754781 got ignored. :/
[23:41] <nacc> slangasek: bah, no it was not
[23:41] <nacc> slangasek: if you can reject, i can reupload, or i can reupload now
[23:42] <slangasek> nacc: please go ahead and reupload and I'll reject the previous upload
[23:42] <nacc> slangasek: thanks
[23:47] <nacc> slangasek: sorry about that, was moving too quick before an errand