=== maclin1 is now known as maclin
=== crogers_ is now known as crogers
[10:58] <joelkraehemann> hi all
[10:59] <joelkraehemann> how is the bionic beaver release?
[11:01] <joelkraehemann> I just ask since there is a new release of GSequencer in unstable:
[11:01] <joelkraehemann> https://tracker.debian.org/pkg/gsequencer
[11:01] <joelkraehemann> https://launchpad.net/ubuntu/+source/gsequencer
[11:02] <rbasak> joelkraehemann: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gsequencer shows problems getting 1.4 into Bionic.
[11:02] <joelkraehemann> with the new release the integration tests pass, again
[11:02] <joelkraehemann> https://ci.debian.net/packages/g/gsequencer/unstable/amd64/
[11:03] <joelkraehemann> rbasak: there was a broken test
[11:03] <joelkraehemann> ags_functional_audio_test.c
[11:04] <joelkraehemann> Please consider to sync.
[11:04] <rbasak> joelkraehemann: is there an upstream changelog describing the changes from 1.4.19 to 1.4.24 please?
[11:05] <joelkraehemann> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ChangeLog?h=1.4.x
[11:05] <joelkraehemann> fixed ags_functional_audio_test.c to create notation as needed
[11:06] <joelkraehemann> ^^ this was actually the solution ags (1.4.20)
[11:06] <rbasak> Are there any feature changes?
[11:06] <joelkraehemann> since 1.4.19?
[11:06] <rbasak> Yep
[11:07] <joelkraehemann> work-around reverted pulseaudio GMainLoop integration
[11:07] <joelkraehemann> ^^ this is important
[11:07] <rbasak> "defaulted disable OSS4"
[11:07] <joelkraehemann> else the application crashes as doing Pulseaudio
[11:08] <joelkraehemann> improved ags_lv2_manager.c to be faster
[11:08] <joelkraehemann> ^^ this is a nice improvement
[11:09] <rbasak> joelkraehemann: could you perhaps follow https://wiki.ubuntu.com/SyncRequestProcess to document all of this please? It feels a little more complicated than a quick IRC confirmation.
[11:09] <joelkraehemann> Yes, for sure :)
[11:09] <rbasak> Please describe the changes in your request, and for the ones that sound like feature changes, please explain why they aren't, or request a freeze exception if they are.
[11:10] <rbasak> joelkraehemann: thanks! If the conclusion is that there aren't feature changes, and the changelog and upstream commits appear to match this, then I'll be happy to sponsor a sync for you.
[11:10] <rbasak> If they contain feature changes then we need a release team approval first.
[11:11] <joelkraehemann> only for Apple OS X there is a new feature CoreMIDI support
[11:11] <joelkraehemann> but this won't affect GNU+Linux
[11:11] <rbasak> Just point out in the request why it won't affect Ubuntu and that's fine.
[11:13] <rbasak> Once you've documented the sync request in a bug, feel free to continue pinging here for attention if it's needed.
[11:13] <rbasak> (as in: please don't assume it'll get attention automatically)
[11:20] <joelkraehemann> seb128: I just recognized you was asking for GSequencer update
[11:26] <seb128> joelkraehemann, hey, did I? I think I asked if somebody was looking at the autopkgtest issues for it
[11:27] <joelkraehemann_> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1759549
[11:27] <ubottu> Launchpad bug 1759549 in gsequencer (Ubuntu) "Sync gsequencer 1.4.24-1 (universe) from Debian unstable (main)" [Undecided,New]
[11:28] <joelkraehemann> seb128: autopkgtest told about regression due to a broken integration test
[11:28] <joelkraehemann> seb128: this is fixed, now
[11:28] <seb128> joelkraehemann, ah, good, thanks
[11:30] <joelkraehemann> here is the prove https://ci.debian.net/packages/g/gsequencer/unstable/amd64/
[11:32] <seb128> joelkraehemann, synced, let's see :)
[11:34] <joelkraehemann> you are awesome
[11:35] <seb128> :)
[11:35] <seb128> I just did the sync, not the actual work, but thx :)
[11:35] <coreycb> rbasak: hi, any chance we could fast-track the xenial/artful fixes for bug 1758411 to -updates? it fixes a bad regression.
[11:35] <ubottu> bug 1758411 in neutron (Ubuntu Artful) "[SRU] Revert fix for bug 1752838 regression" [Critical,Fix committed] https://launchpad.net/bugs/1758411
[11:44] <rbasak> coreycb: looking
[11:45] <coreycb> rbasak: thanks, we also have a stable point release of neutron in the artful upload
[11:48] <rbasak> coreycb: "There should be none as long as the code is reverted to what it was before the SRU for 1752838" -- isn't that statement wrong then?
[11:49] <coreycb> rbasak: the fix reverts all the code from another SRU that caused the regression
[11:49] <rbasak> Right, and that part is fine to consider for a fast track.
[11:49] <GunnarHj> seb128, cjwatson: Two especially disturbing translation bugs:
[11:49] <coreycb> rbasak: so there should be no regression potential, at least that's what i was trying to say
[11:49] <GunnarHj> Bug #1758684 because snapd is a 'hot' package which also affects other distros, and we are upstream.
[11:49] <ubottu> bug 1758684 in snapd (Ubuntu) "LP only imported a fraction of the snappy translation template" [High,Confirmed] https://launchpad.net/bugs/1758684
[11:49] <GunnarHj> Bug #1756547 because it probably affects quite a few packages and prevents strings with plural options (for certain languages) to show up as translated for Ubuntu users.
[11:49] <ubottu> bug 1756547 in gnome-shell (Ubuntu) "LP does not understand msgstr[2] entries in PO files" [Undecided,New] https://launchpad.net/bugs/1756547
[11:49] <rbasak> coreycb: but I think that choosing to bundle further updates disqualifies it from that.
[11:50] <seb128> GunnarHj, thanks for raising this up
[11:51] <coreycb> rbasak: think we could at least get xenial released? i'm not too concerned about artful.
[11:51] <rbasak> coreycb: I think that should be OK. Still looking.
[11:58] <arges> rbasak: hey looking at some srus this morning
[11:58] <rbasak> arges: OK. I'm just looking at neutron for coreycb as above. I've not looked at anything else yet.
[11:59] <arges> ok i'm just looking at the top of xenial atm
[11:59]  * coreycb waves to arges
[11:59] <arges> coreycb: hi : )
[11:59] <coreycb> arges: howdy :)
[12:01] <joelkraehemann_> The tests are running now on my system and as expected:
[12:01] <joelkraehemann_> PASS: ags_functional_audio_test
[12:04] <joelkraehemann_> Just noticed https://launchpad.net/ubuntu/bionic/+source/gsequencer
[12:04] <joelkraehemann_> Thank you all
[12:04] <cjwatson> GunnarHj: Ack, but chances of me having time to look before Easter are slim
[12:05] <joelkraehemann> Where can I see your test results?
[12:06] <GunnarHj> cjwatson: I understand if the msgstr[2] thing may be tricky, but it would be great if you could check why on earth snappy.pot does not get fully imported.
[12:07] <joelkraehemann_> https://autopkgtest.ubuntu.com/packages/gsequencer/bionic/amd64
[12:08] <joelkraehemann_> seb128: are the tests running anywhere?
[12:09] <rbasak> coreycb: done
[12:09] <coreycb> rbasak: thanks!
[12:09] <seb128> joelkraehemann, they are going to be once the binaries are published/picked up
[12:10] <seb128> joelkraehemann, you can keep an eye on e.g http://autopkgtest.ubuntu.com/packages/g/gsequencer/bionic/amd64
[12:10] <joelkraehemann> great!
[12:11] <cjwatson> GunnarHj: Chances of me having time to look before Easter are still slim.  I have another urgent project
[12:11] <cjwatson> I'm not saying I won't look after Easter, just setting expectations
[12:12] <GunnarHj> cjwatson: I see. Just wanted to call attention to those two. Btw, is there anybody else who could look at the snappy thing?
[12:13] <GunnarHj> wgrant: ^ ?
[12:21] <wgrant> GunnarHj: The latter doesn't look like a bug to me. The msgid includes a %d, the msgstr[0] doesn't include the %d.
[12:22] <wgrant> GunnarHj: So the msgstr[0] is invalid; it's nothing to do with msgstr[2].
[12:22] <wgrant> msgid "%d minute ago"
[12:22] <wgrant> msgid_plural "%d minutes ago"
[12:22] <wgrant> msgstr[0] "před minutou"
[12:22] <wgrant> msgstr[1] "před %d minutami"
[12:22] <wgrant> msgstr[2] "před %d minutami"
[12:24] <GunnarHj> wgrant: Some languages has separate form for 2, i.e. they don't have just singular or plural. I have been told that such options are common in many GNOME translation files.
[12:24] <GunnarHj> wgrant: So probably gettext understand, but LP does not.
[12:26] <GunnarHj> wgrant: Ah, now I see what you mean. Wondering if the missing %d is a common denominator. Need to recheck.
[12:27] <wgrant> GunnarHj: That's why there's three forms rather than two
[12:27] <wgrant> GunnarHj: The missing %d is absolutely the bug in the upstream translation.
[12:27] <wgrant> It's nothing to do with plural forms at all; the singular translation is just buggy.
[12:29] <wgrant> (LP supports up to nplurals=6, eg. Arabic)
[12:31] <GunnarHj> wgrant: Thanks for the lesson. Then there are plenty of buggy translations out there. :( I'll follow up on the bug report.
[12:32] <wgrant> GunnarHj: Do you know how many packages this has hit?
[12:32] <wgrant> GNOME stuff used to be reasonably well behaved.
[12:32] <GunnarHj> wgrant: No. But apparently damned lies accepts it.
[12:36] <seb128> GunnarHj, wgrant, are you sure it's illegal? https://www.gnu.org/software/gettext/manual/html_node/Translating-plural-forms.html#Translating-plural-forms states that
[12:36] <seb128> "Can you do this in your translation as well?
[12:36] <seb128> msgstr[0] "jednom datotekom je uklonjen"
[12:36] <seb128> Well, it depends on whether msgstr[0] applies only to the number 1, or to other numbers as well. If, according to the plural formula, msgstr[0] applies only to n == 1, then you can use the specialized translation without the number placeholder."
[12:36] <seb128> also msgfmt -c doesn't complain about the po attached to the bug
[12:38] <seb128> cz uses nplurals=3; plural=(n==1) ? 0 : (n>=2 && n<=4) ? 1 : 2; it seems
[12:39] <jbicha> for languages with a separate plural form for 2, it's often unnecessary (and even wrong) to explicitly use the numeral 2 in the phrase
[12:39] <GunnarHj> seb128, wgrant: I'll await with closing the bug report. ;)
[12:41] <seb128> jbicha, do you have a reference to that, the gettext page I was mentioning doesn't include that case
[12:41] <jbicha> um, I know some Arabic which has a separate form for 2
[12:42] <seb128> well I guess the principle is the same, if the form applies to a specific/unique number then include the %d doesn't make sense
[12:42] <jbicha> the word itself already tells you there is 2 of the item
[12:43] <seb128> wgrant, ^ how does launchpad verify the validity? it uses msgfmt or equivalent or has its own implementation?
[12:43] <jbicha> but I guess it depends on context a bit too
[12:43] <wgrant> seb128: It uses gettext
[12:44] <wgrant> I wonder if there's some flag on the message that makes it more pedantic.
[12:45] <seb128> wgrant, the gettext command? it has a "validate" mode?
[12:45] <wgrant> seb128: It's a Python binding to gettext
[12:46] <seb128> ah
[12:46] <seb128> maybe it's a bug in the binding then
[12:46] <GunnarHj> wgrant: Ouch. Python isn't reliable wrt l10n matters. ;)
[12:47] <wgrant> Hmm
[12:47] <wgrant> It's javascript-format, I wonder if that's extra pedantic in some gettext
[12:48] <wgrant> The bindings are very thin, there can't really be this sort of bug in them.
[12:58] <wgrant> GunnarHj, seb128: It's a difference between xenial and bionic gettext
[12:58] <wgrant> GunnarHj, seb128: javascript-format in xenial requires an exact match
[12:58] <wgrant> I wonder which is right.
[12:59] <seb128> wgrant, well, the gettext upstream documentation I pointed earlier made it clear it's optional
[12:59] <seb128> "If, according to the plural formula, msgstr[0] applies only to n == 1, then you can use the specialized translation without the number placeholder.""
[12:59] <wgrant> seb128: It probably depends on the syntax mode selected.
[13:02] <GunnarHj> wgrant, seb128: Maybe gettext has adapted to better fit the grammar rules of certain languages.
[13:03] <wgrant> So we should probably establish whether javascript-format is meant to be pedantic or not, and probably fix xenial's gettext or give LP a patched one.
[13:05] <GunnarHj> wgrant: In regular strings it's probably motivated to be pedantic wrt number of %s etc.
[13:06] <GunnarHj> Or isn't it possible to distinguish between regular strings and plural form strings?
[13:06] <seb128> wgrant, why do we use javascript mode?
[13:07] <wgrant> seb128: We don't. The .pot does.
[13:07] <seb128> ah, ok
[13:07] <wgrant> You can repro the issue with xenial's msgfmt -c
[13:07] <seb128> tha's what I tried, it doesn't complain
[13:07] <wgrant> Just stick "#, javascript-format" before the problematic message to match the .pot
[13:07] <wgrant> What exactly did you try?
[13:07] <seb128> ah
[13:07] <seb128>  msgfmt -v -c gnome-shell.po
[13:07] <seb128> 423 messages traduits.
[13:07] <seb128> I tried
[13:08] <seb128> k, that does it indeed
[13:09] <seb128> wgrant, so one workaround would be to remove the javascript-format from the pot?
[13:09] <seb128> in gnome-shell
[13:09] <wgrant> Yep, that would be an easy workaround.
[13:09] <seb128> GunnarHj, ^
[13:10] <GunnarHj> seb128: Yeah, I saw.
[13:10] <seb128> wgrant, how do we go about figuring out if gettext handling of javascript mode is buggy in xenial or bionic?
[13:10] <wgrant> seb128: I have no idea.
[13:11] <wgrant> I'm not a translator, I just play one on Launchpad :)
[13:13] <GunnarHj> seb128: OTOH, the .pot is not the problem. All the .po files are.
[13:13] <seb128> GunnarHj, the .po don't have that javascript format hint
[13:13] <seb128> the pot has
[13:14] <GunnarHj> seb128: But it's the .po files which are (partially) rejected by LP.
[13:14] <GunnarHj> Or can that be because of that comment in the .pot?
[13:15] <seb128> GunnarHj, wgrant said that launchpad does the validation in javascript format because that's what the pot tell it to do
[13:15] <wgrant> The POs are validated against the POT
[13:16] <GunnarHj> seb128, wgrant: I see.
[13:17] <GunnarHj> So I suppose we are talking about modifying the .pot during package build. Worth a try for now, I suppose.
[13:18] <GunnarHj> seb128: Or should we let dh_translations do it? :)
[13:18] <GunnarHj> (forget the latest remark. This is meson, I suppose.)
[13:18] <seb128> GunnarHj, well I don't think dh_translations can do that
[13:18] <cjwatson> Looks like this changed in gettext 9b9ebf8f96dd3b142e4202ca4a60feac9db0820e
[13:19] <seb128> ah, cjwatson is better than me at it
[13:19] <seb128> I was building gettext to bisect
[13:19] <seb128> thanks cjwatson
[13:19] <cjwatson> https://git.savannah.gnu.org/cgit/gettext.git/commit/?id=9b9ebf8f96dd3b142e4202ca4a60feac9db0820e
[13:20] <cjwatson> (I'm guessing slightly, but it removes the offending error message at least ...
[13:20] <cjwatson> )
[13:21] <cjwatson> seb128: I just searched the git log for "javascript" and looked at the first few matching commit s:)
[13:22] <seb128> cjwatson, I did that as well for "plural" and "javascript" but the title for that commit didn't make me look at the diff
[13:22] <cjwatson> Giving LP a gettext backport mightn't be totally silly, since they're adding support for new features
[13:23] <cjwatson> I'm slightly surprised we haven't had to do so in my memory, but I guess gettext is pretty slow-moving
[13:23] <seb128> cjwatson, wgrant, what do you recommend us doing for gnome-shell meanwhile? hack the .pot to remove the javascript format? or do you think that launchpad can be changed/fixed in the next week or so?
[13:26] <cjwatson> If people agree that a gettext backport is the right response then we could probably do that next week or so
[13:26] <seb128> where people is you and wgrant? ;)
[13:27] <wgrant> That might be reasonable.
[13:27] <cjwatson> I guess, though opinions welcome since I've spent all of five minutes looking at this and mooching off wgrant's analysis :)
[13:28] <seb128> well, I think it would make sense to base launchpad on recent gettext, as you said some new features/changes are being added that upstreams are taking advantage off
[13:36] <joelkraehemann> Hi all
[13:36] <joelkraehemann> do you provide an ISO installer image for s390x?
[13:38] <TJ-> joelkraehemann: see http://cdimage.ubuntu.com/releases/16.04.4/release/   ubuntu-16.04.4-server-s390x.iso
[13:39] <joelkraehemann> TJ-: thank you
[13:40] <xnox> joelkraehemann, yes.
[13:41] <xnox> joelkraehemann, we also have smaller d-i installer too (which fetches all packages from the network archive), possibly nicer for ftp-loads / zvm uploads.
[13:41] <xnox> joelkraehemann, http://ports.ubuntu.com/dists/xenial-updates/main/installer-s390x/current/images/ both in GA kernel; and rolling hwe kernel variants.
[13:42] <xnox> joelkraehemann, note there is #ubuntu-s390x too, if you have more s390x specific questions =)
[13:43] <TJ-> which reminds me ... do we have any ISO installers for 32-bit EFI systems (so the ISO has /EFI/BOOT/GRUBIA32.EFI ) ?
[13:43] <TJ-> we've been getting a lot of users wiht Intel Atom based deviecs with 32-bit EFI that suffer due to the installer not being seen/bootable
[13:46] <xnox> TJ-, all Intel Atom devices use 64 UEFI, since a long time ago.
[13:46] <xnox> TJ-, even the minnow boards.
[13:47] <xnox> TJ-, and the answer is no, we do not ship 32bit uefi images.
[13:48] <xnox> TJ-, you are hearing a small vocal minority. And if they have such devices, that you should use the amd64 mini.iso and discover that it just works; or e.g. upgrade their firmware - minnow board provides eufi firmware of both arches for download.
[13:52] <TJ-> xnox: We're seeing this especially for Acer tablet/2-in-1 devices, and we've had some HP and Lenovo in the last 3 months as well.
[13:52] <cjwatson> bionic gettext builds on xenial with a couple of Build-Depends tweaks, at least.
[13:52] <cjwatson> Should probably run the LP translations tests against it.
[13:52] <xnox> TJ-, but Intel stopped supporting that.... Do you have exact model numbers?
[13:52] <seb128> it builds, ship it!
[13:52] <seb128> :)
[13:53] <wgrant> Heaps of Bay Trail devices have 32-bit only UEFI
[13:53] <wgrant> Not all, but a lot.
[13:53] <xnox> TJ-, and you mean that said hardware was released "in the last 3 months"?
[13:54] <xnox> wgrant, but bay trail is very very very old it's like 2013/2014? i think it was the last ones still in the pipeline, when everybody agreed that 32bit uefi is silly with a 64bit cpu
[13:54] <xnox> even if userspace/kernel will be 32bit
[13:54] <TJ-> xnox: No, I mean user's come to #ubuntu unable to install on these systems. We have to spend a lot of time to diagnose the cause, but the user's have the opnion "Ubuntu won't work with my PC"
[13:55] <xnox> TJ-, buy Ubuntu preinstalled from Dell? stop taking old weird things (e.g. tablets) and try to install ubuntu on them =)
[13:55] <xnox> TJ-, we killed the Touch/Tablet project ;-)
[13:56] <xnox> TJ-, what I am saying no new hardware is shipped like that, and the hardware that was shipped is niche, and yes there will be random people who try to use ubuntu on those devices.
[13:57] <xnox> TJ-, but there really was no market demand to support 32bit uefi, on ubuntu, ever. it is not something that was ever big, or growing... it's shrinking.
[14:00] <TJ-> xnox: OK, so we can just tell them Ubuntu won't install
[14:10] <coreycb> doko: in adding the .symbols file requested for the liblasso3 MIR, i'm adding it with versions back to precise only. does that make sense?
[14:10] <coreycb> doko: first time adding a symbols file
[14:13] <jbicha> coreycb: I don't even bother going back in time when making a new symbols file
[14:14] <coreycb> jbicha: ah, ok i was wondering about that. probably doesn't hurt though if i've done that a bit already.
[14:14] <coreycb> jbicha: thanks
[14:14] <jbicha> yeah it won't hurt, but maybe less work next time :)
[14:14] <coreycb> jbicha: yep! :)
[14:15] <jbicha> here's a recent one I added: https://salsa.debian.org/utopia-team/volume-key/commit/8545cd24
[14:21] <xnox> TJ-, it can be done, but it's for people who know how to boot & install without using d-i.
[14:22] <xnox> TJ-, e.g. one can manually prepare grub, manually prepare kernel image and initrd, boot that, and use debootstrap and manually configure /etc/fstab, bootloader, reboot....
[14:24] <TJ-> xnox: right, which is why I asked since it takes a lot to talk people through it, or to direct them to sensible, clear instructions. It only boils down to installing grub-efi-ia32 into ISO EFI-SP and having the package install at end of install
[14:25] <coreycb> doko: i've made the requested updates for bug 1610286 and switch it back to New
[14:25] <ubottu> bug 1610286 in libapache2-mod-auth-mellon (Ubuntu) "[MIR] libapache2-mod-auth-mellon, liblasso3" [Medium,Triaged] https://launchpad.net/bugs/1610286
[14:26] <xnox> TJ-, but people who need such guidance, should probably be told "yeah, it's hard, don't do it"
[14:27] <TJ-> xnox: they end up using other people's respins of the ISOs that have had grub-efi-ia32 added
[14:28] <TJ-> xnox: trouble is it takes some digging when a user reports 'ubuntu installer won't work' to figure out the cause.. mostly it's they used some weird method to prepare the USB device (like copying the ISO as a file rather than writing it as a device!) - ends up creating quite a lot of support effort before we get to the point of identifying 32-bit UEFI is the issue
[14:30] <TJ-> especially as many recent systems have locked-down firmware (Insyde H2O and others) across recent Acer, HP, and Lenovo models, where the installer doesn't show up as a boot option because in those you have to go into FW Setup> Security > and specifically /trust/ the EFI boot loader file by using a file-browser
[14:30] <xnox> we do not have 32bit shim; and we do not have secureboot 32bit; hence yeah, one will not boot.
[14:30] <xnox> 64bit is secureboot
[14:31] <xnox> Ubuntu was first to ship secureboot stable release; even ahead of Windows itself.
[14:31] <xnox> TJ-, it's simple really.... if installer doesn't boot, we don't support it =)
[14:32] <xnox> can you boot 64bit image - no? what about 32bit image - no? tried legacy boot settings ? still no.... yeah, we don't support that.
[14:32] <TJ-> right, but even amd64 fails to boot the installer on the systems I just mentioned because the firmware doesn't 'trust' any boot-loader path that isn't Windows specific
[14:36] <TJ-> it's not as simple as 'does it boot?' in many cases because we first have to verify the user actually wrote the ISO to the installer device correctly. These wider issues I'm mentioning is because they consume a lot of support time and create a lot of frustration. A new LTS is generally the time the support channel gets inundated with this kind of problem.
[14:45] <xnox> TJ-, you should start documenting model numbers, devices, and their release dates.
[14:46] <xnox> like we did for non-PAE i386 to discover devices that lie, and we made quirks for them.
[14:52] <TJ-> xnox: will do; it's got to the point where I cringe when these issues come along... they're easy to solve in-front of the PC but painful when trying to talk someone through even the diagnostic steps - especially when they're reliant on Windows at the pre-install point
[14:52] <xnox> TJ-, ability to discover what the UEFI is from windows, would be nice.
[14:53] <TJ-> xnox: yeah... I've not touched Windows since 2005 so out of the loop on that aspect :)
[15:05] <seb128> joelkraehemann, http://autopkgtest.ubuntu.com/packages/g/gsequencer/bionic/amd64 ... it worked :)
[15:18] <joelkraehemann> great!
[15:19] <joelkraehemann> but it fails for s390x
[15:19] <joelkraehemann> Currently I try to setup a VM using qemu
[15:21] <joelkraehemann> but I don't get a screen
[16:09] <seb128> joelkraehemann, that's an improvement still :) do you need a screen to debug the autopkgtest?
[16:10] <seb128> bdmurray, hey, did you see the ubuntu-devel@ discussion about apport warning vs error? seems the consensus is that stopping reporting warnings was the wrong fix, what do you think about reverting? the change currently impact negatively our capacity to understand reports at a time in the cycle where we need those details ...
[16:10] <seb128> bdmurray, if you are unsure maybe we can enable them at least for beta and rediscuss what to do before bionic turns stable?
[16:13] <bdmurray> seb128: I didn't feel like a consensus was reached. One idea I had was making reports w/ journal warnings private but given how JournalErrors are added that'd be every report. If we were to do that could we limit which packages collect the journal warnings?
[17:02] <ahasenack> hi, anybody working on https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1754936 ? It's stuck in excuses due to a test failure
[17:02] <ubottu> Launchpad bug 1754936 in freeipa (Ubuntu) "freeipa cleint missing" [Undecided,Confirmed]
[17:02] <ahasenack> if not, I can take a look
[17:02] <ahasenack> (bug is unassigned)
[17:07] <nacc> ahasenack: i saw someone mention it just now on the ML, I believe no one has looked explicitly, but tjaalton may know
[17:07] <ahasenack> nacc: could you import it into git please?
[17:07] <ahasenack> freeipa-client
[17:07] <ahasenack> actually
[17:07] <ahasenack> let me check if it's just not a binary from the same source
[17:08] <ahasenack> it is, n/m
[17:08] <ahasenack> the whole thing is gone, not just the client
[17:10] <nacc> ahasenack: starting import
[17:11] <seb128> bdmurray, I don't think limiting makes sense, warnings often give useful clues and we lost them
[17:12] <doko> coreycb: it only makes sense in the development series where new upstream versions appear. it doesn't hurt for older releases
[17:13] <seb128> bdmurray, what would help you to feel like we have a consensus? do we need the input for more people, like maybe ask slangasek what he thinks?
[17:13] <slangasek> seb128: I punted to bdmurray ;)
[17:13] <seb128> shrug
[17:13] <seb128> seems we are stucked then :/
[17:14] <coreycb> doko: ok
[17:14] <seb128> slangasek, maybe I put it on the TB agenda then, but I feel like it's going to be too slow of a process to hit bionic
[17:14] <bdmurray> seb128: I'll look at the emails again today and send a reply.
[17:14] <seb128> thanks
[17:14] <seb128> or at least we are going to miss beta
[17:15] <seb128> which is a shame because that's when we need the info the most to be able to address bugs
[17:15] <bdmurray> okay, I could add it back for now while the discussion continues
[17:16] <seb128> that would be great, if that are concerns about specific log output we should fix those apps
[17:16] <seb128> I'm going to have a look to see where the one that triggered the bug is coming from and make sure it's fixed
[17:18] <nacc> ahasenack: it should be done?
[17:18] <nacc> ahasenack: that is, current
[17:19] <ahasenack> yes
[17:19] <ahasenack> yes
[17:27] <ahasenack> the good news is that the failure also happens locally
[17:29] <nacc> ahasenack: that is 'good'
[17:51] <bdmurray> seb128: What about only including JournalErrors w/ warnings for crash reports? Those would be private by default and you could ask for "bug" reports.
=== mhcerri_ is now known as mhcerri
[18:11] <seb128> bdmurray, that would be a good middle way
[18:12] <bdmurray> seb128: Okay, I'll do that today then.
[18:13] <seb128> bdmurray, great, thank you!
[18:29] <joelkraehemann> seb128: where can I get the gsequencer.changes file you have created?
[18:31] <joelkraehemann> or better does a launchpad repository exist?
[18:32] <seb128> joelkraehemann, I didn't create one, the package was copied from debian by the importer
[18:33] <seb128> joelkraehemann, is https://launchpad.net/ubuntu/+source/gsequencer/1.4.24-1 including what you need?
[18:33] <seb128> joelkraehemann, it's a pure source copy from debian
[18:34] <seb128> joelkraehemann, you have the "builds" section on the right, if you click on an arch there you get download the debs
[18:40] <joelkraehemann> I use the debian repo now and create a .deb file
[19:17] <joelkraehemann> I created a small patch doing sigaction()
[19:42] <joelkraehemann_> how long does it take until I can see the PPA?
[19:42] <joelkraehemann_> dput -u  ppa:~jkraehemann/ppa ../build-area/gsequencer_1.4.24-1_amd64.changes
[20:52] <joelkraehemann> what happens to the package as the ubuntu version is not specified?
=== beisner is now known as beisner-afk
[21:01] <jbicha> joelkraehemann: you need to use an Ubuntu series in the .changes file (usually done with the most recent debian/changelog entry)
[21:02] <jbicha> joelkraehemann: I recommend you look into using backportpackage from the ubuntu-dev-tools package to make it easier
[21:03] <Unit193> I note that 'devel' is a symlink to the development version of Ubuntu (right now, bionic), though not a lot of people use that.
[21:11] <joelkraehemann> yeah, I just left it to UNRELEASED :/
[21:26] <tjaalton> nacc, ahasenack: it needs nss-pem, one way or another. ipa-server that is
[21:27] <nacc> tjaalton: ok, thanks
[21:28] <tjaalton> if that won't make it, I can make freeipa client-only
[21:46] <joelkraehemann_> hi all
[21:46] <joelkraehemann_> http://codepad.org/Te4gZiiS
[21:46] <joelkraehemann_> http://codepad.org/hRmGgAUf
[21:47] <joelkraehemann_> ^^ shows the last output of the commands run
[21:47] <joelkraehemann_> https://launchpad.net/~jkraehemann/+archive/ubuntu/gsequencer
[21:47] <joelkraehemann_> ^^ but still nothing available :/
[22:03] <ginggs> joelkraehemann_:  you should be uploading gsequencer_1.4.24-1_source.changes
[22:06] <joelkraehemann> I don't have it.
[22:06] <joelkraehemann> I do `gbp buildpackage`
[22:09] <nacc> joelkraehemann: i dont' think you generally can upload debs directly to PPAs as you did
[22:10] <nacc> joelkraehemann: you upload source packages and LP builds them in the PPA
[22:12] <nacc> joelkraehemann: specifically you need to pass -S somewhere, probably
[22:14] <joelkraehemann> ginggs: thank you
[22:14] <joelkraehemann> I got it
[22:14] <ginggs> joelkraehemann_: \o/
[22:15] <joelkraehemann> nacc: thank you, too
[22:15] <nacc> joelkraehemann: yw
[22:15] <joelkraehemann> where can I see the build log?
[22:15] <nacc> joelkraehemann: once the PPA starts building it you can see it
[22:16] <joelkraehemann> I see
[22:16] <joelkraehemann> https://launchpad.net/~jkraehemann/+archive/ubuntu/gsequencer/+builds?build_state=building
[22:16] <nacc> joelkraehemann: you should get an emil that it's been accepted and it usually builds shortly after
[22:17] <joelkraehemann> Yeah, I have got one
[22:17] <nacc> looks like it's started
[22:28] <flexiondotorg> infinity: Way back when 16.04 release was approaching you directed me at a "package" that helps the release upgrade process.
[22:28] <flexiondotorg> I can't remember what it was. But it almost certainly needs updating given the changes in Ubuntu MATE between 16.04 and 18.04.
[22:29] <sarnold> do-release-upgrade?
[22:29] <flexiondotorg> sarnold: Maybe, I think this was something that the release upgrader downloaded perhaps.
[22:47] <jbicha> flexiondotorg: check the whole ubuntu-release-upgrader package
=== rbalint_ is now known as rbalint
[23:00] <krytarik> flexiondotorg: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/data/DistUpgrade.cfg - might be what you are thinking of.
[23:13] <joelkraehemann> the tests are running, now.
=== beisner-afk is now known as beisner