[00:03] 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] This bug was never fixed, but was closed anyway. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1737671 [04:50] Launchpad bug 1737671 in linux (Ubuntu) "Blu-ray burner no longer detected" [Medium,Expired] [04:50] Am I the only one in the world in need of a working burner? [04:54] mr_lou: it says expired [04:54] give fresh info and it will reopen, afaik [04:55] I burn DVDs at festivals and such to give away ISOs [04:55] I don't have a blu-ray drive thought [04:55] just a USB one [05:00] valorie, There was another dude replying that he had the problem with his DVD burner too. [05:00] But obviously not many people use burners these days, so replies will be scarce. [05:02] valorie, What burner app do you use? [05:02] 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] I use k3b [05:04] a bit old, but it still works [05:04] no clue if it will do blu-ray [05:05] I won't. [05:05] Ubuntu doesn't have UDF 2.5 [05:06] *It won't [05:07] k3b does seem to detect the drive. But doesn't give me Blu-ray options of course. [05:07] But I find it odd that kernel 97 lets ImgBurn detect the burner, and all following kernels doesn't. [05:08] 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] Added more info. Still expired though. [05:25] you might mention the bug number [05:26] perhaps you will catch the interest of a devel who can fix it [05:26] of course what is really wanted is a thorough analysis and a patch [05:35] Gotta go to work. [05:35] L8r === JanC_ is now known as JanC [09:01] 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] 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:08] bug 1756547 in Ubuntu Translations "LP refuses to import plural strings where e.g. msgstr[0] entries in PO file miss %d" [High,In progress] https://launchpad.net/bugs/1756547 [10:09] GunnarHj: Not this month unless there's no reasonable workaround. I thought we'd discussed removing the JS declaration? [10:09] We can upgrade gettext if we really can't drop the JS declaration, but that's a lot easier. [10:09] oh well... I just dput ayatana-indicator-power without option from a bionic chroot to $UBUNTU [10:09] and I wanted to dput it to my personal PPA instead... [10:10] wgrant: Yes, we discussed that as a plan B. Seb and I hoped for plan A. :) [10:10] in case anyone sees the upload, it should be REJECTed. [10:11] 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] 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] sunweaver: It wasn't signed, so was summarily rejected :) [10:13] 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] 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] wgrant: One way might be to try the workaround for one package to confirm that it works. As a base for decision. [10:21] 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] 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] Much lower risk for regression. [10:24] The gettext diff between xenial and bionic is one hundred and fifty thousand lines [10:25] wgrant: But it used at runtime... [10:28] wgrant: But let's try out the workaround, and try to figure out which packages are most affected. [10:31] 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] packages affected then I can dig in more depth. [10:34] GunnarHj, it should be possible to override_dh_translations in debian/rules and sed away the javascript comments from the pot [10:34] unsure how wrong that is though if the code is javascript [10:34] and if that can create other issues [10:36] It's easy enough to validate a POT against xenial's gettext (hi LXD) [10:37] It's the first time I've run into the JS attribute, but I suppose their may be others. [10:38] wgrant: thanks [10:38] wgrant, right, validating is one think, knowing that the result is the one expect is another [10:38] I've no clue what it change to have that format clue or not [10:38] I've never seen that cause trouble before, but it's possible. [10:42] GunnarHj, well seems that safer approach would be probably at this point to sed those away from the debian/rules [10:42] as it trying to do that and see what's the result [10:55] seb128: Ok. I'll fix a gnome-shell patch later today or Monday to start with. [12:55] I see a weird test suite failure with apt in docker's ubuntu:bionic [12:56] We create a temporary package with a changelog, and isntall it [12:56] (in a different, temporary, rootdir) [12:57] but there's no changelog in ithe installed package apparently [12:57] on my own bionic system it works just fine [12:57] for example, https://travis-ci.org/julian-klode/apt/jobs/363080996 [12:57] (APT falls back to HTTP, and thus fails the test) [13:00] I just thought that maybe the docker image ships a dpkg.cfg.d snippet that disables changelog installing? [13:00] I'm not sure if APT's test suite protects against dpkg.cfg files [13:02] let's check, I guess. [13:02] * juliank installs docker ... :( [13:08] found /etc/dpkg/dpkg.cfg.d/excludes === grumble is now known as Guest46633 === grumblr is now known as grumble === mdeslaur_ is now known as mdeslaur [18:16] ahasenack: halp. I need sssd 1.16.1 for freeipa :P [18:17] because of a bug fix? [18:18] no, 4.7-pre1 needs it, and that's needed for sqlite nssdb support et al :/ [18:19] but, 1.16.1 really is worth it [18:20] it's been on debian testing for some weeks, it works [18:20] I'm not against it. It feels like you have more reasons for an FFe than I do [18:21] you are a core dev, much easier for you to do it than I :) [18:21] brb [18:21] sure [18:28] back [18:30] tjaalton: you still prefer the newer freeipa version as opposed to revert the previous one, which didn't need nssdb? [18:30] er, nss-pem [18:31] we have nss-pem, and would need to go to 4.5 [18:32] even 4.6 doesn't work with current dogtag & certmonger which are needed to support sqlite nssdb's etc [18:32] where is nss-pem? I don't see it in bionic [18:32] libnsspem [18:32] I see, new in bionic [18:32] you got that in recently? [18:32] yes [18:33] it doesn't exist in debian yet, right [18:33] I see 0ubuntu [18:33] no, probably never will [18:33] jbicha: Do you know if libwhoopsie-preferences is used anymore in gnome-control-center? [18:35] bdmurray: yes, it's used in Privacy > Problem Reporting [18:36] that's new in 17.10, we used to just use activity-log-manager for that UI [18:36] jbicha: okay, but the metrics stuff is not being used right? [18:37] you mean being able to see old reports sent from your computer? that wasn't implemented in GNOME [18:39] 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] jbicha: Which makes sense because it didn't do anything... [18:41] oh [18:42] 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] but I'm not aware of anyone working on that, might not happen for 18.04's release [18:42] but that wouldn't use whoopsie correct? [18:44] um, ubuntu-report I guess (and its included sysmetrics library) [19:03] nacc, thanks for the update! :) [19:03] kasper: yw! [19:05] nacc, would it be available in official bionic repo right away once the decision is made by bionic-proposed folks? [19:05] kasper: right, we're in freeze right now, so it has to be accepted, which it should be as a bugfix [19:05] kasper: but presuming that is the case, it will go in to bionic release. Worst case, bionic-updates [19:07] nacc, hopefully they will recognize the upstream bug and accept it (forgoing the late report) [19:15] 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] slangasek: looking [19:16] 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] slangasek: right, we could improve that, in theory [19:17] we don't special-case a new upstream version at all [19:17] so to git-ubuntu, it's just a huge delta added [19:17] (well, to git, via git-ubuntu) [19:17] 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] 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] right, it's also ... phrased a bit funny [19:19] it was a merge, but only sort of [19:19] (2:2.0.1-0ubuntu1) [19:19] since there is no merge target there, really [19:20] slangasek: it's certainly a gap, i'd need to think about it a bit to decide what should be done [19:20] now, you *could* do some git-foo locally to help out, i suppose [19:21] slangasek: like save your current state [19:21] go back to the old/debian [19:21] update the orig tarball contents only [19:21] tag that tree/commit [19:21] rebase onto it [19:22] 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] slangasek: but yeah, we're not better than MoM here, you're right; please file a bug [19:32] nacc: also, if I diff against pkg/upstream/debian/2.0.1.gz it doesn't match, so that's fun [19:33] slangasek: i would diff against pkg/upstream/ubuntu/2.0.1.gz [19:33] slangasek: given that it's an ubuntu upload? [19:33] slangasek: but i'd need to investigate manually to help debug why it doesn't match, if it doesn't [19:33] nacc: no such tag [19:33] I looked for that first [19:33] slangasek: hrm [19:35] slangasek: i need to go afk for a bit, but i can try and look in the afternoon [19:36] slangasek: it's possible that, since we import debian first, the debian tarball did end up matching [19:36] nacc: sure. anyway, LP: #1761853 [19:36] Launchpad bug 1761853 in usd-importer "merge of a -0ubuntu1 vs new upstream in Debian requires manual resolution of upstream diff" [Undecided,New] https://launchpad.net/bugs/1761853 [19:37] slangasek: thanks [19:39] 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] nacc: it's possible that's an indicator the Debian tar.gz did not match the Ubuntu one [19:41] slangasek: right, i'll dig into it [20:27] nacc, does '(Accepted)' mean it is through already: https://lists.ubuntu.com/archives/bionic-changes/2018-April/013233.html ? [20:34] kasper: no, you'll see it in the bug when the fix is through [20:34] kasper: it's currently in bionic-proposed [20:35] slangasek: ok, yeah ther's something wonky with the import, i'm running it manually [20:36] slangasek: the ubuntu upload was 2.0.1.orig.tar.xz [20:36] ah [20:36] while debian is 2.0.1.orig.tar.gz [20:36] so they definitely wouldn't match [20:36] right [20:36] but we support that, so i need to reproduce to find out why [20:36] and indeed the Debian one is generated without any of the autotools bits [20:36] right -- i'll dig intoi the pristine-tar stuff ater my 1x1 [20:38] and in fact git ubuntu export-orig notices this and complains and then falls back to pull-lp-source behavior [20:43] nacc: right, meanwhile I'm uploading a MoM-merged cryptsetup 2.0.2-1ubuntu1, so apologies if this complicates your test case [20:43] slangasek: it's fine, thanks! === maxb_ is now known as maxb [21:24] tjaalton: slangasek: pam upload tagged and sponsored [with rich history now] [21:25] nacc: thanks! [21:26] tjaalton: ty! [21:28] sw33t [21:29] 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] s/anything/any [21:30] 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] kasper: we are in a state now, where uploads to seeded things (llvm being one of them) need to be manually accepted [21:31] -proposed in the devel releases is discouraged for manual testing; autopkgtests migrate packages out of -proposed as they pass tests [21:31] kasper: in this case, it was, so it just needs to migrate https://launchpad.net/ubuntu/+source/llvm-toolchain-6.0 [21:31] kasper: err, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#llvm-toolchain-6.0 [21:31] which shows we are waiting for some builds to finish [21:34] nacc, great! is this the release build queue? [21:35] it's ... just the build queue [21:35] kasper: yeah, not sure what you mean by 'release'? [21:35] takes a while to build LLVM, is all [21:36] nacc, the last status on bug page is 'Fix Released', so i thought that's a shared term :) [21:37] kasper: https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-6.0/+bug/1761009 is "Fix Committed" [21:37] Launchpad bug 1761009 in llvm-toolchain-6.0 (Ubuntu) "LLDB.h is missing from liblldb-6.0-dev package" [Undecided,Fix committed] [21:38] kasper: because I have uploaded it and it's in bionic-proposed now ... but it has not been Released yet [21:38] yup, the next one is the last, so my eyes were on that one [21:39] kasper: sorry, I don't parse that, but I think you understand now? [21:41] nacc, totally! the bits you have explained ;) [21:41] kasper: :) [22:22] nacc: your pam upload was built without -i -I and includes a .git directory; is that intentional? [23:07] Gah, looks like LP 1754781 got ignored. :/ [23:07] Launchpad bug 1754781 in irssi (Ubuntu) "Please merge the latest bug release, 1.0.7-1, from Debian" [Undecided,New] https://launchpad.net/bugs/1754781 [23:41] slangasek: bah, no it was not [23:41] slangasek: if you can reject, i can reupload, or i can reupload now [23:42] nacc: please go ahead and reupload and I'll reject the previous upload [23:42] slangasek: thanks [23:47] slangasek: sorry about that, was moving too quick before an errand