[00:02] <infinity> doko: While you're uploading FTBFS compilers, you've noticed that gcc-4.8 can't migrate because you dropped a library that all the olders ones depend on, right?
[00:03] <doko> infinity, I know, I should have gone to bed
[00:03] <infinity> doko: Yeah, my late night uploads usually aren't much better. :)
[00:05] <doko> infinity, feel free to merge the older ones. I wanted to delay that until alioth is up again
[00:06] <infinity> doko: Oh, if you already have the older ones fixed in Debian or a VCS, that's cool.
[00:07] <doko> infinity, feel free to fix 4.4
[00:07] <infinity> doko: I'm in no huge rush to see it all fixed migrate, just wanted to make sure it was happening some day. :)
[00:07] <infinity> doko: I can replicate your 4.6/4.7 fix to 4.4 if you haven't, sure.
[00:07] <infinity> doko: (After I fly across an ocean and such, so... Later)
[00:08] <doko> do you work somtimes too? ;-P
[00:08] <infinity> doko: Every second Thursday.
[00:08] <infinity> (Hey, I worked all day while I was doing laundry!... And most of the long weekend I just had)
[00:08] <infinity> I suck at long weekends.
[00:10] <bdmurray> slangasek: I'm not sure we are collecting everything we need
[04:19] <pitti> stgraber: 1211514> as the changelog says, version 4 fixes half of the problem, but I just figured out the other half last night (way after uploading the SRU)
[04:20] <pitti> stgraber: but that bug is much less critical than the suspend failure, so I wanted to get this out ASAP
[04:20] <pitti> stgraber: that bug is indeed not yet fixed in trusty
[04:20] <pitti> Good morning
[06:40] <pitti> @pilot in
[06:55] <dholbach> good morning
[06:56] <pitti> hey dholbach
[06:56] <dholbach> hey pitti
[07:30] <arun_> Hello guys, I didn't get any feedbacks from the glibc maintainers, I was wanting to add a new language suppport(language package) having iso code ="the" ; please  helpme !!!
[08:16] <pitti> dholbach: happier with the sponsoring queue now? :-)
[08:16] <dholbach> pitti, a bit, yes ;-)
[08:16]  * dholbach hugs pitti
[08:18]  * pitti hugs dholback
[08:33] <arun_> Hello guys, I didn't get any feedbacks from the glibc maintainers, I was wanting to add a new language suppport(language package) having iso code ="the" ; please  helpme !!!
[08:42] <dholbach> seb128, didrocks: salut mes amis! comment ça va? could you add something to https://wiki.ubuntu.com/TimoJyrinki/DeveloperApplication-PPU when you have time? :)
[08:43] <arun_> Hello guys, I didn't get any feedbacks from the glibc maintainers, I was wanting to add a new language suppport(language package) having iso code ="the" ; please  helpme !!!
[08:45] <dholbach> arun_, maybe you bring it up on the mailing list instead?
[08:45] <dholbach> ubuntu-devel-discuss@lists.u.c
[08:45] <didrocks> dholbach: oh, with great pleasure!
[08:45] <seb128> dholbach, salut, c'était bien l'Inde ? sure, can do, adding to my list for today (in fact it was already in my tomboy todo note)
[08:45] <dholbach> arun_, instead of posting this every couple of hour/half hour
[08:46] <dholbach> didrocks, seb128: très bien, merci beaucoup
[08:46] <didrocks> Mirv: you didn't add qtcore itself and all qt plugins?
[08:46] <seb128> dholbach, nice to have you back ;-)
[08:46] <dholbach> seb128, c'était fantastique - j'au aucun idée pourquoi je suis retourné :)
[08:46] <didrocks> Mirv: I think you can add what we are upstream for (what's in cu2d)
[08:46] <seb128> dholbach, don't forget to hug Laney for doing sponsoring reminder
[08:46]  * dholbach hugs Laney
[08:47] <dholbach> that's right! :)
[08:49] <penghuan> Hello, anyone knows how the package‘s "Task" tag comes, if i want to set a package's "Task" tag, what should i do?
[08:52] <Mirv> didrocks: can you be more specific? by qtcore do you mean qtcreator? it rarely needs updating other than new upstream version since now our stuff is separated from there. the qtcreator-plugin-ubuntu includes both plugins we have.
[08:53] <didrocks> Mirv: Source: qtbase-opensource-src
[08:53] <didrocks> Mirv: I don't see it in the first sentence :)
[08:54] <didrocks> (also, we do have way more Qt components than what is listed)
[08:55] <Mirv> didrocks: which sentence, and which list. since this is a different channel too, I don't have the context :) the upstream Qt modules are not suitable for daily release as is.
[08:55] <Mirv> didrocks: the PPU page!
[08:55] <Mirv> didrocks: right, now I understand what on earth you're talking about :)
[08:56] <Mirv> didrocks: so... I thought I'd start with those special modules and QtC. I'm part of the pkg-kde team in Debian, so the official Qt modules can be easily added afterwards, while I'd certainly want to go through them with someone else for the next big 5.2 upload still.
[08:56] <didrocks> Mirv: that was just 10 lines before I pinged you ;)
[08:57] <Mirv> didrocks: yeah, there just wasn't highlight above that and I thought this was some sort of continuation from CI channel :)
[08:57] <didrocks> Mirv: I think you are suited to have all Qt modules at least (I would add daily packages, but if you want to do that later on, I'm fine)
[08:57] <Mirv> didrocks: ok
[08:57] <didrocks> Mirv: you did all the packaging and we just sponsor you, so it's a strong suggestion :)
[08:58] <didrocks> Mirv: I trust you to ask us if you have any question anyway
[08:58] <didrocks> (which are what the upload rights are really about)
[09:09] <pitti> jodh: is https://code.launchpad.net/~jamesodhunt/ubuntu/saucy/sysvinit/force-reload-configuration-for-broken-inotify/+merge/180690 still relevant? (I'd upload it to trusty instead)
[09:17]  * Mirv added the rest of the Qt modules and most of cu2d packages that provide Qt modules
[09:20] <didrocks> Mirv: great!
[09:28] <jodh> pitti: yes, it very much is. I believe slangasek is going to merge it when he gets a chance.
[09:28] <pitti> jodh: it looks fine to me, so if you want I can merge it now
[09:29] <jodh> pitti: oh - sorry, wrong branch. one sec...
[09:29] <pitti> jodh: (being patch pilot today)
[09:29] <xnox> penghuan: tasks come from seeds in ubuntu, see http://pad.lv/p/ubuntu-seeds https://wiki.ubuntu.com/SeedManagement . So it's done post-upload, on the archive side.
[09:36] <jodh> pitti: I've commented on the MP. Essentially, it's fine, but we might want to call on system actually using overlayfs.
[09:43] <Riddell> dholbach: George Merkel on ubuntu-motu list being a bit non-CoC?
[09:43] <dholbach> Riddell, I just replied to the mail
[09:44] <Riddell> I wonder what's going on in his head
[09:44] <dholbach> (but everybody else could have reminded him of the fact too :))
[09:44] <dholbach> no idea - I assume somebody who signed up for the list at some stage, forgot about it and is now surprised about the traffic happening today
[10:02] <arun>  Hello guys, excuse me !!!! I had some questions about the adding of new language having ISO Code = "the" , please help me anyone there !!!
[10:09] <pitti> jodh: is that for the live session? I. e. could we just guard that with 'grep -q '^/cow / overlayfs' /proc/mounts ?
[10:10] <pitti> jodh: (asked the same on the MP)
[10:11] <xnox> pitti: live session, persistent usb, cloud-images with overlayfs. Or any other file system that happens to not support inotify, or have non-notifying inotify support as the case is with overlayfs.
[10:11] <pitti> xnox: right, but that sounds like a rather similar check (just perhaps not with /cow)
[10:12] <pitti> but we shouldn't make it too complicated; if it takes lots of grepping, stat'ing, and guessing, we might just as well do the reload :)
[10:13] <xnox> pitti: similarly session-init is also affected, thus we maybe also should make all session init's reload configs, and that's a few paths /etc/xdg/, /etc/ubuntu-xdg/, /usr/share/upstart/session
[10:21] <pitti> jodh, xnox: proposed a more generic solution on the MP
[10:22] <pitti> I tested this on a live CD (says "overlayfs") and on my desktop (says "ext4")
[10:25] <xnox> pitti: there is no inotify over NFS, when in root over NFS configuration - is /etc mounted local, or is that remote as well?
[10:26] <pitti> xnox: as I said, I'm not trying to deal with each and every broken configuration, just with overlayfs :)
[10:26] <xnox> i'm guessing in fully disk-less configurations it's remote.
[10:26] <pitti> but then / would be remote, too
[10:27] <pitti> so it could be extended to check for overlayfs or nfs
[10:28] <jodh> xnox: re session init, maybe we should consider adding a ConfigurationReloaded signal that they can all react to. Depends how quickly the kernel team fix the overlayfs issue though :)
[10:30] <xnox> pitti: in a way I agree with you. Polluting each invoke-rc.d call with reload-configuration is expensive and needless. And the actual usability bug in question is "i've installed $daemon package, it didn't start" and most commonly that's on overlayfs (live desktop iso / cloud image).
[10:31] <pitti> @pilot out
[10:44] <asac> cyphermox: i still roam to a 40/70 AP while there is a 61/70 AP available (on trusty)
[10:45] <asac> cyphermox: you said that NM is the one deciding on such "policy"?
[10:49] <ari-tczew> hallyn_: you've added 2 changes on package syslog-ng (https://launchpad.net/ubuntu/+source/syslog-ng/3.3.1.dfsg-1ubuntu1) but there is no explanation what do these changes. are they still needed? are they Debian-related, as well?
[10:59] <asac> cyphermox: checking a bit on code there seem to be bgscan_simple and learn ... i only found that NM tweaks the simple parameters for the wpa_eap case, do you know where the "real" defaults used for wpa_psk are?
[11:05] <dholbach> Riddell, he apologised in private and I took him off the list
[11:05] <pitti> diwic: I read through bug 1197395 and the corresponding Fedora bug (I linked that now); I'd rather fix this in libpam-systemd, so that we don't have to apply the workaround in ubuntu's pulse, if that's ok with you?
[11:05] <pitti> diwic: it might still make sense to apply it upstream of course, if the pam fix gets rejected upstream
[11:06] <diwic> pitti, sure, go ahead and fix in systemd, I too think that's better
[11:06] <pitti> diwic: we'd otherwise need the same fix in dconf, dbus, and whatnot
[11:06] <pitti> upstart, gvfs too
[11:06] <Riddell> dholbach: win :)
[11:09] <diwic> pitti, I was hoping that my "blame systemd developers" patch would persuade Lennart to fix the bug upstream, but so far no response. Only been one day though.
[11:36] <seb128> ev, hey, there is something weird with e.u.c
[11:36] <ari-tczew> infinity: I was looking on the package source-highlight. (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/source-highlight/trusty/revision/21) debian has adopted similiar patch like yours. however, sequence in debian/rules is reversed. (http://paste.ubuntu.com/6410267/) anyhow package from Debian builds fine (tested only i386). is it OK and can be synced?
[11:37] <seb128> ev, https://errors.ubuntu.com/problem/eac5049914041dcb1e77bd2c6437da8fa9eca096 has a total of 116 reports in that page, but it has more reports than that on the index (e.g https://errors.ubuntu.com/?release=Ubuntu%2013.10)
[11:39] <Mirv> didrocks: could you push a button to rebuild qtcreator-plugin-ubuntu 2.8.1-0ubuntu1 on armhf? its build dep was an arch-independent package that depended on arch specific package which hadn't yet built at the time of the first try.
[11:40] <seb128> ev, e.g "https://errors.ubuntu.com/?release=Ubuntu%2013.10&from=2013-11-10&to=2013-11-13" has that report with a count=303 which is > 116 total for the detail view
[11:40] <didrocks> Mirv: done
[11:42] <Mirv> thanks
[11:46] <xnox> cjwatson: libwebp has moved to main (MIR approved), is ok to upload imagemagick with webp enabled?
[11:48] <cjwatson> xnox: Any chance of getting Debian to enable it first?  It's not something we currently disable in an Ubuntu delta, as far as I can see.
[11:48] <xnox> cjwatson: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1117481/comments/3
[11:49] <cjwatson> xnox: Right - I'd be more comfortable if it had reached the point where Debian was prepared to support it
[11:50] <cjwatson> xnox: I'm absolutely not going to overrule an "OMG this is a security nightmare" from the Debian maintainer who knows imagemagick much better than I do - persuade *them* :-0
[11:50] <cjwatson> :-)
[11:51] <arun_> Hello excuse me guys , please help me add a new language
[11:52] <xnox> cjwatson: not sure where "5" is taken from, given that public CVEs turned up only 3 in 2012 (as part of MIR). Unless it's part of imagemagick's CVEs of which there are more.....
[11:52] <xnox> right, will talk with debain maintainer
[11:55] <knocte> Cimi: ping
[11:59] <Cimi> knocte, pong
[11:59] <knocte> Cimi: hey, can you have a look at https://code.launchpad.net/~knocte/ubuntu-themes/fix-Radiance-CSS-precedence-of-state-pseudoclasses/+merge/194678 when you have time?
[12:00] <Cimi> I approved, looks the same
[12:01] <knocte> Cimi: cool thanks!
[12:03] <xnox> knocte: omg! i wonder if that's the root cause behind "continue button is insensitive" if any class is applied to GtkEventBox by the application.
[12:03] <xnox> (thus preventing the user to finish the installation)
[12:04] <knocte> xnox: we're talking about CSS here, it shouldn't change behaviour in any way
[12:05] <knocte> CSS==appearance
[12:05] <xnox> knocte: hm. the button did go from (default, sensitive, active) -> (insensitive). Sure but GTK does hook in functionality to css classes. The button was loosing sensitive css class, and ability to be clickable as well upon CSS change.
[12:06] <xnox> (all of us were mind boggled by it)
[12:06] <knocte> a CSS change cannot cause an element lose its classs, if anything, it can change some atributes that are applied to that class in a rule
[12:06] <xnox> i think ubuntu-themes are missing a few other bug-fixes that were applied in Adwaita (ordering, properties, etc)
[12:07] <seb128> right, styling for some of the new widgets also
[12:07] <seb128> e.g the nautilus cog menu
[12:07] <knocte> probably, I already applied one of the fixes that gtk3 upstream is including
[12:08] <pitti> diwic: http://paste.ubuntu.com/6410377/ does the trick for me
[12:09] <xnox> seb128: knocte: so the GtkEventBox.fancy style and "style.add_class('fancy') had to be reverted in http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/6033 because otherwise it was causing https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1240532
[12:09] <xnox> is there anything wrong that you can see with fancy class?
[12:10] <pitti> diwic: doing final build/test now, and then I'll send that to the RH bug
[12:10] <xnox> (it's done in application, so it would be after the theme is loaded)
[12:10] <diwic> pitti, thanks. Feel free to add a pointer to my patch as well if you like (I don't think I have an account on fedora's bug tracker)
[12:10] <ogra_> ScottK, i just saw your comment about qreal/double on the blueprint, that seems to have been decided upstream already (there is a discussion on the debian-arm ML about this http://lists.debian.org/debian-arm/2013/11/msg00015.html)
[12:10] <pitti> diwic: already done in my reply from an hour ago
[12:10] <knocte> xnox: does this involve any pseudo-class (states)?
[12:11] <pitti> diwic: https://bugzilla.redhat.com/show_bug.cgi?id=753882#c57
[12:11] <seb128> we should probably fix bugs like https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1186633 for the LTS
[12:11] <seb128> (if somebody feels like doing some theme hacking/refresh)
[12:12] <pitti> seb128: oh, that reminds me..
[12:13] <pitti> seb128: we got gnome-icon-theme-symbolic 3.10 autosynced into proposed, but we still have gnome-icon-theme 3.8 in trusty
[12:13] <pitti> seb128: this causes both packages to be uninstallable and e. g. breaks the deja-dup test
[12:13] <pitti> seb128: do we want to merge g-i-t 3.10 as well, or stay at 3.8 and remove the 3.10 -symbolic sync?
[12:14] <seb128> pitti, I've not looked at what change in g-i-t, updating to 3.10 seems fine in principle ... let me have a look
[12:14] <knocte> xnox: by looking at it I don't think it's related, take in account that the Ambiance fix ( http://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-themes/trunk/revision/311 ) is only changing affecting elements that have insensitive, selected, focused or backdrop state
[12:14] <pitti> seb128: AFAIR we wanted to by and large stay at 3.8 for trusty, didn't we?
[12:15] <knocte> xnox: but the best way to know is if you test without that change
[12:15] <seb128> pitti, yes, but icons should be on the safe side...
[12:15] <pitti> seb128: certainly safe, yes; and we have our ubuntu icon themes anyway, so probably mostly relevant for ubuntu gnome
[12:15] <pitti> and they certainly want 3.10
[12:16] <seb128> pitti, 3.8 -> 3.10 is 4 commits
[12:17] <seb128> 2 being a commit and revert
[12:17] <pitti> hah
[12:17] <seb128> pitti, there is actually 1 commit between those
[12:17] <pitti> c'est facile
[12:17] <seb128> oui
[12:17] <seb128> pitti, do you want to do the update?
[12:18] <xnox> knocte: right, so we did button.set_sensitive(false) -> add_class(fancy) to gtk_eventbox elsewhere on the gtkwindow -> button.set_sensitive(true) no longer worked, well it no longer made button sensitive nor made it accept any click / actions / signals
[12:18] <xnox> knocte: with knowledge of subclasses and unbroken glade, let me experiment =)
[12:19] <pitti> seb128: can't do right now (only shoestring/yoghurt can internet in the train), but later
[12:19] <seb128> pitti, ok, thanks
[12:27] <ogra_> pitti, i just heard you have a blueprint planned about TRIM support, will you include MMC TRIM too (for arm) ?
[12:28] <ogra_> (got an url for me to subscribe ?)
[12:28] <pitti> ogra_: is that any different than just calling fstrim on their mounts?
[12:28] <pitti> ogra_: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming
[12:28] <ogra_> pitti, well, you want the discard option in fstab
[12:28] <pitti> ogra_: if it's any different, can you please make a note in the whiteboard?
[12:28] <ogra_> (does fstrim set that)
[12:28] <pitti> ogra_: I don't think we actually want that by default
[12:29] <pitti> ogra_: I personally lean towards calling fstrim from cron instead of adding synchronous delays
[12:29] <pitti> but deciding between discard and cron'ed fstrim is the main meat of that discussion
[12:29] <ogra_> well, if it adds the same IO speedup as the fstab option i dont mind
[12:30] <pitti> ogra_: but it sounds like you actually talk about the exact same thing; so yes, it'll be fixed one way or the other
[12:30] <ogra_> good
[12:30] <ogra_> yeah, there shouldnt be much difference in functionality, but the device naming will be mmc specific
[12:30] <ogra_> (/dev/mmcblkXpY and such)
[12:31] <pitti> ogra_: it doesn't care about device name; you run fstrim on mount points
[12:31] <xnox> pitti: i'm also for cron option. Or anacron.
[12:31] <pitti> ogra_: device names come into play if we want to set the discard option by default, though (but then we shouldn't look at device names but their properties, like "SSD?"/"can trim"?
[12:32] <pitti> xnox: I just stuffed into cron.weekly; that should be anacron
[12:32] <ogra_> pitti, xnox ... well, the question is, do we want to run cron by default on phones (and preiodically wake them up)
[12:33] <pitti> ogra_: well, one less often deletes many files on the phone
[12:33] <pitti> so perhaps we want discard on phone and cron on desktop/server
[12:33] <ogra_> right, i added a topic to the whiteboard
[12:33] <ogra_> (and subscribed)
[12:34] <pitti> ogra_: heh, "performance boost" is a nice understatement
[12:34] <pitti> at least on an SSD, not doing any trimming is outright broken
[12:35] <pitti> after a few months my SSD went from 250 to 5 (!) MB/s write speed
[12:35] <ogra_> MMCs usually work fine without but get a lot faster if the MMC supports it and you turn it on
[12:36] <pitti> ogra_: do you have such a device at hand by chance?
[12:36] <pitti> ogra_: can you confirm that "sudo hdparm -I /dev/mmcWHATEVER |grep -i trim" gives you something?
[12:36] <ogra_> the ac100 has such MMCs
[12:36]  * ogra_ hasnt booted any ac100 in a year or two though ... 
[12:37] <ogra_> i'll make sure i have one working for next week
[12:37] <pitti> ogra_: ah, so it's not for Panda/mako/maguro/etc?
[12:37] <ogra_> pitti, i havent checked on the phones yet
[12:37] <pitti> ogra_: ok, thanks
[12:38] <ogra_> and panda uses SD cards ... that would have to be checked individually for each SD
[12:38] <pitti> my cron job just calls fstrim /mount/point, that'll just fail on devices which don't support it
[12:38] <ogra_> well, we should only enable it on devices where we know it works
[12:38] <pitti> calling lots of hdparm/sysfs poking isn't any faster really
[12:38] <ogra_> to not waste cycles
[12:39] <pitti> but we need these checks if we want to set the discard option on devices
[12:39] <ogra_> (on the phne thats easy to know in advance and just flick a switch)
[12:39] <ogra_> (based on the device)
[12:39] <pitti> sure
[12:45] <Cimi> knocte, I noticed that we're missing menu separators, when this started happening?
[12:46] <knocte> Cimi: in what theme?
[12:46] <Cimi> ambiance
[12:46] <Cimi> I don't have them
[12:46] <knocte> I have them, and I have my patch applied, so I don't think my patches are related
[12:47] <Cimi> knocte, I have trusty though
[12:48] <knocte> ok, my only change that could have affected Ambiance in trusty is the removal of empty rules, which I consider very unlikely to be the culprit
[12:49] <rbasak> ogra_: on a phone, how about doing stuff when (say) the phone is charging and hits 100%? Then there shouldn't be a power issue. I imagine there's other maintenance stuff that might be useful here, too. So no cron, then, but you do get reasonably regular maintenance
[12:49] <knocte> Cimi: I have only requested "safe" patches for now, I was going to start with the risky ones now but I guess I'll wait a bit :)
[12:50] <rbasak> I'm sure I read somewhere that dealing with trim works out better if you do it periodically from userspace rather than with discard
[12:51] <rbasak> http://opensuse.14.x6.nabble.com/SSD-detection-when-creating-first-time-fstab-td3313048.html and http://en.opensuse.org/SDB:SSD_discard_%28trim%29_support may be useful to read.
[12:52] <ScottK> ogra_: Upstream has a view, but we have an option about whether or not to follow the switch or how to do it.  I'm aware of the Debian discussion.  They are interested in what Ubuntu decides to do.
[12:53] <ogra_> rbasak, well, lets discuss it at the vUDS session i'd say ;)
[12:53] <ogra_> rbasak, but indeed triggering something on 100% battery would be possible
[12:54] <rbasak> ogra_: just a suggestion and fuel for discussion. It's not my area.
[13:20] <Cimi> this is the broken commit http://bazaar.launchpad.net/~ubuntu-art-pkg/ubuntu-themes/trunk/revision/315
[13:22] <knocte> xnox: that is you? ^
[13:26] <xnox> Cimi: knocte: yeap, also regression spotted on the bug report https://bugs.launchpad.net/ubuntu-themes/+bug/1181661
[13:26] <xnox> comment 7-8
[13:26] <pitti> rbasak: "discard" will always keep your drive fast/clean, but it slows down file deletion quite a bit
[13:26] <Cimi> xnox, there's also another bug
[13:27] <Cimi> xnox, it removes separators
[13:27] <Cimi> from the menu
[13:28] <xnox> right, the bogus *v* got later reverted.
[13:28] <xnox> Cimi: horizontal separators that is?
[13:29] <pitti> what's wrong with horizontal menu separators?
[13:29] <pitti> (I have them in saucy/trusty)
[13:29] <Cimi> xnox, yes
[13:29] <Cimi> pitti, ambiance
[13:30] <pitti> oh, that's the wrong^Wdark theme, right?
[13:30] <Cimi> yes
[13:30] <Cimi> if it's possible, I'd like to be asked to review all branches we get
[13:30] <Cimi> I know it's my fault I let this one, and many others, pass...
[13:31] <Cimi> I worked on unity8 and thought nothing was touched on light-themes
[13:31] <xnox> Cimi: right, so stuff from #1181661 should be reverted as it "blackens" _all_ menuitem separators, not just the vertical ones in inline toolbars.
[13:31] <knocte> pitti: ambiance is the default theme
[13:31] <xnox> Cimi: i'll make a merge proposal and ask you to review.
[13:31] <Cimi> xnox, thanks
[13:32] <Cimi> xnox, the bug should be fixed differently
[13:32] <Cimi> xnox, adding a css rule for menuitems in toolbars
[13:32] <xnox> Cimi: light-themes still have bugs and still need maintenance though to matches changes in gtk+ et.al. =/ e.g.
[13:32] <Cimi> xnox, which is bad
[13:32] <xnox> Cimi: yeap, i'm got that now.
[13:32] <Cimi> xnox, because gtk should not break
[13:33] <Cimi> but apparently gtk doesn't care of that
[13:33] <xnox> Cimi: gtk is also "fixing bugs" =/
[13:33] <xnox> i know. that's why i can't wait to ditch gtk =)
[13:33] <Cimi> every new gtk release something related to theming changes
[13:33] <Cimi> it's ridiculous
[13:34] <xnox> also https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1053986 has been "fixed" by patching Adwaita to generate buttons the right way around. And i don't think i've managed to distill those Adwaita patches back for lighting-themes.
[13:34] <seb128> speaking of annoying bug
[13:35] <seb128> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1018718
[13:35] <seb128> Cimi, ^ could you look at that one, one of the recent comment explain the issue
[13:35] <seb128> with our theme the columns change size on focus in/out
[13:36] <seb128> easy to reproduce, go to e.g /etc with nautilus in list view mode
[13:36] <seb128> and focus/unfocus nautilus
[13:36] <seb128> the name column jump around while doing that
[13:37] <rbasak> pitti: right, and AIUI if you do it less often, there shouldn't be any perf degradation unless you actually run out of free blocks, which is unlikely in a week of churn on a normal system.
[13:37] <pitti> rbasak: exactly
[13:38] <pitti> rbasak: and then it's running async in the bg instead of blocking your UI
[13:38] <pitti> rbasak: so we mainly need to define sensible conditions when to run it
[13:39] <rbasak> pitti: going from the SuSE pages, I'd go with 1) when power conditions are good (eg. 100% battery and on charge) and 2) if it hasn't been run in a week
[13:41] <pitti> rbasak: mind to add that to the whiteboard of https://blueprints.launchpad.net/ubuntu/+spec/core-1311-ssd-trimming ?
[13:41] <pitti> it's good to collect this kind of links and experiences
[13:48] <rbasak> pitti: done
[13:59] <pitti> rbasak: cheers
[14:25] <hallyn_> arti-tczew is gone, but in case he checks the online logs, the changes are still needed in precise since the libsystemd-daemon-dev pkg does not exist there.
[14:25] <hallyn_> oh, hm
[14:25] <hallyn_> i mis-spelled :)
[14:26] <hallyn_> ari-tczew: syslog-ng change is needed in precise and quantal.  in raring, libsystemd-daemon-dev is present so the changes can be undone.
[14:55] <ari-tczew> hallyn_: ok, so I'm going to sync it in trusty. thank you very much for help!
[14:56] <hallyn_> ari-tczew: awesome, thanks
[15:11] <gQuigs> hi there, can I get this meeting scheduled?  http://summit.ubuntu.com/uds-1311/meeting/22016/limiting-surveillance/
[15:14] <dholbach> cjwatson, xnox: thanks a bunch!
[16:44] <ev> seb128: sometimes the counters over/under count for the front page. The canonical count should be the number of reports you see on the problem page itself.
[16:44] <arun_> guys, is the glibc responsible for the language option ??
[16:45] <ev> (counters in Cassandra are not idempotent)
[16:45] <seb128> ev, what does it mean if the report is way off the frontpage index?
[16:45] <ev> Moving to Acunu Analytics for the front page counts will fix this
[16:45] <seb128> ev, does it mean we can't trust the bucket/trend since it's loosing/not collecting most of the issues?
[16:45] <ev> this happens rarely, I don't think it means we cannot trust the data
[16:45] <ev> it's also something we can repair
[16:46] <seb128> well, it makes difficult to trust the datas
[16:46] <ev> since we just need to count the number of columns in the Bucket Column Family (each column is an instance of the problem)
[16:46] <seb128> since I don't know if we drop is because we fixed the bug
[16:46] <seb128> or because we are failing to collect the reports under the bucket
[16:47] <ev> seb128: the bucket page itself should give you the confidence that you fixed the bug
[16:47] <seb128> well, the number goes down there
[16:47] <ev> because it's not appearing in high numbers on the newly released version
[16:47] <seb128> but the summary page disagrees with that
[16:47] <seb128> so what is creating the delta?
[16:47] <ev> ^ bdmurray would you mind looking into this on your next Errors day?
[16:48] <seb128> ev, bdmurray: thanks
[16:49] <bdmurray> ev: looking into the bucket count being different on the index page compared to the bucket page?
[16:52] <ev> bdmurray: yeah, ensuring that seb128 has something he can look at as the canonical source for knowing whether a problem still exists in new versions
[16:53] <ev> and then why we're seeing discrepancies in the counters in the example he raises - though this one might be best fixed by bringing up Acunu Analytics if it's a problem with the counters themselves
[16:53] <ev> I suspect it'll be easier now that we have the read-only access :)
[16:54] <ev> you can just dig at the problemid in the database
[16:54] <ev> and see what the real count should be
[16:55] <bdmurray> seb128: do you have an example?
[16:57] <ev> bdmurray:  there's one in the asana task I just created
[17:01] <pitti> brainwash: hey, how are you? would you have some time to test systemd-shim 4 in my PPA? in theory that should work better than the fixed 10 min timeout
[17:02] <pitti> brainwash: I'm now also able to reproduce that bug, with the instructions I put into the bug
[17:02] <arun_> guys, is the glibc responsible for the language option ??
[17:05] <seb128> bdmurray, http://irclogs.ubuntu.com/2013/11/13/%23ubuntu-devel.html#t11:36
[17:12] <brainwash> pitti: sure, I can test the new package, but it will take some time until I'm able to report back. my system goes into sleep mode much faster at the momment, because I changed my gpu setup
[17:12] <pitti> brainwash: ah, "it doesn't regress" is also worthwhile; but suspend/resume is also way below 1 s for me, I can only reproduce it with the 00break pm-utils script
[17:15] <brainwash> pitti: did you test with an artificial delay of 30 or more seconds?
[17:16] <pitti> brainwash: no, so far just with 15
[17:16] <pitti> 30 seconds to suspend? wow, that sounds really broken
[17:17] <brainwash> pitti: in this case the dbus connection did timeout, but the prepareforsleep flag got reset
[17:18] <brainwash> hibernation probably
[17:19] <pitti> brainwash: ah, that would be a different spot in the code, though
[17:19] <pitti> but that would explain why some people still see this happening
[17:21] <brainwash> pitti: I guess we need to wait for the new test results
[17:22] <brainwash> oh wait, the latest comment does not look promising =S
[17:22] <pitti> brainwash: well, neither did the first one after the first version :)
[17:22] <pitti> so here's hope
[17:23] <brainwash> :)
[17:54] <seb128> shrug
[17:55] <seb128> jodh, slangasek, xnox, stgraber: hey upstart friends ... "sudo restart networking" seems to take the system dbus bus down, is that a known issue? how would you go about debugging that? (as you can image it makes things really unhappy, including upstart)
[17:56] <seb128> jcastro, ^ (that's looking at the email you sent me)
[17:56] <stgraber> seb128: not really a known issue, it's a known consequence
[17:56] <cjwatson> I thought "restart networking" was a "you get to keep both pieces" kind of thing
[17:56] <xnox> seb128: is "sudo restart networking" at all supported?
[17:56] <cjwatson> Why is anything doing that?
[17:57] <stgraber> seb128: dbus is stop on deconfiguring-networking which is emitted by networking when going down, so that's indeed to be expected
[17:57] <stgraber> seb128: you probably want: ifdown -a --exclude=lo && ifup -a --exclude=lo
[17:58] <stgraber> though even that one isn't necessarily a good idea on systems that require event based network bring up (systems with complex bridges, bonds, ...)
[17:58] <ogra_> couldnt we split networking and loopback-networking ?
[17:58] <ogra_> in two separate jobs
[17:59] <xnox> ogra_: we already do. networking is a dummy job, and you have network-interface* job instance per interface.
[17:59] <xnox> ogra_: look at $ sudo initctl list
[17:59] <seb128> stgraber, xnox, cjwatson: I don't know why people to restart networking, but they do
[17:59] <seb128> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/1072518
[17:59] <seb128> jcastro, ^ do you know why user do network restart?
[18:00] <ogra_> xnox, then dbus should probably depends on the loopback one
[18:00] <ogra_> *depend
[18:00] <seb128> why do we ever need to stop dbus?
[18:00] <stgraber> ogra_: we could but that still wouldn't solve the other half of the problem (virtual interfaces ordering), so we'd just trade one bug for another. I think the real problem here is people recommending to use restart networking at all
[18:00] <seb128> that should go away on shutdown with the system
[18:00] <xnox> seb128: at shutdown for example =)
[18:00] <seb128> do we need to stop it cleanly?
[18:00] <seb128> rather than just going down?
[18:01] <stgraber> seb128: apparently this was made so dbus would be stopped before the loopback interface actually goes away. I'm not sure there was a reason to do that though (like dbus crashing if the loopback interface disappears under its feet)
[18:02] <arun_> guys, is the glibc responsible for the language option ??
[18:02] <stgraber> if we had such a thing as a restart statement in upstart, I think it'd be reasonable to skip emitting that signal and have ifup/ifdown run with --exclude=lo, but since we don't, I think our best option is to make sure people don't do things we don't support
[18:02] <seb128> stgraber, in any case it's not a g-s-d issue, where do you suggest reassigning?
[18:03] <stgraber> seb128: to whatever documentation told the user to do that. Or mark it invalid as an unsupported user action.
[18:03] <seb128> stgraber, well, why do we provide a "networking restart" if that's not supported? can't we just make that display a big warning with a type "yes I'm sure"?
[18:03] <stgraber> seb128: because it's not possible not to provide it
[18:03] <cjwatson> Right, we don't deliberately provide it, it's an emergent consequence
[18:03] <stgraber> seb128: "restart networking" is just a standard upstart command
[18:04] <seb128> well, can we make the "networking" job to not do what it's asked
[18:04] <seb128> or ask for confirmation?
[18:04] <stgraber> upstart jobs can't interact with the console
[18:05] <cjwatson> The only way to do that would be to break "stop networking", which would break shutdown
[18:05] <stgraber> right
[18:05] <seb128> http://askubuntu.com/questions/98201/whats-the-right-way-to-restart-services-in-11-10
[18:05] <seb128> can we fix the web to stop suggesting stupid commands to users? ;-)
[18:05] <stgraber> we sure can try ;)
[18:05] <cjwatson> restart is just stop then start as far as the job is concerned
[18:05] <xnox> stgraber: cjwatson: well, we can do a pre-stop script, that will check upstart events. If there is none, it means user invoked it directly. And we can bail out. And we can check goal, if goal is to restart, we can again do nothing.
[18:06] <xnox> or indeed execute ifdown / ifup sequences.
[18:06] <cjwatson> that's true, although there's no such thing as a restart goal
[18:06] <cjwatson> the goal is set to stop and then to start
[18:06] <stgraber> and I'd rather not break "stop networking" since it's at least used in testing (by people who know what's going to happen when they do so)
[18:07] <seb128> stgraber, how is that ever useful for testing?
[18:08] <seb128> I don't want to screw my system, but I tried a bit earlier it took dbus's system bus down
[18:08] <gQuigs> we specifically need a way to restart networking for enterprises, it's part of how to set up bonded interfaces in the server guide
[18:08] <seb128> which made upstart enable to work properly
[18:08] <gQuigs> it
[18:08] <cjwatson> upstart uses a private connection, surely
[18:09] <seb128> e.g I couldn't even use "status"
[18:09] <slangasek> seb128: argh don't manually stop networking (i.e., what everyone else said)
[18:09] <stgraber> seb128: it's useful when I test a new ifupdown as my test systems are simple containers that don't have anything to bring up/down when networking restarts
[18:09] <stgraber> seb128: that lets me make sure all the network-interface instances get properly created/destroy and that all the events are emitted as expected
[18:10] <slangasek> seb128: you should have been able to run 'status' still as root
[18:10] <gQuigs> it's currently completely broken in 12.04;  there is a private escalation for it
[18:10] <stgraber> if the server guide recommends restarting networking, then it's wrong and needs to be fixed
[18:10] <cjwatson> status> won't work as a user if dbus is stopped, but should still work as root or with --system
[18:11] <cjwatson> er, I may not mean --system
[18:11] <stgraber> right, upstart as root always uses the private socket and doesn't depend on dbus at all
[18:11] <seb128> cjwatson, I might have forgotten the sudo
[18:11] <slangasek> cjwatson: AFAIK not with system because upstart only accepts connections from root on the private bus
[18:11] <stgraber> seb128: I posted a comment on that askubuntu question, maybe jcastro can make sure it's more visible and that the current "good" answer is marked as being wrong somehow.
[18:11] <cjwatson> yeah, that was a brainfart
[18:11] <slangasek> gQuigs: can you give us a specific reference into the server guide?  the server guide should be fixed
[18:11] <seb128> cjwatson, thanks ;-)
[18:11] <cjwatson> but it should be fine with sudo, anyway
[18:11] <seb128> google return lot of "/etc/init.d/networking restart" from the old times
[18:12] <slangasek> right
[18:12] <slangasek> we can file off some of the sharp points here, but fundamentally, "networking restart" was /never/ the correct interface
[18:12] <seb128> right
[18:12] <gQuigs> slangasek: I detail it here: https://bugs.launchpad.net/ubuntu-advantage/+bug/1210277  we through users for a loop and don't actually have a way that works...
[18:12] <seb128> it's just that it bites users really since it takes the desktop fully down
[18:13] <jcastro> seb128, I don't know why people do it, they apparently do it enough to bother people
[18:13] <jcastro> stgraber, can you link me to the AU question with the wrong info? we can fix that.
[18:13] <stgraber> jcastro: http://askubuntu.com/questions/98201/whats-the-right-way-to-restart-services-in-11-10
[18:13] <gQuigs> slangasek: https://help.ubuntu.com/12.04/serverguide/network-configuration.html and in https://help.ubuntu.com/13.10/serverguide/network-configuration.html
[18:14] <stgraber> hmm, that last one should just be "ifup br0"...
[18:15] <cjwatson> yeah, trying to restart the entire networking stack seems like an unnecessarily gigantic hammer there
[18:15] <slangasek> right
[18:15] <jcastro> stgraber, ok so that's a duplicate, I can have the answer removed
[18:15] <jcastro> but we need the proper way someplace on: http://askubuntu.com/questions/19320/what-is-the-recommended-way-to-enable-disable-services
[18:15] <ogra_> but its a very common answer in debian and ubuntu forums
[18:16] <ogra_> as wrong as it is, it is very wide spread
[18:16] <jcastro> I think the issue is people don't expect their desktop to stop working when you restart networking
[18:16] <stgraber> jcastro: look at my comment on the link I gave you, that should cover what people should be doing
[18:16] <slangasek> enable/disable services> that seems unrelated to restarting the networking stack
[18:16] <xnox> arges: ^^^^^^^ (Re: networking, one shouldn't do "restart networking", instead one should ifdown/ifup individual interfaces as needed)
[18:16] <stgraber> well, also, "restart networking" won't actually restart anything on a desktop, it'll just break your machine :)
[18:17] <stgraber> "restart network-manager" would be vaguely more correct :)
[18:17] <ogra_> vaguely
[18:17] <xnox> stokachu: ^^^^^^
[18:18] <jcastro> http://askubuntu.com/questions/230698/how-to-restart-the-networking-service
[18:18] <jcastro> here we go
[18:20] <jcastro> ok so I added a link from the main "services" question, and I've flagged all the incorrect answers
[18:20] <jcastro> so they will be removed shortly
[18:20] <gQuigs> in any case; we do have enterprise customers that want to restart all of networking to updating multiple bonded configurations at once
[18:21] <gQuigs> they can also use out of band management, so it does actually make sense to restart networking and not the entire machine
[18:21] <jcastro> also there's plenty of old people like me who just grew up with "/etc/init.d/networking restart" as the hammer for everything network related
[18:23] <seb128> yeah, same here, I used to use that before the n-m times
[18:24] <gQuigs> chaining ifupdowns for 8 physical interfaces and several bonded interfaces is not usable
[18:25] <xnox> stgraber: stop --all-instances job (or just stop --all job)
[18:25] <xnox> (which doesn't exist at the moment)
[18:26] <stgraber> xnox: sure but I usually want to make sure that they all stop on the expected events, remember, I'm testing ifupdown, not upstart ;)
[18:26] <arges> xnox: yup that was my understanding. I think the only thing is we should probably fix the 'stop: Unknown instance' not defined in precise.
[18:27] <arges> anyway half at lunch need to read the backlog...
[18:27] <xnox> arges: that can be done. But i'm not sure if we have any ways to notify user though.
[18:28] <xnox> arges: start with seb128 at 5 minutes to.
[18:28] <stgraber> slangasek: I sent a MP to the serverguide, replacing the two instances of restart networking by the proper ifup/ifdown command
[18:29] <slangasek> stgraber: cheers
[18:30] <stgraber> gQuigs: in such case, you probably want: "ifdown --exclude=lo --exclude=... -a && ifup -a" where you list all interfaces that aren't affected (such as monitoring interfaces, ...) as excludes, then you bring the rest down and everything back up
[18:30] <stgraber> though note that bonds specifically rely on the event based bring up, so this will only work if you /etc/network/interfaces has been written in the right order, if you didn't, it'll deadlock
[18:31] <stgraber> (ifupdown itself is sequential, that's why we try never to use the -a option as it'll just hang if any dependency isn't there)
[18:31] <gQuigs> stgraber: so how do I bring a bond up?? or reconfigure it?
[18:32] <stgraber> ifdown bond0 && ifup bond0
[18:32] <arges> stgraber: on a side note: bug 1065077 affects p/q and I'll be SRUing that. using ifup/ifdown on bonded interfaces take 1.5m before that patch and 5s after
[18:32] <arges> which causes some reboots to have the 'waiting for network configuration' upon boot
[18:32] <stgraber> arges: yeah, I saw that, thanks
[18:34] <jcastro> stgraber, seb128: ok I've corrected nearly all the mentions of restarting networking on AU, here's the only one I am unsure about: http://askubuntu.com/questions/347687/how-can-i-enable-and-keep-wifi-without-restart-networking-service-in-ubuntu-serv
[18:35] <jcastro> `ifdown --exclude=lo -a && ifup --exclude=lo -a` <-- nobody is ever going to remember that btw
[18:36] <slangasek> honestly, it can probably just be 'ifdown -a && ifup -a'
[18:36] <slangasek> stgraber: is there a specific reason to worry about lo?
[18:37] <arges> is there a risk of loopback is brought up/down
[18:37] <gQuigs> how is that better than just making that be what restart does?
[18:37] <stgraber> I think newer ifupdown won't ever touch lo even if you tell it to (it even no longer needs to be in /e/n/i) but on older version, -a may bring lo down
[18:38] <stgraber> gQuigs: because as we said above, there's no such thing as "restart" in upstart, we can't make restart do something different than stop+start
[18:38] <slangasek> jcastro: the problem statement on http://askubuntu.com/questions/347687/how-can-i-enable-and-keep-wifi-without-restart-networking-service-in-ubuntu-serv implies he has some serious misconfiguration going on, I wouldn't hazard an answer without a clearer problem description
[18:38] <stgraber> slangasek: the recommendation for that --exclude is that at least dbus seems to be specifically designed to shutdown before lo goes away, so I suspect it does something bad if lo just vanishes
[18:39] <arges> stgraber: what usecase is there for doing 'service networking restart' ?
[18:39] <stgraber> arges: none
[18:39] <arges> or is there none ?
[18:40] <arges> ok
[18:40] <slangasek> stgraber: no, dbus is 'stop on deconfiguring-networking' because that's the /latest/ we can shut dbus down
[18:40] <slangasek> not because taking out lo will break it
[18:40] <slangasek> anyway, /etc/init/networking.conf doesn't take down lo at all, not sure why that is
[18:41] <gQuigs> stgraber: umm.. so?  I'm happy with restart = stop + start... in fact isn't that the definition?
[18:41] <jcastro> stgraber, ok, so I searched the site for networking restarting and all the answers now point to that question, so we should be set pending some flags getting actioned by the community
[18:41] <seb128> slangasek, why do we need to stop dbus?
[18:41] <mdeslaur> tjaalton: what's mod_revocator, and is the ubuntu change to nss still necessary?
[18:42] <slangasek> seb128: because that's the trigger for other services like network-manager being stopped
[18:42] <stgraber> slangasek: ok, then ifdown -a && ifup -a may be safe. I guess the other reason is to keep "something" around so that we don't get weird behavior from software binding to :: suddenly noticing that there's really nothing to bind at all
[18:43] <seb128> hum, k
[18:43] <slangasek> stgraber: well, but so what? :)  things trying to bind while you're in the process of making administrative network changes are undefined
[18:44] <slangasek> seb128: if you think we should keep dbus running and stop the individual services instead, it's possible we could do that, but someone would need to double-check that dbus wouldn't hold any files open under /usr or /var
[18:44] <stgraber> slangasek: anyway, the way ifup/ifdown work nowadays, -a is indeed "safe" for both as lo is now special cased in ifupdown, so I guess telling people to do ifdown -a && ifup -a is fine
[18:44] <slangasek> (so that we can cleanly unmount)
[18:45] <stgraber> (with the usual warning about event based bring up and the fact that if their /e/n/i isn't properly ordered, it'll just hang there)
[18:45] <slangasek> stgraber: I don't believe there was ever a reason that it was unsafe even when it did handle lo
[18:45] <slangasek> if you think there is one, let's figure out, concretely, what it is :)
[18:45] <seb128> slangasek, I've no strong opinion, dbus is a core component and it feels like that's not something we would need to take down "that easily"
[18:46] <arun_> adam_g: are u the maintainer of glibc for Ubuntu?
[18:46] <slangasek> seb128: it's not "easily", it's only supposed to be stopped at shutdown, because *networking* is only supposed to be stopped at shutdown
[18:47] <sarnold> arges: I've done 'sudo restart networking' before when network-mangler was Very Unhappy and I wanted a quick way to kill it and force my network configuration to happen completely fresh. I got that chance when I had to reboot. :/ I was very unhappy.
[18:47] <seb128> slangasek, well, reality is that user memory/internet/old habits makes that command to be run more that it should ... and it's hard to fix the internet/old habits
[18:47] <arges> stgraber: so the upstart networking script is just used/useful during boot and shutdown then?
[18:47] <slangasek> seb128: and if we need to make it possible to keep dbus alive in spite of misuse of /etc/init/networking.conf, we can do that; let's not conflate that with the shutdown problem
[18:47] <seb128> slangasek, you are right
[18:47] <ogra_> dont we have something like "stop on stopping filesystem" ?
[18:47] <ogra_> that dbus could use instead
[18:47] <slangasek> no
[18:48] <slangasek> nor should there be one
[18:48] <stgraber> slangasek: well, I just tried on my laptop for fun, no service appear to have crashed, however for whatever reason wpa_supplicant or NM became deeply unhappy and I lost my wifi connection. Had to re-initialize it entirely after lo came back up.
[18:48] <slangasek> stgraber: interesting
[18:48] <ogra_> slangasek, well, it swwms likw a workaround to make dbus depend on networking while we need it stopped for unmounting
[18:48] <ogra_> *seems
[18:49] <stgraber> ogra_: I think the reason was because of network filesystems on desktop machines
[18:49] <ogra_> ah
[18:49] <stgraber> ogra_: basically for those you need NM to be running, for NM to run, you need dbus
[18:50] <slangasek> it's 'stop on deconfiguring-networking' -> dbus -> N-M
[18:50] <ogra_> yeah, understood
[18:50] <ogra_> slangaseks statement above sounded like it would only be filesystem related
[18:51] <slangasek> seb128: incidentally, dbus shows open FDs for /var/run/[...]; those should be fixed to reference /run instead
[18:51] <stgraber> it's, we want NM to go away very late to avoid hanging on network filesystems but we also need NM to really go away instead of keep on running till the end as it has a bunch of files opened which prevent the remount of /
[18:51] <slangasek> (not sure if following the /var/run symlink would hold /var open)
[18:51] <seb128> stgraber, I'm surprised that NM copes well with the system bus going down
[18:52] <slangasek> it doesn't
[18:52] <ogra_> hmm, intresting ... so i upgrade my new XPS13 to 12.10 and update-mananger asks me if i want to replace /etc/init.d/casper ...
[18:52] <stgraber> seb128: it doesn't
[18:52] <stgraber> seb128: when we stop dbus, NM goes away, that's why we're shutting down dbus so late so we can keep NM around till as late as possible
[18:52] <ogra_> i wasnt aware casper ever had a sysvinit script
[18:52] <seb128> I see
[18:53] <stgraber> ogra_: well, I guess the question mostly is, why is casper installed on your system? :)
[18:53] <ogra_> stgraber, ask dell ... the device runs only as long as i needed to have u-m do the upgrade and to install xchat
[18:53] <ogra_> like 1.5h or so
[18:54] <ogra_> i havent installed any SW except xchat yet
[18:54] <ogra_> (or removed)
[18:54] <xnox> ogra_: do you have "dell-recovery" installed? or oem-config?
[18:54] <ogra_> xnox, i think oemßconfig uninstalled itself, but yeah, dell-recovery is indeed there
[18:55]  * ogra_ allows it to replace ... 
[18:56] <ogra_> i still have more upgrades to do tonight ...
[18:56] <tjaalton> mdeslaur: an apache module needed by dogtag pki, although neither of those have made it to debian/ubuntu yet..
[18:57] <ogra_> bah
[18:57] <ogra_> it repopulated the launcher with all the default crap :(
[18:57] <mdeslaur> tjaalton: is it worth me still merging those changes? I'll do what you think is best
[18:58]  * ogra_ reboots 
[18:58] <tjaalton> mdeslaur: hmm looks like dogtag 10 doesn't need it anymore, I'll double check to be sure
[19:04] <tjaalton> mdeslaur: nah it still does, but maybe best to get that from debian along with the other pending changes I need.. so feel free to drop the diff
[19:04] <mdeslaur> tjaalton: cool, thanks for checking
[19:10] <tjaalton> yw
[19:59] <mdeslaur> infinity: hi! libimobiledevice has an ICE on arm64...do I mash retry or do you still push it on a specific builder?
[20:02] <xnox> mdeslaur: mash retry until it hits b*
[20:02] <mdeslaur> xnox: thank
[20:22] <arges> stgraber: hi.
[20:23] <arges> in bug 1065077 you changed (seq 600) to a while loop that only counts to 50. is this a typo or deliberate?
[20:37] <stgraber> arges: good catch. typo. I'll upload ifenslave-2.6 with a 60s timeout to trusty
[20:37] <arges> stgraber: before you do, I'd like to discuss the further implications of it
[20:38] <arges> stgraber: so we're seeing a bug where bringing a bonded interface using ' sudo service network-interface start INTERFACE=bond0' takes most of the timeout (60s) and obviously with this shortened timeout it doesn't delay as quickly
[20:39] <arges> stgraber: this bug causes issues when booting with bonds where we are more likely to hit the 'waiting on networking' message during boot
[20:39] <stgraber> well, that message in itself isn't a problem
[20:40] <stgraber> so long as the network is up by the time the 3min timeout hits (otherwise services may start before the networking is ready)
[20:40] <arges> so why does it take such a long time to bring up bonded interfaces?
[20:40] <stgraber> it doesn't take time to bring them up, but it can take a lot of time for the kernel to detect them
[20:40] <stgraber> I've seen bug reports of some systems where it'd take minutes for the kernel and udev to be done processing all the interfaces
[20:41] <arges> hmm...
[20:41] <stgraber> once the interface is ready to be bonded, ifenslave and ifupdown need less than a second to configure it
[20:41] <arges> stgraber: so in the ifenslave pre-up script there are two waits... one for the bonding module which is 5s and the other is for the slave interfaces to join the master
[20:42] <arges> does the later wait make sense to be 60s?
[20:43] <arges> stgraber: anyway. if it makes sense for the delay to be 60s, then the SRUs for P/Q i'll make sure are 60s, are you going to push a fix for R/S as well? or should i take care of that
[20:44] <stgraber> arges: I'm just pushing to trusty, the actual waiting time is completely arbitrary so 50s vs 60s isn't really going to make a huge difference :)
[20:44] <arges> well in this case it is 5s vs 60s
[20:45] <stgraber> oh indeed it's... yeah, that may fix some bugs ;)
[20:45] <stgraber> not that I actually saw any report that could be tracked down to that
[20:46] <stgraber> it'll also make things worse for someone who would configure a bond but not any member (or make a typo in the bridge name) as it'll now take longer before ifupdown gives up (though that'll at least match what ifupdown prints)
[20:47] <arges> stgraber: yea if 5s works for people, then why the long delay in the first place?
[20:48] <stgraber> because of those few weird systems where it can take minutes for hardware to be done initializing
[20:48] <stgraber> (blade systems with dozen of network cards is one known case)
[20:49] <arges> stgraber: it takes long times for bonding to get set up for me even in virtual machines
[20:49] <arges> so i run into the 'waiting on network configruation' pretty often with basic bonded setups
[20:49] <stgraber> arges: hmm, that's odd, can you pastebin your /etc/network/interfaces ?
[20:50] <arges> stgraber: yea booting up the vm right  now...
[20:50] <arges> so this is the original bug i was looking at, then i essentially found that raring fixed it, and found this bug... then as I was formatting the debdiff for the SRU i noticed the descrepancy
[20:51] <stgraber> yeah, looks like I copy/pasted the first loop without bumping the wait time
[20:53] <arges> stgraber: http://pastebin.ubuntu.com/6412656/ this is the bare-bones interfaces file i was using to reproduce
[21:04] <arges> note that it reproduces intermittently (at least on kvm) for me.
[21:04] <arges> anyway, i can file another bug for this one. For now how should I fix bug 1065077?
[21:06] <stgraber> arges: wow, that config is pretty wrong ;)
[21:07] <stgraber> arges: try that one instead: http://paste.ubuntu.com/6412714/
[21:08] <arges> stgraber: why wouldn't the bond-slaves contain eth0?
[21:08] <stgraber> basic changes are, ordering (so that ifup -a would work), emptying bond-slaves as it's meaningless on Ubuntu, moving IP configuration from the slave up to the bond as otherwise you're in undefined behavior
[21:09] <stgraber> because we're doing event based networking on Ubuntu, we can't guarantee all the slaves will be present at the time you try to bring up the master, so that's why ifenslave ignores bond-slaves and instead has the master wait for a slave to appear, the slave -> master relation being done through bond-master on the slave
[21:09] <stgraber> that's also why slaves should always be listed before the master in the config
[21:10] <stgraber> so that ifup -a will bring up a slave which will in turn bring up the master, doing it the other way around will give you the 60s timeout
[21:10] <arges> stgraber: so the interfaces file is followed sequentially?
[21:10] <stgraber> when calling ifup -a, yes
[21:10] <arges> which is called by the upstart scripts
[21:11] <stgraber> when booting Ubuntu, interfaces are brought up independently when receiving kernel events
[21:11] <stgraber> so if your interfaces file ordering is wrong, it'll likely still work at boot time so long as udev emits net-device-added
[21:11] <stgraber> but if it hits the fallback (networking.conf), then it'll hang
[21:12] <stgraber> (networking.conf works as a fallback in the boot sequence, calling ifup -a to bring up anything that wasn't brought up through events)
[21:12] <arges> stgraber: ok more complex example here: http://paste.ubuntu.com/6412731/
[21:12] <arges> with what i think it should be after my review and your comments
[21:13] <stgraber> hmm, I'm not sure the mtu stanza is allowed on manual interfaces, if it's not, then you'll need to use a pre-up instead
[21:14] <stgraber> but the ordering is indeed correct. I'm also not sure whether anything expect bond-slaves to be set, if so, you'll have to set it to none
[21:14] <arges> stgraber: ok i'll test with that.  Is the interface ordering for /etc/networking/interface documented somewhere?
[21:15] <arges> stgraber: nm man 5 interfaces, shows ifup brings the named interffaces up in the order listed
[21:16] <arges> stgraber: thanks for your help!
[21:16] <stgraber> right. I don't think it's actually written anywhere that ifup isn't doing parallel bring up but it can be assumed
[21:16] <stgraber> arges: also, the examples in the ifenslave-2.6 packages should be correct
[21:16] <stgraber> arges: https://www.stgraber.org/2012/01/04/networking-in-ubuntu-12-04-lts/ may also be ueful
[21:16] <stgraber> *useful
[21:17] <arges> cool thanks
[21:32] <orbisvicis> how do I find out which version of ubuntu a particular versioned package belonged to?
[21:35] <slangasek> orbisvicis: https://launchpad.net/ubuntu/+source/$package (for example)
[21:57] <orbisvicis> i need to go further back than supported releases
[21:57] <orbisvicis> is there an index in a repository (http://old-releases.ubuntu.com) that could help?
[21:58] <tarpman> orbisvicis: the
[21:58]  * tarpman sigh
[21:59] <tarpman> orbisvicis: the "View full publishing history" link on the package page should have the complete history
[21:59] <tarpman> orbisvicis: or, if you're wondering about a particular version, you can go straight to https://launchpad.net/ubuntu/+source/$package/$version and it has a publishing summary
[22:00] <orbisvicis> tarpman: perfect, thank you
[22:00] <orbisvicis> (I was wondering about a particular version)
[22:00] <slangasek> or, if you have that version of the package available, you can just look at the top of the changelog included in the package
[22:09] <doko> zul: simplejson should not build for pypy (universe). at least barry did that for beautilsoup4
[22:24] <doko> jamespage, there are some java sources ready for demotion. were these intended? http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
[22:25] <zul> doko:  ack
[22:25] <doko> well, barry didn't do it yet for bs4 :-/
[22:29] <bdmurray> slangasek: regarding the already installed and configured bugs I've seen some cases like bug 1250951 where one package operation crashes and then the next one runs into the already installed and configured error
[22:30] <slangasek> bdmurray: right, historically this kind of problem only shows up if something goes wrong with an earlier package operation
[22:30] <slangasek> but something is sending the wrong request to dpkg in these scenarios... and it's not apt
[22:32] <bdmurray> in the log files all we have is "Commandline: aptdaemon role='role-commit-packages' sender=':1.73'" which doesn't specify a version of aptdaemon
[22:47] <bdmurray> slangasek: Do you think gathering information about the aptdaemon version would help or is there something else we would need?
[22:48] <slangasek> bdmurray: I think that's the place to start
[23:12] <slangasek> xnox: hmm, "not booting flipped"?
[23:12] <slangasek> xnox: N7> AUUUUGH NOO :)
[23:13] <xnox> slangasek: yes, i'm booting a tarball from system-image.ubuntu.com not from cdimage.ubuntu.com/ubuntu-touch/)
[23:13] <slangasek> xnox: the N7 is absolutely not the template for android partitioning
[23:13] <xnox> slangasek: sure, but i don't want to brick my N4 =)
[23:13] <slangasek> the N7 is the device we can't get rid of the loop mount on, because it has broken firmware that causes its GPT to be broken in three different ways
[23:13] <xnox> slangasek: what's wrong with N7? N4 partitions are semi ok.
[23:13] <slangasek> all of which are N7-specific
[23:14] <xnox> slangasek: ok.
[23:14] <xnox> slangasek: and N4 GPT? any better?
[23:14] <xnox> slangasek: so I call cdimage.u.c/ubuntu-touch-preview/ - unflipped, /ubuntu-touch/ - flipped, system-image.u.c - systemimage
[23:14] <slangasek> xnox: the N4 GPT should be fine
[23:15] <slangasek> xnox: right - and 'flipped' should be the current baseline
[23:15] <xnox> in flipped, indeed android's system partition is mounted direct from the system one.
[23:15] <slangasek> oh
[23:15] <slangasek> but the difference between flipped and unflipped is whether Android is in a container, or Ubuntu is
[23:16] <xnox> slangasek: i don't think so. given that (a) system-image is easier to boot and port to new devices. (*) as long as one touches /userdata/.writable_image ;-)
[23:16] <xnox> and system-image is better tested model =) and boots more reliably.
[23:16] <slangasek> oh, so you mean system-image rather than flipped
[23:16] <xnox> yes.
[23:16] <slangasek> right
[23:17] <slangasek> yeah, that's what I mean by 'flipped should be the current baseline' - because calling it "flipped" implies the question, "flipped wrt what" :)
[23:17] <xnox> currently it was agreed that emulator should look more like system-image. And it does mimic it rather well, the final booted state. There is no way to actually apply delta updates.
[23:17] <xnox> slangasek: ok. so it is flipped+optionally-ro
[23:19]  * ogra_ still disagrees with that decision 
[23:20] <ogra_> (going for system-image immediately)
[23:22] <xnox> ogra_: (a) final phones will be system-image (b) will-not have android sized partitions (c) we need to get there somehow
[23:22] <xnox> ogra_: what do you think about bypassing CM and rebasing on top of kitkat/AOSP ?
[23:22] <ogra_> right, but we dont help porters with that
[23:23] <ogra_> i wish we had gone the same way we had to go for our phones and which porters have to go as well
[23:23] <slangasek> we're not doing all this work on the emulator to help porters
[23:23] <xnox> ogra_: phonedations can help porters ;-)
[23:23] <xnox> if there is any spare time
[23:23] <ogra_> not really anymore ... i have not the slightest clue about the current probs that show up when porting
[23:24] <xnox> ogra_: i'll just post how to start a port direct from system-image, how about that?
[23:24] <ogra_> going the same path would have helped
[23:24] <ogra_> and we could have updated the docs alongside
[23:24] <slangasek> no, going the same path would have just slowed us down
[23:24] <ogra_> anyway, its to late now
[23:24] <ogra_> we're simply leaving the community behind
[23:25] <ogra_> (none of the ports is even near to functional, we gave up on them and they gave up on us)
[23:26] <ogra_> i wish we had sent a sign to them with the emulator work (and updated the porting docs)
[23:30] <xnox> well emulator is not functional yet - it doesn't read kernel/initramfs of the hard-drive, nor has unity painting anything on the screen.
[23:31] <slangasek> any minute now :)
[23:31] <ogra_> yeah
[23:31] <ogra_> rsalveti rocks ... only minor details left :)
[23:55] <barry> doko: i might get to it tomorrow