[00:24] <Noldorin> hi guys
[00:25] <Noldorin> lifeless, jelmer
[00:43] <lifeless> hi there
[01:24] <MechanisM> hello. who can help me with creating ppa?
[01:25] <MechanisM> I'm so bored that ubuntu doesn't have latest chromium builds so I'm going to create new ppa with all latest builds and maintain it daily builds like
[01:26] <lifeless> https://launchpad.net/~chromium-daily/+archive/ppa
[01:27] <MechanisM> lifeless you sure it's latest? it has 18 chromium while now it's 21!
[01:27] <MechanisM> and it's called daily builds and latest build on january?
[01:28] <lifeless> micahg: ^ sup with that ?
[01:29] <MechanisM> lifeless I mean repos called daily builds but latest built there is only date january. actually all builds outdated even compare to stable.
[01:34] <MechanisM> I'm already discussed it with ppl here http://askubuntu.com/questions/112432/chromium-19-for-ubuntu <-- since 19 chromium I'm missing builds on chromium-daily ppa
[01:38] <MechanisM> Guys I'm a lot of time coding and so much need latest chromium coz I like it and work via this browser. Please help me create repos and I'll maintain it. So other ppl can use it. I'm really care about latest chromium builds
[01:40] <MechanisM> Currently I'm using bash script to download latest builds and put it in folders used by chromium-daily
[01:40] <lifeless> so there is a ppa that is meant to have daily builds alread
[01:40] <lifeless> chromium takes ages to build, its a waste to ahve two daily ppas.
[01:40] <lifeless> micahg runs the ppa, so I've asked him.
[01:40] <lifeless> Now we wait for a response:)
[01:41] <MechanisM> ok I hope this repos will back
[01:41] <MechanisM> lifeless sometimes not needed to build. just download from build server and package it as deb
[01:42] <MechanisM> all builds on build server
[01:44] <lifeless> MechanisM: Part of the way we make Ubuntu trustworthy is making the code that goes into it auditable and inspectable.
[01:44] <lifeless> MechanisM: downloading binaries from somewhere else and then uploading them would circumvent that entirely.
[01:45] <MechanisM> for example latest build of chromium for x64 is http://commondatastorage.googleapis.com/chromium-browser-snapshots/Linux_x64/139446/chrome-linux.zip just needed to be packaged. It's already built on ubuntu 12.04
[01:47] <MechanisM> lifeless okay I see your point
[01:48] <lifeless> I'll nag micahg when he comes online
[01:49] <MechanisM> lifeless okay I'm glad someone can see this problem
[01:49] <MechanisM> web dev not so good without lates chromium builds
[01:52] <MechanisM> lifleless btw do you know someone I can talk with my project related to ubuntu? I'm creating website where ppl can design and generate their own gtk3 themes and donload it etc.
[01:52] <MechanisM> about my project*
[01:56] <lifeless> MechanisM: what sort of role should this person have?
[01:56] <MechanisM> lifeless I'm just wanna know if it's really needed to community and if yes I need to find someone who can help etc.
[01:57] <MechanisM> to join the team
[01:58] <lifeless> so for the former bit, you could ask around, see how many folk want it
[01:59] <lifeless> for finding help, you can blog about it, and if lots of folk want it, they''ll probably repost it etc. :)
[02:00] <MechanisM> lifeless I know about it. So until I show any result noone cares
[02:01] <MechanisM> I wanted to get help before releses and not telling to others before release
[02:09] <jimis1> In a bug report, can I use special syntax for pasting code segments?
[02:09] <jimis1> like the {{{blah blah}}} in other wikis
[02:12] <bigjools> no, there's no special syntax.  You can attach patches though.
[02:12] <lifeless> bigjools: someone should finish poolies markdown branch ;)
[02:13] <lifeless> bigjools: by which I mean prod testing and feature flag enablement
[02:13] <bigjools> lifeless: you sound like a volunteer!
[02:13] <jimis1> alright, thanks bigjools
[02:14] <jimis1> bug filed, bzr slowness again :-p
[04:16] <micahg> lifeless: I've had a build failure for weeks on generating the translations for chromium 19, it's on my list (I've been off since Fri)
[07:51] <jf_> hi, please could you help me on bug #869022 : I can't branch my project.
[08:21] <czajkowski> jelmer: are you alive?
[08:22] <czajkowski> mgz: vila jam ^^^^^^
[08:25] <vila> jf_: as explained in the bug, your local repository seem to be corrupted, you need to create a new one from lp. From there, you can try to rescue local bits if needed (but don't hold your breath)
[08:25] <jam> czajkowski: I'm around, but I don't know if jelmer is alive or not, I assume he is
[08:25] <jam> when I stopped by earlier, jf was no longer in chat
[08:25] <jf_> vila, is not the local repositroy but the repository in bazaar
[08:25] <czajkowski> was just help with bzr :)
[08:26] <vila> jf_: note that all corruption reports we got in the past years have all been linked to either: hard disk dying or hard crashes leading to disk corruption
[08:26] <jf_> vila, I can't push nor pull from.to my project
[08:26] <wgrant> vila: The repository on LP is corrupt.
[08:26] <vila> on lp ???
[08:27] <vila> darn, misread the bug, let me try
[08:33] <vila> jf_: reproduced locally, digging
[08:33] <jf_> so you will fix it ? :)
[08:33] <vila> jf_: hold on, I trying to understand what the issue is, it's a pre-requisite to even pretend it can be fixed :)
[08:34] <jf_> vila, ok thanks
[08:34] <vila> jf_: I can branch lp:unifield-server/sprint4 at least (but trunk and main fail)
[08:36] <vila> weird, after branching sprint4 (in a local shared repo), both trunk and main succeed
[08:36] <vila> jam: can you imagine what can allow such a scenario ??
[08:36] <jf_> vila, yes I know, it's very strange, but you can't: "bzr diff -c 3359.2.65"
[08:36] <wgrant> vila: That sounds rather expected.
[08:37] <wgrant> vila: The relevant repo bits are uncorrupted in sprint4.
[08:37] <wgrant> vila: So if you branch that first, it won't try to retrieve the corrupt bits from trunk...
[08:37] <vila> wgrant: on how can trunk and main succeed when I retry then ?
[08:38] <jam> vila: if there is a specific block that is bad, you only get the error when accessing it. so if you have a duplicate copy of the data that gets used, or if the current tip doesn't access it, etc.
[08:38] <wgrant> vila: It'll see the relevant texts or whatever are already in your shared repo, so it won't try to download them from trunk.
[08:38] <mgz> what's the bug #? predated me joining the channel.
[08:38] <wgrant> mgz: Bug #869022
[08:38] <mgz> ta.
[08:38] <vila> jam: hmm, so a repack will be a russian roulette ?
[08:39] <jam> vila: repack will always touch everything
[08:39] <jam> so either it will always fail, or it will succeed and clean things up
[08:39] <vila> jam: but select one out of the duplicates right ?
[08:39] <wgrant> I suspect you want to just empty out the branch on LP and repush it from a good local copy.
[08:39] <jam> if it is dupes, yes
[08:39] <wgrant> Which can be obtained by grabbing sprint4 first.
[08:40] <vila> right, russian roulette indeed
[08:40] <jf_> wgrant, I can't push to a new repo
[08:41] <jf_> revno  3359.2.65 is corrupted when I push or when I pull
[08:41] <vila> jf_: this revno comes from which branch ?
[08:43] <jf_> vila, it comes from lp:openobject-server/6.0
[08:45] <vila> nah, I wanted the context where this revno is valid, it's neither in trunk nor sprint4
[08:45] <vila> 3359.2.65 is a 'launchpad automatic translation update' in trunk
[08:48] <vila> even weirder, sprint4 is stacked on trunk...
[08:49] <wgrant> What if the revision was first in sprint4, and merged into trunk later, at which point it was corrupted?
[08:49] <vila> ha right, several merges from sprint4 into trunk
[08:49] <vila> wgrant: yup
[08:50] <jf_> I think there isn't any merge from sprint4 to trunk
[08:50] <jf_> everything is developped on trunk and then push to sprint4
[08:54] <vila> bzr check bzr+ssh://bazaar.launchpad.net/~unifield-team/unifield-server/trunk fails
[08:55] <vila> bzr: ERROR: Corruption while decompressing repository file, zlib: Error -3 while decompressing data: incorrect data check
[08:55] <wgrant> vila: Interestingly, I can't branch sprint4 locally over bzr+ssh
[08:55] <wgrant> Or HTTP
[08:55] <vila> 8-/
[08:56] <wgrant> Ah
[08:56] <wgrant> main branches OK
[08:56] <vila> wgrant: try 'bzr init-repo xxx; cd xxx; bzr branch lp...' ?
[08:56] <jf_> to my mind, the only branch I can't branch from scratch is lp:unifield-server/main
[08:57] <wgrant> Yeah, main branches from scratch fine, trunk/sprint4 don't
[08:57] <wgrant> main has the relevant data uncorrupted.
[08:57] <vila> wgrant: standalone branches ?
[08:58] <vila> no, main, does not contain everything used in trunk/sprint4
[08:58] <wgrant> vila: Standalone branches of trunk/sprint4 fail, main works. If I then branch main into a shared repo, I can branch trunk/sprint4 into it.
[08:58] <vila> ha, right
[08:59] <vila> bzr check bzr+ssh://bazaar.launchpad.net/~unifield-team/unifield-server/main fails nevertheless
[08:59] <wgrant> vila: Hm, indeed.
[09:00] <wgrant> The repo with all 3 has a zlib error.
[09:00] <vila> yeah, but no indication of which file
[09:00] <wgrant> But all three trees build.
[09:00] <vila> note that (as mentioned earlier) zlib error strongly hint corruption
[09:00] <wgrant> Oh yes.
[09:00] <vila> but I've never ever heard about corruption on lp repos :-/
[09:01] <vila> by corruption I mean: hardware failure, crash, nothing inside bzr itself
[09:01] <wgrant> Well
[09:01] <vila> main is not stacked
[09:01] <wgrant> If it was not using normal smartserver ops it could reasonably happen.
[09:01] <vila> sprint4 is stacked on trunk
[09:02] <vila> wgrant: what do you mean ?
[09:03] <wgrant> vila: "reasonably" meaning a client-side RAM issue or similar.
[09:06] <vila> wgrant: hmm, you mean, RAM issue locally when creating the pack file which is then uploaded ?
[09:06] <wgrant> vila: Right, something like that seems most likely to me.
[09:07] <vila> never heard about such a scenario, not sure we have additional checks for that nor when the md5 is processed though
[09:07] <wgrant> Given that none of LP, bzr or SSH are known for corrupting things.
[09:07] <vila> oh right, yeah, when you've ruled out the unlikely...
[09:08] <vila> still, it's weird we have the corruption in both main and trunk/sprint4 (or even in the 3 of them) but still manage to branch them all
[09:09] <wgrant> main and trunk seem to be corrupted in different ways.
[09:10] <wgrant> vila: Huh, now this is interesting.
[09:10] <wgrant> vila: Can branch main, and can branch trunk into that.
[09:10] <wgrant> But can't branch trunk *out* of that.
[09:10] <vila> urgh
[09:11] <wgrant> So it can build the trunk tree in the repo, but you can't branch it from that repo to elsewhere... wtf
[09:11] <vila> I just did
[09:11] <vila> bzr branch trunk out-of-trunk
[09:11] <vila> Branched 3401 revisions.
[09:22] <wgrant> vila: That looks like you're branching within the repo.
[09:23] <vila> wgrant: yes. That's not what you meant by 'out of that' ?
[09:23] <wgrant> vila: I meant branching from inside the repo to out of it.
[09:23] <vila> ha
[09:24] <vila> yeah, reproduced, ouch
[09:25] <wgrant> There's only 33 extra mainline revs in trunk
[09:37] <wgrant> Aha
[09:37] <wgrant> Salvaged.
[09:37] <wgrant> I have a clean standalone trunk branch.
[09:37] <wgrant> vila, jf_: ^^
[09:38] <jf_> wgrant,  great !
[09:38] <wgrant> Let me just run a few checks and then we can work on fixing the one on LP.
[09:38] <jf_> wgrant, thanks
[09:39] <wgrant> vila: How's your link to LP?
[09:39] <wgrant> vila: I don't really want to push up 67MB over 512kbps if I can help it.
[09:40] <vila> well done, I have a list of corrupted entries here: http://paste.ubuntu.com/1014470/
[09:40] <mgz> wgrant: do the ops over ssh to a machine in london?
[09:40] <wgrant> mgz: Hopefully nowhere in London has my SSH key, but maybe.
[09:41] <wgrant> Anyway, the key is to use lp:openobject-server as the base.
[09:41] <wgrant> Seed the repo with that, then you can branch lp:unifield-server fine.
[09:41] <wgrant> So we should probably delete lp:unifield-server's .bzr, then push up a clean copy from the seeded repo.
[09:45]  * vila blinks
[09:46] <vila> wgrant: I don't enough about lp internals to do that kind of stuff (which I agree is the right thing to do though, just checking I find no corruption in lp:openobject-server)
[09:46] <wgrant> checked repository <bzrlib.transport.local.LocalTransport url=file:///home/wgrant/really/trunk/> format RepositoryFormat2a()                                                                                6611 revisions 2418 file-ids
[09:47] <wgrant> I got a bit uncreative with branch names by the 20th try
[09:47] <wgrant> really/trunk is a copy of lp:unifield-server
[09:48] <wgrant> vila: The broken revision is a massive merge of lp:openobject-server, so I tried seeding with that, and it all seems happy.
[09:49] <vila> ok, reproduced locally, in a shared repo, branch lp:openobject-server then lp:unifield-server(main,trunk,sprint4) run repodetails there, no corruption
[09:49] <wgrant> Yep
[09:51] <mgz> I've got a machine in the data center with that on it.
[09:51] <mgz> tell me where to poke things and I will.
[09:52] <wgrant> mgz: Push it up to like lp:~mgz/+junk/unifield-server or so
[09:52] <mgz> sure
[09:52] <vila> mgz: beat me to it :)
[09:54] <mgz> is done.
[09:54] <wgrant> We can then get either jf_ or an admin to branch mgz's copy locally, rename lp:unifield-server's .bzr to something else, then "bzr push --use-existing-dir lp:unifield-server".
[09:55] <mgz> main is a strict subset, right?
[09:55] <vila> no
[09:55] <wgrant> No
[09:55] <wgrant> 5 extra revs in main
[09:55] <vila> but the repo should contains everything
[09:55] <mgz> sprint4 and trunk are the same thing
[09:55] <vila> yes
[09:55] <wgrant> Ah, indeed, sprint4 is identical.
[09:56] <vila> meh, subset != superset, but anyway, they diverge
[09:56] <mgz> if main has 5 revs not present, what I just pushed will not be enough
[09:56] <wgrant> mgz: What did you push?
[09:57] <vila> mgz: push trunk then push --overwrite main
[09:57] <wgrant> I doubt any revs unique to main are corrupted
[09:57] <vila> so the repo will get them all
[09:57] <wgrant> But it's possible, I guess.
[09:57] <mgz> yeah, I'll cheat and get those revs in as well
[09:57] <wgrant> jf_: Still around?
[09:57] <jf_> wgrant, yes,  should I do something ?
[09:59] <wgrant> jf_: lp:~gz/+junk/unifield-server is a fixed copy of lp:unifield-server
[09:59] <wgrant> jf_: Now we just need to replace lp:unifield-server with it.
[09:59] <jf_> wgrant, ok
[09:59] <vila> argh ! I meet melmoth at 12:00 ! Should run
[10:01] <jf_> wgrant, who is "we" in "we just need" ?
[10:01] <wgrant> jf_: you or a Launchpad sysadmin. So ideally you :)
[10:02] <jf_> wgrant, ok so I need to: bzr branch  lp:~gz/+junk/unifield-server in a standalone repo ?
[10:02] <wgrant> jf_: Right, eg. in /tmp somewhere.
[10:02] <wgrant> It must not be in a shared repo which has been anywhere near the broken branch.
[10:03] <jf_> ok should I make a backup of branches in lp:unifield-server ?
[10:03] <wgrant> jf_: You'll also need lp:hitchhiker. I'll tell you how to use hitchhiker to remove the broken branch content from Launchpad.
[10:03] <wgrant> jf_: Might be a good idea, but it might be difficult because of the corruption.
[10:04] <jf_> ok
[10:05] <wgrant> Once you're ready, in your local branch of hitchhiker, run './hitchhiker lp:unifield-server'. Once that's connected you should say 'rename .bzr backup.bzr'.
[10:06] <wgrant> Then you can switch over to your copy of the fixed branch, then 'bzr push --use-existing-dir lp:unifield-server'
[10:06] <wgrant> And that should fix it.
[10:10] <jf_> wgrant, I'm pushing, it should take time ....
[10:11] <wgrant> jf_: Yeah, you'll have to push the full 67MB or so, since it's the trunk branch that you're recovering :(
[10:15] <jf_> wgrant, done
[10:16]  * wgrant tries.
[10:16] <wgrant> Branched 3401 revision(s).
[10:16] <wgrant> Branched 3401 revision(s).
[10:17] <wgrant> jf_: That's fixed it!
[10:17] <jf_> wgrant, ok many thanks, should I remove all my corrupted shared repo ?
[10:18] <wgrant> jf_: Yeah, you and anyone else working on the project will probably need to recreate any shared repos from scratch.
[10:18] <wgrant> It won't re-corrupt the branch on LP, but it will still be corrupt locally.
[10:19] <jf_> wgrant, ok perfect !
[10:19] <jf_> wgrant, many many thanks
[10:19] <wgrant> jf_: np, glad we could sort it out.
[11:18] <czajkowski> jam: jelmer vila mgz can someone look into this please.  https://bugs.launchpad.net/launchpad/+bug/1006323
[11:19]  * mgz has a look
[11:25] <vila> wgrant: thanks (I should have thought about hitchhiker)
[13:50] <mdeslaur> I'm sure getting a lot of "Processing Failed" errors when trying to download stuff from launchpad bugs and PPAs...is this a current known issue?
[14:21] <james_w> mdeslaur, bug 1000805 probably
[14:22] <mdeslaur> james_w: looks like it, thanks
[15:31] <colon_D> still having a permission denied error when uploading my ppa.  anyone around to check what's wrong?
[15:33] <czajkowski> colon_D: what issues are you seeing ?
[15:33] <colon_D> czajkowski: I get this: Rejected:  Unhandled exception processing upload: [Errno 13] Permission denied: '/tmp/tmpbAwawq/trafficserver-3.1.3/debian/copyright'
[15:34] <czajkowski> colon_D: what lp id and what ppa ?
[15:35] <colon_D> czajkowski: i'm uploading here: https://launchpad.net/~wolfnet/+archive/trafficserver
[15:36] <czajkowski> colon_D: ok let me see if I cna get someone to help
[15:37] <colon_D> czajkowski: thanks :-)
[15:41] <czajkowski> jelmer: if you can would you mind helping colon_D please
[15:42] <dobey> colon_D: is the permissions of that file mode 600 or something?
[15:44] <colon_D> dobey: 644 root:root for everything when I package it up
[15:44] <colon_D> kind of weird it stops on copyright as there are other files like control compat changelog above it with same permissions
[15:50] <dobey> is the debian.tar.gz for that package accessible somewhere?
[15:53] <colon_D> debuild seemed to make one trafficserver_3.1.3-0ubuntu1~precise.debian.tar.gz
[15:56] <jelmer> hi colon_D
[15:56] <colon_D> hi jelmer :]
[15:57] <dobey> colon_D: accessible on the internet by persons other than yourself, in order to look at it directly
[15:57] <dobey> :)
[15:57] <dobey> anyway
[15:57] <dobey> maybe jelmer will help you
[16:07] <jelmer> colon_D: did you see dobey's last question?
[16:08] <colon_D> jelmer: yes I'm not sure what that means
[16:09] <jelmer> colon_D: can you put the .debian.tar.gz file up somewhere?
[16:10] <colon_D> jelmer: http://dl.dropbox.com/u/85144/trafficserver_3.1.3-0ubuntu1%7Eprecise.debian.tar.gz
[16:11] <jelmer> colon_D: the debian/ directory does not have any x bits set
[16:12] <jelmer> so it's imposible for anybody to list its contents
[16:12] <colon_D> jelmer: ah! you are right
[16:13] <colon_D> thanks a lot!  I will fix and resubmit
[16:13] <jelmer> colon_D: great :)
[16:23] <colon_D> Awesome!  It was accepted.  Thanks everyone for the help.  User error in the end x_x
[23:57] <broder> how does registering a private project work? are proprietary projects private by default?


[05:17] <tjaalton> all the bits are in xenial now, phew
[07:33] <tjaalton> oh right, mesa still in depwait for libva
[16:00] <JanC> in het geval van xscreensaver lijkt me dat iedere Debian-gebruiker die weet wat xscreensaver is (en dus geen "gewone" gebruiker) ook wel dat bugs in Debian stable in de Debian bugtracker horen of dat je anders eerst upstream moet testen?
[16:01] <JanC> is iets anders voor echte eindgebruiker-toepassingen natuurlijk
[17:01] <soee> http://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-364.15-Released
[17:07]  * mamarley slaps soee around a bit with a large trout.
[17:13] <mamarley> soee: Actually, the driver doesn't seem to have been uploaded to the FTP site yet, which makes it impossible to get all the files necessary to package it.
[17:19] <mamarley> tseliot: Also, it looks like they fixed the bug that was causing DRM KMS to break PRIME.  Do you want to enable DRM KMS by default now or leave it off?
[17:20] <tseliot> mamarley: I would like to test it first. I can do that tomorrow
[17:20] <mamarley> OK.  I can't even package the driver yet though because the .run files aren't on the FTP server.
[17:21] <mamarley> Or, maybe I can, if I can get the -no-compat32 from the regular download site.
[18:00] <mamarley> soee_: I will upload the new driver after I get home from work. :)
[18:10] <ricotz> mamarley, e.g. "debian/rules get-orig-source" -- http://us.download.nvidia.com/XFree86/Linux-x86_64/364.15/NVIDIA-Linux-x86_64-364.15-no-compat32.run
[18:12] <mamarley> ricotz: I was already able to grab the files by wgetting what I thought the URL should be.
[18:15] <ricotz> alright
[19:23] <soee_> mamarley: ok, thanks :)
[21:11] <mamarley> soee_: ricotz: 364.15 is up in the normal place. :)
[21:12] <soee_> mamarley: yes already updated but need will reboot soon, have to finish few things
[21:55] <soee> mamarley: works fine :)
[22:09] <mamarley> Yep, works for me too.
[22:39] <tjaalton> JanC: ik versta het niet
[22:40] <tjaalton> spreek je Engels?
[22:44] <JanC> tjaalton: sorry, wrong channel  :)
[22:45] <tjaalton> ha :)


[02:06] <fishcooker> how to disable/blacklist a package to be installed permanently?
[02:10] <patdk-lap> pinning
[03:03] <craig_> hello all
[03:17] <dpb1> fishcooker: https://askubuntu.com/questions/75895/how-to-forbid-a-specific-package-to-be-installed
[04:13] <cpaelzer> good morning
[08:55] <jamespage> morning cpaelzer
[08:58] <cpaelzer> hi jamespage
[08:58] <cpaelzer> jamespage: as much as I like a greeting I'm afraid there is more coming - is it?
[08:58] <cpaelzer> jamespage: and a good morning to you as well
[09:38] <jamespage> nope just good morning ;)
[10:00] <fishcooker> noted dpb1, thanks
[10:35] <trippeh> hm. not having much luck in getting Network Manager to push actual upstream dns servers to resolvconf after 17.04. /run/resolvconf/interfaces/NetworkManager is only getting <IP_ADDRESS>
[10:36] <trippeh> borking the unbound integration.
[10:59] <trippeh> dns=unbound in NetworkManager.conf + dnssec-trigger seems to work better. hmm.
[12:03] <cpaelzer> jamespage: coreycb: if one could check if you have seen bug 1583009 that would be kind
[12:05] <cpaelzer> zioproto: you had an update to this bug recently ^^
[12:05] <cpaelzer> zioproto: was your update Trusty+UCA-Mitaka -> Xenial (no UCA) ?
[12:24] <coreycb> cpaelzer, i've not seen that one
[12:25] <coreycb> cpaelzer, that's the release where group name etc were changed i think
[12:25] <cpaelzer> coreycb: thanks for checking
[12:25] <cpaelzer> coreycb: and yes it is the libvirt->libvirtd switch
[12:25] <coreycb> cpaelzer, seems suspicious that this started to occur in 1.3.4 and 1.3.3 changed the group
[12:26] <cpaelzer> but still why only in some cases
[12:27] <cpaelzer> actually no, xenial already was the one changing IIRC
[12:27] <cpaelzer> checking
[12:27] <coreycb> cpaelzer, i'd guess a race
[12:29] <cpaelzer> the last report of zioproto was T->X which is to 1.3.1
[12:29] <cpaelzer> which was prior to the rename
[12:30] <coreycb> cpaelzer, oh ok.  any log messages?  seems like init fails the first time around for libvirtd and virtlogd, but starting them again works.
[12:30] <cpaelzer> coreycb: I haven't seen more than what is in the bug
[12:30] <cpaelzer> coreycb: I mainly wanted to do a check if this showed up with you
[12:31] <cpaelzer> The more related changes are more likely all the renamings of libvirt services in 1.3.1, but then without any better repro or data it can't be debugged for now
[12:40] <coreycb> cpaelzer, it looks like a fix may have been provided to yakkety but not yet backported to xenial for upstart and sysvinit
[12:41] <coreycb> cpaelzer, maybe not a race but depends on upstart vs systemd?  just guessing.
[12:41] <cpaelzer> I wish hallyn would still be around as he was already context switched into this
[12:42] <cpaelzer> maybe he is atm
[12:42] <zioproto> cpaelzer: sorry I am in a meeting. Yes I have seen 1583009
[12:42] <cpaelzer> zioproto: the question was more on the exact versions you upgraded from/to - but take your time ro report after the meeting is over
[13:16] <zioproto> cpaelzer: version that works for me is qemu-system-x86_2.5+dfsg-5ubuntu10.11_amd64.deb and qemu-block-extra_2.5+dfsg-5ubuntu10.11_amd64.deb
[13:25] <xpistos> Hey all, I logged into my server this morning and it says my boot partition (300 mb) is at 89%. Not sure why  or what to do with it
[13:28] <simosx> xpistos, there is a script to clean up the older kernels. If you install "byobu", you can then "sudo purge-old-kernels". More at http://ubuntuhandbook.org/index.php/2016/05/remove-old-kernels-ubuntu-16-04/
[13:34] <xpistos> simosx: Thanks. That worked like a charm! Book marking it now.
[13:54] <hallyn> cpaelzer: i'm afraid i'm not context switched into anything :) bug#?
[14:36] <cpaelzer> hallyn: bug 1583009
[15:55] <c0mrade> how to let mongodb automatically start if my server reboots (Ubuntu 16.04.2 LTS 64bit Server)
[17:54] <c0mrade> How to let mongodb automatically start if my server reboots (Ubuntu 16.04.2 LTS 64bit Server)?
[18:26] <sarnold> c0mrade: if you don't already have a systemd unit file or sysv-init script for your mongodb then you should write one
[18:32] <Ussat> There are examples on the net all over
[20:56] <axisys> how do I find duplicate in sources.list
[20:56] <patdk-lp> vi
[20:56] <patdk-lp> how would there be duplicates in there?
[20:56] <axisys> patdk-lp: i know .. sort | uniq did not find duplicates///
[20:57] <axisys> patdk-lp: previous guy.. :-)
[20:57] <patdk-lp> sort | uniq will NOT find duplicates
[20:57] <axisys> patdk-lp: I had to stop him for a sec..
[20:57] <axisys> pasting it..
[20:57] <dpb1> axisys: did you get a message printed at apt-get update?
[20:58] <axisys> http://dpaste.com/399TSGB
[20:58] <axisys> dpb1: yep
[20:58] <dpb1> axisys: paste that please?
[20:58] <patdk-lp> line 21, remove main
[20:58] <axisys> with the message http://dpaste.com/07CBN6Q
[20:58] <axisys> patdk-lp: ah
[20:59] <patdk-lp> only thing I see
[20:59] <dpb1> universe in there too
[20:59] <dpb1> duplicated
[20:59] <patdk-lp> where?
[20:59] <patdk-lp> oh, line 21 is just a whole dup
[20:59] <patdk-lp> remove line 21
[20:59] <dpb1> right
[21:00] <axisys> fixed.. thank you guys..
[21:00] <axisys> mutliple pair of eyes :-)
[21:02] <axisys> W: There is no public key available for the following key IDs:
[21:02] <axisys> 3B4FE6ACC0B21F32
[21:02] <axisys> showing 4 times..
[21:02] <axisys> no external repo.. just ubuntu
[21:02]  * axisys looking for the previous guys
[21:02] <axisys> heh
[21:03] <c0mrade> I provide free hosting on my home server :P full root account, up to 2GBs of RAM and 200GB of HDD.
[21:03] <patdk-lp> c0mrade, why do we care?
[21:04] <c0mrade> patdk-lp: I don't know.
[21:04] <nacc> !ot | c0mrade
[21:04] <nacc> well, for #ubuntu-server, i guess :)
[21:04] <nacc> and !spam
[21:04] <nacc> !spam
[21:06] <dpb1> axisys: basically this: https://askubuntu.com/questions/235880/how-to-fix-gpg-in-updater
[21:07] <axisys> dpb1: yes I know the answer.. thanks anyways
[21:45] <arooni> trying to ssh from mac mini ==> ubuntu server; seeing; What does untrusted X11 forwarding setup failed: xauth key data not generated .... i have xquartz set up;  what do?  delete ~/.xauthority?
[21:45] <dpb1> arooni: did you ssh -X
[21:47] <arooni> dpb1: sure did
[21:49] <dpb1> arooni: try -Y ?
[23:29] <arooni> so i have a scrip (letsencrypt cert renewal) that apparently first searches via apt-get update then upgrades itself before it runs.  i'd like to invoke via cron; but if i do that; i'm not going to be around to manually hit the 'YES' when prompted.  is there a way to run the script that will auto answer y for me in my absence?
[23:32] <sarnold> the yes(1) tool can emit an endless stream of 'y\n'
[23:32] <sarnold> this might be enough for the script in question
[23:48] <compdoc> you probably dont want it to be an endless stream


[14:44] <awafaa> dannf: have you encountered http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/346135.html ? I asked infinity but didn't realise he wasn't up to date kernel wise
[14:46] <dannf> awafaa: i haven't , but i also haven't done much testing w/ post-3.19 kernels yet
[14:48] <awafaa> dannf: ok thanks, hopefully we can get it fixed before you run into it then
[14:49] <dannf> awafaa: yeah, well - at least the right people seem to be engaging
[14:49] <dannf> on the thread
[14:51] <awafaa> yup
[16:06] <infinity> dannf: You were supposed to say "yeah, I test the tip of mainline every day, WTF man, your bugs suck".  I was counting on you here. ;)


[03:40] <BionicMac> emma: Ok. I'm glad you pinpointed the root of the situation.
[03:41] <BionicMac> emma: In the meantime... I found a couple of really good articles on the subject. https://www.hiroom2.com/2017/08/24/ubuntu-1610-nameserver-127-0-0-53-en/ and https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320
[03:46] <valorie> BionicMac: did it help you fix your issue with your previous VPN?
[04:24] <BionicMac> BionicMac: Yes. I ended up using my VPN providers cli application and it solves everything for me. I tried using their openvpn.ovpn configuration files with openvpn in cli and importing it into the Kde network connection wizard to no avail.
[04:25] <BionicMac> valorie: ^
[04:27] <BionicMac> valorie: While using their *.ovpn config files it was always and every time a dns issue. The connection was made just fine. DNS would not resolv. It was exactly related to what emma is experiencing.
[04:31] <valorie> it would be good if both of you commented in the bug report
[04:32] <BionicMac> valorie: will do. Now that I am semi-educated on systemd and resolv.conf I may try the openvpn.ovpn files again before I file the bug comment.
[04:39] <user|95300> XBMC or Kodi on this distro
[08:23] <elichai2> Hi, I reinstalled plasma-pa, and now the applet is really big
[08:23] <elichai2> https://usercontent.irccloud-cdn.com/file/pWwD5D5z/20180416_112010.jpg
[08:23] <elichai2> any ideas whats going on?
[09:27] <globaldn> hey guys
[09:27] <globaldn> how can I register nichname?
[09:29] <mparillo> https://freenode.net/kb/answer/registration
[09:30] <globaldn> thanks
[10:43] <hay207> Hi guys, is there a program to monitor my network connection and notify me of disconnections?
[12:03] <BluesKaj> Hey folks
[12:03] <diogenes_> hey
[13:07] <dubis> hello world
[15:19] <newtest1> hi
[15:19] <newtest1> can some1 help me?
[15:20] <newtest1> how can I enable Encryption/SSL with Freenode in KDE Konversation client?
[15:21] <newtest1> i can't find any networking settings in Konversation client...
[15:21] <om26er> that's probably the wrong channel you are asking that in but search for a freenode server that is tls enabled
[15:21] <om26er> newtest1: ^
[15:21] <newtest1> ?
[15:24] <newtest1> i'm sorry... I know it's enablen on Freenode side, but looks like it's disabled in Kubuntu Konversation client... If not - how can I check that it's working? I haven't any indication...
[15:25] <om26er> newtest1: when your client is trying to connect you should be able to see if it does the SSL handshake and succeeds
[15:26] <om26er> so check the server logs
[15:26] <newtest1> where I can find logs? :)
[15:28] <newtest1> ah I see some logs in Freenode "root" window
[15:29] <om26er> maybe post it somewhere if it doesn't expose anything private, so that we can see.
[15:39] <BluesKaj> newtest1, konversation creates a log folder in your /home dir
[17:40] <test2482> ?
[19:16] <emma> valorie: my problem still isn't really fixed so when bionic is back let me know where to file a bug.
[20:46] <valorie> emma: best to comment on https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320 and mark yourself as affected
[20:47] <valorie> best way to file any bug report is commandline: `ubuntu-bug packagename` which in this case seems to be systemd
[23:34] <emma> valorie: i do not have that bug I guess.
[23:34] <emma> valorie: my problem is a bit different but also seems to be some tangled mess between PIA VPN -- NetworkManager -- resolv.conf
[23:36] <emma> The current status is that as long as I am using the VPN I am fine. If I turn off the VPN then I have to manually edit resolv.conf so that it says <IP_ADDRESS> INSTEAD OF <IP_ADDRESS> but if my USB wireless adapter needs to be unplugged or plugged back in then NetworkManager rewrites it to <IP_ADDRESS> and I can no longer use the internet without the VPN.
[23:38] <valorie> so perhaps file the bug against resolved if that is possible
[23:38] <valorie> but resolved is part of systemd
[23:47] <spirithawk> I am new to Ubuntu want kubuntu how can I make the .iso to a install cd bootable
[23:49] <valorie> hmm, what is the right invocation
[23:50] <valorie> !iso
[23:50] <valorie> hmmm
[23:50] <valorie> not right
[23:50] <valorie> !cd
[23:50] <valorie> nope
[23:52] <valorie> !install
[23:52] <valorie> there we go, spirithawk ^^^
[23:53] <BionicMac> Hello valorie
[23:53] <BionicMac> Hi emma
[23:54] <valorie> hi BionicMac
[23:58] <spirithawk> thank you all


[00:00] <smoser> right? and you can SRU that to stable releases.
[00:00] <bdrung> yes
[00:00] <bdrung> that's the plan
[00:00] <smoser> i added code to use it in cobbler, but then was pointed at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[00:01] <smoser> (i just dropped the Recommends in distro-info of cobbler to a Suggests)
[00:01] <smoser> as it was showing mismatch for build-depends on distro-info of haskel
[00:01] <smoser> so..
[00:01] <smoser> so...
[00:01] <smoser> to the question
[00:02] <smoser> are you insistent on haskell?
[00:02] <bdrung> i fail to see haskel in that diagram.
[00:02] <smoser> right. its gone now.
[00:03] <smoser> but there was a long line hanging off cobbler into some haskell libraries
[00:03] <bdrung> the haskell version is way faster than the python version and therefore i like to keep the haskell version
[00:03] <bdrung> there was a haskell transition
[00:04] <smoser> hm.. well, since its a build-depens, it doesn't really gain us to do separation (like you've done with the -data)
[00:04] <ScottK> bdrung: The problem is that haskell isn't and won't be in Main.
[00:04] <smoser> ie, we sitll get all the build-depends pulled into main of the source.
[00:06] <smoser> so, i guess my question is going forward would you be open to even splitting out source packages ? or something else that removed a dependency on haskell ?
[00:07] <smoser> i think its absolutely silly to have to SRU a package to get a string change.
[00:07] <Laney> you could feasibly have haskell bindings to a C lib
[00:07] <Laney> in a separate package
[00:08] <bdrung> smoser: what do you really want? distro-info in main?
[00:08] <Daviey> I think what smoser is getting at, would you be happy having two source packages.. a distro-info-data (containing csv's) and a distro-info tool?
[00:08] <smoser> well, i supose distro-info and distro-info-data.
[00:08] <Daviey> That would mean that A) you don't need to recompile for SRU
[00:08] <Daviey> and secondly, peope can cuse a shell or python version if they want. (in main)
[00:09] <smoser> i'd like distro-info in main
[00:09] <smoser> (or some shell usable utility, i dont really care about speed)
[00:09] <Daviey> bdrung: I must say, that a 1.5M binary + csv is pretty nuts.
[00:09] <bdrung> other user's care about speed
[00:09] <smoser> because if the shell utility is not in main, then i have to write the same thing in shell
[00:09] <smoser> (or python)
[00:09] <smoser> people dont care about speed that much.
[00:09] <smoser> and really, why would you call this program 1000s of times ?
[00:10] <smoser> it changes once per 6 months
[00:10] <bdrung> bash completion and bashrc
[00:10] <smoser> thats fair.
[00:10] <smoser> but i bet i can write native bash that are faster
[00:10] <smoser> :)
[00:10] <bdrung> Daviey: the binary size is due to haskell
[00:10] <smoser> or very close.
[00:12] <bdrung> smoser: i am willing to adopt a shell script if it can do the same as the haskell script and comes with a test suite
[00:12] <smoser> well.... that'd only get us part of the way.
[00:12] <bdrung> i can split distro-info-data into a separate package
[00:13] <smoser> ok.
[00:13] <smoser> yeah, so that'd work.
[00:13] <Daviey> bdrung: Do you agree or not that a tool for this function, is crazy being 1.5M ?
[00:14] <smoser> Daviey, i dont think we need to be rude :)
[00:14] <smoser> i'm really thankful for the utility.
[00:14] <bdrung> Daviey: yes, 1.5M is huge (but this is a restriction of Haskell)
[00:14] <Daviey> Oh i am aswell.. i think that came out wrong.. Sorry bdrung
[00:14] <bdrung> smoser: which interface do you use?
[00:14] <smoser> i just wish i would have realized it needed some help for main inclusion.
[00:14] <smoser> i'm using the shell interface.
[00:14]  * bdrung wasn't offended.
[00:14] <smoser> and i'd prefer that just because i dont care to do the date math.
[00:15] <smoser> (shell interface == command line == distro-info --supported)
[00:16] <bdrung> btw, the csv file shouldn't be used directly. so there are: command line, python, perl
[00:17] <smoser> right. i guess i hadn't thought of using python library.
[00:19] <bryceh> slangasek, hey in looking into a key mapping issue I notice our console-setup is quite diverged from debian's
[00:21] <bryceh> slangasek, there's been quite a bit of change.  I'm figuring I should just cherrypick out the specific fixes I need, but wanted to check with you if we should think about a larger import of some sort
[00:23] <bdrung> Daviey, smoser: which programming languages can be compiled in main?
[00:24] <bdrung> or should this tool be codified in shell?
[00:24] <smoser> i dont think there is a hard reason for shell.
[00:24] <smoser> if you wanted to write it in C, that'd be fine.
[00:25] <bdrung> i would prefer C over shell.
[00:25] <Daviey> bdrung: I was going to also mention vala, but it's been demoted this cycle..
[00:25] <smoser> that'd be fine. the only advantage of shell over C would be executable size.
[00:25] <bdrung> vala would be a nice tool to learn
[00:26] <Daviey> smoser: You don't think there is a slight speed advantage in C?
[00:26] <bdrung> smoser: really? shell would be smaller than C?
[00:26] <smoser> $ ls -l /bin/true
[00:26] <smoser> -rwxr-xr-x 1 root root 22896 Nov 20 12:42 /bin/true
[00:26] <Daviey> smoser: I imagine true is a compelx tool :)
[00:28] <bdrung> running u-d-t 100 times takes 0.330s and running the python version of it takes 3.045s
[00:29] <smoser> bdrung, where is "the python version" ?
[00:29] <bdrung> smoser: in the source in python/
[00:31] <bdrung> but it lacks some parameters
[00:35] <ScottK> jtaylor: Why does python-numpy recommend gcc, but python3-numpy does not?
[00:37] <infinity> bdrung: shell, C, C++, perl, python, there are a few options.
[00:38] <infinity> bdrung: As much as it's taboo to mention it, Perl would do this same job MUCH faster than Python. :P
[00:38] <smoser> infinity, FOR SHAME!
[00:38] <bdrung> infinity: nope
[00:38] <infinity> bdrung: (And it could be done entirely in perl-base, and have no deps outside Essential, I'm sure)
[00:38] <bdrung> infinity: the perl version was the slowest
[00:38] <infinity> bdrung: That's a pretty bold nope.
[00:39] <bdrung> infinity: you can either blame perl or tumbleweed for that slowness ;)
[00:39] <infinity> I'll go with the latter.
[00:40] <bdrung> i would ask you to write a faster one, but perl is not readable.
[00:40] <infinity> But other than the slightly larger disk footprint, C seems like a fair choice.  It's a simple enough thing to write bug-free on the first go.
[01:02] <cjwatson_> bryceh: it's a pain to merge and historically merges have introduced a lot of fragility, so I would be -1 on a merge at this point.  feel free to cherry-pick, though.
[01:02] <bryceh> cjwatson, sounds good, will do
[01:02] <cjwatson> that's why it tends to "fall behind" as some people see it
[01:03] <cjwatson> we'll deal at some point
[01:03] <bryceh> yeah I can tell; the patch I'm dealing with appears to be a whole bunch of different changes all mashed together.  picking out what I need will be interesting
[01:03] <cjwatson> hope you aren't trying to work with lp:{debian,ubuntu}/console-setup
[01:04] <bryceh> cjwatson, am I interpreting correctly that at least some of the keyboard mapping is duplicating code elsewhere?
[01:04] <cjwatson> almost certainly
[01:04] <bryceh> cjwatson, no, git checkout from debian
[01:04] <cjwatson> good
[01:04] <cjwatson> yeah, some of the committers aren't ... quite perfect at separating out logical changes
[01:26] <Sarvatt> ok so I want to file a bug about how apport hooks with questions present all questions twice if you click "show details" on the "Sorry, Ubuntu 12.04 has experienced an internal error." window to figure out what package the bug is for. Where would that go now?
[01:26] <Sarvatt> whoopsie or apport? :)
[01:28] <Sarvatt> xorg bugs are no fun when you have to click show details to figure out that its even the xorg bug you want to file now that it shows that generic info and walk through all of the questions to see what package its for, then again to actually file it
[01:31] <Sarvatt> i usually have at least 10 .crash files in /var/crash that i've already filed bugs for so clicking show details on each is required to see if i'm wasting my time filing the same one
[02:00] <smoser> bdrung, still around ?
[02:19] <bdrung> smoser: yes
[02:20] <smoser> i have a version of ubuntu-distro-info in shell that compares favorably in load times to the haskel
[02:20] <smoser> http://paste.ubuntu.com/891634/
[02:21] <smoser> i think the --date= needs some work.
[02:21] <smoser> but it shouldn't add too much
[02:22] <smoser> locally, 1000 runs shows http://paste.ubuntu.com/891636/
[02:23] <smoser> but i have to run now.
[02:24] <smoser> i'm willing to polish that some more.
[02:43] <bdrung> smoser: you are fast. it could use "set -e". some comments would be nice.
[02:50] <bdrung> smoser: --devel and --lts produce wrong output
[04:01] <slangasek> bryceh: console-setup isn't a safe package to be doing large imports of post-FF... I'd say cherry-pick what you need
[04:01] <ScottK> slangasek: He got the lecture from cjwatson already today.
[04:01] <slangasek> heh, ok
[04:04] <bryceh> slangasek, yeah picked out the bit I needed.  I gather all changes are direct applied rather than use a patch system?
[04:05] <slangasek> it's a native package maintained in a VCS - a patch system would be unhelpful :)
[04:05] <bryceh> er...
[04:18] <komputes> hi bryceh how are you?
[04:18] <bryceh> hi komputes I'm good
[04:19] <komputes> thats good to hear, long time no talk. are you strictly maintaining xorg these days?
[04:20] <bryceh> komputes, I would say more indulgently
[04:25] <komputes> it's in your blood :D
[08:04] <dholbach> good morning
[08:10] <ZeroKewl> hi
[08:11] <ZeroKewl> where did xbox controller started working out of box in ubuntu 12.04
[08:11] <ZeroKewl> when* -where
[08:32] <Riddell> janimo`: libva-cedarview-vaapi-driver for restricted?
[08:52] <apw> can anyone tell me what an package flagged 'un' in dpkg -l means ?
[08:52] <apw> un  linux-image-3.0
[08:53] <apw> and indeed how one gets rid of em
[08:56] <geser> apw: see the header of "dpkg -l" for an explanation (un: Desired=Unknown, Status=Not Installed)
[08:57] <apw> geser, hmm oh desired ... so once you install a packge its in your db forever even if its not longer installed
[08:57] <smb> That does not seem to be what happens when I uninstall things
[08:58] <smb> Those seem to either become rc (removed configured) or go away (purged)
[08:59] <geser> apw: I guess that's also true for any package dpkg knows about (because it's listed in Recommends, Suggests, Conflicts, etc)
[08:59] <apw> geser, hmmm, i'd expect them to be singletons as they are all test kernels once installed long ago
[09:01] <apw> un  linux-image-3.0-0-generic                             <none>                                                (no description available)
[09:01] <apw> so that one i literally just purged it and its gone to that state
[09:03] <geser> IIRC dpkg has a list of package names it has ever seen
[09:03] <geser> check if it's listed in /var/lib/dpkg/available
[09:05] <apw> geser, yep it is in there
[09:09] <geser> try "dpkg --forget-old-unavail" (or ask someone who knows dpkg better than me how to get rid of those old entries)
[09:12] <smb> So the difference is in how one uses dpkg -l: "dpkg -l|grep linux-image" won't show un, but "dpkg -l linux-image-*" will do
[09:12] <jhojho> has anyone actually tried out the openssl package on 64bit precise?
[09:13] <jhojho> i'm getting much slower speed timings for one and secondly, it seems to be dropping back to sslv3 vs tls1 for some reason
[09:13] <jhojho> even when i have what I think is a correct config.....
[10:04] <janimo`> Riddell, please purge that package, there will be a newer upload later, with fixed copyright
[10:06] <Riddell> janimo`: rejected!
[10:06] <janimo`> Riddell, thanks!
[11:06] <janimo`> pitti, the acpi-support deprecation wikipage is almost 3 years old. https://wiki.edubuntu.org/AcpiSupportDeprecation . What is the status of this package? I lookoed at the hotkey debugging pages that mantioned it is being phased out but no details
[11:17] <nailora> could someone un-private bug #930677 if possible? thanks!
[11:18] <nailora> it is referenced in Bug #952577
[11:25] <sladen> nailora: what is your Launchpad ID?
[11:28] <sladen> nailora: poke
[11:29] <brendand> sladen, i don't see anything private in there so it's un-privated
[11:33] <sladen> nailora: see brendand above ^^
[11:41] <nailora> https://launchpad.net/~nailor
[11:42] <nailora> brendand: thanks
[11:59] <MacSlow> mvo, ping
[12:22] <mvo> MacSlow: pong
[13:04] <slangasek> janimo`: acpi-support hasn't been phased out yet because there are some hotkeys that nothing else in the stack has handling for (antenna, touchpad toggling keys)
[13:06] <seb128> slangasek, the pad enable,disable is handled by gnome-settings-daemon (just for info) but maybe you need something not desktop specific for those ;-)
[13:07] <slangasek> seb128: when did it start handling them?
[13:08] <seb128> slangasek, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=1c8f64d1dc6beb7d27a6dce74fa29e27e8c34583
[13:08] <seb128> slangasek, so in the natty version it seems
[13:09] <seb128> slangasek, if that's the same keys we are talking about
[13:10] <slangasek> seb128: ah, I'm pretty sure X can't actually receive that keypress due to the core input limitation
[13:11] <janimo`> slangasek, Riddell the acpi-support changelog mentions dropping power.sh when kubuntu starts using upower, not sure if that is the case, it is an old comment
[13:11] <janimo`> slangasek, and are there better suited packages for the things acpi-support is still needed for or it is here as a catch-all for the forseeable future?
[13:11] <seb128> slangasek, well, it works for most people it seems
[13:12] <slangasek> janimo`: if there were better-suited packages, it wouldn't still be needed :)
[13:12] <seb128> slangasek, we got bugs about the notify-osd corresponding images being reversed previous cycle
[13:12] <slangasek> seb128: hmm, I'll have to test then
[13:12] <seb128> slangasek, which indicates the g-s-d action get triggered
[13:12] <seb128> slangasek, ok ;-)
[13:13] <slangasek> seb128: right, but we just recently (this cycle) got a report from someone else wanting touchpad toggle support in acpi-support for a new device
[13:13] <janimo`> slangasek, well what I meant was there may be other packages but migrating is ongoing and not terribly urgent
[13:13] <janimo`> as opposed to noweher to migrate yet :
[13:13] <janimo`> :)
[13:14] <slangasek> janimo`: power.sh should definitely go away if kubuntu is using upowerd now
[13:14] <seb128> slangasek, https://bugs.freedesktop.org/show_bug.cgi?id=31300#c2 might be interesting
[13:15] <seb128> slangasek, well not sure what happened since and if that works for laptop that have a physical action connected to the key or not
[13:15]  * slangasek nods
[13:16] <seb128> slangasek, seems it's the same issue than sound, some hardware require you to handle to action, some others don't
[13:16] <slangasek> well, seems like those should be represented as different types of events
[13:17] <slangasek> not sure why a button press that the software isn't expected to handle should ever show up as a key event
[13:18] <slangasek> anyway, I'll test with my T60 and see what I get
[13:18] <seb128> slangasek, because you still want the notify-osd bubble
[13:18] <slangasek> there's no reason to logically represent that as a *keypress* though
[13:18] <seb128> slangasek, what is doing the action doesn't matter much, but you want a consistent feedback mechanism
[13:18] <slangasek> it's a notification event
[13:18] <seb128> right
[13:18] <seb128> that's a good point ;-)
[13:19] <slangasek> so there should be a different channel for that from the kernel to g-s-d... and maybe that's the one that actually works now
[13:19] <slangasek> anyway, I know thinkpads *don't* handle it in hardware, so I'll check it out and report back :)
[13:21] <seb128> slangasek, thanks ;-)
[13:26] <stgraber> dpm: can you add me to the translation team mailing-list whitelist so I can reply to mails without having them go through moderation, yet don't need to subscribe?
[13:29] <dpm> stgraber, I can at least try :) IIRC there is a filter to accept any ubuntu.com address, but it seems not to be working. Let me have a look...
[13:31] <stgraber> dpm: I usually do it through the moderation queue, when you accept my next e-mail, you can tick a box saying any other e-mail from my address is accepted
[13:32] <dpm> stgraber, ah, I see. I never use the admin interface, I use listadmin, which is much quicker
[13:33] <dpm> in any case, you're now whitelisted
[13:34] <stgraber> dpm: thanks
[13:36] <cjwatson> it'd be awesome if listadmin could understand that bit of the moderation queue interface
[14:05] <cjwatson> popey: bug 960092 - can you tell me about your partition/filesystem layout?
[14:06] <soren> debconf is confusing me.
[14:06] <soren> When I add a template to a package  (which already used debconf)... How does its new templates get added to the debconf cache?
[14:07] <soren> dpkg and debconf are separate, so it's not dpkg itself.
[14:07] <cjwatson> the frontend loads templates from whatever it's operating on
[14:07] <cjwatson> dpkg-preconfigure does it too, via apt-extracttemplates
[14:07] <soren> Ah.
[14:08] <soren> It's a bit special. I'm building something very much like dbconfig-common, so my package ships the templates, but doesn't actually use debconf itself.
[14:08] <soren> ...so that's why they're not getting loaded (and why I can't reference them with db_register from another package).
[14:08] <cjwatson> there's debconf-loadtemplate if you really have t
[14:08] <cjwatson> o
[14:09] <cjwatson> or you could load the confmodule in your postinst, but do nothing else with debconf
[14:09] <soren> The latter sounds like a better idea.
[14:09] <cjwatson> likely, yes
[14:09] <soren> I guess I eventually will want to actually use debconf in this package too.
[14:09] <soren> I wonder how the first set of templates got added..
[14:10] <popey> cjwatson: left comment on the bug
[14:10] <soren> I guess I must have triggered debconf at some point. I can't imagine how or why, but meh.
[14:11] <cjwatson> popey: hm, so 1.99-17ubuntu1 worked but 1.99-18ubuntu1 failed?
[14:11] <cjwatson> (wtf?  I didn't touch partition handling.)
[14:11] <popey> cjwatson: well, it may have been a day or more between updates on that box. but it is my main desktop, and doesn't get rebooted that often, often suspended
[14:12] <cjwatson> popey: you said you reinstalled grub to get it back to a bootable state, so presumably you know what version you reinstalled?
[14:13] <popey> cjwatson: I just did grub-install
[14:13] <popey> cjwatson: sorry, "grub-install /dev/sdb"
[14:13] <cjwatson> oh, you were probably misconfigured to start with then.  I left a question in the bug ...
[14:14] <soren> cjwatson: Fantastic, that did the trick. Thanks!
[14:14] <popey> cjwatson: sorry, pasted, should have attached.
[14:15] <cjwatson> no matter
[14:39] <soren> cjwatson: What if I'm updating an existing template rather than adding a new one? The new ones are in /var/lib/dpkg/info/<my package>.templates, and I do include confmodule in my postinst, but /var/cache/debconf/templates.dat still has the old templates.
[14:42] <cjwatson> soren: that normally just works
[14:42] <cjwatson> sorry, not sure what the problem might be in your case
[14:43] <smb> cjwatson, Just to make sure I understand right: so the multipath udeb would only carry dm-multipath and dm-round-robin ? I am not sure abotu the scsi device handlers. They might be only used for multipath setups but on the other hand are grouped into the scsi subsystem.
[14:44] <soren> Perhaps it refrains from refreshing because there are multiple owners?
[14:45] <cjwatson> smb: {dm-multipath,dm-round-robin} -> multipath-modules, scsi device handlers -> scsi-modules sounds o
[14:45] <cjwatson> ok
[14:46] <cjwatson> smb: I'm just trying to claw things back into being slightly more in line with Debian because it means less unnecessary divergence in the userspace installer code
[14:47] <smb> cjwatson, ok thanks. will look to get it done. Less divergence is good and it should not be a really big change, so it makes much sense to get it done right now that there need to be changes anyway
[14:51] <cjwatson> smb: great, thank you
[14:51] <cjwatson> soren: I would have expected it to add an owner in the case of any shared templates, and just add any non-shared ones
[15:10] <soren> cjwatson: *blush*
[15:10] <soren> cjwatson: I had a copy of the templates file in another package.
[15:11] <soren> cjwatson: With all the same names.
[15:11] <soren> cjwatson: So each time I installed that, I'd get the old version.
[15:12] <soren> cjwatson: And my test-debug cycle included: Install the config-common package -> isntall a package that consumes it -> test.
[15:12] <soren> cjwatson: So it always overwrote the changed templates.
[15:12] <cjwatson> whoops
[15:13] <cjwatson> yeah, easy to make that kind of mistake with shared templates
[15:19] <soren> cjwatson: Ironically, I'm doing this to *avoid* sharing templates, and just ship them in a single package (and use db_register <common package>/$question <consumer package>/$question). I just copied the templates file over at some point by mistake.
[15:19] <soren> I never noticed because so far, I've only been *adding* new templates. Added templates got through just fine.
[15:19] <soren> *headdesk*
[15:19] <cjwatson> heh
[15:19] <cjwatson> ah well
[15:52] <tsdgeos> what's the best way to store a dictionary inside a gvalue?
[15:52] <tsdgeos> i went the way of gvalue being a variant and the variant being a dictionary
[15:52] <tsdgeos> sounds ok?
[16:05] <Riddell> janimo`: yes we use upower in KDE
[16:05] <slangasek> mvo: I'm not sure I understand the right way to pop up a notification about a package's download failing; from what I can see in the code, /var/lib/update-notifier/user.d/ is only processed when a new file is added there or when the applet starts, is that right?
[16:05] <slangasek> mvo: in which case it seems I want the script to add/remove a file to that directory, and not use DisplayIf?
[16:06] <mvo> slangasek: yeah, add it or touch it (to display the notification again)
[16:07] <slangasek> ok
[16:10] <smb> cjwatson, Oh, I just remembered something else. I think you at least sponsored some updates to dmraid user-space. I think I found some discrepancy in the initramfs-tools scripts/hooks. Unfortunately lost the bug reporter for now... bug 948291 (comments 37 and 38)...
[16:11] <smb> (afraid it is a bit in the middle of things... just the difference between output and input seemed like one thing more likely broken...)
[16:11] <cjwatson> smb: sponsored, but I don't feel confident to make changes on my own initiative
[16:12] <cjwatson> smb: if you can get hold of psusi, he tends to be useful on this
[16:12] <smb> cjwatson, Ok, I'll try... Saw his name too
[16:15] <ricotz> smoser, hi, could you have a look at qemu-kvm which installs /usr/etc/qemu/target-x86_64.conf, i guess this should go to /etc/qemu/target-x86_64.conf
[16:16] <smoser> ricotz, can you open a bug ?
[16:16] <ricotz> smoser, i was hoping pinging you might be enough
[16:17] <smoser> well, i was just going to ping hallyn
[16:17] <smoser> but ... a bug would still be helpful.
[16:17] <ricotz> ok
[16:19] <slangasek> mvo: do you know what creates /var/lib/update-notifier/user.d/firefox-restart-required nowadays?  The only thing I find in the firefox postinst is 'touch /var/run/firefox-restart-required'
[16:19] <slangasek> mvo: I'm trying to find this to see how they've handled localization so I can copy it
[16:19] <ricotz> smoser, https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/960359
[16:19] <mvo> slangasek: sorry, I don't know
[16:19] <mvo> slangasek: maybe the ubufox stuff?
[16:20] <mvo> slangasek: but chrisccoulson should know
[16:20] <slangasek> I'll look there, thanks
[16:20] <smoser> ricotz, gracias
[16:20] <chrisccoulson> mvo, slangasek, we haven't had that in firefox since lucid
[16:20] <slangasek> chrisccoulson: hah, ok
[16:21] <slangasek> chrisccoulson: why did it go away?
[16:21] <slangasek> (OOI)
[16:22] <chrisccoulson> slangasek, it was sort-of redundant. we already have the restart notification banner inside firefox, so we just use that rather than relying on update-notifier
[16:22] <slangasek> fair enough
[16:22] <slangasek> (though personally, the restart banner drives me crazy ;)
[16:23] <chrisccoulson> slangasek, it's meant to make you want to restart :)
[16:23] <chrisccoulson> although, i think i changed the timings this cycle so that it doesn't remind so often
[16:23] <slangasek> chrisccoulson: it doesn't make me want to do that, it makes me want to swear off web browsing! :)
[16:23] <chrisccoulson> lol
[16:24] <slangasek> ah, looks like the french translation is statically encoded here, ah well
[16:27] <chrisccoulson> slangasek, we might get rid of the restart banner at some point (and turn it in to a notification panel inside firefox instead, which doesn't shift the content down when it appears)
[16:44] <mdeslaur> slangasek: fyi: #952556
[16:47] <slangasek> mdeslaur: are you seeing this behavior?
[16:47] <mdeslaur> slangasek: I haven't checked personally, but it looks like something we should take a look at
[16:48] <mdeslaur> I'll try it on my test laptop, one sec
[16:50] <slangasek> mdeslaur: looks like I can reproduce it here
[16:50] <slangasek> which is strange, because I definitely *didn't* see this earlier in the cycle when making that change
[16:52] <slangasek> cking: why are you sure bug #952556 isn't a kernel bug?  I don't think this was the behavior in January at the time I changed the hdparm apm_battery setting, and hdparm hasn't changed at all since
[16:52] <slangasek> so I think something has changed in the kernel
[16:52] <mdeslaur> slangasek: well, some of the desktop power optimisations may have decreased regular disk activity
[16:53] <slangasek> yes, that was actually a precondition of me changing hdparm
[16:53] <mdeslaur> ah! i see
[16:53] <slangasek> before, the root problem wasn't the spin*down* time, it was the spin *up* frequency
[16:53] <cking> slangasek, well, it still happens when the user uses an oneiric kernel
[16:53] <slangasek> cking: ok
[16:53] <slangasek> that's pretty conclusive then
[16:54] <cking> and I checked it on an hpmini this afternoon
[16:54] <slangasek> let me see if something's regressed on the desktop to cause these spin-ups
[16:54] <cking> I also factored out the pm-utils changes just to sanity check things
[16:55] <slangasek> so, setting a higher spindown time by default is probably reasonable in any case
[16:55] <slangasek> and would guard against destroying disks
[16:55] <slangasek> so I think we'll go ahead with that
[16:56] <mdeslaur> fwiw, my count increased by 3 in 5 minutes
[16:57]  * slangasek breaks out fatrace \o/
[16:58]  * mdeslaur tries fat race too :)
[17:03] <slangasek> kinda looking like a firefox regression
[17:03] <slangasek> or possibly a google regression :P
[17:05] <cking> slangasek, yep I think a higher spindown time is a good solution
[17:09]  * micahg pops his head up
[17:10] <doko> is there a known issue with usb disks in the precise kernel? getting now I/O errors with the second usb disk. just do not want to believe that both external disks are damaged
[17:11] <mdeslaur> wow, fatrace is awesome
[18:09] <slangasek> mvo: I notice as I'm testing this u-n change that u-n only processes hooks when something touches /var/lib/update-notifier/dpkg-run-stamp.  It seems to me that the two should be somewhat independent?
[18:59] <ahasenack> SpamapS: ping, around?
[19:04] <psusi> ok, so multipath-tools has a binary package named multipath-tools-boot that contains the initramfs hook to add multipath-tools and kpartx to the initramfs... dmraid needs kpartx to be in the initramfs.. so, should I add a hook to dmraid to copy the kpartx binary, or split the multipath-tools hook in two, so there is on efor multipath-tools-boot, and one for kpartx?  hrm...
[19:08] <cjwatson> we generally put the hooks in the package that ships the binary because that means that the initramfs gets updated every time the package that actually ships the binary is updated, which is important
[19:09] <cjwatson> so maybe in kpartx itself but with something to arrange that it only actually goes in the initramfs when needed?
[19:10] <psusi> ahh.. hrm.. what would that something be?
[19:10] <cjwatson> not sure :-)
[19:11]  * cjwatson handwaves merrily
[19:11] <ahasenack> hi, quick (I hope) question about bzr merge-upstream, it seems it is bzr deleting all files and then bzr adding all the new files, that's not a merge
[19:12] <ahasenack> bzr st shows it removing and adding the same file, even though that file didn't change regarding the upstream version
[19:12] <ahasenack> like, the LICENSE file, it's exactly the same
[19:12] <psusi> what is it that makes the initramfs update when you upgrade the package anyhow?  does it need to call update-initramfs from its postinst?
[19:12] <cjwatson> psusi: right, and that ends up activating a trigger
[19:16] <psusi> hrm... this is odd... multipath-tools-boot has a postinst that runs update-initramfs to process the included hook... the hook checks for the existance of /sbin/multipath-tools and exits if it doesn't exist.  multipath-tools-boot does not depend on multipath-tools... so strangely, you can install it and it effectively does nothing unless you also install multipath-tools
[19:17] <psusi> I think I'll fix the existing hook so that it just skips the multipath-tools parts if it is not found, but if kpartx is found, will copy that in... then add multipath-tools-boot as a depend of dmraid
[19:20] <broder> psusi, cjwatson: you could use the initramfs-tools variable thing that plymouth uses to trigger
[19:21] <broder> so then i think anything that wanted kpartx would ship a file in, uh, /usr/share/initramfs-tools/conf-hooks.d/blah
[19:27] <cjwatson> broder: thank you for concretifying my handwaving
[19:29] <mvo> slangasek: sorry for the delay- that is correct, it was designed to not popup in the middle of a upgrade, originally this handled stuff like the reboot required. but indeed, its no longer a valid reason (as reboot-required is done differently these days)
[19:30] <slangasek> mvo: ok, I'll adjust the code then to process the hooks anyway, thanks
[19:32] <mvo> thanks
[19:32] <mvo> for a bit of background, I had hoped we could get rid of update-notifier in favor of upstart user session event scripts, but we are not there yet
[19:32] <mvo> (it seems at least)
[19:39] <slangasek> ah :)
[19:51] <SpamapS> ahasenack: howdy
[19:51] <ahasenack> SpamapS: \o/
[19:52] <ahasenack> SpamapS: so I tried a bit bzr merge-upstream, can I make some questions?
[19:53] <ahasenack> SpamapS: are you on the udd mailing list?
[19:54] <micahg> https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2012-March/001052.html
[19:54] <ahasenack> micahg: thanks! :)
[19:57] <SpamapS> ahasenack: I'm not
[19:57] <ahasenack> SpamapS: my question is above in the archive link that micahg pasted
[19:57] <ahasenack> SpamapS: basically, seems like bzr merge-upstream deletes and adds all files again
[19:57] <ahasenack> regardless if they had changes or not
[19:58] <SpamapS> ahasenack: hm
[19:58] <SpamapS> ahasenack: I would not expect it to do that.
[19:58] <ahasenack> SpamapS: good :)
[20:01] <SpamapS> ahasenack: I am trying it now.. I've never used the bzr branch with --revision and --version before.. it may work differently
[20:02] <ahasenack> SpamapS: I tried a few combinations, but got the same result
[20:03] <micahg> it might be treating it as a bzr branch instead of an upstream tarball, but I'm not sure how the upstream tarball behaviour works TBH
[20:04] <SpamapS> ahasenack: as micahg is eluding to.. try it that way
[20:04] <SpamapS> with bzr exported to a tarball
[20:04] <ahasenack> SpamapS: I think it's what merge-upstream ends up doing, because I saw a tarball in the parent directory
[20:04] <ahasenack> SpamapS: but let's try
[20:05] <ahasenack> SpamapS: yeah, now it worked as expected
[20:06] <ahasenack> SpamapS: http://pastebin.ubuntu.com/892732/
[20:07] <SpamapS> ahasenack: so, I would suspect that when doing a bzr branch, there is some extra magic being attempted..
[20:09] <ahasenack> SpamapS: what you did yesterday, was with a tarball?
[20:10] <ahasenack> SpamapS: and, did you just try with a branch? Did you get the same add/remove outcome as I?
[20:12] <SpamapS> ahasenack: what I did yesterday was upload a pure source package. The package importer pulled that into ubuntu:landscape-client
[20:13] <ahasenack> SpamapS: ok, and did you try merge-upstream with a branch just now, just to see if you get the same outcome as I?
[20:13] <SpamapS> ahasenack: I did, and got the same outcome.
[20:14] <ahasenack> ok
[20:14] <ahasenack> looks like we should avoid that for now
[20:14] <ahasenack> SpamapS: thanks!
[21:16] <bernie> anyone knows why there have been no new chromium snapshots in the ppa for a couple of months?
[21:17] <micahg> bernie: various reasons, I'm trying to get it sorted, hopefully by the time precise releases
[21:18] <bernie> micahg: cool thanks
[22:11] <rsalveti> ogra_: do you know why the installer slideshow is still broken on arm?
[22:12] <rsalveti> don't remember if it was simply something we decided to drop, or that wasn't enabled properly after that bug we had with webkit
[22:12] <rsalveti> I'd like to have it working again as then we can have a similar installer experience as we have for other archs
[22:12] <rsalveti> let me try to find a bug for it
[22:32] <rsalveti> ogra_: neither universe nor multiverse is enabled by default
[22:33] <rsalveti> it's also lacking the deb-src lines as well
[22:33] <rsalveti> guess a bug at livecd-rootfs
[23:15] <TheMuso> @pilot in
[23:34] <popey> cjwatson: just seen someone else with the same grub issue I had
[23:36] <popey> cjwatson: https://plus.google.com/u/0/115941496951821782702/posts/1vwCLcQtFY4
[23:37] <popey> pointed him at the bug report


[14:39] <rzr> hi
[14:39] <rzr> anyone near KL ?
[14:40] <rzr> an event about linux mobile is planned next week and the organizers are looking for visibility , can you help ?
[14:40] <rzr> anyway here is the entry point :
[14:41] <rzr> http://wiki.meego.com/Local_MeeGo_Networks/Malaysia
[18:59] <ejat> elo ..
[19:30] <rzr> hi$
[21:07] <ejat> ?
[21:13] <rzr> hi
[21:13] <rzr> ejat: do u know about linux kl lugs ?
[21:14] <ejat> got a few groups ..
[21:14] <ejat> but they all gather under osdc.my
[21:14] <ejat> anything ?
[21:29] <rzr> ok
[21:29] <rzr> because I wanted to help some pals to promote this event :
[21:30] <rzr> http://wiki.meego.com/Local_MeeGo_Networks/Malaysia