[05:00] <pitti> Good morning
[05:02] <pitti> hallyn: "systemctl status" says "bad", looks like this unit wasn't actually installed, or has some error? Alias= are translated into symlinks at install time
[05:03] <pitti> stgraber: the libnl3 package caused many network-manager failures, so it got pulled after a quick discussion in #u-r; Adam later replaced trusty-updates with a reversion
[05:03] <pitti> stgraber: right, that wouldn't have helped users who already upgraded, only those who didn't yet
[05:09] <infinity> pitti: Should never delete without a revert.  The revert allows those who upgraded but didn't reboot to have a higher chance of being fixed before things go south.
[05:09] <infinity> pitti: Anyhow, thanks to stgraber's script freaking out, I went on the warpath to fix it all.
[05:10] <pitti> infinity: thanks! understood for next time (I ran out of time on Fri); i. e. I'll just leave it to some US folks right away next time
[05:11] <infinity> pitti: Yeah, acting quickly was good, but if you couldn't revert, nick highlighting (or given the severity, phoning) someone who can DTRT would help.
[05:11] <infinity> pitti: I suspect a whole lot of grandparents with broken networks phoned their grandkids over the weekend.
[05:11] <infinity> pitti: But hopefully it's mostly settled out by now. :/
[05:37] <sarnold> pitti: sorry to bother you directly, could you take a loot at my systemd timers for my archive sync? http://paste.ubuntu.com/16471760/
[05:38] <sarnold> pitti: the goal is to run the rsync, and once that's finished, run the zfs snapshots, then wait four hours before repeating
[05:38] <infinity> sarnold: Is it coincidence or intentional that 4h is the delay we use to trigger non-Canonical mirrors?
[05:39] <infinity> sarnold: (The followup question being "why don't you ask IS to trigger you?")
[05:39] <sarnold> infinity: I had the impression from IS that they only wanted to push-sync Big Mirrors and wanted everyone else to periodically pull
[05:39] <infinity> Perhaps so, yes.
[05:40] <sarnold> infinity: the 4hours was slightly informed by the "six times a day" mention I saw somewhere.. mostly I wanted lots of snapshots to work with in a hurry, and considered switching to five or six hours between syncs later on..
[05:41] <infinity> sarnold: Well, 4h is a good cadence if you're pulling from a tier2 mirror, since that's when we trigger them. :)
[05:41] <infinity> If you're pulling from archive.ubuntu.com, all bets are off, they update constantly.
[05:42] <sarnold> pulling from archive.ubuntu.com, it's remarkably speedy over rsync :)
[05:42] <infinity> Anyhow, I have no opinions on your units.  I still live in a mindset where replacing cron was silly.
[05:42] <sarnold> I even found the 'fast' IP address and did terrible terrible things with /etc/hosts that I'm not proud of.
[05:42] <infinity> Why mangle hosts?
[05:43] <sarnold> because one IP was five to ten times fsater than the others for me
[05:43] <infinity> rsync rsync://ip.add.re.ss::foo?
[05:43] <infinity> I mean, why bother pinning down the hostname instead of just using the IP.
[05:43] <infinity> rsync doesn't vhost.
[05:43] <sarnold> hmm. good point. :)
[05:43] <sarnold> thanks
[05:44] <cpaelzer> good morning
[05:44] <sarnold> re: replacing cron, believe me, I'm half tempted to return this to cron. but getting the one to run after the other finished, under two different user accounts, seemed like a worthwhile enough feature to try out
[05:44] <sarnold> morning cpaelzer :)
[05:44] <infinity> sarnold: Alternately, it might be that what you're looking for is "us.archive.ubuntu.com" :P
[05:45] <infinity> For reasons I've never fully understood, archive.u.c is a round-robin of gb and us.
[05:45] <infinity> So its usefulness fluctuates based on time of day and phase of moon.
[05:46] <sarnold> infinity: even within the us hosts one was way faster than the other
[05:46] <infinity> sarnold: Curious.
[05:46] <infinity> sarnold: IS might want to know about that.  Pretty sure they sit on the same VLAN.  Probably the same switch on the same rack even.  If one sucks, that's odd.
[05:46] <sarnold> especially since I saw roughly no difference between mtr results between the two. the fast one was 85 ms away, the slow one 80 ms away, and stddev was <5 ms on both
[05:47] <sarnold> infinity: they are actually on different routers and different uplinks
[05:47] <pitti> sarnold: the main issue is that you don't want to use a .target for those
[05:48] <pitti> sarnold: as the .target is never stopped (there is no such thing as an "oneshot target", this doesn't make sense)
[05:48] <pitti> sarnold: so once it's running, the timer won't do anything any more
[05:48] <sarnold> pitti: ah :)
[05:48] <infinity> sarnold: Hrm.  Not from me, they aren't.
[05:48] <sarnold> infinity: hmm.
[05:48] <pitti> sarnold: so, drop the .target, have the .timer trigger the rsync unit, and have that Requires/Before= the snapshot unit
[05:49] <pitti> sarnold: and as both are oneshot, they will be restarted on the next timer
[05:49] <pitti> sarnold: also, you don't need to add Before= to one and After= to the other, once is enough
[05:49] <sarnold> infinity: <IP_ADDRESS> was the fastest -- <IP_ADDRESS> was the slowest.
[05:50] <sarnold> pitti: excellent, good to know, I thought it seemed inelegant for Before/After to be anything except duals of each other, but that forum post was so sure.. (I should have known. :)
[05:51] <infinity> sarnold: Very weird indeed.  I have identical routes to both.  Under severe load, economy would probably be faster due to being a slightly larger machine, but I'm not sure they have enough outbound bandwidth to actually cripple them.
[05:51]  * infinity shrugs.
[05:52] <sarnold> infinity: .23 would routinely give me 4-8 MBps, .26 would routinely give me 120KBps.
[05:52] <infinity> sarnold: Ouch.
[05:52] <infinity> sarnold: If that's reproducible, I suspect IS would definitely like to know.
[05:53] <sarnold> ..especially since I wanted to see ~50MBps from these things :) heh
[05:53]  * pitti needs to disappear for a few hours for a long appointment
[05:53] <sarnold> pitti: thanks for the help
[05:54] <infinity> pitti: Have fun storming the castle.
[06:25] <ginggs> morning! freecad doesn't want to migrate because freecad-doc (arch:all) was dropped. would someone decruft please?
[07:03] <infinity> ginggs: Done.
[07:04] <ginggs> infinity: thanks!
[08:53] <sil2100> cjwatson: hey! We had the 503 again during two image builds - is there a way to re-try those builds somehow?
[08:53] <sil2100> cjwatson: since essentially the livefs builds succeeded, would be a waste of time to rebuild those from scratch
[08:54] <sil2100> cjwatson: also, it's a bit worrying that it happens so frequently recently, in the past I don't remember it happening even once
[09:13] <cjwatson> sil2100: as cdimage@nusakan, run the usual build command (you can get it from cdimage/etc/crontab) but without --live
[09:13] <sil2100> Oh, ok
[09:13] <sil2100> Good to know, thanks!
[10:17] <brendand> why would it be the case that lxdbr0 isn't visible in ifconfig, after i've run lxd init?
[10:17] <brendand> i have of course specified to set up networking
[10:27] <juliank> infinity: Coverage report for APT https://apt.alioth.debian.org/coverage/index.html :D
[10:31] <pitti> brendand: what does "systemctl status lxd-bridge.service" say?
[10:32] <pitti> brendand: note that both lxd.service itself and also the bridge are only started on demand (via socket activation)
[10:32] <pitti> brendand: i. e. you won't actually see the bridge up until you try to start your first container
[10:36] <brendand> pitti, hi btw!
[10:36] <pitti> hey brendand, how are you?
[10:37] <brendand> pitti, i'm good. you know i'm back on the inside, right?
[10:37] <pitti> brendand: yeah, I read it on the ML; welcome back!
[10:37] <brendand> ok, didn't realise it only starts with the containers
[10:37] <pitti> brendand: you didn't hold up on the outside for very long :)
[10:38] <brendand> pitti, yep joining the same club as such luminaries as xnox and mvo :)
[10:38]  * pitti waves to lamont to :)
[10:38] <brendand> pitti, no, unfortunately it didn't last long at all - or fortunately maybe!
[10:38] <brendand> pitti, oh lamont too, heh - he's on my team
[10:39] <Laney> the outside world is that bad eh?
[10:40] <brendand> Laney, yeah it's a dark and scary place
[10:42] <brendand> pitti, so it looks like: http://paste.ubuntu.com/16473414/
[10:43] <brendand> green is good
[10:43] <brendand> but 'failed to setup lxd-bridge' seems bad
[10:44] <pitti> right, so lxd-bridge.start should not succeed in this case
[10:48] <brendand> i feel like i did something very bad to my lxd. even launch doesn't work
[11:12] <farblue> hi all :) Maybe not the right channel to ask but I'm working with fan networking and wondered if anyone knew why the docs suggest docker should be configured with iptables=false when using fan networking
[11:17] <xnox> brendand, so you are the new Yo-Yo =) as elmo called me the other day.
[11:35] <farblue> anyone here know about fan networking?
[11:37] <sladen> farblue: sorry know.  A possible reason for disabling iptables is that iptables is already being used to perform the static-nat that FAN-network requries
[11:38] <sladen> farblue: however, I would stress that I don't know, and it's not something I've ever used
[11:39] <farblue> ok, that makes some sense. I’m struggling to work out what the problem is but while my containers can talk to each other and the host can talk to them, they don’t seem able to talk to the outside world :(
[11:39] <sladen> farblue: isn't that the point :)
[11:41] <farblue> well, no, not really. I don’t want anything other than the docker hosts to be able to talk to the containers but it is quite useful for containers to be able to talk out to other services
[11:41] <sladen> kirkland: you are quoted on the PR for the fan-networking/OpenStack stuff.  If you're around, would you be able to follow-up with farblue
[11:43]  * sladen reads with amusement "There are several class A network addresses reserved for Class E".  No, there are several /8s reserved for Class E.
[11:43] <farblue> I think half the problem is that docker does all this ‘magic’ stuff under the hood and I strongly suspect turning off iptables in the docker config does more than expected
[11:45] <sladen> farblue: nb. kirkland is normally on US time, so likely to be around later rather than now
[11:46] <farblue> ok, I’ll keep working on the problem and ask again later :)
[11:48] <sladen> farblue: yes, but please stay on IRC!
[11:48] <farblue> sure :)
[11:49] <farblue> if iptables management is disabled in docker then it doesn’t create the iptables FORWARD rules or create the DOCKER chain or the DOCKER-ISOLATION chain and it doesn’t add the PREROUTING rules - which I suspect is rather more than I need disabled
[13:35] <barry> Laney: hi.  have you had a chance to look at the libpeas PPA?
[13:36] <Laney> hi barry, not yet
[13:36] <Laney> I'll let you know
[13:36] <Laney> inside CSS currently
[13:36] <barry> Laney: cool, no worries
[13:36] <barry> and thanks!
[13:49] <rharper> infinity: pitti: so for the nm/libnl cluster;  where did I mess up in the process?  in the libnl bug, once we found out the nm break happened in -proposed, I built an update (attached v3 of the debdiff to the bug) and requested a sponser;  I can't upload myself.
[13:51] <rbasak> rharper: I think it was adding verification-done. This implies that it's OK to copy the current version in -proposed to -updates.
[13:52] <rharper> rbasak: hrm, yes;  I was pretty sure that we tested proposed; that we had unbroken proposed
[13:52] <rharper> which I thought meant that v3 was in proposed already
[13:53] <rharper> that is, I had to create the v3 with Breaks to *unbreak* anyone testing proposed;
[13:54] <rharper> and ISTR that someone helped unbreak proposed by uploading the  newer version;  but maybe that didn't happen in which case changing the tag wasn't correct;
[13:54] <rbasak> I understand how it went wrong - lots of moving pieces, especially when complicated by the extra coordination needed by sponsorship.
[13:55] <rbasak> I'd say that marking verification-done needs double checking of everything, including what version is where and that everything known is accounted for (in this case the Breaks, together with everything else).
[13:56] <rbasak> I wonder if it would be better to mark verification-failed and start again in this sort of case, to reduce the chance of error.
[13:57] <rharper> rbasak: so, where would I check to ensure the right versions are in place?  pulling the Packages version from the the archive ?
[13:57] <rharper> rbasak: as in start a new bug?  wading back into those it's quite a lot to take in after one has paged it out of memory context
[13:58] <rbasak> rharper: rmadison, or https://launchpad.net/ubuntu/+source/libnl3 etc. That should tell you what version of what is where, and sometimes Launchpad has useful diffs to show you to save you downloading and checking.
[13:58] <rharper> rbasak: cool
[13:58] <rbasak> rharper: not necessarily starting a new bug, but marking verification-failed, having the SRU team delete from -proposed, and re-uploading new fixes or something. That's what I was thinking. I don't know if this is a good idea or not in general, but I feel that it might have reduced the probability of error in this particular case.
[13:59] <rharper> ah
[14:02] <pitti> rharper: I think that should have come up during testing, and indeed I considered teh v-done as "good enough" (when mass-processing SRUs I don't/can't check every detail again)
[14:03] <pitti> rharper: not easy to put a finger on a particular point in the process, it was sort of an emergent corner case between sponsoring, verification, and not prodding about removing a known-bad proposed version
[14:03] <pitti> rharper: i. e. the half-done version should have been removed from the queue, or marked as v-failed after accepting into -proposed, I think
[14:04] <rharper> pitti: yeah; I think not being able to make those changes myself makes things harder since a sponsor has to grok all of what happened as well;
[14:05] <rbasak> rharper: thank you for asking the question BTW. respect++.
[14:05] <pitti> rharper: everyone can mark as v-failed, and everyone needs to prod the archive admins about dropping an upload from the queue
[14:06] <pitti> rbasak: indeed, echoing rbasak; thanks for thinking about the post-mortem
[14:06] <rharper> rbasak: only way to learn =)  also; I felt really bad since it happened while I was out; everyone here was putting out a fire I started.  =(
[14:06] <hallyn> pitti: could the 'systemctl status' -> 'bad' error be related to bug 1579922 ?
[14:07] <pitti> hallyn: yes, very plausibly
[14:07] <pitti> hallyn: I did see teh report and your call for feedback; didn't get to that yet, sorry
[14:09] <hallyn> np.  i assume it has to do with the manual work i do in libvirt-bin.preinst, i suspect i should move another file or something.
[14:09] <rbasak> pitti: it still feels wrong that there's only one person standing in the way of failure here though. Do we need more staffing on the SRU team so closer reviews are possible before accepting v-done?
[14:09] <hallyn> i didn't get around to reproducing with a set of empty dummy packages
[14:09] <pitti> rbasak: not really realistic, I think
[14:10] <pitti> second-guessing v-done would mean a wholly new second v-really-done, and that's pointless as it doesn't add anything new
[14:10] <pitti> rbasak: in this case, more testing results from "real users" would have helped
[14:11] <rbasak> I'm thinking something like "<random> v-done; I checked X and Y"; "<SRU> <reviews what should be checked> what about Z?"
[14:11] <pitti> rbasak: and we run the SRU process under the assumption that some folks run -proposed and report regressions
[14:11] <pitti> which apparently didn't happen despite this being in -proposed for like half a year
[14:11] <rbasak> So trusting results from v-done, but confirming that the right things were checked.
[14:11] <rbasak> In this case we all knew what was needed, so I don't think additional testing would have helped.
[14:12] <rbasak> What I think we needed was clarity over what we already knew.
[14:12] <rbasak> (between us)
[14:12] <pitti> rbasak: to me as an SRU process guy it wasn't at all obvious from this bug that this broke NM
[14:12] <pitti> it was supposed to fix NM :)
[14:12] <rbasak> Well, it fixed libnl3 but exposed a bug in NM.
[14:13] <rbasak> pitti: how about a tag to say "this is complex, needs two full reviewers please?"
[14:13] <rbasak> Most SRUs are trivial compared to this one.
[14:14] <pitti> yeah, SRUs depending on each other are rare
[14:14] <pitti> which is probably why it's easy to forget to add Depends:/Breaks:
[14:14] <rbasak> Doesn't even need SRU team. Just another uploader.
[14:15] <pitti> and given enough luck (installing NM first), even ten testers would have confirmed it works
[14:15] <pitti> the root cause was to introduce a change that depended on a change in NM without saying so
[14:15] <rharper> pitti: we didn't know it broke NM until we uploaded to -proposed; mostly because the testing done was on server (with no NM);
[14:15] <pitti> and that most probably wasn't even known initially
[14:15] <pitti> exactly
[14:15] <rbasak> Another issue is that after the initial problem was revealed, we told testers that we knew about the issue.
[14:16] <pitti> at that point we should have marked this as v-failed
[14:16] <pitti> or ask an AA to pull the package
[14:16] <rbasak> After that test results become muddled because we don't know if the tester accounted for the original regression proposed or not. They might fail the new version but not report because they think we already know because of the failure in the initial version.
[14:17] <rbasak> Yeah. I guess one simple thing to do is to delete from -proposed immediately if we know that it isn't suitable to land in -updates.
[14:17] <rbasak> And if that isn't immediate (eg. SRU team member online to immediately help with a replacement), then v-failed.
[14:18] <pitti> that or tagging v-failed, which can be done by everyone
[14:29] <juliank> infinity: pitti (?): bdmurray (?): Looking for endorsements on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU (or could I rather apply for core-dev?).
[14:31] <juliank> mvo is not here, which is somewhat unfortunate
[14:33]  * juliank contributes in somewhat unusual ways, so there is not that much evidence of what he does (mostly just told mvo to syncpackage something)
[14:35] <seb128> could somebody from the SRU team look at unity-control-center / unity-settings-daemon in the xenial queue? they are small patches and things the oem team is wanting
[14:48] <juliank> Anyone thought about AppArmor profiles for APT's http and https methods? I'm currently implementing seccomp for the former, but I thought it might make sense to also get some AppArmor safety (not an expert on that, though)
[14:51] <juliank> I should probably also chroot() the method into the partial dir
[14:51] <rbasak> juliank: that sounds like a good idea. AIUI those run in separate processes so should be fairly easy to do?
[14:52] <juliank> rbasak: I think the problem is that it's not clear where they are fetching to. APT has CWD, /var/lib/apt/lists/partial and /var/cache/apt/archives/partial
[14:52] <juliank> But some other programs also use them to fetch stuff into other dirs
[14:53] <rbasak> I see.
[14:53] <juliank> Also we have proxy scripts we need to run :/
[14:53] <juliank> But we could at least use AppArmor to protect against writes to /usr and friends
[14:55] <rbasak> That would certainly be a useful start.
[14:57] <juliank> Although: They currently cannot do that anyway (under normal circumstances) since they run as a separate user
[15:33] <nacc> rbasak: still around?
[15:57] <coreycb> arges, hi, regarding the neutron-* stable release for xenial bug 1580674.
[15:58] <coreycb> xenial and yakkety are currently at 8.0.0-0ubuntu1
[15:59] <coreycb> upstream will release the first beta of 9.0.0 for newton in two weeks which we'll then upload to yakkety
[15:59] <coreycb> ara, can we get an exception to upload the stable release to xenial before that?
[15:59] <coreycb> arges, ^  (sorry ara)
[15:59] <ara> coreycb, no worries :)
[16:19] <infinity> rharper: Absolutely what went wrong is that it should have been marked v-failed, not v-done.
[16:19] <infinity> rharper: It would have flipped back to v-needed when the new version was uploaded (which never happened).
[16:34] <bdmurray> pitti: wrt bug 1446537, would it be possible to tag bugs apport-hook-error that have an attachment named "HookError.*" so it is easier to find issues like this?
[16:48] <farblue> I’m still working with the fan networking and it seems to me that a docker container on the fan network doesn’t have a route out of the fan unless you enable iptables management in docker
[16:51] <farblue> could it be because the fan network is overlay’d on top of a physical ethernet interface that doesn’t actually have a route out anywhere?
[16:51] <farblue> anyhow, home time for me now.
[17:04] <arges> coreycb: i'm not sure what exception you mean. the version in xenial can't be >> than the version in yakkety
[17:10] <coreycb> arges, ok I wasn't sure if there were any exceptions to that rule.  we can probably upload the xenial version to yakkety for the next 2 weeks.
[17:36] <kirkland> farblue: hi -- you're interested in fan networking?
[18:07] <coreycb> arges, can you reject the mitaka neutron* uploads?  there are 4 packages for 8.1.0-0ubuntu1.
[18:07] <coreycb> arges, these are for xenial
[18:09] <arges> coreycb: ok
[18:10] <arges> done
[18:10] <coreycb> arges, thx
[18:39] <bdmurray> pitti: I ended up pushing a change to the ubuntu hook to the yakkety branch of apport re apport-hook-error
[18:42] <sarnold> pitti: thanks for your help yesterday, my timer ran twice without trouble since then :)
[19:05] <rharper> infinity: ok; thanks
[20:03] <shadeslayer> chrisccoulson: hi, I was wondering, https://launchpadlibrarian.net/259046127/firefox_46.0.1+build1-0ubuntu<IP_ADDRESS>_46.0.1+build1-0ubuntu<IP_ADDRESS>.diff.gz seems to have extra things that are not present in https://code.launchpad.net/~mozillateam/firefox/firefox.xenial
[20:04] <shadeslayer> could you please update the branch? :)
[20:05] <shadeslayer> chrisccoulson: specifically : https://bazaar.launchpad.net/~mozillateam/firefox/firefox.precise/revision/1070
[21:25] <karstensrage> are there any backporters that can help with  #1562434 and #1561837
[21:26] <karstensrage> ive tested them up the wazoo with ppa's and vms
[21:26] <karstensrage> they are a library and a pam module so im not sure how to propagate that information
[21:27] <karstensrage> and its already in xenial, tested and working
[21:28] <karstensrage> i will help anyone with configuring PAM in some way and credentials are required that can be provided as well
[21:54] <karstensrage> or is there someone that would consider testing so that the backporter doesnt have to just take my word for it?
[22:01] <karstensrage> debfx, you possibly, youre the newest approved backporter?
[22:03] <karstensrage> Laney? broder?
[22:03] <sarnold> bueller?
[22:04] <karstensrage> it sure feels like that
[22:05] <Unit193> Tempting to try getting a backport instead of SRU, because the former seems easier and more likely. >_>
[22:07] <karstensrage> SRU?
[22:07] <sarnold> stable release update
[22:07] <Unit193> karstensrage: Different matter at hand, but st..dang.
[22:07] <sarnold> the process for updating existing packages in published releases
[22:07] <karstensrage> getting it in xenial proposed was easy
[22:08] <karstensrage> getting a backport is proving frustratingly impossible
[22:08] <Unit193> karstensrage: FWIW, part of that is limited number of backporters too, iirc.
[22:08] <karstensrage> yeah ive heard it all
[22:09] <Unit193> LP 1582713, LP 1562358.
[22:16] <mapreri> I wonder, is a SRU acceptable just to fix an appstream issue (including bigger icons)?  my pet package is not showing up in that gnome-software thinghy allegedly for this...
[22:20] <sarnold> mapreri: it looks sort of like the infrastructure should be there, there's icons-* appstream packages in the -updates, -security, and -proposed pockets
[22:20] <sarnold> s/packages/blobs/
[22:21] <mapreri> well, that's what I'd expect from an archive that supports DEP-11, I'd be surprised if those files weren't there.


[00:09] <cupped> euler
[00:09] <cupped> whoops
[00:43] <is_> Hey guys, I found what seems to be a minor security issue, but I'm not entirely sure if it is or not, and I don't really know where to report either
[15:32] <drcooper> Any member of Ubuntu Bug Control please set https://bugs.launchpad.net/unity/+bug/666768 to wishlist
[15:32] <ubot2> Launchpad bug 666768 in unity "Make sidebar translucent (affects: 1) (heat: 6)" [Undecided,New]
[15:34] <hggdh> drcooper: this is not an Ubuntu bug (yes, it is Unity, but the *upstream* Unity. We cannot deal with it, sorry
[15:35] <drcooper> hggdh: ok..
[15:51] <drcooper> https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/666746
[15:51] <ubot2> Launchpad bug 666746 in gnome-screensaver (Ubuntu) "Screen locked after hibernate (affects: 1) (heat: 6)" [Undecided,New]
[15:51] <drcooper> which package should this bug be associated to
[16:01] <drcooper> which package should the 666746 bug be associated to? new to bug squad pls help
[16:01] <rusivi> bug 666746
[16:01] <ubot2> Launchpad bug 666746 in gnome-screensaver (Ubuntu) "Screen locked after hibernate (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/666746
[16:04] <rusivi> drcooper: You nailed it for now. I'll quickly test to get it confirmed.
[16:05] <drcooper> rusivi: it was not reported by me...i doubt if it should be reported as a gnome-screensaver bug
[16:06] <drcooper> rusivi: i think it affects pm-utils package or something like that
[16:06] <micahg> bug #?
[16:07] <rusivi> bug 666746
[16:07] <ubot2> Launchpad bug 666746 in gnome-screensaver (Ubuntu) "Screen locked after hibernate (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/666746
[16:08] <rusivi> micahg / drcooper: I already found?! another bug in Maverick -> System -> Admin -> Login Settings, I did not have the opportunity to auto-login as my originally created user account :D
[16:08] <micahg> rusivi: I think that should stay in gnome-screensaver since the settings aren't being honored
[16:09] <rusivi> micahg: Agreed.
[16:09] <rusivi> micahg: What do you think about the Login Settings "bug" is that intentional or buggable?
[16:10] <micahg> rusivi: the setting might have moved, maybe check in #ubuntu before filing
[16:10] <drcooper> micahg: rusivi but how would hibernation be related to screensaver settings
[16:11] <micahg> drcooper: I've actually been experiencing a bug where my screensaver is activated after resume as well, but I actually use the lock feature, if the setting says don't require a password ever, then that should be respected, there might be 2 bugs in fact
[16:12]  * micahg seems to recall a setting for no password on resume as well
[16:12] <drcooper> micahg: thats debatable as u set LOCK screen to be enabled
[16:13] <drcooper> micahg: there should be some lock
[16:13] <drcooper> :D
[16:16] <drcooper> micahg: rusivi i think its apt to confirm the bug
[16:16]  * micahg would suggest someone reproducing it :)
[16:17] <drcooper> micahg: yes it does happen that way
[16:17] <drcooper> micahg: i tried
[16:18] <micahg> drcooper: feel free to confirm then explaining what you did
[16:20] <rusivi> drcooper: you beat me to the punch :P hehe
[16:20]  * micahg found an upstream bug
[16:20] <drcooper> rusivi: ?
[16:20] <rusivi> drcooper: jk
[16:20] <drcooper> rusivi: again ?
[16:20] <rusivi> drcooper: I'm a jokster don't mind me.
[16:21] <micahg> are you both using the same version of gnome-screensaver as the reporter?
[16:23] <drcooper> micahg: yes
[16:25] <micahg> drcooper: does the gconf key mentioned in the upstream bug help?
[16:27] <drcooper> micahg: sorry, did not get you
[16:27] <micahg> drcooper: I linked an upstream bug to the LP bug, can you read that and see if the gconf key helps
[16:34] <micahg> rusivi: can you try the gconf key?
[16:36] <drcooper> micahg: setting the key fixed it !!
[16:36] <drcooper> micahg: so what shud be done with the bug
[16:36] <micahg> drcooper: :), well that's good news, I'll post to the upstream bug, maybe it can be fixed
[16:36] <micahg> drcooper: thanks
[16:37] <micahg> drcooper: this one? /desktop/gnome/lockdown/disable_lock_screen=true
[16:37] <rusivi> micahg: Let me check it out
[16:37] <drcooper> micahg: yaes
[16:37] <micahg> rusivi: 'tis ok
[16:37] <micahg> drcooper: thanks
[16:39] <rusivi> micahg: Regarding /desktop/gnome/lockdown that's a little over my head, where do I go to find that file/folder?!
[16:39] <micahg> rusivi: you need to use gconf-editor, it's already been confirmed, so you don't need to do it unless you want the fix
[16:45] <drcooper> micahg: so thats how a bug is triaged !! :D
[16:45] <micahg> drcooper: one way :)
[16:46] <drcooper> micahg: turns out to be my first experience
[16:46] <micahg> drcooper: cool, well thank you for confirming
[16:47] <micahg> drcooper: generally, it makes it to triaged where there is enough information to reproduce and it's a confirmed bug (upstream bug link almost always makes a bug triaged)
[16:47] <drcooper> micahg: ohhk..
[17:22] <mreiter> Hi, I filed a bug about failing hibernation on Thinkpads in 10.10 and I think it is ready to be triaged according to the wiki (https://wiki.ubuntu.com/Bugs/HowToTriage/). Could some Bug Control member maybe have a look and triage it? Here's the bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/661711
[17:22] <ubot2> Launchpad bug 661711 in linux (Ubuntu) "Hibernate fails on Thinkpads (affects: 9) (heat: 54)" [Undecided,Confirmed]
[17:27] <mreiter> I really did everything I could to make the report as complete as possible and according to the criteria in the wiki, the report is ready to be triaged. I can't do it, because I'm not a member of Bug Control. The wiki says to ask here in this case. It would be really awesome if this get fixed and it shouldn't be difficult, because I am not able to reproduce the bug with a newer kernel version...
[17:39] <micahg> drcooper: duplicate bug? bug
[17:39] <micahg> bug 599783
[17:39] <ubot2> Launchpad bug 599783 in gnome-control-center (Ubuntu) (and 1 other project) "proxy capplet is not IPv6 aware (affects: 1) (heat: 32)" [Low,Triaged] https://launchpad.net/bugs/599783
[17:42] <sense> drcooper: Seems indeed duplicate
[17:42] <drcooper> yup
[17:42] <micahg> drcooper: you can mark it a duplicate, please use the response on the responses page
[17:43] <sense> drcooper: Do you know how to mark a bug as a duplicate?
[17:43] <drcooper> sense mark as dulicate right?
[17:43] <sense> drcooper: THere is a list of stock responses at <http://wiki.ubuntu.com/Bugs/Responses> you can use when responding to bug reports, it saves you some time.
[17:43] <sense> drcooper: yes.
[17:52] <micahg> drcooper: it's good to make a comment when marking as a duplicate using the response from the responses page sense gave you
[17:52] <drcooper> micahg: as a comment before marking as duplicate?
[17:52] <micahg> drcooper: yes
[17:52] <drcooper> micahg: can i add it now
[17:52] <micahg> drcooper: yes
[17:53]  * micahg will be back later
[19:19] <BUGa_badmood> o/
[19:26] <JimmyJohn> Hey, I think this bug has been reported before but I'm not sure. I'm on a toshiba satellite e205 s1904 and can't finish installing. gives me a "child_rip" error and just halts, reading 0x0 0x20
[19:26] <JimmyJohn> I got it to go farther and actually got ubuntu to boot once by turning off acpi but it won't work again
[19:26] <JimmyJohn> it crashed after that anyway
[19:28] <JimmyJohn> Anybody know anything about this?
[19:30] <mrand> JimmyJohn: Google turns this up: http://ubuntuforums.org/showthread.php?t=1496796, which seems to imply it isn't a bug with Ubuntu.
[19:32] <JimmyJohn> but it also turns this up
[19:32] <JimmyJohn> http://ubuntuforums.org/showthread.php?t=1445892
[19:32] <JimmyJohn> and the OP isn't even on a toshiba. not to mention i've checked the site, no bios updates
[19:37] <mrand> Many computer vendors use the same chipsets and BIOS, so I don't think it much matters that it isn't toshiba specific.  The first thread links to a bug which then points to a work-around (kernel patch)
[19:40] <JimmyJohn> would you mind telling me what I'm supposed to do with that? I'm at the link from the first thread.
[19:46] <mrand> JimmyJohn: short of compiling your own kernel with that patch and/or continuing going down the  acpi route, unfortunately the answer appears to be that the bug in the BIOS is blocking your computer, and many like it, from properly using Linux.
[19:46] <mrand> down the non-acpi, that is.
[19:47] <JimmyJohn> I think i just got a kernel from a guy. He posted it in one of the linked threads, after compiling it, so now i have a .deb and a .patch, i just don't know what to do with them. Others are saying this fixed it though
[19:50] <JimmyJohn> ?
[19:52] <mrand> JimmyJohn: .deb are normally installed with dpkg.  Not sure what you would do with the .patch.  You might try asking on #Ubuntu.  this channel is more discussing the process and processing of bugs rather than debugging.
[20:27] <guntbert> what is the meaning of "One Hundred Paper Cuts" ?
[20:28] <BUGa_badmood> quick fixes
[20:30] <guntbert> BUGa_badmood: thx -- if your nick is "true" I won't bother you any more :-)
[20:32] <BUGa_badmood> guntbert: in a bad mood, cause I missed the delivery guy
[20:32] <BUGa_badmood> now will have to wait another day to get my hands on my new Desire HD
[20:32] <hggdh> heh
[20:32] <RedSingularity> lol HATE when that happens!
[20:32] <guntbert> BUGa_badmood: sorry to hear - no neighbors around to take it for you?
[20:33] <BUGa_badmood> they don't do that
[20:33] <BUGa_badmood> its a 500+€ piece
[20:33] <BUGa_badmood> no leaving on the neibour
[20:34] <guntbert> understandable
[20:34] <guntbert> but back to my question: is there anyplace to read up on the "One Hundred Paper Cuts"?
[20:37] <rusivi> guntbert: https://wiki.ubuntu.com/PaperCut
[20:37] <guntbert> rusivi: thx
[21:08] <guntbert> about https://wiki.ubuntu.com/Bugs/CommonTasks  : there is stated about kernel bugs that "For Hardy (8.04) - Lucid (10.04) the correct package is linux". I guess that is/will be true for current and future releases as well. I f no one objects I'm going to change that to "For Hardy (8.04) and later releases the correct ..."
[21:13] <rusivi> guntbert: Sounds good.
[21:18] <guntbert> rusivi: done
[21:22] <njin> hello, there's a finnish here to triage this ? https://bugs.launchpad.net/ubuntu/+bug/431922
[21:22] <ubot2> Launchpad bug 431922 in ubuntu "dead_stroke broken in some applications (affects: 1) (heat: 8)" [Undecided,Incomplete]
[21:38] <MoLE_> Quiet in here - everyone must be at UDS
[21:38] <MoLE_> any suggestions on how to advance bug 558431 ?
[21:38] <ubot2> Launchpad bug 558431 in parted (Ubuntu) (and 3 other projects) "gparted crashes at startup - Assertion failed (affects: 20) (dups: 3) (heat: 100)" [Undecided,Confirmed] https://launchpad.net/bugs/558431
[22:37] <RedSingularity> micahg:  are you going to address bug 643736 or should i move my comment about wish-listing there?
[22:37] <ubot2> Launchpad bug 643736 in thunderbird (Ubuntu) ""What's new in Thunderbird 3" reappears on minor upgrades (affects: 1) (heat: 102)" [Undecided,New] https://launchpad.net/bugs/643736
[22:38] <micahg> RedSingularity: yes, I think I'll mark it won't fix though
[22:39] <RedSingularity> micahg: for which bug?
[22:39] <micahg> RedSingularity: the one you just said
[22:40] <RedSingularity> micahg:  your going to handle the other one about 2.0 migration?
[22:40] <micahg> RedSingularity: yes, when the user replies
[22:40] <RedSingularity> micahg: ok
[22:43] <micahg> RedSingularity: nm, I found an upstream bug
[22:44] <micahg> RedSingularity: why did you post an apport-collect message on bug 643736?
[22:44] <ubot2> Launchpad bug 643736 in thunderbird (Ubuntu) (and 1 other project) ""What's new in Thunderbird 3" reappears on minor upgrades (affects: 1) (heat: 8)" [Wishlist,Triaged] https://launchpad.net/bugs/643736
[22:44] <RedSingularity> micahg:  get more info about the system
[22:44] <micahg> RedSingularity: there is no more information
[22:45] <RedSingularity> micahg:  damn, i didnt even notice he used apport to report it at first.
[22:46] <RedSingularity> micahg:  telling him to disregard
[22:48] <RedSingularity> micahg:  you notified mozilla team?
[22:48] <micahg> RedSingularity: huh?
[22:48] <RedSingularity> micahg:  it says assigned to mozilla bugs
[22:48] <micahg> RedSingularity: that means it's linked to an upstream bug
[22:49] <RedSingularity> micahg: alright
[22:49] <RedSingularity> micahg: marking as "wont fix"?
[22:49] <micahg> RedSingularity: huh?
[22:49] <micahg> RedSingularity: I changed my mind as I noted above
[22:50] <RedSingularity> micahg: oh you did link it....ok


[00:53] <ratman> buenas
[00:53] <magu42> como va ratman
[01:22]  * magu42 is away: ~
[02:06]  * magu42 is back (gone 00:44:48)


[14:36] <sadmac2> Keybuk: release day, is it?
[14:38] <Keybuk> yesterday
[14:39] <sadmac2> o rite
[14:39]  * sadmac2 's concept of time has been having some issues
[14:39] <sadmac2> today is friday
[14:39] <sadmac2> right
[14:46] <Keybuk> right
[14:49] <Keybuk> today is the first day of planning for 9.04
[14:51] <sadmac2> suggestion: more cowbell
[14:52] <suihkulokki> apt-get moo
[14:56] <sadmac2> suihkulokki: I did that, but its not enough
[14:56] <sadmac2> suihkulokki: I got a fever, and the only cure is more cowbell


[01:14] <Rjones> hello
[01:15] <Rjones> hi there!
[01:15] <learnbsd> Rjones: hi
[02:09] <bregma> muka, if an X11 app running in libertine was designed to zoom in/out, then you can zoom in/out with it
[02:09] <bregma> but there is nothing in the Unity 8 shell at the moment that will allow you to zoom in/out on arbitrary windows
[02:22] <duflu> bregma: Super+wheel/two-fingers in mir_proving_server. I still think that feature should be moved into common Mir and USC... just as soon as the required cursor support is done for Unity8
[02:26] <bregma> there's still plenty of a11y functionality on the list of things to be added to Unity 8, they're pedalling as fast as they can
[06:41] <MrChrisDruif> Hey guys, can someone tell me if the GPS is indeed broken on the OnePlus One built of Ubuntu Touch as mentioned in this link? https://devices.ubports.com/#/bacon
[06:42] <MrChrisDruif> #AintNobodyGotTimeToFlashAndTestThemselves
[07:19] <mardy> t1mp: hi! Unless you think you'll be able to fix bug 1617745 by OTA-13, you might want to send a message to the ML to warn developers to check their apps
[08:15] <t1mp> kalikiana: ^ do you want to comment on that bug? I see you change a debug() call to a warn().
[08:16] <kalikiana> Not sure how debug/warn is related, but taking a look
[08:21] <kalikiana> mardy: Can you be more specific what "doesn't work"?
[08:22] <mardy> kalikiana: it's not about the warning, but about the fact that the attached test case doesn't work anymore
[08:23] <kalikiana> mardy: There is no attached test case :-)
[08:23] <mardy> kalikiana: oops, lemme check
[08:25] <mardy> kalikiana: you are right, let me quickly write one...
[09:09] <mardy> kalikiana: added a test case to bug 1617745
[09:26] <rvr> dpm: ping
[09:38] <dpm> hi rvr
[09:38] <kalikiana> mardy: Did you always use a Window as a root item? I'm not sure that worked before
[09:39] <mardy> kalikiana: mmm, let me check, when I introduced it...
[09:39] <kalikiana> So I'm still investigating why this breaks it, but it's not a regression from my pov
[09:41] <rvr> dpm: Hi
[09:41] <rvr> dpm: So I think that sil2100 needs at least indicator-keyboard in the ubuntu-15.04/rtm series
[09:42] <mardy> kalikiana: you might be right, I don't think that the released version of my app is using Window
[09:43] <mardy> kalikiana: and indeed, then it wouldn't be a regression
[09:44] <dpm> rvr, ok, let me have a look at LP and see if the template needs approving, give me a few minutes
[09:45] <rvr> dpm: Ack
[09:45] <sil2100> dpm, rvr: thanks! I don't know enough of the LP-side-of-things internals, but I'd need indicator-keyboard visible in the ubuntu-rtm/15.04 exports
[09:49] <gb_mks> hi! I found a bug related in the package "click-review" related with Ubuntu-Trisquel. Can anyone help me to solve it? https://bugs.launchpad.net/click-reviewers-tools/+bug/1617288
[09:56] <dpm> rvr, sil2100, the template is there, but unfortunately I can't approve it as LP gives me a timeout error every time I try it :/ https://translations.launchpad.net/ubuntu-rtm/15.04/+source/indicator-keyboard/+imports?field.filter_status=all&field.filter_extension=pot
[09:56] <rvr> dpm: :(
[09:56] <dpm> rvr, ah, managed to get it approved after a few tries
[09:56] <rvr> Wee!
[10:01] <dpm> rvr, sil2100, https://translations.launchpad.net/ubuntu-rtm/15.04/+source/indicator-keyboard. The translations should be included in the next LP export and then added to the language packs if all goes well
[10:01] <rvr> dpm: Great, thanks you!
[10:01] <dpm> np
[10:03] <sil2100> \o/
[10:03] <sil2100> dpm: excellent, thank you!
[10:15] <matv1> during the weekend I installed rc-proposed in my Frieza. loving lots except that Libertine apps would cause a graphics freeze everytime i tried them. Didnt matter which.
[10:15] <matv1> Usualy it would take anything between a few minutes and a max of 10 minutes.
[10:16] <matv1> just having them open would be enough
[10:16] <matv1> as I said a graphics freeze so I assume a MIR thing?
[10:18] <matv1> is anyone able to confirm this is the case?
[10:19] <matv1> Also I discovered that the particular rc-prop image i went with wasnt as up to date as i expected.
[10:19] <matv1> its rc-proposed/ubuntu-pd
[10:20] <matv1> So it might be that this is already known and fixed.
[10:20] <matv1> Can anyone shed light?
[10:21] <gb_mks> hi, I´m trying to "build and validate" an app but I´m having issues with the bug #1617288.
[10:21] <gb_mks> I wrote one of the developers of the package https://launchpad.net/click-reviewers-tools
[10:21] <gb_mks> Is this a good practice?
[10:24] <Soelen> hello everyone, can anyone help me out? I am trying to flash a bq aquaris e5 device with the latest ubuntu phone os
[10:24] <Soelen> https://github.com/bq/aquaris-E5/tree/aquaris-E5-ubuntu-master
[10:25] <Soelen> unfortunatly when I do fastboot boot boot.img the < waiting for device > message seems never to go away
[10:25] <Soelen> when I do adb devices I dont see my devices listed there
[10:26] <Soelen> when I do dmesg | grep -i usb I can see that the devices has been connected successfully, I guess "[68930.280122] usb 2-3: New USB device found, idVendor=2a47, idProduct=2008"
[10:27] <Soelen> last but not least when I do lsusb -v | grep ID I see the devices being there but I think with no vendor attached to it? "Bus 002 Device 006: ID 2a47:2008"
[11:07] <MrChrisDruif> Soelen: is your device in fastboot mode?
[11:11] <Soelen> MrChrisDruif: how do I check that?
[11:11] <MrChrisDruif> If you can use your device normally it isn't in fastboot mode
[11:12] <Soelen> what do you mean with use your device normally?
[11:13] <mcphail> Soelen: I don't know what way you are flashing your device, but it doesn't sound like the "correct" way. Do you currently have Ubuntu or Android on the phone?
[11:13] <MrChrisDruif> On Android devices you have to hold the power and volume up button simultaneously during boot to go into fastboot mode
[11:14] <Soelen> mcphail: it has android on it
[11:14] <Soelen> MrChrisDruif: gotcha, I will try that!
[11:14] <mcphail> Soelen: then you'll probably need to bq tool to reflash it
[11:19] <mcphail> http://www.mibqyyo.com/en-articles/2015/09/16/ubuntu-android-installation-process-for-bq-aquaris-e4-5-and-e5
[11:21] <Soelen> ah thank you
[11:22] <Soelen> haha
[11:23] <Soelen> my spanish isnt really fluent but I think I found the link
[11:23] <mcphail> You'll need the flash tool and the OTA12 image
[11:24] <mcphail> IIRC, when you extract the flash tool archive, you need to move it into a directory without spaces in the path, or the script breaks
[11:25] <Soelen> mcphail: ok, but
[11:25] <Soelen> I only see windows executables in this zip file
[11:27] <mcphail> Soelen: nope. script is there. Follow the instructions on that page _exactly_ or you may end up with a brick
[11:27] <ogra_> you need to do this only once though, to get the correct partitioning ...
[11:28] <ogra_> if you re-flash ubuntu on a properly partitioned phone you can just user ubuntu-device-flash then
[11:28] <ogra_> *use
[11:28] <mcphail> ogra_: Unless he is fickle like me, and flip-flops between Ubuntu and Android ;)
[11:28] <Soelen> heh
[11:28] <ogra_> yeah, then the MTK tool is your best friend (or you just buy a nexus4 )
[11:29] <Soelen> https://storage.googleapis.com/otas/Tools%26Drivers/Drivers_Tools.rar
[11:29] <Soelen> so I am downloading this rar file, and the flash_tool doesnt seem to be in there
[11:30] <mcphail> https://storage.googleapis.com/otas/2015/Tablets/Freezer%20FHD/Ubuntu/SP_Flash_Tool_exe_Linux_v5.1612.00.100.zip
[11:30] <mcphail> That's the link I get
[11:39] <Soelen> BROM ERROR : S_DA_SDMMC_CONFIG_FAILED (3152)
[11:40] <Soelen> that is what I get when I do step 5
[11:44] <Soelen> BROM Exception! ( BROM ERROR : S_TIMEOUT (1042)
[11:45] <ogra_> mvo, btw, not sure you have seen https://github.com/snapcore/classic-snap/pull/4
[11:54] <ogra_> bah
[11:54] <ogra_> echan
[12:04] <Soelen> so it started the booting process, how long does this take normally?
[12:06] <matv1> still no one on that Frieza image of mine? ^^
[12:14] <Soelen> it is still booting, is that normal
[12:33] <Soelen> I think the boot process is stuck
[12:33] <Soelen> still booting it
[12:35] <Soelen> it would help if somebody could tell me how long this fastboot process takes its time normally
[12:39] <mcphail> Soelen: it usually takes about 5--15 minutes, in my experience
[12:41] <Soelen> mcphail: thank you, I guess I can assume something went wrong since it is booting this phone for around 35 minutes : /
[12:41] <mcphail> Soelen: yep - that would seem abnormal
[12:42] <mcphail> Soelen: I'd repeat the process, making sure you follow every step carefully. Don't know what those error messages were about, but don't sound healthy
[12:45] <Soelen> mcphail: I disconnected it and it turned out the screen on the smartphoen froze, I guess I will charge it fully before I try this again
[12:45] <Soelen> charge the battery*
[12:45] <Soelen> also I was sitll able to boot up android so I guess it didnt flashed anything
[12:46] <mcphail> Soelen: sounds like it
[12:46] <Soelen> also also, I used a boot.img which I compiled it, sources from there: https://github.com/bq/aquaris-E5/tree/aquaris-E5-ubuntu-master
[12:46]  * mcphail see bq have released Android 6 for the e4.5, and might be running the flash tool again to experiment
[12:48]  * mcphail sees it is actually for M4.5 and contains his excitement
[13:34] <dobey> pitti: hey. can you look at https://requests.ci-train.ubuntu.com/static/britney/last-run.txt and search for "landing-019" in it. seems there's something wrong with the result.tar for the apparmor-easyprof-ubuntu tests
[13:35] <pitti> dobey: robru pointed that out last Friday; apparently apt has slightly changed the format of the Package-List: field, I adjusted autopkgtest this morning
[13:36] <pitti> dobey: i. e. a retry should work
[13:37] <dobey> hmm ok
[14:36] <Soelen> so I tried to install ubuntu touch with sudo ubuntu-device-flash touch --channel ubuntu-touch/stable/bq-aquaris.en --bootstrap --recovery-image recovery.img
[14:37] <Soelen> and it tells me this: Device 1 not found on server https://system-image.ubuntu.com channel ubuntu-touch/stable/bq-aquaris.en
[14:37] <Soelen> so I guess
[14:37] <Soelen> https://www.amazon.de/gp/product/B00KLZB53A
[14:37] <Soelen> this product is not compactible with ubuntu touch?
[14:37] <dobey> !devices Soelen
[14:38] <dobey> it sounds like it has the wrong device identifier
[14:38] <dobey> to use ubuntu-device-flash the device must also be repartitioned
[14:39] <Soelen> how do I do that?
[14:41] <Soelen> dobey:
[14:42] <Soelen> also when you wrote !devices Soelen nothing appeared
[14:42] <dobey> yeah, should have been...
[14:42] <dobey> !devices | Soelen
[14:45] <Soelen> ubot5: so 2 of them are tables, 2 of them are emulators, 2 of them are sold out and 2 of them are linked wrong
[14:45] <Soelen> oh.
[14:45] <Soelen> who would have thought to get an ubuntu phone would be so hard
[14:45] <dobey> the E5 is "vegetahd" for device name
[14:46] <dobey> from scrollback it looks like you managed to mess things up with some other tools
[14:46] <Soelen> I guess so, so what do I do now?
[14:48] <dobey> it sounds like the tool needs to be used to restore the device; given that device appears to be "1" you probably broke the IMEI data too. i don't know exactly what you need to do, though. perhaps bq support can help you?
[18:03] <linmob> I guess the fact that the "Software Updater" app gives wrong timestamps for older updates (it pretends that the updates were done at the same time as the latest update) is a known one? (Nexus 4, rc.proposed 517)
[18:08] <pmcgowan> yes, bug fix in QA
[18:40] <linmob> pmcgowan: Great. Thanks!
[18:50] <barryt> Hello.
[18:53] <linmob> Hello!
[18:54] <barryt> I need a little advice about reporting a bug.
[18:55] <dobey> !ask | barry
[18:55] <dobey> :)
[18:55] <barryt> This is my first time on IRC so please be kind!
[18:56] <barryt> I installed UT on a Nexus 4 16Gb but had trouble connecting to my home wifi. What package should I report this under?
[18:58] <dobey> trouble in what sense exactly? wifi itself just wasn't working right, or you had trouble typing the password, or with the UI?
[19:00] <barryt> My SSID was shown on the list of available networks but it would not connect when I typed in my password. However if I typed the SSID using the 'hidden network' option then it would accept my password and connected succesfully.
[19:01] <dobey> i think i've seen someone else describe that problem recently. or was that you at a different time? (hard to remember everyone :)
[19:01] <barryt> Not me: this is my first time on here.
[19:02] <dobey> ah ok
[19:02] <barryt> Do you know if a bug was filed?
[19:02] <dobey> i'm not certain, would have to look and see
[19:03] <barryt> I could not find anything but I may not have used the correct search criteria.
[19:03] <JanC> barry: does your SSID have special characters in it?
[19:04] <JanC> barryt: I mean
[19:04] <pmcgowan> barryt, are you on the stable channel? A bug with wifi connect timeout was just recently fixed
[19:04] <barryt> No, just letters - all lower case - and numbers.
[19:05] <barryt> Yes, it was the stable channel.
[19:05] <pmcgowan> could be this bug https://bugs.launchpad.net/canonical-devices-system-image/+bug/1588126
[19:06] <pmcgowan> sounds like you found a better workaround
[19:06] <barryt> I found that one, but my password is shorter than his limit.
[19:08] <pmcgowan> I think the key in finishing in 25 secs, if you did that could be something else
[19:11] <barryt> It could be the time limit as I have to jump back and forward between text and numbers on the on-screen keyboard which slows me down.
[19:12] <dobey> barryt: do you have an otg cable and a spare keyboard (or a bt keyboard) to test if that's it?
[19:13] <barryt> No I don't.
[19:16] <pmcgowan> barryt, could try copy and paste from another place, but pretty sure thats the issue
[19:17] <barryt> You said earlier that this has been fixed on an upstream channel. Should I just let it go and wait for the OTA update?
[19:19] <pmcgowan> barryt, the fix will go to stable within a couple weeks or you could run rc-proposed
[19:19] <pmcgowan> barryt, but seems you found a good workaround
[19:20] <barryt> I have a work around so I will wait. I shall also try and borrow an otg cable from a friend to see if it is the time out issue.
[19:21] <barryt> Thank you for your help. Bye.
[19:21] <dobey> you're welcome
[19:37] <matv1> i am finding that launching x-apps in desktop mode causes my graphics to freeze up all the time
[19:37] <matv1> is this a known issue?
[19:38] <matv1> in rc proposed
[19:40] <dobey> bregma, ChrisTownsend: ^^
[19:42] <ChrisTownsend> matv1: What device?
[19:43] <matv1> Frieza
[19:43] <ChrisTownsend> matv1: You say desktop mode, do you have it connected to an external monitor?
[19:44] <ChrisTownsend> matv1: I will say, no known issues of X apps freezing up the machine.
[19:44] <matv1> no. I thought this at first. But its just desktop mode that does it. No external screen is needed for this to be triggered
[19:45] <ChrisTownsend> matv1: Hmm, my frieza is on rc-proposed and fully up to date and X apps launch fine in desktop mode, ie, with BT keyboard and mouse.
[19:46] <ChrisTownsend> matv1: Is this all X apps?  And do you have your own custom Libertine container or is it the Desktop Applications container?
[19:46] <matv1> Ah well maybe we are using different images. yesterday I flashed my Frieza to rc-proposed/ubuntu-pd
[19:47] <matv1> but have since found out that this image may be a little beind other rc-prop images
[19:47] <ChrisTownsend> matv1: Ah, no, that won't work and is deprecated.
[19:48] <matv1> ahah but which one should I be running. I was led to believe that bq-aquaris-pd currently has an empty libertine scope is that right?
[19:49] <dobey> err?
[19:50] <matv1> dobey did I misunderstand?
[19:50] <dobey> yes. i said i think it has the empty _puritine_ click (because real one is like 650 MB)
[19:51] <dobey> but either way, unless you didn't have the full one installed already, and didn't --wipe, that's not especially important
[19:52] <matv1> dobey ok so all that means that I wont be able to create new x-apps for myself on the system, correct?
[19:52] <matv1> the ones that are installed with the system are just there and working?
[19:53] <dobey> no. you can still create your own container instead of using the default one
[19:53] <ChrisTownsend> matv1: Yes, there is currently a problem wit hte Libertine Scope in rc-proposed that I'm currently working on.
[19:53] <matv1> ChrisTownsend So how exactly will that limit me?
[19:54] <ChrisTownsend> matv1: The problem being that the Libertine Scope installed on devices and from the Store is built against libubuntu-app-launch2, but that has been removed from the image, so the Libertine Scope fails.
[19:54] <ChrisTownsend> matv1: You can't launch X apps.
[19:54] <dobey> oh that's a click
[19:54] <dobey> fun
[19:54] <ChrisTownsend> dobey: Yes:(
[19:55] <matv1> ok and what if I go back a few revisions on that same channel?
[19:55] <ChrisTownsend> matv1: I'm not sure of the exact revision this showed up, but yes, that is possible.
[19:55] <dobey> matv1: well, depends on what your goal with using that channel is
[19:56] <ChrisTownsend> matv1: You could also run stable and it will work.
[19:56] <dobey> matv1: if it's to get/test something which landed after that point, going back won't really help you much :)
[19:56] <matv1> my aim was to be as current as I can on rc-proposed. on the on the one hand for some goodies that i want to look at coming up in ota 13 . like owncloud plugin
[19:57] <matv1> on the other hand I also definetly want the libertine purtine stuff to work
[19:58] <matv1> but I dont need it to be bleeding edge
[19:58] <ChrisTownsend> I can't publish a new version of the Libertine Scope in the Store yet because if I do, it will break everyone on stable when they update the Libertine Scope package:(
[19:59] <matv1> ChrisTownsend Stable be damned. There is work to be done!
[19:59] <ChrisTownsend> matv1: lol, I wish:)
[19:59] <matv1> just joking. I understand
[19:59] <dobey> ChrisTownsend: you can fix it to resolve that library at runtime, and then work with either one. ;)
[20:00] <dobey> you know you always wanted to write a plug-in system just for loading system libraries
[20:00] <ChrisTownsend> dobey: It's probably possible, but who has time for dat?
[20:02] <matv1> ChrisTownsend dobey so my best would be to try going back a few revisions on bq-aquaris-pd and see if it hold together
[20:04] <matv1> my short experience with libertine apps on stable is that they dont crash but are slower than on rc-proposed (before they crash on me)
[20:04] <ChrisTownsend> matv1: If you feel particularly brave, you can put your device in r/w mode and install libubuntu-app-launch2...but I'm sure others would highly discourage that.
[20:04] <ChrisTownsend> matv1: Also, I think r175 will work.
[20:05] <ChrisTownsend> matv1: r176 and later has this issue I believe.
[20:05] <dobey> i think the problem with that is that the version from the overlay is no longer available
[20:06] <dobey> so if you were able to install libubuntu-app-launch2 it would be ~18 months old
[20:06] <ChrisTownsend> dobey: Oh, rvr stated in the bug that he installed it on his device and it fixed it, so I'm just taking that with a grain of salt.
[20:06] <matv1> ChrisTownsend dobey I am still not that brave :)
[20:07] <ChrisTownsend> matv1: lol, ok, it's not for the faint of heart.
[20:08] <dobey> meh
[20:08] <dobey> it's easier than getting stuff mounted in lxc
[20:08] <matv1> faintness of heart is not my problem. I am trying to put together a short demo for my it department on the system. I want to be as up to date as possible without having the risk of crashing be too big
[20:09] <matv1> but thanks very much both. i will try for rev 175
[20:09] <matv1> have a good evening!
[20:09] <ChrisTownsend> matv1: Ok, you're welcome and good luck!
[20:36] <kaisoz> hi!
[20:54] <learnbsd> kaisoz: hi
[20:55] <MrChrisDruif> Hi