[04:18] <pitti> Good morning
[05:13] <ion> Hi
[06:46] <dholbach> good morning
[07:59] <ev> @pilot in
[08:17] <lifeless> ok, I have an offtopic q; what would cause setgid(1000) to fail in a process I just ran as sudo process; my uid being 1000, and the process is a fuse file system provider
[08:17] <lifeless> pointers etc appreciated
[08:17] <lifeless> EPERM is the error
[08:17] <pitti> was just going to ask, but man setgid() actually lists that as only possible error
[08:18] <pitti> lifeless: do you get an AppArmor violation in dmesg by any chance?
[08:18] <lifeless> its being called from the pre_exec hook of a subprocess call
[08:18] <lifeless> checking
[08:18] <lifeless> [1021271.432495] iwlwifi 0000:02:00.0: Tx aggregation enabled on ra = 94:44:52:a8:40:2f tid = 0
[08:18] <lifeless> [1021547.963081] iwlwifi 0000:02:00.0: Tx aggregation enabled on ra = 94:44:52:a8:40:2f tid = 6
[08:18] <lifeless> (e.g. no, not AFAICT)
[08:19] <lifeless> pitti: oh, and finally, the subprocess call preexec function does a chroot as its very very first thing
[08:19] <lifeless> so fork; chroot; setgid -> failure
[08:20] <lifeless> its chrooting into the parent processes fuse fs
[08:20] <pitti> lifeless: at the time you do setgid() you have euid==1000?
[08:20] <pitti> or euid==0?
[08:20] <lifeless> I sure hope so, let me instrument
[08:20] <lifeless> (the chroot works, so I have been assuming that)
[08:20] <pitti> if you are not root, i. e. euid=1000, then in the chroot the uid 1000 might not be in group 1000, or there is no group 1000 in /etc/groups or something like that?
[08:21] <lifeless> one possibility is that /etc/groups isn't in the chroot
[08:22] <pitti> lifeless: so printing out euid, uid, egid, and gid is useful; if that looks alright, then maybe print capget()
[08:22] <ogra_> if it is its very unlikely to contain 1000
[08:22] <pitti> that shouldn't matter if you are euid=0, but very well might if you are euid=1000
[08:22] <ogra_> yeah
[08:22] <jamespage> doko: the java7 FTBFS bugs will need a retest early in quantal - suspect there will be some new ones as well
[08:23] <lifeless> 0 0 0 0
[08:23] <lifeless> before the chroot
[08:24] <lifeless> will grab after the chroot figures, but I wouldn't expect them to have changed
[08:24] <lifeless> yeah, all 0
[08:26] <pitti> hm, perhaps there is some new YAMA magic or whatever which removes capabilities after chroot()?
[08:26] <sbeattie> I don't think so...
[08:26] <pitti> lifeless: can you compare the output of cap_get_proc() before and after chroot?
[08:26] <pitti> and print it?
[08:26] <lifeless> I'll take the chroot out as an experiment
[08:27] <lifeless> no error without the chroot
[08:27] <pitti> lifeless: in particular, test cap_get_proc() & CAP_SETGID ?
[08:27] <lifeless> what module is cap_get_proc in?
[08:28] <pitti> #include <sys/capability.h>
[08:28] <lifeless> harh
[08:28] <lifeless> (this is python :P)
[08:28] <pitti> oh, hmm; ctypes FTW?
[08:29] <sbeattie> lifeless: paste strace -f output perhaps?
[08:32] <lifeless> python-cap-ng
[08:37] <lifeless> so, cap_to_text() ?
[08:39] <lifeless> hah, python segfault
[08:43] <lifeless> in cap_to_text
[08:46] <angeloc> Hi guys, i'm writing some scripts for ubuntu accomplishments, until now i solved all my problems reading online api documentation, but I'm now in stuck
[08:46] <angeloc> i have to find all packages uploaded by a person, can you suggest me the best way?
[08:47] <diwic> seb128, I was able to resolve part a) of bug 984637, see comment 8
[08:47] <diwic> seb128, and part b) has been resolved by ronoc already
[08:47] <micahg> angeloc: look at this: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
[08:47] <seb128> diwic, great, thanks, I will make sure both are fixed in the SRU
[08:48] <diwic> seb128, thank you
[08:48] <tumbleweed> micahg, angeloc: be aware that ubuntu-sponsorships.cgi is quite slow, please don't hit it too hard
[08:48] <micahg> angeloc: tumbleweed: I wasn't suggesting to use it, but to look at the code behind it (link at the bottom)
[08:48] <tumbleweed> ah
[08:49] <angeloc> tumbleweed, thank you
[08:49] <angeloc> tumbleweed, micahg: ok
[08:50] <micahg> angeloc: although, now that I think about it, would probably want to query Launchpad directly rather than Debian's database
[08:50] <tumbleweed> it gets data from UDD. We have a UDD mirror on ubuntuwire, so if you need to run something server side that accesses UDD, it's doable
[08:51] <angeloc> tumbleweed, micahg: weel yes, i'm using launchpad api for all my needs
[08:51] <angeloc> tumbleweed, micahg: but I cannot find a way to get all packages uploaded by a person
[08:51] <tumbleweed> angeloc: yeah launchpad's API won't help you there
[08:52] <micahg> angeloc: #launchpad or #launchpad-dev would probably be better
[08:52] <angeloc> tumbleweed, micahg: i asked there, but no replies ...
[08:52] <lifeless> win
[08:52] <lifeless> #0  0x00007ffff523d501 in cap_to_text () from /lib/x86_64-linux-gnu/libcap.so.2
[08:52] <lifeless> #1  0x00007ffff545aea4 in ffi_call_unix64 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
[08:52] <lifeless> #2  0x00007ffff545a8c5 in ffi_call () from /usr/lib/python2.7/lib-dynload/_ctypes.so
[08:52] <lifeless> #3  0x00007ffff544b2c2 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so
[08:52] <lifeless> (this works if I do it outside of a worker thread)
[08:53] <lifeless> could libcap be unsafe with threads? seems unlikely. ..
[08:55] <pitti> lifeless: libcap shoudl be thread save, but ctypes might not?
[08:57] <lifeless> http://stackoverflow.com/questions/7024507/am-i-crashing-ctypes-or-libflac seems relvant
[08:57] <lifeless> *relevant*
[08:59] <lifeless> pitti: it claims to be threadsafe
[09:02] <lifeless> pitti: it may be this - http://bugs.python.org/issue11048 - a libffi bug
[09:13] <pitti> lifeless: oh, is your chroot r/o?
[09:14] <lifeless> pitti: it should support writes to /tmp
[09:14] <lifeless> pitti: but its a bit hard to reason about
[09:14] <lifeless> pitti: as its a fuse layer
[09:14] <lifeless> pitti: in the parent process
[09:14] <lifeless> I'm whipping up a cython binding
[09:40] <lifeless> pitti:
[09:40] <lifeless> '=ep'
[09:40] <lifeless> '=ep'
[09:41] <lifeless> before and after the chroot
[09:44] <pitti> lifeless: ok, so it's not that either; I'm afraid that was my last idea what could cause it to EPERM :/
[09:45] <lifeless> does setgid read stuff from the fs ?
[09:45]  * lifeless is willing to assume his fuse layer is buggered ;>
[09:45] <pitti> no, it shouldn't
[09:47] <pitti> ev: wow, haven't seen https://errors.ubuntu.com/ before
[09:47] <ev> pitti: it only went live last/this week :)
[09:47] <lifeless> shiny isn't it
[09:48] <ev> *lots* more to do there
[09:48] <ev> so read it as what it could be, not what it is :)
[09:48] <pitti> yes, sure, but it's the first real ouput I see from whoopsie
[09:49] <lifeless> ev: what does the MTBF mean there?
[09:49] <ev> the mean of the mean time between failures for all users in the system (so only people who have experienced crashes)
[09:49] <pitti> ev: oh, this has public tracebacks?
[09:49] <ev> pitti: they're going behind openid
[09:50] <ev> webops is on it
[09:50] <ev> err Ubuntu SSO
[09:50] <pitti> that pycentral crash looks so trivial to fix
[09:51] <ev> I know, right? :)
[09:52] <ev> pitti, lifeless: ps. we've shovelled 3,868,092 crashes into the database since March 20th
[09:52] <lifeless> sweet
[09:52] <lifeless> what % have been retraced ?
[09:53] <ev> https://errors.ubuntu.com/api/retracer/results
[09:53] <ev> mind, not all crashes get retraced (some are python, and we only ask for one core dump for each stacktrace address signature)
[09:54] <ev> not sure why 10.04 is showing up
[09:54] <ev> it's on my list to look into
[09:54] <hrw> debootstrapping quantal ends with: E: Release signed by unknown key (key id AED4B06F473041FA)
[09:54] <ev> it's going off apport's DistroRelease field
[09:54] <hrw> what is a reason?
[09:55] <dholbach> cking, regarding bug 987840 - my sister has the same model, so if you need some testing, please let me know
[09:55] <lifeless> ev: so a tiny proportion ?
[09:56] <lifeless> assuming that "20120426": {"Ubuntu 10.04:failed": 17, "Ubuntu 10.04:success": 1, "Ubuntu 11.10:failed": 3, "Ubuntu 11.10:success": 8, "Ubuntu 12.04:failed": 864, "Ubuntu 12.04:success": 1812} means what I think it does ?
[09:56] <ev> yes
[09:56] <cking> dholbach, ok, thanks for letting me know
[09:56] <lifeless> ev: how many of that 3.8M are dupes, do you know ?
[09:56] <hrw> nevermind - rebuilt debootstrap with quantal
[09:57] <ev> lifeless: one moment, I'll craft something to count buckets
[09:57] <lifeless> pitti: an alternate approach, is it possible to setuid etc while keeping the capability to chroot ?
[09:57] <pitti> lifeless: yes, there is
[09:58] <pitti> lifeless: don't use setuid(), use setresuid(uid, uid, -1)
[09:58] <pitti> then you can switch back to setresuid(0, 0, -1)
[09:58] <pitti> but of course that only provides protection against programmer errors
[09:58] <pitti> a malicious program can also setresuid back to root
[09:59] <pitti> so in general it's better to fork and setuid() in the child
[09:59] <lifeless> pitti: ah, I mean irreversible setuid, keep the capability to chroot /only/
[09:59] <pitti> lifeless: yes, that works, too
[09:59] <lifeless> pitti: the current does the better thing, but has this little flaw its not working
[09:59] <cjwatson> hrw: That's the Debian signing key, so you were accidentally bootstrapping Debian
[09:59] <lifeless> pitti: so I'm looking for a workaround; keeping root is undesirable
[10:00] <lifeless> pitti: pointers on how to keep the capabilities ?
[10:00] <pitti> lifeless: prctl(PR_SET_KEEPCAPS), setuid()
[10:00] <pitti> lifeless: and the cap_set_proc() and drop all but CAP_SYS_CHROOT
[10:00] <lifeless> thanks; I presume I call a cap_set_proc to drop the caps after the chroot
[10:01] <ev> lifeless: 30525 total problems (with the aforementioned 3.8 million instances)
[10:01] <lifeless> I'm thinking this will let me alter the order of calls
[10:01] <pitti> lifeless: note that with prctl(PR_SET_KEEPCAPS) and setuid() the process still has effectively root privs
[10:01] <lifeless> ev: cool; and the daily thing shows instances, not problems ?
[10:02] <ev> the website shows problems, not instances (until you click through on a crash signature)
[10:02] <lifeless> ev: I meant the counts
[10:02] <pitti> lifeless: and yes, you should drop CAP_SYS_CHROOT right after chrooting, otherwise you can easily escape out of the chroot
[10:02] <ev> something is wrong with the numbers in the table
[10:02] <ev> ah yes
[10:02] <ev> the counts in the table (frequency) should show instances
[10:02] <ev> but they feel wrong at the moment - another thing I'll be looking into
[10:04] <jk-> looks like precise hasn't made it to http://changelogs.ubuntu.com/meta-release-lts yet, is that intentional?
[10:04] <jk-> (it's in /meta-release though)
[10:04] <cjwatson> Yes.
[10:04] <cjwatson> It won't until 12.04.1.
[10:05] <cjwatson> It's in http://changelogs.ubuntu.com/meta-release-lts-development so that do-release-upgrade -d works.
[10:05] <jk-> cjohnston: ok, thanks :)
[10:08] <jk-> sensible plan is sensible.
[10:56] <lifeless> pitti: lolol that works now chroot fails because of denied access to the fs; *that* I can do something about :)
[10:56] <micahg> cjwatson: are you planning on removing the archive enforcement for the xz deb dpkg pre-depends for quantal (or is it already done)?
[10:56] <lifeless> pitti: and this may explain the setgid/setuid failure - if the cwd isn't readable by the new group.
[10:58] <lifeless> pitti: however, that can wait for evil genius saturday
[10:58] <lifeless> after sleeps
[10:58] <lifeless> pitti: thanks for the hand, much appreciated
[11:09] <pitti> lifeless: hm, strange -- setuid() shouldn't care about cwd
[11:15] <tjaalton> jibel: hey, you marked 989525 as dupe of a closed bug, but that's wrong
[11:16] <tjaalton> jibel: since the bug is not the error message of the dupe, but the fact that a package is installed and later dpkg claims it's not
[11:21] <tjaalton> jibel: uh, sorry.. noticed your comment..
[11:22] <tjaalton> jibel: ok so disregard everything I said :)
[11:27] <cjwatson> micahg: At some point yes
[12:20] <cjwatson> micahg: https://code.launchpad.net/~cjwatson/launchpad/remove-data-tar-xz-version-requirement/+merge/103859 FYI
[12:21] <micahg> cjwatson: shouldn't the check stay in place for pre-12.10 stuff? (I'm thinking backports here)
[12:22] <cjwatson> No
[12:22] <cjwatson> We don't generally bother since it's trivial to review and it's painful to make the check act that way in LP
[12:22] <cjwatson> We didn't bother for bzip2
[12:23] <cjwatson> Also, backports don't matter much for lucid->precise upgrades
[12:23] <micahg> I was thinking backporting to lucid :)
[12:23] <cjwatson> DDTT, it'll fail
[12:23] <cjwatson> the check in archiveuploader wasn't for the benefit of people backporting without paying attention, it was solely to ensure sane upgrades
[12:24] <cjwatson> your backports tests should catch wrongness like that already without LP needing to help you
[12:24] <micahg> ok :)
[12:54] <hyperair> weird. it looks like liferea's dbus stuff just screws up every now and then
[12:54] <jdstrand> pitti: hi! would you mind rejecting https://code.launchpad.net/~jtaylor/ubuntu/precise/dropbear/CVE-2012-0920/+merge/103739, https://code.launchpad.net/~jtaylor/ubuntu/oneiric/dropbear/CVE-2012-0920/+merge/103385 and https://code.launchpad.net/~jtaylor/ubuntu/lucid/dropbear/2012-0920/+merge/103384. they are security fixes against the release version, not security (I have uploaded the patches though)
[12:54] <pitti> jdstrand: sure, done
[12:54] <hyperair> first the menu disappears from the unity panel and reappears on the liferea window, then it disappears from the messaging indicator...
[12:55] <jdstrand> pitti: thanks! :)
[13:00] <Laney> cjohnston: Hey, I've got some summit questions if you can help me… What does "Attend this meeting" do? Does it have the same effect on the scheduler as subscribing to the blueprint (what about Participation Essential)? And what is "Propose a meeting"? Is it now an additional step that needs doing after all of the LP blueprint stuff to get stuff on the schedule?
[13:05] <cjohnston> Laney: attend is the same as subscribing to a bp except that if there is a bp you will not get the emails when the bp is changed
[13:05] <cjohnston> I have to look at the code about the essential question.. I didn't write that part
[13:06] <cjohnston> Laney: the blueprints still work the same way
[13:06] <Laney> I'm not sure what effect that has on the scheduler to be honest, but if it does have some then ideally you could set that through summit too.
[13:07] <cjohnston> if you follow the old.way of creating a bp for the meeting, you don't need to worry about proposing a meeting in summit
[13:07] <cjohnston> proposing a meeting in summit would be instead of creating a bp
[13:08] <Laney> ah, another way of proposing meetings without needing a blueprint
[13:08]  * Laney gets it now
[13:08] <Laney> thanks
[13:08] <cjohnston> Laney:  the essential or something else.. I dont understand your comment
[13:08] <Laney> go to subscribe to a blueprint and you will see a "Participation essential" checkbox
[13:09] <Laney> it is my understanding that this has some influence on the scheduler vs. just normally subscribing
[13:09] <Laney> I was suggesting that this should also be possible through the new summit UI
[13:14] <cjohnston> Laney:  ok.. ya.. familiar with that, just wanted to make sure I had context.of the statement right
[13:14] <cjohnston> ty
[13:15] <Laney> np
[13:15] <cjohnston> Laney: I'm talking with mhall119  about it right now
[13:18] <Laney> :-)
[13:50] <ogra_> dholbach, oh, btw i'll be in berlin over the weekend
[13:52] <dholbach> ogra_, nice - when?
[13:52] <ogra_> well, tomorrow afternoon until ...
[13:52] <ogra_> open end :)
[13:52] <dholbach> awesome
[13:53] <s1aden> ogra_: moving?  Or just until UDS?
[13:54] <ogra_> s1aden, just visiting a friend
[14:34] <bjf> @pilot out
[14:40] <tedg> I'm getting an odd behavior when installing packages: http://paste.ubuntu.com/949899/
[14:40] <tedg> Does anyone have a clue on what's going on there?
[14:42] <seb128> tedg, do you use i386 or amd64?
[14:42] <seb128> "/sbin/ldconfig.real: /lib/i386-linux-gnu/ is not a symbolic link" is weird
[14:42] <seb128> I blame infinity :p
[14:42] <tedg> seb128, I use amd64 but have a bunch of i386 packages (I'm not sure why)
[14:42] <seb128> tedg, multiarch?
[14:42] <tedg> Guessing I installed flash or something that pulled them in.
[14:42] <seb128> righ
[14:42] <ogra_> stop cross-grading to redhat !
[14:42] <tedg> Yeah, but I imagine they don't come for fun ;-)
[14:42] <seb128> you can probably to uninstall them and see what it wants to remove
[14:43] <seb128> that's orthogonal to the warnings though
[14:43] <ogra_> but yeah, probably balme infinity, seb128 is right
[14:43] <ogra_> or doko :)
[14:44] <seb128> the fun factor is higher when you blame infinity though ;-)
[14:44] <ogra_> indeed :)
[14:53] <happyaron> jono: ping
[15:30] <trijntje> Hi all, can anybody tell me who is responsible for hosting the tracker for ubuntu torrents?
[15:30] <cjwatson> Canonical.
[15:35] <trijntje> cjwatson: sorry for double posting. What I meant was if there is any team/person I could contact about using the ubuntu tracker for localized iso images
[15:39] <cjwatson> trijntje: I suspect we might not be willing to do that.  That tracker is on very old hardware and has a hard time of it as it is.
[15:40] <cjwatson> trijntje: But I guess you could ask #canonical-sysadmin on freenode.
[15:41] <trijntje> cjwatson: I'll ask there, thanks. I'm from a small country, so it shouldnt add too much extra load
[15:42] <cjwatson> Right, but if we add one localised image then to be fair we have to be willing to add them all.
[15:42] <cjwatson> And that's a lot, at least potentially.
[15:45] <trijntje> thats true, I'll just ask and see ;)
[16:03] <pelya> Hi. I've made an app for Android, that will install and run Ubuntu without root privileges (that is, you can run it on a stock phone, without custom ROM or anything, it's similar to Wubi in this regard). It's achieved by using fakechroot, and of course it's buggy like hell. The mouse and keyboard are highly advised, but not required (Galaxy Note' stylus substitutes mouse quite well).  Here's the link: https://play.google.com/store/apps/details?id=com.cun
[16:03] <pelya> I've tested it on Galaxy Note, and I've installed and launched Gimp using Synaptic (took several tries though), no promises that any other application will work.
[16:03] <pelya> There was a lot of fuss about Ubuntu on Android, and there's lot of text here: http://www.ubuntu.com/devices/android  it mostly advertises Ubuntu to cellphone manufacturers, but it misses one point - those guys are driven by money and business, and they are not interested in anything that does not show immediate profits (even if that's something as simple as rooting your device and unpacking tarfile). So, Ubuntu needs an app, a simple app that non-techie
[16:03] <pelya> Alternatively, we may try to wrap some popular applications with no alternatives on Android, like Gimp or Libreoffice, into minimal fakechrooted Linux environment, however that stuff can only be installed into internal phone storage (not SD card), which is usually very limited, so 2-3 of them will eat all free space.
[16:03] <pelya> So, I've wanted to make announcement on the ubuntu-mobile mailing list, but there's no such mailing list and the link is broken on https://wiki.ubuntu.com/ContributeToUbuntu  So, where should I post that info, or this IRC channel is enough? I suppose I should open a bug on an Ubuntu brainstorm page.
[16:12] <SpamapS> pelya: perhaps ubuntu-devel-discuss mailing list would be better, IRC is not a great place to announce things
[16:35] <pelya> I've created a ticket on brainstorm.ubuntu.com, so the idea won't get lost (I hope)
[17:39] <dobey> barry: ping
[17:40] <barry> dobey: pong
[17:41] <dobey> barry: hey, how does one get things added to the python3 porting progress spreadsheet?
[17:41] <slangasek> as requirements?
[17:41] <slangasek> did we miss some? :)
[17:41] <dobey> yes. there are things we'll need for u1, which aren't on there
[17:42] <slangasek> for parts of u1 that are going to be on the CD, though?
[17:42] <barry> dobey: just edit the doc!  it's shared publicly and anons can edit it
[17:42] <slangasek> I thought the main body of u1 isn't on the CD currently
[17:42] <dobey> slangasek: yes, particularly for running the test suites, though not necessarily requirements for the runtime
[17:43] <barry> dobey: put those on the "good to have" sheet
[17:43] <dobey> slangasek: only part of u1 not currently on CD is the qt dependant bits
[17:43] <dobey> barry: well i don't see how we can port u1 itself without them :)
[17:43] <barry> dobey: that's where we're putting things that aren't strictly required for the cd but might be useful for other reasons (e.g. Suggests)
[17:45] <slangasek> dobey: ah, and that's documented on the spreadsheet, yes - not sure what I was thinking of, probably a different release :)
[17:45] <dobey> though i suspect the big problem for us is goign to be twisted
[17:45] <slangasek> barry, dobey: I think anything needed for the test suite needs to be treated as required; we don't want to be sacrificing testability in the process of python3 porting
[17:46] <barry> dobey: yep, twisted is something of a blocker.  i've been chatting with various folks in the twisted community.  we'll have to talk about how to get the parts of twisted we need ported in 4 months, at uds
[17:46] <barry> slangasek: agreed.  dobey feel free to put those testing requirements in the main pages.  maybe add a comment about what they're used for
[17:46] <dobey> barry: yeah, i just added myself to the blueprint as participation essential :)
[17:46] <dobey> ok, will do
[17:47] <barry> dobey: +1
[18:59] <barry> kenvandine: ping.  i wonder if you could provide some help with running the test suite for lp:gwibber
[18:59] <kenvandine> barry, sure
[18:59] <kenvandine> you need to run make check  from in the test subdir
[19:00] <barry> kenvandine: ah, thanks, let me try that
[19:00] <kenvandine> tests isn't in the SUBDIRS
[19:00] <barry> kenvandine: (i'm working on removing the dependency on mx.DateTime since it looks like mx won't be ported to py3 any time soon)
[19:00] <kenvandine> barry, AWESOME!
[19:00] <kenvandine> i was worried about that
[19:00] <barry> kenvandine: yikes: ./test-runner: line 2: dbus-test-runner: command not found
[19:01] <kenvandine> ah, you need dbus-test-running
[19:01] <kenvandine> s/running/runner
[19:01] <barry> gotcha
[19:03] <kenvandine> barry, i was planning to spend my spare time next week during the product sprint trying to run gwibber-service with py3 to see how much pain that would be
[19:03] <kenvandine> get a feeling for it before UDS
[19:03] <kenvandine> barry, how are you feeling about it?
[19:03] <barry> kenvandine: awesome.  definitely ping me if you want any help.  right now i just want to get rid of mx :)
[19:04] <barry> kenvandine: freaking out a bit at the amount of work, but excited to be digging in :)
[19:04] <barry> kenvandine: do you know what package gtk.test comes in?
[19:04] <kenvandine> so it won't be "trivial" :-D
[19:04] <barry> ImportError: No module named gtk.test
[19:04] <barry>  
[19:04] <barry> ;)
[19:04] <kenvandine> hummm
[19:04] <kenvandine> must be the gtk gir?
[19:05] <kenvandine> no... /me looks
[19:07] <kenvandine> barry, where is that coming from?
[19:09] <barry> kenvandine: weird.  it came the first time i ran 'make check', but now it's not happening!
[19:09] <kenvandine> barry, odd...
[19:09] <kenvandine> :)
[19:09] <barry> kenvandine: well, i guess we can pretend it never happend
[19:09]  * kenvandine never saw a thing
[19:09] <kenvandine> :)
[19:10] <barry> kenvandine: :)  thanks.  let's see how far i get
[19:12] <kenvandine> barry, the mx.DateTime stuff is actually covered in the tests, which should help
[19:13] <barry> kenvandine: phew :)
[19:13] <kenvandine> keep the tests using mx.DateTime and change the service to see if it breaks the tests
[19:14] <barry> great idea
[19:20]  * happyaron sabdfl 
[19:20]  * happyaron sorry...
[19:20] <sabdfl> np
[19:32] <ScottK> Where is the knob I turn to coax apport into sending bug reports and not just to the crash database?
[19:56] <dobey> anyone know how to get -Wmaybe-uninitialized on gcc in precise? doesn't seem to exist there, but i have code failing to build on quantal because of it, so it makes it hard to fix :-/
[20:00] <slangasek> ScottK: apparently the answer is to delete line 23 of /etc/apport/crashdb.conf :/
[20:00] <ScottK> slangasek: Thanks.
[20:01] <slangasek> dobey: are you looking for -Wuninitialized?
[20:02] <dobey> slangasek: no, there seems to be a maybe-uninitialized in the new gcc now
[20:02] <slangasek> which "new" gcc?
[20:02] <slangasek> gcc-4.7?
[20:02] <dobey> yeah
[20:03] <slangasek> ok
[20:03] <slangasek> well, I expect the answer is you can't (sanely) get it on precise, and would need to set up a quantal chroot for debugging
[20:04] <dobey> so it would seem :-/
[20:04] <ScottK> That did it.  Thanks.
[20:05] <slangasek> dobey: really though, if you're trying to debug build failures on quantal, you should use a quantal chroot *anyway*, since there could be any number of other latent issues
[20:06] <slangasek> i.e. issues not related to the compiler
[20:23] <slangasek> kees: what do you think of resolvconf running chattr -i automatically on upgrade and popping a debconf prompt to let the admin know? (bug #989585)
[20:24] <kees> slangasek: that'd be fine, IMO.
[20:25] <kees> slangasek: I would have welcomed it in my situation
[20:25]  * slangasek nods
[20:25] <slangasek> we've effectively already said that you don't get to keep it immutable, so the admin doesn't actually have a choice
[20:25] <slangasek> so no sense in making them do it manually when we can do it automatically
[20:26] <maco> i'll need to remember that one
[20:26] <slangasek> maco: ?
[20:26] <maco> i am a big fan of chattr +i as a hack to work around daemons stomping on my config
[20:26] <maco> i'm sure ive used it on resolv.conf before
[20:27] <slangasek> ah
[20:27] <slangasek> yeah, /etc/resolv.conf is officially no longer Your Config™. :)
[20:31] <Nafallo> O_o
[20:32] <bdmurray> slangasek: I think the only thing to do with bug 989040 is mark it invalid
[20:32] <bdmurray> slangasek: and then block those in apport
[20:37] <hyperair> well this sucks. gnome-sushi's scrolling is broken in precise, probably because clutter can't handle xi2
[20:43] <barry> kenvandine: well, mx.DateTime definitely has more powerful time string parsers.  it's a bit hard for me to tell what the expected input formats are, but i think it's ISO 8601 from FB, right?
[20:43] <barry> kenvandine: gwibber/util/__init__.py's parsetime() is more difficult to decipher.
[20:44] <dobey> barry: does it really make any sense to differentiate between binary and source packages on the python 3 spreadsheet?
[20:44] <barry> kenvandine: oh, and naive timestamps, utc?  i think local/naive, but FB's API makes me think maybe us/pacific timezones
[20:45] <barry> dobey: mostly, that's for convenience so you don't have to figure out what to download to hack
[20:45] <dobey> barry: i mean, shouldn't it only list the source packages? it seems silly to me to list the same things over and over N times, particularly for sources which create numerous binary packages
[20:48] <kenvandine> barry, i think we store all the timestamps as utc
[20:48] <dobey> barry: the library/application split can also be a bit confusing for some of these packages
[20:48] <kenvandine> but i vaguely recall not all of the services gave us utc so we do the conversion
[20:48] <dobey> but perhaps that just exposes problems in the binary packaging that need to be fixed as well
[20:49] <kenvandine> i think facebook might give us the logged in users current time with timezone
[20:51] <kenvandine> barry, i think parsetime was to convert the timestamp without the local locale
[20:51] <barry> dobey: probably should just list source packages, but the initial search yielded binary packages so that kind of got exposed through the tools that created the initial spreadsheet
[20:51] <barry> kenvandine: so let me ask it a different way.  are all these semantics tested? :)
[20:52] <kenvandine> yes :)
[20:52] <barry> kenvandine: excellent!  i'm less worried about screwing it up then :)
[20:52] <barry> kenvandine: thanks
[20:52] <barry> brb
[20:53] <kenvandine> well, the test suite doesn't take into account all the possible variations of time strings we might get from the service, it just uses the sample data
[20:56] <e11bits> I would like to modify an existing package and make it available to the public as a variant of the original package. Are there some recipes on how to change package naming, versioning, control files to do so? I'm sure I'm not the first one in doing something like this.
[20:56] <dobey> lol, there's a screenshot for pyflakes in the software center
[20:57] <dobey> e11bits: the personal package archives page on launchpad help has info about how to do it with launchpad PPAs
[20:59] <e11bits> dobey: thanks. I will have a look and already threaten to come back with more questions (or if you name a channel that is more suited for things like this)
[21:00] <dobey> barry: how does one package an application such as pep8 for both python3 and python 2.x exactly?
[21:00] <tumbleweed> dobey: you usually end up doing a pep8 and pep83
[21:00] <tumbleweed> well, pep8-3 would probably be better
[21:01] <tumbleweed> e11bits: #ubuntu-packaging
[21:01] <dobey> ick
[21:01] <e11bits> tumbleweed: Ah, great! Thanks!
[21:01] <tumbleweed> unless it has a shebang, you can't tell what version of python a .py file is targetting
[21:02] <dobey> tumbleweed: what if it targets both?
[21:03] <tumbleweed> then run both pep8s on it :)
[21:04] <tumbleweed> pep8 is probably something that wouldn't need a separate version for python3, though
[21:04] <tumbleweed> pyflakes would
[21:05] <dobey> well pep8 apparently does
[21:05] <dobey> try "python3 pep8 /usr/bin/pep8" for a fun error
[21:05] <dobey> yay eggs
[21:06] <tumbleweed> dobey: I mean, the level of analylis it does on python source would probably allow one version to work on both. I wasn't saying I expected it to run on python3
[21:06] <dobey> tumbleweed: or i guess it would just include the python3 one in the package as well?
[21:08] <dobey> tumbleweed: oh, does it not actually import files to analyze them?
[21:08] <tumbleweed> nope, it parses them with piles of regexes
[21:09] <dobey> ok, well my original question with s/pep8/pyflakes/ then? :)
[21:10] <tumbleweed> so we'd probably do a separate pyflakes3 binary package
[21:11] <tumbleweed> (depending on how upstream supported python3, it could be a new source package, too. some upstreams are only supporting python3 throguh separate py3-only forks)
[21:27] <barry> dobey, tumbleweed, kenvandine sorry, i was afk.  i agree w/tumbleweed
[22:07] <slangasek> bdmurray: 989040> ack
[22:16] <Amoz> bkerensa, you're in the live hangout, right?
[22:17] <bkerensa> Amoz: yes
[22:17] <bkerensa> Amoz: do you have a question?
[22:17] <Amoz> bkerensa, Wayland!
[22:17] <bkerensa> Amoz: What about?
[22:17] <Amoz> please say something about Wayland =)
[22:17] <Amoz> progress, etc.
[22:17] <Amoz> is it going into 12.10?
[22:18] <slangasek> jono: rc6
[22:18] <slangasek> ;)
[22:19] <Amoz> bkerensa, ^ something about the status of it, is it usable yet? etc :)
[22:21] <bkerensa> Amoz: there :)
[22:21] <Amoz> bkerensa, aah too bad
[22:23] <Amoz> jono, one of the options? please tell me more!
[22:25] <ScottK> This really isn't the IRC channel for discussing a live hangout someone is having.
[22:26] <Amoz> ScottK, sorry, would you mind guiding me where I can get in touch with them? :)
[22:26] <ScottK> No idea, but this channel is for discussion of development of Ubuntu.
[22:27] <stgraber> Amoz: /query jcastro, /query bkerensa, /query akgraner or /query jono come to mind
[22:27] <Amoz> stgraber, thank you :)
[22:28] <bkerensa> Amoz: you could join #Ubuntu-community-team and ask any questions there
[22:28] <bkerensa> :)
[22:28] <Amoz> I wasn't aware it was so important to keep it clean in here :(
[22:28] <akgraner> Amoz, just gave you the link to watch the stream
[22:29] <akgraner> and please join the channel bkerensa posted to ask questions - it's ok - this is all new to us as well :-)