| bdrung_ | doko: btw, do you have any idea how to debug bug #629955? | 00:01 |
|---|---|---|
| ubottu | Launchpad bug 629955 in audacity (Ubuntu) "audacity 1.3.12-5 FTBFS on maverick" [High,Confirmed] https://launchpad.net/bugs/629955 | 00:01 |
| bdrung_ | doko: i tried to build with gcc-4.4 (suggested by ScottK), but it still fails | 00:01 |
| doko | bdrung_: we still build with 4.4 | 00:02 |
| bdrung_ | doko: hm, ok. then what else changed between lucid and maverick? | 00:04 |
| persia | bdrung_, If nothing else, you might look at differences between the powerpc build environment and the others: it did get built on powerpc, and there's probably < 15 packages that differ in the installed build-deps. | 00:05 |
| bdrung_ | right | 00:06 |
| TheMuso | Whats up with powerpc? | 00:08 |
| persia | TheMuso, It builds packages a bit slower than i386, and it seems audacity happened to get built at the right time to be successful on powerpc, but failed everywhere else. | 00:08 |
| TheMuso | ah | 00:09 |
| TheMuso | Probably because its slower hardware perhaps? | 00:09 |
| ogra_cmpc | then armel would never ftbfs ;) | 00:10 |
| ogra_cmpc | doko, just noticed your ping upstairs, will test tomorrow (sorry, i didnt notice it earlier) | 00:10 |
| persia | ogra, armel has special reasons to FTBFS, which make up for the lack of speed :) | 00:11 |
| doko | bdrung_: can you test to build with https://edge.launchpad.net/~ubuntu-toolchain-r/+archive/ppa/+packages (gcc-4.4-fsf)? not sure if this package still installs cleanly | 00:11 |
| ogra_cmpc | persia, heh | 00:12 |
| doko | bdrung_: seems to build with g++-4.3, so please find out which of the autoconf tests is the one that doesn't do the thing it should do | 00:14 |
| bdrung_ | doko: AC_EGREP_HEADERS | 00:15 |
| === dendro-afk is now known as dendrobates | ||
| bdrung_ | in the portmixer tree | 00:16 |
| doko | bdrung_: well, extract a self-contained test case and attach it to the report? | 00:16 |
| bdrung_ | doko: the failing configure.ac part: http://paste.debian.net/90486/ | 00:23 |
| doko | bdrung_: sure, and now find out, why it succeeds with 4.3, and fails with 4.4 ... | 00:25 |
| bdrung_ | doko: it fails if i run "./configure" in lib-src/portmixer | 00:27 |
| bdrung_ | doko: probably there needs to be a parameter. let's compare them... | 00:28 |
| doko | bdrung_: and does it succeed if you run CC=gcc-4.3 CXX=g++-4.3 ./configure ? | 00:28 |
| ogra_cmpc | it likely does some tests | 00:28 |
| ogra_cmpc | extract them and call them manually with different gcc's | 00:29 |
| bdrung_ | doko: no. it needs additional parameters. | 00:30 |
| bdrung_ | doko: i found one differing parameter: libjack | 00:38 |
| === dendrobates is now known as dendro-afk | ||
| bdrung_ | doko: i make progress: I was able to limit the error to one command in lib-src/portmixer/configure.ac: AC_EGREP_HEADER([PaMacCore_GetStreamInputDevice], [pa_mac_core.h], , [have_support=no]) | 01:03 |
| Chipzz | doko: there was some discussion earlier about the default alignment on AMD64; you're the toolchain person, right? | 01:18 |
| Chipzz | doko: https://launchpad.net/bugs/24692 | 01:19 |
| ubottu | Launchpad bug 24692 in NVIDIA Drivers Ubuntu "Amd64 ubuntu build hogs memory due to libs built with excessive alignment requirement" [Undecided,Incomplete] | 01:19 |
| bdrung_ | doko: i have created a small testcase and attached it to bug #629955 | 01:22 |
| ubottu | Launchpad bug 629955 in audacity (Ubuntu) "audacity 1.3.12-5 FTBFS on maverick" [High,Triaged] https://launchpad.net/bugs/629955 | 01:22 |
| bdrung_ | ScottK: just to let you know: ^ | 01:23 |
| persia | bdrung_, So, why does that work on powerpc? | 01:25 |
| bdrung_ | persia: dunno. look at the attached testcase. something triggers the bug in this small example | 01:27 |
| bdrung_ | persia: i am too tired to work further on it. | 01:27 |
| persia | Heh. I've started a powerpc build against current maverick: I might look at the test case if I run into time, and I'll update the bug. I just generally find it odd when things work on one arch and not others. | 01:28 |
| bdrung_ | persia: can you run the testcase on current maverick on powerpc? | 01:29 |
| persia | I can, and will if I run into time to dig through it (requesting a maverick test rebuild of audacity requires more CPU time, but is one line at the command prompt) | 01:30 |
| lifeless | kees: around? | 01:35 |
| kees | lifeless: nope :) email me :P | 02:25 |
| lifeless | kees: its for your embargo bug | 02:25 |
| lifeless | kees: can't really move on it atm >< | 02:25 |
| TheMuso | c | 05:08 |
| === Amaranth_ is now known as Amaranth | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| AnAnt | Hello, can someone ack: LP #640567 | 06:14 |
| ubottu | Launchpad bug 640567 in swt-gtk (Ubuntu) "Candidate revision 3.5.1+versionbump-5ubuntu1" [Undecided,New] https://launchpad.net/bugs/640567 | 06:14 |
| persia | AnAnt, You probably want a rationale for the release team review. | 06:17 |
| AnAnt | persia: the bugs it closes ? | 06:17 |
| persia | Yep. I usually write a few sentences in a "Rationale: " section at the top of the bug description just to make it super-easy for approval teams. | 06:19 |
| AnAnt | ok | 06:20 |
| AnAnt | done | 06:20 |
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === nxvl_ is now known as nxvl | ||
| === spike_ is now known as spikeWRK | ||
| === oSoMoN_ is now known as oSoMoN | ||
| pitti | Good morning | 08:24 |
| AnAnt | Hello | 08:26 |
| AnAnt | please ACK LP #640567 | 09:25 |
| ubottu | Launchpad bug 640567 in swt-gtk (Ubuntu) "FFe: Candidate revision 3.5.1+versionbump-5ubuntu1" [Undecided,New] https://launchpad.net/bugs/640567 | 09:25 |
| ogra | mvo, around ? | 09:25 |
| mvo | ogra: yes | 09:30 |
| ogra | mvo, so i tried to use apturl ... but it doesnt work :( | 09:30 |
| ogra | i ship a .desktop file with Typer=Link and Exec=apt:package-name?channel=ti-omap4-ppa .... | 09:31 |
| ogra | klicking on it doesnt bring up software-center | 09:31 |
| ogra | *Type | 09:31 |
| mvo | does it bring up anything? | 09:31 |
| ogra | only the loading animation of the netbook-launcher-efl | 09:31 |
| ogra | i dont see anything in the processlist | 09:32 |
| ogra | (at least it doesnt bring up an error ... i should probably see that as positive :) ) | 09:32 |
| mvo | ogra: does gnome-open DTRT ? | 09:35 |
| ogra | lets see | 09:35 |
| mvo | ogra: I wonder if netbook launcher is just having issues with Type=Link | 09:35 |
| ogra | it opens weblinks fine | 09:35 |
| iulian | AnAnt: I accept cheques, direct bank transfers and postal orders. Is that OK with you? | 09:36 |
| AnAnt | iulian: as long as I am not paying, I don't mind | 09:36 |
| ogra | mvo, yeah. gnome-open brings up software center telling me there isnt a package called package-name :) | 09:37 |
| mvo | ogra: haha | 09:37 |
| ogra | using the above url | 09:37 |
| mvo | ogra: so do you have a package in that channel ? | 09:37 |
| mvo | ogra: then s-c will be more happy :) | 09:37 |
| ogra | yes, there shuld be one | 09:37 |
| * ogra looks up the ppa | 09:38 | |
| ogra | mvo, https://edge.launchpad.net/~tiomap-dev/+archive/release .... | 09:40 |
| ogra | mvo, same error with the actual package name now | 09:40 |
| iulian | AnAnt: Are the rdepends affected by those changes? | 09:40 |
| mvo | ogra: oh, that is rather silly of s-c, could you please report a bug about it? | 09:40 |
| cjwatson | slomo: nitpicking I suppose, but your gst-plugins-good0.10 upload makes the changelog improperly formatted, due to: | 09:41 |
| cjwatson | -gst-plugins-good0.10 (0.10.25-2ubuntu1) maverick; urgency=low | 09:41 |
| AnAnt | iulian: should not, because that's not a new upstream | 09:41 |
| cjwatson | + gst-plugins-good0.10 (0.10.25-2ubuntu1) maverick; urgency=low | 09:41 |
| ogra | mvo, what about the .desktop file ? | 09:41 |
| ogra | should i just blindly call gnome-open and make it Type=Application ? | 09:41 |
| mvo | ogra: I'm not sure why it does not DTRT, but you can use gnome-open | 09:41 |
| ogra | k, i'll try that | 09:41 |
| mvo | ogra: could you try it with gnome-panel? it smells like a potential issue with efl-launcher | 09:41 |
| cjwatson | slomo: could I have an upload without that glitch? | 09:42 |
| slomo | cjwatson: sure, thanks | 09:42 |
| ogra | mvo, well, gnome-open with Application works fine, i can live with that | 09:43 |
| mvo | ogra: ok | 09:43 |
| cjwatson | mvo: this software-center upload doesn't actually seem to have any change relevant to bug 640906. r1218 in bzr claims to fix it but is just a changelog change | 09:45 |
| ubottu | Launchpad bug 640906 in update-manager (Ubuntu) "gksu invocation with incorrect .desktop file" [Undecided,New] https://launchpad.net/bugs/640906 | 09:45 |
| mvo | cjwatson: let me double check | 09:45 |
| cjwatson | (the rest looks fine) | 09:45 |
| slomo | cjwatson: new version without that space uploaded :) | 09:46 |
| cjwatson | slomo: thank | 09:46 |
| cjwatson | s | 09:46 |
| ogra | mvo, ugh ... i should probably do my tests with a binary packagename, not with a source one :P | 09:47 |
| * ogra tests again | 09:47 | |
| iulian | AnAnt: Please upload. I will take another look at it when it's in the queue. | 09:48 |
| AnAnt | iulian: swt-gtk is in main, and I am MOTU | 09:48 |
| pitti | didrocks: you rock! http://qa.ubuntu.com/reports/bug-fixing/maverick-fixes-report.html | 09:49 |
| AnAnt | pitti: I think he knows that already | 09:50 |
| mvo | cjwatson: thanks for the review and sorry for that oversight, I will upload a new one with just that diff | 09:50 |
| pitti | he does, but I just can't stop saying | 09:50 |
| didrocks | pitti: oh great! :-) | 09:50 |
| iulian | AnAnt: OK. | 09:50 |
| * pitti hugs mvo as well for being such a close #2 | 09:50 | |
| pitti | mvo: you can still beat him! | 09:50 |
| * didrocks hugs pitti & mvo | 09:50 | |
| iulian | Group hug! | 09:50 |
| mvo | woah! I had no idea | 09:51 |
| didrocks | pitti: don't tell that, he will add bugs to USC for beating me :) (I'll add more in unity then :p) | 09:55 |
| cjwatson | mvo: no problem, thanks | 09:55 |
| persia | How is that calculated? I'm sure I didn't fix anything in prboom, and I know I fixed a couple other things. | 09:55 |
| cjwatson | wow, I'm well behind this cycle | 09:56 |
| * mvo hugs didrocks | 09:56 | |
| cjwatson | pitti: note that #4 and #5 look like the same person, and added together exceed didrocks | 09:56 |
| * mvo hugs pitti | 09:56 | |
| cjwatson | (not to burst his bubble or anything ;-) ) | 09:56 |
| cjwatson | that would be bhavi's vast pile of merges I imagine | 09:56 |
| persia | Indeed. | 09:56 |
| didrocks | cjwatson: don't make me cry :-) | 09:57 |
| cjwatson | persia: I believe it's from Changed-By of uploads with Launchpad-Bugs-Fixed fields. Maybe sponsorship? | 09:57 |
| cjwatson | persia: https://bugs.launchpad.net/ubuntu/+source/prboom/+bug/375498/comments/24 certainly shows you | 09:58 |
| ubottu | Launchpad bug 375498 in prboom (Ubuntu) "prboom exits with signal 8" [Medium,Fix released] | 09:58 |
| persia | Hrm, possibly (or potentially pabs just insisting a one-character fix was correct) | 09:58 |
| pitti | cjwatson: indeed, our king of sponsoring | 09:58 |
| persia | Ah, faulty memory works too :) | 09:58 |
| mvo | but careful, once seb128 sees that he is only #3 I'm sure he will go into some final frenzy to catch up ;) | 09:59 |
| didrocks | mvo: he's on vacation until eow :) | 10:01 |
| cjwatson | mvo: python-apt: does DebSize maybe need to use K rather than L? I notice that it's unsigned long long | 10:24 |
| cjwatson | mvo: I don't know whether this matters - if it doesn't, feel free to ignore me | 10:25 |
| mvo | cjwatson: yeah, K is more correct, also in pratice it should not matter that much. I can fix and re-upload if you want (and go through to see that its correct at the other places | 10:25 |
| cjwatson | mvo: if it doesn't matter in practice, I'll just accept this now - you can always tweak it later | 10:26 |
| cjwatson | ogra: your jasper-initramfs upload has a typo | 10:26 |
| cjwatson | + cp /root/usr/share/jasper-initramfs/ppa/ti-omap4-ppa.desktop /root/usr/share/applications/ti-ppa.dektop | 10:26 |
| cjwatson | ogra: should be .desktop at the end. Rejecting, please upload with that fixed | 10:26 |
| mvo | thanks cjwatson, I think it does not matter much currently, in this case it should just limit the DebSize (the size of the packages download) to 2^63 when it could be 2^64 | 10:30 |
| bdrung_ | persia: what was the result of your powerpc build of audacity? | 10:57 |
| persia | Precisely the same failure. | 10:57 |
| persia | So that it built was clearly a timing issue, which means that a review of the differences in versions of the installed build-dependencies might identify the culprit. | 10:58 |
| persia | Unfortunately, I haven't found time to run your test case yet (although I hope to as soon as I finish this one more bit on the other thing). | 10:59 |
| ogra | cjwatson, ugh, please reject i'll do a new upload | 10:59 |
| ogra | ah, you did already :) | 10:59 |
| ogra | mvo, where exactly does sw-center get the channel name from ? the filename or the ppa url ? | 11:01 |
| mvo | ogra: what does it display currently? | 11:04 |
| * persia thought it got it from the channel definition file | 11:04 | |
| ogra | it doesnt display anything, still the error, i want to know if i use the right one in the apt: url | 11:05 |
| ogra | i have ti-omap4-ppa.list in /usr/share/app-install/channels/ and the url contains channel=ti-omap4-ppa | 11:05 |
| ogra | the full url for installing a test package is: apt:titiler-memmgr-tests?channel=ti-omap4-ppa | 11:07 |
| ogra | https://edge.launchpad.net/~tiomap-dev/+archive/release/+packages | 11:07 |
| ogra | sw-center displays the package name with a capitalized T and tells me that package is not available in my current software sources | 11:08 |
| doko | bdrung_: updated bug #629955. I think the test should always fail, and that were just lucky until now. however I don't see yet why the extra error line leads to a different test result | 11:08 |
| ubottu | Launchpad bug 629955 in audacity (Ubuntu) "audacity 1.3.12-5 FTBFS on maverick" [High,Triaged] https://launchpad.net/bugs/629955 | 11:08 |
| === smb-afk is now known as smb | ||
| === smb is now known as smb-afk | ||
| === ivoks-afk is now known as ivoks | ||
| bdrung_ | doko: should it really fail? should AC_EGREP_HEADER check the existence or the usability? | 11:26 |
| doko | bdrung_: how is this header ever used? | 11:32 |
| bdrung_ | doko: it's used in src/px_mac_coreaudio.c. a separate check checks if we want to build src/px_mac_coreaudio.c | 11:34 |
| bdrung_ | wrong answer | 11:34 |
| doko | bdrung_: well, then the correct fix would be to only run this test, iff you build src/px_mac_coreaudio.c | 11:34 |
| bdrung_ | i am looking for the documentation | 11:35 |
| persia | Another option would be to not fail the build for platforms that don't have coreaudio if the test fails. | 11:35 |
| bdrung_ | doko: very good idea | 11:36 |
| === amitk is now known as amitk-afk | ||
| bdrung_ | doko, persia: thanks for you help. i will forward our results to upstream | 11:41 |
| persia | bdrung_, Did you get it building? | 11:42 |
| bdrung_ | persia: no, but we know now the reason and how to fix it (doko's suggestion) | 11:42 |
| bdrung_ | just run AC_EGREP_HEADER on the files that we want to build | 11:43 |
| persia | OK. I usually try to go one step more (maybe in discussion with upstream, or other interested parties). Obviously, it would be unfortunate to release in current state. | 11:43 |
| persia | Do you still want me to run the test in a couple minutes? | 11:43 |
| bdrung_ | persia: no | 11:44 |
| bdrung_ | persia: i will do a quick workaround test | 11:44 |
| persia | Sorry about that then. | 11:44 |
| bdrung_ | persia: commenting the failing test should work | 11:44 |
| persia | That's my least favorite way to fix things, but yeah, since in this case we know in advance it should fail, and we don't care. | 11:46 |
| jibel | !regression-alert | 11:48 |
| ubottu | cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 11:49 |
| jibel | bug 642518 | 11:49 |
| ubottu | Launchpad bug 642518 in fglrx-installer (Ubuntu Lucid) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,Triaged] https://launchpad.net/bugs/642518 | 11:49 |
| cjwatson | chatter I saw in IRC scrollback suggested that kees was already on top of that | 11:49 |
| jibel | this was introduced by the security fix of last week | 11:49 |
| cjwatson | 17:01 <kees> ebroder: okay, thanks. this is a bug in the kernel update and we'l get it fixed asap; sorry for the glitch! | 11:50 |
| cjwatson | (yesterday) | 11:50 |
| jibel | cjwatson, okay. There is no comment from kees on the bug report. | 11:51 |
| cjwatson | yes, I saw that | 11:52 |
| bdrung_ | cjwatson: my workaround works. let's wait for the upstream fix. | 11:58 |
| === BlackZ_ is now known as BlackZ | ||
| === amitk-afk is now known as amitk | ||
| lucidfox | 'Having SABDFL simply state ?this is how it is? may have given people finality, but for me, it was the wrong kind of finality. It was the finality of someone saying ?I?ve listened to the hundreds of comments complaining about this change, and I?ve chosen to ignore you?.' | 12:36 |
| sabdfl | lucidfox: which issue? | 12:37 |
| directhex | i guess the popular "sent from Ubuntu" bug | 12:37 |
| lucidfox | Uh oh, I summoned the mighty giant! *hides* :) | 12:37 |
| lucidfox | not that one | 12:38 |
| directhex | no? wow! | 12:38 |
| lucidfox | the window placement issue - this was a comment in my blog | 12:38 |
| lucidfox | er, window button placement | 12:38 |
| lucidfox | I actually feel concerned that, since it's only configurable via a hidden gconf setting, people turn to applications like Ubuntu Tweak, with known security issues, to change it | 12:39 |
| lucidfox | I think I'll make a separate blog post about the harm of hidden preferences | 12:39 |
| === MacSlow is now known as MacSlow|lunch | ||
| === rgreening_ is now known as rgreening | ||
| sabdfl | i wonder how folks feel about the buttons placement now? | 12:51 |
| sabdfl | lots of discussion before the release, very little after | 12:51 |
| directhex | sabdfl, i haven't found the regedit value to make my windows 7 partition put the buttons on the correct side of the window :/ | 12:53 |
| sabdfl | directhex: i had to use windows the other day too. wow. backwards. | 12:53 |
| kklimonda | sabdfl: its so last week, now we are complaining about the new Evolution signature ;) | 12:54 |
| directhex | kklimonda, what happened to complaining about the wallpaper? BRING BACK ubuntu-calendar! | 12:54 |
| didrocks | about the button placement: a lot of people hated it at the beginning in the French forum, but now, they are advocating for it when people wanting the change it back to the right. Funny :) | 12:55 |
| directhex | didrocks, i am reminded of http://www.ubercharged.net/wp-content/uploads/2010/06/1258035395841.jpg | 12:56 |
| persia | I suspect most folk don't care that much, but it's nearly impossible to collect useful data, as those who were unhappy have "fixed" it, those who appreciate the change are quietly happy, and those who don't care are characteristically silent. | 12:56 |
| kklimonda | directhex: hmm.. the old, good wallpaper of the month.. | 12:57 |
| pitti | didrocks: all just a matter of being used to something.. | 12:58 |
| directhex | change is scary! | 12:58 |
| didrocks | pitti: right, habits are hard to change… even for people who already switched to Linux | 12:58 |
| * wgrant got used to the button placement in about a day. Now Windows is painful :( | 12:58 | |
| pitti | mr_pouit: hm, it seems there is no real code for saving the default keyboard layout in XFCE right now? or am I missing something? | 12:59 |
| === al-maisan is now known as almaisan-away | ||
| pitti | mr_pouit: I added some ideas to http://bugzilla.xfce.org/show_bug.cgi?id=5270, but not sure what would be the most upstream-desirable variant | 12:59 |
| ubottu | bugzilla.xfce.org bug 5270 in Plugins "Active keyboard layout no remembered" [Normal,New] | 12:59 |
| pitti | mr_pouit: in other words, how well should xfce support gdm | 12:59 |
| persia | Why do we do that at the DE level again, rather than in X directly? | 13:00 |
| kklimonda | sabdfl: but there is still the issue of not communicating those changes more clearly beforehand. I can see why some members of the community feel left out. It would make a good uds session probably. | 13:00 |
| * persia doesn't currently, but has previously often had disagreements between keyboard layouts in GNOME vs. other places (raw X, console, etc.) | 13:00 | |
| directhex | kklimonda, it's not a democracy though. so perhaps stuff needs to be better communicated - but i wouldn't necessarily pay attention to the peanut gallery | 13:02 |
| vish | well i dont lucidfox was complaining about the change itself , but rather the way it was changed.. the change had no purpose and still doesnt have any purpose | 13:02 |
| persia | There's heaps of folk who can upload the packages that were controversial: if even one of them felt strongly enough to force the discussion to consensus to wait or to change, it may have been done that way. That none of them did indicates a consensus to accept the change within the set of developers who can adjust it (Ubuntu Desktop and Core in this case). | 13:04 |
| persia | Since anyone at all is able to be part of that group, just by having done a bunch of work (training is often received along the way), it's hard for me to see how it's an us vs. them thing. | 13:05 |
| kklimonda | directhex: wellthat's all I'm saying - to make community understand the process. | 13:05 |
| directhex | persia, the people who shout loudly about this stuff, very often, aren't interested in getting involved - only in having their opinions voiced | 13:06 |
| vish | directhex: ++ | 13:06 |
| persia | directhex, My point is that we need to be clear that we're looking for ways to have our collective decisions be broadcast to a wider audience, rather than finding ways to ensure that certain participants provide certain other participants with specific information. | 13:08 |
| directhex | twitter! | 13:08 |
| persia | I have reservations about some behaviours related to embargoes myself, but I'm not that sure how different an announced embargoed item is from something someone spent doing unannounced and didn't share for a similar period of time. | 13:09 |
| persia | Anyway, someone explain to me why selection of keyboard layout isn't done in X directly, rather than in the DE :) | 13:11 |
| directhex | legacy mess | 13:12 |
| persia | What would it take to fix? Are we close enough that a UDS session would be productive? | 13:14 |
| cjwatson | wait a sec, I don't like the change but there's a big difference between that and overruling a decision which was apparently requested by my manager's manager | 13:16 |
| cjwatson | persia: ^- | 13:16 |
| persia | cjwatson, Quite possibly. Note that I make no statements about the motivation of individuals to choose not to overrule a decision. Some folks might not do it for professional reasons. Some folks might not do it out of respect, etc. | 13:17 |
| cjwatson | persia: what I mean is that you can't translate that into a "consensus to accept the change" | 13:18 |
| persia | I do claim though that if anyone who could make the change *really* wanted to do so, we'd at least have a discussion before the TB. | 13:18 |
| persia | Why not? If you accept a change because of your employment, how is that different from you accepting a change for another reason, in terms of your acceptance of the change? | 13:18 |
| persia | I don't claim you're happy about it, only that you accept it. | 13:19 |
| cjwatson | I might well choose to voice my disagreement in other ways. There are ways of not accepting a change that consist of something other than immediately uploading to revert it. | 13:20 |
| cjwatson | And this one hasn't been around for long enough that you can infer anything much from there not having been a TB discussion about it yet. | 13:20 |
| cjwatson | (speaking for myself not as a TB member etc.) | 13:20 |
| mr_pouit | pitti: there's a dialog in xfce4-settings-manager, and the backend in xfce4-settings-helper to apply the settings. From a quick look, something is stored and apply, but I don't know how, nor if there's a way to set something by default (libxklavier doc is so badly written that it's useless) | 13:21 |
| wgrant | Is it a TB matter? | 13:21 |
| persia | I'm thinking of the button-placement issue as a better example. The evolution change is too young to be usefully analysed. | 13:21 |
| persia | wgrant, I'd think that in a case of dispute between developers, the TB would have a say. Might be CC instead. | 13:22 |
| mr_pouit | pitti: and btw, the bug you commented it is reported against mcs (the previous settings manager for < 4.6), which did not include any keyboard dialog | 13:22 |
| mr_pouit | s/it// | 13:23 |
| cjwatson | wgrant: or whatever | 13:24 |
| persia | cjwatson, But, yes, there are other ways of expressing disagreement. It may be that "consensus" isn't the right word. My feeling is that enough of us developers were willing to accept a change for one reason or another, or that we would have collectively agreed not to make that change. | 13:25 |
| cjwatson | persia: alternatively: in a structure where enough people feel bound by some kind of authority not to revert something, you can't infer anything useful from a consensus to accept a change | 13:25 |
| cjwatson | so it might be true but is essentially a null statement | 13:25 |
| Laney | yes, I can't say that I would feel socially able to revert such a change, even if I had the technical requirements to do so | 13:26 |
| persia | Possibly. I like to believe that most folk do stuff because they think it's right, rather than because they think they should, but I understand this may not be true. | 13:26 |
| Laney | Anyway, I'm happy to escalate to the TB if people feel that this is appropriate to do so now, given where we are in the release schedule. | 13:32 |
| persia | Laney, You'd really want to first organise both opinions in terms of solid arguments, etc. for presentation, so they can be rationally considered. Otherwise, the meeting will just be noise, which wouldn't help, regardless of your initial position. I'm not saying you should or shouldn't do this, just that if you choose to do it, please do it in a way that doesn't devolve to confusion. | 13:34 |
| Laney | persia: Yes. I'm obviously not interested in creating more noise, just having a decision made either way. | 13:35 |
| Laney | ...and of course guidance on how best to handle/flag up potentially controversial changes in future | 13:35 |
| vish | when does the TB convene? or how to keep track of this? | 13:37 |
| Laney | wiki | 13:37 |
| persia | vish, Subscribe to the TB mailing list. TB meetings are alternate Tuesdays at 14:00 (sometimes UTC, sometimes british time, changing only slightly out of step with the UK) | 13:37 |
| * vish looks up the list | 13:38 | |
| vish | persia: thanks.. | 13:38 |
| === MacSlow|lunch is now known as MacSlow | ||
| pitti | mr_pouit: oh, oops | 13:46 |
| pitti | mr_pouit: shoudl I reassign it or create a new one then? | 13:46 |
| bdrung_ | FYI, the sponsoring overview is not up-to-date due to a bug. I have fixed the bug and you can find a newer overview here (until the fix is merged): http://people.ubuntu.com/~bdrung/sponsoring/ | 13:47 |
| === dendro-afk is now known as dendrobates | ||
| === almaisan-away is now known as al-maisan | ||
| mr_pouit | pitti: mmh, actually, the assignment is probably wrong (xfce 4.6 was released on 2009-02-27, and the bug filed on 2009-04-20, so I think it's already against the new settings manager) | 14:15 |
| doko | bdrung_: could you comment on bug #640567? | 14:24 |
| ubottu | Launchpad bug 640567 in swt-gtk (Ubuntu) "FFe: Candidate revision 3.5.1+versionbump-5ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/640567 | 14:24 |
| bdrung_ | doko: it looks good. | 14:31 |
| bdrung_ | doko: should i sponsor it? | 14:31 |
| doko | bdrung_: well,needs an exception from the release team | 14:32 |
| bdrung_ | doko: Iulian approved it | 14:32 |
| didrocks | doko: thanks for backporting the fix of fullscreen OOo + compiz | 14:34 |
| doko | didrocks: does it work for you? | 14:34 |
| didrocks | doko: not tested here (I have compiz 0.9 for testing), just saw from the changeog. Will try to downgrade and see if it fixes. Does it work for you? I powndered backporting this one as I saw in the upstream bug this wasn't fully working | 14:35 |
| doko | didrocks: it works for me in oowriter, and I can see presentations in full screen mode. | 14:36 |
| didrocks | doko: good news, we'll definitively give it a look before eow | 14:37 |
| didrocks | doko: that worthes a SRU I think. A lot of people should be using OOo to give presentations on lucid | 14:37 |
| === ivoks is now known as ivoks-brb | ||
| doko | didrocks: waits on pitti's approval | 14:38 |
| didrocks | doko: oh nice :) | 14:38 |
| bdrung_ | didrocks: that the panels are over the presentation? | 14:40 |
| didrocks | bdrung_: right | 14:41 |
| bdrung_ | didrocks: nooo. it was a nice feature for me (using two monitors and presenter-console) | 14:41 |
| bdrung_ | :) | 14:41 |
| didrocks | bdrung_: you can avoid updating or create a package which conflicts with latest version :p | 14:42 |
| didrocks | like apt-get install ooo-give-me-broken-panel | 14:42 |
| bdrung_ | :) | 14:42 |
| sladen | pitti: https://bugs.launchpad.net/bugs/625849 that CVE (bzip2) has been published now | 14:45 |
| ubottu | 'Error: Could not parse data returned by Launchpad: HTTP Error 401: Unauthorized\nResponse headers:\n---\ncontent-length: 21\ncontent-type: text/plain\ndate: Mon, 20 Sep 2010 13:45:50 GMT\nserver: zope.server.http (HTTP)\nstatus: 401\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\nBug 625849 is private\n---\n (https://launchpad.net/bugs/625849)' | 14:45 |
| pitti | sladen: I can't access this | 14:46 |
| pitti | sladen: you want the security team to make it public? | 14:46 |
| pitti | kees, jdstrand ^ | 14:46 |
| jdstrand | pitti, sladen, kees: there is other discussion in that bug which should not be made public yet | 14:55 |
| sladen | jdstrand: I don't know, it's private ;-) | 14:56 |
| sladen | jdstrand: but the new version with the fix has now been published (on the bzip.org website) | 14:57 |
| jdstrand | sladen: yes | 14:57 |
| jdstrand | sladen: we have the patch in dapper-maverick for both bzip2 and clamav already | 14:57 |
| jdstrand | (I'm working on publishing USNs as we speak) | 14:58 |
| jdstrand | sladen: the point I was making is there is *other* discussion in that bug that is not public yet | 14:58 |
| smb | jdstrand, kees, pitti I had been discussing the 64bit problems in fglrx after last security update with tseliot. As there might be more to do than just make EXPORT_SYMBOL_GPL a EXPORT_SYMBOL (the function declaration would also need to go somewhere fglrx could use it), I would hope that the problem could be worked-around in fglrx-installer by the code I posted to bug 642518 | 15:22 |
| ubottu | Launchpad bug 642518 in fglrx-installer (Ubuntu Lucid) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,Triaged] https://launchpad.net/bugs/642518 | 15:22 |
| ogra | mvo, bug 643571 for you | 15:22 |
| ubottu | Launchpad bug 643571 in software-center (Ubuntu) "apturl from .desktop file to enable PPA does not work" [High,New] https://launchpad.net/bugs/643571 | 15:22 |
| tseliot | smb jdstrand, kees, pitti: right, I'm getting a 64bit Lucid image to test smb's patch so that hopefully I'll just have to update fglrx | 15:23 |
| pitti | are we even legally allowed to do that? i. e. exporting a new symbol as GPL? | 15:24 |
| smb | pitti, That might be a third issue | 15:24 |
| mvo | thanks ogra | 15:24 |
| smb | The work-around would not need to | 15:24 |
| ogra | mvo, tell me if i do anything wrong | 15:25 |
| pitti | smb: they dropped a GPL symbol in a security patcH? | 15:25 |
| smb | pitti, They changed an inline into a wrapper that is a real function | 15:25 |
| smb | pitti, which is only GPL exported but has the same name of the inline before | 15:26 |
| === ivoks-brb is now known as ivoks | ||
| === zyga is now known as zyga-gone | ||
| === deryck is now known as deryck[lunch] | ||
| === al-maisan is now known as almaisan-away | ||
| ebroder | smb: I like your approach of checking kallsyms better than mine. I think the patch looks fine, for whatever that's worth | 16:08 |
| smb | ebroder, Thanks. :) | 16:08 |
| === almaisan-away is now known as al-maisan | ||
| smb | ebroder, Oh, I see your approach. I must admit that I failed to read through the whole bug report after discussing on irc. In theory the grep might be done against the header as well. Maybe having the advantage to let it compile against a kernel that does not run | 16:12 |
| === oubiwann is now known as oubiwann-away | ||
| === oubiwann-away is now known as oubiwann | ||
| ebroder | smb: Oh, hmm. Good point. If you use kallsyms it'll pick the wrong function when you're building against the new kernel while running the old one | 16:15 |
| smb | Now that you say so... Err, tseliot maybe we should do a hybride of both patches | 16:16 |
| tseliot | smb, ebroder: let me check ebroder's patch | 16:17 |
| smb | tseliot, Apart from doing the check differently it seems there is one half of the checking missing in the wrapper function. ebroder, was this done on purpose? | 16:21 |
| tkamppeter | pitti, hi | 16:21 |
| ebroder | smb: There's similar code for detecting other things there already, so it seemed like a half-decent place to put it | 16:21 |
| cjwatson | ogasawara: can bug 641618 be closed now? the only bug in there that isn't in the kernel I just upgraded to is bug 630885 | 16:22 |
| ubottu | Launchpad bug 641618 in linux (Ubuntu Maverick) "Maverick Kernel Freeze Exception" [High,Confirmed] https://launchpad.net/bugs/641618 | 16:22 |
| ubottu | Launchpad bug 630885 in linux (Ubuntu) "Preinstalled Maverick netbook image has no display on omap3 EVM (no LCD)" [Undecided,In progress] https://launchpad.net/bugs/630885 | 16:22 |
| ogasawara | cjwatson: yep, I'll close it. | 16:23 |
| cjwatson | thanks | 16:23 |
| === mathiaz_ is now known as mathiaz | ||
| smb | ebroder, I was more referring to this check in the kernel compat_alloc_user_space: if (unlikely(((unsigned long) size) > (((compat_uptr_t)~0) >> 1))) | 16:24 |
| ebroder | smb: Oh, hmm. That must have been a mistake on my part | 16:24 |
| ebroder | So your patch to kcl_ioctl.c, and my patch to the make infrastructure? :) | 16:24 |
| smb | Heh, yeah. sort of | 16:25 |
| smb | Though I somehow dropped __user on the variable declaration... | 16:25 |
| tseliot | ebroder, smb: ok, so this would mean that should combine your patches and check the availability of that function in linux/compat.h as ebroder suggested. Is this correct? | 16:28 |
| smb | tseliot, Yes that would be the idea | 16:29 |
| tseliot | ok | 16:29 |
| corecode | hey | 16:30 |
| corecode | i'm always having problems finding the right bzr branch for a package | 16:30 |
| corecode | i'd like to bzr clone the lucid glibc version | 16:31 |
| pitti | corecode: if apt-cache show (or showsrc) shows a Vcs-Bzr:, then that's the one | 16:31 |
| pitti | corecode: otherwise, lp:ubuntu/srcpackagename | 16:31 |
| corecode | no /lucid/ somewhere? | 16:32 |
| corecode | ah, /lucid-updates/eglibc | 16:32 |
| pitti | corecode: right, for the stable branches; without a release name, it's the current dev release (i. e. maverick right now) | 16:36 |
| corecode | how do i know whether to use lucid-updates, lucid-security or plain lucid? | 16:36 |
| pitti | corecode: whichever is most current | 16:38 |
| corecode | strange, my libc does not contain frame pointers, but the rules don't specify -fno-frame-pointer | 16:39 |
| pitti | corecode: you can check with "rmadison packagename", or "apt-cache policy" | 16:39 |
| corecode | thanks | 16:39 |
| corecode | ah, it is called omit-frame-pointer | 16:40 |
| corecode | still not finding anything that would set that | 16:41 |
| tseliot | ebroder, smb: something like this should work: http://pastebin.ubuntu.com/497086/ | 16:52 |
| smb | tseliot, On a quick glance over this looks good to me | 16:54 |
| tkamppeter | pitti, can a correction of a versioned dpendency of ghostscript on gsfonts still get into Maverick, as freeze exception? | 16:54 |
| ebroder | smb, tseliot: Same here | 16:55 |
| tseliot | ebroder, smb: good. I'll test it in both Maverick and Lucid | 16:55 |
| tseliot | ebroder, smb: thanks for your help | 16:55 |
| === deryck[lunch] is now known as deryck | ||
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| ebroder | tseliot: No problem. Let me know if there's anything else I can do to help | 17:24 |
| === bjf[afk] is now known as bjf | ||
| === amitk is now known as amitk-afk | ||
| === beuno is now known as beuno-lunch | ||
| tseliot | ebroder, smb: even though $ARCH_COMPAT_ALLOC_USER_SPACE is set to 0 in lucid (according to make.sh.log), the patch still makes it use the arch_compat_ function. Any ideas? | 17:39 |
| tseliot | ebroder, smb: oh, now I see why | 17:40 |
| tseliot | because it's defined and we check it with ifdef | 17:40 |
| tseliot | and it's always defined | 17:40 |
| smb | tseliot, Oops, yes | 17:40 |
| smb | Needs to be re-phrased to another #if construct or probably the code which sets it to 0 removed | 17:42 |
| tseliot | ebroder, smb: so I should just do this in the makefile: ifeq ($(ARCH_COMPAT_ALLOC_USER_SPACE), 1), EXTRA_CFLAGS += -DARCH_COMPAT_ALLOC_USER_SPACE, endif | 17:45 |
| tseliot | or whatever other solution looks better | 17:46 |
| smb | tseliot, This sound reasonable, just be careful with that section before having a backslash at the end, so the hunk needs to be seperated by an empty line | 17:46 |
| tseliot | smb: right | 17:47 |
| pitti | tkamppeter: sure, please just upload it | 17:47 |
| fta | cjwatson, hi, do you have time for the libvpx sync request from last week? | 17:48 |
| tkamppeter | pitti, OK. | 17:49 |
| corecode | how would i run debuild with make -j? | 17:49 |
| corecode | i have 24 cpus | 17:49 |
| corecode | and it is only using 1 :) | 17:49 |
| ebroder | tseliot: You could do #if ARCH_... instead of #ifdef, but your way sounds fine too | 17:55 |
| corecode | oh, just -j | 17:56 |
| ebroder | corecode: Setting DEB_BUILD_OPTIONS=parallel=n is the same as -j n, but it's up to the package in question to support that - not all do | 17:56 |
| corecode | ah ok | 17:57 |
| tseliot | ebroder, smb: the final version of the patch works fine in Lucid and Maverick. I'll request an SRU tomorrow. | 17:57 |
| smb | tseliot, Ok, thanks for doing all the tests and integration work | 17:58 |
| tseliot | smb: np | 17:59 |
| cjwatson | fta: need to wait for the fix for bug 635591 to be rolled out | 18:03 |
| ubottu | Launchpad bug 635591 in Soyuz "Regression: syncing packages with UTF-8 changelogs fails" [High,Fix committed] https://launchpad.net/bugs/635591 | 18:03 |
| fta | oh, ok | 18:04 |
| tkamppeter | pitti, ghostscript_8.71.dfsg.2-0ubuntu7 uploaded. | 18:10 |
| corecode | can i set CFLAGS_APPEND for dpkg-buildpackage in a config file? | 18:15 |
| tkamppeter | pitti, fixed also a trivial typo in gsfonts: gsfonts_8.11+urwcyr1.0.7~pre44-4.2ubuntu1 | 18:18 |
| pitti | tkamppeter: thanks | 18:20 |
| pitti | . o O { try to quickly speak this version number three times } | 18:21 |
| === al-maisan is now known as almaisan-away | ||
| === ivoks is now known as away | ||
| === away is now known as ivoks-away | ||
| corecode | should debuild -e CFLAGS_APPEND=-fno-omit-frame-pointer work? because i don't see it appearing | 18:27 |
| bdrung_ | doko: bug #643107 is your issue. eclipse builds on armel in Debian. | 18:28 |
| ubottu | Launchpad bug 643107 in openjdk-6 (Ubuntu) "Eclipse 3.5.2-6 FTBFS on armel" [Medium,Confirmed] https://launchpad.net/bugs/643107 | 18:28 |
| cjwatson | corecode: I think that should be DEB_CFLAGS_APPEND | 18:29 |
| cjwatson | corecode: it might still be overridden by debian/rules or by a Makefile in the package | 18:29 |
| corecode | but it says the package may not override it | 18:30 |
| cjwatson | that is an aspiration rather than truth | 18:30 |
| cjwatson | (not entirely sure where you're seeing "it" say that, either ...) | 18:31 |
| corecode | dpkg-buildpackage | 18:32 |
| cjwatson | don't see anything like that in the current dpkg-buildpackage(1) manual page | 18:33 |
| corecode | CFLAGS_APPEND | 18:34 |
| corecode | Optimization options appended to the compiler flags, which must | 18:34 |
| corecode | not be overwritten by the package (mostly used to for test | 18:34 |
| corecode | builds). Default value: empty. | 18:34 |
| cjwatson | it doesn't say that any more in maverick | 18:34 |
| cjwatson | which might suggest that it was never right to start with :) | 18:34 |
| corecode | oh duh | 18:34 |
| corecode | so how do i tell it now to build with a frame pointer? | 18:35 |
| cjwatson | corecode: the easiest way is always to modify debian/rules | 18:35 |
| cjwatson | corecode: all this DEB_CFLAGS_APPEND etc. stuff is an attempt to make that unnecessary in the future, but it's early days | 18:36 |
| cjwatson | corecode: and you don't sound like your goal is debugging weird stuff in dpkg-dev, but rather getting your job done. thus, modify debian/rules. | 18:36 |
| corecode | thanks | 18:37 |
| === beuno-lunch is now known as beuno | ||
| === ivoks-away is now known as ivoks | ||
| === ivoks is now known as ivoks-dinner | ||
| SpamapS | lifeless: I think here is an appropriate place for the java discussion actually. | 19:56 |
| SpamapS | lifeless: /win 23 | 19:58 |
| SpamapS | I keep doing that. :-P | 19:58 |
| lifeless | hah :) | 19:58 |
| SpamapS | lifeless: a side tangent to the java discussion is your recent mentioning of Cassandra w.r.t. Ubuntu One... | 19:59 |
| SpamapS | I've been reading the Cassandra mailing lists for about 4 months now.. and I am beginning to think its one of the most misunderstood databases in existence. | 20:00 |
| lifeless | heh | 20:01 |
| lifeless | sorry, phone call, paying attention again in abit | 20:01 |
| SpamapS | np | 20:01 |
| sladen | rickspencer3: | 20:26 |
| smoser | ugh. i feel beaten. | 20:30 |
| smoser | in gnu make: | 20:30 |
| smoser | x := $(shell case 1 in 1): ;; 2) echo 2;; ; esac) | 20:31 |
| smoser | i cant seem to escape the close parens from indicating the end of $(shell) | 20:31 |
| smoser | any ideas ? | 20:31 |
| soren | smoser: Would you feel more beat or less beat if you resorted to a couple of if, if/else, else things? | 20:33 |
| smoser | http://pastebin.com/dnbeDQs6 is my pathetic attempt. | 20:33 |
| smoser | it is nicer to me when i act like that, yes soren. | 20:33 |
| ebroder | smoser: close_paren = ) | 20:34 |
| ebroder | $(shell case $var in 1${close_paren} [...]) | 20:34 |
| soren | *chuckle* | 20:34 |
| ebroder | It's what cdbs does | 20:34 |
| soren | smoser: Well, you /could/ used backticks, but I can't really bring myself to recommend it. | 20:34 |
| soren | smoser: Because, you know, they're evil and all that. | 20:35 |
| smoser | ebroder, nice. | 20:35 |
| soren | smoser: I'm sure if yo uused ebroder's suggestion, both you and make would walk away feeling like you've won. | 20:36 |
| ebroder | I don't know...I'm pretty sure that make is winning no matter how you solve the problem | 20:36 |
| smoser | well, its crazy, but this works: http://pastebin.com/1V2npC0D | 20:42 |
| === ogra_ is now known as ogra_ac | ||
| lifeless | barry: hi | 21:08 |
| lifeless | barry: your friend hasn't replied | 21:08 |
| barry | lifeless: :/ | 21:08 |
| === amitk-afk is now known as amitk | ||
| lifeless | barry: did my ''Python packaging, dependencies, upstream facilities'' mail make sense to you? | 21:09 |
| lifeless | SpamapS: (off the phone) | 21:10 |
| * barry re-reads ;) | 21:11 | |
| barry | lifeless: can i forward this to debian-python? | 21:13 |
| lifeless | of course; I'm also sending it to Jos | 21:14 |
| barry | lifeless: cool | 21:14 |
| SpamapS | lifeless: so, upstream facilities.. does that mean maven/cpan/pypi/rubygems ? | 21:16 |
| lifeless | SpamapS: whats your mail | 21:16 |
| lifeless | I'll copy you :P | 21:16 |
| SpamapS | lifeless: clint.byrum@canonical.com or clint@ubuntu.com | 21:17 |
| lifeless | SpamapS: check your mail :P | 21:18 |
| SpamapS | wom 3 | 21:19 |
| SpamapS | ugh must get new keyboard | 21:19 |
| === ogra_ is now known as ogra_ac | ||
| SpamapS | lifeless: indeed, I think the high level idea needs to be that the installed package versions need to become arrays instead of scalars.. | 21:29 |
| SpamapS | lifeless: Tho, I think the way many are handling this is with funny thigns like lxc/openvz .. where they just build a new lightweight machine w/ the versions they want installed. | 21:30 |
| lifeless | SpamapS: ugh | 21:30 |
| === tkamppeter_ is now known as tkamppeter | ||
| SpamapS | lifeless: if something can accurately state its dependencies, then we can certainly assemble them in a number of ways. dpkg wants to satisfy each requirement with *one* package... but maven, for instance, allows one to simply install multiple versions, and picks one for the current build. | 21:32 |
| SpamapS | lifeless: so if launchpad can state its dependencies, a program could probably assemble them into a private python library to override whatever is in the system's library. | 21:34 |
| === warp11 is now known as warp10 | ||
| ari-tczew | doko: why you use *ubuntu2 to *ubuntu3 change in SRU? it should be *ubuntu2.1 | 21:58 |
| kklimonda | ari-tczew: it doesn't have to be - it just has to be lower than the version from the next release | 21:59 |
| ari-tczew | very interesting | 22:02 |
| === dendrobates is now known as dendro-afk | ||
| === dendro-afk is now known as dendrobates | ||
| === ivoks-dinner is now known as ivoks | ||
| SpamapS | lifeless: I wonder if ensemble has something to help with this. :) | 22:31 |
| lifeless | SpamapS: I think the basic packaging layer needs fixing | 22:31 |
| lifeless | SpamapS: lxc stuff and vms are nice tech but totally different layers to this | 22:32 |
| lifeless | SpamapS: the same issue turns up if you have two different python apps that have mutual incompatabilities with package A | 22:32 |
| lifeless | and as you say, maven handles this better (and so we should also package java properly too, not in the flattened manner we do - as we discussed the other day) | 22:32 |
| SpamapS | lifeless: debhelper type build tools can actualy solve this IMO. We just have to become comfortable with packages that have versions in their names.. which we already do when forced.. right? | 22:37 |
| SpamapS | I mean, you can tell dpkg that launchpad needs python-super-library (>= 1.9, << 2.0) .. if python-super-library is kept as a virtual package provided by all versions of python-super-library.. this works.. no? | 22:39 |
| SpamapS | probably not actually now that I type it out | 22:39 |
| SpamapS | Provides: default-mta, mail-transport-agent, postfix-tls | 22:40 |
| SpamapS | ||/ Name Version Description | 22:40 |
| SpamapS | un default-mta <none> (no description available) | 22:40 |
| lifeless | SpamapS: standard policy for C/C++/CLR packages is to have the soname in the name | 22:41 |
| lifeless | SpamapS: I'm proposing the same thing | 22:41 |
| lifeless | s/packages/library packages/ | 22:42 |
| SpamapS | Hmm, Ok. | 22:42 |
| SpamapS | Is there an easy way to detect API changes in a python library? | 22:42 |
| === bjf is now known as bjf[afk] | ||
| kklimonda | no | 22:44 |
| SpamapS | So right now your only hope is update lib, and run your unit tests? | 22:45 |
| lifeless | thats not entirely true | 22:45 |
| lifeless | setuptools has declarative per-version module obtaining glue | 22:46 |
| lifeless | which isn't upstream really; which is why I initially only wrote barry saying 'upstream this man' | 22:46 |
| lifeless | detecting an API change really isn't all that important in the first iteration of improvements, | 22:46 |
| lifeless | the big issue is being *able* to represent the thing in dpkg; being able to have casual 'import foo' still work sanely and allowing more complex setups to work properly. | 22:47 |
| SpamapS | I'm just trying to get at what would stand in for soname in a python package | 22:47 |
| lifeless | right now we can't represent 1.2 and 1.3, we can have casual import foo work, but more complex setups fail | 22:48 |
| lifeless | SpamapS: upstream releases ;) | 22:48 |
| lifeless | SpamapS: policy vs mechanism :) | 22:48 |
| SpamapS | in the pylons framework, for instance, they simply have you running a shell with the python include path prepended.. and easy_install/etc. everything just dumps stuff in your project's lib | 22:48 |
| lifeless | SpamapS: which is terrible. | 22:48 |
| SpamapS | totally | 22:48 |
| lifeless | bbiab | 22:48 |
| SpamapS | thats the length at which they have gone to get around this | 22:48 |
| corecode | % bzr branch lp:ubuntu/mdadm | 22:50 |
| corecode | bzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: CannotHaveLinkedBranch: <Distribution \'Ubuntu\' (ubuntu)> cannot have linked branches.">') | 22:50 |
| corecode | what am i doing wrong? | 22:50 |
| jml | corecode, that's a known bug in Launchpad right now. | 22:51 |
| corecode | oh | 22:52 |
| corecode | so, how do i do it right? | 22:52 |
| corecode | because my actual issue is: | 22:53 |
| corecode | % sudo lvresize -l+100%PVS media/media | 22:53 |
| corecode | zsh: segmentation fault sudo lvresize -l+100%PVS media/media | 22:53 |
| jml | corecode, well, actually, https://code.edge.launchpad.net/ubuntu/+source/mdadm says there aren't even any branches for the package on LP | 22:53 |
| corecode | so how is that package maintained then? | 22:54 |
| corecode | is it possible that it isn't in bzr? | 22:54 |
| micahg | corecode: yes, some packages there are issues with importing | 22:55 |
| corecode | oh, too bad | 22:56 |
| micahg | corecode: Debian has mdadm in git | 22:57 |
| corecode | also i want lvm | 22:57 |
| corecode | no food = bad concentration | 22:57 |
| corecode | :) | 22:57 |
| * micahg wonders how we got so far behing | 22:57 | |
| micahg | *behind | 22:57 |
| corecode | how behind | 22:58 |
| micahg | testing at 3.1.4, maverick at 2.6.7.1 | 22:58 |
| SpamapS | mdadm is a mess | 23:00 |
| SpamapS | look at the bugs | 23:00 |
| corecode | uh | 23:01 |
| micahg | SpamapS: I would think that to be expected with 7 kernel revisions and no updates | 23:01 |
| corecode | i thought every release takes all testing | 23:01 |
| micahg | corecode: no, not if there are Ubuntu changes, someone needs to do a merge | 23:02 |
| corecode | oh wow | 23:02 |
| SpamapS | merging didn't get much priority this cycle | 23:02 |
| * SpamapS vows to do more merges for natty | 23:03 | |
| corecode | if there was an easy way for me to do the merge, i'd occasionally do a merge | 23:04 |
| SpamapS | I wonder how long squeeze will be frozen? The longer its frozen, the bigger our delta gets. | 23:04 |
| SpamapS | corecode: merging is pretty easy really | 23:04 |
| SpamapS | unless its one of the things that we maintain as fundamentally different from debian.. | 23:04 |
| SpamapS | https://merges.ubuntu.com/main.html | 23:06 |
| corecode | i know | 23:06 |
| SpamapS | the stats at the bottom are interesting | 23:06 |
| corecode | if there was one script i could run, and then i have to fix the collisions | 23:06 |
| corecode | fine | 23:06 |
| SpamapS | grab-merge in that dir pretty much does that | 23:06 |
| corecode | great; now i know where lvm is segfaulting | 23:07 |
| corecode | but i don't know how to fix it | 23:07 |
| * ari-tczew encourages SpamapS and corecode to do some merges for natty development. :) | 23:09 | |
| amikrop | Hello, where can I find some packages in which the code is Python and are packaged using CDBS? | 23:16 |
| amikrop | I mean, some Python apps packaged with CDBS. | 23:17 |
| SpamapS | amikrop: debian python packaging has been dominated by debhelper from what I've seen | 23:19 |
| achiang | is there a proper way to override a setting in /etc/modprobe.d/alsa-base.conf ? can i drop a file into that directory that overrides it somehow? | 23:24 |
| achiang | [i have a brute force method that works, just wondering if there's a better way to do it] | 23:24 |
| Keybuk | curious | 23:30 |
| Keybuk | I wonder whether X is using the i915 or nvidia card | 23:30 |
| achiang | shouldn't it say in Xorg.0.log? | 23:31 |
| Keybuk | seems to only detect the nvidia one | 23:35 |
| Keybuk | the Intel one doesn't even show up in lspci | 23:35 |
| Keybuk | well, it's in the chip I guess | 23:39 |
| amikrop | SpamapS: I thought CDBS was using (extending?) debhelper | 23:42 |
| cjwatson | corecode: psurbhi has been working on the big mdadm merge, but it took a bit longer than expected and will be natty at this point | 23:42 |
| cjwatson | smoser: re your make problem, there's a simpler way | 23:42 |
| cjwatson | smoser: it doesn't seem to be widely known, but you're allowed to put an open parenthesis before the pattern as well as a close parenthesis after it | 23:43 |
| cjwatson | smoser: so if you write (1) rather than 1), the parentheses are balanced and make will be happier with you | 23:44 |
| cjwatson | smoser: there are one or two other situations where this trick is useful too, such as a case statement inside $() | 23:44 |
| cjwatson | (as in shell command substitution, not make function invocation) | 23:44 |
| === zyga-gone is now known as zyga | ||
| cjwatson | heh, cdbs doesn't use this - I may not know more make than cdbs, but I'm betting I know more shell ;-) | 23:45 |
| === ivoks is now known as ivoks-afk | ||
| superm1 | /j #ubuntu-docs | 23:52 |
| superm1 | oops | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
