[03:06] <TheMuso> @pilot out
[04:20] <pitti> Godo morning
[04:23] <pitti> ev: apport patch> NB that the data can already be bytes, and in most cases, should be; you seem to have hit a corner case where a string is recognized as binary data
[04:24] <pitti> ev: is this running with py2 or 3? looking at _is_binary() it should work alright with py3
[04:25] <pitti> ev: for the py2 case, it looks like a "if isinstance(string, unicode)" check is missing?
[04:37] <pitti> ev: would it be possible for me to get the .crash file it was trying to reprocess? I'm afraid it's not quite obvious which kind of data caused this
[05:53] <gogo_> Hello, any idea if we will be able to install catalyst legacy drivers in Ubuntu 12.10? There is a thread about this on reddit --> http://www.reddit.com/r/Ubuntu/comments/11743j/ubuntu_developerstesters_please_comment_on_status/
[05:58] <RAOF> gogo_: Short answer -no.
[05:59] <RAOF> gogo_: Although the free drivers for those cards aren't terrible.
[06:02] <gogo_> RAOF: Oh, what happens when a user having these old cards tires to install catalyst driver in Ubuntu 12.10? I think Ubuntu still shows an option to install fglrx for legacy cards, which gives users a broken experience.
[06:02] <gogo_> tries*
[06:04] <RAOF> gogo_: It shouldn't; we (should) only display the proprietary drivers as an option if the proprietary drivers actually support the card they're using.
[06:06] <RAOF> (Also, that thread is somewhat out of date; the free drivers in Quantal should support full acceleration up to < radeon 78xx (and possibly 3D for the 78xx & 79xx cards, although I've not tested that and I'm not sure how well it works).
[06:14] <gogo_> RAOF: Thanks for the info, I am installing Ubuntu 12.10 now; will check out open source drivers.
[06:35] <dholbach> good morning
[06:39] <diwic> infinity, I got a build error email from Launchpad this morning, it says pulseaudio failed building on quantal/armhf, but when I click on the build log I get a "lost something?" page. Is it anything I should do anything about?
[06:45] <cjwatson> diwic: that means it's been retried, and in this case it succeeded, so ignore it
[06:46] <diwic> cjwatson, ok, thanks
[06:46] <alkisg> Hi, 4 out of 5 times this file cannot be found and is breaking firefox upgrade, where can I report a web-server related problem?
[06:46] <alkisg> http://archive.canonical.com/pool/partner/a/adobe-flashplugin/adobe-flashplugin_11.2.202.243.orig.tar.gz
[06:46] <cjwatson> (assuming this wasn't a PPA - I'm checking the primary archive)
[06:46] <diwic> yep, it was the primary archive
[06:46] <diwic> alkisg, +1, I'm seeing the same problem this morning
[06:47] <alkisg> diwic: to solve it I put wget in a while loop... it succeeded that way :-/
[06:47] <sarnold> alkisg: some mirrors had it, some mirrors didn't?
[06:47] <alkisg> sarnold: yes, for example:
[06:48] <cjwatson> There are only two hosts behind archive.c.c
[06:48] <diwic> @pilot in
[06:48] <alkisg> 91.189.92.150 => not found, 91.189.92.191 found
[06:49] <cjwatson> right, kudan has it, sadalbari doesn't
[06:49] <cjwatson> I'll ask our sysadmins
[06:50] <alkisg> Thank you cjwatson
[06:50]  * dholbach hugs diwic
[06:51] <diwic> dholbach, thanks, still unsure of what to do with it :-/
[06:53] <i3d> The latest update seem to have changed the behavior of df output
[06:53] <i3d> df does not print root filesystem anymore
[06:55] <dholbach> diwic, I think that even if you can't upload a patch directly, it's still useful to check some of the patches and find somebody who can get them in - basically try to help nudge the patch along
[06:56] <diwic> dholbach, or maybe redo them as SRUs
[06:56] <dholbach> yes
[06:57] <dholbach> many of the people who are submitting patches don't know all the correct procedures yet
[06:57] <dholbach> so whatever helps them get their change in is much appreciated
[06:58] <i3d> http://pastebin.com/AnW9g5zj would some wise minds take a look and see what might be the problem?
[07:06] <cjwatson> i3d: strace -s 1024 please to see full strings.  but isn't /dev/sda5 your root fs?
[07:07] <i3d> cjwatson: ok search on 12.10 bugs and I think I found it... https://bugs.launchpad.net/ubuntu/quantal/+source/mountall/+bug/1060296
[07:07] <i3d> looks like it is a legit issue
[07:08] <i3d> right that is my root fs... but after the latest update, it becomes -
[07:08] <i3d> hopefully will get fixed soon..
[07:10] <cjwatson> i3d: ah, right - yeah, Steve's working on that
[07:13] <i3d> cool thanks cjwatson !
[07:46] <elixey> i'm on ubuntu server 12.04 and running     cat /proc/sys/kernel/random/entropy_avail     will steadily decrease estimated entropy in the system
[07:57] <elixey> btw, that stuff doesn't occur in debian 6.0
[07:57] <elixey> why does it happen?
[07:57] <elixey> what possible use could there be
[07:57] <sarnold> elixey: it doesn't? o_O
[07:57] <elixey> sarnold, have you triedit?
[07:58] <sarnold> elixey: no debian machines around :/
[07:58] <elixey> why wouild it happen in ubuntu sarnold
[08:04] <mvo> cjwatson: sorry if that got answered already, but is someone looking at bug #1064545 - if not I can do that now
[08:06] <seb128> mvo, slangasek fixed that yesterday no?
[08:06] <seb128> mvo, https://launchpad.net/ubuntu/+source/update-notifier/0.125
[08:06] <seb128> https://launchpad.net/ubuntu/+source/update-notifier/0.126 fixes the build
[08:08] <sarnold> btw, elixey's problem answered: http://lkml.indiana.edu/hypermail/linux/kernel/1004.0/01031.html
[08:08] <mvo> seb128: oh, ok, the bug is not closed and no bug references, this is why I was confused, if its done, I will leave it as is
[08:09] <seb128> mvo, sorry for breaking it, "it's just translations updates" ... you tricked me there :p
[08:10] <mvo> seb128: ehhh, sorry !
[08:10]  * seb128 hugs mvo, no worry
[08:10]  * mvo hugs seb128 back
[08:11] <seb128> mvo, on the good side Steve added tests for that issue so it will not happen again ;-)
[08:11] <mvo> seb128: great!
[08:11] <mvo> seb128: if you are certain its the one of the bug, would you mind closing the bug?
[08:11] <seb128> mvo, doing it
[08:12] <mvo> ta
[08:12] <cjwatson> mvo: yeah, what seb128 said :-)
[08:13] <seb128> mvo, it still feel weird that "$package" is marked as a string to translate when the translation should be "$package", it's a translator trap for sure
[08:13] <cjwatson> Yes, it should be untranslatable; if you want to figure out how to make it so, I'm sure slangasek would appreciate it
[08:13] <mvo> seb128: I haven't looked at this at all
[08:18] <seb128> cjwatson: right, I'm pretty sure that if it's done this way it's because there is no trivial solution though :-(
[08:19] <seb128> cjwatson, slangasek: one workaround could be to make the package build hack the pot at the end of the build to drop that string from the template so it wouldn't show on launchpad...
[08:32] <ev> pitti: yeah, I was hopeful to look over a .crash file, but they're surprisingly absent on the retracer boxes.
[08:33] <ev> pitti: I'll see if I can force it to happen again
[08:33] <pitti> ev: oh, doesn't it download the report from somewhere?
[08:34] <cjwatson> seb128: I bet this libgtk2-perl failure is related to https://bugzilla.gnome.org/show_bug.cgi?id=616997
[08:34] <cjwatson> That's the obvious change in Gtk+ 2.24.12
[08:34] <pitti> ev: AFAICS this coudl happen if you have an unicode (py2) / str (py3) object with characters < 32
[08:34] <ev> pitti: apols, my brain is still warming up
[08:34] <pitti> ev: is your retracer using py2 or py3?
[08:34] <ev> I was thinking of the .crash file for apport-retrace itself
[08:34] <ev> py2
[08:35] <pitti> ev: ah, ok; that's relieving, as it really ought to work for py3
[08:35] <seb128> cjwatson, http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=1070c5849e45433ad66c076e0bf692d936813a31 then ?
[08:36] <ev> pitti: I think it's time to switch to py3 on them, once this issue is sorted
[08:37] <cjwatson> seb128: Yeah, I suspect that commit broke it.  I'm having a look round to figure out how to adapt the Perl tests now
[08:37] <cjwatson> (I suspect this is just a test bug)
[08:39] <diwic> @pilot out
[08:39] <diwic> might continue later
[08:39] <cjwatson> Though, I dunno, seems non-ideal that you can't call gtk_recent_chooser_set_current_uri right after gtk_recent_manager_add_item any more
[08:40] <seb128> right...
[08:40] <cjwatson> I guess because reload_recent_items hasn't been called
[08:43] <cjwatson> But I suppose this is kind of the point of that bug fix - don't guarantee that items show up in the chooser immediately, because it's too slow
[08:44] <cjwatson> Could just have the test forcibly emit the changed signal, maybe
[08:45] <seb128> I'm still surprised it was that slow before (looking at the number on the bugzilla comments), even sequential adding for the entries shouldn't take that long... anyway those who fixed it this way know that part of GTK and probably did the right thing
[08:47]  * cjwatson tries adding $manager->signal_emit('changed');
[08:48] <cjwatson> That looks happier
[08:48] <cjwatson> Result: PASS
[08:49] <seb128> cjwatson, \o/
[08:49] <cjwatson> I'll test that a bit more, send to upstream/Debian, upload
[08:50] <seb128> thanks
[09:08] <wmp> hello
[09:08] <wmp> i have problem with linker and boost, i cant compile program. this is linker error and my package list: http://paste.ubuntu.com/1270735/ with: http://paste.ubuntu.com/1270737/
[09:09] <cjwatson> Sweetshark: I've copied libreoffice from quantal-proposed to quantal; based on the changelog, does that mean that bug 1062448 can now be untargeted from quantal (if not closed)?
[09:51] <glatzor> tyhicks, hello
[09:51] <tyhicks> glatzor: Hi
[09:53] <glatzor> tyhicks, I run an ecryptfs protected home dir on my debian wheezy system and run into the corrupted files on disk full error
[09:53] <glatzor> tyhicks, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=+%09690071
[09:54] <glatzor> tyhicks, you mentioned that some patches to fix this problem have been applied in ubuntu. but I still get the problem with the patches applied
[09:54] <glatzor> tyhicks, are there any further patches missing?
[09:56] <tyhicks> glatzor: You applied the 3 patches mentioned at the bottom of that bug?
[09:59] <jibel> jodh, I attached a more complete stack trace to bug 1060249 if it helps. It occurs on every upgrade.
[10:00] <glatzor> tyhicks, right.
[10:00] <jodh> jibel: thanks!
[10:00] <glatzor> tyhicks, with the applied patches the command to fill up the disk failed correctly by a disk full error. I used dd if=/dev/zero of=disk-full bs=1M
[10:01] <glatzor> tyhicks, but without the patches the dd command tries to write for ever
[10:02] <tyhicks> glatzor: With the patches applied, it sounds like things are working correctly. Why do you think there is still a problem?
[10:03] <glatzor> tyhicks, because I still get files of zero size in $HOME/.Private/ that cause problems
[10:08] <tyhicks> glatzor: If you have DEBUG level kernel logging enabled, you'll still see a "Valid eCryptfs headers not found ..." message at times but then those files are properly handled now. Can you confirm that you're actually still getting zero length files and not just seeing that message in the logs?
[10:15] <tyhicks> glatzor: FYI, see https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/957843/comments/22
[10:16] <tyhicks> glatzor: Those two extra patches don't fix the problem that you're seeing, but they're needed if you carry the other three patches
[10:17] <glatzor> tyhicks, Is it ok if I add this conversation to the bug? I will try with the other two patches
[10:18] <tyhicks> glatzor: Sure
[10:18] <tyhicks> glatzor: I'm going to have to step away shortly. If you're sure that you're still seing zero length files, please file an upstream eCryptfs bug at https://bugs.launchpad.net/ecryptfs/+filebug and I'll take a look at it tomorrow.
[10:19] <tyhicks> glatzor: Please include the steps that you're doing to hit the bug and also what you're doing to verify that zero length files are still a problem after those patches are applied
[10:22] <glatzor> tyhicks, thanks!
[10:22] <tyhicks> glatzor: thank you!
[10:25] <diwic> @pilot in
[11:24] <Riddell> pitti: were you not doing to delete the -kde-xx-base packages?  I still see them
[11:31] <diwic> @pilot out
[11:49] <pitti> Riddell: hm, I thought I did
[12:02] <pitti> Riddell: hmm, WTF; I did run that long remove-packages command; digging out the shell command and trying again
[12:04] <cjwatson> pitti: do you think you could take bug 1061924?
[12:05] <pitti> Riddell: do you still have the list of packages that you make? http://paste.kde.org/562928/ timed out
[12:06] <pitti> cjwatson: hm, I guess udev is just about as wrong a package to put that in as any other?
[12:07] <cjwatson> Quite ...
[12:07] <pitti> that could be made a lot more elegant and efficient, but of course that'd need access to the actual hw
[12:08] <cjwatson> I expect it would be very short if a udev rule rather than an upstart job
[12:08] <cjwatson> (which seems to be what they're suggesting)
[12:08] <pitti> the main issue is that these crappy workarounds tend to be sticky
[12:08] <pitti> we'll never really get rid of them any more
[12:09] <cjwatson> mm, if you want to punt it I have no problem with that - it's just on the foundations rls-q-tracking list and I wasn't totally sure what to do with it
[12:10] <pitti> cjwatson: I'll ping jmleddy and see whether we can at least turn it into an udev rule on the PCI device
[12:11] <pitti> that woudl be at least much less hideous than calling dmidecode, lspci, and twice grep
[12:11] <cjwatson> Yeah
[12:24] <pitti> cjwatson: followed up on the bug, subscribed, and pinged jmleddy
[12:24] <cjwatson> thanks
[12:30] <pitti> Riddell: removed for good now; https://launchpad.net/ubuntu/+source/language-pack-kde-aa/+publishinghistory and https://launchpad.net/ubuntu/+source/language-pack-kde-zh-hant-base/+publishinghistory both confirm
[12:33] <pitti> hm, DEB_BUILD_OPTIONS=noopt seems to work for hardly any package these days :(
[12:39] <xnox> pitti: file debbugs =)
[12:40] <cjwatson> I thought that if anything noopt coverage should be improving due to dpkg-buildflags support
[12:40] <pitti> yeah, that's what I thought as well; what does seem to work is CFLAGS="-g -O0" debian/rules build
[12:40] <cjwatson> Using dpkg-buildflags is almost certainly the right fix for packages that fail to handle it
[12:40] <cjwatson> If any such packages already use dpkg-buildflags, that's worth investigating
[12:50] <spartan-11510> Hi
[12:50] <spartan-11510> i've a litlle question on packaging. When you have a java software, do you create a shell for launh the software, because you must write "java -jar archive.jar"
[12:50] <spartan-11510> ?
[12:56] <Riddell> pitti: lovely thanks
[13:03] <Sweetshark> cjwatson: untargeted, not closed for bug 1062448. I still have to investigate, if this still shows up in other more rare scenarios.
[13:06] <dupondje> telepathy-haze types can't be configured in the Online Accounts?
[13:07] <mpt> ev, could you kick off another graph update perhaps?
[13:07] <ev> mpt: sure, though I'm likely to request a deployment of the view that http://poppy-dev.local has tomorrow
[13:09] <cjwatson> Sweetshark: ok
[13:10] <cjwatson> spartan-11510: You can use something like jarwrapper; http://www.debian.org/doc/packaging-manuals/java-policy/x85.html
[13:11] <cjwatson> Or a wrapper script if you prefer, yes
[13:12] <spartan-11510> cjwatson: thank's for your advice. i'll looking for jarwrapper
[13:13] <ev> mpt: I'm getting OOM running the 12.04 variant (I'm also back populating the other graph at the same time), so I'll leave it as just 12.10 for now
[13:14] <mpt> ev, you mean from calculating the "by 12.04 standards" line?
[13:14] <cjwatson> spartan-11510: If you use javahelper, jh_exec can help with this.  See /usr/share/doc/javahelper/tutorial.html for a worked example
[13:14] <ev> oh, are you asking me to update the graph on errors.ubuntu.com or poppy-dev.local?
[13:14] <mpt> ev, e.u.c
[13:15] <ev> right
[13:15] <cjwatson> (I've not done this much myself - I just know where the tools are :-) )
[13:15] <mpt> ev, to see if all mvo's bug fixes made a dent :-)
[13:15] <ev> so then I mean that updating errors.ubuntu.com for 12.04 is using too much memory because I'm already updating poppy-dev.local for days gone past
[13:15] <mpt> ev, you do the errors.ubuntu.com calculations on your own machine?
[13:16] <ev> mpt: yes, because the cron job that would otherwise do them is broken
[13:16] <mpt> I see
[13:16] <ev> and I haven't gotten around to submitting a branch of memento to fix it
[13:19] <cjwatson> Sweetshark: That bug doesn't seem to be untargeted ... you probably need to mark the quantal task won't-fix
[13:20] <cjwatson> (with an explanation of course)
[13:26] <mpt> ev, thanks for the update ... and here I was thinking the line might dip down :-/
[13:46] <cr3> hi folks, are there projects that share common bzr ancestry upstream (lp:project) and downstream (lp:ubuntu/project)?
[13:49] <pitti> I don't know any; for that to work, you'd need to force-overwrite the auto-importer UDD branch with a custom-created branch
[13:49] <pitti> since bzr learned about "import-upstream" this should actually work
[13:49] <pitti> but I'm not aware of anyone doing that yet
[13:49] <pitti> so if someone knows a package that does that, I'm interested as well
[13:51] <cr3> pitti: after every release, I sync checkbox from upstream to downstream by overwriting just about everything except .bzr/ of course. at that point, I was thinking of pushing lp:ubuntu/checkbox to lp:checkbox and use common ancestry from that point onward, at the cost of losing some bzr history
[13:51] <xnox> cr3: no, but you can have your own downstream branch that does that.
[13:52] <xnox> cr3: for a native package, that might actually work.
[13:52] <pitti> cr3: we do use packaging branches derived from lp:project, but so far we have pushed them to e. g. ~ubuntu-desktop/indicator-applet/ubuntu instead of to lp:ubuntu/indicator-applet
[13:52] <pitti> cr3: then you can just do "bzr merge" for updating to a new upstream version, etc.
[13:53] <xnox> cr3: or you can simply request lp:ubuntu/checkbox to point to lp:checkbox. Any reason not to develop directly on the lp:ubuntu/checkbox and abandon the lp:checkbox?
[13:53] <barry> cr3: you might get on #udd and ask there.  many of us have wanted something like this for forever
[13:53] <pitti> if the packaging branch has the pristine-tar data, it should be okay to force-overwrite push it to the UDD branch
[13:53] <pitti> xnox: not if lp:checkbox doesn't have the packaging
[13:53] <pitti> upstream branches usually shouldn't have packaging
[13:53] <cr3> xnox: yes, after FF, we still want to be able to push changes that won't necessarily land in the current development release of ubuntu
[13:54] <xnox> and tags matching all versions ever uploaded in ubuntu/debian.
[13:54] <xnox> pitti: *cough* lp:ubiquity
[13:54] <pitti> xnox: that's native
[13:54] <cr3> pitti: lp:checkbox does have packaging though, how's that a problem?
[13:54] <pitti> well, I guess you could treat checkbox as native, too
[13:55] <pitti> cr3: if it's only used in Ubuntu, and you don't need another packaging branches for PPAs etc., that's fine
[13:55] <pitti> cr3: but "real" upstream projects don't, otherwise you'd have to maintain spec files, Debian, Ubuntu, and whatnot packaging all upstream
[13:56] <xnox> for me the biggest problem was the upstream-tarball when $upstream-tag !=  tarball contents and therefore need for pristine-tar tarball commit on top of the tag and then somewhere down the line I was getting fileid conflicts =/ and I gave up.
[13:56] <cr3> pitti: I think lp:checkbox is special in that it's native (has packaging) and  not native (lp:checkbox != lp:ubuntu/checkbox), which is something I'd like to cleanup at some point
[13:59] <cjwatson> cr3: grub2 is mostly done that way except that I don't have the packaging branch in lp:ubuntu/grub2, but in a nearby branch
[14:00] <cjwatson> cr3: while openssh isn't in bzr upstream, there's an import in lp:openssh and it's bzr all the way down to lp:ubuntu/openssh
[14:01] <cjwatson> so yeah, openssh is pretty much an example of the kind you're looking for
[14:01] <cr3> cjwatson: do you have a non-ubuntu branch somewhere for development that might only land in a daily ppa before going into lp:ubuntu/grub2?
[14:01] <cjwatson> No
[14:01] <cjwatson> I don't bother
[14:02] <cr3> openssh sounds more similar then, I'll have a look at that project first
[14:02] <cjwatson> For openssh, I have a separate tarball branch that I merge each upstream tag into and which corresponds to the various little differences in the released tarball
[14:02] <cjwatson> grub2 is a bit more haphazard because I haven't yet bent the Debian maintenance branch entirely to my will
[14:05] <cr3> cjwatson: I like what I'm seeing in the openssh branches, would it make much difference in my case if the debian/ directory was maintained both upstream and downstream?
[14:06] <cr3> cjwatson: my motivation for maintaining it in both places is to have upstream packages built daily
[14:06] <cjwatson> If you're doing that you're basically talking about a native package with occasional forks
[14:06] <cjwatson> I think if anything that probably simplifies it
[14:06] <cr3> cjwatson: exactly, forks usually happen from FF onwards
[14:06] <cjwatson> Ah, indeed, checkbox *is* native per its versioning
[14:07] <cjwatson> So yeah, as long as you make sure to tag lp:ubuntu/checkbox before each upload the importer probably shouldn't overwrite it
[14:07] <cr3> cjwatson: indeed, but I think I'm doing some things that aren't strictly native. not sure what though
[14:07] <cjwatson> But I would definitely start with the full upstream history rather than throwing it away in favour of the auto-imported package history
[14:07] <cjwatson> Personally
[14:07] <cjwatson> cr3: Not sure how you could be without an orig :-)
[14:09] <cjwatson> cr3: The alternative is that you could do like we do in ubiquity: only use lp:checkbox, and between FF and release occasionally have feature branches or "next" branches or similar, which you can build in a PPA if you want too
[14:09] <cr3> cjwatson: so, once quantal is released and we start with fresh packages for the next release, would that be a good time to talk to someone about replacing lp:ubuntu/checkbox with a fresh branch of lp:checkbox, so that both share the same ancestry from that point onward?
[14:09] <cjwatson> Good time yes, but you don't need to talk to anyone about it - somebody with upload privileges can bzr push --overwrite
[14:09] <cjwatson> OK, you might need to talk to your sponsor
[14:10] <cjwatson> But not an admin or anything
[14:10] <cr3> cjwatson: I think my team likes the separation between lp:checkbox and lp:ubuntu/checkbox, except for the lack of common ancestry that's making patching time consuming and error prone
[14:10] <cjwatson> Yeah
[14:10] <cjwatson> It's simpler for native packages because it's just bzr merge and you don't bother about quilt patching or similar
[14:10] <cr3> cjwatson: ok, roadmr might have upload rights by then but we'll make sure to talk with a sponsor beforehand just to be extra sure
[14:11]  * cr3 should also fill paperwork to have upload rights one of these days
[14:12] <cr3> pitti, xnox, cjwatson: thanks for all the advice, much appreciated!
[14:13] <cr3> barry: I had a python question for you: map() returns a list in python2 and an iterator in python3, so I was wondering if there was a naming convention to make it clear whether a function I write returns a list or an iterator.
[14:14] <barry> cr3: nope :)
[14:14] <cr3> barry: this could easily be mentionned in the docstring of the function, but it's annoying to have to read the docstring every time someone just wants to call something like get_foos
[14:15] <barry> cr3: you could always just treat the return as an iterator, and list()-ify it if you needed a concrete list.  it does some wasted work in py2, but is at least consistent
[14:15] <xnox> cr3: there are ~15 tags missing in lp:checkbox as compared with lp:ubuntu/checkbox probably the "post-ff-mini-forks", so for history/archive I'd push lp:ubuntu/checkbox to lp:~/ubuntu/quantal/checkbox/old-branch or something
[14:16] <xnox> cr3: although, lp:ubuntu/quantal/checkbox will be your history if you do it right after release. so ignore me.
[14:16] <cr3> barry: the problem is that I've seen this degrade into people either always returning lists (return list(map(float, results))) or always calling list() to check for the length (if list(get_foos()))
[14:17] <xnox> barry: did I not see apis .get_iter() .get_items() for such cases?!
[14:17] <cr3> xnox: right but, just for my edification, what tags might I be missing? a tag everytime the version was bumped?
[14:17] <xnox> cr3: http://paste.ubuntu.com/1271221/
[14:17] <cr3> xnox: I would be afraid of falling into hungarian notation that way :(
[14:18] <barry> xnox: well, iter(obj) would be the api for .get_iter() right?
[14:18] <xnox> cr3: '-' missing in the trunk. '+' extra tag in the trunk.
[14:18] <barry> i guess it depends on whether the api really (usually) wants concrete lists or iterators... or both :)
[14:19] <xnox> barry: well, actually to be memory efficient by default i'd do the other way round. call list() for the .get_items() such that my iter api is actually yield statements for performance.
[14:20] <barry> xnox: me too.  i think that's the rationale for python3 by default returning iterators
[14:20] <cr3> xnox: yes, some changes upstream were backported downstream into new versions. does that make sense?
[14:20] <barry> call list() if you need a list (or tuple() etc as the case may be)
[14:20] <cjwatson> I would tend to not bother with a list variant.
[14:20] <doko> infinity, https://launchpadlibrarian.net/119386939/buildlog_ubuntu-quantal-armhf.mercurial-buildpackage_0.9_FAILEDTOBUILD.txt.gz
[14:20] <xnox> barry: i've seen another pattern of returning a single item or list of items. And the code everywhere to check if not isinstance list result = [item] *sigh* to _always_ have lists...
[14:20] <doko> dpkg-shlibdeps: warning: /lib/arm-linux-gnueabihf/ld-linux.so.3 has an unexpected SONAME (ld-linux-armhf.so.3)
[14:20] <doko> dpkg-shlibdeps: error: no dependency information found for /lib/arm-linux-gnueabihf/ld-linux.so.3 (used by debian/mercurial-buildpackage/usr/bin/mercurial-tagversion)
[14:21] <barry> xnox: sigh ;)
[14:21] <cjwatson> I think I looked at that mercurial-buildpackage failure and it went into my WTF bin
[14:22] <infinity> doko: Is it shipping pre-compiled binaries?  That's the only way that can happen.
[14:24] <doko> infinity, no
[14:25] <infinity> doko: Well, it just plain can't be getting any of its own binaries linked with that SONAME if it's all built fresh.  Unless it's using a broken compiler.  Did we fail to fix one? :P
[14:25]  * infinity looks.
[14:25] <doko> infinity, using haxe
[14:25] <infinity> doko: So, yes, we failed to fix a compiler.  Fun.
[14:26] <cjwatson> With one (1) reverse-build-dep.
[14:26] <infinity> Luckily, that's literally the only thing that build-deps on it.
[14:26] <cjwatson> Niche.
[14:26] <infinity> Heh.
[14:27] <infinity> Oh, and it likely doesn't even need patching, just rebuilding.
[14:27] <infinity> I'll give that a quick whirl in a sec too.
[14:27] <infinity> doko: Thanks for the heads-up.
[14:27] <cjwatson> Where's it even getting the linker path from?
[14:28] <cjwatson> No relevant matches for ld- or ld.so anywhere ...
[14:28] <infinity> I don't find it in the source, so I'm guessing it hunts it down during build time, then hardcodes it for future linking.
[14:28] <xnox> cr3: well cherry-picked. yeah =)
[14:29] <infinity> I didn't bother looking too hard, cause I suspect a rebuild will magically fix it.  We'll see.
[14:29] <cjwatson> It might actually be in neko instead.
[14:29] <infinity> Oh, is haxe just a frontend to evil?
[14:30] <infinity> Indeed, it may be.
[14:30] <infinity> dpkg-source: info: applying debian-changes-1.8.1-6ubuntu1
[14:30] <infinity> ^-- We're pro.
[14:30] <cjwatson> Not that I see a linker path in neko either ...
[14:31] <infinity> No, but neko does seem like a more likely candidate for doing real work.
[14:31] <infinity> I'll play with both.
[14:31] <cjwatson> Yeah, maybe it does some godawful build-time thing to work out the linker path.
[15:01] <cr3> barry: is calling list() on something that is already a list a noop until it is modified, copy-on-write, or is a completely new list always created?
[15:01] <barry> cr3: a completely new list object is created
[15:02] <barry> >>> x = list((1, 2, 3))
[15:02] <barry> >>> y = list(x)
[15:02] <barry> >>> x is y
[15:02] <barry> False
[15:02] <barry>  
[15:03] <cr3> barry: thanks! I should've tried that myself :)
[15:04] <xnox> barry: hm... if only this would happen to kwargs & dictionaries passed to functions.... so confusing. but I am now used to "abusing" that for fun and profit =)
[15:05] <barry> xnox: right, that's kind of a different effect.  default arguments are evaluated at def time
[15:38] <iainfarrell> kthxbai
[15:40] <slangasek> mvo: ping re bug #1016643
[15:54] <mvo> slangasek: about if that needs a apt-key patch as well? I would appreciate double checking the diff I put in there and welcome feedabck from https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1016643/comments/12 - I would love to be able to disable it in adv as well
[16:03] <slangasek> mvo: right, the question is whether more is needed than the software-properties fix.  I'm coming to this a little cold, I mostly just know that it's on our quantal bug list - how does 'apt-key adv' relate to software-properties?
[16:03] <slangasek> ah, that's how s-p invokes apt-key
[16:04] <slangasek> mvo: so what's insecure about the current behavior?
[16:07] <bdmurray> cjwatson: so using your test on quantal I received the following message from apt 'W: Some index files failed to download. They have been ignored, or old ones used instead.' and then I ran 'chdist apt-get captive-portal update' again but without the proxy and it succeeded
[16:09] <cjwatson> bdmurray: That sounds basically awesome
[16:10] <bdmurray> I'll do some looking at bug reports to see if I can find any recent incidents of the bug too
[16:11] <stokachu> infinity: http://paste.ubuntu.com/1271408/
[16:33] <ev> pitti: finally able to reproduce it on one of the retracer boxes. It's gdb hitting a corrupt stack, as far as I can tell
[16:33] <ev> http://people.canonical.com/~evand/tmp/f269837a-116f-11e2-9d07-2c768aafd08c.crash
[16:34] <ev> pitti: a retrace on my local machine produces http://paste.ubuntu.com/1271445/
[16:34] <ev> but on the retracer we get ?^VQ^H just below __PRETTY_FUNCTION__
[16:34] <pitti> ev: oh, so that works?
[16:34] <pitti> ev: is the errors.u.c. retracer running under LANG=C?
[16:35] <ev> I tried that locally - no such luck (LANG=C)
[16:35] <ev> I even built a precise chroot
[16:35] <ev> but I can only trigger it on the retracers
[16:35] <ev> it's definitely the gdb output though
[16:36] <ev> the quantal version of gdb has a better message:
[16:37] <pitti> ev: I don't see broken strings in that .crash file, I guess that's why it didn't trigger
[16:37] <pitti> ev: anyway, I'll play around with that tomorrow morning, I'm about to run out for today
[16:39] <ev> pitti: "Cannot access memory at address 0x100000007"
[16:39] <ev> pitti: sure thing - thanks!
[16:39] <ev> (which is why I was led to believe it might be a combination of running precise and something else that causes it to surface on the retracer box)
[16:40] <ev> that message appearing just below __PRETTY_FUNCTION__ that is
[16:43] <pitti> good night everyone!
[16:46] <ev> g'night pitti
[16:46] <ion> nighte
[16:47] <ev> mpt: october 5th was the first day we had the separate counters for each problem type
[16:47] <ev> and that landed part way through the day
[16:47] <ev> so I'll just need to go back and redo that day
[17:45] <darkcrow666> Hi !
[17:46] <darkcrow666> What do you have in mind when you still use compiz ?
[17:56] <bdmurray> seb128: could you have a look at bug 1048059?
[18:09] <Kano> hi, where is that gcdx64.efi file mentioned in the grub2 changelog?
[18:31] <Kano> found it, most likely you lost
[18:31] <Kano> chain can load any efi binary
[18:33] <Kano> where is shim
[18:34] <Kano> the signed version of course ;)
[18:34] <stgraber> Kano: apt-get install shim-signed
[18:35] <Kano> good, i guess i have to use kvm to verify what i think, but most likely your system is broken
[18:45] <slangasek> Kano: my understanding is that the load_image call goes through the SB verification chain
[18:46] <Kano> why would you use the linux call?
[18:46] <Kano> i have got no interest in using it. but chainloader
[18:46] <slangasek> I didn't say anything about linux
[18:47] <Kano> ok, why did you patch efilinux in it?
[18:47] <slangasek> sorry, what are you talking about?
[18:47] <slangasek> you were asking about shim and gcdx64.efi
[18:47] <slangasek> that's nothing to do with efilinux
[18:47] <Kano> yes, can that includes chain(loader)
[18:48] <Kano> with chainloader you can start efi binaries on an efi system
[18:48] <slangasek> yes, and chain uses load_image, and load_image fails if the image doesn't verify
[18:49] <Kano> verify against what? do you check now signatures for the kernel?
[18:50] <Kano> at least you could not verify any initrd
[18:52] <slangasek> Kano: if you find an exploit that allows unsigned code to be run in BootServices, please let us know and we'll fix it
[18:53] <Kano> would not help anything if it is a binary that is out now
[18:53] <slangasek> of course it would
[18:54] <Kano> btw, in the ubuntu + debian grub 2.00-7 is a stupid bug
[18:54] <Kano> or better 2 bugs
[18:54] <Kano> http://kanotix.com/files/fix/efi/grub-2.00-7-debian-bugs.txt
[18:55] <Kano> one thing is, it calls efibootmgr even if grub-pc is installed but the system is booted via efi (not necessaryly via grub)
[18:55] <slangasek> Kano: we have a bug tracking system, please report these there
[18:55] <Kano> the other thing is, the use of -w is not needed and absolutely critical when you use a hd with mbr
[18:55] <Kano> it kills the serial
[18:56] <Kano> you can use efi partition with mbr hd as well, it just needs to be a primary one
[18:57] <Kano> with those 2 bugs combined you get directly a system that only boots grub, no win, no other bootloader you specified because the serial of hd is used inside the nvram
[18:57] <Kano> and inside win bootloaders
[18:58] <Kano> as soon as you install that grub
[18:59] <Kano> bbl
[19:37] <seb128> bdmurray, hey, I will have a look, thanks for pointing it
[19:39] <bdmurray> seb128: thanks I've an upgraded system where /media/$username/ doesn't exist if that is any hlep
[19:40] <seb128> bdmurray, well, that's not an issue, they should be created by udisk when needed
[19:40] <seb128> bdmurray, it's rather a pitti's topic (he maintains the udisk stack) but I will check the bug details and see with him
[20:09] <jibel> SpamapS, is bug 1021471 fixed for you with kernel 3.5.0-17.28 ?
[20:09] <SpamapS> jibel: I haven't had a chance to fully test it yet
[20:10] <jibel> I still get it with lxc
[20:10] <SpamapS> jibel: hard because I have to test with b43 instead of wl which is.. less than reliable ;)
[20:10] <SpamapS> jibel: do you have a wl based network connection?
[20:10] <jibel> SpamapS, no, I've a wired connection
[20:11] <SpamapS> jibel: and does refcount == 2 ?
[20:11] <jibel> driver is an r8169 exactly, refcount = 1
[20:11] <SpamapS> jibel: its possible other drivers than wl have the problem. :-/
[20:12] <SpamapS> jibel: only way to tell is to run 3.6 and make sure the problem is gone there
[20:12] <SpamapS> or at least, that is one way
[20:12] <SpamapS> anyway, need to get lunch... starting to hear rumbles
[20:13] <jibel> I'll try on another machine, but on my main desktop I can reproduce it very reliably just by creating an lxc container and shutting it down with poweroff
[20:13] <jibel> SpamapS, ack, I'll try 3.6
[21:10] <slangasek> smoser: hey, so is mountall looking happy for you now?  I'm feeling a little disoriented with no mountall bugs from you in my queue and fear that something is wrong ;)
[21:12] <Daviey> hah
[21:13] <Daviey> slangasek: He understood that for any change he wanted, you mandated a fork removal. :)
[21:13] <slangasek> heh
[21:16] <smoser> i actually havne't tested your latest.
[21:16] <smoser> let me check.
[21:18] <slangasek> heh, ok :)
[21:26] <ScottK> Not testing is the easiest way not to get bugs.
[21:27] <mlankhorst> Testing is the easiest way to get bugs?
[21:32] <ScottK> No, convincing someone else to test is often easier than testing yourself.
[22:08] <Sweetshark> anyone with glib knowledge around?
[23:25] <geofft> Is pesign / sbsign / something Debian-packaged already perchance?
[23:26] <geofft> (I noticed shim was packaged recently.) The packaging is probably trivial, but it'd be nicer to just use Ubuntu's :)
[23:26] <cjwatson> geofft: sbsigntool, yes
[23:27] <geofft> aha, singular, unlike the thing on OBS. Thanks!
[23:29] <cjwatson> the upstream name is singular :)
[23:47] <psusi> cjwatson, you think porting partman to parted3 will happen for 13.04? ;)
[23:47] <cjwatson> psusi: dunno, I guess we should get round to it
[23:47] <cjwatson> but now is the worst time to ask
[23:49] <psusi> it seems I'm going to become co-maintainer of parted
[23:49] <cjwatson> Then perhaps you might like to help with porting partman :)
[23:50] <cjwatson> Not sure where I put that preliminary patch