[00:11] <robert_ancell> doko, yeah, I think I have a solution for that, was just waiting to see if upstream agreed http://lists.x.org/archives/xorg-devel/2015-September/047504.html
[04:04] <FourDollars> Who can help me to change the bugs status of https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095? Changing "Trusty" of "network-manager (Ubuntu)" to "In Progress".
[04:09] <TJ-> From Fix Released to In Progress ?
[04:10] <FourDollars> Yes
[04:10] <FourDollars> Because it is not fixed.
[04:14] <TJ-> Done
[04:14] <FourDollars> Can we still fix the bug for wily now?
[04:14] <FourDollars> TJ-: Thx.
[04:16] <FourDollars> I have a patch for libmbim (Ubuntu) wily. It is reviewed and approved but still no "Fix-Commited" for wily.
[04:16] <FourDollars> s/Commited/Committed/
[04:17] <TJ-> I think you need to ping one of the core devs responsible for getting it out. I suppose beta freeze might be affecting things
[04:19] <FourDollars> OK.
[06:31] <pitti> Good morning
[06:31] <FourDollars> Good morning
[06:32] <FourDollars> Could you help me to change the bug status of modemmanager (Ubuntu) Trusty of https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095 from "
[06:32] <FourDollars> Fix Released" to "In Progress"?
[06:38] <seb128> FourDollars, done
[06:39] <FourDollars> seb128: Thx
[06:39] <seb128> yw
[06:41] <FourDollars> seb128: There is still no bzr branch for trusty on https://code.launchpad.net/network-manager so I am going to attach the debdiif on https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095.
[06:41] <seb128> FourDollars, that makes sense
[06:42] <FourDollars> seb128: Could you help to release the libmbim for wily?
[06:42] <seb128> FourDollars, oh right, let me have a look
[06:42] <FourDollars> seb128: thx
[06:43] <seb128> yw!
[06:57] <FourDollars> seb128: Could you also help to review other patches for trusty?
[06:57] <seb128> FourDollars, depending on which components?
[06:58] <FourDollars> seb128: libmbim, network-manager and modemmanager.
[06:59] <seb128> FourDollars, n-m/modemmanager you probably want cyphermox
[06:59] <FourDollars> seb128: https://code.launchpad.net/~fourdollars/ubuntu/trusty/libmbim/1441095/+merge/273015, https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095/comments/56 and https://code.launchpad.net/~binli/ubuntu/trusty/modemmanager/lp1441095/+merge/272054.
[07:00] <FourDollars> seb128: OK
[07:03] <FourDollars> seb128: I think the trusty patches of libmbim and network-manager are pretty simple.
[07:06] <doko> mvo, https://launchpad.net/ubuntu/+source/ubuntu-snappy/1.6ubuntu1
[08:03] <doko> jamespage, designate (1:1.0.0~b3-0ubuntu1 to 1:1.0.0~rc1-0ubuntu1)
[08:03] <doko> Maintainer: Ubuntu Developers
[08:03] <doko> Section: universe/misc
[08:03] <doko> 2 days old
[08:03] <doko> python-designate/amd64 unsatisfiable Depends: python-dnspython3 (>= 1.12.0)
[08:03] <doko> Not considered
[08:03] <jamespage> doko, urgh - ok lemme fix that up
[08:03] <jamespage> I thought I already did
[08:04] <doko>  python-dnspython3 isn't packaged
[08:07] <jamespage> doko, yes and its for py3 only
[08:08] <jamespage> doko, the dependency generation script we use needs a tweak
[08:09] <jamespage> doko, coreycb already fixed that but needed me to sponsor (I forgot)
[08:44] <doko> willcooke, Laney: I rejected the libreoffice upload, because it discards the changes made in 1:5.0.1-0ubuntu2. There is also no FFE accepted yet. LP: #1495512 is filed, but doesn't have any subscriber
[08:45] <Laney> doko: that upload says it is a bugfix release
[08:45] <Laney> s/upload/bug/
[08:45] <doko> Laney, then why file a FFE? ;p
[08:46] <pitti> coreycb: FYI, http://autopkgtest.ubuntu.com/packages/c/ceilometer/wily/amd64/ regressed, so it's stuck in -proposed
[08:46] <Laney> don't ask me, but it's not relevant as a reject reason
[08:46] <doko> I gave the reason
[08:46] <Laney> maybe the other part still stands :)
[08:47] <pitti> seb128: aptdaemon regressed, it
[08:47] <pitti> seb128: 's stuck in -proposed, FYI
[08:47] <seb128> pitti, ?
[08:47] <pitti> http://autopkgtest.ubuntu.com/packages/a/aptdaemon/wily/amd64/
[08:47] <seb128> pitti, the uploda that changed a one line to the lintian profile?
[08:47] <seb128> that seems buggy to me
[08:47] <pitti> nose.proxy.AssertionError: 'binary-file-compressed-with-upx' not found in 'Lintian check results for /t
[08:47] <Laney>     self.assertIn("binary-file-compressed-with-upx", trans.error.details)
[08:48] <Laney> ha
[08:48] <pitti> seb128: the failed test case does sound related to a lintian change, yes
[08:48] <seb128> that test was removed from lintian
[08:48] <seb128> not an aptdaemon issue...
[08:48] <pitti> ah, so do we need to drop that check from aptdaemon then?
[08:49] <seb128> urg
[08:49] <Laney> you need to fix aptdaemon's test yeah
[08:49] <pitti> did we get a new lintian yesterday? aptdeamon succeeded on Sep 29, and failed yesterday
[08:49] <seb128> yeah, it seems like a forgot a line
[08:49] <Laney> assumedly to exhibit a different lintian error so the test still does something
[08:49] <seb128> pitti, no, but aptdaemon's profile included that test which was not in lintian anymore
[08:49] <pitti> err no, lintian changed on Aug 17
[08:49] <seb128> and that lead software-center to claim packages were bad quality
[08:49] <seb128> let me do another aptdaemon upload to drop the test as well
[08:50] <pitti> seb128: ah, so the patch dropped it from the aptdaemon code but not its tests?
[08:50] <pitti> seb128: cool, thanks
[08:50] <seb128> right
[08:50] <seb128> local build worked
[08:50] <seb128> I guess those tests are not done on build
[08:50] <pitti> seb128: I thought aptdaemon would run its tests during package build too
[08:50] <pitti> weird
[08:51] <Laney> seb128: it would be better to change the test to use a different tag instead of dropping it
[08:51] <Laney> it does check something useful
[08:51] <seb128> Laney, please do the change if you have an idea how to do it :-)
[08:51] <Laney> look at one of the tags we are still erroring on and make a deb which has that
[08:52] <seb128> k, adding to my todo
[08:52] <seb128> I've 3 or 4 things ongoing though
[08:52] <seb128> so likely for later this afternoon
[08:52] <Laney> up to you, but I think it makes sense
[08:52] <Laney> :)
[08:52] <seb128> shrug, I wish the new glib would hit wily
[08:52] <seb128> gedit segfault 3 of 4 timesz
[08:52] <seb128> that drives me mad
[08:52] <Laney> already looking
[08:53] <seb128> thanks
[08:54] <seb128> pitti, thanks for pointing out the aptdaemon test issue!
[08:54] <Laney> bleh, we forgot to upload dbus-test-runner
[08:57] <pitti> seb128: no worries -- emulating the still missing email notifications :)
[09:02] <Laney> the personal touch is a nice one :P
[09:05] <pitti> Laney: *puts a cherry on top*
[09:05] <pitti> seb128: that's colord and dbus-test-runner/ppc64el only, right?
[09:06] <Laney> I retried those
[09:06] <seb128> pitti, was that meant for Laney? I'm not aware of those...
[09:06] <pitti> seb128: I meant what's holding up glib2.0, looking
[09:06] <seb128> oh ok, Laney is on it
[09:07] <seb128> FourDollars, libmbim uploaded to wily/trusty
[09:07] <pitti> dbus-test-runner seems very unstable on ppc, I'll fudge that
[09:08] <Laney> pitti: retried it already, let's see
[09:08] <Laney> I pinged ted_g in another channel to review it too
[09:08] <Laney> (larsu made a fix)
[09:10] <seb128> cyphermox, hey, could you have a look to bug #1448879 seems like you discarded a patch when syncing the new version
[09:10] <FourDollars> seb128: Cool~ Thx a lot. :D
[09:10] <seb128> FourDollars, yw!
[09:11] <Laney> pitti: passed that time
[09:11] <pitti> Laney: ah, your lucky day!
[09:11] <Laney> is Ted at this sprint you are at? ;-)
[09:12] <pitti> Laney: do you mean me? no
[09:13] <Laney> pitti: yeah - oh well
[09:13]  * Laney is using running.html
[09:13] <larsu> Laney: just merge it! :P
[09:14] <Laney> tempted
[09:14] <larsu> it's been long enough
[09:14]  * larsu is annoyed by long review times
[09:16]  * pitti fixes the bug that some armhf results are eternally "in progress" -- go time zones
[09:16] <Laney> uh?
[09:17] <pitti> Laney: http://autopkgtest.ubuntu.com/packages/o/oss4/wily/armhf/
[09:17] <pitti> Laney: look at the two topmost results -- the second one is newer than the first, but it wasn't considered
[09:17] <pitti> one of the workers was in PDT, and the others in UTC
[09:17] <pitti> I set it to UTC, but I also just pushed a worker fix to make the swift timestamps UTC
[09:17] <pitti> so that worker time zones stop mattering
[09:19] <Laney> ah, and it was storing just a bare time
[09:19] <Laney> nice
[09:24] <doko> coreycb, jamespage: looking at the ryu MIR ... may I ask to package python3-ryu as well, and to use python3 in ryu-bin?
[09:25] <Laney> rbasak: Hey, noticed that mariadb-10.0 is wily < vivid-security
[09:25] <Laney> ok to copy it up?
[09:31] <Laney> tseliot: this ^ situation applies to nvidia-346 too
[09:46] <dholbach> Laney, is the ubuntu-wallpapers upload good to go?
[09:47] <dholbach> Laney, if yes, do you think you could upload it? I have a bit of a bad connection here
[09:47] <Laney> OK
[09:47] <Laney> thanks
[09:47] <smb> pitti, Hi! To get back to the discussion we had yesterday (if sprint allows), the build of dahdi-dkms would use plain wget for downloads which should honor http[s]_proxy if set. I do not see a real change between the trusty and wily package in that area. Now the details of the failure would be in the dkms log which I have no idea how to get from an environment that fails...
[09:52] <tseliot> Laney: what situation?
[09:52] <Laney> tseliot: vivid > wily
[09:52] <tseliot> Laney: there's no nvidia-346 in wily, we have 352
[09:53] <Laney> tseliot: it's still in the archive
[09:54] <tseliot> Laney: yes, but it should be a transitional package provided by 352
[09:55] <Laney> so the old source packages should be removed?
[09:55] <tseliot> Laney: yep
[09:56] <ricotz> hello :)
[09:56] <Laney> tseliot: any chance you could file that? :)
[09:56] <tseliot> Laney: doesn't that happen automatically after a while?
[09:57] <Laney> don't think so
[09:57] <Laney> unless there's something I don't know
[09:57] <ricotz> is someone hit by some intltool/gettext failures on armhf builds recently? (qemu crashing while checking for it) happens for vivid and wily builds
[09:57] <tseliot> Laney: ok, I can file that request
[09:58] <Laney> thanks
[09:58] <pitti> smb: hm, don't we export the dkms log as an artifact? if not, we really should
[09:59] <cjwatson> ricotz: qemu-user-static fails on lots and lots and lots of things
[09:59] <pitti> smb: bah, seems we really don't
[09:59] <cjwatson> we're lucky it ever works
[10:00] <ricotz> cjwatson, I see, so if I retry it it might work at some point?
[10:00] <ricotz> cjwatson, although it seems pretty consistent and fails all the time afaics
[10:00] <smb> pitti, that log only exists for dkms builds obviously and in a bit of a complicated path. I guess its hard to squeeze those smarts into a generic thing
[10:01] <ricotz> cjwatson, just for reference https://launchpad.net/~ricotz/+archive/ubuntu/docky/+build/7992439
[10:01] <cjwatson> ricotz: well no, I'm saying that if qemu can't do it you may have to give up
[10:01] <cjwatson> there's a swathe of stuff it just can't manage
[10:01] <pitti> smb: oh wait -- our generic DKMS runner actually does export the logs, like in e. g<EMAIL_ADDRESS>[10:01] <ricotz> cjwatson, precise and trusty builds works (exactly same source packages)
[10:02] <cjwatson> ricotz: there may be differences in which syscalls it happens to tickle
[10:02] <cjwatson> ricotz: or use of threading
[10:02] <pitti> smb: dahdi-linux has its own debian/tests/, so it's not using the synthesized dkms tests
[10:02] <cjwatson> ricotz: hopefully we'll have a better system for virtualised armhf builds in a few months
[10:03] <ricotz> cjwatson, ok, this kind of autotools check isn't that uncommon since it is quite the default and probably hit a lot of other packages too
[10:03] <jamespage> doko, looking now
[10:04] <cjwatson> ricotz: *shrug* I'm sorry it's not something we can fix
[10:04] <cjwatson> ricotz: other than by replacing the existing system relying on qemu-user-static
[10:05] <ricotz> cjwatson, alright :\, thanks
[10:05] <cjwatson> ricotz: in some specific cases it *may* be possible to reproduce them locally and pare it down to a test case that could be sent to qemu upstream - but a lot of these come down to "qemu-user-static can't reliably support threaded code", and even for those that don't it's an awful lot of effort
[10:08] <ricotz> cjwatson, I see
[10:09] <cjwatson> ricotz: but we have arm64 hardware in place which will be used to build a replacement for the qemu-based builds - once the team working on it is done with building the cloud for power builds, I believe arm is next
[10:09] <pitti> smb: running dahdi-linux/trusty manually now, then I can ssh in and do stuff for you
[10:10] <smb> pitti, ah thanks. trying to look at the artifacts you mentioned but getting distracted by brother asking for ubuntu support... :-P
[10:12] <smb> oh wait missed that was for a different package
[10:17] <jamespage> doko, urg - no python3-formencode
[10:21] <pitti> Laney: glib> I filed bug 1501697 to keep track of this
[10:21] <pitti> Laney: i. e. glib is now held because we got a new unity8; that shouldn't re-run already succeeded tests
[10:21] <pitti> (just FYI)
[10:24] <pitti> smb: I'm now in a shell with the failed test
[10:25] <pitti> smb: make.log actually looks fine
[10:25] <smb> pitti, ok, so can you easily see in the mentioned dkms log whether it is ... oh
[10:25] <pitti> $ dkms status
[10:25] <seb128> Laney, pitti, ok, aptdaemon fix uploaded, it was easy, barry added  a patch to the package this cycle that was not needed/wrong with the lintian changes, dropping it and going back to upstream code makes things work
[10:25] <pitti> dahdi, <IP_ADDRESS>+dfsg-1ubuntu4~14.04.3: added
[10:25] <pitti> seb128: yay
[10:25] <pitti> smb: but "added" isn't enough, is it? it shold be "installed" or so
[10:25] <Laney> pitti: thanks!; seb128: nice!
[10:25] <smb> pitti, added in that case is bad it should be installed
[10:25] <smb> pitti, yes
[10:26] <pitti> find /lib/modules -name '*dadhi*'
[10:26] <pitti> smb: nothing ^
[10:26] <pitti> Error!  Build of dahdi_vpmadt032_loader.ko failed for: 3.13.0-65-generic (x86_64)
[10:26] <smb> pitti, there should be that log file under /usr/src/... that got mentioned.
[10:26] <pitti> smb: that's on stderr ^ so perhaps another log or so?
[10:26] <pitti> smb: mentioned where?
[10:27] <Laney> ah, that reminds me
[10:27] <smb> pitti, normally in the build error ... though not /usr/src it seems ... /var/lib/dkms/dahdi/<IP_ADDRESS>+dfsg-1ubuntu4~14.04.3/build/make.log for some example
[10:27] <smb> pitti, version numbers may vary of course
[10:27] <pitti> smb: yes, that's what the stdout says; but tat make.log looks okay
[10:28] <pitti> smb: ah, no!
[10:28] <pitti> onnecting to downloads.digium.com (downloads.digium.com)|2001:470:e0d4::ee|:80... failed: Network is unreachable.
[10:28] <pitti> http://downloads.digium.com/pub/telephony/firmware/releases/dahdi-fwload-vpmadt032-1.25.0.tar.gz
[10:28] <pitti> smb: wget'ing this file works fine
[10:29]  * smb wibbles
[10:29] <pitti> smb: maybe the dkms env gets cleaned so that it doesn't see $http_proxy any more?
[10:29] <doko> jamespage, well, no surprise for a 2012 package ... but there is https://pypi.python.org/pypi/FormEncode/1.3.0
[10:29] <pitti> smb: and that got fixed in wily or so?
[10:29] <smb> pitti, hm... maybe but why not also when it does the wily build
[10:29] <smb> oh... so dkms
[10:29] <pitti> smb: /me diffs trusty vs. wily dkms
[10:30] <smb> pitti, maaaybe ... that would be evil indeed...
[10:30] <jamespage> doko, yeah - I'm just concerned this will snowball in impact
[10:30] <jamespage> formencode has a few reverse-depends
[10:30] <pitti> smb: hm no, there's nothing relevant at all
[10:30] <pitti> smb: so maybe in dahdi-linux itself
[10:31] <jamespage> doko, I'll commit my team to the work, but can we defer for wily and do in +1?
[10:31] <smb> pitti, i try to get that checked
[10:33] <pitti> smb: I checked ./drivers/dahdi/firmware/Makefile and I can't immediately see a difference either
[10:33] <doko> jamespage, sure
[10:34] <smb> pitti, yeah... unlikely the makefile... wonder about the dkms.conf maybe ...
[10:35] <pitti> smb: no relevant diff
[10:36] <pitti> smb: is that actually blocking stuff, or more like "I like green"?
[10:36] <pitti> smb: (it's
[10:36] <pitti> "always failed", thus sholdn't block stuff?)
[10:37]  * pitti runs "$ sudo dkms build dahdi/<IP_ADDRESS>+dfsg-1ubuntu4~14.04.3
[10:37] <smb> pitti, kinda. the current upload basically adds dep-8 because I thought its now working and so we can see when we break stuff with hwe kernels
[10:38] <pitti> smb: I'm heading for lunch, but I let the instance run for a bit
[10:38] <pitti> smb: if you can think of anything else which you'd like me to try there
[10:38] <smb> pitti, ok... reminds me to get food as well
[11:16] <dupondje> where is that cyphermox hiding :)
[11:18] <seb128> dupondje, likely in his bed, it's only 7am where he lives
[11:25] <TJ-> Is there a more appropriate channel for dealing with modification of the ISO images?
[11:30] <pitti> seb128: ah, glib2.0 is in
[11:43] <pitti> smb: I found a difference
[11:43] <pitti> smb: in the shell that I get on trusty there are no $*_proxy, but in the wily shell there are
[11:43] <smb> pitti, sorry otp kinda get back in a bit
[11:44] <pitti> smb: I'm not done debugging yet, I just excluded dkms and dahdi-linux themselves
[11:52] <pitti> smb: !
[11:52] <pitti> smb: the difference is that "sudo -i" uses /etc/environment in wily, but not trusty
[11:53] <smb> pitti, doh!
[11:53] <pitti> smb: the testbed has the proxy in /etc/environment, but the vars are unset for root
[11:56] <pitti> smb: so apparently we changed pam_environment somehow
[11:58] <pitti> smb: /etc/pam.d/sudo looks identical, though
[12:11] <dholbach> Laney, thanks for sponsoring
[12:12] <Laney> dholbach: might be 0.001% of the number of sponsorings you did for me back in the day :)
[12:13] <Mirv> Laney: not sure if you noticed, but you uploaded "vivid-security" mariadb-10.0 to wily https://lists.canonical.com/archives/wily-changes/2015-October/011123.html
[12:13] <Laney> Mirv: I copied it
[12:13] <Mirv> ok then
[12:49] <smb> pitti, Ok, now back. Sorry I was quite distracted. So maybe it sounds like one option may be to enhance the dkms part of dahdi with sourcing in /etc/environment before the build just in case for the the Trusty part. That should not hurt for "normal" builds outside the adt case either
[12:49] <seb128> pitti, re glib, great ;-)
[12:51] <pitti> smb: I was trying to move the env vars to /etc/profile as I source that in the test runner, but it still doesn't work
[12:52] <smb> pitti, Ah ... ok. Darn.
[12:53] <pitti> smb: so, I have a feeling that this is solvable somehow, I just don't have enough quiet time here to figure that out
[12:54] <smb> pitti, Yeah, we could ... erm you and me trying to help, work on this another day/week.
[12:56] <smb> pitti, The only thing I would avoid this to block is letting the added dep-8 testing upload out of proposed. Because the one that is pending after that would fix some build failure
[12:57] <pitti> smb: sorry, parse error; you want to release http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#dahdi-linux or not release it?
[12:58] <smb> pitti, maybe I should switch to German :-P I would release it.
[12:59] <smb> pitti, I got another upload (not uploaded yet) pending sponsorship when the current one is done
[12:59] <pitti> smb: can do, it's verified and 7 days
[12:59] <pitti> smb: released
[12:59] <smb> pitti, thanks a lot. I'll hassle me favourite sponsor about the follow up :)
[13:04] <cyphermox> dupondje: hey
[13:05] <doko> tdaitx, did you intend to keep the old libecap?
[13:07] <tdaitx> doko, squid 3.3 and 3.4 require libecap 0.20 (libecap2), only squid 3.5 can use libecap 1.0 (libecap3)
[13:07] <dupondje> cyphermox: hi, did you see my pm? :)
[13:08] <dupondje> cyphermox: https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1448879
[13:09] <doko> tdaitx, understood, so you want to remove the libecap in -proposed?
[13:09] <doko> and not merge squid?
[13:10] <tdaitx> doko, I agree that merging squid would be preferred, but when I started I was just trying to get the existing one to build, rbasak was working on the merge
[13:10] <tdaitx> since we don't have the merge yet I decided to finish and post my patches just in case
[13:11] <doko> ahh, ok, so lets wait
[13:18] <doko> pitti, could it be that the autopkg tests don't uses parallel builds?
[13:19] <seb128> dholbach, Laney
[13:19] <seb128> +Package: ubuntu-wallpapers-wily
[13:19] <seb128> +Description: Ubuntu 15.04 Wallpapers
[13:19] <seb128> that should be 15.10
[13:52] <seb128> bdmurray, pitti, what's the standard way to propose a change against the apport ubuntu packaging vcs? I would like to get review for http://paste.ubuntu.com/12631780/
[14:13] <pitti> doko: if this requires anything else than "dpkg-buildpackage -us -uc -b", then no; that's just what I'm calling
[14:14] <pitti> doko: do we need to call it with -j<numcpu>?
[14:14] <pitti> seb128: Vcs-Bzr: is up to date, so if you want do an MP or just commit (it
[14:14] <pitti> seb128: 's ~ubuntu-core-dev)
[14:14] <seb128> pitti, yeah, I've the right vcs, I just didn't figure out where to push
[14:15] <seb128> usually I push to ~user/project/somebranche
[14:15] <pitti> seb128: ah, is UbiquitySyslog a str, not a bytearray?
[14:15] <seb128> pitti, correct
[14:15] <pitti> seb128: you can use ~seb128/ubuntu/wily/apport/fix-foo
[14:15] <seb128> k
[14:15] <seb128> ubuntu/wily/source was the bit I was missing
[14:15] <pitti> seb128: ah, I see - I think this does some opportunistic decoding when reading a report
[14:15] <seb128> I knew if was something like that
[14:16] <seb128> pitti, btw aptdaemon just migrated to wily ;-)
[14:16] <pitti> seb128: très bien !
[14:20] <seb128> bdmurray, pitti, k, https://code.launchpad.net/~seb128/ubuntu/wily/apport/str_no_decoding/+merge/273075 for review
[14:21] <seb128> hum
[14:22] <seb128> https://code.launchpad.net/~seb128/ubuntu/wily/apport/str_no_decoding/+merge/273076 rather
[14:22] <pitti> seb128: looks like you branched off trunk, not the wily VCS?
[14:23] <seb128> pitti, no, it's just the launchpad ui that picked lp:ubuntu/apport as default
[14:23] <pitti> seb128: ah no, you proposed merging into lp:ubuntu/apport, which is the UDD autogenerated one
[14:23] <seb128> ^ fixes it
[14:23] <seb128> right
[14:23] <seb128> launchpad tricked me :p
[14:39] <hallyn> @pilot in
[14:41] <cjwatson> pitti: You want DEB_BUILD_OPTIONS=parallel=<number of cores>, as launchpad-buildd does, not -j.
[14:42] <pitti> cjwatson: ah, good
[14:43] <pitti> cjwatson: grep -c '^processor\b' /proc/cpuinfo
[14:43] <pitti> cjwatson: or something more elaborate?
[14:45] <cjwatson> pitti: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/view/head:/sbuild-package#L64 is our code, pretty much that
[14:45] <pitti> cjwatson: ah, and you clamp it to 1, thanks
[14:46] <cjwatson> Just in case
[14:49] <pitti> doko: added that ^ to adt-run now, and restarted bintuils/amd64
[14:51] <pitti> cjwatson: thank you
[14:52]  * dholbach hugs hallyn
[14:52]  * pitti hugs hallyn too, for the same reason (whatever good one it is) and LXC
[14:53] <pitti> oh, patch pilot I figure :)
[14:53] <dholbach> :)
[14:53] <hallyn> \o :)
[14:54] <cjwatson> pitti: cool
[14:55] <pitti> meh, I attached it to the wrong place
[15:01] <seb128> dholbach, thanks for fixing the typo ;-)=
[15:02] <Laney> pitti: are these akonadi tmpfails you killing the workers?
[15:02] <pitti> Laney: I retried them
[15:02] <Laney> just checking
[15:02] <pitti> Laney: I don't really know what's going on there, the log files don't have an error but adt-run exited with 1
[15:03] <Laney> I thought it might have been you killing them to deploy the parallel stuff
[15:03] <pitti> Laney: not sure about the bintuils one running out of space
[15:03] <pitti> Laney: no, there's no need to restart the workers, that's a change in the autopkgtest tree only
[15:04] <Laney> the second akonadi/amd64 got ENOSPC too
[15:04] <pitti> Laney: oh -- that actually smells like the adt-run *host* getting out of spae
[15:04] <pitti> /dev/vda1       9.9G  3.7G  5.7G  40% /
[15:05] <pitti> Laney: when it copied down the rather sizable build tree between the test
[15:05] <pitti> Laney: that also explains akonadi
[15:05] <pitti> Laney: looks like I should redeploy the adt-run host as a bigger instance
[15:05] <pitti> but I'm not gonna do this today
[15:06] <pitti> Laney: we were running linux, bintuils, and glibc at the same time, and they all rebuild themselves
[15:06] <pitti> so, mystery solved
[15:07] <pitti> Laney: so please don't retry libo etc. yet, let's retry the big ones (linux etc.) serially
[15:10] <rcj> stub, can you look at bug #1473533?  I've nominated series for SRU.  I'm happy to scratch my own itch and get those SRUs done, but I can't approve the nominations.
[15:11] <cjwatson> rcj: I've approved the nominations for you.
[15:11] <rcj> cjwatson, thanks
[15:12] <rcj> then I can spend time fixing the root issue rather than hacking cloud stream generation code with a "fix"
[15:14] <Laney> pitti: OK, I'll let you serialise these :)
[15:18] <Laney> I guess you could use block storage instead of asking for a beefier instance too
[15:19] <pitti> Laney: ah, does that give me an additional virt disk to mount?
[15:20] <pitti> Laney: i. e. to not waste additional CPUs/RAM (which I won't be needing), just disk?
[15:20] <pitti> single-core 2GB is just fine otherwise, just 10 GB disk is too small
[15:20] <Laney> pitti: indeed
[15:20] <Laney> I'm sure you can ask for it with juju somehow, just don't ask me how to do it :)
[15:20] <pitti> Laney: do you happen to have some details... ok
[15:20] <Laney> hahaha
[15:21] <juliank> As nothing was moving with regard to syncing the python-apt 1.0 final release since I asked a few weeks ago, I now gone with a bug report in bug #1501805.
[15:22] <juliank> If this does not get done, we'll have the same problems as in vivid with the non-PEP440 version number, amongst other issues
[15:22] <Laney> juliank: seems sensible, I'm sure it'll get dealt with
[15:23]  * juliank hopes so, having that weird ~beta3.1 thing will do no good.
[15:24] <arges> cyphermox: hey for bug 1486931, leitao gave the commits. Do you want to just re-format the patch with updated DEP-3 info and i can review that?
[15:25] <Laney> pitti: https://jujucharms.com/docs/1.24/storage
[15:25] <cyphermox> arges: k
[15:26] <pitti> Laney: oh, nice!
[15:26] <pitti> Laney: ah, seems new in 1.24, we don't have that command yet on wendigo
[15:27] <pitti> Laney: but anyway, we have a cpu1-ram2-disk50 flavor, that souds fine
[15:27] <Laney> pitti: ah right, that's a shame
[15:28] <pitti> Laney: or use nova directly for hot-adding
[15:28] <Laney> pitti: You probably want it all contained in the charm though?
[15:29] <Laney> unless you can call nova directly there
[15:29] <pitti> Laney: https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=4beddeae66989301a939f2eaa5d3fd63ff825fad
[15:29] <pitti> Laney: I mean for patching the existing setup without redeploying
[15:29] <pitti> I just need it to go quiet, then mount /tmp from that storage
[15:29] <Laney> nod
[15:29] <pitti> Laney: but I'll redeploy on Monday or so, when I'm not on a sprint
[15:30] <pitti> Laney: good opportunity to fix bug 1480962
[15:52] <rcj> cjwatson, How do I number the versions when backporting the fix in python-tz?  wily is 2014.10~dfsg1-0ubuntu2.  Would vivid be 2014.10~dfsg1-0ubuntu2~15.04.0 as they would have the same content?
[15:57] <slangasek> smb: I haven't seen a dpdk reupload yet for the debian/copyright fix, is that pending?
[15:57] <smb> slangasek, yeah sorry pending me getting my sh... iny things together and pack it up
[15:58] <slangasek> ok :)
[15:58] <cjwatson> rcj: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging has examples
[15:59] <smb> slangasek, meanwhile you could probably reject it from new if you happen to be looking that direction
[15:59] <slangasek> smb: done
[15:59] <smb> slangasek, ta
[16:00] <rcj> cjwatson, excellent. bookmarked!
[16:04] <chiluk> infinity any update on the netboot respin for the new kernel?  lp 1481490
[16:20] <alkisg> flexiondotorg: hi, we've talked the other day on #ubuntu-devel about an issue with fcitx and Greek keyboard layout
[16:20] <alkisg> It's still an issue, we can't properly type Greek unless we uninstall fcitx-bin, which is depended upon by ubuntu-mate-core
[16:21] <alkisg> So the end result is that Greeks can't properly use mate
[16:21] <flexiondotorg> alkisg, OK, understood.
[16:21] <flexiondotorg> alkisg, I have a fix for that I believe.
[16:21] <flexiondotorg> I'll get on it.
[16:21] <alkisg> flexiondotorg: I tried with beta2, mate and vanilla ubuntu. It happened on mate but not on ubuntu
[16:21] <flexiondotorg> I think if fcitx is move from -core to the live seed everything will work.
[16:21] <alkisg> Thank you flexiondotorg
[16:22] <flexiondotorg> alkisg, The idea of moving fcitx to the live seed is based on me poking through the ubuntu seeds.
[16:22] <flexiondotorg> alkisg, Question.  - https://ubuntu-mate.community
[16:22] <alkisg> Let me check if both those flavours behave the same in the live cd...
[16:22] <flexiondotorg> Oops.
[16:23] <alkisg> ?
[16:28] <alkisg> flexiondotorg: ubuntu beta 2 live CD has a whole lot of fcitx packages installed, but it does not have the issue
[16:28] <alkisg> mate only has fcitx-bin, and does have the issue
[16:28] <alkisg> I'm wondering if the issue is in ubuntu-mate-core, or of it has something to do with the window manager...
[16:28] <flexiondotorg> So Ubuntu MATE has the issue in the Live session?
[16:28] <alkisg> Yes
[16:29] <flexiondotorg> Oh, bother.
[16:29] <alkisg> (both in the live and installed)
[16:29] <flexiondotorg> OK. More thought required.
[16:29] <flexiondotorg> Worst case, I yanked fcitx from Ubuntu MATE completely.
[16:29] <flexiondotorg> Or figure out how to work around this issue.
[16:30] <flexiondotorg> alkisg, Please can you file a bug against Ubuntu MATE describing this problem?
[16:30] <flexiondotorg> https://bugs.launchpad.net/ubuntu-mate
[16:30] <flexiondotorg> I'll need a bug reference in any package changes I might have to make.
[16:30] <FourDollars> cyphermox: Hi. Could you help to review https://bugs.launchpad.net/ubuntu/+source/modemmanager/+bug/1441095/comments/56 and https://code.launchpad.net/~binli/ubuntu/trusty/modemmanager/lp1441095/+merge/272054 for trusty?
[16:30] <flexiondotorg> alkisg, Thanks for testing.
[16:30] <alkisg> flexiondotorg: sure, will do, I'll also test some more
[16:31] <flexiondotorg> Thank you.
[16:31] <flexiondotorg> I suspect fcitx is being detected as the default input handler.
[16:31] <cyphermox> FourDollars: did we not already land this?
[16:31] <flexiondotorg> But on Ubuntu iBus is probably the default detected.
[16:32] <cyphermox> oh, I see, it landed in wily
[16:32] <alkisg> flexiondotorg: here's an interesting test, in the live session: dpkg -r --force-all fcitx; service lightdm restart ==> solves the problem. The dpkg -r ==> to not uninstall ubuntu-mate-core but only fcitx
[16:33] <FourDollars> cyphermox: Yup, but not include trusty.
[16:33] <cyphermox> right
[16:33] <cyphermox> I'll review it a little later, I want to finish other fixes first :)
[16:33] <alkisg> flexiondotorg: you're probably right, ibus is installed in ubuntu, not in mate
[16:34] <alkisg> And running on the live session
[16:34] <FourDollars> Ok. Take your time. Thx in advance.
[16:34] <flexiondotorg> alkisg, MATE has isn't own input system.
[16:34] <flexiondotorg> And fcitx is "getting in the way".
[16:34] <alkisg> flexiondotorg: one of the reasons we want to use mate is because it still respects the xorg settings, while ubuntu doesn't
[16:35] <flexiondotorg> alkisg, I'll fix it for you :-)
[16:35] <alkisg> So grp:alt_shift_switch is respected in mate, overriden in ubuntu by ubuntu-settings-daemon
[16:35]  * alkisg files a bug...
[16:35] <cyphermox> FourDollars: won't you also need libmbim changes in trusty too?
[16:36] <FourDollars> cyphermox: Yes, I need it. Just missing.
[16:36] <cyphermox> FourDollars: do you want to do the merge proposal?
[16:36] <FourDollars> cyphermox: I thought seb128 had done it.
[16:37] <FourDollars> cyphermox: I did. Wait a minute. Let me show you the link.
[16:37] <cyphermox> ok
[16:38]  * FourDollars is working by a tablet.
[16:39] <alkisg> flexiondotorg: https://bugs.launchpad.net/ubuntu-mate/+bug/1501832
[16:39] <FourDollars> cyphermox: https://code.launchpad.net/~fourdollars/ubuntu/trusty/libmbim/1441095/+merge/273015
[16:40] <cyphermox> oh, great. Looks like seb128 already uploaded that
[16:40] <FourDollars> Cool.
[17:00] <pitti> apw: (CC: jibel): how far are we from killing the old dkms jobs? (jibel asked todya)
[17:04] <apw> pitti, i am waiting confirmation from bjf and smb that they are done with the old and using the new
[17:04] <smb> apw, confirmed
[17:04] <apw> (that you have stopped using dkms-matrix and that adt-matrix is supplying what you need; if anythign)
[17:05] <gQuigs> should I divide this removal request bug up by source pacakge ?  - https://bugs.launchpad.net/ubuntu/+source/glade-3/+bug/1496227
[17:05] <smb> apw, Yep I have not looked back to the old one for a while and concentrated on the new one. You may have noticed some attempts at least to improve stuff with adt/dep-8 :)
[17:06] <apw> smb, indeed, thought so, but best to be sure :)
[17:08] <smb> apw, sure-ack
[17:13] <pitti> apw, smb: cool, thanks
[17:14] <pitti> jibel: zap it!
[17:15] <pitti> jibel: and then we can drop a lot of cruft from lp:auto-package-testing :)
[17:15]  * pitti → food
[17:44] <hjd> hallyn: Hello. I have to admit I don't know whether sync/feature freeze expection requests fall in under path pilots, but if it does, could you please take a quick look at bug 1500112?
[17:47] <hallyn> hjd: i can't do ffe's,
[17:47] <hallyn> thta's a #ubuntu-release thing i think
[17:47] <hallyn> quesitonwould be how big is the debdiff.  if it doesn't do much beside fix that bug then it shouldn't need ffe
[17:58] <gQuigs> hmm... it is much cleaner separate ..   now just for dockmanager -https://bugs.launchpad.net/ubuntu/+source/dockmanager/+bug/1501859
[17:58] <jibel> pitti, apw \o/
[17:58] <jibel> thanks!
[18:09] <hjd> hallyn: The diff should be rather small, but I don't have experience with FFEs and the documentation said that when in doubt, check first. Didn't know there was an #ubuntu-release though, I'll try there. Thanks :)
[18:58] <infinity> chiluk: Doing it nowish.
[19:11] <cjwatson> hjd: I'll deal with it, thanks.  No need for an FFE.
[19:16] <chiluk> thanks infinity
[19:21] <hjd> cjwatson: Thank you :)
[19:49] <juliank> barry: I have a fix for the stderr thing in python-apt :)
[19:50] <barry> juliank: other than Restrictions: allow-stderr? :)
[19:50] <juliank> barry: Yes, catching the warning and checking it's a deprecation one :)
[19:51] <juliank> barry: http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=91d32c8
[19:51] <barry> juliank: cool!  if you upload that to unstable, i can resync and drop our delta.  maybe we can even do that before the release team approves my 1.0.0ubuntu1 upload :)
[19:52] <barry> juliank: lgtm!
[19:52] <juliank> barry: There are also some fixes by mvo: http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=92f7e29f55bc0f4bf7bf9cc78730814700fb2284 and http://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=598bbabf7a97962426e70233430cda78182b453b pending for 1.0.1
[19:52] <juliank> I think they're fine too
[19:53] <barry> +1
[19:53] <barry> juliank: do you have an eta for 1.0.1 in unstable?
[19:53] <juliank> barry: I'll do it now
[19:53] <barry> juliank: awesome, thanks.  as soon as that gets picked up by lp i'll sync it
[19:54] <barry> juliank: and i think that can be a straight up syncpackage rather than a merge
[19:54] <juliank> Yeah
[19:57] <juliank> barry: At some point, I really need to switch the build system over to pybuild instead of the ugly hack from the pre-python3 helper times
[19:57] <barry> juliank: +1 :)
[19:57] <hallyn> sforshee: bug 1483796 , you see that perf regression yourself?
[19:58] <sarnold> doko: this is reported as a gcc5 issue: https://bugs.launchpad.net/bugs/1501634
[19:58] <sarnold> the patch inthe second url looks like good old fashioned broken code though, heh
[19:58] <juliank> barry: meh, dinstall just started on ftp-master.d.o., this will take a while...
[19:59] <barry> juliank: no worries.  i'm here for several more hours :)
[19:59]  * juliank not. Just paused the walking dead to do the 1.0.1 release :)
[20:00] <barry> juliank: wow! that's dedication.  i've been binge watching season 5 on netflix and am about 1/2 through.  i don't know that i'd pause it for that reason. :)
[20:00] <juliank> Nah, I'll be here for two hours.
[20:01] <juliank> barry: I started with the series yesterday, and am now at season 2 episode 2, 8 minutes in.
[20:01] <barry> food, maybe.  sleep, pshaw.  work, hahahah (but don't tell slangasek :)
[20:02] <doko> sarnold, should that be fixed in gnupg?
[20:02] <barry> juliank: just call in sick tomorrow and have a great, sleep deprived and freak out filled weekend! :)
[20:02] <juliank> barry: I'm a student, and I have holidays :)
[20:02] <barry> juliank: :)
[20:02] <doko> juliank, enjoy
[20:03] <juliank> Two semesters left until M.Sc. in CS is complete.
[20:04] <jrwren> juliank: congrats.
[20:07] <juliank> Dammit, gbp dch put mvo as the uploader in the changelog...
[20:07] <juliank> I'm not sure what that tool is thinking
[20:08] <juliank> It's tagged and uploaded now, so I won't fix it anymore.
[20:09] <juliank> or wait, I will
[20:13] <sforshee> hallyn: yes I do
[20:14] <doko> robert_ancell, https://launchpad.net/ubuntu/+source/xserver-xorg-video-siliconmotion/1:1.7.8-1ubuntu3/+build/7987052
[20:15] <robert_ancell> doko, yeah, I was waiting to see if that patch I sent to xorg-devel was considered correct
[20:15] <hallyn> sforshee: and you're using that patch locally?
[20:15] <robert_ancell> doko, is this a daily poke I get for having something FTBFS? ;)
[20:15] <barry> juliank: well, 1.0.0ubuntu1 got approved, but i'll still do the syncpackage when it's ready
[20:16] <doko> robert_ancell, sorry, I'm trying to get this automated ;-P
[20:16] <robert_ancell> hah
[20:16] <juliank> barry: OK, sorry about the wrong bug number, BTW, I only noticed this yesterday. Not sure how it slipped in
[20:16] <sforshee> hallyn: yep, it's much better
[20:16] <barry> juliank: no worries, but do you remember the correct bug #?
[20:18] <hallyn> sforshee: i see, it's upstream :)
[20:19] <hallyn> sforshee: i don't see you having nominated that for trusty,but you said all major releases - should i add trusty?
[20:19] <juliank> I tagged it fix committed yesterday, let me have a look
[20:19] <juliank> It's bug #1484470
[20:20] <sforshee> hallyn: I don't think trusty was affected
[20:21] <hallyn> oh, ok.
[20:21] <juliank> barry: The wrong number came direct from john apparently, not sure if there was another bug about it
[20:21] <sforshee> or maybe it was ... my description makes it sound like it is, but my memory says it wasn't
[20:22] <juliank> where john = John R. Lenton<EMAIL_ADDRESS>[20:22] <hallyn> sforshee: hm, it's fixed in the unstable package
[20:23] <hallyn> but i guess it's a bit late for something so drastic
[20:23] <barry> juliank: ah, cool no worries then
[20:23] <sforshee> hallyn: mutt in trusty seems fine
[20:23] <hallyn> not a soothing difference eiterh  226 files changed, 33071 insertions(+), 40447 deletions(-)
[20:23] <hallyn> so i guess i'll just cherrypick your patch into wily - thx
[20:23] <juliank> barry: I uploaded 1.0.1 a few minutes ago, BTW
[20:25] <juliank> Now we only need to wait for dak and its friends
[20:26]  * juliank is mostly back to walking dead now. But they're just talking in the woods
[20:39] <infinity> chiluk: And both uploaded/accepted/building.
[20:40] <infinity> chiluk: If you can turn around verification on that reasonably quickly, that would be lovely.
[20:41] <infinity> chiluk: And poke me directly when you do, since I need to make seed changes at the same time as d-i is copied, or dailies explode. :P
[20:42] <infinity> Oh, actually, trusty is building with proposed right now, I guess I need to make those seed changes today.
[20:42] <infinity> La la la.
[20:44] <kentb_> mwenning: thanks! (2 days late lol)
[20:57] <chiluk> ok infinity sorry I missed that earlier I'll verify now-ish.
[21:01] <chiluk> nm I see that it's still building
[21:14] <juliank> too many zombies, i'll get bad dreams...
[21:17] <mwenning> kentb_, :-)
[21:24] <Unit193> infinity: Get a chance to review some things? ;P
[21:29] <infinity> Unit193: I feel like that question is a trap.
[21:29] <infinity> Unit193: Which things?
[21:30] <Unit193> infinity: cdimage/livecd-rootfs/debian-cd reviews, Openbox debdiff (likely too late, I'm fine dropping it.). :D
[21:30] <infinity> Unit193: Bug#, MPs, where am I looking?
[21:31] <infinity> Unit193: (If I had context on this at one point and forgot, sorry, I'm a bit headless chickeny this week)
[21:32] <infinity> chiluk: trusty-proposed and vivid-proposed should have bits published now, at least for the architecture I suspect you planned to test. :P
[21:32] <Unit193> infinity: Yes sorry, I thought that might trigger a memory, it's not just me being vague: https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 - https://code.launchpad.net/~unit193/livecd-rootfs/xubuntu-core/+merge/267880 - https://code.launchpad.net/~unit193/debian-cd/xubuntu-core/+merge/267879 -
[21:32] <Unit193> https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/5397648/+listing-archive-extra
[21:33] <infinity> chiluk: 376.1 for vivid-proposed, 318.30 for trusty-proposed.
[21:33] <chiluk> infinity, ok.. I'll kick off a virt-install net-install.
[21:34] <infinity> Unit193: Ahh, core, right, that would triggered more flashbacks than "openbox". ;)
[21:34] <infinity> s/would/would have/
[21:34] <Unit193> But then you're thinking Snappy! :---D
[21:35] <chiluk> infinity the dates for the netboot images are still old http://archive.ubuntu.com/ubuntu/dists/trusty-updates/main/installer-amd64/current/images/netboot/ubuntu-installer/amd64/
[21:35] <infinity> Unit193: So, was this a flavour you intended to release with 15.10?  We tend to try to stick by the rule "if you didn't participate in Beta 2, you don't participate in release".
[21:35] <infinity> Unit193: If you just want the commits in there to alpha test the whole thing with an eye to being able to release ISOs "officially" for 16.04, there's no reason we have to wait until after release to do that.
[21:36] <infinity> chiluk: Because you're looking in updates, not proposed.
[21:36] <chiluk> doh
[21:37] <Unit193> infinity: If that's the rule, then sure I think we can get this reviewed with XXX in mind.
[21:39] <infinity> Unit193: Like all rules, it's bendable, but it's a good rule, IMO, in that it makes sure that you had something that was at least half functional and QAable a month before release, and aren't wasting time (yours or others) on trying to fix the world in the last month when you should just be adding polish that that Beta. :)
[21:39] <infinity> s/that that/to that/
[21:41] <infinity> Unit193: I'd agree that xubuntu-core, the packageset, is a special case here, because it's a strict subset of things you already need to fix and ship for Xubuntu proper.
[21:41] <infinity> Unit193: But you'll still need to suck some resources to fix xubuntu-core the ISO product, unless it's magically perfect the first time.
[21:46] <Unit193> infinity: Right, and we've tested something unofficial a bit, but not using the exact infra so it'll likely be a bit odd.  If it's good enough, or close to it then it might be nice to fix but otherwise that'll come later.
[21:53] <sarnold> doko: yes, the proper fix is going to be in gnupg
[21:55] <chiluk> infinity netboot looks to be going along swimingly.. booted fine.. installing now.
[22:00] <Unit193> infinity: (The Openbox issue was another one I poked you about, though.)
[22:31] <chiluk> infinity netboot install completed successfully http://paste.ubuntu.com/12635027/  ... additionally I checked for the existence of the sfc module and it was there like we expected...
[23:01] <juliank> barry: I think I'll turn some warning display on by default for all warnings in the test suite, so such bugs do not happen only during autopkgtests
[23:02] <barry> juliank: +1
[23:02] <juliank> That's the second time this happened, which is two times more than I'd like
[23:02] <barry> juliank: still waiting for LP to pick up 1.0.1
[23:03] <juliank> barry: Probably happens only after the dinstall run finished, in about 5 hours?
[23:03] <juliank> or 4 hours
[23:03] <barry> juliank: yeah, not sure, but that seems likely.  if not tonight, tomorrow
[23:05] <mdeslaur> infinity: what created the weird dual partition tables on our iso media?
[23:05] <mdeslaur> s/created/creates/
[23:06] <infinity> chiluk: So, that tested one of 4 things. :)
[23:09] <infinity> mdeslaur: xorriso, with a bit of prep.
[23:09] <infinity> mdeslaur: http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/view/head:/tools/boot/wily/boot-amd64
[23:10] <mdeslaur> infinity: ah, cool, thanks
[23:49] <TJ-> infinity: re: cdimage - could we switch to the syslinux project's MBR isohdpfx_c.bin instead of isohdpfx.bin at some point, to provide a workaround for several buggy BIOS implementations? bug 277903


[02:53] <robru> soooo anybody know anything about opencsg? apparently qmake is bringing in gles on armhf but the source isn't compatible with gles at all.
[06:24] <darkxst> can I get gnome-online-accounts 3.16 removed from wily-proposed, doesnt look like we can get around webkit2 requirements
[06:25] <darkxst> bug 1466245
[06:25] <darkxst> ah no its bug 1466290
[06:56] <darkxst> infinity, didrocks ^
[07:01] <didrocks> hum, I guess we will need to blacklist it to not get it synced back. I'm unsure what's the procedure to blacklist only for one release? (as we copy the black list to the next release)
[07:01] <didrocks> I guess infinity already got this case
[07:09] <darkxst> didrocks, yeh it will need blacklisting
[07:11] <didrocks> darkxst: I just don't want to blacklist it and forget about it later on (and so, will be blacklisted in next release), so that's why I wonder if there is a special section for this
[07:11] <darkxst> ok
[07:13] <darkxst> it would sometimes be nice if the sync-er ignored packages that are just going to depwait!
[07:15] <didrocks> darkxst: it's slightly more complicated I guess, because the new versionned dep-wait can be into that transaction
[07:15] <didrocks> doable, but not trivial :)
[07:16] <didrocks> (especially as we don't know about the dep-wait without having a build running IIRC)
[07:18] <darkxst> yeh, and its probably only a few packages each cycle that get hit, so not worth the effort
[07:21] <darkxst> didrocks, also can you look at the gnome-getting-started-docs langpack split in new, would be nice to get the the 120MB monster package, off our dailies for the next build, so I can get people testing it;)
[07:23] <didrocks> darkxst: will probably after finishing the morning duties (so at my start of afternoon). Opening a tab with it :)
[07:27] <darkxst> didrocks, ok, thanks!
[07:28] <didrocks> darkxst: no worry, I just gave a first quick look, sounds good. Quite impressed they are shipping localized webm videos as well, do you know what tool did they use to create those animations?
[07:28] <didrocks> (as it's a space where we don't have really good tools)
[07:29] <darkxst> didrocks, no idea, but wonder if its somewhat not automated, since only 5-6 out of 30 locales have them
[07:30] <darkxst> where as all have localised svg's
[07:31] <didrocks> oh, so yeah, maybe they are svg with placeholders
[07:31] <didrocks> not sure, you can't rely on this
[07:32] <didrocks> so yeah, ok, I'll maybe poke upstream at some point
[07:38] <darkxst> didrocks, yeh, Ive not looked into the details at how they are generated, but they seem to have a bunch of python scripts that generate them, https://git.gnome.org/browse/gnome-getting-started-docs/tree/animation?id=8ad76711dbc4b895efa1cdea62fc06c1cff68fea
[07:45] <didrocks> darkxst: ok, seems they match that with some blender magic and spits out the webm, interesting…
[07:45] <didrocks> darkxst: while I was at it, I finished the review, NEWed
[07:51] <darkxst> didrocks, thanks
[07:53] <didrocks> yw
[15:44] <slangasek> Laney: so there are a lot of autohints in update_output right now that are all failing.  Do you have the big picture view of what needs to happen to unblock the big mass?
[15:44] <cyphermox> slangasek: should we do a respin of one image once syslinux lands?
[15:44] <slangasek> cyphermox: yes
[15:45] <cyphermox> slangasek: I'm saying this because I don't think I have access to trigger that :)
[15:45] <cyphermox> it's still going to be a bit though, it's building right now
[15:45] <Laney> slangasek: No, I occasionally have a small view into it though
[15:45] <slangasek> cyphermox: maybe you do via the iso tracker, I'm not sure?  but yes, when it's built let us know and we'll get it respun
[15:45] <Laney> Give me two minutes and I'll share my script so you can all be as clueful as me
[15:47] <cyphermox> slangasek: I only have access to trigger touch builds, I'm not in the cdimage team or whichever is used to respin isos
[15:51] <slangasek> Laney: well I've at least managed to find the two 700+ package easy hints; I wonder how much overlap there is between those
[15:56] <slangasek> in fact the two 700+ package easy hints differ by 16 packages
[15:59] <Laney> slangasek: https://code.launchpad.net/~laney/ubuntu-archive-tools/update-output-helper/+merge/267970
[16:02] <slangasek> Laney: ok
[16:03] <slangasek> fwiw I've just looked at double-conversion, which was notable in the list because one of the autohints tried it and one didn't; looks like qtdeclarative-opensource-src is the blocker there
[16:04] <Laney> I tried to fix kdeclarative
[16:04] <Laney> ah man, one of the upstream tests is failing too
[16:05] <slangasek> what's the nature of the kdeclarative failure?
[16:06] <slangasek> the autopkgtest log isn't very scannable :/
[16:06] <Laney> look for "FAIL non-zero exit status"
[16:06] <slangasek> thank
[16:06] <slangasek> s
[16:07] <Laney> hopefully just a missing dep
[16:08] <slangasek> claims QtQuick is not installed, but qml-module-qtquick2 is in the log
[16:15] <Laney> it's not in the test-deps of "testsuite"
[16:16]  * Laney ponders on @ vs. qml-module-qtquick2
[16:29]  * Laney starts documenting blockers for this transition
[16:31] <Laney> too much k and q
[17:05] <jdstrand> slangasek: hey, it seems today's wily i386 livecd doesn't get past ISOLINUX in kvm. is this known? if so, do you know when the last usable wily i386 was?
[17:05] <slangasek> jdstrand: yesterday's was usable; syslinux built with gcc5 is broken, we're working on getting a new image built with a gcc-4.9 syslinux
[17:05] <jdstrand> ok, great. thanks!
[17:11]  * jdstrand confirms that http://cdimage.ubuntu.com/daily-live/20150812/wily-desktop-amd64.iso appears to work
[17:11] <jdstrand> slangasek: thanks again
[17:13] <slangasek> jdstrand: sure thing
[17:14] <slangasek> and syslinux 3:6.03+dfsg-8ubuntu1 is built/published, so I'll trigger an image respin now ( cyphermox davmor2 )
[17:15] <slangasek> only triggering for ubuntu at the moment, but if any other flavors are blocked and need a respin let me know (or use that handy dandy iso tracker)
[17:44] <cyphermox> slangasek: thanks.
[18:07] <cyphermox> slangasek: apparently not any better sadly :(
[18:10] <cyphermox> ah, I see, we're still picking up lots from 5.2.1
[18:32] <slangasek> cyphermox: picking up lots of what?
[18:32] <slangasek> is it linking in libgcc?
[18:33] <cyphermox> slangasek: I see a bunch of libraries coming from libgcc 5.2.1
[18:33] <cyphermox> yes
[18:33] <slangasek> hmm ok
[18:33] <cyphermox> I'll just try the patch that's included, despite it not being blessed upstream
[18:33] <cyphermox> it seems to work for redhat if I read the bug report properly
[18:42] <robru> anybody know anything about qmake pulling in gles on armhf? I'm working on opencsg and it has seemingly no gles support but it's being pulled in somehow and ftbfs
[18:46] <infinity> robru: ARM has defaulted to GLES instead of GL pretty much since we did the first armel port.  It's more surprising that that package hasn't tripped over it until now.
[18:47] <robru> infinity: seems it's a case of new upstream changes? wily release version is 1.3 and built on armhf, proposed has 1.4 and failed. the error message looks a lot like it's trying to mix GL and GLES in bad ways
[18:47] <robru> infinity: it's using qmake which tries to pull gles in automatically, but it seems like most of the code just has GL hard-coded and has no real support for GLES
[18:48] <robru> infinity: like, the code has references to "experimental GLES" that's commented out.
[18:48] <robru> infinity: and uncommenting it doesn't build successfully ;-)
[19:05] <wxl> hey folks problems with our alternates building today http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/wily/daily-20150813.log
[19:05] <wxl> seems like some seed is missing?
[19:05] <ianorlin> it looks like the import of the packages it should have fails in bzr looking at the log
[19:06] <wxl> near the bottom gpg issues too
[19:12] <infinity> wxl: Probably just need to mangle some priorities.  Will fix.
[19:17] <wxl> thx infinity
[19:32] <robru> Laney: any thoughts on opencsg gles on armhf issue?
[19:47] <slangasek> infinity: so the package in question (opencsg) basically bundles glew from what I can see, which isn't going to work with GLESv2 AFAIK
[19:47] <slangasek> infinity: and the reason it pulls in GLESv2 is that it asks qmake for 'opengl' and this is the answer it gets
[19:47] <slangasek> so the first offense of course is using qmake
[19:47] <infinity> slangasek: Right, the second bit is well known, but the bundling of glew seems wrong...
[19:47] <slangasek> but I wonder how we could fix this
[19:48] <infinity> slangasek: The old version build-depped on glew, so I assume this bundling is a new offense.
[19:49] <infinity> The new one build-deps on glew too...
[19:49] <slangasek> robru: ^^ can you investigate why opencsg is now bundling glew?  (if there's upstream history or Debian bugs that explain)
[19:50] <slangasek> robru: it's possible that a distro patch to replace the 'CONFIG += opengl' with 'LIBS += -lGLEW -lGL' would be enough to fix this here
[19:50] <robru> hmm
[19:52] <slangasek> robru: and if you exhaust those options, I'm fine with punting this one to the corner; there are other higher-priority issues that will need looked at, e.g. the "failing tests that need resolving" listed on the pad as blockers
[19:52] <robru> ok
[19:53] <robru> LOL http://opencsg.org/ their latest release is from 2014 but this website is straight outta 1993.
[19:56] <robru> "The archive contains all required helper libraries, i.e., also RenderTexture and GLEW." I'm not seeing a changelog suggesting that's new though
[19:57] <robru> v1.3 definitely had glew bundled as well
[19:59] <infinity> So, the bundling could be a red herring.  Or it could be that we accidentally started using the bundled version when we didn't before.
[20:01] <robru> infinity: slangasek: clue? http://anonscm.debian.org/cgit/collab-maint/opencsg.git/commit/?id=6f46d2e0f28ed4ffa9b72b5bcfa68e0f643a4264
[20:02] <infinity> robru: Now if only that changelog entry related to a code change...
[20:03] <robru> yeah I'm poking around a bit...
[20:05] <infinity> ---- opencsg-1.3.2.orig/Makefile
[20:05] <infinity> -+++ opencsg-1.3.2/Makefile
[20:05] <infinity> -@@ -1,4 +1,4 @@
[20:05] <infinity> --SUBDIRS = glew src example
[20:05] <infinity> -+SUBDIRS = src example
[20:05] <infinity> -
[20:05] <infinity> Etc.
[20:06] <infinity> Check the debian-changes patch from the previous version.
[20:06] <infinity> Entirely possible none of that applied to the new version, hence they dropped it, but it might still be relevant in spirit and someone oopsed.
[20:13] <infinity> robru: If the above was gibberish, just debdiff 1.3.2 and 1.4.0, search for 'debian-changes', and go "oh, look at that".
[20:14] <robru> infinity: it took me a bit but I realized you were talking about the distropatch from 1.3, I see it now
[20:14] <infinity> robru: The maintainer was (a) disabling the bundled glew build, and (b) changing the link line to link slightly different sets of GLish libs.
[20:18] <robru> infinity: http://paste.ubuntu.com/12074203/ ok here's a diff of the patch. new version looks kinda fluffy (eg almost exclusively patching html files, no meat)
[20:18] <robru> infinity: so you're saying I should resurrect the old bits and try building with that?
[20:22] <robru> infinity: this isn't making a lot of sense, the Makefile in the new version no longer references glew at all, no SUBDIRS variable either.
[20:23] <infinity> robru: Right, the upstream build system no doubt changes substantially, leading the maintainer whose patch no longer applied to believe it was also no longer needed.
[20:23] <infinity> robru: s/changes/changed/
[20:24] <infinity> A fine argument for the patch having been written in an upstreamable way, adding a "--no-bundled-glew-you-twits" flag to the build system, so they could wash their hands of it and not mess up on rebase.
[20:24] <infinity> But oh well.  We're all guilty of not upstreaming as much as we should.
[20:24] <robru> right
[20:25] <robru> infinity: I guess what it comes down to is that I don't understand the new build system well enough to be able to identify how to disable building the bundled glew
[20:25] <robru> infinity: also that debian changelog entry seemed to imply the bundled glew wasn't building...
[20:26] <infinity> robru: Fair enough.  As our glorious leader pointed out, there are more important things to bang your head on anyway.
[20:26] <robru> ok
[20:26] <robru> I'll grab lunch and start fresh on something else then
[20:38] <slangasek> the list of outstanding transitions is now fairly short and this makes me suspicious
[20:39] <slangasek> I wonder if there are a bunch of boost revdeps tied up in the transition knot
[20:39] <infinity> slangasek: You guys have put in a ton of hours on this, maybe you actually just made progress?
[20:39] <infinity> Look at me and all my optimism.
[20:39] <slangasek> infinity: it's a shorter list of edge things than I would expect given that the transition hasn't yet gone through :)
[20:47] <cyphermox> infinity: slangasek: could one of you please respin Ubuntu desktop wily once more?
[20:47]  * cyphermox will need to go buy a bunch of new USB keys tonight or so
[20:50] <infinity> cyphermox: Sure.
[21:03] <robru> slangasek: alright, thoughts on what  should look at next?
[21:11] <cyphermox> ah, the livefs got broken because of the bluetooth transition :/
[21:38] <bdmurray> infinity: could you do some -proposed cleanup?
[21:40] <robru> sweet, upstream success https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795144
[21:52] <infinity> bdmurray: Yup.
[21:52] <infinity> bdmurray: Done.
[21:52] <bdmurray> Thanks
[21:59] <slangasek> robru: anything listed under 'blockers'...
[22:03] <robru> slangasek: ok so randomly I'm looking at python-launchpadlib. Why does the excuses page say "regression" when clicking through to the log doesn't show any ever passing?
[22:03] <robru> slangasek: eg here: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#simplejson
[22:06] <infinity> robru: Because this new infrastructure didn't import logs of old jenkins runs, but it did import state.
[22:06] <robru> ah
[22:07] <infinity> I suppose faking up old runs and importing logs might not be the worst idea, but scraping that all from jenkins would suck.
[22:22] <doko> slangasek, infinity: unrelated: what's holding up valgrind for trusty?
[22:22] <doko> and I'm unsure about the state of python3.4
[22:25] <infinity> doko: See the bug, arges commented on it.
[22:25] <infinity> doko: Short story, backporting from the devel series for SRUs is generally frowned upon, but if that's the best option, please also update vivid to match.
[22:26] <doko> infinity, bug number?
[22:26] <infinity> doko: I'll go a bit further though, and say is there a test plan to validate this?  Some things build-dep on valgrind for testsuites and such.  A 5MB diff is, obviously impossible to audit.
[22:26] <infinity> doko: https://bugs.launchpad.net/ubuntu/trusty/+source/valgrind/+bug/1386524
[22:27] <doko> ta
[22:27] <doko> infinity, honestly, I think valgrind isn't good enough for these things. we should find out how to use the sanitizers for that
[22:28] <infinity> doko: Perhaps, but that's not an answer for SRUs. :)
[22:29] <infinity> doko: At least, a PPA test of $(reverse-depends -r trusty -b src:valgrind) should be done, and we also need some what to know that $(reverse-depends -r trusty src:valgrind) don't break.
[22:29] <doko> infinity, I thought you were supposed to care about the ppc64el issues ...
[22:30] <infinity> doko: I care about ppc64el, but oddly enough, not at the expense of other arches.
[22:30] <infinity> doko: "valgrind sucks on ppc64el" is no excuse to shove in a new version without testing it doesn't break everything else.
[22:31] <infinity> Anyhow, commented on the bug.
[22:31] <infinity> doko: The upshot here is that this isn't a mass rebuild or something, it's dumping 20ish sources in a PPA and seeing how they do.
[22:32] <infinity> doko: The downside is testing the runtime rdeps, which aren't many, but I'm not sure how best to make sure they "don't break".
[22:32] <doko> infinity, can you do that?
[22:32] <infinity> doko: I can certainly do the "dump some stuff in a PPA" bit, sure.
[22:33] <infinity> doko: I'm less likely to agree to take ownership of it if any of them break. ;)
[22:33] <doko> thanks
[22:34] <doko> well, show me the results, and we'll see
[22:36] <infinity> doko: Give us a vivid upload to match (or backport the vivid one instead, if the wily one isn't actually needed), and I can set up the test PPAs.  I'll do it under toolchain-r, so you have access to them too.
[22:38] <doko> toolchain-r/test please
[22:38] <doko> infinity, please take the one proposed for trusty and rebuild it
[22:38] <infinity> doko: I was going to just create a new PPA, they're cheap.
[22:38] <doko> or that
[23:47] <robru> hey xnox, when you get a chance can you do a release for lp:launchpadlib? looks like trunk has a fix for the latest autopkgtest failures that are blocking some things in proposed.


[10:23] <davmor2> cjwatson: on oem install why is it that you have to type in you username where as in ubiquity a username gets put in automatically?
[10:24] <davmor2> on end user sorry not very clear
[10:30] <CIA-3> partman-base: cjwatson * r125 ubuntu/ (debian/changelog parted_server.c):
[10:30] <CIA-3> partman-base: Only mark the partition table as changed due to CHANGE_FILE_SYSTEM if it
[10:30] <CIA-3> partman-base: actually makes a change (i.e. the partition wasn't already using that
[10:30] <CIA-3> partman-base: filesystem or didn't have that flag set). This avoids the partition
[10:30] <CIA-3> partman-base: table being rewritten even if partman did nothing more than autousing
[10:30] <CIA-3> partman-base: swap (LP: #287660).
[10:32] <davmor2> cjwatson: I'm still having issues with kubuntu oem.  After the enduser details are in I hit forward and I just get a black screen still
[10:33] <davmor2> I'm trying it on mt all intel machine incase it's a nvidia thing and I'll try 32 bit too incase it's a 64bit issue
[10:40] <cjwatson> davmor2: there's an open bug about the username not being automatically filled in by oem-config's KDE frontend
[10:41] <davmor2> cjwatson: cool :) I'm still having issues with oem but I'll work through every option I can think of to see if any of them work
[10:42] <cjwatson> davmor2: TBH, it sounds like this is a Kubuntu or driver problem rather than something specifically wrong with oem-config
[10:42] <davmor2> I'm letting Riddell know as I work through them
[11:08] <davmor2> cjwatson: I just hit a-c-F1 to look for some logs for Riddell and there is a message about an issue with oem_config_dm (or something similar) and xserver timing out.  Which logs would be best to look at?
[11:18] <cjwatson> davmor2: /var/log/oem-config.log, /var/log/Xorg.*.log
[11:28] <davmor2> cjwatson: in oem-config.log at the end it says.  Fatal server error:(NL)  Server is already active for display 0 (NL) If this server is no longer running, remove /tmp/.X0-lock and start again. (NL)  a bit about contact x.org (NL) ddxSigGiveUp: Closing log
[11:29] <davmor2> (NL) = new line :)
[11:29] <davmor2> it repeats that 4 times
[12:06] <davmor2> cjwatson: oem install has worked fine on my all intel box
[12:53] <CIA-3> debian-installer: cjwatson * r1032 ubuntu/ (7 files in 2 dirs): Remove CD-specific language from boot screens (LP: #14722).
[13:16] <CIA-3> usb-creator: evand * r71 trunk/ (4 files in 3 dirs):
[13:16] <CIA-3> usb-creator: * Work around a long standing GTK label bug by using a Python version of
[13:16] <CIA-3> usb-creator: * libview's WrapLabel.
[14:51] <CIA-3> debian-installer: cjwatson * r1033 ubuntu/debian/changelog: releasing version 20081029ubuntu14
[15:34] <davmor2> evand, cjwatson:  Is there any reason why there is no encrypted home on Kubuntu desktop?
[15:37] <cjwatson> davmor2: requires separate implementation in the KDE frontend
[15:37] <davmor2> cjwatson: ah okay cool just wanted to check it wasn't an oversight :)
[17:13] <CIA-3> user-setup: evand * r149 ubuntu/ (debian/changelog user-setup-apply):
[17:13] <CIA-3> user-setup: chroot to get the mount passphrase and mount /sys and /dev/shm to
[17:13] <CIA-3> user-setup: support the encrypted home code.


[01:13] <C1t1z3n> hello
[01:13] <C1t1z3n> when i open transmition everything bug and i am not even able to close the computer.
[01:14] <C1t1z3n> i am not even able to log as sudo
[01:14] <C1t1z3n> it say dbus error
[01:15] <C1t1z3n> and everything start to shut down one by one and i can't restart them the computer don't even stop he just stop service after service...
[04:44] <C1t1z3n> how i reinstall transmission
[05:07] <axk4545> C1t1z3n: sudo apt-get install transmission-gtk in terminal.
[05:08] <axk4545> is there a way to make the xfce app finder behave like the the launcher in chromeos?
[05:14] <C1t1z3n> thx
[05:14] <C1t1z3n> that was only the -gtk that i was missing in the command ;)
[07:58] <jaspreet> hi i am facing wireless issue, can anybody help me solve it
[07:59] <jaspreet> i have realtek wifi card
[08:00] <jaspreet> it require rtl8723be driver, which is already there in system
[08:00] <jaspreet> but still not able to connect any wifi access point
[08:01] <jaspreet> i followed some solutions.
[08:01] <jaspreet> like cloned rtlwifi_new git repository and make install it reloaded driver again
[08:01] <jaspreet> but still it is not working
[11:06] <pezus> hi guys
[11:06] <pezus> my screen locking doesn't work after switching from 15.04 to 15.10
[11:07] <pezus> ctrl+alt+delete doesn't do anything anymore
[11:22] <Hund> pezus: Did you check the keyboard shortcuts? Maybe they got lost? :)
[11:22] <pezus> no they are there
[11:22] <pezus> it seems to be a problem with xfce-power-settings and the lightdm-locker
[11:34] <pezus> i "solved" it now by invoking gnome-locker-command -a
[12:12] <rigel_> my monitor's hardware key for menu selection is stuck. monitor is too bright. How do i turn it down? (using viewsonic if it helps)
[12:15] <rigel_> xrandr helps a bit, but it doesn't tone down the brightness of the monitor as well. (and redshift is more about the color warmth)
[12:15] <rigel_> s/mouse pointer/monitor
[13:36] <R13ose> How come xfce4 notifications don't do anything when I click show?
[14:05] <xubuntu76w> hi
[14:05] <R13ose> hi
[14:05] <xubuntu76w> how can i adjuest brighness in ubuntu
[14:06] <xubuntu76w> please tell me...is there any option to adjust brighness?
[14:06] <knome> patience please
[14:06] <xubuntu76w> ok
[14:08] <xubuntu76w> are you there?
[14:13] <xubuntu76w> someone will give me resolution?
[14:14] <xubuntu76w> please help me out to find the resolution..
[14:14] <xubuntu76w> please tell me...is there any option to adjust brighness?
[14:14] <R13ose> xubuntu76w: you have to wait, someone will ask if they know
[14:21] <knome> brightness of your display? is it a laptop?
[14:43] <R13ose> Any thoughts on my question?
[16:47] <mozmck> I notice that it says that Xubuntu 16.04 will not have a default media manager installed.  What exactly does that mean?
[16:48] <mozmck> I'm reading this on the blog here ->  http://xubuntu.org/blog/
[16:53] <flocculant> mozmck: it means that we're not seeding gmusicbrowser
[16:54] <mozmck> ok - I don't guess I use that.
[16:54] <mozmck> Seeding?
[16:55] <flocculant> putting it in the default iso
[17:31] <lerner> how do I change the mac address for wlan0 so my xubuntu remembers it, and I dont have to suco macchange every time I log in?
[17:32] <lerner> sudo*
[17:39] <Guest14090> can someonoe link me to dev channel?   i can never seen to find it
[17:40] <knome> not that quickly, no
[18:17] <xubuntu84w> xubuntu-dev is the developer channel right?
[18:19] <xubuntu84w> ?
[18:19] <knome> #xubuntu-devel
[18:19] <xubuntu84w> ty
[19:20] <RoadRunner> anybody home?
[21:00] <skafta> Good evening to all of you, i had a dual boot win7/xubuntu. when i booted yesterday it said "no surch partition ... grub rescue" - did i suddently lost my linux partition?
[21:03] <skafta> , i'm afraid the partition has deleted itself. does anyone know more? thank you very much !
[21:04] <skafta> ...because i took out the HDD and i'm browsing it with another computer. it only shows the windows files, but i don't see the ubuntu home folder
[23:14] <C1t1z3n> hello got a little problem when my battery is charging it never stop displaying a notification sayin my batterie is charging like every 2 or 3 min or so
[23:14] <C1t1z3n> is there a way to stop this
[23:16] <C1t1z3n> it also say that my battery is full charge then another notification that say my battery is charging but it is only at 94%
[23:16] <C1t1z3n> and it charge normally only the notification
[23:17] <knome> sounds like your battery/charger combination might have some physical contact issue
[23:18] <C1t1z3n> no it do that only on xfce not on other interface
[23:19] <C1t1z3n> it keep saying full charge but it also say charging...
[23:19] <C1t1z3n> and it is charging normally
[23:20] <C1t1z3n> and in fact only the notification say it is full charge the tray icon say 98%
[23:20] <C1t1z3n> right now
[23:21] <C1t1z3n> now it's full charge so no more problem
[23:21] <C1t1z3n> but how i can prevent this
[23:26] <knome> well, you can turn off the notifications completely
[23:30] <C1t1z3n> how
[23:32] <knome> click the applet and select power manager settings
[23:32] <knome> the setting is on the first tab
[23:33] <C1t1z3n> nothing happen
[23:33] <C1t1z3n> i can't go to  power manager when i click nothing happen
[23:33] <knome> which xubuntu version are you running?
[23:34] <C1t1z3n> i have the option but the option don't work
[23:35] <C1t1z3n> but i just find the other way to get to power manager
[23:35] <C1t1z3n> and just uncheck the notfication option
[23:35] <C1t1z3n> thx
[23:35] <C1t1z3n> i use xubuntu 14.04
[23:35] <C1t1z3n> ou.06
[23:35] <knome> ok, glad you got it fixed.
[23:35] <C1t1z3n> the current lts
[23:36] <C1t1z3n> but i logged to xfce not xubuntu


[15:50] <azepic819> ▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)mrkaz: chihchun_afk sbeattie lamont ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
[15:50] <azepic819> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)gpqrzcggyx: Guest87025 palasso flexiondotorg ▄▄▄▄▄▄▄▄▄▄▄▄▄▄
[15:50] <azepic819> ▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)yshieugid: stokachu kristbaum niemeyer ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
[15:50] <azepic819> ▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)rwvkcsmve: kristbaum jospoortvliet AmarokNelg ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
[15:50] <azepic819> ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)dynehh: Kaleo joedborg tianon ▄▄▄▄▄▄▄▄▄▄▄▄▄▄
[15:50] <palasso> JamieBennett ogra
[23:26] <mcphail> flexiondotorg: I saw you post about MATE welcome and boutique as snaps. Are snaps available on the Pi MATE image yet? It'd be a shame to break compatibility
[23:41] <flexiondotorg> mcphail: Not yet, but something I want to resolve for 18.04.
[23:52] <mcphail> flexiondotorg: brilliant. I was hoping that would be the answer!