[03:43] <ohsix> hi, re: changelog for pam in natty, mentions kernel changes for file descriptor limits; is that for the patch that changes it to 4096 or was there something else interesting that happened in .38
[03:53] <micahg> ohsix: did you see the latest kernel changelog?
[03:53] <c2tarun> micahg: hi, if possible please look at a query I posted in #ubuntu-motu :/ i am stuck
[04:00] <ohsix> micahg: yea, the one about the patch to change the number of fds; thats "the patch" i was referring to :]
[04:02] <ohsix> hrm nevermind, reading the bug now
[07:26] <ohsix> hi, another java question: NetX and the plugin moved to the IcedTea-Web project with a separate release cycle.
[07:27] <ohsix> in the icedtea readme for openjdk-6, but it appears theres no package for it, there _is_ a package for an icedtea plugin, but it appears to be something else, and older
[07:35] <ohsix> afk, but if someone can clarify the whole java situation it'd be much appreciated; trying to eventually report somtehing crashing but finding out the relationship of everything involved is proving difficult
[07:38] <micahg> ohsix: the plugin is in a separate source called icedtea-web
[07:38] <micahg> the binary is icedtea-plugin
[07:58] <Tm_T> Patc (:
[08:00] <micahg> mthaddon: you realize that's an hour early, right?
[08:02] <didrocks> good morning
[08:02] <mthaddon> micahg: an hour early compared to what?
[08:02] <slangasek> compared to the stated time
[08:03] <micahg> mthaddon: the notice is up 1hr before the downtime
[08:04] <mthaddon> I don't think so - I'm pretty sure it was always scheduled for this time in UTC
[08:05] <micahg> mthaddon: I was just noting current time is 07:04 UTC, just wanted to make sure since various people have had DST issues lately
[08:06] <pitti> Good morning
[08:07] <ohsix> micahg: ok
[08:08] <ohsix> micahg: i just reproduced the problem i was having with icedtea/openjdk with the sun plugin, so i'm looking at ff now
[08:08] <ohsix> it is something that changed between b1 and b2
[08:08] <micahg> ohsix: help with bug reporting in #ubuntu-bugs please :)
[08:08] <ohsix> i'm reporting them :D
[08:11] <ohsix> oh heh, it does say icedtea-web in the changelog for icedtea-plugin, oof,
[08:12] <micahg> ohsix: there were just new uploads of both
[08:12] <ohsix> ok
[08:14] <ohsix> micahg: can you explain why jamvm/cacao are there? since for most purposes they're drawn in with the browser plugin where its a bit tricky to switch between them
[08:14] <micahg> ohsix: nope, I haven't dug into it that much yet
[08:15] <ohsix> okie dokie, thanks again
[08:22] <ohsix> micahg: maybe you can confirm something; http://www.runescape.com/game.ws use firefox's full screen mode; let it load, make sure the toolbar is set to auto hide
[08:23] <ohsix> it crashes when the toolbar comes donw after it is fully loaded (shown the login screen) you can tell w/o logging in by the cursor having stopped blinking and not being able to click on it, the applet viewer crashes and nothing notifies the browser side plugin about it
[08:25] <micahg> ohsix: not right now, maybe someone in #ubuntu+1 can verify
[08:25] <ohsix> micahg: ok, thanks
[08:26] <ohsix> oh yea, keep forgetting i'm  using natty D:
[08:26] <ohsix> i had great luck pinning natty's ff4 to maverick before i switched entirely though :]
[08:44] <dholbach> good morning
[08:45] <sladen> ohsix: "RuneScape Applet" ... I get a "do you trust this content?" box
[08:47] <ohsix> sladen: oh, yea it uses native code to do 3d, and needs authorization
[08:47] <ohsix> it might just use software 3d if you don't but i haven't tried it
[08:53] <ohsix> sladen: i may have to read your response in the morning, but if it doesn't crash immediately; have it bring down the toolbar a few times (also it rarely hides automatically since the focus change is to a native plugin and not client web content, to force the toolbar away focus in the address bar and hit escape)
[08:54] <ohsix> but i will be looking, msg or hilight if you can
[10:19] <talat> Hi i try to repacakged my python using apt-get and dpkg but python gives 3 error in unit test can you help me why cant i repackage my python ?
[10:25] <talat> ?
[10:25] <talat> isn't there any one knows packaging ?
[10:26] <cjwatson> plenty, but your question is pretty vague
[10:27] <cjwatson> a full build log posted to paste.ubuntu.com or similar would stand a better chance of getting somebody to look at it
[10:28] <talat> cjwatson: ok now i paste :)
[10:40] <tjaalton> what is the preferred naming scheme for SRU's? I see all kinds of variants, incrementing -0uX, -0u1.Y, -0u1~hardyX, -0u0.8.04.X etc
[10:40] <tjaalton> quite a mess imo :)
[10:41] <pitti> tjaalton: the preferreed naming schema is to add 0.1 ubuntus
[10:41] <pitti> tjaalton: appending it sometimes needs more tricks like appending 0.8.04 and 0.10.04 if the same versino exists in several releases
[10:42] <tjaalton> pitti: ok thanks, so 7.3+2 -> 7.3+2ubuntu0.1 then (for x11-xserver-utils SRU)
[10:42] <tjaalton> pitti: yeah, ok
[10:42] <pitti> tjaalton: right
[10:44] <simion314> hi, i need a link to some page that has information about how to get a comercial application on the ubuntu software center,thx
[10:55] <bdrung> to whom can i talk about multiarch?
[10:55] <mthaddon> simion314: trying to find out for you - will let you know when I get some info
[10:56] <seb128> bdrung, you can just ask on the channel
[10:56] <seb128> bdrung, but slangasek has been driving the work on it mostly so if you have specific questions maybe slangasek
[11:01] <bdrung> seb128, slangasek: i just want to let the multiarch people know about bug #752101 and #752350
[11:02] <bdrung> is someone working on multiarch in synaptic?
[11:02] <bdrung> it currently renders synaptic useless
[11:03] <seb128> mvo, ^
[11:03] <seb128> tseliot, ^
[11:03] <mvo> bdrung: not currently :/
[11:03] <seb128> bdrung, you can tag multiarch bugs as "multiarch"
[11:03] <bdrung> seb128: already done
[11:04] <mvo> bdrung: I can have a look after lunch, basic support (to show audacious:386) should be striaghtforward
[11:04] <bdrung> seb128: is it possible to subscribe to tagged bugs?
[11:04] <bdrung> mvo: that would be a huge improvement
[11:05] <seb128> bdrung, I don't think so
[11:05] <SpamapS> cjwatson: is there a way I can take a look at the plymouth bits that will show the integration with upstart's dbus signals?
[11:06] <cjwatson> in what way?
[11:06] <cjwatson> perhaps change the plymouth-upstart-bridge job to run with --debug?
[11:06] <SpamapS> cjwatson: well I'm trying to form a good vision fo where we are and where I'd like to see us go for server boot.
[11:06] <SpamapS> s/fo/of/
[11:08] <SpamapS> cjwatson: the most common request is "just show me what its doing"
[11:08] <SpamapS> which I think it already does..
[11:08] <SpamapS> but I'm not entirely sure how to show that. ;)
[11:09] <cjwatson> plymouth-upstart-bridge gets all goal and state changes from upstart from the point it starts up, and does its best to render those into a reasonable approximation of traditional starting/stopping messages
[11:10] <cjwatson> oh, and it gets told when jobs fail too
[11:10] <SpamapS> cjwatson: and those will show up in plymouth-theme-ubuntu-text if --debug is passed?
[11:10] <cjwatson> I think if you look at the on_failed and on_state_changed functions in src/upstart-bridge/plymouth-upstart-bridge.c, it should make it fairly clear
[11:11] <cjwatson> SpamapS: oh, for a user to see them, they just need to not pass 'quiet'
[11:11] <cjwatson> I thought you wanted more than that
[11:11] <SpamapS> *ah*
[11:12] <cjwatson> if you want a full dump of what the bridge is getting from upstart, you can edit /etc/init/plymouth-upstart-bridge.conf to add '--debug 2>/dev/.initramfs/plymouth-upstart.log' to the end of the exec line
[11:12] <cjwatson> but that's for developers not users
[11:12] <cjwatson> (roll on /run)
[11:13] <SpamapS> cjwatson: ty.. thats just what I needed. :)
[11:13] <cjwatson> one thing I suspect we need to do is to go through the description fields of upstart jobs and make them fit into this presentation (or possibly adjust the presentation code in the bridge)
[11:14] <cjwatson> since that field was purely informational before this, there are some cosmetic inconsistencies
[11:14] <ev> could someone please approve my mail to ubuntu-devel-announce?
[11:15] <SpamapS> cjwatson: while I have your attention.. as a hypothetical, if we want this on all the time..  would it be possible and/or advisable to make the server not have 'quiet' passed by default?
[11:16] <cjwatson> to fit well into the bridge, the description field of task jobs should be a sentence about what the task is doing, in sentence case, without a final full stop; and the description field of services should be a noun phrase naming the service, starting with a lower-case letter unless the service name is naturally title-case
[11:17] <cjwatson> SpamapS: it should be possible
[11:17] <cjwatson> the code gets fiddly due to too-many-requirements-syndrome, but that's my problem
[11:17] <cjwatson> ev: done
[11:18] <ev> thanks
[11:22] <SpamapS> cjwatson: I see what you mean.. "Stopping: System V runlevel compatibility" .. doesn't make much sense but could be quite helpful.
[11:22] <cjwatson> (there's no :)
[11:22] <cjwatson> er, "no colon"
[11:23] <cjwatson> that's an interesting case; there's currently no way to have per-instance descriptions, or to explicitly mark a job as always quiet
[11:24] <cjwatson> I've added the basic facility, but it definitely needs a full review for the cosmetics
[11:25] <cjwatson> seb128: FYI, you can now do orig.tar.xz uploads (bug 742408)
[11:25] <seb128> cjwatson, oh nice, thanks a lot ;-)
[11:25] <SpamapS> cjwatson: whats there now is actlually good, I didn't realize the "Starting AppArmor Profiles ..." stuff was actually that.
[11:25] <SpamapS> most of my VMs don't have many services installed. :-P
[11:26] <cjwatson> SpamapS: actually that one is emitted by a traditional init script, not by plymouth-upstart-bridge
[11:26] <SpamapS> ah
[11:28] <SpamapS> hrm.. so w/o quiet.. we get stuff all over tty1 ..
[11:28]  * SpamapS really shouldn't be brain dumping to IRC at 3am
[11:30] <cjwatson> seb128: (though note that I don't believe .xz source uploads are available in Debian yet - I know they're working on it)
[11:32] <seb128> cjwatson, (no worry, GNOME said they would not switch to .xz before next cycle and they will keep .tar.bz2 for a while as a backup solution for those who don't support .xz)
[11:33] <seb128> but nice to know that launchpoad handle .xz for when it will be needed ;-)
[11:36] <SpamapS> cjwatson: looks like respawning could use special consideration too. I think smbd may get respawned a whole bunch of times right now because it needs an 'and net-device-up' in it start on.. we get about 6 "Starting SMB/CIFS File Server" lines..
[11:37] <cjwatson> or maybe that's a case where the six lines are a useful note to us that we need to fix something - could look at that either way
[11:38] <SpamapS> true.. the detail will be in syslog
[11:39] <SpamapS> heh.. I imagine that is slowing down boot
[11:39] <SpamapS> smbd thrashing about in the first 5 seconds
[11:44] <SpamapS> cjwatson: is it a bug then, when init.d scripts call 'echo' directly?
[11:44] <cjwatson> no, init.d scripts have to
[11:45] <cjwatson> plymouth-upstart-bridge doesn't do anything with them, only with native upstart jobs
[11:45] <tseliot> seb128: I'll fix nvidia-common. Thanks for the heads up
[11:46] <cjwatson> oh, sorry, do you mean directly rather than using the LSB functions?
[11:46] <SpamapS> I thought they would need to call a shell function that would send to plymouth or console so they didn't run all over the plymouth output
[11:46] <seb128> tseliot, thanks
[11:46] <SpamapS> cjwatson: yes
[11:46] <cjwatson> SpamapS: on the whole Ubuntu init.d scripts should have been converted to LSB functions; but calling echo still goes via plymouth
[11:47] <cjwatson> now that we don't use usplash any more, the main purpose of the LSB functions is just to do nicer formattin
[11:47] <cjwatson> g
[11:47] <SpamapS> http://paste.ubuntu.com/590174/
[11:48] <SpamapS> This shows things not really looking so pretty..
[11:48] <cjwatson> that's basically a line-buffering problem
[11:49] <SpamapS> so.. plymouth bug?
[11:49] <cjwatson> I'm not quite sure
[11:49] <cjwatson> plymouth is a reasonable dumping ground for it, but I'd need to sit and think about it
[11:50] <SpamapS> As I understand it, the point of plymouth is to be the traffic cop between stuff running in parallel and the console.
[11:50] <SpamapS> (I mean the point of plymouth sans pretty graphics for the desktop)
[11:50] <cjwatson> yes, but there's only so much it can do if the actual bytes sent to the console are out of order
[11:50] <cjwatson> that's why I want to think about it
[11:50] <SpamapS> Ok. :)
[11:50] <cjwatson> it may be that lsb-base-logging.sh should be changed to use the plymouth client, which would give plymouth more structured input in this case
[11:53] <cjwatson> plymouth is also what makes /var/log/boot.log exist, BTW
[11:53] <SpamapS> Right, thats a bit of magic I was just counting on.. not thinking about at all. :)
[11:53] <cjwatson> we never had boot logging working before, because it needed something that was basically plymouth-shaped
[11:55] <SpamapS> cjwatson: so that you can decide when to think about this.. rather than it interrupting you at the moment, do you want me to open a bug report?
[11:55] <cjwatson> yes please
[11:56] <cjwatson> if you can include a recipe for setting up a vm to look like that, that would be good
[11:56] <SpamapS> surely. should I open it against plymouth?
[11:57] <cjwatson> actually, you might as well just open it against lsb-base
[11:57] <cjwatson> I think that's likely where it belongs
[11:57] <SpamapS> cool
[11:57] <cjwatson> so the lsb source package
[12:02] <SpamapS> cjwatson: bug #752393 opened
[12:03] <cjwatson> thanks
[12:03] <SpamapS> oh no, as always, thank you. :)
[12:34] <ev> mvo: heads up: I've added an item to OneiricPlanning for this idea http://paste.ubuntu.com/590182/ which I thought might interest you.
[12:42] <TeTeT> I've submitted a debdiff for bug 692922 that seems to be faulty - it may crash compiz hard. any chance to hinder it to get into lucid-proposed?
[12:42] <mvo> thanks ev!
[12:42] <seb128> TeTeT, hum, mvo said he uploaded it?
[12:42] <mvo> TeTeT: that is uploaded, no?
[12:43] <TeTeT> mvo: yes, fear so - I got a report from a tester a few minutes ago
[12:43] <mvo> seb128: could just just reject it from the queue (or another archive admin)?
[12:43] <seb128> mvo, why? is it incorrect?
[12:43] <mvo> ev: thanks, the data snapshot is a good point, the release one as well
[12:43] <seb128> doh
[12:44] <mvo> seb128: apparently it can crash
[12:44] <seb128> TeTeT, mvo: sorry I misread what TeTeT was saying
[12:44] <mvo> seb128: yeah, me too
[12:44] <mvo> I thought he looked for sponsoring, not reverse sponsoring
[12:44] <seb128> TeTeT, mvo: rejected from the lucid queue
[12:44] <ev> mvo: sure thing
[12:45] <mvo> seb128: thanks!
[12:45] <seb128> mvo, yw
[12:45] <seb128> ev: hey, you got a ubuntu-geonames merge request from mterry ;-) just mentionning it in case you don't notice those, I know we tend to not get notified for desktop ones
[12:46] <ev> seb128: indeed, it's on my todo list for today :)
[12:46] <seb128> ev: great, thanks ;-)
[12:47] <TeTeT> seb128: thanks a bunch!
[12:54] <YokoZar> Is CDBS something we're trying to phase out long term?
[12:54] <YokoZar> I've heard a lot of devs express great preference for debhelper
[12:59] <cjwatson> YokoZar: it probably depends whom you ask
[12:59] <cjwatson> YokoZar: there is a trend in that direction, certainly, but I wouldn't say there's consensus
[13:00] <mvo> bdrung: basic support is now done (took more time to write the configure.in bits then the actual code :/
[13:00] <YokoZar> cjwatson: I was considering putting in a debhelper feature request but the particular feature is already completely implemented in CDBS
[13:00] <cjwatson> http://people.debian.org/~cjwatson/dhstats.png <- dh vs. cdbs trend in Debian
[13:01] <cjwatson> (sorry, the legend is mangled, I should fight with gnuplot some more at some point)
[13:01] <cjwatson> s/legend/X-axis labelling/
[13:01] <soren> What is dh(1)?
[13:01] <soren> Or rather, how is it different from "debhelper"?
[13:02] <cjwatson> http://manpages.ubuntu.com/manpages/natty/en/man1/dh.1.html
[13:02] <soren> Yes...
[13:02] <YokoZar> From that graph I'd have to guess that it looks like cdbs packages are staying cdbs, but all the new ones are debhelper
[13:02] <soren> Ok, then what is debhelper 7?
[13:02] <soren> :)
[13:02] <cjwatson> "debhelper 7" on that graph means that debian/compat says >= 7
[13:03] <soren> Oh, ok, so there are packages that might count against both?
[13:03] <cjwatson> yes
[13:03] <soren> s/both/more than one/?
[13:03] <soren> Oh, ok.
[13:04] <cjwatson> YokoZar: I think on the whole that's probably true (and there's conversion of existing packages to dh too), although there are also some cdbs->dh and *->cdbs conversions
[13:04] <cjwatson> gets hard to graph those
[13:05] <cjwatson> actually, sorry, having checked my code, "debhelper 7" is actually packages whose build-dependencies imply at least debhelper (>= 7~)
[13:06] <soren> Ok.
[13:06] <cjwatson> the dh(1) line is any package whose debian/rules matches /^\s+dh\s+/m
[13:11] <YokoZar> how on earth did I manage to make solitaire crash with a branding update...
[13:15] <bdrung> mvo: thanks. where do i get the code from?
[13:16] <mvo> bdrung: I just uploaded it to natty
[13:18] <bdrung> mvo: you forgot to close bug #752350 in d/changelog
[13:20] <mvo> bdrung: ups, thanks
[13:41] <juliank> Did nobody work on multi-arch support in aptitude?
[13:42] <juliank> OK, it partially works with multi-arch, but it uses Name() instead of FullName() to display names, causing architecture information to be omitted
[13:46] <bdrung> diwic: re bug #722375 - your patch fixes the crashes (a big improvement), but still produces ~ 10% load on my netbook.
[13:47] <diwic> bdrung, hmm, what was the cpu load before the patch?
[13:47] <bdrung> i just launched audacity
[13:50] <bdrung> diwic: 50% - 70%
[13:52] <bdrung> diwic: and it hanged often before the crash
[13:52] <bdrung> s/crash/patch/
[13:56] <diwic> bdrung, if you use the other workarounds (menuproxy= etc), do you get rid of the 10% then? I'm just thinking it might be unrelated
[13:59] <bdrung> diwic: you are right. that's unrelated. same workload with menuproxy workaround
[13:59] <diwic> phone
[13:59] <bdrung> diwic: then please upload your fix.
[14:08] <diwic> bdrung, I don't have any upload rights
[14:09] <bdrung> diwic: then give me a debdiff :)
[14:13] <diwic> bdrung, ok, will do later today (just got three things in parallel)
[14:13] <bdrung> k
[14:15] <steveire> I'm running a live cd and trying to install iotop which is in universe. I tried sudo vi /etc/apt/sources.list but the file doesn't exist. What's going on?
[14:29] <diwic> bdrung, for appmenu.patch, did you talk to upstream anything or did you just cherrypick their svn commit
[14:31] <bdrung> diwic: i didn't talk to upstream. i just tested the patch that you posted
[14:32] <diwic> bdrung, I was asking about the previous patch, appmenu.patch
[14:34] <bdrung> diwic: dunno who wrote it and where it comes from.
[14:35] <diwic> bdrung, I just ask you because you were the one uploading appmenu.patch.
[14:35] <seb128> TeTeT, hey, seems I closed that IRC tab
[14:35] <bdrung> diwic: mom, let's check that.
[14:36] <seb128> TeTeT, vinagre ... depends of kees and the security team, we wanted to use reminna this cycle but they blocked it on security review issues
[14:36] <seb128> not sure vinagre is any better but status quo is that we are blocked with it until that is sorted
[14:36] <TeTeT> seb128: can we expect reminna to make it into 12.04, or way to early to tell?
[14:37] <diwic> bdrung, debdiff attached to the bug
[14:37] <bdrung> diwic: i pulled the patch from upstream vcs
[14:37] <seb128> TeTeT, dunno, as said kees blocked it so it depends of whether upstream fixes the issue or not
[14:38] <diwic> bdrung, just wondering if you just picked it or if a discussion with upstream was preceeding that pick. I think my fix should be upstreamed
[14:38] <TeTeT> seb128: ok, thanks
[14:39] <seb128> TeTeT, do you have issue with vinagre or request to use reminna?
[14:39] <bdrung> diwic: can you upstream your fix and add a DEP-3 header to the app-menu2.patch?
[14:39] <seb128> TeTeT, https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/673908 for the record if you are interested in details
[14:39] <TeTeT> seb128: nah, customer surprised me by telling me something new was coming and I had no idea ;)
[14:39] <seb128> TeTeT, https://bugs.launchpad.net/ubuntu/+source/freerdp/+bug/673925
[14:40] <diwic> bdrung, I'm quite busy, do we have anyone who is our upstream contact?
[14:41] <bdrung> dunno
[14:41] <diwic> ok
[14:41] <diwic> I'll see if I can find a ML then
[14:42] <bdrung> diwic: the app-menu.patch was posted by Tim Kosse who seems to be an upstream developer
[14:42] <bdrung> diwic: https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/662077/comments/7
[14:45] <diwic> bdrung, thanks
[14:47] <bdrung> diwic: let me know once you have added the dep3 header
[14:48] <diwic> bdrung, is it ok with forwarded: no for now?
[14:48] <diwic> i e in the dep-3 header
[14:48] <bdrung> yes
[14:56] <diwic> bdrung, uploaded to bug
[14:58] <seb128> slangasek, hey, I thin you broke unity application matching with the multiarch bamf update
[15:02] <bdrung> diwic: uploaded, thanks
[15:02] <diwic> \o/
[15:02] <diwic> thanke
[15:02] <diwic> s/e/s
[15:02] <bdrung> diwic: or s/th/d/ ;)
[15:06] <killown> do anyone know what's the .qml file responsible to set the laucher width? I could resize the icons using LauncherItem.qml, LauncherList.qml but I have not found anything about resize launcher width
[15:17] <pitti> stgraber: hm, what's this "fake-udev" package that udev.preinst refers to?
[15:18] <stgraber> pitti: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/745011 (dpkg-divert diverts a file for all packages except the one in --package)
[15:19] <pitti> stgraber: ah, I'm currently trying to recover from a really nasty upgrade failure due to that
[15:19] <pitti> Preparing to replace udev 167-0ubuntu1 (using .../udev_167-0ubuntu2_amd64.deb) ...
[15:19] <pitti> dpkg-divert: error: `diversion of /sbin/udevadm to /sbin/udevadm.upgrade by fake-udev' clashes with `diversion of /sbin/udevadm to /sbin/udevadm.upgrade by udev'
[15:20] <stgraber> oh, how's that even possible ... did you have a udev upgrade crash in the past ?
[15:20] <stgraber> that'd explain why you have a divert set before the upgrade to the new package
[15:20] <pitti> stgraber: ah, it's just the retracer chroots
[15:20] <pitti> I think seb128 just nuked the postinst instead of just removing set -e
[15:20] <pitti> yes, that'd explain it
[15:20] <stgraber> I'd just remove the divert manually, that should fix it
[15:20] <pitti> right, that's what I did
[15:20] <pitti> stgraber: thanks!
[15:20] <pitti> sorry for the noise, got the idea a second after I pinged
[15:20] <seb128> pitti, oh right, sorry about that
[15:21] <pitti> seb128: np
[15:22] <seb128> ok, I officially hate the multiarch changes landing so late in the cycle that's decided ;-)
[15:25] <cjwatson> stgraber: is it possible to safely clean up the old diversions?
[15:27] <slangasek> bdrung: 752101, 752350> yes, there are package management tools that don't work when multiarch is enabled, that's why I'm not pushing to enable it by default in natty
[15:28] <slangasek> seb128: application matching - hrmm, where is this?
[15:28] <seb128> slangasek, bamf
[15:29] <slangasek> seb128: right, but how did it break?
[15:29] <seb128> slangasek, I'm investigating, the gio part is not being used
[15:29] <seb128> slangasek, /usr/lib/i386-linux-gnu/gio/modules has an empty cache there
[15:30] <seb128> which would explain it
[15:30] <seb128> trying to figure why it's empty now...
[15:31] <slangasek> seb128: ah, giobamf is present but missing from the cache here as well.. maybe I messed up the trigger somehow
[15:31] <seb128> slangasek, no, launching the cache update command by hand leads to the same result
[15:32] <slangasek> hmm
[15:32] <seb128> there is something it doesn't like in libgiobamf.so
[15:32] <stgraber> cjwatson: postrm is supposed to revert the binary and remove the diversion in case something goes wrong. I can probably check for an old diversion before doing dpkg-divert and remove it if it exists though.
[15:33] <seb128> slangasek, I've copied that file in /usr/lib/gio/modules and run the update cache line and the .cache list everything but it
[15:33] <slangasek> seb128: is it reproducible with the previous upstream version of bamf?
[15:34] <seb128> slangasek, it works with 0.2.80-0ubuntu1 and is broken with 0.2.80-0ubuntu2
[15:34] <slangasek> hmm
[15:35] <seb128> slangasek, no in fact I'm wrong
[15:36] <seb128> it's not listed
[15:37] <seb128> slangasek, I need to check on that, i seem to recollection that gio check the cache and fallback to read the directory if the file it needs is not cached
[15:39] <slangasek> seb128: looking at gio-querymodules source, it tries to find the symbol g_io_module_query and only adds it to the cache if found; bamf doesn't provide this symbol; I'm reasonably certain nothing I did for multiarch broke this
[15:40] <seb128> slangasek, right, the cache issue was a wrong track
[15:40] <slangasek> ok
[15:40] <seb128> slangasek, it was not in the cache either for 0.2.80-0ubuntu1 but that version works
[15:42] <slangasek> seb128: ok - but the functionality regressed between -0ubuntu1 and -0ubuntu2?
[15:42] <seb128> slangasek, yes
[15:42] <seb128> slangasek, one way to test is cp /usr/share/applications/gedit.desktop .
[15:42] <seb128> edit gedit.desktop, tweak the Name=
[15:42] <seb128> double click on that .desktop from nautilus
[15:42] <seb128> with 0.2.80-0ubuntu1 the launcher display the edited .desktop name
[15:42] <seb128> with 0.2.80-0ubuntu2 it matches the system one
[15:43] <seb128> i.e it doesn't track which one gio launched but go back to do fallback matching
[15:43] <seb128> you need to restart bamfdaemon and unity between upgrades or downgrades to test
[15:43] <seb128> slangasek, it's likely what create bug #751025 as well
[15:44] <slangasek> seb128: ok. I only moved the files as part of the FTBFS fix because it looked like an easy win; if it's not, let's roll back the multiarch changes for natty and see if that fixes
[15:47] <seb128> slangasek, doing a mv /usr/lib/i386-linux-gnu/gio/modules/libgiobamf.so /usr/lib/gio/modules seems to fix it
[15:47] <seb128> I don'g get why though
[15:47] <seb128> don't
[15:48] <slangasek> oh.  In that case, what about other modules in /usr/lib/<triplet>/gio/modules?  Is the process that's failing to find bamf failing to find them as well?
[15:51] <seb128> slangasek, we have none in there right now so not sure, I would still like to understand why it breaks before moving it back
[15:53] <slangasek> seb128: I have glib-networking installed to that directory, but I haven't used it
[15:54] <slangasek> I'm not sure I know how to use it
[15:55] <slangasek> seb128: what if you were to manually add the module to the cache in the multiarch dir?
[15:55] <slangasek> (as a test)
[15:56] <seb128> would that work since it doesn't define the symbol for lazy loading?
[15:56] <slangasek> it's possible the patch for the compatibility fallback in glib assumes the module will be in the cache
[15:56] <slangasek> I don't know, let me see if that symbol is needed at runtime or just at cache build time
[15:57] <seb128> well a strace on bamfdaemon shows that it loads the .so correctly
[15:57] <slangasek> hmm
[16:08] <seb128> slangasek, ok, right, adding a cache listing it in the new dir fixes it
[16:08] <seb128> slangasek, ie echo "libgiobamf.so:gio-desktop-app-info-launch-handler"
[16:08] <seb128> slangasek, removing it bring back the bug
[16:09] <seb128> slangasek, so it doesn't like things in the new dir which are not in the cache list
[16:09] <slangasek> ok, I wonder why that is
[16:10] <slangasek> it would be a glib bug rather than a bamf bug, I guess... which way would you like this fixed?
[16:10] <seb128> seems a glib issue indeed
[16:10] <seb128> slangasek, well ideally we would make it work in the new dir the same way it did in the old one
[16:10] <tseliot> slangasek: does changing the "Section" field in debian/control cause the package to be NEWed? Just to be sure..
[16:12] <seb128> slangasek, but I don't care much how we fix it in natty, I would prefer not by adding bamf to the cache list though since other components could run into the same issue
[16:13] <slangasek> tseliot: no
[16:13] <slangasek> seb128: ok; I can try to look at fixing glib later today then
[16:13] <tseliot> slangasek: ok, thanks
[16:14] <seb128> slangasek, thanks
[16:33] <seb128> slangasek, I've assigned you bug #751025 for tracking
[16:33] <SpamapS> slangasek: can you think of any reason moving smbd to 'start on runlevel [2345] or net-device-up' would cause things to break horribly?
[16:34] <SpamapS> slangasek: right now its 'start on local-filesystems' and this causes it to respawn profusely until lo exists...
[16:35] <slangasek> SpamapS: 'start on net-device-up' will just make it respawn profusely until /usr/sbin exists instead (or else get itself into a wedged state where it doesn't respawn at all)?
[16:38] <SpamapS> slangasek: right.. so if we marry it with local-filesystems then nfsroot has the same issue.. :P
[16:38] <slangasek> SpamapS: only when /usr is on a distinct nfs share, I think?
[16:39] <SpamapS> slangasek: what about just doing runlevel [2345]? Is smbd needed ever between local-filesystems and filesystem?
[16:39] <ohsix> micahg: cacao/jamvm are apparently available to help bootstrap the compiler; i'm sure there are other reasons but thats the first compelling one i've found
[16:49] <slangasek> SpamapS: I'm not sure; I would want to look at the genealogy of the upstart job in the package to see why it was set that way to begin with
[16:50] <SpamapS> slangasek: it has always been that start on since you wrote it. :)
[16:50] <SpamapS> timestamp: Thu 2010-02-18 12:51:45 +0000
[16:53] <slangasek> SpamapS: ok - then I'm still not sure, and you should do whatever makes sense :)
[16:54] <SpamapS> slangasek: I'm trying to think of a scenario where smbd should start before 'filesystem' ...
[16:54] <slangasek> SpamapS: /usr on loopback-mounted cifs? :P
[16:54] <SpamapS> slangasek: i think we call that *WINNING*
[17:02]  * cjwatson nails wubi bugs to the floor and stomps on the pieces
[17:02] <cjwatson> now I need to do something else for a while to keep my sanity
[17:15] <pitti> mterry, doko: do you have some time to review bug 752530? as this is a very late FFE, it'd be good to get that in ASAP for more testing
[17:15] <pitti> rickspencer3: ^ FYI
[17:16] <rickspencer3> thanks pitti
[17:17] <mterry> pitti, looking now
[17:17] <mterry> pitti, sorry, I haven't looked at incoming MIRs for a bit, didn't expect any  :)
[17:17] <rickspencer3> pitti, mterry could you guys please let me know asap if there are any problems there
[17:17] <rickspencer3> I can get back to sabdfl asap in case it doesn't look suitable
[17:17] <pitti> mterry: I only filed it a couple of hours ago, as before it wasn't ready yet :)
[17:19] <dbarth_> pitti: there is a wiki page describing a set of tests you guys can do on the scrollbar
[17:20] <dbarth_> pitti: it was used for the last call for testing that jibel organized
[17:20] <pitti> dbarth_: probably not that important for the MIR, but interesting in general; is that part of what QA does in their regular tests?
[17:21] <dbarth_> pitti: https://wiki.ubuntu.com/Ayatana/ScrollBars#Test guidelines
[17:21] <mterry> rickspencer3, no .symbols file.  I usually consider that a blocker.  Shouldn't take long to fix, can that be done soon?
[17:22] <dbarth_> pitti: ack
[17:24] <mterry> kenvandine, can you add a .symbols file to overlay-scrollbar?
[17:27] <kenvandine> mterry, sure
[17:28] <fEnIo> hello
[17:40] <kenvandine> mterry, done and uploaded
[17:41] <mterry> kenvandine, awesome
[18:00] <pitti> mterry, kenvandine: nice! seeding/promoting now
[18:02] <chrisccoulson_> has anyone had this error when trying to push a bzr branch: http://paste.ubuntu.com/590350/
[18:03] <pitti> chrisccoulson_: hm, try bzr reconcile?
[18:03] <chrisccoulson_> pitti - hmmm, same problem :(
[18:13] <Ampelbein> slangasek: hi, would it be possible for you to regenerate the http://people.canonical.com/~vorlon/broken-srcs-universe.txt list?
[18:13] <slangasek> Ampelbein: sure, running now
[18:13] <Ampelbein> slangasek: thank you!
[18:17] <j1mc> hi all - i wanted to discuss a doc-related bug here, as i think it's pretty important: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/748673
[18:17] <j1mc> basically, there are no real natty docs at this point, and i wanted to see about getting them in late, even post-release.
[18:21] <slangasek> Ampelbein: refreshed - pretty good progress!
[18:22] <j1mc> see bug: https://bugs.launchpad.net/bugs/600875 for background
[18:22] <slangasek> Ampelbein: from what I see, over half the packages left to be rebuilt have no reverse-dependencies anyway; I don't have this in report form, but if you're keen, a prioritized list would be: libfsobasics (FTBFS), libfsoframework, nbtk (FTBFS), libtranslate, tntnet, synfig, libsylph, nufw, libgsm0710mux, libfsotransport, abiword
[18:24] <Ampelbein> slangasek: yeah, I've been looking at the list, too. The libfsobasics-ftbfs I don't know how to fix, vala is completely new to me.
[18:25] <slangasek> Ampelbein: right, I don't know either
[18:26] <Ampelbein> slangasek: I filed some RM bugs, too: bug 749470, 749804, 750926, 751014
[18:26] <slangasek> Ampelbein: ah, great :)
[18:42] <geser> I'm looking at some of the FTBFS from the recent archive rebuild and stumbled about several build errors on amd64 with the same error: "dpkg-deb: error: control directory has bad permissions 700 (must be >=0755 and <=0775)". Someone have an idea what caused this?
[18:56] <fmut> Hello
[18:58] <fmut> I'm looking for some help. I have a source code that I would like to convert into a package (ubuntu compatible). I followed some of the tutorials for package generation using debhelper apps but everything seems to assume that you already have the standard configure/make setting
[18:58] <fmut> My question is the where is the best way to generate these configure/makefile configuration to be as standard as possible with the rest of the community
[18:59] <slangasek> geser: just buggy control dir generation that dpkg now complains about?  Do you have a sample link?
[18:59] <geser> slangasek: https://launchpadlibrarian.net/68375035/buildlog_ubuntu-natty-amd64.outguess_1%3A0.2-7_FAILEDTOBUILD.txt.gz
[18:59] <fmut> any help will be greatly appretiated
[19:00] <slangasek> fmut: if it's C or C++, to be as standard as possible, use autoconf+automake+libtool.  I don't know if there's a quickstart guide for autotools though
[19:00] <fmut> yes, it is c
[19:03] <bcurtiswx> fmut, in the youtube tutorials for packaging they use the package hello, correct?
[19:03] <fmut> no, they used ed, the gnu editor
[19:03] <geser> slangasek: if you need more pick one of the amd64 FTBFS after "mx" from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html and you might be lucky
[19:04] <bcurtiswx> maybe the wiki tutorials has hello.. but you may want to apt-get source <packagename> and look at the config and make files to maybe get a visual representation.
[19:04] <bcurtiswx> slangasek, is there a wiki on autotools at least?
[19:04] <slangasek> geser: oh, so it's just started happening in later builds?
[19:04] <slangasek> bcurtiswx: you are asking the wrong person, I learned autotools before wikis were invented
[19:04] <slangasek> :-)
[19:05] <geser> slangasek: looks like, the earlier ones I checked all failed with a different error
[19:06] <bcurtiswx> slangasek, were dinosaurs around? no no j/k.  thx tho :)
[19:06] <slangasek> geser: is there a different version of dpkg in use in the different failing builds?
[19:07] <fmut> it seems that the tutorial are all outdated ..
[19:07] <fmut> I'm also interested in learning a proper dirtory structure to organize my code ....
[19:07] <fmut> *directory*
[19:08] <slangasek> geser: hmm, 1.16.0~ubuntu6 is a dpkg build I uploaded and it hasn't failed for me here, so probably not
[19:08] <slangasek> wgrant: do you know what's going on with, e.g., https://launchpadlibrarian.net/68375035/buildlog_ubuntu-natty-amd64.outguess_1%3A0.2-7_FAILEDTOBUILD.txt.gz in the test rebuilds?
[19:10] <geser> slangasek: I looked at earlier builds and they all use the same dpkg-dev version
[19:13] <stgraber> pitti, cjwatson: http://paste.ubuntu.com/590389/ <- looks good ? that should fix the case where there was an old diversion set on a system
[19:14] <geser> slangasek: and only amd64 seems to be affected (https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2406466)
[19:14] <slangasek> geser: does it look like it's a single builder affected, or multiple ones?
[19:15] <geser> slangasek: was about to check it right now
[19:27] <geser> slangasek: the build records mention all available amd64 PPA builders. And the last package with that error is currently "picocom" but I don't know if the problem fixed itself or if the later packages are still in queue on amd64
[19:28] <slangasek> alrighty
[19:28] <slangasek> I guess we can watch for new failures showing up with the same error
[19:39] <plotino> ciao
[19:39] <plotino> anybody knows how to get java working in firefix?
[19:39] <plotino> firefox
[19:42] <micahg> plotino: support is in #ubuntu or #ubuntu+1, but just install icedtea6-plugin or sun-java6-plugin
[19:44] <plotino> sun-java6 is a propetary plugin?
[19:45] <micahg> plotino: yes
[19:47] <plotino> ok thanks
[20:23] <cjwatson> geser,slangasek,wgrant: whoa, that sounds like a recurrence of https://wiki.ubuntu.com/IncidentReports/2011-02-25-Permissions-build-failures
[20:23] <cjwatson> lamont: ^- alert, please?
[20:23] <lamont> that's build 2406466?
[20:24] <cjwatson> lamont: https://launchpadlibrarian.net/68375035/buildlog_ubuntu-natty-amd64.outguess_1%3A0.2-7_FAILEDTOBUILD.txt.gz
 slangasek: and only amd64 seems to be affected (https://launchpad.net/ubuntu/+archive/test-rebuild-20110329/+buildjob/2406466)
[20:24] <lamont> more interested in that to ge tteh builder name
[20:24] <cjwatson> ah yes
[20:25] <cjwatson> that's the one
[20:26] <geser> lamont: pick one of the amd64-only FTBFS between "mx" and "picocom" from http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html and you have a high chance to find an affected build
[20:27] <lamont> cjwatson: identified.  I've stuck the virtual builders on manual while I sort out the scope of it
[20:27] <lamont> non-virtual is not affected
[20:29] <cjwatson> phew.  thanks
[20:29] <cjwatson> is it the same thing as before?
[20:30] <lamont> there are about 3 different fixes for the mess before.  the virtual amd64 buildds are missing most or all of them atm
[20:33] <lamont> any one of them would be sufficient
[20:48] <lamont> cjwatson: so here's the scope....   to continue the saga of the original incident:  ultimately, the incident was resolved by adding a umask() call to sbuild on all of the non-virtual builders on 2/26, and sudo was downreved back to 1.6.9.  Subsequent to that, a compatible sudoers.d/buildd file was rolled out, and sudo went back to 1.7.2 as part of centralized management's requirements.  lp-buildd-76 did not include the cowboyed call to umask(), and
[20:48] <lamont>  was rolled out to the amd64 boxes Monday via dist-upgrade, creating the situation on the virtual builders that they (1) had sudo 1.7.2, (2) did not have a compatible sudoers file, and (3) lacked the sbuild backstop. ==> FAIL.
[20:48] <lamont> Also affected are any builds on non-permanent ppa builders that were re-installed anytime after early march. ==> MORE FAIL
[20:48] <lamont> launchpad-buildd 77 is building now, with the umask() call in it for the final backstop.  As I roll that out to the virtual builders, I'll put
[20:48] <lamont>  them back on auto.
[21:04] <ohsix> hm, mango-lassi uses the same icon networkmanager uses for ethernet, that's a little confusing :D
[21:17] <lamont> cjwatson: all but terranova are back.  we are still having words
[21:34] <cjwatson> lamont: thanks
[21:38] <ScottK> mtaylor: Please fix python-drizzle in Debian and Ubuntu.  kthnxbye.
[22:09] <jelmer> barry: hi
[22:09] <jelmer> barry: is there a UDD meeting?
[22:21] <mtaylor> ScottK: yes. on it.
[22:22] <ScottK> mtaylor: Great.
[22:23] <infinity> lamont: Sounds messy...
[22:24] <lamont> infinity: clusteramic
[22:24] <lamont> infinity: sudo changed umask handling between 1.6.9 and 1.7.2..  and well, sbuild wasn't ready for that kind of crazy
[22:25] <infinity> lamont: Yeah, I read the old incident report.
[22:25] <lamont> most amusingly, the "fix it in sudoers by restoring old behavior" is a syntax error with 1.6.9
[22:25] <lamont> anyway, afk for me for a while
[22:43] <kees> ScottK: say, your bug/feature email... how should the testcase be run?
[22:43] <ScottK> kees: I didn't actually run it (not my test case).  Let me find you the original message.
[22:44] <kees> ScottK: yeah, I'm a little lost on the actual situation they're seeing.
[22:46] <ScottK> kees: Here's the full message it came in: http://paste.ubuntu.com/590467/
[22:46] <ScottK> Their online mail list archive seems to be out of date.
[22:47] <kees> ScottK: ah-ha, okay. I waited too long. This reproduces for me: while ./testcase.pl ; do echo -n . ; done
[22:47] <ScottK> kees: With this as a followup http://paste.ubuntu.com/590468/
[22:47] <ScottK> (which motivated me to write the message)
[22:48] <kees> ScottK: right. let me poke at this for a bit -- a change like this in the kernel would likely effect more than just amavisd.
[22:49] <ScottK> Yep.
[22:57] <kees> hmmm
[23:15] <kees> ScottK: it's not perl. the kernel seems to be treating "shutdown()" differently :(
[23:15] <ScottK> Lovely.
[23:18] <kees> ScottK: I think it's a bug. I sent email with a C version of the PoC
[23:19] <ScottK> kees: Cool.  Could you comment in the Ubuntu bug?
[23:19] <kees> ScottK: yeah
[23:19] <ScottK> Thanks.
[23:29] <ScottK> kees: The other question I have is should we apply the Net::Server patch anyway?
[23:30] <ScottK> My Perl is non-existent, so I've no idea.
[23:33] <kees> ScottK: no, I think that's a hack specific to perl to work around the kernel bug. this will bite other daemons too, so we need to fix it in the kernel.
[23:34] <ScottK> OK.  Thanks.
[23:34] <kees> ScottK: I've converted the bug to a kernel bug and subscribed the kernel team. I assume it will get forwarded to upstream for a solution, since this is likely not an expected change.
[23:35] <kees> if it IS an expected change for some reason (I doubt it, given that the listening socket disappears from netstat) then we can revisit patching Perl (and all kinds of other stuff)
[23:36] <ScottK> Right.  Sounds good.