| doko | I really love autoconf-2.63 | 00:03 |
|---|---|---|
| Keybuk | really? why? | 00:04 |
| Keybuk | what's better compared to 2.61? :p | 00:05 |
| doko | just trying to get gcc-4.3 and gcj-4.3 buildable again | 00:11 |
| Keybuk | did it break anything? | 00:12 |
| doko | gcc-4.3 and gcj-4.3 | 00:13 |
| Keybuk | how were they broken? | 00:13 |
| Keybuk | it didn't look like much changed from 2.61 to 2.63 | 00:13 |
| doko | see https://edge.launchpad.net/ubuntu/+source/gcc-4.3/4.3.3-3ubuntu4 | 00:13 |
| doko | fixed that by using autoconf-2.59, as required by upstream | 00:14 |
| doko | still have to look at the failure for gcj-4.3 | 00:14 |
| doko | if /bin/bash ../../libtool --tag=CC --mode=compile /scratch/packages/gcc/4.3/u/java/gcj-4.3-4.3.3/build/./gcc/xgcc -B/scratch/packages/gcc/4.3/u/java/gcj-4.3-4.3.3/build/./gcc/ -B/usr/i486-linux-gnu/bin/ -B/usr/i486-linux-gnu/lib/ -isystem /usr/i486-linux-gnu/include -isystem /usr/i486-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../../../src/libjava/classpath/native/fdlibm -I../../include @EXTRA_CFLAGS@ -O2 -g -g -O2 | 00:15 |
| doko | -MT e_acos.lo -MD -MP -MF ".deps/e_acos.Tpo" -c -o e_acos.lo ../../../../../../src/libjava/classpath/native/fdlibm/e_acos.c; \ | 00:15 |
| doko | then mv -f ".deps/e_acos.Tpo" ".deps/e_acos.Plo"; else rm -f ".deps/e_acos.Tpo"; exit 1; fi | 00:15 |
| Keybuk | weird | 00:15 |
| Keybuk | I can't see anything obvious in the i386 build log that looks like an autoconf failure | 00:15 |
| doko | probably this is my mistake (@EXTRA_CFLAGS@ not substituted) | 00:15 |
| doko | well, it does work again using autoconf-2.59 | 00:16 |
| Keybuk | I can't find the error in the build log? | 00:16 |
| Keybuk | libtool: compile: not configured to build any kind of library | 00:17 |
| Keybuk | libtool: compile: See the libtool documentation for more information. | 00:17 |
| Keybuk | libtool: compile: Fatal configuration error. | 00:17 |
| Keybuk | ./libtool: line 150: CDPATH: command not found | 00:17 |
| Keybuk | that looks like the problem? | 00:18 |
| doko | it's in libobjc | 00:18 |
| doko | yep | 00:19 |
| doko | anyway, heading to bed now, will look at this after feature freeze | 00:20 |
| Keybuk | bit of an odd one | 00:21 |
| Keybuk | since all libtool ever does with CDPATH is try and unset it ;) | 00:21 |
| Keybuk | looks more like a libtool bug | 00:22 |
| doko | maybe, triggered by the autoconf update | 00:23 |
| Keybuk | sh -e debian/patches/libobjc-gc-link.dpatch -patch -d /build/buildd/gcc-4.3-4.3.3/src | 00:23 |
| Keybuk | patching file libobjc/Makefile.in | 00:23 |
| Keybuk | what does that patch do? :) | 00:23 |
| Keybuk | patching file libobjc/configure.ac | 00:23 |
| doko | patching the libobjc/configure.ac and after that calling atutoconf the regenerate the configure file | 00:24 |
| Keybuk | it might just be an ordering of the configure.ac problem | 00:25 |
| doko | 2008-07-03 Matthias Klose <doko@ubuntu.com> | 00:26 |
| doko | * configure.ac (OBJC_BOEHM_GC_LIBS): Link with libgcjgc_convenience.la | 00:26 |
| doko | and needed thread flags and libraries. | 00:26 |
| doko | * configure: Regenerate. | 00:26 |
| doko | * Makefile.in (libobjc_gc$(libsuffix).la): Link with OBJC_BOEHM_GC_LIBS. | 00:26 |
| Keybuk | did it work ok with 2.61? | 00:27 |
| doko | yes, 4.3.3-3ubuntu3 was built sucessfully before the autoconf update | 00:28 |
| Keybuk | kooky | 00:30 |
| Keybuk | everything in here is just a bug fix | 00:30 |
| Keybuk | mostly to do with string quoting | 00:31 |
| Keybuk | I'll have a look here and see if I can figure it out | 00:31 |
| Keybuk | hmm, you build-dep on automake 1.9? | 00:38 |
| Keybuk | might be a bug caused by that - try 1.10? | 00:39 |
| cody-somerville | Keybuk, :P | 00:40 |
| * Adri2000 needs a core-dev click on bug #328874 | 00:43 | |
| ubottu | Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Undecided,New] https://launchpad.net/bugs/328874 | 00:43 |
| Adri2000 | (hardy nomination) | 00:43 |
| Adri2000 | cody-somerville or Keybuk ? ^ | 00:50 |
| === RAOF_ is now known as RAOF | ||
| ScottK | If there's a buildd admin around, I'd appreciate it if you would find out what's up with the qt4-x11 build for sparc on artigas. That's an early step in a long chain of build and so it'd be nice to get it killed/finished/restarted/whatever. | 04:39 |
| StevenK | artigas was showing as timed out on +builds ... | 04:47 |
| ScottK | Yep. So it can't even fail and I get to retry it for the other buildd, it's just stuck in suspended animation. | 04:48 |
| StevenK | ScottK: I think you gave back kdegraphics too early. I got a failed mail for it, so I retried it last night and it has now built | 04:48 |
| ScottK | I did jump the gun on a few. Sorry for spamming your inbox. Thanks for taking care of it. | 04:49 |
| ScottK | Today I hit a few sparc retries by accident when I meant to do powerpc. | 04:49 |
| StevenK | We could start fixing ia64, too. Hm, did I release it from NEW ... | 04:50 |
| ScottK | Yes. I retried mesa. that's the first one. | 04:51 |
| StevenK | On sparc or ia64? | 04:51 |
| ScottK | Waiting for it now. Unfortunately soyuz in it's infinite wisdom scores all manual retries at 0. | 04:51 |
| ScottK | ia64 | 04:52 |
| StevenK | I'm not certain I released linux-ports ia64 from NEW | 04:52 |
| ScottK | Someone did. | 04:52 |
| ScottK | sparc it's done. qt4-x11 was the next in the chain. | 04:52 |
| * StevenK shrugs | 04:52 | |
| ScottK | I'm all trained now on doing binary New (thanks to pitti), but kernels are in the class that I can't do from the web u/i. | 04:53 |
| StevenK | Yes, kernels are special | 04:53 |
| ScottK | Which is fine. I probably wouldn't touch them even if I could. | 04:54 |
| ScottK | I knocked out at least a third of the out of date on power pc already last night and today. | 04:55 |
| StevenK | The last time I NEW'd a kernel the whole thing ended up in universe :-( | 04:55 |
| StevenK | Which involved a *large* one-liner and bunch of watching to fix | 04:56 |
| StevenK | ScottK: So you're the reason the powerpc queue is so large? :-) | 05:00 |
| ScottK | Yes. | 05:00 |
| ScottK | I did the same thing to lpia and armel recently too. | 05:01 |
| dholbach | good morning | 06:23 |
| ion_ | morniŋ | 06:26 |
| ScottK | Good morning | 06:28 |
| highvoltage | good moo | 06:28 |
| highvoltage | and morning | 06:28 |
| dholbach | hi ion_, scottK, highvoltage | 06:29 |
| highvoltage | dholbach: nice stuff on the loco-doc day. one day when I'm rich enough to not have to work so hard during the day I also want to be as cool as you :) | 06:30 |
| dholbach | highvoltage: it's not like I did most of the work there | 06:30 |
| dholbach | highvoltage: check out http://www.jonobacon.org/2009/02/13/the-docs-were-indeed-rocked/ | 06:30 |
| dholbach | highvoltage: lots of people put some hard work into fixing the docs, which is awesome | 06:31 |
| highvoltage | *nod* | 06:31 |
| highvoltage | I just read that post | 06:31 |
| dholbach | :) | 06:31 |
| Koon | Archive admins: I just uploaded a cleaner new release of eucalyptus-javadeps (0.2.1), please do not waste any more time on the fat 0.1 | 08:34 |
| pitti | Good morning | 08:54 |
| StevenK | Morning pitti | 08:55 |
| seb128 | hello pitti StevenK sabdfl | 08:56 |
| StevenK | Hey seb128 | 08:56 |
| sabdfl | howdy seb128 | 08:56 |
| sabdfl | are we feeling jaunty this moining? | 08:56 |
| pitti | hey sabdfl | 08:57 |
| pitti | sabdfl: look, behind! a three-antlered jackalope! | 08:57 |
| soren | pitti: Yikes. | 08:58 |
| Koon | pitti: the jackalope is ahead, not behind. | 08:58 |
| directhex | mornin'! | 09:03 |
| apw | anyone know anything about glade widget definitions? specicially if they can have variables in tehm? | 09:06 |
| ogra_ | you mean inside the xml ? | 09:06 |
| apw | yeah in that xml spagetti | 09:06 |
| ogra_ | yep, you usually can define default values in there | 09:07 |
| apw | i have two identicle widgets other than the description line, and that seems stupid | 09:07 |
| apw | nice where can i find out how to override them | 09:07 |
| ogra_ | well, in the xml code worst case | 09:07 |
| * apw needs some n00b docs, clearly | 09:08 | |
| ogra_ | apw, i always use a gui for creating the glade files being a lazy chap ... | 09:10 |
| apw | hmmmm yeah wonder what was used before | 09:10 |
| ogra_ | glade-3 or glade-gnome-3 | 09:11 |
| ogra_ | they are very helpful tools | 09:11 |
| * directhex used glade once upon a time | 09:11 | |
| * apw watches his disk space dissappear | 09:14 | |
| * ogra_ hands apw bzip2 | 09:14 | |
| * apw tries to mount /usr/bin via fuse to it | 09:14 | |
| ogra_ | haha | 09:15 |
| liw | mvo, yo? | 09:29 |
| === mvo__ is now known as mvo | ||
| liw | mvo, connectivity problems? | 09:40 |
| mvo | liw: yes :( | 09:41 |
| mvo | liw: give me some minutes, I'm still fighting a compiz problem | 09:42 |
| liw | mvo, sure | 09:42 |
| apw | pitti, which version of the glade editors would you have used to edit the apport glade stuff? | 09:51 |
| pitti | apw: apport's glade is still glade-2, I believe | 09:52 |
| apw | thats why the whole thing changed when i tried to edit it | 09:53 |
| cjwatson | I always find it best to do a load/save in the glade editor before doing anything else, to see what it changes | 09:55 |
| sabdfl | pitti: i blinked and missed it, it booted too fast | 10:03 |
| savvas | slangasek: do you recall why was bug #232469 rejected for jaunty? | 10:07 |
| ubottu | Launchpad bug 232469 in wget "wget does not use network proxy in some cases" [Undecided,Confirmed] https://launchpad.net/bugs/232469 | 10:07 |
| ivoks | correct me if i'm wrong... | 10:10 |
| ivoks | gcc-4.2 in hardy is 4.2.4 | 10:10 |
| ivoks | but the kernel is compiled with 4.2.3 | 10:10 |
| cjwatson | savvas: declining a release nomination doesn't mean that it can't be fixed for the release - just means the release team isn't interested in tracking it | 10:11 |
| ivoks | we can't build modules that way | 10:11 |
| cjwatson | savvas: it's usually much more productive to figure out a fix rather than arguing about the nomination state :-0 | 10:11 |
| cjwatson | :-) | 10:11 |
| savvas | aaah | 10:11 |
| savvas | cjwatson: ok, thanks! | 10:12 |
| savvas | cjwatson: I wasn't going to argue about it, I was just curious :P | 10:12 |
| apw | cjwatson, did we just have a gcc update for security? | 10:14 |
| ivoks | 4.2.4 is in updates | 10:14 |
| ogra_ | seb128, the "evo doesnt unfold the folder tree for message folders" (remember, the thing i showed you at the sprint) bug comes and goes for me, now i can expand and collapse with +/- but mouseclicks still dont work | 10:16 |
| seb128 | weird bug | 10:17 |
| ogra_ | yeah | 10:17 |
| ogra_ | its only in evo | 10:17 |
| ogra_ | and this time i rebooted before checking, but its definately there | 10:17 |
| seb128 | nobody else complained about that and I never got this issue | 10:17 |
| ogra_ | but you use subfolders as well ? | 10:18 |
| seb128 | yes | 10:18 |
| ogra_ | though it doesnt work on the toplevel either | 10:18 |
| ogra_ | i.e. the inbox expander | 10:19 |
| seb128 | it work on the account, inbox, subfolder there | 10:19 |
| apw | ivoks, that version is pretty old, entered updates on 2008-10-22, and the kernel version in update and proposed were buld 2009-01-29 ish | 10:19 |
| apw | so i would have expected them to be built with it? | 10:19 |
| ivoks | apw: correct | 10:19 |
| apw | can you paste the full version string for me from /proc/version | 10:20 |
| cjwatson | apw: no idea I'm afraid | 10:21 |
| * apw notes there _is_ something cjwatson doesn't know ... odd | 10:21 | |
| cjwatson | I could look it up ;-) | 10:21 |
| cjwatson | (https://launchpad.net/ubuntu/+source/gcc-4.2) | 10:21 |
| apw | cjwatson, s'ok ... don't worry | 10:21 |
| cjwatson | 4.2.4 was in intrepid as released, according to that | 10:21 |
| cjwatson | oh, this was hardy | 10:21 |
| ogra_ | seb128, clicking fast i can see "opening folder" in the status bar | 10:21 |
| ivoks | apw: Linux version 2.6.24-23-server (buildd@crested) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Mon Jan 26 01:36:05 UTC 2009 | 10:22 |
| ogra_ | but the expander still does nothing | 10:22 |
| seb128 | ogra_: can you open a bug on bugzilla.gnome.org? | 10:22 |
| cjwatson | hardy did have an update, but not "just" - it was back in October | 10:22 |
| apw | ivoks, can you get the whole output of /proc/version for me | 10:22 |
| apw | that matches my findings too ... | 10:22 |
| ogra_ | seb128, will do ... do you also need something in LP to track it ? | 10:22 |
| ivoks | but on the other machine: | 10:22 |
| apw | so need to confirm that the kernel was miss compiled or not | 10:22 |
| seb128 | ogra_: no | 10:22 |
| ivoks | Linux version 2.6.24-23-server (buildd@palmer) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Thu Nov 27 19:19:15 UTC 2008 | 10:22 |
| ogra_ | ok | 10:22 |
| seb128 | ogra_: it's not important enough for me to track | 10:22 |
| ogra_ | hmm | 10:23 |
| seb128 | I don't want to track every upstream bug which happens to one user | 10:23 |
| ogra_ | right :/ | 10:23 |
| apw | ivoks, ok on the 'broken' one whats in /proc/version_signature | 10:23 |
| * ogra_ is sad he's the only one | 10:23 | |
| seb128 | or we could import the zillions bugzilla bug to launchpad | 10:23 |
| ivoks | apw: Ubuntu 2.6.24-23.48-server | 10:23 |
| seb128 | and make the buglists impossible to work on | 10:23 |
| ivoks | hm | 10:23 |
| ogra_ | yeah, indeed | 10:23 |
| apw | ivoks, and the working one? | 10:23 |
| ivoks | apw: 46-server | 10:23 |
| ivoks | i have kernel from the future? :) | 10:24 |
| TheMuso | tjaalton: it happens to the best of us. :p | 10:24 |
| apw | oh, thats a security kernel | 10:24 |
| apw | ivoks that looks broke to me, could you file a bug against the linux package please | 10:25 |
| ivoks | apw: sure | 10:25 |
| apw | and in the description put the cat /proc/version and /proc/version_signature | 10:25 |
| apw | for both the bad and good machines for me | 10:25 |
| apw | it smells like we have a build environment out of sync. if you could paste me the bug# once its done i'll have a poke | 10:25 |
| tjaalton | TheMuso: heh.. *headdesk* :) | 10:26 |
| ivoks | apw: we have that bug opened for 3 months: bug 292381 | 10:28 |
| ubottu | Launchpad bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,Triaged] https://launchpad.net/bugs/292381 | 10:28 |
| apw | ivoks, thanks ... | 10:28 |
| pitti | tseliot: do you think xorg-options-editor will make it for FF? (if not, no big harm, but I'm reviewing the jaunty spec list) | 10:29 |
| pitti | Riddell: most kubuntu-jaunty-* specs are "not started"; I guess they are, could you please update their status? | 10:29 |
| tseliot | pitti: bryce will review my changes soon and if we make it available in Jaunty, it will be in universe | 10:30 |
| ogra | tjaalton, geeez, i just noticed that evdev started to drive my touchscreen with the lates updates ... (totally miscalibrated though) | 10:30 |
| pitti | tseliot: I know, but it's still covered by FF | 10:30 |
| apw | ivoks, ok could you add the -23 ones from your experience, and include both /proc/version and /proc/version_signature | 10:30 |
| ivoks | apw: it's a gcc thing | 10:30 |
| pitti | tseliot: so there is a working version? great | 10:30 |
| tjaalton | ogra: good or bad?-) | 10:30 |
| ivoks | apw: updates have gcc 4.2.4, but the security has 4.2.3 | 10:30 |
| apw | ivoks, yes i know, but the evidence is in your kernel strings which reported the gcc used | 10:31 |
| apw | those are therefore what i need | 10:31 |
| ivoks | ok | 10:31 |
| apw | shove gcc -v in with each machine too | 10:31 |
| apw | yours is a nice clear example of what is wrong | 10:31 |
| tseliot | pitti: yes, but the UI does not follow the usability guidelines. Other that this, it works well | 10:31 |
| ogra | tjaalton, well, good as in motion events and clicks are recognized, bad as in miscalibrated (i can only use the middle of the screen, like the size of a touchpad ... it behaves slightly similar to the touchpad) | 10:32 |
| pitti | tseliot: cool, so it sounds it could well make it into universe by FF, and get UI cleanup by UIF? | 10:32 |
| pitti | tseliot: would you mind updating the spec status and set it to "good progress"? | 10:32 |
| pitti | (and say which bits are done and which are missing) | 10:33 |
| tseliot | pitti: I doubt the UI cleanup will be done in time for jaunty | 10:33 |
| tseliot | pitti: but yes, I'll update the blueprint | 10:33 |
| tjaalton | ogra: ok, I don't know if it should autocalibrate somehow | 10:33 |
| pitti | tseliot: ah, ok; do you think that' a blocker for getting it into universe? | 10:33 |
| ogra | tjaalton, i doubt that and we need a calibration tool ... i somewhat lost my trust in upstream getting that support done since it took so long, i'll try to package the cairo calibration tool on the weekend, so we'll have it in for FF | 10:34 |
| tseliot | pitti: no, I don't. While the UI cleanup could take place in time for Jaunty+1 the program works well, therefore it should be ok for universe | 10:35 |
| pitti | tseliot: yay | 10:35 |
| tjaalton | ogra: ok, good | 10:35 |
| apw | ivoks, let me know when its in there | 10:35 |
| ivoks | apw: there | 10:35 |
| ivoks | apw: 64bit buildd is out of sync | 10:36 |
| apw | ivoks, and i assume you get some kind of missmatch error when you try and build and external module? | 10:37 |
| ivoks | apw: yes | 10:37 |
| apw | can you paste one of those in too for me | 10:37 |
| apw | also can you add the /etc/apt/sources.list for both machines if possible | 10:38 |
| tseliot | pitti: spec updated | 10:41 |
| === thekorn__ is now known as thekorn | ||
| danimo_ | is there an ftp master around? | 10:54 |
| danimo_ | /ubuntu/dists/feisty/ is missing on archive.ubuntu.com and all the mirrors I checked | 10:54 |
| elmo | danimo_: feisty is end of life; it moved to old-releases.ubuntu.com | 10:55 |
| elmo | danimo: https://lists.ubuntu.com/archives/ubuntu-announce/2008-September/000113.html | 10:55 |
| danimo_ | elmo: ok, just surprised that the other links are still around | 10:56 |
| elmo | danimo_: I agree; that's a bug | 10:57 |
| danimo_ | anyway, thanls for the clarification | 10:58 |
| danimo_ | er, thanks :) | 10:59 |
| slytherin | what could be the reason that a build that was given back yesterday is not yet started? | 11:10 |
| cjwatson | slytherin: give-backs unfortunately default to a very low score | 11:13 |
| cjwatson | (well, perhaps unfortunately, perhaps not) | 11:13 |
| cjwatson | it does mean that it's harder to DoS the buildd with give-backs | 11:14 |
| apw | ivoks, i suspect your 32 bit machine will suffer the same fate once rebooted | 11:14 |
| ivoks | apw: you think? :) | 11:15 |
| apw | sadly so :) | 11:15 |
| apw | i think we know why this is occuring, just need to work out what the right way out of the maze of twisty pockets is | 11:15 |
| slytherin | cjwatson: didn't know that. I was wondering why buildd are picking news uploaded packages when an old one given-back is pending. | 11:16 |
| ivoks | well, it's obvious... -security and -updates don't have same gcc version | 11:16 |
| ivoks | so, there's no easy way out of this | 11:16 |
| cjwatson | ivoks: the easy way out is to copy gcc-4.2 from -updates to -security | 11:17 |
| ivoks | right :) | 11:17 |
| ivoks | and rebuild kernel | 11:17 |
| apw | ivoks, right ... two solutions copy gcc to -security, or have two kernel builds one per pocket | 11:18 |
| apw | and someone other than i needs to make that call.. will start the discussion | 11:18 |
| cjwatson | two kernel builds => distasteful, IMO | 11:18 |
| apw | cjwatson, i am with you, though its lower risk probabally | 11:19 |
| cjwatson | personally I reckon we've already taken most of the risk having incorporated 4.2.4 into -updates | 11:20 |
| ivoks | so, if ever gcc gets updated again, kernel rebuild is needed | 11:20 |
| apw | ivoks, yes, and we need to put that on our proceedures to catch it too | 11:21 |
| ivoks | or not change gcc version during release | 11:21 |
| apw | yep. or that. | 11:21 |
| apw | i guess unless its a security issue, which is ok | 11:22 |
| ivoks | not even in -backports :) | 11:22 |
| apw | nnnng | 11:22 |
| apw | only backporting higher releases is ok | 11:22 |
| apw | as the packages are prefixd | 11:22 |
| ivoks | right | 11:22 |
| cjwatson | doko: this all looks like a reason to be cautious about gcc version bumps in stable releases in future :-/ | 11:23 |
| cjwatson | apw: so the kernel build literally looks at the upstream gcc version and encodes that in its ABI? | 11:24 |
| cjwatson | apw: as opposed to the ABI bump being a result of a change in gcc code generation? | 11:24 |
| apw | i don't think its quite that rigid, but there is clear issues with different compilers generating incompatible code across boundaries | 11:24 |
| apw | so they have stated 'you should use the same' and people have coded that in their tools for those modules | 11:25 |
| apw | and it is a bit frightening, its not like they are libraries with clean interfaces, they are really .o's munged together at run time | 11:25 |
| apw | its wholy scarey the thought htat they might be at different compiler versions | 11:25 |
| cjwatson | apw: so in that case backports are surely risky too? | 11:27 |
| doko | well, the conservative approach would be not to change the compiler at all and tell people: "broken code with the default optimizations, please work around". or is this caused by -security/-updates divergencies? | 11:27 |
| cjwatson | apw: I would have thought that if different versions of gcc were behaving as you say, that would be a serious problem for userspace too | 11:27 |
| cjwatson | apw: after all userspace static linking is little different, but we don't have these problems | 11:28 |
| apw | apps don't talk to other apps so tightly | 11:28 |
| apw | we don't static link half a program | 11:28 |
| cjwatson | true | 11:28 |
| apw | we make a whole package or none of it | 11:28 |
| apw | thats where the nasty fear comes in | 11:28 |
| apw | and i suspect its not reasonable, but its there | 11:28 |
| cjwatson | doko: right, this is because -security and -updates are different; my suggestion here is to copy 4.2.4 into -security | 11:28 |
| apw | i think in paranoid builds we do insert the compiler version into the symbols somehow | 11:29 |
| cjwatson | apw: so the nasty fear has resulted in people checking the upstream gcc version in their module build system, and if the versions were identical we would dodge that check? | 11:29 |
| apw | right, we would be fine | 11:29 |
| broonie | The kernel is also doing things like packing stuff aggressively and using ABI-relevant GCC features. | 11:32 |
| apw | yeah i don't think i've ever seen quite so many options passed to gcc by anything else | 11:33 |
| Adri2000 | slangasek: bug #328874 is the samba bug I want to fix in hardy; you'll find there all the references. now for jaunty, can we hope for 3.2.8 to be uploaded to debian before our FF? or should we rather start working on it ourselves? | 11:38 |
| ubottu | Launchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Confirmed] https://launchpad.net/bugs/328874 | 11:38 |
| pitti | doko, cjwatson: WDYT about dropping belocs-locales-bin and moving back to building locale-gen etc. from glibc? belocs is basically dead upstream, and patching locales to still work with our belocs-locales-bin version becomes painful | 11:51 |
| doko | pitti: sure, sounds fine | 11:52 |
| StevenK | pitti: Belocs died? I thought they were more active ... | 11:52 |
| cjwatson | pitti: if belocs is dead, I don't have a problem with it; is this like kbd and console-tools, they oscillate in terms of levels of activity? | 11:55 |
| pitti | cjwatson: seems so; right now, glibc upstream is pretty good at updating locales and such.. | 11:55 |
| cjwatson | Denis Barbier got fed up with something in Debian (I forget what) and left, which probably didn't help belocs | 11:55 |
| pitti | cjwatson: I'm still fine with keeping the locales themselves separate | 11:55 |
| pitti | it's easier to update them that way | 11:55 |
| cjwatson | pitti: as long as all the locale-gen stuff keeps on working the same way, I don't really care :) | 11:55 |
| pitti | okay, then I'll look into that | 11:56 |
| pitti | makes more sense than spending two hours on adding workaround patches | 11:56 |
| StevenK | cjwatson: Denis Barbier left? Hm. I missed that. | 11:57 |
| * pitti -> lunch and appointment, will be back for release team meeting | 11:57 | |
| pitti | slangasek: I might miss the first couple of minutes of the release meeting; Rick should be there, but could you move the desktop team report down the agenda? | 11:57 |
| === Rafik_ is now known as Rafik | ||
| doko | pitti, cjwatson: please accept python2.6 in NEW | 12:23 |
| jdstrand | Keybuk: hi! I'm developing a dhclient apparmor profile. I'm running into a race condition with udev bringing up dhcp auto interfaces before apparmor is started, which means dhclient is started before apparmor and thus unconfined. I have a way solve this by utilizing /etc/network/if-pre-up.d and checking for a few things. Ie, is apparmor available/enabled in the kernel and if so, sleep for a bit until apparmor starts | 12:54 |
| jdstrand | Keybuk: ifup is called via start-stop-daemon, so the sleep doesn't affect boot time | 12:55 |
| jdstrand | Keybuk: it works great in almost all cases but one-- a system with apparmor enabled where the user disabled its initscript | 12:55 |
| apw | how long after a PPA package is marked published should i expect it to show up in an apt-get update/upgrade ? | 12:56 |
| jdstrand | Keybuk: I'd ideally like to skip the checks after rcS completes | 12:56 |
| jdstrand | Keybuk: a) does my method make sense and b) is there a reliable way to see if rcS is completed (perhaps upstart's 'status' command)? | 12:57 |
| apw | jdstrand, runlevel perhaps? | 12:58 |
| slytherin | apw: #launchpad is the right channel to ask that question | 13:00 |
| apw | slytherin, ta | 13:00 |
| ogra | jdstrand, does that take NM into account ? :) | 13:00 |
| jdstrand | ogra: works great with nm, and resolvconf :) | 13:01 |
| jdstrand | apw: I thought about runlevel, but didn't think it would report 'S'. its manpage says it does, so that should work great | 13:01 |
| jdstrand | ogra: it should work fine for anything that drops stuff into the various hooks directories too | 13:03 |
| === pochu_ is now known as pochu | ||
| ogra | sounds good | 13:03 |
| jdstrand | ogra: actually, while I've got you here-- dhcpd also has a profile. I scoured the LTSP docs to make sure it would work out of the box there. would you mind perusing /etc/apparmor.d/usr.sbin.dhcpd3 and make sure I didn't miss anything? | 13:04 |
| jdstrand | ogra: or if grabbing the source see debian/apparmor-profile | 13:05 |
| soren | jdstrand: Is there a debhelper thing to install apparmour profiles? | 13:10 |
| * soren wonders if he could get irssi to s/apparmour/apparmor/ for him. | 13:11 | |
| jdstrand | soren: no, not yet. some could possibly be automated-- I'd have to think about it | 13:18 |
| soren | jdstrand: It could be quite like the dh_installudev helper, I imagine. | 13:24 |
| jdstrand | soren: the more I think about it, the more I think it is a good idea | 13:24 |
| * soren takes a break | 13:24 | |
| soren | jdstrand: It's very convenient, especially if the paths should change at some point or they need particular permissions or whatever. | 13:25 |
| * jdstrand nods | 13:25 | |
| jdstrand | soren: of course, it's still on my todo like to have a dh_ufw :) | 13:25 |
| EagleScreen | hello | 13:33 |
| === LucidFox_ is now known as LucidFox | ||
| EagleScreen | the upstream Debian maintainer disagree with to split 'menu' and su-to-root script, becouse using of su-to-root for .desktop files make them Debian-specific, but may be this is not a problem in Ubuntu. | 13:36 |
| pochu | is he aware that people use su-to-root in desktop files anyway? | 13:38 |
| cjwatson | perhaps there should be a special syntax for this in .desktop files that doesn't involve an explicit auxiliary command | 13:38 |
| cjwatson | and have the desktop figure out how to escalate privileges - that seems more elegant | 13:39 |
| pochu | or perhaps the freedesktop folks could resurrect xdgsu and say in the desktop standard that is the official way to gain su priviledges | 13:40 |
| pochu | but that is much to ask, I guess... :) | 13:40 |
| cjwatson | or that, yes | 13:40 |
| EagleScreen | i am not sure, but may be polycikit will fix this kind of issues in a near future.. | 13:40 |
| jdstrand | apw, Keybuk: fyi, runlevel doesn't have enough info yet to report 'S', but it will exit non-zero, which I can test for | 13:52 |
| jdstrand | apw: thanks for the suggestion | 13:52 |
| ogra | cjwatson, hmm, after being asked about automatic updates in d-i i always see "running kdesudo" before it switches to pkgsel, is that intentional (that message seems a bit weird especially on a gnome install) | 13:54 |
| soren | ogra: ...and server, IIRC. | 13:54 |
| cjwatson | ogra: it's cosmetic, it's just a script called "kdesudo" that happened to get inherited and that does nothing | 13:54 |
| cjwatson | you can ignore it | 13:54 |
| ogra | ok | 13:55 |
| cjwatson | ogra: I'll remove it since it does nothing for Ubuntu | 13:55 |
| superm1 | slangasek, mythbuntu's dailies got a weird mirror syncing issue in the log (http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/mythbuntu/jaunty/daily-live-20090213.log) can you queue up another attempt? all other build problems should have been resolved with many of the uploads i did yesterday | 14:01 |
| rtg | I need an archive admin to promote wireless-crda to main per this MIR: https://bugs.edge.launchpad.net/ubuntu/+bug/325801 | 14:04 |
| ubottu | Ubuntu bug 325801 in ubuntu "Main inclusion request: wireless-crda" [Undecided,In progress] | 14:04 |
| devfil2 | Keybuk: can I work on uswsusp merge? | 14:19 |
| slangasek | savvas: 232469 - exactly what cjwatson replied in the bug | 14:35 |
| slangasek | Adri2000: I think in fact that we'll have samba 3.3.0 in before FF | 14:36 |
| slangasek | pitti: shuffling> ack, will do | 14:36 |
| slangasek | superm1: rerunning mythbuntu cronjob | 14:38 |
| superm1 | slangasek, thanks | 14:38 |
| apw | pitti, how do i find the errors from the backend of apport | 14:43 |
| apw | from the thing behing the (!) | 14:43 |
| apw | or how do i run the backend by hand or ... | 14:44 |
| EagleScreen | networkmanager-gnome sometimes fail to connect to a WPA-Entrepise net | 14:53 |
| === bluesmoke is now known as Amaranth | ||
| === thunderstruck is now known as gnomefreak | ||
| pitti | apw: behind the "!"? | 15:09 |
| apw | the ! appears on the gnome task bar you hit that, it dies horribly without telling your logging anywhere i can find | 15:10 |
| pitti | ah | 15:10 |
| pitti | apw: the ! is from update-notifier | 15:10 |
| apw | how does one do the same thing either getting a log, or from the command line or anything other than blind fixing | 15:10 |
| pitti | apw: you can run /usr/share/apport/apport-gtk -c /path/to/crashfile | 15:10 |
| apw | but that has #!no at the top | 15:10 |
| pitti | ? | 15:11 |
| apw | hmmm perhaps i fecked that up somehow | 15:11 |
| * apw reinstalls | 15:11 | |
| pitti | apw: so is update-notifier itself dying, or is /usr/share/apport/apport-gtk not starting? | 15:11 |
| pitti | $ head /usr/share/apport/apport-gtk | 15:11 |
| pitti | #!/usr/bin/python | 15:12 |
| apw | well hard to say of course | 15:12 |
| apw | ok then somehow thats me thats typed it, doh | 15:12 |
| * apw will retest | 15:12 | |
| soren | Could a friendly AA please accept the axis2c binaries? | 15:18 |
| soren | libapache2-mod-axis2c, libaxis2c-bin, libaxis2c-dev, libaxis2c-doc, and libaxis2c0. | 15:19 |
| seb128 | soren: to universe? | 15:23 |
| soren | seb128: universe is fine (for now). | 15:24 |
| seb128 | soren: done | 15:27 |
| * soren hugs seb128 | 15:27 | |
| * seb128 hugs soren back | 15:27 | |
| shtylman_ | evand: I am told you are working on the gtk side of ubiquity installer. I am dabbing a bit with the kde side. What are the major changes you plan to implement, so I can think about making the two similar in usability. Currently, I am working on making the timezone graph behave in a similar manner. Thanks | 15:30 |
| evand | shtylman_: https://wiki.ubuntu.com/JauntyUbiquityUsability - should give you a pretty good idea of what I'm up to | 15:31 |
| shtylman_ | evand: noted, thanks...on a side note..I did an implementation for the kde side of the timezone map that lets you click on a band instead of the cities. I dunno if you have done that yet, but I was able to do it pretty easily after I figured out a way to use the actual images to help me | 15:34 |
| shtylman_ | evand: also, some of the things say done, but I really don't see them in the launchpad repo...do you keep a separate copy of the unmerged changes you have made, and if so where? thanks | 15:35 |
| evand | shtylman_: The timezone map is implemented (there's a version in the archive, but you'll want to build from bzr), but do note that just the timezone band is insufficient information. You need to ultimately be clicking on a city as you need DST information. | 15:37 |
| evand | shtylman_: Everything that's done should be in the ubiquity bzr repository (lp:~ubuntu-installer/ubiquity/trunk) | 15:37 |
| cjwatson | DST information> also country for the purposes of locale | 15:39 |
| shtylman_ | evand: gotcha, ok..I will check bzr, I might have just thought it was a carryover from previous versions and not a new feature so I might have missed it. And right, I tried the gtk one current in there and found that my biggest annoyance was that it gets the city closest to where you click versus the city closest to where you clicked in that timezone | 15:39 |
| === tkamppeter_ is now known as tkamppeter | ||
| shtylman_ | evand: my goal is to first be able to click on the timezone on the map, and then get the city closest to that in that zone, but it should be easy for me to implement it either way if I need to be consistent | 15:39 |
| evand | shtylman_: that's fixed in bzr. | 15:40 |
| shtylman_ | evand: ok, cool | 15:41 |
| evand | a simple debuild in the bzr root, then scp the resulting debs into a live CD environment and install ubiquity, ubiquity-ubuntu-artwork, and ubiquity-frontend-gtk | 15:41 |
| shtylman_ | is that the test procedure? | 15:43 |
| evand | depends on the size of the change. More often I'll just edit the files on the live CD and copy them out. | 15:43 |
| shtylman_ | gotcha...ive been editing on my machine and just not doing the actual final isntall step...although for testing I have to change some of the paths for it to work when its not installed globally | 15:45 |
| evand | I'd do all testing inside the live CD, you don't want to get bit and accidentally lose a partition. | 15:45 |
| shtylman_ | true, but thats why I have external harddrives to take the pain for me :), but I will do some more testing inside the livecd environment now that you suggested it | 15:46 |
| evand | If you don't already have a preferred virtualization environment, allow me to suggest KVM | 15:46 |
| evand | good deal | 15:46 |
| evand | shtylman_: by the way, you might want to hang out in #ubuntu-installer, and let us know what your bzr branches are so we can follow the progress | 15:47 |
| soren | If something is in dep-wait, it should automatically be rebuilt once the package in question is available, shouldn't it? | 15:47 |
| shtylman_ | evand: will do | 15:47 |
| ScottK | soren: Yes it will. | 15:51 |
| ScottK | It takes some time to cycle through, so it's not immediate. | 15:51 |
| soren | ScottK: Ah, I thought it was done as part of the ACCEPTing script or whatever type of magic wand is involved. | 15:52 |
| ScottK | No, depwait packages get revisited on some periodic and then kicked to needs buiding of the dep is satisfied. | 15:53 |
| soren | ScottK: Thanks. I'll just click the rebuild button myself. | 15:53 |
| soren | Patience has never been a thing of mine. | 15:53 |
| ScottK | You may not want to do that. | 15:53 |
| cjwatson | rebuild => score 0 | 15:53 |
| ScottK | There's a soyuz bug where manual retries get scored to 0 | 15:53 |
| ScottK | Yep. | 15:54 |
| cjwatson | I can't decide whether that's actually a bug | 15:54 |
| cjwatson | it has the useful effect of preventing people DoSing the buildds with repeated retries | 15:54 |
| ScottK | I filed a bug on soyuz earlier in the week and they accept it. | 15:54 |
| cjwatson | since any developer can do that, and it's a lot less visible than repeated uploads | 15:54 |
| ScottK | accept/accepted. | 15:54 |
| cjwatson | their problem, then :) | 15:54 |
| apw | pitti, perhaps you could cast an eye over https://code.launchpad.net/~apw/apport/suspend-resume-pt3 and see if that seems a resonable solution to the showing sensible text problem for suspend/resume | 15:54 |
| ScottK | cjwatson: It's been a major hindrance for me getting the ports archs resurrected for KDE since there is a sequence things have to get built in. | 15:55 |
| PecisDarbs | pitti: can be python be used in init.d script? one-liner for example? | 15:56 |
| pitti | PecisDarbs: in principle yes, but you really shouldn't; it's horribly expensive | 15:56 |
| pitti | PecisDarbs: also, you need to account for systems which have /usr on a separate partition, so you can't use it for rcS.d | 15:56 |
| PecisDarbs | ok, then I have to try to do it in bash anyway | 15:57 |
| pitti | PecisDarbs: what do you want to do? | 15:57 |
| pitti | apw: will do after the meeting | 15:58 |
| PecisDarbs | pitti: about that sl-modem-daemon init.d script - it has code which detects if there is standalone modem as ALSA device in system, but it doesn't detect for subdevice - which I have. Subdevice doesn't appear in /proc/asound/cards and it has harder to grep device number and subdevice number. | 15:58 |
| pitti | PecisDarbs: hm, that seems like something which could also be done in postinst? | 15:59 |
| pitti | it doesn't matter much if postinst is slow, but init script bites you on every boot | 15:59 |
| cjwatson | hardware detection should be at run-time, surely | 15:59 |
| pitti | (it's a little less tolerant to hardware changes, though) | 15:59 |
| ScottK | TheMuso: Congratulations on a successful kernel build for hppa. | 15:59 |
| PecisDarbs | I try to extract two numbers for such line - http://pastebin.ca/1336122 | 16:00 |
| Riddell | doko: I don't suppose you know anything about building apps with maven? | 16:00 |
| PecisDarbs | number after card and number after device | 16:00 |
| pitti | PecisDarbs: use awk or sed, they are much faster than calling python or perl | 16:01 |
| cjwatson | if that format is reliable then you don't even have to use a subprocess at all | 16:01 |
| pitti | PecisDarbs: first iteration: | 16:02 |
| pitti | echo 'card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]' | sed -r 's/^card ([[:digit:]]+).*device ([[:digit:]]+).*$/\1 \2/' | 16:02 |
| PecisDarbs | wow | 16:03 |
| cjwatson | $ line='card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]' | 16:03 |
| cjwatson | $ card="${line#card }"; card="${card%%: *}" | 16:03 |
| cjwatson | $ device="${line#*, device }"; device="${device%%: *}" | 16:03 |
| cjwatson | $ echo "$card $device" | 16:03 |
| cjwatson | 0 6 | 16:03 |
| PecisDarbs | shell gurus :) | 16:03 |
| PecisDarbs | thanks | 16:03 |
| pitti | PecisDarbs: one thing, please call aplay -l with LC_ALL=C | 16:03 |
| PecisDarbs | right, localization issues... | 16:04 |
| pitti | mine says "Karte" and "Gerät" :) | 16:04 |
| PecisDarbs | lol | 16:04 |
| PecisDarbs | users in mine language sometimes want us, translators punch in the head because of translating command line stuff :) | 16:04 |
| === Nicke_ is now known as Nicke | ||
| doko | Riddell: please ask Koon. I think our current advice for packaging apps using maven: don't use maven. | 16:07 |
| Koon | Riddell: you want to build something or package something ? | 16:08 |
| cjwatson | doko: *laugh* | 16:16 |
| doko | cjwatson: ? | 16:16 |
| cjwatson | "advice for using maven: don't use maven" | 16:17 |
| lamont | Keybuk: fixing the git tree now - I was tired last night when I wrote the email... | 16:26 |
| walters | doko: in fedora we have maven patches which cause it to work entirely offline and just look at local patches (mvn-jpp); i think the debian java layout is unfortunately not the same as the jpackage one, but the patches are probably adaptable | 16:29 |
| Koon | walters: we have our own effort under way | 16:31 |
| Koon | http://wiki.debian.org/Java/MavenBuilder | 16:32 |
| ScottK | pitti and slangasek: Can we do out Dx bugs in Universe discussion now? | 16:32 |
| walters | Koon: yay, a cdbs plugin | 16:32 |
| slangasek | ScottK: if you can tolerate some latency due to my attempts to acquire breakfast | 16:33 |
| pitti | ScottK: sure; so you have some concern with applying patches? | 16:33 |
| ScottK | OK | 16:33 |
| Koon | walters: it's a slightly different design, with the same kind of problems in the end | 16:33 |
| ScottK | pitti: My concern is that if we created a long term divergence from upstream we have a maintenance burden that MOTU is ill equipped to accept. | 16:33 |
| walters | Koon: yeah | 16:34 |
| ScottK | To the extent these things are incorporated in Universe packages, I think it should be upstream. | 16:34 |
| === dholbach_ is now known as dholbach | ||
| jdstrand | mathiaz, slangasek: I figured I would review/handle the gnutls portion of the openldap regression. However, if it makes more sense for just mathiaz to handle it, I'll help in whatever way is needed | 16:34 |
| ScottK | Alternatively if Canonical Dx will commit to maintain the packages, then I think my concern would be resolved. | 16:34 |
| pitti | ScottK: they should indeed go upstream, no doubt | 16:35 |
| Koon | walters: maven is orthogonal to the concept of linux distributions. we can hack around it, but in the end it could still fail. | 16:35 |
| walters | Koon: yeah | 16:35 |
| pitti | ScottK: in fact, the condition for applying those (to main as well) is that they are sent upstream and aren't Ubuntu specific | 16:35 |
| Koon | Death to Maven! | 16:35 |
| ScottK | pitti: So I don't see a point in having a bunch of "bugs" against packages. | 16:35 |
| walters | Koon: i have hopes the modularity effort upstream will result in at least filesystem-level standardization of these things | 16:35 |
| ScottK | These aren't actually defects, but a difference in design. | 16:35 |
| pitti | ScottK: it's for having a place to discuss, track, and attach them, as well as xref with upstream bugs | 16:35 |
| pitti | and it's still (arguably) an usability defect | 16:36 |
| ScottK | pitti: It's even more arguable that aspects of the proposed Dx design are a usability defect. | 16:36 |
| ScottK | If you want to start that conversation .... | 16:36 |
| pitti | ScottK: sure :) | 16:36 |
| * ScottK doesn't | 16:36 | |
| * pitti doesn't either | 16:36 | |
| ScottK | I think the most appropriate status is the Ubuntu task wontfix since it that's generally what will happen. | 16:37 |
| ScottK | That doesn't stop some developer who feels motivated taking it on. | 16:37 |
| slangasek | jdstrand: uploading the SRUs is easy, sorting the patch is the hard (and first) part :-) I'm happy to see it fixed, whoever does the work | 16:37 |
| pitti | ScottK: having the bug with a patch doesn't mean that we have to upload it immediately | 16:38 |
| ScottK | It does, however, keep the expectation correct about where change will happen. | 16:38 |
| pitti | ScottK: if upstream takes teh patch, then we can close it once we got a new upstream version, for example | 16:38 |
| persia | pitti, There are a number of people who troll universe bugs looking for patches to upload: if a patch should not be uploaded, this ought be indicated. | 16:38 |
| pitti | persia: well, if there are MOTUs uploading patches just because they are there, without reading the bug, then we have a bigger problem | 16:40 |
| ScottK | I think linkage to a upstream bug task with the Ubuntu task wontfix expresses the general approach correctly. | 16:40 |
| slangasek | in that case, it sounds appropriate to un-tag them patch if that tag is currently set? | 16:40 |
| seb128 | confirmed and wishlist would make sense | 16:40 |
| slangasek | or is there a concern that people will find the patches anyway? | 16:40 |
| ScottK | seb128: It's not a bug. | 16:40 |
| ScottK | I actually haven't seen any with a patch. | 16:40 |
| seb128 | wishlist = change request | 16:40 |
| persia | pitti, Not usually MOTU: it's more that it's one of the targets at which new contributors are pointed (go find some patches, test them, propose for upload). | 16:40 |
| seb128 | persia: well they ought to read the comments in a bug before uploading no? | 16:41 |
| seb128 | persia: should be easy to state there if something should not be uploaded | 16:41 |
| ScottK | I didn't see anything so far in the bugs about this ought to be done upstream. | 16:41 |
| seb128 | or do we have people who upload without reading bug comments? | 16:41 |
| pitti | persia: I see | 16:41 |
| persia | seb128, Yes, they ought. A comment saying "This bug is for upstream tracking" would cover my concern. | 16:42 |
| ScottK | persia: I agree. | 16:42 |
| mathiaz | jdstrand: I don't have the time in the next few days to sort out the regression | 16:42 |
| pitti | and we shouldn't upload them straight away without the bug being filed upstream anyway | 16:42 |
| persia | seb128, It's not upload, it's testing the patch, preparing a new candidate revision, pushing into the sponsors queue, etc. | 16:42 |
| mathiaz | jdstrand: however I do hope to update openldap to 2.4.13 before FF | 16:42 |
| jdstrand | mathiaz: well, it makes sense that I would do it, I'm fairly familiar with it. upstream seems to have settled on a solution | 16:43 |
| Laney | Who's to say that upstreams will accept the philiosophy behind these notification changes? | 16:43 |
| ScottK | pitti: I would also not want these bugs/patches upstreamed to Debian. | 16:43 |
| slangasek | mathiaz: does 2.4.13 include changes to the gnutls code to bring parity with the openssl implementation? | 16:43 |
| slangasek | mathiaz: I.e., explicitly enabling V1 sigs? | 16:43 |
| slangasek | s/sigs/certs/ | 16:43 |
| ScottK | Laney: No one. That's why we don't want to take on the possible long term maintenance of them in MOTU. | 16:43 |
| jdstrand | mathiaz: honestly, it'll be a struggle for me to get it sorted out in the next few days too | 16:43 |
| pitti | ScottK: seems you are very fond of actions in notifications :) | 16:43 |
| seb128 | what is this discussion about exactly? | 16:44 |
| Laney | ScottK: Good. So do we go with each upstream's wishes then? | 16:44 |
| seb128 | refusing to do ubuntu changes to ubuntu packages to avoid work? | 16:44 |
| slangasek | mathiaz, jdstrand: I don't think "next few days" is necessarily the expectation either, fwiw | 16:44 |
| rtg | slangasek: a followup on bug #317270. For some reason it didn't get pushed to the git repo, so I missed it when I uploaded yesterday. I need to upload again to fix an armel FTBS, so it'll appear then. It ought to fix bug #320632. | 16:44 |
| ScottK | seb128: It's about Dx filing bugs against Universe packages for their pet project. | 16:44 |
| ubottu | Launchpad bug 317270 in linux "[Studio XPS 16] touchpad doesn't return from resume" [Medium,In progress] https://launchpad.net/bugs/317270 | 16:44 |
| ubottu | Launchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/320632 | 16:44 |
| seb128 | which are valid requests for ubuntu | 16:44 |
| jdstrand | slangasek, mathiaz: rest assured it hasn't dropped off for me-- I'll get to it | 16:44 |
| slangasek | seb128: er, if it's agreed that the patches should go upstream first, then such a refusal should be a no-op? | 16:45 |
| seb128 | if you don't want to work on those feel free to not | 16:45 |
| ScottK | seb128: It's about not pushing maintenance work onto community developers that they are not resourced to handle. | 16:45 |
| seb128 | nobody force community people to do anything | 16:45 |
| cody-somerville | pitti, The new notification system is pretty but it is difficult to see if your screen is black where it shows up (ie. console) and I often find that I move my mouse over it not to click through it but to find out *more* information. | 16:45 |
| mathiaz | slangasek: I don't know if .13 has the gnutls fixes - .14 has them though. | 16:45 |
| cody-somerville | pitti, It isn't clear where the notification originates from | 16:45 |
| seb128 | cody-somerville: those are bugs and should be channeled to the correct media which is not there | 16:45 |
| mathiaz | slangasek: and IIUC upstream is in the process of pushing .14 out of the door | 16:46 |
| ScottK | seb128: We have plenty of pointless diff in Universe already without making it work. | 16:46 |
| slangasek | seb128: but increasing the number of deltas for universe packages increases the merge workload; I think it's legitimate to be concerned about who's taking responsibility for this | 16:46 |
| ScottK | work/worse | 16:46 |
| mathiaz | slangasek: I don't know it if that will be done before FF though. | 16:46 |
| seb128 | slangasek: whoever is doing the change is responsible for it usually | 16:46 |
| jdstrand | mathiaz: if we are talking about jaunty, don't we already have the new gnutls patches from debian already? | 16:46 |
| jdstrand | I haven't looked too closely, but thought I saw some patches | 16:47 |
| slangasek | seb128: in reality, I don't think that's the case over the long term | 16:47 |
| slangasek | mathiaz: well, we're talking about a major regression (bug), that doesn't need a freeze exception to get it fixed | 16:48 |
| persia | seb128, That's often not the case in universe, where there is more significant turnover, and much less sense of ownership of packages. | 16:48 |
| slangasek | mathiaz: but this is the first I've heard about the bug being fixed upstream - you've heard specifically that upstream is force-enabling V1 cert checking in gnutls in .14? | 16:48 |
| seb128 | there is only a bunch of those packages and a team of people paid to work on that, I fail to see what is such of an issue | 16:48 |
| seb128 | that's not like there was hundred of changes | 16:49 |
| slangasek | seb128: who's paid to take responsibility for the packages in universe? | 16:49 |
| ScottK | seb128: There is no team paid to work on these packages. | 16:49 |
| slangasek | that's the open question here | 16:49 |
| === fader is now known as fader|lunch | ||
| primes2h | pitti: Sorry about build-time stuff on debdiff. | 16:49 |
| mathiaz | slangasek: no. I haven't heard anything that specific | 16:49 |
| slangasek | mathiaz: ok; then .14 might be orthogonal... | 16:49 |
| seb128 | slangasek: the dx team said they would provide patches, they will probably maintain those too no? | 16:49 |
| seb128 | and if they don't that's only a couple of changes to maintain | 16:49 |
| pitti | primes2h: don't worry, I figured it out :) | 16:50 |
| seb128 | we do that for lot of other things | 16:50 |
| pitti | seb128: well, provide -> send to and argue with upstream | 16:50 |
| seb128 | people add random .desktop without translations to universe packages for example | 16:50 |
| primes2h | pitti: Next time I'll check it better before posting... | 16:50 |
| seb128 | if you really want to discuss MOTU efficiency better to start on real unrequired efforts | 16:50 |
| ScottK | seb128: AFAIK there are no Ubuntu developers in Dx, so even if they do all the patch work, it still afftect the sponsorship queue. | 16:50 |
| persia | seb128, Well, yes, but that's because I like to launch apps. | 16:50 |
| slangasek | seb128: hum, that sounds like an unfounded assertion to me - I think everyone would be satisfied if the DX team was committed to maintaining patches applied to universe packages for as long as necessary, but this is the first I've heard that such a committment might exist | 16:51 |
| ScottK | seb128: IMO I am. | 16:51 |
| seb128 | persia: and you don't care about non english users | 16:51 |
| seb128 | come on, we are speaking about 15 packages or so | 16:51 |
| ScottK | seb128: One can't add a non-existant translation. | 16:51 |
| seb128 | if you want 0 delta to universe just say it | 16:51 |
| seb128 | but that's not really such of an issue | 16:51 |
| persia | seb128, I just have a different opinion than you about whether it's better to not have a menu item or have an untranslated menu item. We've debated this before: let's not do it again now. | 16:51 |
| ScottK | seb128: If Canonical will commit to maintaining the Universe diff for their Dx initiative, then I have no problem with it. | 16:52 |
| ScottK | So far, Canonical has not agreed to do so. | 16:52 |
| seb128 | there is nothing canonical specific there | 16:52 |
| seb128 | those changes are for ubuntu consistency | 16:52 |
| seb128 | if there is MOTU who want to work on that why do you want to stop them? just because you are not interested in the changes? | 16:53 |
| seb128 | should I stop people to upload .desktop changes because I think those are wrong | 16:53 |
| seb128 | etc | 16:53 |
| cody-somerville | I don't think ScottK is trying to stop anyone from doing anything. | 16:54 |
| seb128 | cody-somerville: it seems that he doesn't want of such changes in universe package because it means extra work | 16:55 |
| cody-somerville | I don't think he is saying that either. I think he is asking a question: "Who will be responsible for the extra work?". | 16:55 |
| seb128 | who is responsive for any ubuntu change? | 16:55 |
| ScottK-palm | Apparently I only get 2 hours of wifi @ McDonalds. | 16:55 |
| seb128 | the people contributing to ubuntu ... | 16:56 |
| cody-somerville | seb128, and thats probably what will happen. However, it could very well mean that now because those packages require a merge, it might not get done as a lot of packages in universe don't get done in a cycle (just way too much to do). | 16:56 |
| LaserJock | seb128: ultimately though MOTU is responsible | 16:57 |
| seb128 | right as for any change | 16:57 |
| LaserJock | so we do need some concern about how things are going to be maintained, and commitments | 16:57 |
| seb128 | should we declare a 0 change to universe rule to minimize work? | 16:57 |
| cody-somerville | No | 16:57 |
| seb128 | lol | 16:57 |
| LaserJock | no, nobody said that | 16:58 |
| seb128 | who is commiting for all the changes people are randomly doing now? | 16:58 |
| LaserJock | sometimes nobody | 16:58 |
| LaserJock | and that sucks | 16:58 |
| seb128 | I can give you a list of change which add for no real win | 16:58 |
| cody-somerville | But if someone was going to make a change to a universe package like the dx proposes, I'd expect to get some sort of commitment from them to maintain it. | 16:58 |
| seb128 | so how is that case different? | 16:58 |
| slangasek | seb128: there have been ongoing conversations about this exact issue among MOTU before now | 16:58 |
| LaserJock | because, I think, that we are trying *not* to do that | 16:58 |
| seb128 | I just think you pick the wrong target for this discussion | 16:58 |
| seb128 | those changes are for look and feel consistency | 16:59 |
| seb128 | and concern a small number of sources | 16:59 |
| LaserJock | I would feel much better with the Dx team making some commitment to the Universe changes | 16:59 |
| ScottK-palm | seb128: If Canonical wants a global design change implemented in Universe, they should maintain it. | 17:00 |
| seb128 | nothing to do with canonical | 17:00 |
| LaserJock | I personally don't care either way on the change, so I'm not against the changes by any means | 17:00 |
| LaserJock | sure it is | 17:00 |
| seb128 | the ubuntu team has decided to change the ubuntu desktop look | 17:00 |
| ScottK-palm | Frankly the communication between Dx and the community has been and IME continues to be very poor. | 17:00 |
| LaserJock | it's Canonical's team from what I can see | 17:00 |
| seb128 | canonical is not revelant there | 17:00 |
| seb128 | how is that revelant? | 17:01 |
| seb128 | it could be a community spec | 17:01 |
| ScottK-palm | seb128: Where is the spec that approved this? | 17:01 |
| LaserJock | because none of them are Ubuntu developers | 17:01 |
| seb128 | discussed at uds | 17:01 |
| LaserJock | which means volunteers have to take care of it | 17:01 |
| LaserJock | which can lead to more work and bitrot that we'd rather not have | 17:01 |
| seb128 | ubuntu members will decide to use those changes or not | 17:01 |
| ScottK-palm | seb128: Discussed, but not in any regular session. | 17:01 |
| seb128 | if they do it will go to ubuntu | 17:01 |
| seb128 | right, and we will ship GNOME 2.26 too | 17:02 |
| seb128 | but there was no session about it | 17:02 |
| seb128 | and we didn't get specs about lpi changes either | 17:02 |
| seb128 | etc | 17:02 |
| ScottK-palm | Yes, Gnome updates happen every time. | 17:02 |
| seb128 | don't try to make it looks like this is different of whatever has been made before or not an ubuntu change | 17:02 |
| seb128 | that's the same sort of changes as lpi | 17:03 |
| ScottK-palm | I think it is very different. | 17:03 |
| seb128 | brb | 17:03 |
| pitti | well, since this now seems miles away from the original discussion -- is it okay for everyone to open bugs for those, attach patches and upstream bugs, and decide this on a per-patch basis? | 17:04 |
| seb128 | re | 17:04 |
| pochu | will those changes be forwarded upstream? | 17:04 |
| seb128 | yes | 17:04 |
| pitti | pochu: absolutely | 17:04 |
| pitti | pochu: I consider this as a precondition for applying them at all | 17:04 |
| ScottK-palm | pitti and slangasek: I need to go and I think I've made my points. Is wontfix in Ubuntu linked to an upstream task OK? | 17:04 |
| seb128 | no | 17:04 |
| pitti | ScottK-palm: I object to this generality | 17:05 |
| seb128 | why wontfix in ubuntu? | 17:05 |
| pitti | ScottK-palm: unconditionally marking all of them as wontfix is pretty pointless and not really justifiable | 17:05 |
| seb128 | ubuntu desktop will use the new notification for consistency having those changes would be nice | 17:05 |
| pochu | for the couple of bugs I've seen, at least for one they provided a rationale on why the change is good for usability, so I think it wouldn't be too strange if upstream would accept the change if it was forwarded | 17:05 |
| ScottK-palm | Because it's not the kind of change we should be doing. | 17:05 |
| seb128 | no reason to wontfix if somebody wants to work on this | 17:05 |
| pitti | marking one as wontfix is okay if upstream rejects it, and it doesn't impact usability too much (or we don't care) | 17:05 |
| seb128 | it's not up to you to decide what other people want to work on | 17:05 |
| pochu | that would mean there's no need to maintain anything | 17:05 |
| pochu | seb128: pitti: cool | 17:05 |
| ScottK-palm | seb128: wontfix doesn't stop people working on anything. | 17:06 |
| pitti | but if upstream accepts the patch, then I don't see why it should be marked wontfix in ubuntu | 17:06 |
| seb128 | it gives the messages than change will not be accepted | 17:06 |
| seb128 | which is wrong | 17:06 |
| LaserJock | the point of wontfix on an Ubuntu task is to signify that we want it to go upstream first, then sync | 17:06 |
| seb128 | no | 17:06 |
| pitti | since then we'd actively had to patch it out again, which would be nonsense | 17:06 |
| seb128 | that's not what wontfix means | 17:06 |
| pitti | LaserJock: no, it isn't; it means that we don't want the change at all | 17:06 |
| ScottK-palm | What it does is set an appropriate expectation that this is not something we would likely do. | 17:06 |
| LaserJock | I think that's how it's being used | 17:06 |
| seb128 | or we can start wontfix 90% of the bugs on launchpad | 17:06 |
| seb128 | but that's something we want to do | 17:07 |
| pitti | LaserJock: we have hundreds of open bugs with an upstream task which just wait for a fix trickling through upstream, after all | 17:07 |
| seb128 | you want universe application to not work nicely on the ubuntu desktop? | 17:07 |
| pochu | LaserJock: not really, I use it as saying "we won't implement it" | 17:07 |
| pochu | LaserJock: e.g. upstream disagrees, and we don't want to change behaviour, so we wontfix it | 17:07 |
| pitti | pochu: but "we won't do the work" != "we won't change it when upstream does" | 17:07 |
| ScottK-palm | seb128: If we ar | 17:08 |
| pochu | pitti: right right | 17:08 |
| ScottK-palm | urgh. | 17:08 |
| LaserJock | pochu: I can see that if there's no Debian task | 17:08 |
| pochu | pitti: I see "wontfix" as "wontfix upstream & in ubuntu", otherwise triaged forever sounds good | 17:08 |
| pochu | pitti: so I'm fine with leaving the Ubuntu tasks opened | 17:09 |
| seb128 | wontfix = we will not accept such changes | 17:09 |
| pochu | right | 17:09 |
| LaserJock | no | 17:09 |
| LaserJock | not exactly | 17:09 |
| ScottK-palm | seb128: Not at all. | 17:09 |
| seb128 | that's how we use it for desktop right now | 17:09 |
| LaserJock | so? | 17:09 |
| seb128 | well you can't say no | 17:09 |
| LaserJock | desktop != MOTU | 17:09 |
| ScottK-palm | It's not how it's generally ised in MOTU. | 17:09 |
| LaserJock | we all have different triage/status rules | 17:10 |
| ScottK-palm | used ... | 17:10 |
| seb128 | how do you use it? | 17:10 |
| seb128 | wontfix = ubuntu will not work on that? | 17:10 |
| seb128 | ie any bug sent upstream where you will wait for an upstream fix is wontfix? | 17:10 |
| LaserJock | if there are multiple tasks then won'tfix directs where the work is appropriate | 17:10 |
| ScottK-palm | seb128: For wouldn't accept the change, I'd use invalid. | 17:10 |
| LaserJock | so an open Debian task and a won'tfix Ubuntu task means "do it in Debian" | 17:10 |
| * ScottK-palm needs to go. | 17:10 | |
| persia | seb128, Rather, a bug which won't be changed in variance to upstream is set that way. | 17:10 |
| seb128 | LaserJock: so we should wontfix all the bugs forwarded upstream now? | 17:11 |
| LaserJock | seb128: if we're just waiting for a sync, I think that would be appropriate | 17:11 |
| seb128 | ok | 17:11 |
| LaserJock | but not a big deal as most of the time people get it | 17:11 |
| persia | seb128, It's not the forwarding, it's forwarding with a statement that the Ubuntu behaviour won't vary from upstream. | 17:11 |
| seb128 | cool, can close some ten thousand bugs | 17:11 |
| ScottK-palm | If you won't fix it in Ubuntu, then say so. | 17:11 |
| pitti | that sounds like an entirely uncovered state, like "Waiting for upstream" | 17:12 |
| LaserJock | but in the case where you're specifically trying to say "don't do this in Ubuntu, wait for Debian" then I think won'tfix is accurate and appropriate | 17:12 |
| seb128 | so basically you suggest keeping any bug we don't intend to fix in an ubuntu specific way as wontfix? | 17:12 |
| persia | No. | 17:12 |
| pitti | LaserJock: well, I disagree heavily, but it's also an entirely separate discussion | 17:12 |
| seb128 | ie close 99% of the bugs since we rely on upstream to fix most of the bugs | 17:12 |
| LaserJock | pitti: no doubt :-) | 17:12 |
| LaserJock | seb128: right, and we don't | 17:13 |
| persia | The practice is that when we won't apply some change (even with a patch) until/unless upstream accepts that change, it gets set "Won't Fix". | 17:13 |
| seb128 | LaserJock: but you are suggesting that we should? | 17:13 |
| LaserJock | seb128: heavens no | 17:13 |
| persia | This is different from the set of bugs that are forwarded upstream, but for which we would accept a patch. | 17:13 |
| LaserJock | you guys do what you want with your bugs | 17:13 |
| LaserJock | but let us do what we want with our bugs | 17:13 |
| seb128 | persia: why wouldn't we accept a patch to make notification consistent on the desktop? | 17:13 |
| LaserJock | seb128: if upstream rejects it I can see doing that | 17:14 |
| seb128 | LaserJock: I'm a MOTU too and can upload to universe, that's as much my bugs than yours | 17:14 |
| persia | seb128, I'm specifically not arguing that: I'm only trying to define the practice. | 17:14 |
| LaserJock | seb128: right ... | 17:14 |
| seb128 | LaserJock: upstream will not accept lpi changes should we not use that in ubuntu either then? | 17:14 |
| LaserJock | seb128: and desktop bugs are as much mine as yours, but I respect your bug practices | 17:14 |
| seb128 | seems you are trying to enforce a "ubuntu should have no distro specific changes" rule | 17:15 |
| LaserJock | no | 17:15 |
| LaserJock | I'm saying let the people who are responsible for the changes decide what they feel they should take | 17:15 |
| pitti | LaserJock: sounds again like the case-by-case basis :) | 17:15 |
| pitti | (which I feel good about) | 17:15 |
| pitti | much less abstract discussion | 17:16 |
| seb128 | right, me too | 17:16 |
| seb128 | wontfix is just wrong there | 17:17 |
| seb128 | it means "we will not accept patches to make this work" | 17:17 |
| seb128 | and there is no reason we should refuse patches than make things work correctly on ubuntu if they don't | 17:17 |
| LaserJock | it makes sense to me anyway | 17:17 |
| LaserJock | but I'm unlikely to be the person uploading it so ... :-) | 17:18 |
| warren_ | hi | 17:18 |
| pochu | I don't think we should close those as wontfix | 17:18 |
| pochu | waiting for upstream comments would be nice though | 17:18 |
| LaserJock | it really doesn't matter | 17:19 |
| pochu | I can imagine in many cases they will integrate the change | 17:19 |
| LaserJock | I assume the Dx people will track how things are going and set appropriate statuses with MOTu | 17:19 |
| LaserJock | the point of the won'tfix stuff would be to direct people to Debian | 17:19 |
| LaserJock | so we don't get duplicative work or conflicts | 17:20 |
| pochu | how is Debian related here? | 17:20 |
| seb128 | LaserJock: what debian has to do with that? | 17:20 |
| pochu | Debian is not changing notification-daemon :) | 17:20 |
| seb128 | LaserJock: the notification daemon will be jaunty specific | 17:20 |
| LaserJock | this stuff isn't going to Debian at all? | 17:21 |
| pochu | LaserJock: it's not. it can go upstream though | 17:21 |
| LaserJock | umm | 17:21 |
| pochu | for "disable actions in notifications" changes | 17:22 |
| LaserJock | but don't we usually get upstream through Debian? | 17:22 |
| pochu | no | 17:22 |
| LaserJock | so wouldn't it be appropriate to discuss such a change with them? | 17:22 |
| cjwatson | we often send things directly as well, or instead | 17:22 |
| cjwatson | in cases where it's really just more efficient to talk directly with upstream | 17:22 |
| LaserJock | sure, if there's good relationships there, that makes sense | 17:22 |
| persia | And in the case of things like GNOME, we often have a different integration cycle than Debian. | 17:23 |
| LaserJock | sure | 17:23 |
| pochu | or even when there are not. You just need to report a bug usually | 17:23 |
| LaserJock | but generally in Universe we work tighter with Debian | 17:23 |
| LaserJock | perhaps it's just the packages that are being changed | 17:23 |
| pochu | well yes | 17:23 |
| shankhs | does creating themes in ubuntu come under ubuntu development? | 17:23 |
| pochu | but I don't like when people think that "forward upstream" means "forward to Debian" | 17:24 |
| pochu | I mean, I prefer that you forward upstream or both upstream&Debian when it makes sense the latter | 17:24 |
| slangasek | persia, ScottK: this idea of setting a task 'wontfix' to mean 'will not diverge from upstream' is alien to me as well; is this interpretation promulgated in the community documentation somewhere? | 17:25 |
| persia | slangasek, It was for a while. I'll try to track down a current location. | 17:25 |
| LaserJock | it just makes sense to me | 17:25 |
| seb128 | to me wontfix = not something that should go to ubuntu | 17:25 |
| LaserJock | right | 17:26 |
| seb128 | I let things I don't intend to work on open so anybody else pick those | 17:26 |
| LaserJock | so it should be done upstream | 17:26 |
| seb128 | or by a contributor | 17:26 |
| LaserJock | no | 17:26 |
| LaserJock | that's the point of won'tfix | 17:26 |
| LaserJock | would be to say, "this is what we'd like to do as a team" | 17:26 |
| seb128 | well why should not we let people who want to work on those changes do it? | 17:26 |
| LaserJock | because it should go upstream | 17:27 |
| persia | slangasek, https://wiki.ubuntu.com/Bugs/Status : The usage described is part of the first bullet, where something needs upstream confirmation. Whether that is true in the case of this class of bugs is a separate discussion from this usage. | 17:27 |
| seb128 | what you want to do is universe applications no work correctly on the ubuntu desktop, that seems weird | 17:27 |
| seb128 | LaserJock: the notification deamon is ubuntu specific | 17:27 |
| seb128 | for now | 17:27 |
| seb128 | it will be suggest as a freedesktop project but nobody else will use it this cycle | 17:27 |
| slangasek | seb128: which people are you referring to, and what is their long-term committment to maintaining this delta? Fire-and-forget changes to universe packages are a real concern, MOTU have been struggling to keep this under control by encouraging good upstreaming practices, and the DX stuff is just one instance in the larger picture | 17:28 |
| seb128 | slangasek: I'm not referring to any people | 17:28 |
| seb128 | slangasek: but if there is 15 applications to patch so they work correctly on the ubuntu desktop I think there is no reason to not do it for maintainship cost | 17:29 |
| slangasek | seb128: if there were a clear committment from the uploaders to maintain the delta, then I don't think there would be any issue here | 17:29 |
| LaserJock | slangasek: exactly, thanks for putting it better than I could have | 17:29 |
| slangasek | seb128: that's not the same thing as saying there's a committment to *shoulder* the maintenance cost | 17:29 |
| seb128 | welcome to open source, we don't have any committment | 17:30 |
| persia | Or even from the patch authors, if they cannot upload today. Doesn't really matter who, as long as someone claims they will either maintain it, or ensure it gets applied upstream. | 17:30 |
| seb128 | we ship lot of softwares which have unactive upstream, if you want to get a commitment that volunter will be there for ever doing the same job you can wait | 17:30 |
| persia | seb128, Indeed, and there are a number of us who have packages like that. | 17:31 |
| seb128 | well that's not a reason to refuse changes which are useful | 17:31 |
| slangasek | seb128: I think that's a poor excuse for endorsing the same kind of behavior within our own community. "It's open source, there's no committments" is not exactly the motto the millions of users who depend on Ubuntu are looking for. | 17:31 |
| seb128 | again we are speaking about making ubuntu applications work correctly on the ubuntu desktop | 17:31 |
| seb128 | so you say you prefer having those not work correctly just because volunteer might not keep updating changes? | 17:32 |
| LaserJock | I'd say yes | 17:32 |
| seb128 | ie, you opt for having things not working because it could create work | 17:32 |
| persia | For a few months now, most of the universe sponsors have been rejecting any patches which don't include active submission upstream in an effort to reduce the volume of Ubuntu-specific patches. I suspect the raised concern is a growth of that effort. | 17:32 |
| pitti | that's a good policy indeed | 17:32 |
| pitti | and nobody questioned that, AFAICS? | 17:33 |
| pitti | (in fact, I do the same for main patches) | 17:33 |
| persia | There's been a couple minor quibbles, and some stuff gets through, but there seems to be broad consensus. | 17:33 |
| slangasek | seb128: also, a committment is not the same thing as a contractual guarantee | 17:33 |
| seb128 | well, there is a difference between useless changes | 17:33 |
| seb128 | and having ubuntu softwares working correctly on ubuntu | 17:33 |
| seb128 | I puzzled that you guys suggest just letting things broken because carrying fix has a maintainship cost | 17:34 |
| persia | seb128, This is for *all* changes, regardless of perceived utility. We don't currently have kvm on lpia and ia64 mostly because the person who was maintaining the patch stopped. | 17:34 |
| seb128 | well, if nobody is there to maintain the change and that's an issue drop those | 17:34 |
| seb128 | but why refusing correct fix because they might be extra work later? | 17:35 |
| slangasek | seb128: I don't think there's a consensus that "broken" and "fix" are the correct terms here; aren't we talking about consistent user experience, not about programs failing to function? | 17:35 |
| persia | seb128, Refusing if the fix is not also pushed to other interested parties: not refusing because of the patch itself, and not requiring the fix to be applied upstream first. | 17:35 |
| LaserJock | seb128: why is it hard to expect some commitment from the Dx team to maintain this stuff? | 17:36 |
| pitti | slangasek: some might work pretty bad, for cases where programs spawn a lot of notifications with actions, which you then need to click away (since they turn into dialogs) | 17:36 |
| seb128 | LaserJock: because you will not get those | 17:36 |
| pitti | the bar should at least be set to filing the patch upstream and discussing it there | 17:36 |
| seb128 | slangasek: those are easy changes in a few packages, I'm really surprised that you argue that those applications should go to an ugly fallback mode rather than work correctly just to avoid to maintain some distro changes | 17:37 |
| LaserJock | seb128: why not? it's their changes | 17:37 |
| seb128 | LaserJock: because they don't have the ressources for that | 17:37 |
| cjwatson | the DX team ought to at least be on the hook to discuss their change, although not necessarily to maintain them; we don't necessarily expect people who submit patches upstream to maintain them forever either | 17:37 |
| LaserJock | seb128: they shouldn't make changes they can't maintain/support! | 17:37 |
| cjwatson | but we do expect them to justify them upstream and make adjustments as request | 17:37 |
| cjwatson | ed | 17:37 |
| cjwatson | LaserJock: see my comparison with any other kind of patch submission upstream | 17:38 |
| pochu | I see a problem with packages that are currently in sync with Debian being patched solely for this purpose; then they won't be autosynced anymore and somebody will need to merge them | 17:38 |
| cjwatson | we do not, in general, expect patch submitters to maintain the change once it is accepted | 17:38 |
| cjwatson | (upstream) | 17:38 |
| pochu | otherwise, for packages that have Ubuntu delta, I don't think this is a major problem | 17:38 |
| seb128 | pochu: again we are speaking about a few applications, we do it for lpi already for example | 17:38 |
| cjwatson | I think it's entirely reasonable to ask the DX team to submit upstream, but what I've been hearing is that that's what they're going to do? | 17:39 |
| seb128 | what is the point of doing a distro if you can't make distro changes to have things working nicely and be consitant on your distro | 17:39 |
| slangasek | seb128: I'm not arguing that; I'm trying to get you to understand the other side of this argument, which is that little changes turn into a big unmanageable pile of work if there's no corresponding committment of resources from the people who want these changes | 17:39 |
| pochu | seb128: right, but for lpi changes we already have a delta or are ahead of Debian | 17:39 |
| pochu | at least AFAIK | 17:39 |
| seb128 | pochu: in fact the lpi changes are higher in number than the notification ones will be | 17:39 |
| cjwatson | anyway, I suppose I shouldn't dive into a debate when I have to run; bye ... | 17:40 |
| pochu | seb128: but we don't have lpi patches in universe packages that would otherwise be in sync with Debian, do we? | 17:40 |
| * slangasek waves to the back of cjwatson's retreating head ;) | 17:40 | |
| seb128 | pochu: no, but we have those for packages in main that would be in sync otherwise, how is that different? | 17:40 |
| * pitti is off for today, too | 17:41 | |
| pochu | seb128: do we? | 17:41 |
| * seb128 should go too, that's a pointless discussion | 17:41 | |
| pochu | seb128: I'm not opposing the patches. but I understand concerns about "fire & forget" | 17:41 |
| pochu | OTOH "fire & forget" is what we do a lot of times in Ubuntu... | 17:41 |
| slangasek | seb128: I think the difference is that there's an expectation that when Canonical makes changes to packages in main, Canonical will provide manpower to maintain these packages on an ongoing basis | 17:42 |
| pitti | it seems that people are discussing about the extreme ends of "immediatly apply" vs. "mark as wontfix and reject" | 17:42 |
| seb128 | pochu: yes, look at the GNOME packages, there is quite some ones where the current version is 2.24 and that we could sync, file-roller, gedit, etc | 17:42 |
| pitti | why can't we at least have the patches in our bug tracker, and have maintainers decide for themselves? | 17:42 |
| seb128 | slangasek: how canonical is revelant there? | 17:42 |
| pochu | pitti: agreed | 17:42 |
| seb128 | slangasek: that's only one contributor | 17:42 |
| seb128 | the contributor could be whatever loco team writting patches | 17:42 |
| slangasek | seb128: frame it as "core-dev", then; whichever way you split it, the per-package resources available for main are significantly greater than for universe, so deltas are more tolerable in main | 17:43 |
| * seb128 waits for archive reorganisation | 17:44 | |
| persia | pitti, Main issue is that we don't really have maintainers. Personally speaking, I'd rather not have patches in the bug tracker that weren't expected to be either applied or rejected as soon as someone got around to looking at them. | 17:44 |
| seb128 | I can list you some packages in main which have nobody looking at them and some actively maintained in universe | 17:44 |
| seb128 | I don't think the component argument is revelant there | 17:44 |
| LaserJock | seb128: well, you're a MOTU, you maintain it then | 17:45 |
| LaserJock | hmm, that could sound snotty | 17:45 |
| LaserJock | I didn't mean it that way | 17:45 |
| jdong | snooty? | 17:46 |
| LaserJock | I meant snotty | 17:46 |
| LaserJock | but since it's essentially a Desktop team change, perhaps the Desktop Team could commit to maintaining it? | 17:46 |
| highvoltage | heh. Ferris Beuler joke! | 17:47 |
| === asac_ is now known as asac | ||
| seb128 | LaserJock: why do you need somebody to commit to maintain it? | 17:47 |
| seb128 | we have lpi changes in several packages and nobody commited to maintain anything | 17:48 |
| LaserJock | seb128: well, because it's an Ubuntu specific change | 17:48 |
| LaserJock | and that's bad, IMO | 17:48 |
| pochu | I think it's been already mentioned, but how many packages are we talking about? | 17:48 |
| seb128 | same for random desktop files motus keep adding | 17:48 |
| seb128 | LaserJock: what is the purpose of a distro if you can't make distro changes to have your distro be consistent | 17:48 |
| LaserJock | just because it *has* been done doesn't mean that's the way we'd like it | 17:48 |
| LaserJock | you *can* make distro changes | 17:48 |
| persia | seb128, Well, in the case of those, most of them are submitted upstream and to Debian (and the majority are now carried in Debian). | 17:48 |
| seb128 | no you can't | 17:48 |
| LaserJock | but you need to be responsibel for them! | 17:49 |
| seb128 | wake up that's not how opensource work | 17:49 |
| LaserJock | whatever | 17:49 |
| seb128 | look at upstream project, people come contribute, get busy, and move to other things | 17:49 |
| LaserJock | sure | 17:49 |
| seb128 | that's not a reason to reject contributions | 17:49 |
| seb128 | just because they might get busy one day | 17:49 |
| LaserJock | yes, it is | 17:49 |
| persia | No, it's not. | 17:49 |
| LaserJock | if the team says "we're not sure we can maintain that" | 17:49 |
| seb128 | welcome to the "do no change ever" | 17:49 |
| LaserJock | they have every right to reject the change | 17:50 |
| slangasek | seb128: "might get busy one day" - that's a mischaracterization of the issue | 17:50 |
| seb128 | LaserJock: that's not like motu was having universe under control | 17:50 |
| seb128 | there is too much work to do for the number of people | 17:50 |
| persia | The question isn't about rejecting contributions. It's about avoiding distro delta where possible by integrating with mainline development. Some delta is inevitable. | 17:50 |
| seb128 | well, delta to having thing work on our distro is useful | 17:50 |
| LaserJock | seb128: right, so we try to be smart about what work we make for ourselves | 17:51 |
| seb128 | ok, forget about that | 17:51 |
| === fader|lunch is now known as fader | ||
| seb128 | I'm going to apply those changes and to maintain those, happy? | 17:51 |
| seb128 | where maintain means I will probably have time every 3 years to reply to emails about it | 17:51 |
| LaserJock | well, I would prefer the Dx team did it because you are so busy | 17:52 |
| seb128 | that was an ironic comment | 17:52 |
| LaserJock | that's why I asked if there's any commitment from them | 17:52 |
| LaserJock | they shouldn't be making changes they can't maintian, IMO | 17:52 |
| seb128 | you don't have anybody in motu who declare to be responsive for the changes done | 17:53 |
| seb128 | motu should never do any change either | 17:53 |
| slangasek | MOTU collectively are responsible for them | 17:53 |
| seb128 | and they will be responsive for those as for any other change | 17:53 |
| LaserJock | I take responsibility for every upload I make | 17:53 |
| seb128 | and what if you run away next week or get a new job or for whatever reason stop contributing? | 17:53 |
| slangasek | which is why, when it appears that someone is making a change and expecting the rest of the MOTU to take responsibility for the ongoing work, there's resistance | 17:53 |
| seb128 | that's life | 17:53 |
| LaserJock | then I will step down right | 17:54 |
| seb128 | does it mean you should stop you doing changes? | 17:54 |
| LaserJock | and hand my responsibilties off | 17:54 |
| persia | seb128, That'd be a violation of the Code of Conduct, unless there was a transition effort. | 17:54 |
| seb128 | persia: what do you mean? | 17:54 |
| slangasek | seb128: again, you're mischaracterizing the problem. There's a difference between not being committed, and being unable to fulfill the committment due to changing circumstances | 17:54 |
| seb128 | come on that's open source, people have life, they contribute when they can and sometime get busy, you want to track them down now when they do? | 17:55 |
| LaserJock | seb128: that whole "Step down considerately" paragraph | 17:55 |
| seb128 | slangasek: we always do things in a best effort way | 17:55 |
| pochu | looks like it's just 12 packages: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=dxteam | 17:55 |
| persia | seb128, Part of the Code of Conduct is that we will step down gracefully, and hand over any resposibilities or tasks if we leave. That includes responsibility for uploads. Most of those who were active and have faded away have asked others to care for their packages that had significant unavoidable delta in universe. | 17:55 |
| seb128 | persia: ok, we don't live in the same opensource world | 17:55 |
| slangasek | seb128: yes - but where has anyone agreed to make that effort? | 17:56 |
| slangasek | for the set of changes in question | 17:56 |
| seb128 | slangasek: well, whoever writes the patch make the effort to get the thing done | 17:56 |
| seb128 | when I write a patch for GNOME I don't agree to update the changes when they reorganize their code either | 17:56 |
| slangasek | now, if the usability is really as horrible as it sounds, then this falls under the general "bugfixes" umbrella and I'm of the opinion that it's reasonable for MOTU to collectively shoulder the additional workload | 17:57 |
| seb128 | that's not how opensource work | 17:57 |
| seb128 | I sponsor ton of changes without asking for commitment for the patch submitters | 17:57 |
| seb128 | for -> from | 17:57 |
| slangasek | seb128: but if you write a patch and GNOME reorganizes their code before it's accepted, it's your responsibility to rewrite your patch to get it accepted, not upstream's | 17:57 |
| seb128 | slangasek: ok, that's my point | 17:57 |
| seb128 | slangasek: well, but what you ask there is for people to commit to update their fixes for ever, who is wanting to commit to do that when fixing a bug? | 17:58 |
| seb128 | when I fix a bug I usually send a patch | 17:58 |
| seb128 | and switch to something else | 17:58 |
| persia | slangasek, Completely agreed: a bug is a bug. I'd like to see the patches sent upstream as well, but delaying on acceptance is dependent on the bug/enhancement determination. | 17:59 |
| seb128 | persia: there is no upstream there ... | 17:59 |
| slangasek | seb128: right; I think the disconnect here is that you've been approaching these as "bugfixes", and others have been assuming "enhancements"... :) | 17:59 |
| seb128 | persia: that's like waiting for upstream to take launchpad integration changes | 17:59 |
| pochu | what will happen if a package isn't patched to not display actions? will the notification keep working, just without the button? | 18:01 |
| slangasek | so instead of making the case for why these are important bugfixes that it's warranted for universe to carry a delta for, we've wound up down a rathole discussing Principles of Open Source Contribution :) | 18:01 |
| seb128 | slangasek: I was not sure of the discussion, I just disagree about MOTU wontfix useful changes just because they don't want to maintain those | 18:02 |
| seb128 | pochu: no, it will have some ugly fallback mode really annoying | 18:02 |
| persia | I'm confused. At the beginning of the discussion, it seemed like we were talking about patches that were sent to some upstream and waiting on discussion. If that's not the case, then they are indeed unavoidable distro deslta. | 18:02 |
| slangasek | seb128: maintaining the changes is a collective responsibility, so FWIW I think it's reasonable that deciding to accept the delta is also a collective decision | 18:03 |
| seb128 | persia: those changes can go upstream though upstream have no strong reason to take those since their implementation has no issue with the current way to do thing | 18:04 |
| slangasek | which is different than saying I think the delta should not be accepted in this case | 18:04 |
| seb128 | slangasek: what struck me there is that ubuntu people argue that universe applications should look ugly on ubuntu just because they don't want the project to carry a few liners changes | 18:04 |
| persia | seb128, Ah. Thanks for the explanation. | 18:04 |
| LaserJock | seb128: I don't think anybody said that | 18:05 |
| slangasek | seb128: there's an awful lot of stuff in universe that looks ugly, for reasons unrelated to the notification spec :_) | 18:05 |
| seb128 | persia: the upstream notification daemon display action correctly, the ubuntu one will not but fallback to something annoying and ugly (ie opening dialogs for example) | 18:05 |
| persia | seb128, At least I'm not arguing that universe applications should look ugly, but only that if someone uploads something, they should take responsibility for ensuring that the outstanding delta is ported forward in the future. | 18:05 |
| seb128 | slangasek: and we usually don't refuse patches to fix those things | 18:05 |
| slangasek | seb128: if it meant redesigning upstream's UI, I expect we would | 18:06 |
| LaserJock | if somebody were to port a GTK1 app to GTK2 I'd tell them to go upstream | 18:06 |
| pochu | seb128: huh, either we fix everything or we change that to not open a dialog... I'd hate if everytime a song is played, a dialog is opened ;) | 18:06 |
| seb128 | LaserJock: did you read what I just said? | 18:06 |
| seb128 | pochu: that will open a dialog, the discussion is wether we want the few line patch to not open a dialog | 18:07 |
| LaserJock | seb128: yes, we do sometimes refuse fixes because they aren't very maintainable and should go upstream | 18:07 |
| seb128 | which is what people are resistant to | 18:07 |
| seb128 | LaserJock: there is no upstream there, grrrr | 18:07 |
| LaserJock | seb128: sure there is | 18:08 |
| seb128 | LaserJock: no there is not | 18:08 |
| seb128 | LaserJock: this notification daemon is new ubuntu code | 18:08 |
| LaserJock | right | 18:08 |
| seb128 | it's different of the upstream one | 18:08 |
| LaserJock | but the change comes from Dx and the packages we have to change have upstreams | 18:08 |
| seb128 | why should upstream change their code to work on an ubuntu specific daemon? | 18:08 |
| LaserJock | well, frankly that's why you don't *do* stuff like that in a distro | 18:09 |
| LaserJock | but that's somewhat beside the point | 18:09 |
| pitti | seb128: please note that the fd.o libnotify protocol, as it is, doesn't guarantee availability of actions | 18:09 |
| pitti | seb128: also, the change is being made for an usability argument, not just because of our daemon | 18:09 |
| pochu | LaserJock: the problem is that upstream may not accept it as their code still works with a vanilla notification-daemon. But then if we don't patch it, it will look ugly / loose some functionality | 18:09 |
| LaserJock | pochu: sure | 18:09 |
| LaserJock | again, I'm *not* against the change | 18:09 |
| pochu | then? | 18:10 |
| LaserJock | I'm against a dump-and-forget mentality by Dx | 18:10 |
| pochu | changes are going to be forwarded upstream | 18:10 |
| seb128 | LaserJock: there is no such mentality | 18:10 |
| pochu | LaserJock: I see that mentality everyday in jaunty-changes | 18:10 |
| seb128 | you are the one assuming there is one | 18:10 |
| LaserJock | seb128: you *told* me there was no commitment | 18:10 |
| persia | pochu, That's not an excuse: that's a target for correction. | 18:11 |
| pochu | persia: then we need specific maintainers for every package | 18:11 |
| LaserJock | Dx is making a change that we would not have otherwise | 18:11 |
| LaserJock | so I do expect some commitment from them on at least helping us maintain it | 18:11 |
| LaserJock | when we need merges would they be willing to help with that? | 18:11 |
| seb128 | LaserJock: commitment is strong, we work on a best effort basis usually | 18:11 |
| pochu | I hope so | 18:12 |
| LaserJock | ok, so are they going to put effort into it or no? | 18:12 |
| LaserJock | my impression was that they weren't | 18:12 |
| seb128 | that's a different question than commitment | 18:12 |
| seb128 | ask them | 18:12 |
| pochu | if you do a merge and the upstream code has changed so much as to make the update non-trivial wrt the notification patch, I'd hope the Dx guys to lend a hand with the patch update | 18:12 |
| seb128 | I'm wanting to put some effort in it | 18:12 |
| seb128 | but I will not commit to do any work | 18:12 |
| LaserJock | pochu: exactly | 18:12 |
| seb128 | I've enough to do | 18:12 |
| ogra | LaserJock, so if you were the new upstream for a new notification system that required chnages to an app, would you wirte patches for all apps in the first distro that uses your system over the existing one ? | 18:12 |
| seb128 | and I work on best effort basis | 18:12 |
| persia | pochu, I don't follow how the one leads to another. If I make a change, I'll take responsibility for porting that change, or getting it upstream, and expect that if someone has a question about a change I made when making their change, I'll be asked. I don't care if someone else works on a package I changed: I think that's a good thing, but the individual change is my responsibility. | 18:12 |
| LaserJock | ogra: no, but that's not the case here | 18:13 |
| ogra | sure it is | 18:13 |
| seb128 | pochu: we agreed to just drop the patch in such case if they don't update it | 18:13 |
| LaserJock | not it isn't | 18:13 |
| LaserJock | the distros would have a choice whethe to accept the notification system | 18:13 |
| ogra | and ubuntu chose to | 18:13 |
| LaserJock | and they are unlikely to do so until the apps support it decently well | 18:13 |
| pochu | we do integration work all the time | 18:14 |
| pitti | apw: the change needs some work, _("text") + self.report['FlagFile'] doesn't really work i18n wise | 18:14 |
| LaserJock | in this case the distro *is* the upstream and we have no choice | 18:14 |
| pochu | I really can't figure out what's wrong with patching 12 packages to work with the new system | 18:14 |
| persia | seb128, That addresses all the concerns: adding a patch with a plan to drop it if not accepted is a committment to making sure the package continues to work long-term. | 18:14 |
| pitti | apw: and we need to apply the same change to the qt version | 18:14 |
| ogra | LaserJock, canonical != ubuntu | 18:14 |
| LaserJock | so they tell me | 18:14 |
| apw | pitti, thought you'd say that, whats the right way to fix that? | 18:14 |
| apw | there is a qt version? | 18:15 |
| pitti | apw: I need to run now, but unless you beat me to it I can try and look into it on Monday | 18:15 |
| ogra | this system wasnt developed by the ubuntu distro team it has its own upstream ... | 18:15 |
| ogra | totally distinct | 18:15 |
| apw | pitti, will see how i get on, and sync with you on mon | 18:15 |
| pitti | apw: I'd check the value of self.report['FlagFile'] and based on that, use two different strings | 18:15 |
| LaserJock | ok, then can Ubuntu refuse it then? | 18:15 |
| apw | ok | 18:15 |
| jcastro | LaserJock: at the minimum the DX patches sent to gnome upstream (or whatever) should be linked to the lp bug filed in ubuntu. I noticed that today and ask tedg to let the DX people know to do that. | 18:16 |
| pitti | apw: also, the label in the glade file that you changed is still marked as translatable, but now just contains markup | 18:16 |
| LaserJock | I mean, I'm really not against the change. I think all 12 apps will end up patched | 18:17 |
| pitti | apw: that's fine, just remove the translatable="yes" | 18:17 |
| LaserJock | but I don't like Canonical deciding something and then expecting MOTU to "just deal with it" | 18:17 |
| LaserJock | I'm hoping that's not what's going on | 18:17 |
| jcastro | LaserJock: well, if the bugs are linked we can at least keep track, banshee upstream for example accepted the patch | 18:17 |
| LaserJock | and mostly I'm happy with it | 18:17 |
| seb128 | LaserJock: again there is no canonical there but ubuntu as a project and distro | 18:18 |
| LaserJock | whatever | 18:18 |
| jcastro | it's an easy fix, filed in lp, filed upstream, and then we tag it and link it. | 18:18 |
| seb128 | LaserJock: who contributes should not be an issue and ubuntu is still free to accept changes or not | 18:18 |
| LaserJock | this is Canonical's team, I don't see how you get around that | 18:18 |
| LaserJock | but you could do s/Canonical/Ubuntu team that's not MOTU/ if you like | 18:19 |
| pochu | pitti: do you have a link to that fdo spec? | 18:19 |
| LaserJock | the point is about how orthogonal teams in Ubuntu should work on things | 18:20 |
| LaserJock | and I generally feel like "deal with it" is not a great attitude | 18:20 |
| seb128 | LaserJock: that's not really team revelant, motus dump work on other motus all the time | 18:20 |
| LaserJock | hopefully that's not what's going on, but saying that Dx has no commitment to the changes they make in Universe doesn't sound encouraging | 18:20 |
| seb128 | some upload libraries soname changes which need transitions, etc | 18:20 |
| LaserJock | seb128: that's vastly different though | 18:21 |
| seb128 | I've for sure no commitment to rebuild the whole archive because I do a soname change | 18:21 |
| seb128 | I do try to do rebuilds though | 18:21 |
| pochu | pitti: I think if I point upstream to it for one of the affected packages, he won't have problems in making the action conditional to whether the daemon has actions support or not | 18:21 |
| LaserJock | that's team work, so team members are accountable to other team members | 18:21 |
| james_w | pochu: it's a galago spec, not fdo at this point | 18:22 |
| james_w | pochu: it is *the* notification spec though still | 18:22 |
| LaserJock | anyway, I don't think there's much disagreement here | 18:22 |
| directhex | galago? | 18:22 |
| LaserJock | 12 packages isn't much work | 18:22 |
| directhex | o_o | 18:22 |
| pochu | james_w: ah, thanks | 18:22 |
| james_w | http://www.galago-project.org/specs/notification/0.9/index.html | 18:22 |
| pochu | james_w: http://www.galago-project.org/specs/notification/, right? | 18:22 |
| pochu | :) | 18:22 |
| james_w | you got it | 18:22 |
| directhex | i have a maintainer who wants to RM the galago bindings for mono, due to lack of users | 18:23 |
| pochu | ah cool | 18:23 |
| pochu | notification-daemon's upstream wrote it | 18:23 |
| james_w | directhex: does banshee use them? | 18:23 |
| LaserJock | if MOTU end up having problem maintaining the diff and nock on Dx's door I hope they'd be willing to help | 18:23 |
| pochu | so | 18:24 |
| directhex | james_w, no. nothing does. except beagle, optionally | 18:24 |
| pochu | these are all upstream bugs | 18:24 |
| pochu | we can't forward them upstream and fix them in Ubuntu at the same time | 18:24 |
| james_w | pochu: the ones currently reported are, yes | 18:24 |
| directhex | james_w, iirc banshee uses its own notification thing, due to lack of features in the conventional gtk methods | 18:24 |
| pochu | "This functionality may not be implemented by the notification server, conforming clients should check if it is available before using it" | 18:25 |
| james_w | pochu: though currently minor as there is only one implementation of the daemon so far | 18:25 |
| pochu | james_w: but bugs nevertheless :) | 18:25 |
| persia | pochu, Why not? I'd think that's the best way to fix a bug. Fix it in Ubuntu, and push the patch upstream. | 18:25 |
| Adri2000 | slangasek: any change coming in debian we should wait for? or can we merge now? (do you want to do the merge?) | 18:25 |
| pochu | persia: so we can fix all these bugs in Ubuntu | 18:25 |
| seb128 | LaserJock: it was agreed that if patches are not trivial to update and they are not responsive we would drop those | 18:25 |
| seb128 | LaserJock: meanwhile they is no real reason to refuse written patches | 18:26 |
| * pochu files a bug to one of his upstreams | 18:26 | |
| seb128 | LaserJock: that makes applications look better meanwhile and you can drop that later if required | 18:26 |
| slangasek | Adri2000: there will be an upload to unstable soon, which will make the merge a bit easier since it will show up in MoM then :) | 18:26 |
| persia | pochu, I've not looked at the specific bugs, but I don't see any reason why not. I especially like your suggestion of trying to determine what sort of support is available for multiple code paths. | 18:26 |
| james_w | pochu: if it is a C project then see the goobox bug for a patch that queries the capabilities | 18:26 |
| Adri2000 | slangasek: okay | 18:26 |
| pochu | james_w: do you have an example for Python apps? | 18:27 |
| james_w | pochu: not yet | 18:27 |
| pochu | james_w: ok, let me know if/when you know of one. Will be helpful to my upstream :) | 18:28 |
| directhex | james_w, and if banshee loses its actions in its notifications, i'll cry. | 18:28 |
| devfil2 | pochu: emesene? | 18:30 |
| james_w | pochu: 'actions' in pynotify.get_server_caps() | 18:30 |
| james_w | pochu: after pynotify.init(... | 18:30 |
| pochu | devfil2: decibel-audio-player | 18:31 |
| devfil2 | pochu: ok | 18:32 |
| pochu | james_w: thanks, I just found it too ;) | 18:32 |
| pochu | ok, forwarded upstream | 18:35 |
| pochu | the other one would be Liferea | 18:35 |
| * pochu check the C patch | 18:35 | |
| savvas | are .save files in /etc/apt/sources.list.d/ ignored? | 18:39 |
| slangasek | I wouldn't expect so | 18:39 |
| savvas | hm.. I think Software Sources adds .save files in there, let me check again | 18:40 |
| savvas | yep | 18:40 |
| cody-somerville | I think only files ending in .list got parsed | 18:43 |
| cody-somerville | *get | 18:43 |
| savvas | http://paste.ubuntu.com/117765/ | 18:44 |
| savvas | ah .list files | 18:45 |
| savvas | thanks cody-somerville ! :) | 18:45 |
| lamont | Keybuk: I'm planning to push 2.14.2 to jaunty - does that make sense for the basis of your stuff? | 18:45 |
| Keybuk | sure, that'd be good | 18:45 |
| Keybuk | Karel hasn't made public his topic/blkid to master push | 18:45 |
| devfil2 | Keybuk: can I work on uswsusp merge? It's a new upstream release | 18:47 |
| Keybuk | devfil2: you can do whatever you like ;) | 18:47 |
| Keybuk | you don't need my permission | 18:47 |
| Keybuk | obviously things may change once I'm Emperor of the World | 18:48 |
| devfil2 | Keybuk: I think it's good to ask the last uploader if you want to work on a merge/sync | 18:49 |
| lamont | Keybuk: I thought that happened with either the udev or upstart upload | 18:49 |
| Keybuk | devfil2: I uploaded it last? | 18:49 |
| Keybuk | lamont: needs a util-linux-ng 2.15 upload first ;) | 18:50 |
| devfil2 | Keybuk: yes, DaD reports that you are the last uploader | 18:50 |
| devfil2 | you did a rebuild as I can see | 18:50 |
| slytherin | can any archive admin please process sync bug 326172? I am waiting for it to process fop merge. | 18:52 |
| ubottu | Launchpad bug 326172 in xmlgraphics-commons "Please sync xmlgraphics-commons 1.3.1 (universe) from debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/326172 | 18:52 |
| === seb128_ is now known as seb128 | ||
| * ScottK just got back and read the backscroll. He thinks it's just as well he had to go ... | 19:07 | |
| ScottK | james_w: I read your changes to the Debain Import spec and I think they are a definite improvement. Thanks. | 19:08 |
| cody-somerville | ScottK, McDonald's kicked you out? | 19:08 |
| ScottK | cody-somerville: Only two hours of free wifi on one arch card per day. | 19:08 |
| ScottK | I had some other stuff to go do anyway. | 19:08 |
| LaserJock | kees: regarding smarty MIR, you really need the full templated wiki page for something that's already in Main? | 19:12 |
| ebroder | Hmm...jdong says he uploaded a new version of xen-meta yesterday to hardy-backports, but I don't see it at <https://launchpad.net/ubuntu/+source/xen-meta>. Where should I watch to track the progress of the package? | 19:14 |
| kees | LaserJock: it's part of the process, and is a nice place to have a historical detail about the package, yeah. will you have time to write it up? | 19:18 |
| jdong | ebroder: it is in the SOURCE NEW queue awaiting archive admin approval | 19:19 |
| jdong | ebroder: all manually uploaded backports require intervention of the archive admins | 19:19 |
| LaserJock | kees: I guess so. I thought I was pretty thorough in the bug report but I can add the usual upstream/debian stuff | 19:19 |
| LaserJock | kees: I'm not a PHP person so I don't think I can really audit any of the code myself | 19:20 |
| ebroder | jdong: Ok. For my own curiosity, is that listed on a website somewhere (I do a lot of work with Debian packaging, but very little work with what the upload process looks like) | 19:20 |
| kees | LaserJock: yeah, no audit needed. just getting the record of CVEs, bugs, activity level, etc. | 19:20 |
| LaserJock | kees: k, will do right now | 19:21 |
| jdong | ebroder: is the queue, or is this process? | 19:21 |
| ebroder | The queue | 19:21 |
| kees | LaserJock: great, thank you! | 19:21 |
| jdong | ebroder: I think it is supposed to show up at https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text= | 19:23 |
| jdong | https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1&queue_text= | 19:24 |
| jdong | that one | 19:24 |
| ebroder | Cool. Thanks | 19:24 |
| Keybuk | gnargh! who took away Alt+F2 | 19:25 |
| * Keybuk shakes his fast | 19:25 | |
| andersk | Run ccsm and activate the Gnome Compatibility plugin. | 19:26 |
| Keybuk | ccsm is not installed | 19:29 |
| andersk | compizconfig-settings-manager package. | 19:29 |
| ivoks | hoce netko firefox-3.1.xpi? | 19:37 |
| ivoks | ups... | 19:37 |
| ScottK | jdong and ebroder: Accepted. | 19:37 |
| jdong | neato :) | 19:38 |
| ScottK | jdong: Next time please Fix Committed and subscribe ubuntu-archive. | 19:42 |
| jdong | indeed, my bad. | 19:42 |
| LaserJock | kees: question on CVEs. There are 14 in the cve search, but most seem to just sort of indirectly mention smarty | 19:44 |
| LaserJock | kees: do you just want the ones where they say the vulnerability is directly in smarty? | 19:44 |
| kees | LaserJock: whatever is easiest | 19:48 |
| kees | LaserJock: just having a pointer to it is a good start | 19:48 |
| LaserJock | kees: well, am I supposed to be actually discussing these or is it merely informative for you? | 19:49 |
| kees | LaserJock: in a perfect world, the MIR would describe how all CVEs against smart are closed. | 19:50 |
| kees | e.g. if upstream has a list of fixes, etc. | 19:50 |
| * ScottK remembers the clamav MIR "Yeah, there's a lot of them, but we ought to suck it up and do this anyway". | 19:53 | |
| calc | grr at&t can't actually install the faster internet that the tech claimed they could, i'm too far out for the other service as well | 19:54 |
| calc | max distance is 3000ft and i am apparently at 4000ft for that service | 19:54 |
| calc | so i will be stuck with either slow service or have to switch to comcast :\ | 19:54 |
| ScottK | No Verizon where you are? | 19:54 |
| calc | ScottK: no verizon anywhere nearby | 19:54 |
| calc | ScottK: i think the closest place verizon has fios is about 250mi from here | 19:55 |
| calc | at&t is the ilec here unfortunately | 19:55 |
| * ScottK is a big fan of FIOS. | 19:55 | |
| calc | if i moved to another house i could get 18/1.5 from at&t, but where i currently am | 19:55 |
| calc | and comcast doesn't even have their fast speeds yet in houston aiui | 19:56 |
| ScottK | Before I moved and had DSL, I found third party DSL providers could do faster than the telco. | 19:56 |
| calc | but it would be a little faster than what i have now (3.0/0.5) | 19:56 |
| calc | ScottK: this issue is a line length problem, i am 16K ft from the dsl location and 4K ft from the higher end equipment | 19:57 |
| ScottK | If megapath dsl serves your area I highly recommend them. | 19:57 |
| jsmidt | If I have a package which doesn't have a version number yet, it is just a git snapshot, but I would like to pakage it, what is the naming convention? foo-git20090213? | 19:57 |
| calc | the only way i could get higher speed is if they rerun my line from the telco building, which is very unlikely :( | 19:57 |
| slytherin | jsmidt: foo-0+gitxxxxxx | 19:57 |
| jsmidt | slytherin, thanks | 19:58 |
| calc | ScottK: i'm going to call at&t and ask the sales group if there is any way to get it fixed they want to sell this new tv setup but my line is too far away | 19:58 |
| ScottK | Good luck. | 19:58 |
| ScottK | If there's a buildd admin about, it'd be nice to have a retry for soundtracker on hppa. The current FTBFS predates the LP retry function and so I can't do it via the GUI. I assume that's why anyway. | 20:02 |
| ScottK | Being able to remove libdb4.5 is blocked on this currenlty. | 20:03 |
| LaserJock | kees: hmm, yeah. moodle's smarty is older than our dapper version | 20:04 |
| LaserJock | kees: I think we'll be getting rid of some vulnerabilities ;-) | 20:04 |
| kees | LaserJock: yeah, no doubt at all. :) | 20:08 |
| Mithrandir | ScottK: given-back on hppa | 20:08 |
| ScottK | Mithrandir: Thanks. | 20:08 |
| Mithrandir | ScottK: you're aware it FTBFS on armel too? | 20:09 |
| ScottK | Mithrandir: I wasn't. The hppa FTBFS was the only one where the obsolete binary still depends on the old libdb version. | 20:10 |
| * ScottK isn't particularly interested in soundtracker. ... trying to excise cruft. | 20:10 | |
| LaserJock | kees: secunia searches suck :/ | 20:17 |
| Mithrandir | ScottK: ah, ok. | 20:21 |
| ScottK | Now that you mention it, I looked and I suspect a retry would work now. I'll press that button. | 20:22 |
| ScottK | There's also something odd going on with qt4-x11 on sparc. It was building on artigas when artigas timed out last night. Since it came back it's built partway twice and then (AFAICT) gone immediately back to Needs Build. I'd be interesting in the log if it's failing so we can get it fixed. | 20:24 |
| kees | LaserJock: yeah :( | 20:30 |
| LaserJock | kees: I tried smarty and Smarty and got nothing but I then found a link to one that had "Smarty" in the title | 20:34 |
| LaserJock | go figure | 20:34 |
| sbeattie | ScottK: bug 318866 verified. | 20:38 |
| ubottu | Launchpad bug 318866 in kdeutils "printer-applet does not display when new printers get configured" [Undecided,Fix committed] https://launchpad.net/bugs/318866 | 20:38 |
| Riddell | yay! | 20:39 |
| LaserJock | kees: all yours :-) | 20:46 |
| kees | LaserJock: cool, thx | 20:47 |
| ScottK | sbeattie: Great. Thanks. | 20:59 |
| ScottK | pitti: I believe that KDE 4.1.4 is fully verified, so we're ready to copy it to intrepid-updates. All the bugs are tagged kde4.1.4 and have intrepid tasks open for it. | 21:00 |
| calc | grr at&t can't do anything to fix it unless they get a lot of complaints :\ | 21:09 |
| LaserJock | calc: a shell script? | 21:13 |
| LaserJock | :-) | 21:13 |
| bryce | interesting; LP seems to be cutting off at displaying 80 comments | 21:20 |
| TheMuso | ?c | 21:20 |
| bryce | wish it was the 80 newest comments instead of the 80 oldest | 21:20 |
| TheMuso | ScottK: thanks | 21:20 |
| TheMuso | At least we have a kernel for all ports now. I expect sparc to build, so I can now move onto getting other bits updated. | 21:22 |
| === smarter_ is now known as smarter | ||
| sistpoty | Riddell: around...? would you agree to act as delegate for motu-release for universe kde package for jaunty again? | 22:00 |
| Riddell | sistpoty: sure | 22:01 |
| sistpoty | Riddell: thanks a lot! | 22:01 |
| Lure | sistpoty: you have ScottK there too... | 22:01 |
| === wgrant_ is now known as wgrant | ||
| sistpoty | Lure: but I plan to abuse him for server again :P | 22:01 |
| Lure | sistpoty: good plan ;-) | 22:02 |
| sistpoty | superm1: how about you acting as delegate for mythbuntu for motu-release for jaunty? | 22:02 |
| sistpoty | (again) | 22:03 |
| sistpoty | cody-somerville: same question for you in regards to xubuntu? | 22:03 |
| sistpoty | asac: and you for mozilla? I recall we had a backup... who was it again? fta? (sorry for my lacking memory) | 22:05 |
| * calc might be able to get on a at&t test group, waiting on phone to find out | 22:07 | |
| sistpoty | ogra: up for ubuntu-mobile motu-release delegate again? | 22:08 |
| sistpoty | ScottK: would you want to go for -server again? | 22:10 |
| ScottK | Sure. | 22:10 |
| sistpoty | excellent, thanks! | 22:10 |
| sebner | sistpoty the organisation horse/talent :D | 22:12 |
| sistpoty | sebner: haha | 22:12 |
| calc | gah no timeline available for when they will be offering the test service | 22:17 |
| calc | they only offer uverse with 27mbps sync speed currently, so you have to be really close to the office :-\ | 22:17 |
| calc | doesn't matter what speed you pay for they sync it at 27mbps so you can't get it past 3000ft regardless of if you want 1mbps or 18mbps internet | 22:18 |
| ebroder | Should I subscribe...ubuntu-archive to bug #216761 to get it out of the unaccepted queue? | 22:28 |
| ubottu | Launchpad bug 216761 in xen-3.3 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/216761 | 22:28 |
| ebroder | (Err...unapproved, but whatever) | 22:28 |
| maxb | There's no mention on wiki.ubuntu.com/StableReleaseUpdates of a need to subscribe ubuntu-archive, so I suppose the fact that it's in Unapproved at all is enough for it to be on their radar. | 22:31 |
| ebroder | One might hope as much, but it has been there for a non-trivial amount of time | 22:31 |
| * ScottK looks | 22:54 | |
| ScottK | ebroder: The SRU team is subscribed. That's the appropriate team for htat. | 22:56 |
| ebroder | ScottK: Ok, thanks | 22:57 |
| bryce | kees: I have my fglrx system up and good to go, how can I help you on 323327 now? | 23:08 |
| Kakinho | :P | 23:09 |
| Duff | »mneptok«: plizzz private? | 23:10 |
| directhex | don't you *hate* that? | 23:10 |
| savvas | eh? | 23:11 |
| mneptok | that's a big red "NO GO," Houston. | 23:11 |
| savvas | oh, I thought directhex was referring to valentine's day :P | 23:12 |
| kolby | how important is the python programming language? | 23:15 |
| ScottK | 42 | 23:15 |
| sistpoty | heh | 23:15 |
| slytherin | kolby: important to whom? | 23:15 |
| kolby | really, though. Would anyone agree that the C programming language is more valuable to the Open Source world than Python? | 23:16 |
| ebroder | Mu | 23:16 |
| kolby | perhaps people would be more interested in learning python before C. | 23:16 |
| kolby | if people can quickly learn and use something when they become interested in it, that would be a valuable tool.. | 23:17 |
| ScottK | kolby: This is all rather unrelated to Ubuntu developement. | 23:18 |
| * ScottK suggest #ubuntu-offtopic. | 23:18 | |
| kolby | I'll continue this discussion there. | 23:18 |
| ScottK | Thanks. | 23:19 |
| kees | bryce: yup, -> privmsg | 23:19 |
| ion_ | \o/ | 23:31 |
| ScottK | Urgh. Artigas is on it's third or fourth try on qt4-x11. I think it needs some buildd admin to go give it a really hard kick. | 23:40 |
| * directhex hands ScottK a shotgun | 23:41 | |
| * ScottK hands it back since it's probably patent infested. | 23:42 | |
| directhex | ScottK, the point & click interface it provides may be covered by some xerox patents... | 23:43 |
| ScottK | With a shotgun if it's point and click, that's a bug. | 23:43 |
| directhex | i never said i gave you any ammo... | 23:44 |
| ScottK | You assume I don't already have some. | 23:45 |
| TheMuso | ScottK: Or could it just be that that sparc box is slow? | 23:51 |
| ScottK | TheMuso: No, it's been several hours into the build and then been fewer hours into the build. | 23:51 |
| TheMuso | right | 23:51 |
| ScottK | I caught it needs building at one point. | 23:51 |
| sistpoty | TheMuso: feel free to (ab)use spooky for sparc test-builds, if you're in need for a sparc box | 23:51 |
| TheMuso | sistpoty: Whats it specs? I'd rather not throw kernels at it if its not that beefy. | 23:52 |
| * sistpoty checks | 23:52 | |
| sistpoty | TheMuso: http://paste.ubuntu.com/117886/ (/me must admit that he's not familiar with what that actually means) | 23:53 |
| TheMuso | Hrm me neither. :) | 23:54 |
| sistpoty | TheMuso: but it feels fast compared to sparky *g* | 23:54 |
| TheMuso | sistpoty: Anyway thanks for pointing that out, if I am in a jam and I need to do a build test, I will make use of it. | 23:55 |
| TheMuso | sistpoty: Ok thats good to know. | 23:55 |
| sistpoty | TheMuso: just ping around in #ubuntu-wire for an account then ;) | 23:55 |
| TheMuso | Great. | 23:55 |
| * TheMuso searches for give backs for ports on http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_probs.html. | 23:55 | |
| sistpoty | TheMuso: erm. #ubuntuwire even | 23:56 |
| TheMuso | heh | 23:56 |
| TheMuso | ScottK: the qt build on sparc is moving. I just refreshed its status page and the compilation has moved along. | 23:57 |
| ScottK | TheMuso: Yep. It'll do that and then later it starts over. | 23:58 |
| ScottK | TheMuso: You can leave the KDE related ones to me. They have an order they need to be done it. | 23:58 |
| TheMuso | ScottK: Ok will do. | 23:58 |
| TheMuso | ScottK: I knew you were doing them anyway, but I'm taking care of other stuff. | 23:59 |
| Riddell | yay for ScottK, saviour of KDE on ports | 23:59 |
| ScottK | OK. Just don't want to waste time on slow archs ... | 23:59 |
| * TheMuso nods. | 23:59 | |
| ScottK | Riddell: Wouldn't have been possible without TheMuso's work on kernels. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!