[09:27] <Winko> Hi there, anyone problems with starting-up nekobee? After upgrading 4 machines of the 64 bit 13.10 > 14.04, Nekobee won't startup as a stand alone instrument anymore. Nekobee works when started from Qtractor. When trying to start from the command line, I get “jack-dssi-host: Warning: DSSI path not set”, “jack-dssi-host: Defaulting to "/usr/local/lib/dssi:/usr/lib/dssi:/home/<username>/.dssi" ” and “ jack-dssi-host: Error: Fai
[09:27] <Winko> led to load plugin library "nekobee.so"
[09:27] <Winko>  ”. Anyone any thoughts? Regards, Winko
[10:07] <zequence> Winko: I don't know those paths by heart, but could be Nekobee is not in one of those paths
[10:09] <zequence> The plugin itself, that is. jack-dssi-host is a generic dssi host tool to make it possible to load dssi instruments standalone
[10:13] <Winko> OK thank you zequence I will have a look at that
[10:15] <zequence> Winko: It's in /usr/lib/x86_64-linux-gnu/dssi/nekobee
[10:15] <zequence> If it's 64bit
[10:16] <Winko> All 4 machines are 64 bit
[10:17] <Winko> Its folder says knob.png  nekobee_gtk  switch.png
[10:18] <zequence> nekobee.so
[10:18] <zequence> That's the actual plugin
[10:18] <zequence> Winko: Edit /usr/bin/nekobee
[10:18] <zequence> It says: jack-dssi-host nekobee
[10:18] <zequence> nekobee.so*
[10:19] <zequence> Change it so it gives the full path to nekobee
[10:19] <zequence> You can also start nekobee manually with jack-dssi-host
[10:20] <Winko> It says jack-dssi-host nekobee.so
[10:21] <zequence> Yeah, as I said (allthough, edited myself later)
[10:22] <zequence> Make it say: jack-dssi-host /usr/lib/x86_64-linux-gnu/dssi/nekobee.so
[10:22] <Winko> It works like a charm, you are my hero !!!
[10:22] <zequence> np
[10:22] <zequence> Winko: It's a bug btw
[10:22] <Winko> Thank you very much, zequence !!!
[10:22] <zequence> Winko: Would you mind reporting it?
[10:22] <zequence> Winko: ubuntu-bug nekobee
[10:22] <Winko> No problem, will do!
[10:33] <nick87720z> hello. I spent time, catching reason for pulseaudio to reject in releasing device for jack. With pulse 1.1, which is latest in both ustudio and kxstudio, it rejects if some pulse client is active, but otherwise works. I got pulse 2.0 from ubuntu audio dev team ppa, but it refuses always. And on gentoo (calculate) installation i have pulse 4.0 and jack2 latest version, and they work well always (with only exception when i had
[10:33] <nick87720z> pulseaudio-dedicated plasma applet in kde, which somehow magically crashed acquiring, but after plasma-desktop restart did not get pulse, and acquiring began to work).
[10:34] <nick87720z> so, proposing to upgrade pulse to 4.0.
[10:35] <Winko> Done!
[10:47] <zequence> Winko: Thanks
[10:48] <zequence> nick87720z: pulseaudio from precise and onwards handles that correctly, but not for jack1
[10:48] <zequence> jack1 doesn't have the code that talks with PA on negioating releasing the card
[10:55] <nick87720z> zequence: i'm using only jack2. Is ok with active pulse clients too?
[10:55] <zequence> nick87720z: Yep
[10:58] <nick87720z> i just tried it in very old installation, which i have only for emergency maintainance (its root includes home dirs) and to hold grub/burg. Need to check its pulse version.
[11:30] <nick87720z> pulse with version suffix 15.2, indeed all ok
[11:42] <nick87720z> succeed with pulse 2.0. That was badly configured kde multimedia system, using partially both pulse and real device :)
[11:44] <nick87720z> still proposing to upgrade pulse %). As for self i got it specially to get ladspa feature used by pulse mixer plasma applet.
[11:45] <nick87720z> though of course, they can get it in same way, on ubuntu audio dev
[15:36] <studio-user021> install studio on resefs4:
[15:37] <studio-user021> reiserfs4 help;
[15:37] <holstein> studio-user021: you'll want ext
[15:38] <studio-user021> no, i like reiserfs4
[15:38] <holstein> studio-user021: then, ask the maintainers how to use it
[15:38] <holstein> studio-user021: i suggest ext.. for audio production, and use in general linux
[15:39] <studio-user021> on 12.04 i have reiserfs4
[15:39] <holstein> studio-user021: cool.. nothing about 14.04 is preventing you from using reiserfs
[15:39] <holstein> if you are asking me a question, please use ext
[15:40] <holstein> there are no benifits to reiserfs for audio production or linux
[15:40] <studio-user021> thanks !
[15:40] <holstein> studio-user021: from what i read, the support has been removed
[15:40] <holstein> studio-user021: its not maintained upstream, AFAIK
[18:24] <brentblend> I'm on 14.04. Can anyone help me to display .nef thumbnails in file manager?


[05:48] <pitti> Good morning
[07:29] <dholbach> good morning
[07:31] <sladen> Morgen
[09:22] <mvo> pitti: hi, juliank discovered that a autopkgtest fails on s390 and armhf with "WARNING: CHROOTing to /tmp/tmp.UsVnmk3JLH/rootdir was ignored!" is there anything we can do about that ?
[09:23] <juliank> Maybe because those are run on lxc?
[09:23] <pitti> yes, those are in LXC, the other arches run in VMs
[09:23] <pitti> I guess you can't chroot() in LXC
[09:27] <juliank> pitti: On Debian's amd64 lxc instance it works, though
[09:28] <pitti> juliank: I suppose  it's limited by the apparmor profile
[09:28] <pitti> (which Debian doesn't have)
[09:29] <juliank> Can we do anything about that? We obviously need that for our test suite to work correctly because we're testing interaction with dpkg amongst other things
[09:30] <jjohansen> depends, Debian can have the lxc profile, but they are running the mainline kernel version of apparmor
[09:30] <jjohansen> so it is missing some things, the userspace side is largely up to date
[09:36] <pitti> juliank: with chroot() you can easily escape the container, so I'd rather leave tests as "always failed" on the LXC arches
[09:39] <juliank> OK.
[09:39] <juliank> I'll try to at least get the i386 tests passing, currently they only work on amd64
[09:39] <pitti> juliank: which package is that, OOI?
[09:39] <juliank> pitti: apt
[09:40] <juliank> The failure on i386 is just because we only run the suite on amd64, and thus have bugs...
[09:40] <pitti> juliank: right, so they are "always failed" on all but amd64, so they won't hold up proposed migration
[09:40] <pitti> so that's not urgent
[09:41] <juliank> pitti: It's annoying me a bit, though :) [ppc64el should work too, then]
[10:07] <juliank> pitti: We are not actually chrooting(), but preloading a no-op chroot() library. What happens is that we rewrite all execvpe() calls to run <CHROOTDIR>/COMMAND instead of COMMAND, with DPKG_ADMINDIR=<CHROOTDIR>/var/lib/dpkg. So, does the apparmor profile prevent us from executing stuff in /tmp?
[10:08] <juliank> We get a "No such file or directory" when trying to execute the rewritten script path
[10:08] <juliank> For example, /tmp/tmp.Z4pabkgrXk/rootdir/var/lib/dpkg/info/triggerable-interest-noawait.postinst
[10:09] <juliank> execvp(), not execvpe()
[10:10]  * juliank would have expected some permission denied thing, though
[10:13] <juliank> If we could get a log of apparmor during an autopkgtest run, that would probably be useful.
[11:22] <pitti> juliank: I can start a test run manually and check in the container, hang on
[11:29] <xnox> pitti, looking at http://autopkgtest.ubuntu.com/data/status/xenial/amd64/status.json and http://autopkgtest.ubuntu.com/data/status/xenial/s390x/status.json -> i do not believe that there are move autopkgtests for s390x than there are for amd64 =)
[11:30] <xnox> or what do those numbers mean?
[11:30] <pitti> xnox: that actually seemse right
[11:30] <pitti> xnox: as over the weekend I triggered *all* available autopkgtests on s390x
[11:30] <pitti> xnox: but we don't do that for the other arches, they only run if britney triggers them
[11:30] <pitti> xnox: and there's a bunch of packages which haven't changed since wily and thus never ran for xenial
[11:31] <xnox> pitti, hm, so there are tests that never been run on amd64?
[11:31] <pitti> (or their dependencies)
[11:31] <xnox> oh.
[11:31] <pitti> xnox: not in xenial; they ran in wily (or even earlier for packages that seldomly change)
[11:31] <xnox> that makes comparison between arches odd.
[11:32] <xnox> pitti, can you trigger *everything* on amd64 & ppc64el?
[11:32] <pitti> xnox: I'd need to trigger only the ones which didn't run since wily
[11:32] <pitti> "everything" on these will take way too long
[11:32] <xnox> yeap, like that.
[11:33] <pitti> xnox: yes, I can, the main piece of work is to figure out the list of packages
[11:33] <xnox> cause i want to compare the same ballpark numbers on s390x vs others. for test-report...
[11:33] <xnox> pitti, i can do that from json for you, if you wish?
[11:33] <pitti> xnox: you mean the pass/fail ones?
[11:33] <pitti> xnox: that'd be great, yes
[11:33] <pitti> xnox: btw, fancy graphs: http://autopkgtest.ubuntu.com/status/
[11:34] <xnox> pitti, yeah those graphs are missleading =) as e.g. amd64/ppc64el have less packages and higher pass rate. s390x has more packages and lower pass-rate (even when package count adjusted) cause loads of things are still uninstallable.
[11:35] <xnox> i'm doing what nobody should do, that is rerun tests to bring amd64 to reality such that it is comparable with s390x ;-)
[11:35] <pitti> xnox: so, ~ 92% pass rate on i386, ~ 80% on armhf (using LXC), and roughly 70% on s390x (also LXC)
[11:36] <xnox> when opening new series, can you not copy over old results from previous release? such that we get pkg count continuity?
[11:36] <xnox> or trigger all on opening...
[11:36] <pitti> xnox: I could; so far I only copy over the last successful result (if any), to tell apart "always failed" vs. "regression" across new series
[11:36] <pitti> xnox: but as this isn't necessary for "always failed" packages I don't copy those
[11:39] <pitti> juliank: btw, there's other errors like
[11:39] <pitti> -fancy
[11:39] <pitti>  specific
[11:39] <pitti> +fancy
[11:39] <pitti> juliank: (i. e. ordering); I'm running the apt test on armhf manually, so far I haven't run into apparmor violations yet
[11:40] <pitti> ah, but it's only at test 45, the first of that is 132
[11:46] <juliank> pitti: Yeah the other issues are somewhat strange but unrelated.
[11:46] <juliank> It's just ordered differently for whatever reasons
[11:50] <xnox> $ wc -l *.missing
[11:50] <xnox>   553 amd64.missing
[11:50] <xnox>   585 armhf.missing
[11:50] <xnox>   500 i386.missing
[11:50] <xnox>   799 ppc64el.missing
[11:50] <xnox>     0 s390x.missing
[11:50] <xnox>  2437 total
[11:50] <xnox> pitti, http://bazaar.launchpad.net/~xnox/+junk/missing-autopkgtests/files
[11:51] <xnox> pitti, run.sh is how i generated them, *.missing files are the ones to trigger per arch, which did not yet run on xenial it would seem. Would you please check my work for sanity before triggering?
[11:51]  * xnox thinks the above triggers are too high.
[11:51] <pitti> xnox: heh, e. g. http://autopkgtest.ubuntu.com/packages/libx/libxml-tidy-perl/ never ran :)
[11:52] <xnox> pitti, so it is correct right? =) only ever run on xenial/s390x =)
[11:52] <pitti> I guess the autodep8 stuff landed later than the last change to it
[11:53] <pitti> xnox: and e. g. http://autopkgtest.ubuntu.com/packages/l/lmod/ is a case where xenial version == wily version
[11:53] <pitti> xnox: so some spot checks seem fine
[11:53] <pitti> juliank: I'm getting the chroot warnings now, no apparmor violations
[11:54] <juliank> pitti: OK. Then something stranger is going on. Thanks for testing.
[11:54] <xnox> pitti, well please trigger these then =)
[11:54] <pitti> juliank: as soon as the test finishes I can ssh into the container, if you want me to run anything
[12:06] <juliank> pitti: I'm looking at building something, it's somewhat hard though. We build this library: https://paste.debian.net/344216/.
[12:06] <juliank> pitti: I think I found the bug. It's an off by one, newfile is one byte to short
[12:07] <pitti> juliank: ah!
[12:07] <pitti> juliank: please consider using this:
[12:07] <pitti> char newfile[PATH_MAX];
[12:07] <pitti> snprintf(newfile, sizeof(newfile), "%s/%s", path1, path2);
[12:07] <pitti> juliank: snprintf() is so much safer and avoids these gotchaas
[12:08] <pitti> every strcpy() and strcat() eliminated from production code makes a dead kitten get back to life somewhere! :-)
[12:10] <pitti> xnox: do you really need all the arches for comparison? isn't amd64 or armhf sufficient?
[12:10] <pitti> xnox: I now transformed your lists into run-autopkgtest commands with appropriate --trigger arguments, running amd64 now
[12:10] <xnox> pitti, amd64 will do for this week, and rerun everything else on the weekend / holidays?
[12:11] <pitti> but running 500 tests will take a fair while, I'm not going to launch the i386 ones right away
[12:11] <pitti> xnox: sounds fine
[12:11] <pitti> xnox: http://autopkgtest.ubuntu.com/running.shtml#queue-xenial-amd64
[12:11] <xnox> imho for next series you should copy all the results otherwise we under-report the amount of testing we do.
[12:11] <pitti> yeah, can do
[12:11] <xnox> pitti, \o/ thanks.
[12:11] <pitti> xnox: you are the first to notice/ask about statistics
[12:12] <xnox> hehe.
[12:14] <pete-woods> pitti: sorry to keep nagging, but is there any chance you could do a backport of the latest dbusmock release into the vivid overlay?
[12:15] <pitti> pete-woods: it hasn't landed in xenial yet, stuck on the test regression
[12:15] <pitti> so, don't want to backport yet, this first needs looking into
[12:15] <pete-woods> pitti: ah, hadn't realised that
[12:15] <pete-woods> okay
[12:15] <pete-woods> I will have a look at that then
[12:20] <pete-woods> pitti: https://github.com/martinpitt/python-dbusmock/pull/18/files how about that?
[12:20] <pete-woods> (copied the same setup from test_bluez5.py)
[12:20] <pete-woods> to me it looked like *something* was running the tests individually
[12:20] <pitti> pete-woods: oh nice! do you know what triggered that in your last PR?
[12:21] <pete-woods> pitti: I added a test that did sorta async stuff from the bluez test
[12:21] <pete-woods> where you wait for a bunch of signals to be emitted
[12:21] <pitti> ah, async needs a main loop indeed
[12:21] <pete-woods> but the weird thing is the tests work fine when you run the full suite
[12:21] <pete-woods> maybe that's because the bluez one has already setup the mainloop..
[12:22] <pitti> cd tests
[12:22] <pitti> for f in *.py; do
[12:22] <pitti>     python3 $f
[12:22] <pitti> done
[12:22] <pitti> pete-woods: ^ the autopkgtest does that
[12:22] <pete-woods> right
[12:22] <pitti> pete-woods: yeah, very likely
[12:22] <pete-woods> well that would explain it
[12:23] <pitti> pete-woods: we want to run the tests against the installed py module, so we can't use ./setup.py
[12:23] <pete-woods> fair enough
[12:23] <pete-woods> I have no python-fu
[12:23] <pete-woods> I just type til it stops erroring
[12:25] <pitti> pete-woods: works fine, thanks
[12:25] <pete-woods> cool
[12:32] <pitti> pete-woods: 0.16.3 released and uploaded to Debian; for the backport, I take it vivid+wily?
[12:34] <pitti> pete-woods: uploaded backports to both; thanks for the fix!
[12:36] <pete-woods> pitti: thanks very much, I don't really care about wily too much, but may as well do both just in case
[13:35] <xnox> infinity, may i steal your strace pending merge?
[13:36] <infinity> xnox: Sure.
[13:56] <xnox> infinity, fails on i386 with one fail, fails a lot more on s390x =( here is to new upstream release fixing nothing....
[13:58] <infinity> xnox: Looks fine in Debian build logs.  So, that's curious.
[13:59] <xnox> mono gdoc fails to bootstrap with -O2, strace failures. something odd is going on.
[13:59] <xnox> *mdoc
[14:47] <teward> should I be highly concerned when my sbuild schroot complains with "W: No sandbox user '_apt' on the system, can not drop privileges"
[14:47] <teward> (it's a Xenial schroot)
[14:53] <cyphermox> has it already done some upgrades before showing that message?
[14:54] <infinity> teward: That's because the user doesn't exist outside the chroot, and schroot copies in your external /etc/passwd
[14:54] <infinity> teward: It's mostly harmless.
[15:05] <xnox> infinity, retrying strace/i386 made it "pass" the test-suite.....
[15:05]  * xnox looses confidence in strace testsuite
[15:05] <thebwt> howdy folks! I'm putting together a chart for a history of Ubuntu. Before lucid, Ubuntu was derived from Debian Sid. Was it a frozen Sid at the time of release? (trying to show the relationship overtime to debian)
[15:07] <geofft> can someone who can see private bugs tell me what LP #723515 is?
[15:07] <geofft> or where should I ask?
[15:08] <infinity> geofft: Ask the security team.  If it's an ubuntu bug, they can see it.
[15:08] <geofft> I believe that it is a bug in Ubuntu glibc
[15:08] <infinity> geofft: If it's not, then the only people likely to be able to see it are LP admins, to #canonical-sysadmin
[15:08] <geofft> er, gcc
[15:08] <infinity> Actually, wait, I'm in the security team and I can't see it. :P
[15:08] <infinity> So, no.  It's probably not an Ubuntu bug.
[15:09] <xnox> infinity, >_< #identitycrisis
[15:09] <infinity> xnox: *cough*
[15:09]  * xnox slowly backs away
[15:09] <infinity> xnox: Using hashtags on IRC should be punishable by death.
[15:10] <geofft> I am pretty sure the kids these days are saying things like "hashtag ubuntu-devel"
[15:10] <xnox> infinity, wait till Ev comes over to london and stays at my place. I'll catch up on my hipster training to make you cry. =)
[15:10] <infinity> geofft: *cry*
[15:10] <infinity> xnox: Are you going to grow a beard and roll up your jeans to fit in?
[15:10] <infinity> xnox: I can send you some nice plaid flannel from Canada.
[15:12] <dobey> infinity: don't forget the butter scones and women's clothing too
[15:12] <xnox> thebwt, it's more fluid than that. each release cycle there are autosyncs happening from debian, in general it's always from debian sid, apart from couple of LTS which we did from testing. but these days it's always from sid. Where there are no changes in ubuntu packages are synced from debian unmodified. Upto debianimport freeze milestone, after that some uploads are cherrypicked. But packages that have ubuntu changes can be ahead or behind debian,
[15:12] <xnox> and merged when developers see fit / need / or have time.
[15:13] <xnox> thebwt, further reading is at: https://wiki.ubuntu.com/UbuntuDevelopment https://wiki.ubuntu.com/UbuntuDevelopment/ReleaseProcess https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#SyncingAndMerging
[15:13] <thebwt> xnox: but https://launchpad.net/ubuntu/wily says derived from stretch
[15:14] <thebwt> reading
[15:14] <xnox> thebwt, that field is meaningless. where we sync packages from is what matters. It's mostly a thing used to generate useful debdiffs between packages and a "stablish" debian branch to make static debdiffs from.
[15:15] <infinity> thebwt: Read that with a grain of salt.  We always set that to the current "testing", and it detemines where LP decides to generate some deltas from, but our actual imports happen from sid.
[15:15] <xnox> if all packages, from all ubuntu releases debdiff against sid.... the diffs will have little meaning.
[15:15] <thebwt> makes sense
[15:15] <thebwt> thanks guys, chart just exploded
[15:15] <thebwt> :p
[15:16] <xnox> infinity, https://wiki.ubuntu.com/DebianImportFreeze is telling lies
[15:16]  * xnox edit.
[15:18] <infinity> xnox: Is it not the nature of documentation to be full of lies?
[15:18] <xnox> thebwt, https://wiki.ubuntu.com/DebianImportFreeze updated with slightly less lies.
[15:24] <thebwt> should have asked here instead of google....
[15:24] <teward> infinity: OK, just making sure i don't have to beat my system into submission
[15:25] <teward> cyphermox: regarding what I think was a question to me, it happens right after the schroot tries to double check if it's up to date.
[15:25] <teward> but as infinity says it's mostly harmless, and nothing else seems to be broken... :p
[15:25] <cyphermox> yeah
[15:25] <cyphermox> I never noticed it ;)
[15:25] <teward> ... well, except my packages, of course, 'cause i made a typo in a patch :/
[15:26] <infinity> cyphermox: You've never noticed it because your host system is an up to date xenial, probably.
[15:26] <cyphermox> yeah mostly up to date
[15:27] <infinity> And we don't see it on LP because we don't do the fiddly update-databases-from-the-host-system thing there.
[15:29] <teward> as long as it doesn't break anything (it appears to just be a warning), I guess I don't have to wrry about it
[15:29] <teward> though I'll be testing the output packages anyways ('cause testing a package before submitting it as a merge)
[15:43] <mterry> bdmurray, you probably want to add ~maas-devel to your package-subscribers script
[16:29] <gQuigs> how do I tell a package not to build for [!s390x] architecture?  (seems like both gnome-shell and network-manager-gnome do this, but I can't figure out how..)
[16:31] <seb128> gQuigs, no they don't?
[16:31] <seb128> https://launchpad.net/ubuntu/+source/gnome-shell/3.18.2-0ubuntu2/+build/8374520
[16:32] <seb128> n-m-applet is blocked on libappindicator to be available
[16:32] <seb128> which is blocked on the mono transition
[16:32] <xnox> which is in a landing silo, which still ftbfs on s390x due to dbus test suite error
[16:32] <xnox> and yes mono
[16:32] <xnox> gQuigs, please do not do !s390x unless you are building i386 specific bootloader code =)
[16:33] <xnox> gQuigs, it should not matter at all, why do you care? is something blocked for you?
[16:33] <xnox> in practice s390x build-failures do not matter most of the time, at the moment, unless it's a real regression.
[16:33] <gQuigs> xnox: yea, I did a bad sync request - https://bugs.launchpad.net/ubuntu/+source/meta-gnome3/+bug/1523657
[16:33] <gQuigs> trying to fix it
[16:33] <xnox> (or entangled in funny ways)
[16:34] <xnox> gQuigs, i think it should not have been synced.... it's not only a problem on s390x.... http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#meta-gnome3
[16:34] <gQuigs> it usedto specify [amd64] [other archs]. but since s390x is the only one that's failing
[16:35] <xnox> gQuigs, it's uninstallable on _all_ architectures in ubuntu.
[16:35] <xnox> gQuigs, i think you should copy that output back to the bug report, and ask release/archive admins to remove that sync from -proposed.
[16:36] <gQuigs> xnox: right I missed three on all archs, but those can be fixed by a new merge right?
[16:36] <gQuigs> (libreoffice-evolution, iceweasel, and vino)
[16:36] <xnox> gQuigs, yes, and the rest will be available on s390x eventually. So just leave it as is for me to clean up.
[16:37] <xnox> gQuigs, it will be stuck in -proposed for a while, but it's better that way, and spares me finding all the places people did !s390x, or rather explicit arch list and re-enabling it back later.
[16:37] <xnox> s390x is circa 80% built now, so soon thse high level things will be installable too.
[16:39] <gQuigs> xnox: makes sense I guess, the same status as much of the stuff under it... I should still do a debdiff for the stuff broken on all archs though right?
[16:40] <xnox> gQuigs, yes (libreoffice-evolution, iceweasel, and vino) should be still fixed, as those are not in ubuntu and probably will not be ever (if i recall correctly it's intentional delta for us)
[16:40] <gQuigs> k, will do, thanks!
[19:30] <mitya57> pitti, the autopkgtest triggers display is *awesome* :)
[20:38] <rharper> rbasak: looking at that libnl3 bug and patches, I see that it has a debian/patches dir, under which it has another debian dir (with patches, so debian/patches/debian/XXXX.patch)  ; quilt will apply (pop and push) those patches, but when the last patch is applied, quilt diff still shows a delta;  adding a new patch results in diffs being added to the previous patch (even though I've already quilt new/quilt add file.c)
[20:38] <rharper> ... first time seeing that sort of patch setup; what am I missing ?
[21:00] <rbasak> rharper: it looks like it's regular quilt, just with patches that have debian/ prefixed to it.
[21:00] <rbasak> rharper: try popping all patches and adding a new patch and also to the series file manually, maybe, and see if quilt accepts that?
[21:00] <rharper> rbasak: yeah; I just can't figure out why when I quilt new mypatch; quilt add path/to/file; apply diff, refresh
[21:00] <rharper> it captures the new changes into the previous patch
[21:01] <rharper> ok, I can try manually
[21:01] <rharper> just very strange behavior, but also the first time I've seen subdirs of patches (though that really shouldn't matter)
[21:01] <rbasak> rharper: I'm not sure. I've seen subdirs before and they've worked transparently. I don't see anything here that might cause the specialness you're seeing here.
[21:02] <rharper> =(
[21:02] <rharper> probably a PEBCAC but figured I'd ask
[21:03] <rbasak> rharper: you're right to ask. There are many historical variations on patch mechanisms that we see from time to time.
[21:03] <rharper> pop'ing all and applying at the start seems to work, good new is that the subdir of patches are all build file changes, so no chance of collision
[21:03] <rharper> but I am still somewhat concerned that I have to do it this way
[21:04]  * rharper will try out on a clean env instead of laptop
[21:22] <rharper> rbasak: it appears the suggested fixes won't cleanly apply and look like it depends on some newer changes to the repository that aren't present in the version in trusty (library symbol linker scripts as well as a capabilities system).  Is it reasonable to ask the submitter to look at modifying the changes to work with the older version ?
[21:24] <bdmurray> mterry: maas-maintainers seems like a better team (more canonical / likely to be responsible) than maas-devel
[21:25] <mterry> bdmurray, well I didn't decide which to subscribe...  But I could imagine an argument for devel watching bugs rather than the smaller maintainer team...
[21:25] <rbasak> rharper: I think so, yes. Certainly with an Ubuntu hat on
[21:25] <rbasak> rharper: it's still valuable to have found that and put it in the bug though, thanks. It means that they understand what they need to do, rather than think that they're blocked on our sponsorship.
[21:25] <rharper> rbasak: ok, then I'll update the bug with my analysis and request that submitter look at modifying changes to work with the version in trusty
[21:26] <mterry> bdmurray, but I'm just the messenger here.  I can ask if they want to reconsider on the bug
[21:26] <rbasak> rharper: great. Thanks!
[21:26] <rharper> rbasak: yep
[21:26] <rbasak> rharper: did the principle of the patch itself look OK to you, OOI? I was a little dubious.
[21:27] <rharper> rbasak: it *looked* OK, but it had enough extra non-obvious math that I was going to have to write test cases
[21:27] <rbasak> OK. It seemed to me to be far too much complexity. There should be a better way.
[21:27] <bdmurray> mterry: what is the bug?
[21:28] <rharper> honestly, the psuedo random selection in the array seemed overly complicated
[21:28] <rharper> but it's gone upstream (still scary)
[21:28] <mterry> bdmurray, bug 1522182
[21:28] <rbasak> I wonder if there's a much simpler fix that could fix their use case.
[21:30] <rharper> rbasak: indeed
[23:29] <rtg> infinity, apw mentioned last week that you and/or doko were working on the compiler bug that I'm seeing with build a v4.4-rcx arm64  kernel. Any updates ? https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/unstable/+build/8438034/+files/buildlog_ubuntu-xenial-arm64.linux_4.4.0-0.5_BUILDING.txt.gz


[00:25] <mwhudson> mwhudson@anduril:~/ubuntu/logs$ apt-cache show libstdc++6 | grep -E '^Package|Description-en'
[00:25] <mwhudson> Package: libstdc++6
[00:25] <mwhudson> Description-en: GNU Standard C++ Library v3
[09:36] <eoli3n> Hi mardy
[09:36] <eoli3n> i'm back to work, i really need to find a way to fix firefox
[09:36] <eoli3n> https://forum.snapcraft.io/t/cannot-open-path-of-the-current-working-directory-permission-denied-bis/28704/41
[09:37] <eoli3n> can we take some time on this, if you have some I will answer as quickly as I can
[09:37] <eoli3n> I need to fix this before the end of the week, to be able to start migrating ~800 desktop next week
[12:18] <ahasenack> Unit193: are you planning on updating wireguard in debian before ubuntu's feature freeze?
[12:37] <eoli3n> mardy should I set no_root_squash option client or server side ?
[12:38] <eoli3n> when i add this client side in autofs config and restart autofs/umount user home, then remount, the option seems ignore
[12:38] <eoli3n> d
[13:54] <enr0n> I am looking for a sponsor for bug 1860568, which is a left over from my +1 shift a couple weeks ago
[14:45] <jawn-smith> Did an AA remove my busybox upload from kinetic-proposed? It was there yesterday and now it's gone
[14:47] <ginggs> jawn-smith: it's migrating...
[14:48] <jawn-smith> oh, that's surprising cause there was still a failed autopkgtest
[14:48] <jawn-smith> oh yeah there it is, "will attempt migration due to a hint"
[14:48] <ginggs> zfs-linux?
[14:48] <jawn-smith> Thanks ginggs! Yeah, zfs-linux
[14:48] <jawn-smith> I missed that there was a hint for that
[14:54] <enr0n> bdmurray: The systemd amd64 autopkgtest passed on staging. Would you prefer to try the remaining arches there before re-triggering in the production autopkgtest environment?
[15:16] <nibbon_> o/
[15:17] <nibbon_> is there a way to change the compression of a .deb generated by dkms mkbmdeb?
[15:19] <athos> amurray: hi! I am wondering if it would be OK to sync redis 7.x from debian or if there is some special reason to keep it in 6.x for kinetic
[15:27] <xnox> nibbon_:  because you need different one?
[15:27] <xnox> nibbon_:  normally one would produce those inside schroot created by mk-sbuild such that they are compatible with a target release.
[15:32] <bdmurray> enr0n: Is the PPA upload something that'll eventually go to release? I mean could you get what you are looking for by using staging? It'd be faster than waiting for the production queues to be consumed.
[15:38] <enr0n> Yes, these are pre-upload checks for merging 251.4 from debian. slyon went ahead and triggered the tests though, except for armhf.
[15:41] <ginggs> athos: i'd say redis looks good for a sync, it's in universe and CVE-2022-0543 is fixed in the debian changelog
[15:42] <enr0n> bdmurray: so if we could trigger the armhf test on staging that would be good
[15:44] <bdmurray> enr0n: that is done
[15:44] <enr0n> bdmurray: thanks!
[16:57] <athos> ginggs: thanks! That's what I have been thinking! Just wondered it would be nice to ask before sync'ing to ensure there's no other reason it wasn't sync'd yet apart from that CVE
[17:05] <nibbon_> xnox: yeah, I have a repository that doesn't support the default tar compression. Right now I'm using an ugly hack - unpacking and repacking passing -Zxz - but I wanted to know whether there an option or a env variable I can pass to dkms
[17:09] <xnox> nibbon_:  best option to open a feature request to https://github.com/dell/dkms/issues
[17:13] <nibbon_> oic, I hope there was a special spell to cast 🙄 ... alrighty then, I'll open a feature request with them. Thx
[17:44] <Unit193> ahasenack: I think that's unlikely.
[18:36] <ahasenack> ok
[18:59] <luis220413> How can I get the build status of multiple packages in the development release at once?
[18:59] <luis220413> Specifically, I want to know which Haskell packages are failing to build.
[19:00] <Unit193> ahasenack: Why do you ask?
[19:00] <ahasenack> because the version we have is from september 2021
[19:01] <ahasenack> almost a year old, assuming there is a new one out there
[19:02] <Unit193> If there was a new one, I'd have picked it up.  It's just the tests pending right now.
[19:02] <ahasenack> yeah, just checked, looks like the latest tag: https://github.com/WireGuard/wireguard-tools/tags
[19:02] <ahasenack> so n/m
[19:03] <Unit193> 1. The "This package is out of date, email the maintainer!" would have notified me.  2. I have uscan --report run over all of my packages every three days, I'd know. :3
[19:03] <jbicha> luis220413: click the good checkbox at https://people.canonical.com/~ubuntu-archive/transitions/html/ghc.html
[19:04] <sarnold> that's cool
[19:46] <luis220413> This build is blocking several packages: https://launchpad.net/ubuntu/+source/haskell-lua/2.1.0+ds1-2/+build/24233985
[19:46] <luis220413> Actually, all builds for this source package
[19:46] <vorlon> luis220413: https://people.canonical.com/~ubuntu-archive/transitions/html/html/ghc.html is the best overview; I am working through the necessary rebuilds
[19:47] <luis220413> Thanks!
[19:49] <luis220413> However, this build was retried before that of haskell-tasty, causing dependency failures.
[19:49] <luis220413> vorlon: However, these builds (of haskell-lua) was retried before those of haskell-tasty, causing dependency errors.
[19:49] <luis220413> *were
[19:51] <vorlon> luis220413: someone retried all the failed package builds; there's no logs to say who did this.  I am building the packages in order.
[19:51] <luis220413> Thanks!


[05:48] <oSoMoN> good morning desktoppers
[05:51] <duflu> Morning oSoMoN
[06:21] <didrocks> good morning
[06:22] <oSoMoN> hey duflu, salut didrocks
[06:22] <didrocks> salut oSoMoN
[06:31] <jibel> Good morning all
[06:34] <didrocks> salut jibel
[06:36] <duflu> Hi didrocks and jibel
[06:37] <jibel> hi didrocks duflu oSoMoN
[06:37] <didrocks> hey duflu
[06:39] <oSoMoN> salut jibel
[07:09] <Nafallo> morning desktopers
[07:09] <duflu> Hi Nafallo
[07:14] <didrocks> hey Nafallo
[07:16] <Nafallo> the first cup of coffee did nothing...
[07:32] <jibel> Good morning Nafallo
[07:38] <marcustomlinson> morning oSoMoN duflu didrocks jibel Nafallo
[07:39] <jibel> Hi marcustomlinson
[07:42] <didrocks> hey marcustomlinson
[07:45] <ricotz> good morning everyone
[07:54] <didrocks> hey ricotz
[07:58] <duflu> Morning marcustomlinson and ricotz
[07:59] <marcustomlinson> hey ricotz
[08:04] <Laney> ahoy
[08:08] <didrocks> hey Laney
[08:10] <duflu> Hi Laney
[08:14] <oSoMoN> good morning Nafallo, marcustomlinson, ricotz, Laney
[08:14] <marcustomlinson> hey Laney
[08:20] <seb128> goood morning desktopers!
[08:21] <oSoMoN> salut seb128
[08:25] <Laney> hey didrocks duflu oSoMoN marcustomlinson seb128
[08:25] <Laney> how's it going?
[08:26] <seb128> hey Laney, going alright, still not over that cold and extra tired but otherwise things are fine
[08:26] <oSoMoN> I'm good and mostly rested, how's everyone?
[08:26] <seb128> hey oSoMoN
[08:26] <seb128> oSoMoN, I don't know how you manage to rest with young kids around during the weekends!
[08:26] <duflu> Hi seb128
[08:27] <seb128> hey
[08:28] <didrocks> hey seb128
[08:28] <oSoMoN> seb128, tbh I don't sleep much more than usual, but spending most of my time outdoors helps a lot, that and a short nap after lunch when my youngest sleeps too
[08:29] <seb128> I missed the nap opportunity this weekend :/
[08:29] <seb128> lut didrocks
[08:29] <didrocks> +1 oSoMoN :)
[08:29] <seb128> we got one of those, that's fun, http://www.hollandse-bakfietsen.nl/kopen/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/k/a/kangaroo_luxe_4_zits.jpg
[08:29] <Laney> yessssssssssssssssssssssssss
[08:30] <oSoMoN> good for your legs :)
[08:32] <seb128> oSoMoN, you can also be lazy, it has an small electric engine ;-)
[08:33] <oSoMoN> clever
[08:34] <Laney> needs a seat on the back for the other adult :>
[08:36] <seb128> would be even better indeed
[08:36] <marcustomlinson> hey seb128
[08:36] <seb128> hey marcustomlinson, how are you?
[08:37] <marcustomlinson> Laney, seb128: doing oookaaaaaaaay. our daughter has taken an interest in screaming bloody murder in the middle of the nights now so that's been fun
[08:40] <duflu> seb128, I don't think there is anything more Dutch than that
[08:40] <Laney> marcustomlinson: /o\ /o\ /o\ /o\
[08:40] <seb128> marcustomlinson, :-(
[08:41] <Laney> hope it's a brief phase
[08:41] <ricotz> seb128, hi, fyi, I need to spin another round of vala release due to a regression in an earlier version, effected is e.g. tetravex https://gitlab.gnome.org/GNOME/gnome-tetravex/-/issues/32
[08:41] <marcustomlinson> duflu: a caravan hooked to the back of it - that'd be more Dutch
[08:42] <seb128> ricotz, hey, alright, let me know when you have something ready for upload
[09:08] <KGB-0> gnome-shell ubuntu/master Daniel van Vugt * [update] merge request !47: Drop layout-Allow-updating-struts-in-Overview.patch * https://deb.li/3kKUl
[10:49] <ricotz> seb128, thx, will do
[13:09] <KGB-2> gnome-shell ubuntu/master 353faaa Daniel van Vugt debian/patches/ series layout-Allow-updating-struts-in-Overview.patch * Drop layout-Allow-updating-struts-in-Overview.patch * https://deb.li/3yEI
[13:09] <KGB-2> gnome-shell ubuntu/master Marco Trevisan * [merge] merge request !47: Drop layout-Allow-updating-struts-in-Overview.patch * https://deb.li/3kKUl
[16:09] <hellsworth> i forgot to say good morning desktopers :)
[16:15] <kenvandine> Good morning hellsworth
[16:15] <hellsworth> hi kenvandine :)
[16:33] <oSoMoN> good morning hellsworth
[16:34] <hellsworth> hi there oSoMoN !


[00:28] <micahg> ScottK: right, sorry, that's true as well :)
[01:45] <cdunlap> I am not sure this is the correct forum, but I have a quick question around packaging and expectations.  Would this be an appropriate place to ask?
[01:46] <ScottK> cdunlap: It depends.  If you are working on packages for Ubuntu, it is.  If not, #ubuntu-packaging might be better.
[01:46] <cdunlap> ScottK: I think this could be classified as a general packaging question
[01:47] <ScottK> I'd say ask then.
[01:47] <cdunlap> So I have been trying to learn how to package and I have been working through the information Daniel Holbach has been putting on OMGUbuntu.
[01:48] <cdunlap> When I try to 'make' the file it kicks back, what look to me, as errors with one of the files.  Is the expectation that the packager would fix these errors, or would the packager work with the developer of the application?
[01:49] <ScottK> "It depends"
[01:49] <ScottK> Sometimes the errors are due to packaging problems, sometimes it's an upstream issue.
[01:50] <cdunlap> is being able to tell the difference something you gain with experience or is it usually pretty evident?
[01:50] <ScottK> Sometimes even if it's an upstream issue, a packager will figure out a fix and let upstream know.
[01:50] <ScottK> Yes.
[01:50] <ScottK> Sometimes it's pretty evident, sometimes it's stuff it takes experience to understand.
[01:51] <cdunlap> I figured some of my troubles are because I am trying to figure it out.  Thanks for the clarification.  I do appreciate it.
[01:53] <ScottK> No problem.
[06:03] <alkisg> If I have a debian/upstart file, do I need to have debian/postinst and debian/postrm too? Or dh_installinit can create them for me?
[06:17] <Rhonda> It creates them
[06:25] <alkisg> Thank you, I was worried about this lintian warning: W: panoptes: script-in-etc-init.d-not-registered-via-update-rc.d /etc/init.d/panoptes
[06:26] <Rhonda> hmm
[06:27] <Rhonda> dpkg --info panoptes_*.deb  # does this list postrm/postinst?
[06:27] <Rhonda> Maybe you do need a dummy file then which includes the #DEBHELPER# marker.
[06:28] <alkisg> It has postinst, preinst and prerm
[06:28] <alkisg> All autogenerated
[06:28] <alkisg> And inside postinst:
[06:28] <alkisg> # Automatically added by dh_installinit
[06:28] <alkisg> update-rc.d -f panoptes remove >/dev/null || exit $?
[06:29] <alkisg> ...remove?
[06:30] <Rhonda> uh?
[06:30] <alkisg> I don't know why, but it calls update-rc.d remove in postinst! ????
[06:31] <alkisg> (using gdebi-gtk to look the scripts inside the .deb)
[06:42] <alkisg> It looks like dh_installinit only has this bug with upstart, if I put debian/init scripts instead, I get no lintian warnings and the automatically generated postinst is sane again
[06:43] <alkisg> Oh well I'll just revert the scripts from upstart to sysvinit again. Thanks :)
[07:14] <dholbach> good morning
[08:07] <alkisg> The "update-rc.d -f package remove" part earlier may there to remove the init.d links, as the upstart job should be used instead. I see it on packages that have a manual postinst too.
[08:08] <alkisg> And for the "script-in-etc-init.d-not-registered-via-update-rc.d" warning, I found a bug in launchpad, it was fixed in later lintian versions (I'm using lucid)
[08:15] <micahg> hi Q-FUNK, so have you sponsored bzr branches yet?
[08:15] <Q-FUNK> not that I can remember, no.
[08:16] <micahg> Q-FUNK: oh, well, if you're interested, I'm sure someone here can help you, https://code.launchpad.net/~jbicha/ubuntu/oneiric/gjs/1.29.18/+merge/76441, it's 3AM for me so I'm a little reluctant right now
[08:20] <Q-FUNK> ok
[13:34] <ScottSanbar> ApOgEE: Howdy!
[13:34] <ScottSanbar> (whoops)
[13:41] <alkisg> Which of those should I prefer to package a python app? http://www.debian.org/doc/packaging-manuals/python-policy/ap-packaging_tools.html
[13:41] <alkisg> Is distutils with debhelper a good choice, or should I go for CDBS?
[13:50] <geser> I'd go with debhelper
[13:52] <alkisg> Debhelper with plain distutils, right? Not dh_pysupport nor dh_pycentral... correct?
[13:53] <tumbleweed> --with python2
[13:53] <alkisg> Ah, thank you, /me reads about that ...
[13:56] <alkisg> Could someone suggest me a package that uses that, so that I could use it as a template?
[13:57] <tumbleweed> alkisg: so this is a simple python app. Does it also have a public python library? or is it not going to be useful for other python apps, and should be installed privatel?
[13:58] <alkisg> tumbleweed: It's separated into 2 parts. One daemon is using twisted, and a client/GUI is contacting the daemon part.
[13:58] <alkisg> Neither of them will be useful to external apps
[14:00] <tumbleweed> alkisg: ok, I don't have any packages excatly like that, but upnp-inspector is a simple python app that installs privately
[14:01] <tumbleweed> alkisg: do you install any twisted plugins? (i.e. for the daemon)
[14:01] <alkisg> Thank you, I'll look into that
[14:01] <alkisg> tumbleweed: yes, but I'd prefer to run them manually instead of as plugins, if I manage to do it
[14:02] <alkisg> twistd -f path/to/my/file.py or however else it works
[14:02] <tumbleweed> alkisg: ok, if you install a plugin, you should activate the twisted-plugins-cache trigger
[14:02] <ScottK> If it's using twisted it'll need to use the same python helper as twisted.
[14:02] <tumbleweed> twisted uses dh_python2 these days
[14:02] <alkisg> Good, some good news at last :)
[14:33] <ripps> I'm having some problems with a package that doesn't work anymore, can someone join me #ubuntu-packaging
[20:39] <ScottSanbar> Unit193:  I mean the fact that you clued me in - thanks ...
[20:39] <ScottSanbar> (whoops)


[05:21] -queuebot:#ubuntu-release- New binary: rust-signature [amd64] (mantic-proposed/none) [2.1.0+ds-2] (no packageset)
[05:28] -queuebot:#ubuntu-release- New binary: zug [amd64] (mantic-proposed/none) [0.1.0-2] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: zug [ppc64el] (mantic-proposed/none) [0.1.0-2] (no packageset)
[05:32] -queuebot:#ubuntu-release- New binary: zug [s390x] (mantic-proposed/none) [0.1.0-2] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: zug [riscv64] (mantic-proposed/none) [0.1.0-2] (no packageset)
[05:37] -queuebot:#ubuntu-release- New binary: zug [armhf] (mantic-proposed/none) [0.1.0-2] (no packageset)
[05:47] -queuebot:#ubuntu-release- New binary: zug [arm64] (mantic-proposed/none) [0.1.0-2] (no packageset)
[08:50] -queuebot:#ubuntu-release- New: accepted asgi-lifespan [amd64] (mantic-proposed) [2.1.0-1]
[08:50] -queuebot:#ubuntu-release- New: accepted fonts-atkinson-hyperlegible [amd64] (mantic-proposed) [0.0~git20210430.1cb3116-2]
[08:50] -queuebot:#ubuntu-release- New: accepted node-fast-json-stable-stringify [amd64] (mantic-proposed) [2.1.0-1]
[08:50] -queuebot:#ubuntu-release- New: accepted robtk [amd64] (mantic-proposed) [0.8.4-1]
[08:50] -queuebot:#ubuntu-release- New: accepted wl-mirror [amd64] (mantic-proposed) [0.13.1-1]
[08:50] -queuebot:#ubuntu-release- New: accepted wl-mirror [armhf] (mantic-proposed) [0.13.1-1]
[08:50] -queuebot:#ubuntu-release- New: accepted wl-mirror [riscv64] (mantic-proposed) [0.13.1-1]
[08:50] -queuebot:#ubuntu-release- New: accepted zug [amd64] (mantic-proposed) [0.1.0-2]
[08:50] -queuebot:#ubuntu-release- New: accepted zug [armhf] (mantic-proposed) [0.1.0-2]
[08:50] -queuebot:#ubuntu-release- New: accepted zug [riscv64] (mantic-proposed) [0.1.0-2]
[08:50] -queuebot:#ubuntu-release- New: accepted cvsutils [amd64] (mantic-proposed) [0.2.5-2]
[08:50] -queuebot:#ubuntu-release- New: accepted python-mt-940 [amd64] (mantic-proposed) [4.30.0-1]
[08:50] -queuebot:#ubuntu-release- New: accepted wl-mirror [arm64] (mantic-proposed) [0.13.1-1]
[08:50] -queuebot:#ubuntu-release- New: accepted wl-mirror [s390x] (mantic-proposed) [0.13.1-1]
[08:50] -queuebot:#ubuntu-release- New: accepted zug [ppc64el] (mantic-proposed) [0.1.0-2]
[08:50] -queuebot:#ubuntu-release- New: accepted libmozilla-publicsuffix-perl [amd64] (mantic-proposed) [1.0.6-2]
[08:50] -queuebot:#ubuntu-release- New: accepted wl-mirror [ppc64el] (mantic-proposed) [0.13.1-1]
[08:50] -queuebot:#ubuntu-release- New: accepted zug [s390x] (mantic-proposed) [0.1.0-2]
[08:50] -queuebot:#ubuntu-release- New: accepted rust-signature [amd64] (mantic-proposed) [2.1.0+ds-2]
[08:50] -queuebot:#ubuntu-release- New: accepted zug [arm64] (mantic-proposed) [0.1.0-2]
[10:04] -queuebot:#ubuntu-release- New binary: asgi-csrf [amd64] (mantic-proposed/universe) [0.9-1] (no packageset)
[10:14] -queuebot:#ubuntu-release- Unapproved: gjs (jammy-updates/main) [1.72.0-1 => 1.72.2-0ubuntu2] (desktop-core, desktop-extra, i386-whitelist, mozilla) (sync)
[11:00] -queuebot:#ubuntu-release- New: accepted asgi-csrf [amd64] (mantic-proposed) [0.9-1]
[11:00] -queuebot:#ubuntu-release- New: accepted ktextaddons [arm64] (mantic-proposed) [1.4.0-0ubuntu1]
[11:00] -queuebot:#ubuntu-release- New: accepted ktextaddons [ppc64el] (mantic-proposed) [1.4.0-0ubuntu1]
[11:00] -queuebot:#ubuntu-release- New: accepted ktextaddons [s390x] (mantic-proposed) [1.4.0-0ubuntu1]
[11:00] -queuebot:#ubuntu-release- New: accepted ktextaddons [amd64] (mantic-proposed) [1.4.0-0ubuntu1]
[11:00] -queuebot:#ubuntu-release- New: accepted ktextaddons [riscv64] (mantic-proposed) [1.4.0-0ubuntu1]
[11:00] -queuebot:#ubuntu-release- New: accepted ktextaddons [armhf] (mantic-proposed) [1.4.0-0ubuntu1]
[11:13] -queuebot:#ubuntu-release- Unapproved: accepted gjs [sync] (jammy-updates) [1.72.2-0ubuntu2]
[11:28] -queuebot:#ubuntu-release- New binary: xeus [amd64] (mantic-proposed/universe) [3.1.1-2] (no packageset)
[11:28] -queuebot:#ubuntu-release- New binary: xeus [s390x] (mantic-proposed/universe) [3.1.1-2] (no packageset)
[11:35] -queuebot:#ubuntu-release- New binary: xeus [arm64] (mantic-proposed/universe) [3.1.1-2] (no packageset)
[11:35] -queuebot:#ubuntu-release- New binary: xeus [armhf] (mantic-proposed/universe) [3.1.1-2] (no packageset)
[11:49] -queuebot:#ubuntu-release- Unapproved: docker.io-app (jammy-proposed/universe) [20.10.25-0ubuntu1~22.04.1 => 20.10.25-0ubuntu1~22.04.2] (no packageset)
[11:50] -queuebot:#ubuntu-release- Unapproved: docker.io-app (focal-proposed/universe) [20.10.25-0ubuntu1~20.04.1 => 20.10.25-0ubuntu1~20.04.2] (no packageset)
[11:54] -queuebot:#ubuntu-release- New binary: xeus [riscv64] (mantic-proposed/universe) [3.1.1-2] (no packageset)
[12:02] -queuebot:#ubuntu-release- New binary: xeus [ppc64el] (mantic-proposed/universe) [3.1.1-2] (no packageset)
[14:33] -queuebot:#ubuntu-release- Unapproved: designate (lunar-proposed/main) [1:16.0.0-0ubuntu1 => 1:16.0.1-0ubuntu1] (openstack)
[14:54] -queuebot:#ubuntu-release- Unapproved: horizon (lunar-proposed/main) [4:23.1.0-0ubuntu1 => 4:23.2.0-0ubuntu1] (openstack)
[14:54] -queuebot:#ubuntu-release- Unapproved: neutron (lunar-proposed/main) [2:22.0.1-0ubuntu1 => 2:22.0.2-0ubuntu1] (openstack)
[15:21] <dbungert> paride: looks like http://iso.qa.ubuntu.com/qatracker/milestones/447/builds is missing the tests cases at this point, is that expected?
[15:30] <LocutusOfBorg> if any ubuntu-archive can drop opm-material/opm-models/opm-simulators/opm-upscaling out from release, we can have an opm migration (something is merged inside opm, and they are going to be out from debian testing in one week or so)
[15:35] <paride> dbungert, yes -- I hope. I created the milestone a few minutes ago, and still need to add the cases
[15:38] <LocutusOfBorg> (opm-material is now merged inside opm-common)
[15:38] <LocutusOfBorg> (see #1037809)
[15:53] <ginggs> that's an interesting way to get a package removed in Debian
[15:55] -queuebot:#ubuntu-release- Builds: Kubuntu Desktop amd64 [Jammy 22.04.3] (20230807.1) has been added
[15:57] -queuebot:#ubuntu-release- Builds: Lubuntu Desktop amd64 [Jammy 22.04.3] (20230807) has been added
[15:58] -queuebot:#ubuntu-release- Builds: Ubuntu Budgie Desktop amd64 [Jammy 22.04.3] (20230807) has been added
[15:59] <LocutusOfBorg> don't shoot the messenger :D
[16:01] -queuebot:#ubuntu-release- Builds: Xubuntu Desktop amd64 [Jammy 22.04.3] (20230807.1) has been added
[16:03] -queuebot:#ubuntu-release- Builds: Ubuntu MATE Desktop amd64 [Jammy 22.04.3] (20230807.1) has been added
[16:03] -queuebot:#ubuntu-release- Builds: Ubuntu Kylin Desktop amd64 [Jammy 22.04.3] (20230807) has been added
[16:04] -queuebot:#ubuntu-release- Builds: Ubuntu Studio DVD amd64 [Jammy 22.04.3] (20230807) has been added
[16:37] -queuebot:#ubuntu-release- Unapproved: phpmyadmin (jammy-proposed/universe) [4:5.1.1+dfsg1-5ubuntu1 => 4:5.1.1+dfsg1-5ubuntu1.1] (no packageset)
[16:38] <paride> bdmurray, so apparently entries under the milestone appear as images are created
[16:38] <paride> oops
[16:38] <paride> dbungert, ^^
[16:46] -queuebot:#ubuntu-release- Unapproved: horizon (lunar-proposed/main) [4:23.1.0-0ubuntu1 => 4:23.2.0-0ubuntu1] (openstack)
[16:50] -queuebot:#ubuntu-release- Builds: Ubuntu Desktop arm64+raspi [Jammy 22.04.3] (20230807.1) has been added
[17:01] -queuebot:#ubuntu-release- Builds: Ubuntu Base amd64 [Jammy 22.04.3] (20230807.1) has been added
[17:01] -queuebot:#ubuntu-release- Builds: Ubuntu Base arm64 [Jammy 22.04.3] (20230807.1) has been added
[17:01] -queuebot:#ubuntu-release- Builds: Ubuntu Base armhf [Jammy 22.04.3] (20230807.1) has been added
[17:01] -queuebot:#ubuntu-release- Builds: Ubuntu Base ppc64el [Jammy 22.04.3] (20230807.1) has been added
[17:01] -queuebot:#ubuntu-release- Builds: Ubuntu Base riscv64 [Jammy 22.04.3] (20230807.1) has been added
[17:02] -queuebot:#ubuntu-release- Builds: Ubuntu Base s390x [Jammy 22.04.3] (20230807.1) has been added
[17:09] -queuebot:#ubuntu-release- Unapproved: horizon (jammy-proposed/main) [4:22.1.0-0ubuntu2.1 => 4:22.1.1-0ubuntu1] (openstack)
[17:44] <LocutusOfBorg> I canceled llvm-toolchain-16 on amd64
[17:45] <LocutusOfBorg> please don't reschedule until riscv64 is built :)
[17:57] -queuebot:#ubuntu-release- Unapproved: manila (jammy-proposed/universe) [1:14.1.0-0ubuntu1 => 1:14.1.1-0ubuntu1] (openstack)
[17:57] -queuebot:#ubuntu-release- Unapproved: octavia (jammy-proposed/universe) [1:10.0.0-0ubuntu1 => 1:10.1.0-0ubuntu1] (openstack)
[17:58] -queuebot:#ubuntu-release- Unapproved: designate (jammy-proposed/main) [1:14.0.2-0ubuntu1 => 1:14.0.3-0ubuntu1] (openstack)
[17:58] -queuebot:#ubuntu-release- Unapproved: neutron (jammy-proposed/main) [2:20.3.1-0ubuntu1 => 2:20.4.0-0ubuntu1] (openstack)
[18:12] -queuebot:#ubuntu-release- Unapproved: python-oslo.privsep (focal-proposed/main) [2.1.1-0ubuntu1 => 2.1.1-0ubuntu2] (ubuntu-server)
[18:13] -queuebot:#ubuntu-release- Unapproved: python-oslo.privsep (jammy-proposed/main) [2.7.0-0ubuntu1 => 2.7.0-0ubuntu2] (openstack)
[18:40] <Eickmeyer> So uh... can somebody fill me in on the need to seed the cups snap since it just got removed when I updated the seeds for Studio?
[18:46] <Eickmeyer> Er, maybe I just need to seed cups as a recommends now.
[18:46] <Eickmeyer> Or, maybe somebody can fill me in on the best course of action here.
[18:56] -queuebot:#ubuntu-release- Builds: Ubuntu Server arm64+raspi [Jammy 22.04.3] (20230807.2) has been added
[18:56] -queuebot:#ubuntu-release- Builds: Ubuntu Server armhf+raspi [Jammy 22.04.3] (20230807.2) has been added
[18:56] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+icicle [Jammy 22.04.3] (20230807.2) has been added
[18:56] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+licheerv [Jammy 22.04.3] (20230807.2) has been added
[18:57] -queuebot:#ubuntu-release- Builds: Ubuntu Server riscv64+visionfive [Jammy 22.04.3] (20230807.2) has been added
[19:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity amd64 [Jammy 22.04.3] (20230807.1) has been added
[19:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity arm64 [Jammy 22.04.3] (20230807.1) has been added
[19:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity ppc64el [Jammy 22.04.3] (20230807.1) has been added
[19:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity riscv64 [Jammy 22.04.3] (20230807.1) has been added
[19:36] -queuebot:#ubuntu-release- Builds: Ubuntu Server Subiquity s390x [Jammy 22.04.3] (20230807.1) has been added
[23:13] -queuebot:#ubuntu-release- New binary: in-n-out [amd64] (mantic-proposed/none) [0.1.8-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: docstring-parser [amd64] (mantic-proposed/none) [0.15-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: r-cran-locfdr [amd64] (mantic-proposed/none) [1.1-8-1] (no packageset)
[23:14] -queuebot:#ubuntu-release- New binary: napari-plugin-engine [amd64] (mantic-proposed/none) [0.2.0-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: nabu [amd64] (mantic-proposed/none) [2023.1.1-2] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: psygnal [amd64] (mantic-proposed/none) [0.9.1-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: ppft [amd64] (mantic-proposed/none) [<IP_ADDRESS>+dfsg-1] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: python-covdefaults [amd64] (mantic-proposed/none) [2.3.0-1] (no packageset)


[19:39] <charlie-tca> mr_pouit: We now have the ubuntu slide show in the installation, instead of Xubuntu slide show
[19:40] <charlie-tca> oops
[19:40] <charlie-tca> maybe not, mr_pouit
[19:40] <charlie-tca> seems that slideshow is for the release notes
[20:13] <charlie-tca> our desktop images both fail to install today


[17:29] <aerostasis> I borked my 3-day-old Ubuntu desktop after tweaking the Nvidia xServer settings. I was hoping resetting the gnome desktop settings would fix the problem, but I ran 'dconf reset -f /' a few minutes ago and my desktop still won't allow me to launch a terminal session. What do?
[17:30] <aerostasis> The syslog has several periodically recurring messages from gpowertop saying it tried to run statvfs and permission was denied
[17:32] <aerostasis> I don't know if related, but my guess is this is a little more serious than just a desktop configuration error. Is my best bet to reinstall?


[12:32] <SaiHarshaK> hello, is there a guide for contributors? i only found one for documentation
[14:46] <roaksoax> i'll let you/win 2


[00:02] <micahg> yofel: you want to lino the link to the LP page or wiki page?
[00:05] <yofel> micahg: well, I'm currently linking to the LP page, that's simply https://launchpad.net/~<username> . Not all users have a wiki page and there isn't a default name for it
[00:07] <micahg> yofel: k, I guess that works better actually
[00:19] <penguin42> I *really* wish launchpad wouldn't lose the whole damn report when it timed out
[00:21] <micahg> penguin42: there's a bug open for it
[00:21] <penguin42> ah that's ok :-)
[00:21] <blankthemuffin> Hello, I've got a few bugs to report but not sure what to file them against. The first one being when you have automatic login enabled, the system boots and after everything has loaded it asks for a password. This dialogue blocks the screen lock, so. If I turn on my computer and leave it for a few minutes, I come back and there is just the ordinary password dialogue. But as soon as I put in my password the screen lock
[00:21] <blankthemuffin>  gets the freedom it was after and instantly locks the screen. Meaning I have to enter my password again.
[00:22]  * penguin42 is trying to figure out why the server vm he's updated to maverick isn't doing iscsi serving
[00:24] <penguin42> and wireshark doesn't want to play ball :-(
[00:32] <blankthemuffin> my second problem is that as soon as my battery hits the critical level, I get spammed with 'the system is about to hibernate' notices, and half the time even if I plug in it still powers down about a minute later. There is no timer or way to cancel, and it totally ignores the power status. when it starts to perform the actual hibernate. Also on occasion these build up so much that after plugging in and resuming, it s
[00:32] <blankthemuffin> till has all the warnings and proceeds to almost immediately hibernate again, this happens up to about 5 times in a row which usually means it's much easier just to force a power off and start again.
[00:36] <penguin42> blankthemuffin: I've seen a bug somewhere - maybe ubuntu, maybe fedora bug lists - about how once it's decided it's going to go and even if you throw power in it still hibernates
[00:37] <yofel> sounds like a g-p-m bug
[00:48] <penguin42> hi, any bug swauders want to look at #604087 - I'm seeing this and I think it's a fairly important regression for server
[00:48] <penguin42> q
[00:48] <penguin42> bug 604087
[00:48] <ubot2> Launchpad bug 604087 in iscsitarget (Ubuntu) "iscsitarget fails with can't create a target 2 0 (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/604087
[01:55] <stlsaint> vish: ping
[01:59] <stlsaint> ddecator: ping
[02:03] <stlsaint> anyone now the link on lp to start assigning bugs
 anyone now the link on lp to start assigning bugs  -- what are you wanting to assign bugs to mate?
[02:30] <stlsaint> kermiac: i dont know, vish gave me a linky yesterday that took me to a bunch of unassinged bugs and told me i could have at it on lp
[02:30] <kermiac> stlsaint: was it the first link on this page mate?  https://wiki.ubuntu.com/Bugs/EasyTasks
[02:31]  * micahg does not consider bugs w/out a package an easy task
[02:32]  * kermiac shrugs
[02:33] <kermiac> https://wiki.ubuntu.com/Bugs/FindRightPackage makes it somewhat easy, but the difficulty varies I suppose
[02:34] <micahg> kermiac: I guess
[02:37] <kermiac> micahg: some can be almost blatantly obvious if you follow that wiki page, but I do agree that sometimes it can really be a struggle to find which package is causing the issue.
[02:38] <kermiac> stlsaint: was that the link you were after mate?
[02:39] <stlsaint> kermiac: naw
[02:40] <stlsaint> kermiac: it was this one: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-datecreated&search=Search&field.status:list=NEW&field.importance:list=UNKNOWN&field.importance:list=UNDECIDED&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch
[02:40] <stlsaint> maybe i should have made that a tiny url eh?! :D
[02:40] <stlsaint> kermiac: http://tiny.cc/s36xt
[02:41] <stlsaint> hey i was just thinking, for this whole package ordeal
[02:42] <stlsaint> has anyone tried lfs?
[02:42] <yofel> what's that
[02:42] <kermiac> stlsaint: ah, that has a cpl hundred more reports than the one linked on the "easy tasks" page
[02:44] <stlsaint> yofel: linux from scratch
[02:44] <stlsaint> kermiac: whos the bug wiki editor person?
[02:45] <kermiac> stlsaint: I think anyone should have access to edit the bugsquad wikis
[02:45] <stlsaint> orly? >:)
[02:45] <kermiac> stlsaint: why, what's up mate?
[02:45] <yofel> stlsaint: the most I came close to that was installing gentoo...
[02:46] <stlsaint> yofel: aye, just something on my projects list ;)
[02:47] <stlsaint> kermiac: i was thinking, you guys could add a list of packages and what they do for a base install of ubuntu as listed here: http://www.linuxfromscratch.org/lfs/view/stable/prologue/package-choices.html
[02:48] <stlsaint> kermiac: maybe that can narrow down some of the package searching
[02:49] <kermiac> stlsaint: That would probably be best sent to the ML to ask for opinions
[02:50] <kermiac> stlsaint: 'apt-cache show PKGNAME' somewhat helps with that issue
[02:52] <stlsaint> kermiac: true but you must know the name of the package for that command
[02:53] <stlsaint> kermiac: also does the mailing list post *every* single bug transcation that happens on lp?
[02:53] <kermiac> stlsaint: yup, that can make it difficult hehe
[02:54] <kermiac> stlsaint: not the bugsquad or bugcontrol lists. They are for bug related discussions.
[02:54] <kermiac> stlsaint: I think there is a ml for all ubuntu-related bugs, but I haven't subscribed to it.
[02:55] <hggdh> yes, ubuntu-bugs
[02:55] <stlsaint> kermiac: exactly so a list easily accessible that shows what the package handles can steer people in a better direction for getting bugs to packages :D
[02:55] <stlsaint> kermiac: is there a mailing list just for discussion and not ALL bug transactions
[02:55] <hggdh> and apt-file search <something> will list all packages that deploy <something>
[02:56] <kermiac> stlsaint: yes, bugsquad/ control lists are for discussion. Sorry if i wasn't clear (doing 50 things at once hehe)
[03:02] <stlsaint> hggdh: apt-file?
[03:03] <stlsaint> you sure about that?
[03:03] <stlsaint> hggdh: i use aptitude search <name> if thats what your referring to
[03:04] <stlsaint> hggdh: but most bugs that arent assinged dont put the needed name such as: dbconf
[03:04] <stlsaint> so you cant just use: aptitude search dbconf
[03:04] <stlsaint> hggdh: catch my drift ;)
[03:05] <micahg> stlsaint: apt-file searches the files in the .debs, aptitude search searches the descriptions
[03:06] <stlsaint> micahg: is this what you and hggdh are referring to?
[03:06] <stlsaint> stlsaint@stlsaint-laptop:~$ apt-file --help
[03:06] <stlsaint> The program 'apt-file' is currently not installed.  You can install it by typing:
[03:06] <stlsaint> sudo apt-get install apt-file
[03:07] <micahg> stlsaint: yes, it's a cache of all the filepaths in the archive
[03:07] <stlsaint> micahg: gotcha
[03:08] <stlsaint> micahg: sucks it has to be installed though as most users probably arent tracking that, but im slow and you guys prolly have it in a wiki somewhere
[03:08] <micahg> stlsaint: it's not for regular users
[03:09] <stlsaint> micahg: i see, but isnt package assinging something that even a person who isnt a bug squad member can do
[03:09] <stlsaint> micahg: IE: a regular user
[03:09] <micahg> stlsaint: sure, but it's not required software
[03:09] <stlsaint> im a regular user yet i want to join bug squad and i didnt know that about apt-file
[03:10] <stlsaint> micahg: aye
[03:10] <micahg> stlsaint: no, I meant most people probably don't need it
[03:11] <stlsaint> micahg: aye, but this is why i suggested a list be added to wiki that shows the base packages for ubuntu and what they do. That way a user who doesnt know about apt-file can easily see what these packages do and can assign bugs to them more effectively
[03:11] <micahg> stlsaint: that list would be pretty long
[03:13] <stlsaint> micahg: meh, not too long as to be useless, just something of this nature: http://www.linuxfromscratch.org/lfs/view/stable/prologue/package-choices.html
[03:13] <stlsaint> micahg: a base package list of ubuntu
[03:14] <micahg> stlsaint: most bugs aren't in those packages
[03:14] <micahg> stlsaint: and the find the right package wiki page is much more useful IMHO
[03:21] <stlsaint> i may need to read into more than
[03:23] <stlsaint> micahg: indeed that wiki page is very nice
[03:28] <stlsaint> micahg: success, you guys did have apt-file in wiki! takes a little reading i see
[04:13] <stanley_robertso> hi all
[04:45] <stanley_robertso> hggdh, you there ?
[04:50] <micahg> stanley_robertso: can I help with something?
[05:00] <nigelb> ah,I have mail to send to bugsquad list
[05:04]  * nigelb hits the big red button
[05:06] <kermiac> not the big red button!!! :P
[05:08] <nigelb> haha
[05:08] <nigelb> ok, as usual, sent from wrong ID
[05:08] <nigelb> resent again :)
[05:09] <micahg> nigelb: I think you're about 10 hrs late
[05:10] <nigelb> micahg: how come?
[05:10] <micahg> nigelb: unless you mean next week?
[05:10] <nigelb> I mean next week
[05:10] <micahg> nigelb: k
[05:10] <nigelb> gah, I said "this thursday" - fail!
[07:01] <drew212> =( not a whole lot of people worked on this hugday
[07:20] <trinikrono> maybe too many scary seg faults lol drew212
[07:21] <drew212> seg fault? lol, whats scary about them?
[07:21] <drew212> alot of seg faults the people don't explain their issue, so its easy to begin work... lol
[07:21] <trinikrono> lol
[07:22] <trinikrono> have you got reporters to do backtraces?
[07:22] <trinikrono> thats what the pidgin developers are asking for
[07:22] <kermiac> can anyone remember where the info is on creating alternate "bug names"? I remember reading something about it ages ago but can't find the page again
[07:23] <micahg> kermiac: ?
[07:23] <kermiac> ok, i don't remember the exact name of what it was called, but instead of referring to a bug number, you could refer to a bug by a name
[07:24] <trinikrono> o.o
[07:25] <kermiac> i remember seeing it mentioned somewhere probably about a year ago, but i just got asked about it. IIRC there were "names" for (in)famous bugs
[07:25]  * micahg knows that's a feature in bugzilla, but hasn't seen it in LP
[07:26] <kermiac> hmm... maybe i was getting it confuzed with the bugzilla feature. I only half remember reading something about it very briefly a *long* time ago
[07:27] <kermiac> s/confuzed/confused
[07:58] <nigelb> kermiac: I think it might be in LP api docs, don't remember
[07:58] <nigelb> ask wgrant, he may know
[07:58] <kermiac> ok, thanks nigelb :)
[07:59] <kermiac> wgrant: are you around mate?
[07:59] <nigelb> just fyi though, all LP people are in prague hacking on LP, not many would be around on #launchpad ;)
[07:59] <thekorn> good morning, vish et. al. I'm so sorry I missed the last meeting, and reporting about my mentees, will write a report to the ML thread during lunch break later today
[08:00] <vish> thekorn: sweet! thanks.
[08:13] <wgrant> kermiac: Bug nicknames are deprecated.
[08:13] <wgrant> There is no longer a supported way to set them.
[08:13] <kermiac> ok, thanks for the info wgrant
[08:37] <vish> alrighty , this is what we need to do about bugs > http://www.youtube.com/watch?v=oraONu7Jp_Y
[08:37] <vish> as they keep coming in!
[13:07] <yofel> om26er: about bug 601686, what is the patch for exactly? It's already fixed upstream (It won't make it in time?)
[13:07] <ubot2> Launchpad bug 601686 in telepathy-haze (Ubuntu) (and 1 other project) "tp-haze: contacts are removed upon deleting the group from contact list. (affects: 1) (heat: 8)" [Medium,Fix committed] https://launchpad.net/bugs/601686
[13:07] <om26er> yofel, if you delete a contacts group it removes those contacts too. poof!
[13:08] <om26er> fixed upstream and they recommend it for a stable release
[13:08] <om26er> *update
[13:10] <yofel> k, meaning we need to fix that in maverick soon so we can get to the SRU
[13:10] <yofel> before the upstream release makes it to maverick
[13:11] <seb128> you don't need to fix in maverick before
[13:11] <seb128> you can do the sru directly
[13:14] <om26er> latest version of haze only contained the fix for bug 601686. and I dont see it in debian unstable so I guess will take time for Maverick
[13:14] <ubot2> Launchpad bug 601686 in telepathy-haze (Ubuntu) (and 1 other project) "tp-haze: contacts are removed upon deleting the group from contact list. (affects: 1) (heat: 292)" [Medium,Fix committed] https://launchpad.net/bugs/601686
[13:15] <seb128> you can still try to ask on #telepathy when they plan to update it in debian
[13:19] <stanley_robertso> hi all
[13:21]  * penguin42 is wondering if there are any other bugs similar to bug 605829 - it seems too noticeable a bug to only be affecting me and one other on maverick
[13:21] <ubot2> Launchpad bug 605829 in metacity (Ubuntu) "metacity causing Xorg to hammer the CPU with a focus-request having timestamp of 0 (affects: 2) (heat: 12)" [Medium,Confirmed] https://launchpad.net/bugs/605829
[13:22] <om26er> its good you are not alone ;)
[13:23] <stanley_robertso> hi all
[13:23] <penguin42> om26er: Indeed!
[13:23] <abhijit> hello stanley_robertso
[13:23] <stanley_robertso> hi abhijit
[13:23] <abhijit> stanley_robertso, whatsup?
[13:24] <stanley_robertso> do bug squad team organize regular meetings like other groups do ?
[13:24] <abhijit> stanley_robertso, yes
[13:25] <yofel> yes, every second tuesday of the month at 17:00 UTC
[13:25] <stanley_robertso> ohh cool.. thanks yofe
[13:25] <stanley_robertso> *yofel,
[13:25] <yofel> er, at the second tuesday of a month..
[13:25] <abhijit> !tab | stanley_robertso
[13:25] <ubot2> stanley_robertso: You can use your <tab> key for autocompletion of nicknames in IRC, as well as for completion of filenames and programs on the command line.
[13:25] <yofel> not every second..
[13:25] <abhijit> yofel, :D :D lol
[13:25] <stanley_robertso> ok
[13:25] <yofel> meaning the last was 3 days ago
[13:26] <abhijit> I wll save this log its a good joke yofel :D
[13:26] <stanley_robertso> oh is it ? then i missed it ... as iam in process of my membership .. hehehe
[13:26] <yofel> :P
[13:26] <yofel> let me find the log..
[13:27] <yofel> stanley_robertso: http://irclogs.ubuntu.com/2010/07/13/%23ubuntu-bugs.html#t17:59
[13:30] <stanley_robertso> thanks yofel
[13:31] <stanley_robertso> do we have any videos.. depicting the work process of bug squad ?
[13:33] <abhijit> stanley_robertso, we have flowcharts to understand how to triage bugs
[13:33] <stanley_robertso> abhijit, thatz cool.. do you have the direct link handy ? if so.. can you share it here
[13:34] <abhijit> stanley_robertso, wiat
[13:34] <abhijit> stanley_robertso, https://wiki.ubuntu.com/Bugs/HowToTriage/Charts
[13:34] <stanley_robertso> thanks dude
[13:35] <abhijit> stanley_robertso, this is triage guide: https://wiki.ubuntu.com/Bugs/HowToTriage/ and
[13:35] <abhijit> this is main page of bugsquad team https://wiki.ubuntu.com/BugSquad
[13:36] <stanley_robertso> abhijit, i went through this flow chart yesterday :) .. thought some additional stuff might be helpful.
[13:36] <stanley_robertso> anyhow.. i will bookmark this link.. thanks :)
[13:36] <abhijit> stanley_robertso, ok
[13:52] <stanley_robertso> let me try.. in vbox channel ...  be right back :)
[14:56] <stanley_robertso> hi all
[15:54] <dyfet> I need https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/601420 marked as triaged, and also I think https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/600745 and https://bugs.launchpad.net/ubuntu/+source/omniorb4/+bug/600723
[15:54] <ubot2> Launchpad bug 601420 in empathy (Ubuntu) "empathy cannot connect to my SIP server (affects: 1) (heat: 8)" [Undecided,Confirmed]
[15:58] <charlie-tca> What importance on the empathy bug?
[16:00] <om26er> medium would do It.
[16:01] <om26er> but thats internal ;)
[16:01] <charlie-tca> dyfet: empathy bug is done
[16:02] <charlie-tca> dyfet: update-notifier is done, triaged, low
[16:02] <charlie-tca> Sorry, I don't do packaging bugs
[16:05] <dyfet> charlie-tca: thanks!
[16:05] <charlie-tca> no problem
[16:09] <dyfet> charlie-tca oh, and 604185 is on my list for triage, though that one may end up becoming a cannot-fix based depending how the upstart maintainer sees it, but there is enough info to understand why its broken :)
[16:10] <charlie-tca> bug 604185
[16:10] <ubot2> Launchpad bug 604185 in vsftpd (Ubuntu) "Unable to start vsftpd with upstart if private key (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/604185
[16:10] <dyfet> yes
[16:10] <charlie-tca> let me look at it, then
[16:12] <charlie-tca> Okay, that bug is triaged, medium.
[16:12] <charlie-tca> Thanks for helping.
[16:12] <greg-g> thanks dyfet :)
[16:13] <greg-g> dyfet: and sorry again about last night
[16:13] <dyfet> Well, the SIP one I of course understand very well
[16:13] <dyfet> greg-g no problem at all
[16:13] <dyfet> I just feel bad for the other candidates that did not get a chance at all
[16:14] <greg-g> yeah :/ we were a little disappointed as well. That's why we are having a make up in 1 week.
[16:27] <dholbach> Last day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 33 minutes in #ubuntu-classroom
[17:22] <njin> someone can notice me why there's no builds today ?
[17:23] <micahg> njin: ?
[17:23] <njin> there's no downloadable images on cdimage.ubuntu.com
[17:26] <charlie-tca> Download the current instead of the date
[17:26] <charlie-tca> It will be from the 14th. I think the kernel is giving problems again
[17:28] <njin> charlie-tca: thanks, i have to test Xubuntu but there isn't, i'll test tomorrow :(
[17:29] <charlie-tca> xubuntu for the 14th, desktop image installs
[17:29] <charlie-tca> It will be in current, which is the most up-to-date available today
[17:34] <njin> charlie-tca: no, there's no image in current . There's no image to test, there's no pedro_  that mentoring me, i'm disperate, what i can do :(
[17:34] <charlie-tca> Just a minute, let me see
[17:36] <charlie-tca> I think you will have to do a different bug. The only images available are the Ubuntu Desktop images, and they may not work. Even the server images are broken today.
[17:38] <njin> Ok, i will go to translate then
[17:39] <charlie-tca> Maybe we will have images tomorrow.
[17:40] <njin> I hope, i'm waiting for pedro_, do you know at wath time generally it cames ?
[17:41] <njin> *comes
[17:41] <njin> *he comes
[17:41] <Darxus> There's a fix for #541492.  It involves 5 source packages (one of which is linux).  What needs to be done to get them in Maverick?
[17:41] <hggdh> njin: usually Pedro should already be here at this time
[17:43] <Darxus> Bug 541492
[17:43] <ubot2> Launchpad bug 541492 in xserver-xorg-video-intel (Ubuntu Lucid) (and 2 other projects) "MASTER: [i845] GPU lockup (apport-crash) (Should KMS be blacklisted?) (affects: 77) (dups: 30) (heat: 523)" [High,Triaged] https://launchpad.net/bugs/541492
[17:43] <njin> hggdh: thanks
[17:46] <yofel> Darxus: you should ask in #ubuntu-x
[17:48] <yofel> someone got an idea what the 'Connect to server' app is supposed to be? bug 606357
[17:48] <ubot2> Launchpad bug 606357 in ubuntu "connect to server (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/606357
[17:51] <yofel> or does he mean that odd entry that had something to do with nautilus..
[17:51] <charlie-tca> Ask for more information from the reporter. You need to know what he really means, and what application "connect to server" is in
[17:51] <charlie-tca> Also, what version of Ubuntu/Kubuntu/Xubuntu?
[17:52] <dyfet> If it is gnome, it is perhaps from places and part of nautilus
[17:52] <charlie-tca> but if it is xubuntu, it is gigolo
[17:53] <dyfet> And I think he is speaking of what could be called a feature enhancement
[17:56] <charlie-tca> again, more information is needed from the reporter
[18:01] <Darxus> yofel: Thanks.
[18:02] <yofel> Darxus: np
[18:02] <yofel> thx for the suggestions, didn't know xubuntu has a different one
[18:07] <charlie-tca> You are welcome
[18:15] <njin> what can i do with old bug 360908 ?
[18:15] <ubot2> Launchpad bug 360908 in ubuntu "kashmiri language keyboard input for arabic script not available (heat: 6)" [Undecided,New] https://launchpad.net/bugs/360908
[18:20] <njin> Mark as invalid, excusing for the delay of response,asking him if it contact someone ?
[18:21] <hggdh> njin: ideally, you should be able to check if it is now available...
[18:22] <njin> ok, i go to language selector and control if available
[18:25] <njin> hggdh: is available, then i mark Fix released
[18:29] <hggdh> njin: yes, thank you
[18:31] <njin> hggdh: i'm lucky, i've multiple mentors ;-)
[18:32] <hggdh> :-)
[18:32] <hggdh> njin: any one of us will help
[18:32] <njin> Is a beautiful group
[18:35] <drew212> micahg: how do i figure out what flash is usable in a certain distro of ubuntu?
[18:36] <drew212> micahg: because i can search for each type of flash using rmadison, but there has to be an easier way...
[18:36] <micahg> drew212: they should all be usable, just not necessarily together :)
[18:36] <drew212> micahg: so what would be the command to install flash to hardy?
[18:36] <micahg> drew212: well, depends if people use partner or not
[18:37] <drew212> what is partner?
[18:37] <micahg> drew212: for flash 9, apt-get install flashplugin-nonfree, for flash 10, apt-get install adobe-flashplugin if partner archvie is enabled
[18:37] <drew212> what would you reccomend for bug 602951?
[18:37] <ubot2> Launchpad bug 602951 in firefox-3.0 (Ubuntu) "flash player needed but won't apply to computer (affects: 1) (heat: 460)" [Undecided,Incomplete] https://launchpad.net/bugs/602951
[18:43] <micahg> drew212: well, if the user would've posted teh results, I could tell you :P
[18:44] <micahg> drew212: anyways, I'd suggest installing adobe-flashplugin on hardy
[18:44] <penguin42> hmm, that explains why it was so quiet - something dropped me about 20 mins ago
[18:45] <drew212> micahg: he said that the output said he didn't have any flash plugin installed, would it have said something else that was usefull?
[18:45] <micahg> drew212: yes, if partner is enabled :)
[18:45] <micahg> drew212: by ways of showing the policy of adobe-flashplugin
[18:45] <drew212> should i ask him the output?
[18:46] <micahg> drew212: nah, just suggest installing adobe-flashplugin, if he complains, then say flashplugin-nonfree
[18:49] <drew212> micahg: i feel like we need to educate him on how to copy and paste =P
[21:04] <thekorn> bug 592599
[21:04] <ubot2> Launchpad bug 592599 in zeitgeist (and 1 other project) "Hard to use exclusive queries (affects: 1) (heat: 8)" [Medium,In progress] https://launchpad.net/bugs/592599
[21:04] <dyfet> I think https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/603283 is ready for triage status
[21:04] <ubot2> Launchpad bug 603283 in shadow (Ubuntu) "useradd doesn't create /home/user_name directory (affects: 1) (dups: 1) (heat: 540)" [Undecided,New]
[21:04] <dyfet> oops. I see it is a dup...
[21:05] <dyfet> But I think the new one and the comments are correct
[21:06] <dyfet> (or at least my notes for the maintainer are...)
[21:10] <yofel> dyfet: I'm not sure if useradd is even supposed to do that, we have adduser for that
[21:11] <dyfet> yofel: Well, I simply noted that the behavior is correct per the debian changelogs
[21:12] <yofel> ah sry, I forgot to read your comment...
[21:12] <yofel> debian 39581
[21:12] <ubot2> Debian bug 39581 in passwd "useradd program" [Normal,Open] http://bugs.debian.org/39581
[21:12] <dyfet> and hence specific debian bugs that can be referenced as to why it was done that way...
[21:12] <dyfet> yes, exactly
[21:14] <yofel> uh... very descriptive way to close a bug "Bug closed, ack sent to submitter - they'd better know why !"
[21:15] <dyfet> lol
[21:16] <dyfet> so we don't know why they did it, either :)
[21:17] <dyfet> But we do know that it was done
[21:26] <dyfet> https://bugs.launchpad.net/ubuntu/+source/apcupsd/+bug/602978 may be ready to mark, too, though it too is an odd one :)
[21:26] <ubot2> Launchpad bug 602978 in apcupsd (Ubuntu) "failure to kill UPS power over snmp/pcnet connection (affects: 1) (heat: 539)" [Undecided,New]
[22:46] <atrus> any idea why bug #229945 is marked invalid?
[22:46] <ubot2> Launchpad bug 229945 in network-manager (Ubuntu) (and 1 other project) "wi-fi does not automatically come on during boot up (affects: 1) (dups: 2) (heat: 23)" [Undecided,Confirmed] https://launchpad.net/bugs/229945
[22:46] <atrus> oh.. that's for the upstream task. disregard.
[22:51] <yofel> the upstream bug expired, as the asked for information and it was never provided
[22:51] <yofel> *as they
[23:27] <maxwellian> What do we do with bugs that were files against a package that has become a virtual package to transition to a new name?
[23:27] <maxwellian> filed*
[23:27] <maxwellian> e.g. bug 42622
[23:27] <ubot2> Launchpad bug 42622 in gnome-app-install (Ubuntu) (and 1 other project) "Missing .desktop file (heat: 4)" [Medium,Invalid] https://launchpad.net/bugs/42622
[23:28] <maxwellian> That was filed against drscheme, which is now a dummy package.
[23:36] <yofel> maxwellian: I would set that bug back to fix released and ask the reporter to file a new bug agianst plt-scheme
[23:37] <maxwellian> yofel: Okay, thanks.
[23:37] <yofel> that plt-scheme doesn't have a desktop file has nothing to do with the drscheme package
[23:39] <yofel> I wonder if we can get rid of the transitional package in maverick
[23:39] <maxwellian> yofel: The previous patches seemed to apply to the drscheme package.  You're saying that's changed now, right?
[23:41] <yofel> yes, /usr/bin/drscheme is now part of plt-scheme, the desktop file might still apply though
[23:42] <yofel> actually you can link the new bug with debian 513390
[23:42] <ubot2> Debian bug 513390 in plt-scheme "include DrScheme menu item in package" [Wishlist,Open] http://bugs.debian.org/513390
[23:44] <yofel> *sigh* Date: Wed, 28 Jan 2009 16:33:01 UTC - the debian folks really aren't better at taking care of bugs than we are..
[23:44] <maxwellian> yofel: Well this might be a good candidate for my first bug fix attempt.
[23:45] <maxwellian> yofel: But yes, a lot of the "bitesize" bugs are old, and it seems unclear how to deal with them.
[23:46] <yofel> yeah, but as we just sync the package from debian, this *really* should be fixed there, maybe send the maintainer a mail, or ask in -motu (or -devel?) how to contact the debian folks
[23:47] <maxwellian> yofel: You know that we just sync it because there's no XubuntuX in the version, right?
[23:48] <yofel> yes
[23:48] <maxwellian> yofel: So is it okay to try to make a patch, then send the patch upstream?  Or just e-mail upstream without trying?
[23:50] <yofel> not sure, we'll have a session in -classroom next week (22.) on how to use the Debian BTS, I'm sure you'll find somebody who knows more about this than I do there
[23:51] <maxwellian> yofel: Great, thanks for your help! :)
[23:52] <yofel> you're welcome
[23:53]  * maxwellian high fives yofel o/\o


[05:11] <hikiko> hi
[07:30] <Trevinho> Good morning gents du bureau...
[07:57] <willcooke> happy Friday gang!
[07:58]  * willcooke checks
[07:58] <willcooke> yeah, Friday
[07:59] <hikiko|afk> heh
[07:59] <hikiko|afk> happy Friday willcooke and Trevinho and all
[07:59] <hikiko|afk> bbl
[08:11] <seb128> hey hikiko|afk willcooke Trevinho
[08:52] <andyrock> good morning
[09:05] <willcooke> morning andyrock
[09:05] <seb128> hey andyrock, happy friday! how are you?
[09:06] <andyrock> hey seb128 willcooke
[09:16] <seb128> happyaron, hey, can you help the submitter to test the patch on bug #1579246?
[09:17] <happyaron> seb128: sure
[09:17] <seb128> thanks
[09:17] <happyaron> seb128: but I'm confused cuz I can't reproduce it...
[09:17] <seb128> I think ppa or local build and adding a deb to the bug should work
[09:17] <happyaron> yep
[09:17] <seb128> do you have a 802.1x config?
[09:18] <happyaron> yes, I've set up a PEAP/MSCHAPv2+LDAP Wi-Fi at home to this it
[09:19] <seb128> unsure, maybe it has to do with specific options
[09:19] <happyaron> ok
[09:19] <seb128> do you have a file generated in your /etc/NetworkManager/system-connections/
[09:19] <seb128> does it look like the one in the bug description?
[09:21] <happyaron> seb128: I don't have a ca-cert field, cuz I'm using a letencrypt issued cert which is trusted by the system
[09:21] <seb128> that might be the difference who knows ... anyway we have reported wanted to test a patch so let's just do that ;-)
[09:22] <happyaron> ok
[09:22] <seb128> thanks!
[10:17] <cimi> seb128, hi seb, sorry to bother you for that :) I think that after updating recently my yakkety something doesn't work well with the keyring... it asks my ssh password in the terminal everytime I use bzr, you know how to fix those issues?
[10:27] <cimi> I solved running the keyring daemon in ~/.profile but that looks more like a workaround
[11:15] <ochosi> Trevinho: right, i guess i need to port over the unity theming i had in my theme before. forgot about the UnityDecoration stuff. thanks for the hint!
[11:15] <Trevinho> yw
[11:53] <seb128> cimi, try asking La_ney next week (he's on vac today), that has to do with systemd user session and he looked at those issues
[12:04] <Sweet5hark1> ricotz: urgh, seeing the sd_exports_test fail on 5.2.0/yakkety too now.
[12:05] <Sweet5hark1> seb128: ^^ so no weekend upload, as something updated in yakkety-proposed broke libreoffice this week (it build fine against -proposed last friday)
[12:05] <Sweet5hark1> :?
[12:05] <Sweet5hark1> :/
[12:10] <ochosi> Sweet5hark1: did you manage to resolve your theming issues yet?
[12:11] <seb128> Sweet5hark1, :-( do you have any idea what?
[12:11] <Sweet5hark1> ochosi: not against 5.2 unfortunately. what i did on libreoffice master didnt work there.
[12:12] <Sweet5hark1> seb128: nope, the test seems to be looping (see the session is being killed).
[12:13] <Sweet5hark1> seb128: two options: disable the test for now, care for it later. or do a local build and try to debug it before uploading.
[12:15] <Sweet5hark1> seb128: if I were a betting man, Id think some gcc or boost stuff caued the break. but thats just shooting into the dark right now.
[12:15] <seb128> try asking doko if he knows about any recent toolchain change that could impact you?
[12:15] <seb128> but better to fix than workaround
[12:15] <seb128> so yeah, probably better to debug...
[12:21] <Sweet5hark1> yeah, right now there isnt much info to throw at doko and I would understand a grumpy reply to "do you think there were changes that might have broken something" ;)
[12:25] <Sweet5hark1> OTOH this is possibly currently still broken in -proposed only and stopping the presses might prevent promoting something kaputt that causes trouble elsewhere to main ...
[12:25] <ricotz> Sweet5hark1, ok :\ -- btw, make sure to *fix* and double-check the versioned Conflicts/Replaces for libreoffice-impress
[12:26] <ricotz> and of course push your packaging changes to git
[12:28] <ricotz> Sweet5hark1, might be worth trying to build it with internal libixion/orcus
[12:28] <seb128> that would be a workaround even if it worked
[12:29] <ricotz> seb128, yes, until those libs are built against boost1.61
[12:29] <ricotz> but it would (nearly) exclude boost as a problem
[12:32] <Sweet5hark1> ricotz: what about renes libreoffice-impress C/Rs?
[12:33] <ricotz> they don't work with your ubuntu version
[12:43] <Sweet5hark1> ricotz: urgh, yeah. fixed and pushed.
[14:04] <Trevinho> tedg: in ci-train the systemd unit-tests fail...
[14:05] <Trevinho> tedg: see https://launchpadlibrarian.net/278558119/buildlog_ubuntu-yakkety-amd64.unity_7.5.0+16.10.20160812.1-0ubuntu1_BUILDING.txt.gz
[14:05] <Trevinho> [[14:05] <Trevinho> [  PASSED  ] 1637 tests.
[14:05] <Trevinho> [  FAILED  ] 2 tests, listed below:
[14:05] <Trevinho> [  FAILED  ] TestSystemdWrapper.Start
[14:05] <Trevinho> [  FAILED  ] TestSystemdWrapper.Stop
[14:05] <tedg> Trevinho: Uhg, okay. Let me see.
[14:05] <Trevinho> tedg: try to run make check-headless in a non-x session
[14:08] <tedg> Trevinho: Okay, spinning up the CPU fan :-)
[14:08] <Trevinho> tedg: it's always a great melody when it compiles unity7 :)
[14:09] <Trevinho> Mozart would be jealous
[14:55] <Sweet5hark1> aaahhh fridays. I just tried to install the daily image yakkety amd64 from today. the installer crashed :/
[14:58] <willcooke> :(
[15:07] <seb128> Sweet5hark1, cyphermox knows about it I think
[15:14] <cyphermox> yeah, I'm working on figuring out why
[15:15] <cyphermox> looks like something is now caring more about localization than it used to
[15:24] <doko> Sweet5hark1, seb128: when in doubt, blame glibc ;) (and if it just broke yesterday or today)
[15:25] <chrisccoulson> doko, can I blame all of my problems on glibc too?
[15:26] <doko> it's called glibc, not eliza
[15:26] <chrisccoulson> heh
[15:41] <tedg> Trevinho: The connection check broke the tests. I pushed a fix.
[15:41] <Trevinho> thanks
[15:42] <Trevinho> ah, yeah.. wait for it I guess would work
[16:01]  * Trevinho leaves for some running... Have nice weekend everyone!
[16:08] <Sweet5hark1> doko: yesterday/today sounds about right. ricotz reported breakage yesterday, i had a good build earlier in the week.
[16:10] <flocculant> cyphermox: just fyi - xubuntu installed ok here
[16:13] <infinity> Hey desktop people.
[16:13] <infinity> My laptop has become dangerously close to unusable since an upgrade and reboot yesterday, and I'm trying to sort out where to lay blame.
[16:14] <infinity> I get full-screen redraw flickers on window focus changes and sometimes just on keypress, and the frequency of that goes up and up until it's just flickering non-stop and needs a reboot to calm itself.
[16:15] <infinity> Trevinho, seb128, Laney:  ^--- Any ideas?
[16:15] <infinity> (And this was before I updated my local glibc, so the blame isn't on me :P)
[16:15] <Trevinho> mhmh
[16:15] <Trevinho> infinity: reverting unity/compiz changes anything for you?
[16:15] <seb128> infinity, xenial or yakkety?
[16:15] <infinity> seb128: Yakkety.
[16:16] <seb128> tried to boot an older kernel?
[16:16] <infinity> Trevinho: Maybe.  I haven't gotten to package level bisection yet, just decided to get angry and ask first, in case someone was aware of an issue and could talk me off the ledge. ;)
[16:16] <seb128> does it do it on the greeter?
[16:16] <seb128> but not known no
[16:16] <Trevinho> infinity: nothing known.. Something changed in rendering though, so..
[16:16] <infinity> seb128: Hard to say if it does it on the greeter, since it's very intermittent until it gets going.
[16:17] <seb128> when it gets going does a session restart fixes it?
[16:17] <infinity> Alright.  I'll get to reverting packages then, if no one has any current blame to pass around, and I'll get back to you.
[16:17] <seb128> or do you need a reboot?
[16:18] <infinity> seb128: Unsure, the last couple of times I just rebooted.  The reason I opted for the reboot was that even my VCs were doing the non-stop flickering once it was in that state.
[16:18] <seb128> sounds lower level than the desktop shell then
[16:18] <seb128> would blame the video driver/kernel
[16:18] <seb128> but that's just a guess ;-)
[16:19] <infinity> It certainly sounds mesa/drm/dri, but it could equally be something higher level started perturbing a previously un-tickled bug in the lower layers.
[16:20] <infinity> Anyhow, I'll play with package level reverts later today and see if I can nail down what package change caused it.
[16:20] <infinity> Which, indeed, might not be the package responsible for the bug, but might point at the bug.
[16:21] <infinity> Oh, the other (much less dire) bug I've seen since the mess of updates over the last week is a thin white line appearing on the right edge of any desktop after the first app is launched.
[16:21] <infinity> Not sure who to blame that on either. :P
[16:22] <infinity> (Also a bunch of GTK+ theme bugs, but I'm pretty sure I know who to blame those on)
[16:27] <seb128> hehe
[16:27] <seb128> the line could be unity or nautilus
[16:28] <seb128> Trevinho, ^ is that known?
[16:28] <infinity> I'd bet unity, based on it being tied to having a window on the desktop.    In testing that, I just noticed that the gnome-terminal unmaximize bug was fixed!
[16:30] <seb128> but yeah sounds likely to be unity
[16:30] <infinity> !!!
[16:30] <infinity> Yay!
[16:30] <infinity> Anyone know how/where that was fixed, so it can be SRUed to xenial?
[16:32] <seb128> Trevinho would know, but there was a fix SRUed to xenial a while ago, are you sure it's still an issue?
[16:33] <infinity> Oh, it was fixed in xenial according to the bug.
[16:33] <infinity> Huzzah.
[16:33] <infinity> seb128: Wasn't sure, since I don't run xenial, but I'll trust the bug state. :)
[16:33] <seb128> those italians are good ;-)
[16:34]  * Trevinho celebrates
[16:34] <Trevinho> anyway....
[16:34] <Trevinho> Which line? did I miss a screenshot?
[16:34] <cyphermox> flocculant: thanks but it's directly related to the language you used to install, too
[16:35] <cyphermox> ie those languages that delimit fractions with something other than a dot are affected
[16:35] <flocculant> cyphermox: that'd be why ubuntu worked as well then :p
[16:35] <cyphermox> yeah
[16:35] <cyphermox> there's an easy dumb fix I could apply but I think some other language could do things differently, I would rather really understand
[16:36] <cyphermox> but it looks like maybe I'll force LANG=C and be done with it
[16:36] <infinity> seb128: Oh, while I'm whining, and related to gnome-terminal, we've lose the "LP: #123456" right-click highlighting in gnome-terminal.
[16:36] <infinity> ubot5: NOT HELPFUL.
[16:36] <infinity> cyphermox: LANG=C.UTF-8 please.
[16:36] <seb128> infinity, try with Tre_vinho or La_ney
[16:37] <seb128> Trevinho, no screenshot that I know but I'm sure infinity can provide one
[16:37] <flocculant> cyphermox: while I have you're eye - what would I report against for (probably some gtk3 thing) with the installer?
[16:37] <Trevinho> seb128: ah, I read the description though... But I didn't notice that personally I think andrea fixed it
[16:38] <flocculant> cyphermox: don't know if you noticed but the 'skip' button isn't fixed at right side now - but wanders back and forwards depending on string length ...
[16:39] <infinity> Trevinho: http://lucifer.0c3.net/~adconrad/no-app-no-line.png http://lucifer.0c3.net/~adconrad/app-and-line.png
[16:39] <infinity> Trevinho: See the far right edge of the desktop.
[16:40] <Trevinho> ah, that one.. mh no...
[16:40] <Trevinho> never saw it
[16:41] <cyphermox> flocculant: not sure what you mean with the skip button... do you mean during the slideshow?
[16:42] <cyphermox> infinity: of course, it was just shorthand. if I say anything LC, expect a .UTF-8 tacked onto it, unless otherwise specified
[16:46] <flocculant> cyphermox: this button > http://imgur.com/T9Uz42l
[16:50] <ricotz> Sweet5hark1, I don't think the lo failure is caused by new glibc since it wasn't there when it first failed
[17:09] <willcooke> happy weekend all
[17:09] <willcooke> night
[20:51] <ahoneybun> anyone who works on the ubiquity installer?
[20:52] <ahoneybun> I'm trying to update the kde frontend to Qt5 since Qt4 dropped Webview
[20:54] <ahoneybun> I'm testing building it with debuild but I'm geting errors from wpa
[21:14] <jbicha> ahoneybun: building ubiquity? what's wpa?
[21:15] <ahoneybun> https://paste.kde.org/pogda6jrr
[21:15] <ahoneybun> since ubuntu pastebin is down
[21:15] <ahoneybun> error: this ‘if’ clause does not guard... [-Werror=misleading-indentation]
[21:16] <ahoneybun> that seems to be the mean issue


[07:41] <jackson> evening
[10:12] <rmg51> Morning
[13:09] <teddy-dbear> Morning peoples, dogs, hamsters and everything else
[13:31] <JonathanD> Morning.
[13:37] <teddy-dbear> o/
[15:25] <lazyPower> \o