[04:54] <pitti> Good morning
[04:55] <pitti> cjwatson: g-i> thanks for the heads-up
[05:47] <lucidfox> Question
[05:47] <lucidfox> Where and how do I ask for my Ubuntu Member status to be revoked?
[06:01] <pitti> lucidfox: you can launch any LP team (like https://launchpad.net/~ubuntumembers) with the "Leave this team" button
[06:01] <pitti> lucidfox: err, "launch" →  "leave", sorry
[06:01] <pitti> in leavepad :)
[06:01] <lucidfox> heh
[06:24] <pitti> infinity: wow! https://launchpad.net/builders
[06:24] <pitti> infinity: we have multi-arch builders now?
[06:25] <pitti> infinity: so if I was to throw 823948239 langpacks at them, they'd  all build them in no time? :-)
[06:27] <StevenK> pitti: We have for a little while. wgrant is who you want to buy a fair bit of beer.
[06:27] <pitti> wgrant: woo! many thanks for this
[06:27] <pitti> lftp wgrant
[06:27] <pitti> lcd /cellar/beer-rack/
[06:27] <pitti> mput *
[06:28] <StevenK> And now wgrant is suffering alcohol poisioning?
[06:28] <StevenK> :-P
[06:30] <wgrant> pitti: Yeah, you can now drown the amd64 buildds as well :D
[06:30] <pitti> first trusty langpacks built and tested, throwing buildd-wards then
[06:32] <pitti> wgrant: I guess https://dev.launchpad.net/Translations/LanguagePackSchedule is not current, right?
[06:32] <pitti> wgrant: do we build trusty langpacks on Tue and Thu now (in LP)?
[06:34]  * pitti watches all his little minions on https://launchpad.net/builders
[06:34] <wgrant> pitti: I've updated that page
[06:34] <wgrant> At least the export column
[06:34] <pitti> thanks
[06:35]  * pitti desperately looks for an "Edit" link
[06:35] <wgrant> You need to log in first
[06:35] <pitti> Logged in as   pitti
[06:35] <wgrant> Ah, you probably need to be a member of ~launchpad-doc
[06:36] <wgrant> What should the PPA schedule look like?
[06:37] <pitti> wed, fri: trusty, thu: saucy, tue: precise (currently disabled)
[06:37] <pitti> wgrant: i. e. export day + 1
[06:38] <wgrant> Right
[06:39] <pitti> wgrant: thanks!
[06:40] <wgrant> np
[07:46] <dholbach> good morning
[08:36] <pitti> xnox, stgraber: FYI, it seems fstrim doesn't support LVM (I created a LUKS and an LVM from two PVs), too bad
[08:37] <pitti> xnox, stgraber: and neither does discard
[08:39] <pitti> curiously, hdparm -I /dev/mapper/testlvm-fivem works (it "looks through" the mapper)
[08:39]  * pitti does some RTFM, "fstrim lvm" has plenty of google juice
[08:42] <pitti> ah, /etc/lvm/lvm.conf needs to have issue_discards = 1
[08:52] <zyga> hi
[08:52] <zyga> running trusty daily, I cannot log in, while mouse works okay in lightdm keyboard seems to just be ignored (apart from being able to switch to other vt)
[08:52] <zyga> has anyone seen this issue?
[08:53] <zyga> currently on lighdm 1.9.5-0ubuntu1
[09:08] <pitti> stgraber: so we'll need to add the "allow-discards" option to crypttab in partman; is that something you feel up to? (I added an unowned WI)
[09:09] <pitti> stgraber: the option isn't enabled by default in cryptsetup because it exposes additional information on the raw device (according to the manpage), but for a "full disk encryption" setup we certainly want it
[09:11] <RAOF> I'm not sure that we do want it for full disk encryption? It leaks filesystem details.
[09:12] <pitti> the alternative is "your SSD sucks after a few weeks of usage"
[09:12] <pitti> "For  example,  information leaking filesystem
[09:12] <pitti>               type, used space, etc. may  be  extractable  from  the  physical
[09:12] <pitti>               device  if  the  discarded  blocks  can  be located later."
[09:13] <pitti> that sounds a bit fuzzy, not sure how big the impact is?
[09:13] <pitti> i. e. if you get the raw SSD, look for discarded/non-discarded blocks, and from their pattern make assumptions about the state of the disk
[09:13] <RAOF> Yeah, probably not much.
[09:14] <pitti> but IMHO that's an acceptable compromise to do to keep your SSD in a working state in the first place
[09:14] <pitti> if you are concerned with that, the first thing you'd need to do is to completely fill your drive once
[09:15] <pitti> and then live with getting 1/50th of its normal write performance
[09:26] <xnox> pitti: those that want privacy with ssd, would use self-encrypting drives. in which case one cannot analyze / infer anything from the filesystem, since block devices are not expose until after ATA unlock.
[09:27] <pitti> xnox: ah, good point
[09:27] <xnox> pitti: thus imho, trim should be enabled.
[09:28] <xnox> pitti: then again why use cryptsetup with self-encrypting drive.... is beyond me =)
[09:29] <pitti> hm, issue_discards doesn't seem to work for me (LVM); there's debian bug 717313, but it didn't get an answer
[09:30] <xnox> pitti: hm =( last time i looked into this, i thought that it is safe enough these days to enable "issue_discards" unconditionally, it just wouldn't do anything on spinny drives.
[09:31] <xnox> pitti: i can test it harder here on an ssd. as well.
[09:31] <pitti> xnox: yes, it says it's only having an effect if kernel and drive support it
[09:31] <pitti> xnox: but I enabled it, update-initramfs, reboot, and still fstrim says "invalid ioctl"
[09:31] <pitti> (IOW, not supported)
[09:34] <pitti> xnox: oh, perhaps I need to do this before pvcreate/vgcreate/lvcreate, /me tries
[09:36] <pitti> xnox: oh, nevermind; I formatted it with ext2, that's the bit which breaks it
[09:37] <zyga> running trusty daily, I cannot log in, while mouse works okay in lightdm keyboard seems to just be ignored (apart from being able to switch to other vt)
[09:37] <zyga> is this a known issue, any way to work around it to do stuff?
[09:38] <pitti> xnox: so, issue_discards isn't necessary for fstrim, only if you modify the LVM structure; we should enable it anyway, though
[09:39] <xnox> pitti: excellent \o/
[09:40] <pitti> xnox: so, for "normal" partitions I do an hdparm -I check and fstrim; for devmapper I do fstrim 2>/dev/null || true
[09:40] <pitti> as decomposing the LVM to its PVs and running hdparm on them is probably way more costly than just tryign to call fstrim
[09:40] <pitti> xnox: does that seem ok to you?
[09:41] <xnox> yeap.
[09:41] <pitti> xnox: now my fstrim cron job works for normal partitions, cryptsteup, and LVM
[09:41] <xnox> which package is it going to live in?
[09:41] <pitti> xnox: http://people.canonical.com/~pitti/scripts/fstrim
[09:42] <pitti> xnox: hm, how about util-linux?
[09:42] <pitti> (that ships fstrim)
[09:42] <pitti> xnox: ideas appreciated
[09:44] <xnox> sounds good, if util-linux maintainer would be ok with that. lamont infinity ^
[09:46] <GunnarHj> xnox: Hi Dimitri!
[09:46] <xnox> GunnarHj: holla! =)
[09:46] <GunnarHj> xnox: Have you noticed bug 1260604?
[09:47] <xnox> GunnarHj: yes, i have. and asked for logs on it.
[09:47] <GunnarHj> xnox: Aha, see that now. ;-)
[09:48] <Laney> xnox: http://paste.debian.net/plain/70639
[09:48] <Laney> from ricotz, haven't looked into it
[09:50] <GunnarHj> xnox: It's easy to install and switch to GDM for test purposes.
[09:53] <xnox> Laney: that seems right.
[09:54] <xnox> Laney: will upload, or can ricotz upload it?
[09:55] <Laney> nope
[09:55] <Laney> you do it if you confirm it fixes the problem
[09:55] <xnox> Laney: ack.
[10:23] <pitti> xnox, lamont, infinity: filed debian bug 732054 FTR
[10:25] <seb128> dpm, pitti: can one of you approve https://translations.launchpad.net/ubuntu/trusty/+source/evolution/+imports ?
[10:25] <seb128> the 3.10 template
[10:26] <seb128> the new langpacks still have 3.8 which means no translation since we are on 3.10 :/
[10:26] <seb128> same for https://translations.launchpad.net/ubuntu/trusty/+source/evolution-data-server/+imports
[10:26] <pitti> seb128: I can't approve :/
[10:26] <seb128> :-(
[10:27] <seb128> let's see if dpm can
[10:27] <seb128> we might need wgrant or somebody with lp powers?
[10:27] <pitti> meh, BP WI diff emails are broken, they only show the removals
[10:28] <seb128> pitti, since when? I got some correct ones yesterday
[10:28] <pitti> for several months already
[10:28] <seb128> are you sure it's not your email client?
[10:28] <pitti> also, it seems if you change WIs with the Ajaxy bits, when saving it back it shows the old one
[10:28] <pitti> you need a page reload to update
[10:28] <pitti> seb128: yes
[10:28] <pitti> its LP
[10:28] <seb128> wfm
[10:29] <pitti> i. e. when changing them twice, you need to reload, otherwise you'll destroy your first changes
[10:29] <pitti> gema had it as well, I'm not alone
[10:29] <Laney> FF?
[10:29] <pitti> Laney: yes
[10:29] <pitti> (our default browser, I might point out :) )
[10:29] <Laney> yeah, just checking
[10:29] <Laney> I use it too (and haven't seen that)
[10:29] <pitti> but as the mails reflect that, it doesn't seem browser specific?
[10:30] <Laney> seems like you were describing two issues
[10:30] <seb128> pitti, wfm
[10:30] <seb128> I just editing https://blueprints.launchpad.net/ubuntu/+spec/client-s-system-settings-panels in firefox
[10:30] <seb128> changed charles in charlesk
[10:30] <seb128> and the page had the correct content without reload
[10:30] <seb128> or refresh
[10:30] <Laney> http://paste.ubuntu.com/6565987/
[10:30] <Laney> I did that yesterday
[10:31] <seb128> right, that's the email I got
[10:31] <seb128> correct diff
[10:31] <brendand> pitti, fstrim script. handy
[10:31] <seb128> pitti, maybe QA blueprints have something special that confuses lp?
[10:31] <Laney> the diff does look a bit weird actually
[10:31] <GunnarHj> xnox: ricotz's suggestion is not sufficient to fix bug 1260604. I added my ~/.xsession-errors to the bug.
[10:31] <Laney> why are there all those Work items: sections?
[10:32] <Laney> unless I did actually break that
[10:32] <pitti> seb128: no idea what the difference is; they are ubuntu specs like everything else
[10:32] <seb128> pitti, yeah, me neither, needs some lp debugging I guess :/
[10:32] <seb128> pitti, I just wanted to point out that the feature is not broken across the board
[10:32] <pitti> seb128: good to know
[10:33] <seb128> Laney, but yeah, that diff of yours is buggy as well, it has several "+ Work items for ubuntu-14.01:"
[10:34] <Laney> so I can believe some parser is going wrong
[10:35] <seb128> pitti, did you file a lp bug about that yet?
[10:35] <pitti> seb128: gema said she was going to back then, I'll have a look
[10:41] <caribou> where is the best place (i.e. irc room) to ask debian packaging specific questions ?
[10:46] <seb128> caribou, you can ask here I guess
[10:47] <caribou> seb128: thanks, but I may have found the answer myself
[10:47] <seb128> caribou, if you need confirmation you can still ask here ;-)
[10:48] <caribou> seb128: I need to run a script only at build time & needed to know where it would fit best
[10:48] <seb128> debian/rules?
[10:49] <caribou> seb128: thought of it, but it's a bunch of subshell cmds so it doesn't fit the Makefile format
[10:49] <caribou> seb128: I created a script in debian/ & used 'override dh_auto_build" to cal lit
[10:49] <seb128> caribou, well, you can always write a shell script in debian/ and call that from the rules
[10:50] <seb128> caribou, +1 ;-)
[10:50] <caribou> seb128: then all good then ;) thanks
[10:50] <seb128> yw!
[11:03] <dpm> seb128, pitti, I was on the phone, let me have a look at it now (re: Evo translations)
[11:05] <seb128> dpm, hey, thanks
[11:06] <dpm> np, evolution is a bit of an annoying template, as they version the .pot file and we have to be careful we don't mess up LP's translation sharing and template names
[11:06] <seb128> right
[11:06] <seb128> we screwed in saucy
[11:07] <seb128> we didn't approve the 3.8 template, so the langpack shipped with 3.6
[11:07] <seb128> which means no translation
[11:08] <dpm> ah, let me fix saucy too, then
[11:10] <dpm> it seems someone fixed the domain and .pot import path in saucy already, let me have a look whether the 3.8 imports worked there
[11:15] <tseliot> pitti: I think I'm going to enable hybrid graphics in ubuntu-drivers-common (in 14.04) following the logic of bug #1260683 (which is really about Jockey in Precise). Any thoughts?
[11:16] <dpm> seb128, pitti, so - saucy: everything seems fixed now, we need a full language pack export and release to get Evo translations shipped; - trusty: imports for the 3.10 .pot files should work now, will need to watch the imports queue for the next hour or so if they really get imported
[11:16] <seb128> dpm, ok, thanks for fixing those!
[11:17] <pitti> tseliot: I thought we already don't offer the nvidia driver on hybrid systems in u-c-commmon? or did you change that as we can properly support hybrid now?
[11:17] <pitti> tseliot: so, what do you want to change, offer nvidia only if there is no battery, or something such?
[11:19] <dpm> seb128, np, if I'm away happyaron can probably help with templates, as he's got permissions as part of the ubuntu-translations-coordinators team. I'm happy to add anyone else to the team in LP if they want to help. They'd simply need to have read https://wiki.ubuntu.com/UbuntuTranslationsCoordinators and be familiar with LP
[11:19] <seb128> dpm, ok, great
[11:21] <tseliot> pitti: in u-d-c I plan to check if it's a laptop. The logic is already in nvidia-prime, so I think I can reuse that code
[11:24] <tseliot> pitti: so, yes, we can look for /sys/class/power_supply/ and  /proc/acpi/button/lid
[11:30] <cjwatson> pitti: multi-arch builders - isn't it glorious
[11:30] <pitti> cjwatson: *sheds a tear*
[11:30] <pitti> it's a joy to look at
[11:56] <davmor2> cjwatson: you seem overly overjoyed by this comment.  So I guess it's hugely important :)  So congratulations :)
[12:16] <xnox> pitti: seb128: i also noticed that email diffs for blueprints, do not match reality.
[12:19] <seb128> xnox, do you have any idea when that started?
[12:20] <seb128> infinity, wgrant, cjwatson: do you know if the code on launchpad that generates diff for blueprints changed?
[12:20] <cjwatson> don't know sorry
[12:21] <seb128> ok, thanks
[12:22] <xnox> seb128: no, i got first notification last night. Where a change of the workitem, arried as "- workitem" without matching "+ workitem new description" and thus I got a ping "why did you drop that workitem" on irc.
[12:23] <seb128> k
[12:28] <seb128> diwic, hey, is https://bugs.launchpad.net/bugs/1131220 still on your todolist?
[12:33] <wgrant> xnox, seb128: I came upon a potential issue in the caching of workitems a few months ago, but I didn't get to the bottom of it
[12:33] <wgrant> I didn't think it was affecting emails too
[12:33] <wgrant> Do you have some idea of when it started?
[12:34] <xnox> wgrant: the ajax behaviour is weird. click edit button; change workitem; confirm. and on display the workitem is gone (and email is sent with workitem gone), yet on page refresh it shows the updated workitem description.
[12:35] <xnox> wgrant: to be honest the cache/ajax behaviour we can live with. But, wrong diff sent in emails is sad. Can email diffs be generated from force updated cache?
[12:35] <seb128> xnox, the ajax issue is a problem because if you click edit again, you undo your previous changed
[12:36] <xnox> wgrant: well, we only started using workitems since last vUDS..... i think previous vUDS was ok. so a window of 3 months?
[12:36] <seb128> changes
[12:36] <wgrant> They're probably the same bug.
[12:36] <xnox> seb128: oh, that's bad =(
[12:36] <seb128> wgrant, pitti mentioned it today, xnox saw it recently
[12:36] <seb128> wgrant, I would say it's fairly recent, but I don't think we have too much details
[12:36]  * seb128 checks his blueprint emails
[12:36] <pitti> wgrant: I think I heard it first from gema during the QA team sprint in Boston, hang on
[12:37] <pitti> wgrant: so around september 12
[12:37] <wgrant> Right, thanks.
[12:38] <wgrant> I don't see a bug. Could someone please file one?
[12:38] <pitti> I'll do
[12:41] <pitti> seb128, xnox, wgrant: bug 1260714
[12:41] <seb128> wgrant, pitti: looking in my blueprint inbox the first "weird diff" is from 11/28, but we don't use blueprint that much recently and the ones I had in the previous weeks before that are mostly simple edit where a couple of lines were changed (and those seem less likely to hit the issue)
[12:41] <seb128> pitti, danke
[12:42] <pitti> feel free to adjust the title to something better, of course
[12:42] <diwic> seb128, yes. I was sprinting in Taipei entire last week, and been mostly on sick leave this week.
[12:43] <seb128> diwic, ok, get better!
[12:59] <wgrant> seb128, pitti, xnox: Thanks for pointing that out, fixed.
[12:59] <pitti> wgrant: nice, thanks!
[12:59] <seb128> wgrant, oh, nice that you figure it out, thanks!
[13:00] <wgrant> (the notification and display bugs were indeed the same thing)
[13:11] <dholbach> cjwatson, thanks a lot! :)
[13:39] <ricotz> GunnarHj, please test https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+sourcepub/3726442/+listing-archive-extra and make sure you restart gdm after
[13:55] <plars> pitti: did you happen to see my comments on bug #1258245 - any chance of getting that group added for syslog, or does it create too many concerns?
[13:59] <pitti> plars: seems acceptable to me
[14:25] <seb128> dpm, wgrant: do you know where is launchpad importing the translation templates from?
[14:25] <wgrant> seb128: What do you mean?
[14:25] <seb128> wgrant, https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports
[14:25] <wgrant> Ubuntu templates are imported from source packages, as alway
[14:25] <wgrant> s
[14:26] <seb128> wgrant, the recent gtk 3.10 update didn't make it there
[14:26] <seb128> the pot is in https://launchpad.net/ubuntu/trusty/+upload/6587684/+files/gtk%2B3.0_3.10.6-0ubuntu2_i386_translations.tar.gz
[14:26] <seb128> which is the translation file from the build
[14:26] <seb128> it's also in the srcdir
[14:26] <seb128> that's from https://launchpadlibrarian.net/159463876/buildlog_ubuntu-trusty-i386.gtk%2B3.0_3.10.6-0ubuntu2_UPLOADING.txt.gz
[14:34] <seb128> wgrant, any idea how to debug that?
[14:36] <wgrant> seb128: Hm, weird
[14:36] <dpm> seb128, wgrant, it might be that LP did not import the pot file because the path in the source package changed
[14:36] <seb128> dpm, I doubt it did
[14:37] <seb128> it should still be po/gtk30.pot
[14:37] <wgrant> Also it should have still appeared in the queue.
[14:37] <seb128> dpm, wgrant: https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports also doesn't list any .po which is weird
[14:37] <seb128> since the tarball I downloaded has those
[14:37] <dpm> wgrant, but it is in the queue, is it not? -> https://translations.launchpad.net/ubuntu/trusty/+source/gtk+3.0/+imports
[14:38] <seb128> dpm, no, those are from 2013-11-01
[14:38] <wgrant> dpm: There should be something from December, I thought
[14:38] <seb128> that's old gtk 3.8
[14:38] <wgrant> There was an upload two days ago
[14:38] <seb128> gtk 3.10 was this week
[14:38] <dpm> ok, I see
[14:38] <wgrant> And I see that the jobs were run
[14:39] <dpm> in any case, it's also strange that the old templates in that queue were not imported, either
[14:44] <seb128> dpm, wgrant: can I upload the template by hand or do you prefer to keep the buggy state for debugging?
[14:45] <dpm> seb128, I'll defer to wgrant to comment on that, as I wouldn't know how to debug LP, but from my side, it's fine to manually upload
[14:47] <wgrant> seb128: I think it's fine to upload manually.
[14:47] <wgrant> I can't easily debug it tonight.
[14:47] <seb128> wgrant, no hurry, do you want a bug report for it?
[14:47] <wgrant> seb128: That'd be good
[14:49] <arun__> guys, the new language has been added to the debian ; now what should I do to obtain the language in the Ubiquity ?
[14:51] <xnox> arun__: as of when new language / translations are uploaded into d-i components in Debian, and as of then those translations are merged into ubuntu d-i components and then finally ubiquity reuploaded.
[14:51] <xnox> arun__: so it's automatic, but it does depend on uploads of d-i components in debian & ubuntu
[14:51] <xnox> arun__: there are some ubiquity specific strings, those would need to be translated on launchpad. but those are not the majority of installer used strings.
[14:52] <xnox> (although usually more visible)
[14:52] <arun__> xnox: the language option must be available in the ubiquity thats all ; will that remained to ubiquity from debian ?
[14:53] <xnox> arun__: define "available" ? cd boot-splash language selection, or ubiquity greeter list of languages, or keyboard selection list of languages?
[14:54] <xnox> i don't understand this sentence "will that remained to ubiquity from debian ?" can you say it in another way?
[14:54] <seb128> dpm, wgrant: https://bugs.launchpad.net/launchpad/+bug/1260754
[14:55] <arun__> xnox: I mean that, if the language selection is available in debian installer, will that remain the same in  the ubiquity installer ??
[14:55] <dpm> thanks seb128, subscribing
[14:56] <xnox> arun__: after a delay, it will eventually.
[14:56] <arun__> xnox: oh ok thanks !!!
[14:56] <xnox> arun__: it depends when ubiquity and d-i was last rebuild.
[14:56] <arun__> xnox: ok
[15:03] <wgrant> seb128: Hum, I think I see why. I'm not sure if the manual upload will work.
[15:03] <wgrant> The whole import system is pretty much a total mess.
[15:04] <wgrant> It tries to eliminate duplicates
[15:04] <wgrant> An upload from a package will helpfully ignore any files where duplicates can't be resolved.
[15:05] <seb128> :/
[15:07] <wgrant> seb128: It probably isn't normally a problem, because there won't be dupes once import processing is enabled and the queue clears
[15:08] <seb128> wgrant, what happened there? we uploaded before the imported was on?
[15:08] <wgrant> seb128: I think the imports were only switched on a few hours ago when dpm poked things
[15:08] <wgrant> The initial vim etc. upload went through just recently
[15:08] <seb128> k
[15:09] <seb128> not sure when "duplicates can't be resolved", but in doubt it seems it should import rather than bail out?
[15:10] <wgrant> I don't know Translations well, I'm afraid
[15:10] <wgrant> But there are frequently duplicates that should be ignored/merged/something
[15:10] <wgrant> Because each arch produces a tarball
[15:10] <wgrant> And they would usually all be effectively identical.
[15:10] <seb128> right
[15:11] <seb128> do you have an idea how to force/fix the current situation then?
[15:11] <stgraber> pitti: should be reasonably straight forward to implement, so sure i can do that
[15:11] <pitti> stgraber: thanks, handed to you
[15:11] <pitti> stgraber: I think we cover all the bases now
[15:12] <wgrant> seb128: The next package or manual upload after the queue clears in a few days should work
[15:14] <seb128> wgrant, thanks
[15:15] <seb128> wgrant, btw while we are speaking about gtk, I just opened https://bugs.launchpad.net/launchpad/+bug/1260760 ... that one is annoying as well ;-)
[15:15] <seb128> but->bug
[15:15] <seb128> wgrant, basically doing any change to a gtk+3.0 bug (without using ajax) unset the source silently
[15:16] <wgrant> wat
[15:17] <seb128> wgrant, try yourself, just go to e.g https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1252112 and click "Save Changes" in the bug table
[15:17] <seb128> without doing anything
[15:17] <seb128> it's "fun" :p
[15:27] <asac> doko: the hostname upload, can you give us some confidence that it wont regress our touch image?
[15:40] <attente> hi, i'm only getting square glyphs in plymouth
[15:40] <attente> is it because of the dependency change from ttf-dejavu-core to fonts-dejavu-core?
[15:41] <seb128> attente, do you have any debug info in /var/log/plymouth-debug.log ?
[15:41] <seb128> hum
[15:42] <seb128> that log is old here
[15:42] <seb128> I've the feeling you need to turn on debug to get that :p
[15:43] <attente> yeah. i don't even have that file
[15:43] <seb128> attente, https://wiki.ubuntu.com/Plymouth#Debugging
[15:43] <seb128> seems like you need "plymouth:debug" on your grub options
[15:43] <seb128> follow the instructions there and see if the log has something useful?
[15:43] <seb128> slangasek, ^ hey, do you know if that's a known issue?
[15:44] <seb128> attente, when did that start?
[15:44] <seb128> xnox did some changes recently, wonder if we can blame him :p
[15:44] <attente> i only just noticed it now
[15:44] <xnox> hm?! =)
[15:45] <xnox> i did not change the fonts though =)
[15:45] <seb128> right
[15:45] <xnox> attente: what theme / plugin are you using?
[15:45] <xnox> (screen or photograph of the problem?)
[15:45] <seb128> xnox, you recent change reminds me I meant to file a bug, when it's checking discuss I don't get progress % indicated anymore
[15:45] <seb128> (since saucy I think)
[15:45] <seb128> attente, I guess you should reboot in debug and get log/photo and open a bug ;-)
[15:46] <attente> xnox, ok, i'll get you a screen
[15:47] <seb128> xnox, slangasek: btw, I set https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1165522 to high, it's the most reported plymouth issue on e.u.c and with a non trivial number of reports
[15:47] <seb128> could be a "nice to fix" for the lts ;-)
[15:48] <xnox> seb128: also please attach a photo / screenshot of the problem were there is no % indication of fsck.
[15:48] <seb128> xnox, I guess it's working for you?
[15:48] <seb128> I wonder if that could be a problem in the french translation
[15:48] <xnox> seb128: there is progress in *-logo and details plugins. That is server  & KMS enabled machines.
[15:48]  * seb128 checks translation
[15:49] <seb128> I've an intel machine
[15:49] <seb128> so KMS I guess
[15:49] <seb128> it was working until some point in saucy
[15:49] <xnox> seb128: there is no progress on "ubuntu-text" aka "Ubuntu 13.10/ . . . . ." splash.
[15:49] <xnox> seb128: please check if you get progress upon pressing Esc
[15:49] <seb128> I've the graphical one
[15:49] <seb128> ok
[15:49] <attente> xnox, https://www.dropbox.com/s/3tspo4u05zlr9x7/2013-12-13 10.47.14.jpg
[15:49] <attente> er
[15:51] <xnox> attente: right, do you use full disk encryption? and what locale is set as the system locale?
[15:51] <attente> https://www.dropbox.com/s/3tspo4u05zlr9x7/2013-12-13%2010.47.14.jpg
[15:51] <xnox> attente: please file a bug with that screenshot, and comments about locale / full-disk encryption.
[15:51] <attente> xnox, yes
[15:51] <seb128> the debug.log might be useful there as well
[15:52] <attente> xnox, using full disk encryption, not sure what the system locale is
[15:53] <attente> is ttf-dejavu-core installed on your systems?
[15:54] <seb128> attente, no, it's transitional
[15:54] <seb128> attente, http://paste.ubuntu.com/6567307/
[15:54] <attente>  /etc/default/locale is en_CA.UTF-8
[15:55] <attente> seb128, i don't have the metapackage, but i guess that's not necessary
[15:55] <seb128> attente, likely not
[15:56] <attente> i'll get a debug log for you
[16:14] <GunnarHj> ricotz: ping?
[16:16] <GunnarHj> ricotz: I built a-s locally earlier today with your patch. Still no success with GDM. See bug 1260604
[16:20] <ricotz> GunnarHj, please test the patch which i attached or https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+sourcepub/3727470/+listing-archive-extra
[16:21] <ricotz> GunnarHj, 0.6.35-0ubuntu6~trusty2 works despite harry33's comment
[16:21] <ricotz> GunnarHj, the pastebin contained a typo
[16:22] <GunnarHj> ricotz: ?? Actually I diff'ed them and found them to be identical.
[16:22] <ricotz> they are not identical
[16:23] <GunnarHj> ricotz: Ok, I'll try with the debs in the PPA then. Getting back to you in 30 min or so.
[16:24] <ricotz> GunnarHj, alright
[16:25] <attente> xnox, seb128, LANG="en_CA.UTF-8"
[16:25] <attente> LANGUAGE="en_CA:en"
[16:25] <attente> er,
[16:25] <attente> https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1260792
[16:26] <attente> i didn't see anything related to the font in the debug log
[16:27] <seb128> yeah, me neither
[16:40] <GunnarHj> ricotz: Success with ~trusty2! :)
[16:44] <slangasek> seb128: the remaining plymouth crashes are all things we've never been able to reproduce locally
[16:46] <seb128> slangasek, k
[19:07] <roadmr> hello, the ubuntu-sdk package seems to be uninstallable, is this a good place to ask about that or is there a better place?
[19:07] <beuno> roadmr, #sdk is probably better, although I'm not sure there will be anyone around
[19:08] <roadmr> beuno: just #sdk or #ubuntu-sdk? there's only one other person in the latter (xnox)
[19:09] <beuno> roadmr, oh, I think I made that up
[19:09] <beuno> not sure then  :)
[19:09] <xnox> roadmr: what do you mean "ubuntu-sdk" package is not uninstallable?
[19:09] <roadmr> beuno: hehe it happens :)
[19:09] <xnox> roadmr: where did you install it from, and on to which release?
[19:09] <roadmr> xnox: 12.04.3, I added this ppa: https://launchpad.net/~ubuntu-sdk-team/+archive/ppa
[19:10] <roadmr> xnox: ubuntu-sdk wants qtcreator-plugin-ubuntu-cordova which in turn wants qtcreator-plugin-ubuntu (= 2.8.1bzr56precise0) but only 2.8.1bzr57precise0 is available in that ppa
[19:10] <xnox> roadmr: well then, open a bug report against that ppa.
[19:10] <roadmr> xnox: ok, just wanted to ensure I wasn't doing things wrong. I'll file a bug then, thanks!
[19:10] <xnox> roadmr: it's best to use sdk on trusty ;-) and from the archive, not the PPAs =)
[19:11] <roadmr> xnox: I know, but we have an application that uses the sdk and we need it building and running on precise
[19:11] <xnox> roadmr: cool. ok.
[19:11] <roadmr> xnox: saucy and trusty have no problems :) it's that "legacy" need for precise that makes us suffer
[19:53] <hallyn_> Hi - if a package installs an upstart job, and that upstart job may do {stop; exit 0;}, that seems to cause package install to fail.
[19:53] <hallyn_> is there a clean way to make that 'ok'?
[19:53] <hallyn_> dh_installinit --errorhandler?  seems more work than should be needed
[19:55] <Noskcaj> Can someone please test debian's version of opemmpi on ubuntu armhf? It appears all out diff is fixed, but i need someone to test we don't need any arm support patch
[19:56] <xnox> hallyn_: if there is an example, i can look into that. it shouldn't fail.
[20:03] <hallyn_> xnox: the cgroup-lite package in precise-proposed
[20:03] <hallyn_> at least that's what i think is happening.  i may be misunderstanding...
[20:03] <hallyn_> (install that in a precise container, and apt-get install fails)
[20:07] <xnox> install cgroup-lite in the container.... which already is using cgroup-lite?!
[20:08]  * xnox will try a VM instead.
[20:14] <hallyn_> xnox: just a fresh container
[20:14] <hallyn_> shouldn't have cgroup-lite, if you just 'lxc-create -t ubuntu -n p1 -- -r precise'
[20:16] <xnox> ah ok.
[20:18] <hallyn_> (idea being 'start cgroup-lite' will fail because of the apparmor profile)
[22:25] <Noskcaj> when is the next DMB 19UTC meeting? I'm wanting to apply for MOTU and PPA (xubuntu packages), but cannot attend 15UTC and can only reliably attend 19UTC times before the end of January
[22:35] <darkxst> Accountsservice gir1.2 package is broken. it killed gnome-shell ;(
[22:35] <darkxst> ^xnox
[22:49] <darkxst> is anyone around that can sponsor this? Its pretty urgent given gnome-shell is 100% broken in trusty for the moment. Bug 1260880
[22:53] <ricotz> darkxst, fyi, https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1260604
[22:53] <Noskcaj> Is there an ETA for glew 1.9.0 in ubuntu?
[22:55] <tjaalton> darkxst: i can do that
[22:56] <darkxst> tjaalton, may as well take ricotz patch from bug 1260604
[22:58] <tjaalton> darkxst: next time finalize the changelog and add the bug# ;)
[23:01] <tjaalton> ricotz: why does the -dev package need that dep?
[23:04] <ricotz> tjaalton, it is a convention that the -dev packages pulls in the gir1.2- for a proper build environment
[23:05] <ricotz> not related to this breakage, but still needed
[23:05] <tjaalton> well i'm not adding it here
[23:05] <ricotz> still leaving it is wrong
[23:06] <tjaalton> oh it's a forked package, then I don't care
[23:07] <ricotz> how do you mean "forked"
[23:08] <tjaalton> since raring
[23:08] <ricotz> you mean not "synced from debian" then
[23:09] <tjaalton> right, and I'll add a changelog entry credited to you so you can explain it to the next one :)
[23:10] <ricotz> tjaalton, alright
[23:12] <tjaalton> uploaded
[23:13] <darkxst> tjaalton, thanks
[23:13] <tjaalton> np
[23:14] <ricotz> tjaalton, thx
[23:15] <tjaalton> Noskcaj: you probably need to ask the unity folks if 1.10 would be good for them
[23:15] <Noskcaj> tjaalton, ok, will do
[23:16] <tjaalton> since 1.9 broke the builds or such
[23:16] <tjaalton> as mentioned on the changelog
[23:17] <Noskcaj> yeah
[23:17] <Noskcaj> roaksoax, kirkland: Would you mind putting a testdrive update out? Vbox 4.3 is now in proposed. Could we use this as an excuse to put testdrive in debian?
[23:59] <Noskcaj> roaksoax, kirkland: Please add "Upload to debian. Closes: #718365" to the changelog, and release as just 3.25