/srv/irclogs.ubuntu.com/2010/08/28/#ubuntu-devel.txt

indy__Does https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/582199/comments/111 mean I will have to live with the bug until Maverick is released?00:08
ubottuLaunchpad bug 582199 in alsa-driver (Ubuntu) "No sound on Dell Optiplex 380 (ALC269Q, probably new chip)" [Medium,Fix released]00:08
xnoxindy__, $ update-manager -d #and click to upgrade to 10.10 ;-)00:10
xnoxbut that's if you are ready to upgrade now00:10
xnoxyou can request it to be considered for lucid SRU00:10
xnox!SRU00:10
ubottuStable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates00:10
chrisccoulsonindy__, use the "Nominate for release" button at the top of the bug00:12
indy__xnox, it's vital for me (and every other one using DELL OPTIPLEX 380) to have sound in my system :)00:12
indy__so, thanks, I will nominate it ;)00:12
penguin42you'd think at some point people would stop reinventing how to do simple sound cards00:16
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
halvorsHi!01:21
halvorsI have some important issue to report.01:21
halvorsBut didn't got it done by Apport.01:21
halvorsLanguage Support does not download new language.01:22
halvorsThis is for the maverick alpha-3 latest update.01:22
halvorsIs there some developers here who can try get it fixed?01:22
persiaCould someone give-back gstreamer0.10/powerpc?  https://launchpad.net/ubuntu/+source/gstreamer0.10/0.10.30-1build2/+build/191336601:43
cjwatsonpersia: done01:46
persiacjwatson, Thank you.01:46
cjwatsonhttp://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-08-28-windows-applications-making-grub2-unbootable.html - if you suffer from this problem, please follow the instructions in this post to give me more information01:49
=== steve|m1 is now known as steve|m
pranay_09in spd-say the language option is just for the accent change?03:33
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
persiaCould someone please give-back utouch-gesturetest/powerpc : https://launchpad.net/ubuntu/+source/utouch-gesturetest/1.0.4-0ubuntu1/+build/191784907:58
macogive-back?07:58
macodid someone steal it?07:58
persia"give-back" is short for "Re-add the source to the buildd queue".08:00
persiaI suspect it is also the name of some script that is part of the wanna-build suite, or similar, but that's conjecture.08:01
persiaSo, I'm asking that someone with upload rights to that package visit that web page and press the shiny button to get it off the FTBFS list.08:02
macoyou dont have upload rights to it?08:03
* vish wonders why persia explained! maco knows what give-back means! we just need to turn-off maco's sarcastic-mode! ;p08:04
persiamaco, Nope.08:04
cody-somervillepersia, given-back08:04
persiacody-somerville, Thanks.08:04
macopersia: i thought you were core dev...08:09
persiaEveryone thinks that for some reason.08:09
persiaBut until recently, I had no interest in being core-dev.08:10
macoi think we assume if youre on the MC youre a core dev08:10
persiaSilly assumption.  Only folks that actually work on core stuff ought be core-dev.08:11
macoother direction...08:11
macomore like assumed that only core devs would get elected08:11
persiaMy main motivation for doing it now is that I've become a lot more active in powerpc and armel porting, as well as flavour bring-up, all of which essentially requires core-dev.08:11
persiaI can't think of any good reason to only select core-dev.  I'd rather have folks from a variety of development groups, so we're more likely to have significant personal history with new applicants.08:12
* maco headdesks at a PM she just got08:12
persiaImportant to have one or two highly respected core-dev to help ensure that the requirements for core-dev aren't loosened, but even a majority is probably overkill.08:13
persiaCould someone give-back xserver-xorg-input-evdev/amd64 : https://launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/1:2.3.2-6ubuntu1/+build/193143508:13
cody-somervilledone08:14
persiacody-somerville, Thank you.08:14
* nigelb wonders about the content of the PM08:14
persiaSomething that caused a violation of information hygine.  Be careful: it may be contagious!08:14
nigelbheh08:15
maconigelb: female...linux...surprise08:15
persiaNo sexism.08:15
nigelbmaco: Sigh.08:15
nigelb!gender08:15
ubottuyes, I can confirm I am a female bot :)08:15
nigelb:)08:16
persiaUgh.08:16
vishargh!08:16
cody-somervillemoo08:16
macoapt?08:16
nigelbheh, quite fun.08:16
persiaNo super cow powers.08:16
vishsuper moo! o/08:16
macoone of my laptops has an apt-get sticker with a cow on it08:17
nigelbone of....08:17
maconigelb: the ugly one with all the stickesr08:17
nigelbmaco: that /isn't/ ugly :)08:18
nigelbBeauty is in the eyes of the beholder.08:18
macothe stickered one is stickered to hide the ugly08:18
persiaCould someone please give-back unity/amd64 : https://launchpad.net/ubuntu/+source/unity/0.2.32-0ubuntu2/+build/193594608:20
* persia is stumped at qimageblitz and decides not to submit a patch making it build on amd64/armel/powerpc that breaks i38608:21
nigelbpersia: you know, with so many of us asuming you're core dev, its probably time to be one....08:21
persiaThat's kinda why I'm working on main stuff now.08:21
cody-somervillepersia, done08:21
nigelb\o/08:21
persiaUntil I get some real work done in main, I wouldn't confirm myself as core-dev, so wouldn't ask others to do so.08:22
nigelbYou're membership meeting would be one that we'd always point out to others :D08:22
nigelbDMB member would still have to come for a meeting and no shortcuts etc.08:22
persiaThere's already examples of that from the MC.08:23
persiacody-somerville, Thank you.08:23
nigelbAh.  I'm new.  Haven't looked up MC logs.08:23
nigelbs/new/sortof new/08:23
persianew is relative.  I'm new in some collections of folks.08:24
nigelb:)08:24
=== yofel_ is now known as yofel
=== bilalakhtar_ is now known as bilalakhtar
PadhuHi10:24
PadhuHi10:25
=== apache2logger is now known as apachelogger
persiaCould someone help me understand tickcount?  there's a test that seems like it should pass that fails on powerpc and has been subverted to be wrong by patching on armel and i386.  I'd really appreciate a second pair of eyes on it, to help me understand if it's subtly broken everywhere, or if the logic is wrong.10:45
persiaThe specific point of confusion is in test_difference_wrap in test_tickcount.py (and it's a small enough program it should be obvious from source inspection)10:46
Gpersia: without looking at the source etc, when you are talking about ticks are you talking about time ticks etc?11:04
* G grabs the source in the meantime11:05
persiaYep.11:05
persiaBut there seems to be an off-by-one error somehow.11:05
persiaThat said, I don't see why, since UINT_MAX is the same for every architecture in the set i386/amd64/armel/powerpc11:06
Gpersia: something certainly doesn't look right11:11
persiaI'm 99% certain the armel and i386 test hack patch is wrong.11:12
persiaBut strangely, it passed on amd64.11:13
Gwell on amd64 I get the right result11:13
Gyeah11:13
Gpersia: let me hunt down a 32bit VM :)11:13
persiaWhere it gets extra confusing is if I test with numbers in my python interpreter and a short c hack to show UINT_MAX, I can't see why it should pass for amd64.11:13
persia(or rather, why the result would be any different than that for powerpc, which is my reference)11:14
persiaG, Also, thanks :)11:14
Gpersia: the only 32bit VM I have is RHEL... but I'll also have a look on my mac (i386) as well11:16
persiaI'd suggest trying RHEL first: there's nothing obviously distro-specific in the code.  It might work on MacOS X, but I'm less confident of similarity of python interpreters.11:16
Gyeah, thats my plan11:17
nigelbcjwatson: Re: GRUB and windows - A friend's Dell had a similar issue.  If we booted into windows, it refused to boot up (I suspect GRUB was getting re-written).  He finally reinstalled windows to get the Windows Boot loader11:26
nigelb(Of note, Windows 7 Ultimate and Ubuntu Lucid)11:26
Gpersia: ha I see exactly what you mean11:28
Gpersia: how is this for an 'oddity' though:11:29
GRHEL5:  tickcount.difference(20, -10)  returns -3111:30
persiaDo you understand why it does that?  If there's an explanation that makes sense, I think it'd be good to patch it so that 32-bit architectures return 21 and 64-bit architectures return 20.  If there's no explanation, the current patch is hiding bugs.11:30
GLucid 64bit returns 429496726511:30
Gthere has to be a bug somewhere, I'm sure of it11:30
persia-31 is really 4294967264 (uint vs. int)11:30
Gahhh good point11:30
persiaright.  I get 4294967264 on powerpc too, and apparently chuck got it on armel.11:31
Glet me have a play on OSX11:31
persiaBut when I follow the program logic manually, I get -429496726511:31
Gwon't take a minute11:31
persia(any arch)11:31
persiaErr, 429496726511:32
lanoxxjames_w, u there?11:32
Gpersia: okay, OSX 10.6.4 produces the AMD64 results11:35
persiaAnd that's 32-bit OS X?11:36
Gyeah, OSX Desktop11:36
Guname -a shows i38611:36
* G tries something11:37
cjwatsonnigelb: can he get me the specific information I requested?11:38
cjwatsonnigelb: I don't really need more reports without that information - if you look at the bug, I have plenty ;-)  What I need is the specific data that would let me detect the problem.11:39
cjwatsonnigelb: perhaps reinstall grub2 to recreate the problem, with the aid of a live CD?11:43
Gpersia: I've got an idea...11:55
Gpersia: on a 64bit AMD system.... 'diff' is a 'long int', UINT_MAX is an unsigned_int11:56
persiaAnd on a 32-bit system?11:56
persiaPython is telling me I'm dealing with longs when I use large numbers like that.11:57
Ghold on, just trying to work out, because in my printf, C didn't complain about using %u for either11:57
Gwhich is unsigned int for both11:57
* persia is trying to build current tickcount against lucid python, expecting it to fail.11:57
Geven though diff is defined as 'long'11:58
persiaprintf does an implicit cast when needed.11:58
Gbut yeah, using a calculator w/i GNOME works fine, but as soon as I do it in C it goes haywire12:00
persiaSo, in lucid, I get 20, and in maverick I get 21 when executing the test on i386.12:01
persiaFor precisely the same tickcount source.12:01
persiaWhich makes me think that this is a regression in python, or in gcc.  I'm not sure I like that implication.12:01
Gpersia: http://pastebin.com/ijXXZpzJ12:02
GI'm hazarding a guess at gcc12:02
geserpersia: I can reproduce it on 64-bit in maverick (21 != 20) when I change the "I" to "L" in the test suite (use unsigned long instead of unsigned int)12:03
persiageser, So, should the testsuite use 'L' and look for 21, or is there a bug in python/gcc somewhere?12:05
geserso at least the test suite is buggy to use "uint_max" when the C code uses long12:05
Gpersia: actually, I'm just using the code after 64-bit everywhere now12:05
* persia is now completely certain the current patch is wrong12:05
Gso with the same code on: Lucid 64, RHEL5u4 i386, OSX i386, I get 20 on Lucid & OSX, and 21 on RHEL12:06
* G tries Maverick12:06
geserpersia: not sure yet, I first tried to reproduce it on 64bit12:06
GMaverick 64bit produces 2012:06
geserG: with "I" or "L" in the test suite?12:07
Ggeser: http://pastebin.com/6AmrqqFd12:07
Ggeser: I'm removing the python factor all together12:07
persiaWithin lucid/maverick powerpc/armel, all four produce 21.12:09
Gpersia: 32 bit?12:09
persiaYes.12:09
Gmy Lucid/Mav envs are 64bit12:09
* persia doesn't have any ppc64 hardware, and doesn't know of any arm64 hardware12:09
geserG: long is 64bit while UINT_MAX only 32bit; make old, new, diff an int and you get 2112:10
Ggcc converts long to int on 32bit systems?12:11
geserhmm, can someone with 32bit check "sizeof(long)"?12:12
Gwill do12:12
G412:13
geseron 64bit you get 8 for sizeof(long)12:13
Gokay, so the problem is then, that what, the numbers are wrapping around causing an extra figure or something?12:14
geserso using UINT_MAX for checking an wraparound of a long looks wrong12:14
persiaBut why would we see *different* behaviour for lucid and maverick for i386?12:15
persiaWith lucid, I get 20 on i386.  With maverick, I get 21.12:15
Gpersia: with that C code I pastebined?12:15
Gor w/ the python lib?12:15
persiaWith maverick tickcount source.12:15
* persia runs the C12:15
persiaDiff = 21, UINT_MAX = 4294967295(maverick-i386)12:18
persiaDiff = 21, UINT_MAX = 4294967295(lucid-i386)12:18
Gthats the code that the python unittest is basically running from what I can see12:18
persiaSo yeah, the change is in Python, and it was buggy in Lucid and fixed in Maverick12:18
persiaSo now the test suite is wrong12:18
Gpersia: well the only difference is the tickcounter includes python.h instead of limits.h12:19
Gerrr Python.h12:19
Gpersia: so try changing the #include <limits.h> to #include <Python.h>12:20
persiaThat's not the issue.  maverick/powerpc and maverick/amd64 both have 4294967295 for UINT_MAX in Python.h12:20
Gand if that doesn't work, change 'diff' to 'PyInt_FromLong(diff)' in the printf12:20
persiaNo, I'm convinced that geser has the right solution: the testcase should use 'L' rather than 'I' and look for 21 rather than 20 on all architectures.12:21
geserand also use ULONG_MAX in the C code for the wrap-around12:22
persiageser, Do you want to patch it to do that?  I can, but since it's your work, and you have the same incentives as I ... :)12:24
* G has a look12:25
gesercan do12:25
geseris 21 really the right result for this?12:25
Ggeser: I'm just seeing if I agree :)12:26
persiaI don't know, which is why I asked for help.  G's C code seems to imply it ought be.12:26
persiaI'm happy to test-build for all four architectures, given a patch, just to confirm.12:27
geserusing G C code and using the same computation like the python code for old and new I get also 2112:28
Gyeah, I'm confident that changing all references from int to long gets 2112:29
Ggoing from python to C etc12:29
geserI guess 21 is the correct result as ULONG_MAX is odd12:29
geserso ULONG_MAX/2 gets round down to the next integer12:30
geserwhich results then to the extra "1" when subtracting later ULONG_MAX from that value12:30
nigelbcjwatson: I can try asking him, but I'm not sure if he'll agree.  I'll look at the bug report again to see what you want and try to get it.12:31
Ghttp://pastebin.com/JTSkfiem12:31
Ggeser: with that I get consistency between 32bit & 64bit12:31
Gof course, changing the values for old & new on 32bit to what python says they should be :)12:32
Gpersia: a nice little brain workout none the less :)12:33
persiageser, Shouldn't ULONG_MAX *always* be odd?  We start counting at 0 after all.12:35
persiaBut lifeless put 20 originally for some reason, which I'm not sure I understand.12:36
geserpersia: yes, it's 2^32-112:36
geseror 2^64-112:36
geserwith the 0 you get 2^32 or 2^64 numbers12:36
persiaWell, 2^n-1 is always odd, so 21 feels right.  Doesn't explain why lifeless put 20.12:36
=== dendro-afk is now known as dendrobates
persiaUnless there was some other bug that got fixed, and he just put the value he was getting.12:37
cjwatsonnigelb: it's all on my blog12:38
GI guess that issue can be fixed once & for all now :)12:38
cjwatsonnigelb: though comment 4 on the bug is pretty much the same12:38
nigelbcjwatson: heh, my ping was in response to your blog post.  You apparently dont have a comment system :p12:39
Gnigelb: with the amount of spam comments these days I don't blame people who don't have comment systems :)12:40
nigelbG: well, comments can be moderated :)12:43
Gtrue I guess12:43
geserpersia: http://paste.ubuntu.com/484917/12:43
geserI didn't check if the comment in the test suite is still true12:44
Ggeser: looks right to me12:44
persiaSo we're changing all the ints to longs.  This is fairly normal 64-bit porting.12:46
persiaOn the other hand, why does it work with long and not int?12:47
* persia still thinks there's a bug somewhere)12:47
persiaAre we wrapping something unexpectedly?12:47
Gpersia: I'd say so yeah12:47
persiaAre we converting to the wrong types somewhere?12:47
geserpersia: the problems seems to be that the code uses long (32bit vs 64bit) while the test case is always done with 32bit12:49
persiaThe usual reason to use long rather than int in 64-bit porting is some sort of implicit pointer case.12:49
persias/case/cast/12:49
geseron 32bit archs you the get overflow -> 21 while on 64bit you don't get one -> 2012:49
persiaAha!12:49
persiaBecause of differences between Python and C type definitions?12:50
persiaNo just confusion.  Right.  Testing the patch.12:50
persiaThis replaces zul&ttx7s patch, right?12:50
geseryes, that replaces the existing patch12:50
geserpersia: the problem was the the constants used (UINT_MAX) didn't match the data types used (long)12:51
geserit worked on 32bit because sizeof(int)==sizeof(long) but that's not true on 64bit12:52
persiaRight.  I think that's a good place for the bug then :)12:53
cjwatsonnigelb: yes, it's pretty much deliberate12:53
cjwatsonpersia: you mentioned that printf does an implicit cast - you know that isn't necessarily so, right?12:53
cjwatsonvarargs -> weird12:54
cjwatsonhaven't looked at the code12:54
persiacjwatson, It isn't?  I thought that when you used one type in a format specifier and another as an argument, it tried to cast.12:54
* persia is glad to be disabused12:54
cjwatsonI'd be surprised12:54
cjwatsongcc warns if there's a mismatch12:55
cjwatsonyou could easily be ending up with the first half of a long or something12:56
persiaAnd it just happens to appear to work for small numbers.  This makes a lot more sense.12:56
=== dendrobates is now known as dendro-afk
persiageser, Builds successfully (including test run) for i386/amd64/armel/powerpc : go for it.13:05
=== tkamppeter_ is now known as tkamppeter
bilalakhtarWill bug #619678 need UIFe ?13:27
ubottuLaunchpad bug 619678 in nautilus (Ubuntu) "removing the sidebar closing button" [Wishlist,Triaged] https://launchpad.net/bugs/61967813:27
geserpersia: do you have a sponsor at hand for it?13:30
persiaNope.  It was just bothering me.13:31
geserok, I'll put it into the sponsoring queue and look for a sponsor after the beta freeze gets lifted13:32
persiaMight get found randomly by then :)13:32
* persia has had surprisingly good luck with main sponsorships lately13:33
persiaI can't figure out gawk/amd64 or gcj-4.4/amd64.  likewise-open/powerpc seems to be intentional by upstream.  openjdk-6/armel and openoffice,org/armel are claimed, debian-installer waits on archive recovery, libvirt/powerpc runs into some limitations with how poorly powerpc supports emulation (as a host), and the rest are either depwaits or have bugs awaiting sponsors.13:35
Gpersia: whats this you are refering to?13:37
G(you got my attention at libvirt) :P13:37
persiahttp://qa.ubuntuwire.com/ftbfs/ for main.13:38
persiaBut the libvirt one needs someone with a powerpc, and I *think* it really needs work on qemu-kvm, so perhaps not your cup of tea :)13:39
persiaThat said, there's heaps of stuff in universe (which I was saving for tomorrow).  Please feel free to beat me to it :)13:39
* persia mostly focuses on armel/powerpc stuff anyway, figuring lots of folks have i386/amd64 HW13:40
* bilalakhtar would like to know if the people over here like repeated questions and if they don't mind, then he would repeat his question13:40
Gpersia: the libvirt test that fails has been disabled in Fedora since 0.8.213:41
persiabilalakhtar, Generally repeated questions are best if one waits 6-30 hours between : I suspect nobody here is able/prepared to answer that.13:41
bilalakhtarokay, so my question was difficult :(13:42
Gpersia: check out line #692 http://cvs.fedoraproject.org/viewvc//rpms/libvirt/devel/libvirt.spec?view=markup13:42
persiaG, Works for other arches.  qemu-kvm support for powerpc in Ubuntu was deliberately trimmed by me to get it to build for lucid: as much as anything else, this is a reminder that I should check the status, and maybe build a bit more on powerpc.13:43
persiaWorst case, yeah, I'll comment out the test, but as seen with tickcount, I generally don't like to do that sort of thing, if changing the code makes the test work.13:43
Gpersia: it's nothing to do w/ kvm support though13:43
Glibvirt is independant of all virt types13:44
persiaSo if there exists no virt type that can be a host on the system, that doesn't limit libvirt's tests?13:44
G0.8.x added some network filtering features, look like either the feature or the test is plain broken13:44
persiaWell, it's arch skew, so needs investigation.  Thanks a lot for the hint, but I'm still going to try to figure out why powerpc is different.13:44
geserpersia: bug 625798 if you want to follow it13:45
ubottuLaunchpad bug 625798 in tickcount (Ubuntu) "Don't use int constants with a long data type." [Undecided,New] https://launchpad.net/bugs/62579813:45
persia(but not now: time for food)13:45
* G has a look at the test upstream13:45
persiaheh.  Good bug title.13:45
geserpersia: if you also look at FTBFS in universe: ldc needs an update 0.9.2+hg1650 to fix the FTBFS as we have only llvm 2.7 in the archive and this support for llvm 2.7 got fixed upstream in that revision13:48
Gpersia: I'd take a look at it, but I lack powerpc access but it looks like the XML that libvirt is producing isn't quite what it expects13:53
cjwatsonpersia: what may have been confusing you is the rather arcane bit of the C standard regarding default argument promotions14:23
cjwatsonpersia: lacking a prototype, function arguments are promoted to int or double as appropriate, using the integer promotion rules14:24
cjwatson(int> modulo signedness)14:24
cjwatsonpersia: the effect of this is that you can get away with passing char to %d, for instance, but it doesn't work with long types when sizeof(long) > sizeof(int)14:25
persiacjwatson, Thanks.  That makes lots of sense.14:28
cjwatsonthank goodness for gcc warning me about this kind of thing, otherwise I'd never remember ...14:29
persiageser, universe is next (as I'm running out of main).  I'll start with ldc tomorrow if someone else doesn't get to it first.14:29
cjwatsonif somebody wants to take the freej FTBFS, I would greatly appreciate itb14:30
cjwatson*it14:30
persiaThat'd probably benefit from the attention of the mozillateam14:32
cjwatsonmm14:33
* G looks at some universe FTBFS14:38
=== bjf[afk] is now known as bjf[vacation]
=== dendro-afk is now known as dendrobates
lanoxxjames_w, are you there?15:50
vishi'v tried looking for the lp bug about the Maverick iso not booting in virtual box... but i cant find one :(17:07
vishdoes anyone know the bug# ?17:07
* vish asks here because there was chat about the issue being known..17:07
sbeattievish: hrm, which iso? I managed to boot maverick livecds (i386 and amd64) just yesterday.17:33
vishi'v been trying to use testdrive and the desktop iso does not boot and i cannot install either.17:33
vishthis has been for over a week ..17:34
sbeattievish: hrm, I've not used testdrive, but I think it defaulted to kvm, though could use virtualbox.17:34
vishyeah , it seems to default to kvm when we dont have VB , but uses VB if its there..17:35
vishdoes not boot in the sense , it just loads and then hangs later on , either hangs with the wallpaper "Try Ubuntu"  or when i try to install the installer just crashes and again hangs17:37
* vish tries to read logs again..17:38
vishhttp://irclogs.ubuntu.com/2010/08/26/%23ubuntu-devel.html#t20:2417:39
vishhmm , so its the installer!17:40
cjwatsonvish: I thought I'd fixed that by removing bootchart from the CD17:41
vishcjwatson: tried today too , doesnt help .. still just hangs with the wallpaper17:41
sbeattievish: but also seems to be a discussion about kvm, not virtualbox17:41
cjwatsonyou could try giving it more memory17:42
vishsbeattie: yeah , but it looks like the CD fault than the kvm/VB , [well seemed the same, since i seem the have that prob :D]17:42
* vish adds memory17:43
vishmore memory seems to do the trick.. alteast able to get to the installer now .. :)17:52
* vish fingers crossed17:52
vishcjwatson: yup! more memory and i could install/boot! thanks. :)18:19
james_wlanoxx: am now18:48
lanoxxjames_w, ah hi, did you get my patches?18:49
james_wlanoxx: to what?18:50
lanoxxtilda18:50
james_wI don't think so, and that's not a project that I know18:51
james_wlanoxx: did you send them directly to me?18:51
lanoxxjup, yesterday18:51
lanoxxjames_w, to @ubuntu.com18:52
james_wlanoxx: why did you send them to me?18:53
lanoxxyou are registered in launchpad as maintainer for tilda18:53
lanoxxi wasnt sure to whom else to send it18:53
james_wlanoxx: https://edge.launchpad.net/tilda <- that project?18:54
lanoxxhttps://code.launchpad.net/~ubuntu-branches/ubuntu/maverick/tilda/maverick18:55
james_wright, I created the branch, but I created all of them, so I have no specific links to that project18:55
lanoxxjames_w, ah ok, well then i will send them to ira instead :)18:56
james_wlanoxx: please do18:56
james_wlanoxx: you can submit a merge proposal for Ubuntu as well if they are bugfixes.18:56
lanoxxwell the patches move the config files from ~/.tilda to the XDG_CONFIG_HOME, is that considered a fix?18:57
lanoxxits just about 20 to 30 lines of code18:58
james_wnot particularly18:58
lanoxxhow about maverick?18:58
james_wmaverick is in feature freeze18:59
james_wyou would have to ask someone on the release team whether that required a freeze exception or not18:59
lanoxxok, i will do that, after they got accepted in upstream19:02
mr_pouitpitti: fyi, the randr 1.2 branch of xfce4-settings has just been merged in master22:09

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!