[00:07] <smallfoot-> in synaptic, i can click to see screenshot of apps
[00:07] <smallfoot-> but alwyas it cant find screenshot for no apps
[00:07] <smallfoot-> why?
[00:10] <ScottK> smallfoot-: Try #ubuntu+1 for Maverick help.
[02:16] <jdong> any gcc wranglers in here?
[02:16] <jdong> have this program that breaks when compiling in -O3
[02:16] <persia> Better to ask the question you really want to ask, as the answer to that question is likely to be "no" :)
[02:16] <jdong> but unbreaks at -O3 -fno-inline-functions
[02:17] <ajmitch> don't run gentoo? :P
[02:17] <jdong> and a disassembly seems to indicate the inlined functions aren't using the right registers
[02:17] <jdong> this is on GCC 4.4 in Ubuntu
[02:17] <jdong> gcc 4.3 in Debian doesn't have this bug
[02:17] <ajmitch> you've tried it on other versions of gcc in ubuntu?
[02:17]  * kj4ohh used gentoo for a while a number of years ago, he remembers having to take a small vacation when installing things like OpenOffice lol
[02:18] <jdong> I haven't tried it on GCC 4.3 yet
[02:18] <jdong> (in Ubuntu)
[02:18] <persia> Might try that.  4.5 could also be useful, depending.
[02:18] <ajmitch> 4.5 looks to be in maverick
[02:19] <jdong> okay, I'll have to up a machine to maverick
[02:19] <persia> In a recent FTBFS that might have been toolchain, doko asked for an extracted minimal test case, so I presume that's a sensible first step if you want to fix the compiler.
[02:19] <persia> If you want to just compile the app, just change the flags to work around the bug.
[02:19] <jdong> just wanted to see if the symptoms rang a bell to anyone
[02:19] <ajmitch> I didn't think -O3 was default usually?
[02:20] <jdong> if not, I'll keep investigating and hopefully find it's fixed, SRU-able, or I can write a meaningful bug report for it...
[02:20] <jdong> and no, -O3 is not default; this is the code for a course I'm TA'ing
[02:20] <ajmitch> aha
[02:20] <persia> There's plenty of folk who have done tests that show that -O3 is only faster on certain revisions of Pentium 4 for i386.  Haven't seen comparisons for other arches.
[02:21] <jdong> the reference platform is Debian, but kids playing on their own machines are using Ubuntu and finding that the code breaks in nonsensical ways.
[02:22] <Bachstelze> hi, jdong :)
[02:22] <Bachstelze> back to business, I see
[02:22] <jdong> hey Bachstelze :)
[02:22] <poolie> jdong: and you're pretty sure it's not a bug in the program being compiled?
[02:22] <jdong> eh for some definition of business that involves not having sleep and being a student again, one last time.
[02:22] <poolie> my experience is that's more common than gcc bugs, though of course it can happen
[02:23] <jdong> poolie: oh I don't rule out that it's PEBKAC but it'd be pretty weird PEBKAC
[02:23] <jdong> I'm exporting a copy of the tree and posting it...
[02:26] <jdong> http://stuff.mit.edu/~jdong/pentominoes.tar.gz
[02:26] <jdong> to see the bug, ./pentominoes -b '0,0 0,1 0,2 0,3' -p
[02:27] <jdong> add -fno-inline-functions to CFLAGS_RELEASE in the makefile and run again to see correct output
[02:27] <jdong> namely, adding the noinline attribute to board_set_square() fixes it
[02:27] <jdong> I wrote this sample code for the students, and don't really think I did anything terribly PEBKAC
[02:28] <jdong> (functions of interest are in pentominoes.c I should mention)
[02:28] <maco> does that mean what i think it means?
[02:28] <maco> 5-sided dominoes?
[02:28] <jdong> maco: nah, 5-unit tetris pieces
[02:28] <maco> oh
[02:28] <jdong> maco: http://en.wikipedia.org/wiki/Pentominoes
[02:29] <jdong> maco: it's a variation of the pentomino tiling puzzle, where you must use all 12 pieces to fill a 8-by-8 board
[02:29] <jdong> except in this variant, the board is toroid, so pieces wrap around the edges, like snake :)
[02:30] <maco> O_o
[02:30] <jdong> the solver that I provided them uses horribly-performing data structures and overly abstracted piece representations, and the students' task is to make it perform better :)
[02:30] <jdong> namely, the board is a char[8][8] ;-)
[02:41] <Bachstelze> FWIW, it's broken in gcc 4.4 on Maverick too
[02:42] <jdong> I mean, looking over the code, between solve() and board_set_square()... I don't think I did anything that's not basic C
[02:42] <jdong> in this case I'm prejudiced to blame the optimizer ;-)
[02:48] <persia> If you did things in a way that most folk might find in need of code changes due to poor design, you may only have limited sympathy from the toolchain folk :)
[02:49] <jdong> hahaha
[02:50] <jdong> in this case one can argue it's not poor design but simplicity ;-)
[04:10] <Bachstelze> bug 643168 is another proof that gnome is dumb
[04:10] <Bachstelze> g-c-m wants to install a package that only exists in github
[04:11] <persia> For maverick, probably best to patch out that preference.  For natty, maybe package the missing bit?
[04:17] <Bachstelze> probably
[04:17] <Bachstelze> it's also in Lucid
[04:17] <persia> Nothing safe to do for lucid at this point.
[04:18] <persia> Patching it out is invasive enough to get rejected as an SRU, and new packages are never accepted.
[04:18]  * Bachstelze nods
[04:18] <persia> I suppose someone could package for natty and backport to lucid, but that's only going to help some users.
[04:21] <ScottK> Yes, but that's probably the lowest risk solution.
[04:23] <Bachstelze> someone has it on a PPA, he could also have filed a bug...
[04:24] <persia> Bachstelze, Often it's best to presume that folk don't always know how, or have time.  Maybe you could use the PPA version to start a process for natty, and backports?
[04:24] <persia> And collaborate with the PPA person to pool efforts and make sure it works well?
[04:28] <Bachstelze> better get it pushed to Debian before I guess
[04:28] <persia> That sounds like a good plan to achieve the get-it-into-natty step, indeed.
[06:06] <AnAnt> Hello
[06:06] <AnAnt> LP #640567
[06:10] <micahg> AnAnt:that's in main, you'll have to ask in -devel and it needs a release team ack
[06:11] <AnAnt> ok
[06:14] <persia> Why is it in main?  Doesn't seem to be in any tasks.
[06:14] <micahg> !info swt-gtk
[06:15] <AnAnt> ?!
[06:15] <AnAnt> it is in lucid
[06:15] <persia> It's a source package.  The bot only looks for binary packages.
[06:15] <AnAnt> !info src:swt-gtk
[06:15] <micahg>  swt-gtk | 3.5.1+versionbump-2ubuntu3 |      maverick | source
[06:18] <micahg> persia: no idea :)
[06:18] <micahg> no MIR that I can find
[06:20] <persia> If I wasn't more interested in making "universe" go away entirely, I'd be tempted to go try to pull everything out of main.  As it is, my desire is rather to move everything in universe into main wholesale.
[06:21] <AnAnt> persia: and what would become of MOTUs then ?
[06:21] <micahg> Masters of the Unseeded :D
[06:22] <persia> Indeed.
[06:22] <superm1> but what would that actually accomplish?
[06:22] <persia> Acronym doesn't change.  Activities don't really change.  Confusion about components goes away.
[06:23] <micahg> yeah, mainly the component shuffling, also, when something is dropped from a seed, then MOTU automatically (more or less) would get to upload again, whereas now, it's a manual process, right persia?
[06:24] <persia> superm1, The main issues are semantic: there are lots of folks who avoid "universe" because it's "unsupported", not being aware that there's plenty of software in universe that is supported, and plenty in main that isn't.
[06:25] <persia> There's also a lot of workaround code to enable or disable universe for various things in various places which ends up being a crude hack, essentially, and some wide number of bugs because things got handled wrong.
[06:25] <superm1> isn't that type of line more blurred to the general user with software center though?
[06:25] <persia> In theory, kinda, except in execution, the use of "Supported" happens to be aligned with "main", and lots of folk still talk about stuff on the internet.
[06:26] <persia> blurring that line in the tools was one of the steps that had to be accomplished to making it go away.
[06:27] <persia> Back when "main" represented one flavour, the use of MIRs was helpful to decide what would and wouldn't ship in a context.  This got more confusing with two flavours, but the DE variation made overlap narrow.  These days, a critical MIR for one flavour can change behaviour in another in an undesireable way.
[06:27] <AnAnt> there are unsupported packages on main ?
[06:28] <persia> And the outdated concept of "main"/"universe" hides this to a certain degree, as many folk remember when it was useful.
[06:28] <persia> AnAnt, Remember sl-modem, and how it got out of main, and why it went back in?
[06:28] <AnAnt> so what's the role of main then ?
[06:28] <persia> There's lots more stuff like that.
[06:28] <micahg> persia: the only good thing about MIRs is the security review before being seeded
[06:28] <AnAnt> persia: yeah, that's why I am confused now
[06:28] <persia> "main" used to be the stuff Ubuntu supported, and then it was the stuff Canonical supported, and now it's kinda meaningless.
[06:29] <persia> micahg, Then why not insist on security review *at seeding time*, rather than for something else?
[06:29] <AnAnt> then why don't Ubuntu just do like Debian: main contrib & non-free
[06:29] <micahg> well, it's still the stuff that Canonical is supposed to support, but whether or not it happens is anotehr story
[06:29] <micahg> persia: I think it's a great idea :)
[06:29] <persia> micahg, It's not even that.  Ask someone at Canonical.  There's plenty of stuff they support in universe, and plenty they don't support in main.
[06:30] <persia> (for one or another value of "support", and depending on who you ask)
[06:30] <persia> And it's not my idea: it's "Archive Reorganisation", as has been ongoing for the past couple years :)
[06:30] <micahg> persia: I guess my only experience in this regard is with Seamonkey and they tell me I have to do the testing
[06:31] <persia> AnAnt, I believe the current consensus is to have "main" "restricted-firmware", "restricted-software".
[06:31] <AnAnt> persia: restricted-software = contrib + non-free ?
[06:32] <persia> No.
[06:32] <persia> restricted-software == multiverse
[06:32] <persia> Well, and maybe some stuff from restricted, if there's any non-firmware there.
[06:32] <AnAnt> aha, got the point
[06:33] <AnAnt> well, that's a nice idea
[06:36] <AnAnt> so where can I get a list of current package sets ?
[06:37] <persia> LP API has them.
[06:37] <persia> They are starting to get exposed in other places in LP, but slowly.
[06:40] <AnAnt> persia: LP API is in /usr/share/pyshared/launchpadlib/ ?
[06:47] <persia> https://help.launchpad.net/API : much of it is exposed by launchpadlib, but maybe you prefer Java, or maybe something was exposed that isn't seen, etc.
[06:47] <lifeless> AnAnt: help.launchpad.net/API
[08:13] <persia> Does anyone know why libunwind is built on such a narrow set of architectures?  Seems to build for some others, and some stuff seems to build-depend on it.
[08:31] <\sh> persia: not again libunwind...I thought the only rdepends is the google perftools
[08:31] <\sh> moins btw
[08:37] <persia> \sh, Hey.  Might be: that's the FTBFS for which I saw it.  Still, only works on half our architectures, for reasons I don't understand.
[09:10] <\sh> persia: if google perftools is in ftbfs state, try to rebuild it
[09:11] <persia> Can't: no libunwind for armel/powerpc
[09:12] <persia> Hrm, actually, maybe I just need to change [!i386] to [amd64 ia64 ppc64] ...
[09:12]  * persia will try that later
[09:12] <\sh> persia: nope..I think libunwind and google perftools are only buildable on i386 and amd64
[09:12] <\sh> I think it's in the debian arch build file...what's the name of it again? ;)
[09:13] <StevenK> Pas
[09:13] <StevenK> P-a-s, rather
[09:13]  * persia is more than happy to override P-a-s, but believes it not to be set in this case, as there was a failed powerpc build (and powerpc is built on Debian)
[09:14] <persia> But, yeah, fixing google-perftools to have better build-depends means I don't need to understand why libunwind is annoying.
[09:29] <\sh> I don't touch it anymore...the last debdiff with a buildfix came from fedora, and there was a discussion about -U_FORTIFY_SOURCE
[09:29] <\sh> s/fedora/upstream/
[10:01] <DktrKranz> bdrung_: I'll process u-d-t today, so you can sync it shortafter
[10:26] <bdrung_> DktrKranz: thanks
[10:29] <DktrKranz> bdrung_: I've already uploaded it, expect it to be in incoming in ~4 minutes
[10:29] <bdrung_> DktrKranz: yes, i saw your mail
[13:42] <sylvaing> hu
[15:52] <ari-tczew> ScottK: could you take a look @ bug 524341 ? is it ready for upload?
[16:05] <RainCT> didrocks: Hey. Have you got my mail?
[16:05] <didrocks> RainCT: yes, I received it, I think that's something doable. Do you mind if I upload on Wednesday? Quite busy there and I think we will upload to new zg version
[16:07] <RainCT> didrocks: Okay, cool.
[16:08] <didrocks> RainCT: thanks ;)
[16:11] <RainCT> didrocks: Do you prefer to take care of the packaging yourself? I could also push an update to Debian with any patches you'd like (experimental already has the latest release)
[16:36] <bdrung_> DktrKranz: you uploaded u-d-t too early. i found an bug in sponsor-patch
[16:37] <DktrKranz> d'oh
[16:39] <bdrung_> DktrKranz: i pushed the fix
[16:41] <DktrKranz> bdrung_: are you a DM, aren't you?
[16:41] <bdrung_> DktrKranz: yes, i am
[16:41] <DktrKranz> if you want to add yourself in uploaders, and DM-U-A field, could be fine
[16:42] <bdrung_> DktrKranz: you should add the DM-U-A field
[16:42] <bdrung_> (according to the wiki)
[16:42] <DktrKranz> nice deal
[16:42] <DktrKranz> doing
[16:43] <bdrung_> DktrKranz: the question is: does murphy's law apply. if we release 0.103, a new bug will be found. if i wait some time to catch more bugs, no bug will be found.
[16:43] <bdrung_> s/apply./apply?/
[16:44] <Laney> if you wait indefinitely then there will be no bugs at all
[16:44] <Laney> and no users, ...
[16:44] <DktrKranz> that reminds me of dak package
[16:45] <bdrung_> Laney: if i wait indefinitely, all user will complain about bugs ;)
[16:46] <bdrung_> let's hope that release early, release often is the right approach
[16:46] <Laney> There's always bugs. Not all bugs are serious enough to deserve a new release.
[16:46] <DktrKranz> murphy's law related to debian archive: a new bug happens as soon as process-upload just scanned your package
[16:49] <DktrKranz> bdrung_: btw, DM-U-A field set, and you're on Uploaders now
[16:50] <DktrKranz> also, debian #594424 could be worth fixing
[16:51] <didrocks> RainCT: I'll take care of it, no worry. We have to find a worflow for using the same branches btw.
[16:51] <didrocks> RainCT: just like I'm in super-busy mode until hard freeze ;)
[16:51] <Laney> final freeze isn't hard? :-o
[16:52] <bdrung_> DktrKranz: do you have time to fix that?
[16:53] <DktrKranz> yes
[16:53] <DktrKranz> doing tests on real hardware now
[16:54] <bdrung_> DktrKranz: pushed
[17:11] <bdrung_> geser: import-bug-from-debian doesn't have a man page
[17:13] <DktrKranz> bdrung_: committed
[17:13] <DktrKranz> usr/bin/sponsor-patch
[17:13] <DktrKranz> neither
[17:14] <bdrung_> DktrKranz: i know
[17:15] <bdrung_> DktrKranz: maybe we should ad both man pages before uploading 0.103
[17:15] <DktrKranz> ack
[17:16] <DktrKranz> bdrung_: opinions on debian #584556 ?
[17:16] <DktrKranz> I don't really imagine how to handle that
[17:17] <Laney> ask the user to visit the URL themselves
[17:17] <Laney> instead of opening their browser
[17:18] <bdrung_> that would be a solution
[17:20] <DktrKranz> a functional workaround, at minimum
[17:22] <Laney> most OAuth programs have a separate step for launching the browser
[17:22] <DktrKranz> another idea could be to wait, say, 5 seconds before launching the browser
[17:23] <Laney> that's a pretty grim solution
[17:23] <Laney> i'd rather require another confirmation than that
[17:23] <DktrKranz> mmh, yeah
[17:24] <DktrKranz> a second "press enter to actually launch the browser" could go
[17:24] <Laney> really I'd just give the url
[17:24] <Laney> but maybe I'm old skool
[17:25]  * DktrKranz is used to copy&paste too
[17:25] <Laney> reasonable terminals will make it clickable
[17:26] <DktrKranz> mmmh, just giving the URL seems not enough, as I believe it does additional tasks after browser is launched, and Enter is pressed
[17:27] <Laney> not sure
[17:27] <Laney> seems that comes from lplib anyway
[17:28] <DktrKranz> yeah
[17:28] <DktrKranz> just seen that
[17:28] <Laney> reassign ;)
[17:28] <DktrKranz> ok, let's also ping python-launchpadlib maintainer... DktrKranz: your turn :P
[17:30] <bdrung_> DktrKranz: i have opened bug #643691
[17:31] <bdrung_> DktrKranz: according to ScottK the new scripts should be tested by other than the script write. can you test wrap-and-sort and sponsor-patch?
[17:35] <tumbleweed> bdrung_: I'll happily ack sponsor-patch
[17:37] <bdrung_> tumbleweed: what do you meant with ack in this context?
[17:38] <tumbleweed> bdrung_: "should be tested by [someone] other than the script write[r]"
[17:38] <bdrung_> k
[17:46] <aBaldrich> Hi! I'm a C programmer who's been using ubuntu for over a year. I have a launchpad account for bug reports, but I'd like to contribute more. How do I start?
[17:47] <Bachstelze> aBaldrich: there's not much C in Ubuntu proper, but you can always contribute upstream
[17:47] <kklimonda> !contribute | aBaldrich
[17:47] <aBaldrich> thanks :)
[17:48] <bdrung_> Bachstelze: there are many C apps in Ubuntu.
[17:48] <bdrung_> tumbleweed: there is more work: bug #643691
[17:49] <AnAnt> bdrung_: thanks
[17:49] <bdrung_> AnAnt: for what?
[17:49] <AnAnt> bdrung_: swt-gtk
[17:49] <bdrung_> AnAnt: you're welcome
[17:53] <bdrung_> tumbleweed: do you have time for more work on u-d-t?
[17:54] <tumbleweed> bdrung_: just about to start a loco team meeting, but otherwise I do have, yes
[17:54] <bdrung_> tumbleweed: the package lacks two man pages and i don't like writing those...
[17:55] <tumbleweed> hah!
[17:55] <tumbleweed> I'll have a look later
[18:22] <lucidfox> YokoZar, here?
[20:02] <ScottK> lucidfox: Nice blog post.
[20:03] <lucidfox> ScottK> Thanks! Been brewing in my head for a while :)
[20:04] <ari-tczew> which blog?
[20:04] <lucidfox> I've also been thinking of writing a post encouraging Ayatana to be to GNOME what Ubuntu is to Debian, but I don't think that sugestion would meet much success
[20:04] <lucidfox> ari-tczew>my latest Planet Ubuntu post, http://lucidfox.org/posts/view/623
[20:06] <ScottK> lucidfox: I think it gets caught up in corporate politics.  As I dimly understand it, "Upstream Gnome" decision making is dominated by Red Hat and so the chances of a lot of cooperation are low.
[20:07] <lucidfox> Well, last time a project was perceived as stagnating and suffering from lack of a vision, it resulted in the birth of a new project called... Ubuntu
[20:29] <kklimonda> lucas: the question is whether upstream GNOME (lead mostly by RH) is going to be interested in ayatana bits.
[20:29] <kklimonda> seriously
[20:29] <kklimonda> i can nevee catch her :D
[20:30] <kklimonda> time to enable part messages
[20:30] <Nafallo> kklimonda: not that I think that would be the audience... as little as ubuntu is targetting DDs
[20:31] <kklimonda> Nafallo: what do you mean?
[20:32] <Nafallo> kklimonda: oh. I completely misread the nick you where targetting and hence the reply was aimed for a completely different discussion. sorry :-)
[20:32] <kklimonda> ah, now it makes more sense :)
[20:33] <Nafallo> heh
[20:34] <ari-tczew> kklimonda: hi. what about patch for g-s-d? is it going to be in maverick as upstream, or do we need to add patch manually?
[20:34] <kklimonda> ari-tczew: it got applied by the upstream already
[22:29] <bdmurray> Do I need to do anything process wise to upload the fix for bug 643896?
[22:33] <ari-tczew> bdmurray: this is universe. if you have tested patch, you can push it
[22:37] <ari-tczew> highvoltage: ping