[00:03] <cjwatson> kees: http://ewx.livejournal.com/457086.html#t3016830
[00:04]  * kees hugs cjwatson 
[00:05] <kees> cjwatson: what a PITA. I had everything but the null_decode bit. grr
[00:11] <cjwatson> kees: python 3 is a bit less awful here
[00:11] <cjwatson> thank goodness
[00:12] <cjwatson> $ python3 -c 'print(str(b"\xc2\xb0", "utf-8"))'
[00:12] <cjwatson> °
[00:12] <cjwatson> $ python3 -c 'print("\u00b0")'
[00:12] <cjwatson> °
[00:12] <cjwatson> (not sure whether that first is the most idiomatic way)
[00:12] <SpamapS> slangasek: god bless you for maintaining freetds. :)
[00:13] <kees> cjwatson: ah, much nicer, yes.
[00:13] <cjwatson> maybe better:
[00:13] <cjwatson> $ python3 -c 'print(b"\xc2\xb0".decode("utf-8"))' | cat
[00:13] <cjwatson> °
[00:14] <kees> yeah, I tacked on "| cat" just to be sure :)
[00:14] <cjwatson> either of those is a bytes->str conversion
[00:14] <cjwatson> yeah, I realised I'd forgotten that ...
[00:45] <jono> ScottK, around?
[04:33] <NCommander> dyfet: I've linked you to the patch multiple times already.
[06:00] <Obsidian1723> anyone here know about packaging deb files? I'm in the process of reading https://wiki.ubuntu.com/PackagingGuide/Complete but this is more of a question of, "is this the best way to do it?" than anything else. I want to find the best way to distribute images for wallpapers, fonts, document files, and also an install-setup.sh for setting up new installs. Basically the idea is to do a new Ubuntu install, add the PPA, update it
[06:00] <Obsidian1723> and then the file downloads and does all of the work. Is this the best way to do that? One issue that may arise is the shell script does reqire some user input to it. Forgive me. I am not a programmer, new to packaging, etc. Just want some feedback on my method really. Right now I have an alternaitve Ubuntu ISO with a kickstart file that does a wget to.dropbox.com -O- | sh and it works, but it's crude.
[07:51] <pitti> Good morning
[07:53] <diwic> Good morning pitti
[08:04] <dholbach> good morning
[08:05] <diwic> Good morning dholbach
[08:05] <dholbach> hey diwic
[08:57] <pitti> mr_pouit: do you know if/when it is planned to merge the xrandr-display-settings branch into xfce4-settings trunk?
[09:08] <soren> Does anyone happen to know why python-sphinx 1.x is in experimental (rather than unstable/testing)?
[09:09] <tumbleweed> soren: because it'll break some existing documentation
[09:10] <soren> tumbleweed: And how will that ever be addressed?
[09:12] <soren> tumbleweed: I mean, what's the motivation for people to update their docs?
[09:12] <tumbleweed> soren: I don't know all the details, but I remember on the first experimental upload, a test was done and bugs were filed (in other packages, and in sphinx)
[09:13] <soren> tumbleweed: Ok.
[09:13] <tumbleweed> I assume it's now too late to get it into squeeze (even if it is ready, no idea), so it'll stay in experimental until squeeze is out the door
[09:16] <soren> tumbleweed: Yeah. Hmm..
[09:17] <soren> tumbleweed: Well, thanks.
[09:18] <doko> soren: write a FFe for maverick?
[09:21] <mr_pouit> pitti: no date yet (I'm waiting for another dev to do the ui, and there are some bugs I have to fix, but neither the other dev nor me had the time for that since july...)
[09:21] <tumbleweed> soren: found them: http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-modules-team@lists.alioth.debian.org;tag=sphinx1.0%2bdocutils0.7
[09:21] <pitti> mr_pouit: ok, thanks
[09:57] <smb> cjwatson, pitti Would it be possible to get Jaunty, Karmic and Lucid packages accepted into proposed? Also for Lucid all kernels package (and the previous upload) have gone into NEW. Maybe someone can refresh my memory why that is happening. The -24.40 version are superseded by -24.42 anyway. For hardy one of the uploads can also be removed. Maybe the other one as well. We are working on some issues there and need to re-upload anyways.
[09:58] <pitti> I'm NEWing the lucid binaries now
[10:00] <smb> pitti, Thanks. Just the newer ones. The older could go.
[10:00] <pitti> yep
[10:01] <pitti> smb: rejected the hardy uploads
[10:02] <pitti> smb: I didn't accept the jaunty one, since I have a question in bug 611471 which didn't get an answer yet
[10:02] <smb> I guess that binaries always went into NEW and I just forgot about that for some reason. Ok. Note the lbm upload will need the meta update when it finishes as we added some meta packages
[10:02] <smb> pitti, Ok, looking
[10:03] <pitti> smb: same question applies to karmic, but there the kernel fixes other things, too, so we wouldn't do an entire kernel upload for such an unimportant issue
[10:05] <smb> pitti, OK, well did that because this applied to all kernels since whatever and can cause problems when unloading the module. Its probably arguable whether its important. It was more of a finding that this part was accidentally dropped and all releases can get the same fix.
[10:07] <pitti> smb: unloading a module is a rather uncommon action, too, and I don't see why this bug is important for SRU, TBH
[10:08] <pitti> smb: for karmic it's probalby okay because it also fixes other things, but jaunty changes just that
[10:10] <smb> pitti, OK, that is arguable. I was more approaching this from a having the same code if possible point of view. But given that Jaunty is going away soon, I could live with it being rejected.
[10:11] <pitti> lucid/NEW is empty now
[10:11] <smb> I would add an answer to your question then you could reply to that and we then should fix up the nominations
[10:14] <pitti> smb: already done
[10:14] <pitti> smb: btw, this isn't fixed in maverick yet either?
[10:14] <smb> pitti, It should be by now. I guess I need to go over the status bits
[10:14] <pitti> thanks
[10:15] <smb> pitti, So just to summarize I will accept nominations for Hardy, Karmic. Reject it for Jaunty and set Maverick to released after checking
[10:16] <pitti> smb: nominations are already done; thanks for fixing the maverick state
[10:17] <smb> pitti, Doh! LP is such a useful tool for distributed working. Wasn't seeing anything you did before manually refreshing... :-P
[10:23] <pitti> smb: karmic kernels accepted; I'll watch the karmic/NEW queue this time
[10:24] <smb> pitti, Ok, thanks a lot
[10:26] <pitti> doko: thanks for the OO.o upload!
[12:16] <ogra> Keybuk, !
[12:16] <ogra> good to have you back !
[12:17] <Keybuk> ogra: shush, you'll jinx it
[12:17] <ogra> heh
[12:17] <Keybuk> the engineer has replaced just about my entire telephone line, and the equipment at both my house and the exchange
[12:18] <ogra> well, then it *has* to work now
[12:19] <Keybuk> heh
[12:19] <Keybuk> well, it has come up at 4Mb rather than 2Mb
[12:26] <Keybuk> well, it's been up for 10 minutes now
[12:26] <Keybuk> that's pretty much a new record
[12:26] <Keybuk> the novelty will wear off in a minute and I'll go back to being emacs's bitch
[12:28] <ogra> heh
[12:29] <ogra> Keybuk, if you prefer to not touch emacs yet you could take a look at bug 600359 :)
[12:29] <ogra> (there is a patch attached)
[12:29]  * ogra didnt want to upload that without a review
[12:30] <zyga> should  udisks-tcp-bridge be available in udisks package?
[12:31] <zyga> Attempting to use palimpsest on a remote host fails with a message saying that it failed to launch this command on the far side
[12:32] <zyga> please disregard my question, found bug 568926
[12:33] <Keybuk> ogra: yeah just got robbie's mail
[12:33] <Keybuk> what does the patch do?
[12:33] <ogra> prevent ureadahed from starting on systems that dont have enough ram to hold the cache
[12:34] <Keybuk> I can't see the patch
[12:34] <Keybuk> what's the problem?
[12:34] <ogra> there is a linked branch
[12:34] <Keybuk> the OOM killer should take out ureadahead right?
[12:34] <ogra> right, it does
[12:34] <ogra> and it tears down plymouth with it
[12:34] <Keybuk> right
[12:34] <Keybuk> so there's no problem
[12:34] <Keybuk> why does it take out plymouth?!
[12:34] <ogra> no idea
[12:35] <ogra> the systems that runs on have only 128-256M
[12:35] <Keybuk> so?
[12:35] <Keybuk> ureadahead operates on the page cache
[12:36] <Keybuk> it shouldn't cause any blocks to be mapped that weren't otherwise already there
[12:36] <ogra> i have also seen "no space left on device" messages from udev in that case btw, it seems to fill the ram until OOM kicks in but doesnt clear up the used "diskspace" in the tmpfs
[12:36] <Keybuk> unless it OOMs in tracing mode, in which case "ram to hold the cache" is irrelevant
[12:36] <cnd> pitti, you took a look at the utouch MIR requests and everything looked right to you, but I see that utouch-grail still is uploaded to universe: https://launchpad.net/ubuntu/+source/utouch-grail
[12:36] <Keybuk> ureadahead doesn't use any space in tmpfs
[12:36] <ogra> hmm
[12:36] <cnd> pitti, utouch-grail is now a dependency of xserver-xorg-input-evdev
[12:36] <cnd> pitti, is there something else we need to do?
[12:37] <Keybuk> I suspect you're not seeing anything different to the bug Tim recently uploaded a fix for
[12:37] <Keybuk> that ureadahead uses a stupidly large tracing buffer that's per-cpu
[12:38] <ogra> Keybuk, well, in any case it would be nice to not have OOM messages in dmesg on released images, what rsalveti added is just a way to prevent it from starting completely on low ram systems
[12:38] <ogra> and we already use tims fix
[12:38] <ogra> it helps on systems above 512M but apparently not below
[12:39] <Keybuk> ureadahead should still be started on low ram systems
[12:39] <ogra> might indeed be an arm or even specifically omap thing
[12:39] <Keybuk> it's not putting anything into ram that wasn't already there
[12:39] <ogra> why ? if it definitely hits OOM anyway
[12:40] <ogra> it adds uglyness to dmesg i wouldnt like to expose in released images
[12:40] <Keybuk> as I said, I suspect that's just due to the tracing buffer
[12:40] <Keybuk> released images are months away yet
[12:40] <ogra> heh, indeed
[12:40] <Keybuk> I have a complete ureadahead rewrite coming this week/early next
[12:40] <ogra> oh, ok
[12:40] <Keybuk> which uses a dynamic tracing buffer, so *that* particular problem goes away
[12:40] <ogra> we'll wait for that one then
[12:40] <Keybuk> and I don't see any evidence you're having anything other than the tracing buffer OOM
[12:41] <ogra> [    5.705688] Out of memory: kill process 180 (plymouthd) score 96 or a child
[12:41] <ogra> [    5.711944] Killed process 180 (plymouthd) vsz:6200kB, anon-rss:3836kB, file-rss:720kB
[12:41] <ogra> [    5.851837] init invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0
[12:41] <ogra> (from the dmesg in the bug)
[12:41] <ogra> does that deserve a separate bug ?
[12:41] <cjwatson> perhaps we should be oom-adjusting plymouth
[12:42] <Keybuk> actually we should probably oom-adjust ureadahead in the opposite direction
[12:42] <Keybuk> in a "OMG! PLEASE KILL ME!" kind of way
[12:42] <cjwatson> yes
[12:42] <ogra> yeah
[12:43] <Keybuk> would certainly be worth trying that patch
[12:43] <Keybuk> stick "oom 14" in the ureadahead.conf
[12:43] <Keybuk> and see what gets killed that time
[12:45]  * ogra doubts the first sentence you wrote in your comment ... 
[12:45] <Keybuk> why?
[12:45] <ogra> ureadahead doesnt do any good things on SD rootfs, it usually just exits directly anyway
[12:45] <Keybuk> if the OOM killer is taking out ureadahead when it's in read mode, it's still put stuff in the page cache
[12:45] <Keybuk> so it's still had *some* benefit
[12:45] <ogra> well, it *did* exit in lucid
[12:45] <Keybuk> er, it shouldn't?  what filesystem are you using?
[12:45] <ogra> ext3 on SD card
[12:46] <Keybuk> I don't know of anythiing about an SD card that would prevent ureadahead from running
[12:46] <ogra> and i think it used to exit 5 in that setup before
[12:46] <ogra> the OOM only started showing up in maverick
[12:51] <bilalakhtar> cjwatson: What happened in the discussion about better DMB meeting times?
[12:58] <ari-tczew> cjwatson: do you know about it? https://launchpad.net/ubuntu/+source/freej/+changelog - FTBFS
[13:01] <cjwatson> ari-tczew: yes but I wasn't able to fix it
[13:01] <cjwatson> bilalakhtar: nothing yet
[13:01] <bilalakhtar> ok thanks cjwatson !
[13:02] <cjwatson> ari-tczew: if you want to figure it out, please be my guest :)
[13:03] <ari-tczew> cjwatson: my question is whether did you tried to build before sync?
[13:05] <cjwatson> can't remember
[13:08] <pitti> cnd: hm, I don't see any utouch* on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
[13:09] <pitti> cnd: are you sure it's a dependency of a main package?
[13:09] <cnd> pitti, it may not be yet
[13:09] <cnd> pitti, not until xserver-xorg-input-evdev is built with the deps
[13:10] <cnd> pitti, I just want to be sure everything looks ok right now
[13:10] <pitti> cnd: anyway, I'll promote the lot now
[13:10] <cnd> pitti, ok, mtdev, utouch-grail are the two that should be promoted right now
[13:10] <cnd> utouch-gesturetest isn't a dependency of anything in main yet
[13:11] <pitti> cnd: promoted those and -gesturetest
[13:11] <pitti> cnd: if it doesn't become one, someone will at some point demote it back to universe
[13:11] <cnd> pitti, ok, that's fine too :)
[13:11] <pitti> (it's part of archive admin cleanup)
[13:11] <cnd> pitti, thanks a bunch!
[13:14] <pitti> cnd: no problem
[13:20] <nullslash> Hello, Does anyone know how is mbr loads stage1.5 with out having  file system driver ?
[13:23] <dmb> probably magic, thats my guess
[13:26] <cjwatson> nullslash: normally, it's embedded between the MBR and the first partition, outside a filesystem
[13:26] <cjwatson> (stage1.5 is dead, use grub2 ...)
[13:27] <cjwatson> nullslash: the location is encoded as a blocklist
[13:27] <nullslash> hmm
[13:27] <nullslash> thanks cjohnston
[13:54] <jibel> pitti,  wxwidgets2.8 2.8.10.1-0ubuntu1.2 has been published to lucid-updates. but that version breaks pgadmin3, codelite and poedit with a relocation error
[13:55] <pitti> jibel: urgh - it just removes a binary from the .deb?
[13:56] <pitti> jibel: so we need no-change rebuildls for those three?
[13:56] <jibel> pitti, bug 610975, yes a no-op rebuild will do.
[13:56] <pitti> jibel: any idea how a mere rebuild of the package caused that abi change?
[13:57] <pitti> jibel: so, want me to upload no-change rebuilds for those?
[13:58] <jibel> pitti, the details are on  the debian bug 540060
[13:59] <jibel> pitti,  yes a no-change rebuild would fix it. The problem exists in maverick too.
[13:59] <pitti> ah, binutils
[14:01] <pitti> jibel: codelite and pgadmin3 have newer versions in maverick, though; they are still affected?
[14:03] <pitti> jibel: sorry, this completely slipped my attention; seems ubuntu-sru didn't get subscribed to that one, done now
[14:04] <jibel> pitti, I tried a few days ago, give me 1 mn
[14:04] <jibel> pitti, it's fixed for codelite and pgadmin. only poedit is affected.
[14:05] <pitti> jibel: ah, good; I'll upload that to maverick, too
[14:05] <pitti> jibel: would you mind closing the maverick tasks of those, if you tested them?
[14:05] <jibel> pitti, sure.
[14:11] <ttx> pitti, jibel: not sure pgadmin3 is already fixed, see bug 610975
[14:12] <jibel> ttx, I can't reproduce it anymore with an up to date maverick. Are you ?
[14:13] <ttx> jibel: hmm, I was confused between lucid/maverick I guess
[14:13] <micu> If there is a version X and I want to provide a package in my ppa that supersedes version X, but not sth. newer, I can name it Xppa1, right? But if I want to provide a newer package than a package in *another ppa* that does supersede this package but not a newer pacakge from this PPA → how would I do that?
[14:13] <ttx> jibel: still affects lucid, supposedly fixed in Maverick
[14:13] <micu>  I tried naming it ppa5micu1
[14:13] <micu> does this work?
[14:13] <pitti> micu: you can use arbitrarily long versions, so yes; depends on what the version in "another ppa" is
[14:14] <micu> pitti: ok thx. so the whole version is read from the left to the right ignoring the strings?
[14:14] <sladen> micu: what are the versions you want to supersede, and to keep?
[14:15] <pitti> micu: nothing is ignored; it's sorted asciibetically roughly, with - and ~ being special cased
[14:15] <ttx> jibel: since wxwidgets2.8 is now in lucid-updates, I guess we should push noop rebuilds in lucid-proposed now
[14:15] <pitti> ttx: already at it
[14:15] <sladen> micu: http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[14:15] <jibel> ttx: see discussion above with pitti.
[14:15] <ttx> pitti: ok cool, haven't done it before because I wasn't sure that wxwidgets2.8 would get accepted
[14:16] <micu> sladen: 4:4.7.0~beta2-0ubuntu3~lucid1~ppa5 is it and I want to supersede it, but not if they provide some newer versions
[14:16] <ttx> based on that "regression"
[14:16] <free> pitti: hey, I've seen you've tagged the landscape-client SRU bugs as "verification-done" and removed "verification-needed", in the future is it something we can/should do ourselves?
[14:16] <micu> sladen: thanks, I was searching for some document like this
[14:17] <micu> pitti: ok, great, thx
[14:17] <pitti> free: once you tested the .deb in proposed, please do
[14:17] <free> pitti: cool, will remember for the next round
[14:17] <pitti> free: as for "should", you aren't required/expected to, but of course it makes my life easier :)
[14:17] <free> pitti: sure, that's was one of the goals indeed :)
[14:18] <free> pitti: btw, I believe the packages are ready to be moved to -updates, is there anything else left for that?
[14:18] <pitti> free: nothign except one more day; then they have reached 7 days in proposed
[14:18] <pitti> thus I'll move them over tomorrow
[14:18] <free> pitti: awesome, tnx!
[14:19] <pitti> thanks to you, too
[14:20] <pitti> jibel: all done and accepted, thanks for pointing out
[14:22] <jibel> pitti, you're welcome
[14:46] <Adri2000> pitti: bug #569365, do you have an opinion on what Johan says?
[15:45] <superm1> pitti, cjwatson, unfortunately the hash sum mismatches are happening again, 2 days in a row now. http://people.canonical.com/~ubuntu-archive/cd-build-logs/mythbuntu/maverick/daily-live-20100824.log
[16:07] <pitti> chrisccoulson, kees: so perhaps you can follow up to https://lists.ubuntu.com/archives/technical-board/2010-August/000459.html about whether it's feasible to backport security patches for chromium?
[16:08] <pitti> Adri2000: looking
[16:09] <kees> pitti: sure; it's not feasible. easy response. :)
[16:09] <pitti> kees: .. for the records :)
[16:10] <pitti> kees: it eases the decision, it might just be that rickspencer3 et al might not like it :)
[16:10] <rickspencer3> kees, why is it not feasible?
[16:11] <kirkland> pgraner: ping
[16:12] <kirkland> pgraner: i think you were affected by https://bugs.edge.launchpad.net/ubuntu/+source/screen/+bug/574773 at some point ...
[16:12] <kirkland> pgraner: would you mind verifying that screen works correctly for you now on reboot, and adding a message to that bug?
[16:12] <pgraner> kirkland, will do, will take a few
[16:12] <kirkland> pgraner: ack, thanks so much
[16:15] <pitti> Adri2000: followed up
[16:15] <pitti> superm1: do we actually know whether they are due to mirror updates?
[16:15] <superm1> pitti, i'm not sure how to query that?
[16:16] <pitti> superm1: just whether someone has looked at it before and determined it to be a mirror update problem
[16:16] <superm1> i've always heard it thrown around by slangasek and cjwatson as a locking problem
[16:16] <pitti> or whether it was just a guess
[16:16] <pitti> superm1: Colin fixed a locking problem the other day
[16:16] <pitti> I think last week, for 10.04.1
[16:16] <Adri2000> pitti: thanks
[16:16] <superm1> i think one of them will have to comment if they've investigated it further
[16:17] <pitti> but that was before your latest failure
[16:17] <superm1> yeah, there was a successful build on 8-22
[16:18] <pitti> smb: karmic kernels NEWed, FYI
[16:18] <smb> ok thanks
[16:20] <kees> rickspencer3: it's not feasible to backport individual security fixes from chromium because the chromium maintainer says so. :)
[16:20] <rickspencer3> fair enough
[16:22] <chrisccoulson> yeah, it would be far too much work (and too risky) for us to consider backporting security fixes ourselves
[16:23] <chrisccoulson> and doing that for nearly 3 years of a LTS leaves us pretty much on our own if there are any issues with our packages
[16:23] <pitti> also, given how brittle chromium still is these days, we also do want bug fixes
[16:24] <pitti> it's amazing how often it "aw, snap"s :-(
[16:26] <jdstrand> pitti: yeah I know what you mean. I was developing an apparmor profile for it (now in apparmor-profiles), so I felt kind of obligated to use it for awhile. It felt like several steps backwards
[16:26] <chrisccoulson> i use several browsers all at the same time now
[16:27] <chrisccoulson> it's quite difficult splitting my browsing experience between multiple browsers ;)
[16:27] <jdstrand> yeah, it was hard enough with the two for the short while I did it
[16:28] <chrisccoulson> this ptrace restriction is a real pain for breakpad ;)
[16:29] <jdstrand> chrisccoulson: I assume you talked to kees about it?
[16:29] <chrisccoulson> jdstrand, yeah. i'm doing the prctl call in the parent (which makes it work), but that is inherently racy
[16:30] <chrisccoulson> in that there is nothing to stop the debugger calling ptrace before the parent calls prctl
[16:30] <chrisccoulson> and trying to get threads running in signal handler-context of a crashed process to synchronize is a pain
[16:33] <MrQuincle> I have a kind of general question. How many of the maintainers of Ubuntu packages are actually also maintaining the Debian ones?
[16:33] <ScottK> !regression-alert wxwidgets2.8 Bug #379573
[16:33] <kees> chrisccoulson: if the ptrace fails, just wait a second and try again
[16:33] <ScottK> !regression-alert
[16:34] <ScottK> I don't think it merits a blacklist, but according to the discussion in Bug #379573, there is a regression.
[16:34] <kees> ScottK: I'm about to get on a plane, so I'll have to defer to others
[16:34]  * ScottK doesn't know more than what's in the bug.
[16:35]  * ScottK is about to have to go offline for $WORK meetings, so passes it on.
[16:35] <dmart> Keybuk: hi there, do you have a moment to chat about bootchart?
[16:39] <seb128> ScottK, there was 3 uploads from pitti earlier today to lucid-proposed for that no?
[16:39] <seb128> "
[16:39] <seb128>   * No-change upload to rebuild against current wxwidgets2.8, which
[16:39] <seb128>     involuntarily changed ABI due to a binutils change (see Debian #540060
[16:39] <seb128>     for details). (LP: #610975)"
[16:39] <mdz> ScottK, is the regression https://bugs.edge.launchpad.net/ubuntu/+source/pgadmin3/+bug/610975 ?
[16:40] <ScottK> seb128: It's not clear to me from the bug.
[16:40] <mdz> it looks that way to me
[16:40] <ScottK> I read the last comment in the bug as "it's a regression, but we'll fix it soon so it doesn't need reporting".  That doesn't match my understanding of how it's supposed to work.
[16:44] <ttx> ScottK: IMHO it should not have reached lucid-updates based on comment 10 and 13 in https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/379573 ... but now that it has, we are closer to the fix with the noop rebuilds than by pulling the package of -updates, methinks
[16:44] <ScottK> ttx: Sounds reasonable.
[16:47] <ttx> it all boils down to comment 14 on that bug. If it regresses, it shouldn't have been tagged verification-done. At the very least we should have coordinated the noop rebuilds in -proposed and -updates
[16:49] <ScottK> ttx: It sounds to me like you're in the best position to prepare an incident report around this so we can improve in the future.
[16:50] <ScottK> pitti: I also think the rebuilds should be rescored so they get built quickly and a priority for verification.
[16:50] <ttx> ScottK: I can coordinate that with jibel, I think
[16:51] <ScottK> ttx: Great.
[17:02] <pitti> ScottK: they are all built; pgadmin3/i386 and codelite/i386 still waiting for a publisher, so it should be available in about an hour
[17:02] <ScottK> Cool.
[17:02] <pitti> I'll move them to -updates as soon as they get confirmation that they work
[17:09] <pitti> jibel/ttx: are you in a good position to give the -proposed .debs a try?
[17:09] <pitti> (you can download them from the LP build page if you need the i386 pgadmine/codelite ones; amd64 should be published for all three)
[17:09] <jibel> pitti, just finished a conf call, I'm on it.
[17:09] <ttx> pitti: not really, I'm away for the next hours
[17:10] <pitti> jibel: rock, thank you
[17:10] <jibel> ttx, I'll take care of that.
[17:10] <pitti> ttx: no worries, thanks
[17:10] <ttx> jibel: of the incident report ?
[17:12] <jibel> ttx, testing the debs.
[17:12] <ttx> jibel: ok :)
[17:13]  * ttx will be back in ~2 hours
[17:13] <jibel> ttx, nice try ;)
[17:21] <jibel> pitti, I tested poedit from -proposed and codelite and pgadmin3 downloaded from LP and they run fine.
[17:21] <jibel> pitti, is there a way to find any potentially affected packages ?
[17:39] <pitti> jibel: I think "apt-cache rdepends libwxbase2.8-0" should be an upper bound
[17:39] <pitti> jibel: thanks a lot for testing, I'll move them to -updates
[17:43] <jibel> pitti, thank you. have a nice evening.
[17:43] <savid> Hi, I'm making a python daemon that I would like to have an indicator icon for.  Ie, when the daemon is running, it should show the indicator icon.   My daemon simply uses a python loop for its main loop.  What I've seen from experimenting is that the indicator only shows when I use gtk.main(). Is there any way around this?
[17:45] <ev> savid: please ask such questions in #ubuntu-app-devel .  You need to be able to process GTK events to use an indicator, so no, you'll have to use the GTK main loop.
[17:46] <canesin> Hi all... I need some legal advices.. can someone help me ??
[17:46] <savid> ev,  ok, thanks
[17:47] <ev> sure thing
[17:48] <ev> savid: mind you, you can always separate the indicator code into a child process.
[17:52] <glickster> hey can anyone recommend a single symetrical encryption program for linux? where i can just use a password to encrypt a single file?
[17:53] <glickster> something integrated in ubuntu would be nice
[17:53] <pitti> glickster: gnupg does that in the -c mode
[17:53] <pitti> i. e. "gpg -c file"
[17:54] <glickster> oh sweet
[17:54] <glickster> pitti, what cipher does it use?
[17:54] <pitti> but the nautilus integration only works with public/private keys, not symmetric
[17:55] <pitti> glickster: docs say CAST5, but you can choose it with --cipher-algo
[17:55] <pitti> glickster: i. e. you could use --cipher-algo AES if you care
[17:56] <canesin> Hi all... I need some legal advices.. can someone help me ??
[17:56] <pitti> canesin: not quite the right place here, I'm afraid
[17:56] <glickster> i played a lawyer in a play once
[17:56] <pitti> canesin: but otherwise, please just ask a question, don't ask to ask
[17:57] <glickster> as long as she was over 18 you should be ok
[17:57] <glickster> just dont talk to the police
[17:57]  * pitti just thinks seriousness level considerably dropped in this channel
[17:58] <pitti> canesin: some people here have a rather good udnerstanding about FOSS software licensing, but for anything else this is the wrong place, I'm afraid
[18:03] <canesin> pitti: So.. I want to fork a GPLv3 .. and don't know what references to the original project I should keep
[18:03] <canesin> pitti: the project is GPL v3 and my project is GPL v3 also...
[18:04] <canesin> at the moment I have only clicked in the "fork" bottom at github
[18:04] <pitti> canesin: you mustn't remove any existing license header, copyright statement, and license files; otherwise you are free to change anything
[18:05] <pitti> well, if you entirely remove a file, removing its copyright statements as well is fine, obviously
[18:06] <canesin> rigth ... so if I edit a file, I should not change it header ?? Or I can add an "note" about it beeing modified ?
[18:08] <pitti> canesin: sure (and in fact it's even encouraged in some part of the license IIRC)
[18:08] <pitti> canesin: you just mustn't remove the existing copyright and pretend that it's all your's :)
[18:18] <cjwatson> GPLv2 required placing notices in any modified files stating that you changed the files and giving the date.  This was often ignored, so GPLv3 merely says that the "work" must carry such notices - so a changelog file is fine
[18:19] <cjwatson> GPLv3 section 5 is pretty clear really
[18:19] <cjwatson> and is mostly what conscientious people were doing anyway
[18:20] <pitti> I couldn't imagine touching any code without a VCS these days
[18:27] <canesin> okay.. so I keep everything as it is and only append/add to change log mine modifications
[18:27] <canesin> ??
[18:29] <canesin> I will use a VCS, I'm using github on it
[18:31] <pitti> canesin: yup
[18:33] <canesin> pitti: ok, so it is easy at all.. Was just scaried ..
[18:33] <canesin> pitti: the company who develops the original code is a little evil .. but they release it as GPL v3 ..  =)
[18:36] <smoser> cjwatson, are you around ?
[18:36] <dobey> eh, everyone is evil :)
[18:36] <dobey> hey pitti :)
[18:36] <cjwatson> smoser: hi
[18:37] <smoser> i'm trying to deal with some grub issues in my uec images.
[18:37] <smoser> during build, i trick update-grub into thinking that it successfully installs onto /dev/sda.
[18:37] <smoser> the instance may come up in 1 of 3 environments
[18:37] <smoser> a.) ec2, where there is no /dev/sda device
[18:38] <smoser> b.) uec where /dev/sda is there and subsequent grub-install will work fine
[18:38] <smoser> c.) uec where /dev/sda is not there, but /dev/vda is
[18:38] <cjwatson> update-grub doesn't install to anything.  I suspect you mean grub-install
[18:38] <smoser> ok, yeah.
[18:39] <dobey> hrmm, if i change the names of some binary packages (in a PPA), and replace/conflict the old names, will apt know to pull the new names to update? i'm a little confused on how that works exactly.
[18:39] <smoser> one way or another, right now, if I have 'update-grub' set to run on kernel install, it will fail on ec2.
[18:42] <cjwatson> smoser: because it fails to probe /?
[18:43] <smoser> /usr/sbin/grub-probe: error: cannot find a GRUB drive for /dev/sda1.  Check your device.map.
[18:43] <smoser> is what i get right now
[18:43] <smoser> just running it.
[18:43] <cjwatson> is that /?
[18:43] <smoser> yes
[18:43] <cjwatson> so why would it think that / is /dev/sda1?
[18:44] <smoser> because it is.
[18:44] <smoser> ah.
[18:44] <smoser> i confused you
[18:44] <smoser> there is no /dev/sda
[18:44] <smoser> there is a /dev/sda1
[18:44] <cjwatson> blink
[18:44] <smoser> (ie, in /dev/ or /proc/partitions )
[18:44] <cjwatson> this is going to be hard to debug over IRC, the channel is too narrow for the amount of information that needs to be conveyed or something
[18:45] <cjwatson> a good clear bug report would be better :)
[18:46] <smoser> cjwatson, ok. i'll get one put together.
[18:46] <smoser> i fear it will be long winded-ish, though.
[18:46] <cjwatson> that's ok
[18:49] <azeem> i/W 26
[19:19] <kirkland> ev: ping
[19:22] <bilalakhtar> Can someone get https://edge.launchpad.net/ubuntu/+source/gpsdrive/2.10~pre4-6.dfsg-5ubuntu1/+build/1899805 rebuilt?
[19:25] <Laney> have you confirmed it builds?
[19:29]  * Laney mashes the button anyway
[19:41] <ari-tczew> Laney: does it require a new revision like -ubuntu2?
[19:41] <Laney> not for a give back
[19:41] <Laney> that means there was never a binary for this (arch, version)
[20:01] <hallyn> pitti: cjwatson: hey guys, i'm having a problem with multipath booting, and you are the last two to touch the changelog, so I'm hoping you have an idea for the right place to solve it :)
[20:01] <jaminc> anyone here notice that the server and desktop installs generate different group IDs for the same groups and a conflicting user ID?
[20:01] <hallyn> basically, if the kernel gets a 'root=UUID=xyz' boot option, the initramfs init tries to mount /dev/disk/by-uuid/xyz
[20:02] <hallyn> if that happens early enough, then /dev/disk/by-uuid/xyz points to /dev/sda.  Late enough, and it points to /dev/mapper/abc.  But in between, it still points to /dev/sda1, but /dev/sda1 has been taken by multipath - the links have just not yet been updated - so the rootfs mount attempt fails
[20:02] <pitti> hallyn: I have no clue about multipath, but I reasonably know the "normal" boot
[20:03] <hallyn> my naive thought would be that i need to synchronize between hotplug/udev and the mount_root attempt at init.  But I don't know what would be a clean way
[20:03] <kiko> pgraner, do you know the status of the 2.6.35 kernel coming in from TI?
[20:06] <pgraner> kiko, haven't heard anything davidm should know
[20:34] <ttx> pitti, jibel, ScottK: see https://wiki.ubuntu.com/IncidentReports/2010-08-24-wxwidgets2.8-SRU-breaks-other-packages -- feel free to fix/complete/suggest other recommendations
[21:47] <smoser> cjwatson, i opened bug 623609
[22:15] <cnd> seb128, thanks for uploading utouch-geis
[22:15] <cnd> do you have a minute for a quick question about it?
[22:15] <seb128> cnd, np
[22:15] <seb128> sure
[22:16] <cnd> seb128, so I added a runtime package depends for libutouch-geis1 on libutouch-grail1 (>= 1.0.10) in because geis of the api/abi change
[22:16] <cnd> is there a different method you would use?
[22:16] <seb128> well if the api changes the libutouch-grail1 shlibs or .symbols should reflect that
[22:16] <cnd> ahhh, ok
[22:16] <seb128> I would update the libutouch-grail1 .shlibs or .symbols
[22:16] <seb128> so the libutouch-geis1 would get the right version
[22:16] <cnd> yeah, at first your comment didn't make sense to me
[22:16] <cnd> but it just clicked
[22:17] <cnd> our .symbols file for grail should be correct, so my addition was likely superfluous
[22:17] <seb128> right
[22:17] <cnd> and I'm not sure how that automatic debian packaging patch snuck in there
[22:17] <seb128> the point of having those .symbols is not to have to deal with those depends manually
[22:17] <cnd> I'll make sure to fix both issues for the next upload
[22:18] <seb128> ${shlibs:Depends} will build the depends list based on the symbol you use
[22:18] <cnd> yeah
[22:18] <seb128> it will check what other lib and version provides thoe
[22:18] <seb128> those
[22:18] <seb128> cnd, thanks
[22:18] <cnd> I get all the parts, I just don't remember all of them all the time yet
[22:18] <cnd> :)
[22:18] <seb128> ;-)
[22:19] <seb128> cnd, sorry if the comments were a bit short
[22:19] <seb128> cnd, the other issues is that this autogenerated debian patch is diff done inline
[22:19] <cnd> seb128, no, I think they were good, I just didn't put two and two together
[22:19] <seb128> so either you didn't have a clean source or you just want that renamed to be a proper patch
[22:19] <cnd> yeah
[22:19] <cnd> likely it's not a clean source
[22:20] <cnd> have you noticed that bzr clean-tree doesn't get rid of .o files on maverick?
[22:20] <cnd> fun times...
[22:20] <seb128> where would be the fun to use an unstable version if there was no bug ;-)
[22:21] <cnd> yeah...