/srv/irclogs.ubuntu.com/2009/02/13/#ubuntu-devel.txt

dokoI really love autoconf-2.6300:03
Keybukreally? why?00:04
Keybukwhat's better compared to 2.61? :p00:05
dokojust trying to get gcc-4.3 and gcj-4.3 buildable again00:11
Keybukdid it break anything?00:12
dokogcc-4.3 and gcj-4.300:13
Keybukhow were they broken?00:13
Keybukit didn't look like much changed from 2.61 to 2.6300:13
dokosee https://edge.launchpad.net/ubuntu/+source/gcc-4.3/4.3.3-3ubuntu400:13
dokofixed that by using autoconf-2.59, as required by upstream00:14
dokostill have to look at the failure for gcj-4.300:14
dokoif /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 -O200: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; fi00:15
Keybukweird00:15
KeybukI can't see anything obvious in the i386 build log that looks like an autoconf failure00:15
dokoprobably this is my mistake (@EXTRA_CFLAGS@ not substituted)00:15
dokowell, it does work again using autoconf-2.5900:16
KeybukI can't find the error in the build log?00:16
Keybuklibtool: compile: not configured to build any kind of library00:17
Keybuklibtool: compile: See the libtool documentation for more information.00:17
Keybuklibtool: compile: Fatal configuration error.00:17
Keybuk./libtool: line 150: CDPATH: command not found00:17
Keybukthat looks like the problem?00:18
dokoit's in libobjc00:18
dokoyep00:19
dokoanyway, heading to bed now, will look at this after feature freeze00:20
Keybukbit of an odd one00:21
Keybuksince all libtool ever does with CDPATH is try and unset it ;)00:21
Keybuklooks more like a libtool bug00:22
dokomaybe, triggered by the autoconf update00:23
Keybuksh -e debian/patches/libobjc-gc-link.dpatch -patch -d /build/buildd/gcc-4.3-4.3.3/src00:23
Keybukpatching file libobjc/Makefile.in00:23
Keybukwhat does that patch do? :)00:23
Keybukpatching file libobjc/configure.ac00:23
dokopatching the libobjc/configure.ac and after that calling atutoconf the regenerate the configure file00:24
Keybukit might just be an ordering of the configure.ac problem00:25
doko2008-07-03  Matthias Klose  <doko@ubuntu.com>00:26
doko        * configure.ac (OBJC_BOEHM_GC_LIBS): Link with libgcjgc_convenience.la00: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
Keybukdid it work ok with 2.61?00:27
dokoyes, 4.3.3-3ubuntu3 was built sucessfully before the autoconf update00:28
Keybukkooky00:30
Keybukeverything in here is just a bug fix00:30
Keybukmostly to do with string quoting00:31
KeybukI'll have a look here and see if I can figure it out00:31
Keybukhmm, you build-dep on automake 1.9?00:38
Keybukmight be a bug caused by that - try 1.10?00:39
cody-somervilleKeybuk, :P00:40
* Adri2000 needs a core-dev click on bug #32887400:43
ubottuLaunchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Undecided,New] https://launchpad.net/bugs/32887400:43
Adri2000(hardy nomination)00:43
Adri2000cody-somerville or Keybuk ? ^00:50
=== RAOF_ is now known as RAOF
ScottKIf 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
StevenKartigas was showing as timed out on +builds ...04:47
ScottKYep.  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
StevenKScottK: 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 built04:48
ScottKI did jump the gun on a few.  Sorry for spamming your inbox.  Thanks for taking care of it.04:49
ScottKToday I hit a few sparc retries by accident when I meant to do powerpc.04:49
StevenKWe could start fixing ia64, too. Hm, did I release it from NEW ...04:50
ScottKYes.  I retried mesa.  that's the first one.04:51
StevenKOn sparc or ia64?04:51
ScottKWaiting for it now.  Unfortunately soyuz in it's infinite wisdom scores all manual retries at 0.04:51
ScottKia6404:52
StevenKI'm not certain I released linux-ports ia64 from NEW04:52
ScottKSomeone did.04:52
ScottKsparc it's done.  qt4-x11 was the next in the chain.04:52
* StevenK shrugs04:52
ScottKI'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
StevenKYes, kernels are special04:53
ScottKWhich is fine.  I probably wouldn't touch them even if I could.04:54
ScottKI knocked out at least a third of the out of date on power pc already last night and today.04:55
StevenKThe last time I NEW'd a kernel the whole thing ended up in universe :-(04:55
StevenKWhich involved a *large* one-liner and bunch of watching to fix04:56
StevenKScottK: So you're the reason the powerpc queue is so large? :-)05:00
ScottKYes.05:00
ScottKI did the same thing to lpia and armel recently too.05:01
dholbachgood morning06:23
ion_morniŋ06:26
ScottKGood morning06:28
highvoltagegood moo06:28
highvoltageand morning06:28
dholbachhi ion_, scottK, highvoltage06:29
highvoltagedholbach: 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
dholbachhighvoltage: it's not like I did most of the work there06:30
dholbachhighvoltage: check out http://www.jonobacon.org/2009/02/13/the-docs-were-indeed-rocked/06:30
dholbachhighvoltage: lots of people put some hard work into fixing the docs, which is awesome06:31
highvoltage*nod*06:31
highvoltageI just read that post06:31
dholbach:)06:31
KoonArchive 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.108:34
pittiGood morning08:54
StevenKMorning pitti08:55
seb128hello pitti StevenK sabdfl08:56
StevenKHey seb12808:56
sabdflhowdy seb12808:56
sabdflare we feeling jaunty this moining?08:56
pittihey sabdfl08:57
pittisabdfl: look, behind! a three-antlered jackalope!08:57
sorenpitti: Yikes.08:58
Koonpitti: the jackalope is ahead, not behind.08:58
directhexmornin'!09:03
apwanyone know anything about glade widget definitions?  specicially if they can have variables in tehm?09:06
ogra_you mean inside the xml ?09:06
apwyeah in that xml spagetti09:06
ogra_yep, you usually can define default values in there09:07
apwi have two identicle widgets other than the description line, and that seems stupid09:07
apwnice where can i find out how to override them09:07
ogra_well, in the xml code worst case09:07
* apw needs some n00b docs, clearly09:08
ogra_apw, i always use a gui for creating the glade files being a lazy chap ...09:10
apwhmmmm yeah wonder what was used before09:10
ogra_glade-3 or glade-gnome-309:11
ogra_they are very helpful tools09:11
* directhex used glade once upon a time09:11
* apw watches his disk space dissappear09:14
* ogra_ hands apw bzip209:14
* apw tries to mount /usr/bin via fuse to it09:14
ogra_haha09:15
liwmvo, yo?09:29
=== mvo__ is now known as mvo
liwmvo, connectivity problems?09:40
mvoliw: yes :(09:41
mvoliw: give me some minutes, I'm still fighting a compiz problem09:42
liwmvo, sure09:42
apwpitti, which version of the glade editors would you have used to edit the apport glade stuff?09:51
pittiapw: apport's glade is still glade-2, I believe09:52
apwthats why the whole thing changed when i tried to edit it09:53
cjwatsonI always find it best to do a load/save in the glade editor before doing anything else, to see what it changes09:55
sabdflpitti: i blinked and missed it, it booted too fast10:03
savvasslangasek: do you recall why was bug #232469 rejected for jaunty?10:07
ubottuLaunchpad bug 232469 in wget "wget does not use network proxy in some cases" [Undecided,Confirmed] https://launchpad.net/bugs/23246910:07
ivokscorrect me if i'm wrong...10:10
ivoksgcc-4.2 in hardy is 4.2.410:10
ivoksbut the kernel is compiled with 4.2.310:10
cjwatsonsavvas: 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 it10:11
ivokswe can't build modules that way10:11
cjwatsonsavvas: it's usually much more productive to figure out a fix rather than arguing about the nomination state :-010:11
cjwatson:-)10:11
savvasaaah10:11
savvascjwatson: ok, thanks!10:12
savvascjwatson: I wasn't going to argue about it, I was just curious :P10:12
apwcjwatson, did we just have a gcc update for security?10:14
ivoks4.2.4 is in updates10: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 work10:16
seb128weird bug10:17
ogra_yeah10:17
ogra_its only in evo10:17
ogra_and this time i rebooted before checking, but its definately there10:17
seb128nobody else complained about that and I never got this issue10:17
ogra_but you use subfolders as well ?10:18
seb128yes10:18
ogra_though it doesnt work on the toplevel either10:18
ogra_i.e. the inbox expander10:19
seb128it work on the account, inbox, subfolder there10:19
apwivoks, that version is pretty old, entered updates on 2008-10-22, and the kernel version in update and proposed were buld 2009-01-29 ish10:19
apwso i would have expected them to be built with it?10:19
ivoksapw: correct10:19
apwcan you paste the full version string for me from /proc/version10:20
cjwatsonapw: no idea I'm afraid10:21
* apw notes there _is_ something cjwatson doesn't know ... odd10:21
cjwatsonI could look it up ;-)10:21
cjwatson(https://launchpad.net/ubuntu/+source/gcc-4.2)10:21
apwcjwatson, s'ok ... don't worry10:21
cjwatson4.2.4 was in intrepid as released, according to that10:21
cjwatsonoh, this was hardy10:21
ogra_seb128, clicking fast i can see "opening folder" in the status bar10:21
ivoksapw: 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 200910:22
ogra_but the expander still does nothing10:22
seb128ogra_: can you open a bug on bugzilla.gnome.org?10:22
cjwatsonhardy did have an update, but not "just" - it was back in October10:22
apwivoks, can you get the whole output of /proc/version for me10:22
apwthat matches my findings too ...10:22
ogra_seb128, will do ... do you also need something in LP to track it ?10:22
ivoksbut on the other machine:10:22
apwso need to confirm that the kernel was miss compiled or not10:22
seb128ogra_: no10:22
ivoksLinux 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 200810:22
ogra_ok10:22
seb128ogra_: it's not important enough for me to track10:22
ogra_hmm10:23
seb128I don't want to track every upstream bug which happens to one user10:23
ogra_right :/10:23
apwivoks, ok on the 'broken' one whats in /proc/version_signature10:23
* ogra_ is sad he's the only one10:23
seb128or we could import the zillions bugzilla bug to launchpad10:23
ivoksapw: Ubuntu 2.6.24-23.48-server10:23
seb128and make the buglists impossible to work on10:23
ivokshm10:23
ogra_yeah, indeed10:23
apwivoks, and the working one?10:23
ivoksapw: 46-server10:23
ivoksi have kernel from the future? :)10:24
TheMusotjaalton: it happens to the best of us. :p10:24
apwoh, thats a security kernel10:24
apwivoks that looks broke to me, could you file a bug against the linux package please10:25
ivoksapw: sure10:25
apwand in the description put the cat /proc/version and /proc/version_signature10:25
apwfor both the bad and good machines for me10:25
apwit smells like we have a build environment out of sync.  if you could paste me the bug# once its done i'll have a poke10:25
tjaaltonTheMuso: heh.. *headdesk* :)10:26
ivoksapw: we have that bug opened for 3 months: bug 29238110:28
ubottuLaunchpad bug 292381 in linux "[hardy] kernel 2.6.24-21-generic and gcc version mismatch" [High,Triaged] https://launchpad.net/bugs/29238110:28
apwivoks, thanks ...10:28
pittitseliot: 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
pittiRiddell: most kubuntu-jaunty-* specs are "not started"; I guess they are, could you please update their status?10:29
tseliotpitti: bryce will review my changes soon and if we make it available in Jaunty, it will be in universe10:30
ogratjaalton, geeez, i just noticed that evdev started to drive my touchscreen with the lates updates ... (totally miscalibrated though)10:30
pittitseliot: I know, but it's still covered by FF10:30
apwivoks, ok could you add the -23 ones from your experience, and include both /proc/version and /proc/version_signature10:30
ivoksapw: it's a gcc thing10:30
pittitseliot: so there is a working version? great10:30
tjaaltonogra: good or bad?-)10:30
ivoksapw: updates have gcc 4.2.4, but the security has 4.2.310:30
apwivoks, yes i know, but the evidence is in your kernel strings which reported the gcc used10:31
apwthose are therefore what i need10:31
ivoksok10:31
apwshove gcc -v in with each machine too10:31
apwyours is a nice clear example of what is wrong10:31
tseliotpitti: yes, but the UI does not follow the usability guidelines. Other that this, it works well10:31
ogratjaalton, 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
pittitseliot: cool, so it sounds it could well make it into universe by FF, and get UI cleanup by UIF?10:32
pittitseliot: 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
tseliotpitti: I doubt the UI cleanup will be done in time for jaunty10:33
tseliotpitti: but yes, I'll update the blueprint10:33
tjaaltonogra: ok, I don't know if it should autocalibrate somehow10:33
pittitseliot: ah, ok; do you think that' a blocker for getting it into universe?10:33
ogratjaalton, 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 FF10:34
tseliotpitti: 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 universe10:35
pittitseliot: yay10:35
tjaaltonogra: ok, good10:35
apwivoks, let me know when its in there10:35
ivoksapw: there10:35
ivoksapw: 64bit buildd is out of sync10:36
apwivoks, and i assume you get some kind of missmatch error when you try and build and external module?10:37
ivoksapw: yes10:37
apwcan you paste one of those in too for me10:37
apwalso can you add the /etc/apt/sources.list for both machines if possible10:38
tseliotpitti: spec updated10: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 checked10:54
elmodanimo_: feisty is end of life; it moved to old-releases.ubuntu.com10:55
elmodanimo: https://lists.ubuntu.com/archives/ubuntu-announce/2008-September/000113.html10:55
danimo_elmo: ok, just surprised that the other links are still around10:56
elmodanimo_: I agree; that's a bug10:57
danimo_anyway, thanls for the clarification10:58
danimo_er, thanks :)10:59
slytherinwhat could be the reason that a build that was given back yesterday is not yet started?11:10
cjwatsonslytherin: give-backs unfortunately default to a very low score11:13
cjwatson(well, perhaps unfortunately, perhaps not)11:13
cjwatsonit does mean that it's harder to DoS the buildd with give-backs11:14
apwivoks, i suspect your 32 bit machine will suffer the same fate once rebooted11:14
ivoksapw: you think? :)11:15
apwsadly so :)11:15
apwi think we know why this is occuring, just need to work out what the right way out of the maze of twisty pockets is11:15
slytherincjwatson: didn't know that. I was wondering why buildd are picking news uploaded packages when an old one given-back is pending.11:16
ivokswell, it's obvious... -security and -updates don't have same gcc version11:16
ivoksso, there's no easy way out of this11:16
cjwatsonivoks: the easy way out is to copy gcc-4.2 from -updates to -security11:17
ivoksright :)11:17
ivoksand rebuild kernel11:17
apwivoks, right ... two solutions copy gcc to -security, or have two kernel builds one per pocket11:18
apwand someone other than i needs to make that call.. will start the discussion11:18
cjwatsontwo kernel builds => distasteful, IMO11:18
apwcjwatson, i am with you, though its lower risk probabally11:19
cjwatsonpersonally I reckon we've already taken most of the risk having incorporated 4.2.4 into -updates11:20
ivoksso, if ever gcc gets updated again, kernel rebuild is needed11:20
apwivoks, yes, and we need to put that on our proceedures to catch it too11:21
ivoksor not change gcc version during release11:21
apwyep.  or that.11:21
apwi guess unless its a security issue, which is ok11:22
ivoksnot even in -backports :)11:22
apwnnnng11:22
apwonly backporting higher releases is ok11:22
apwas the packages are prefixd11:22
ivoksright11:22
cjwatsondoko: this all looks like a reason to be cautious about gcc version bumps in stable releases in future :-/11:23
cjwatsonapw: so the kernel build literally looks at the upstream gcc version and encodes that in its ABI?11:24
cjwatsonapw: as opposed to the ABI bump being a result of a change in gcc code generation?11:24
apwi don't think its quite that rigid, but there is clear issues with different compilers generating incompatible code across boundaries11:24
apwso they have stated 'you should use the same' and people have coded that in their tools for those modules11:25
apwand it is a bit frightening, its not like they are libraries with clean interfaces, they are really .o's munged together at run time11:25
apwits wholy scarey the thought htat they might be at different compiler versions11:25
cjwatsonapw: so in that case backports are surely risky too?11:27
dokowell, 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
cjwatsonapw: I would have thought that if different versions of gcc were behaving as you say, that would be a serious problem for userspace too11:27
cjwatsonapw: after all userspace static linking is little different, but we don't have these problems11:28
apwapps don't talk to other apps so tightly11:28
apwwe don't static link half a program11:28
cjwatsontrue11:28
apwwe make a whole package or none of it11:28
apwthats where the nasty fear comes in11:28
apwand i suspect its not reasonable, but its there11:28
cjwatsondoko: right, this is because -security and -updates are different; my suggestion here is to copy 4.2.4 into -security11:28
apwi think in paranoid builds we do insert the compiler version into the symbols somehow11:29
cjwatsonapw: 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
apwright, we would be fine11:29
broonieThe kernel is also doing things like packing stuff aggressively and using ABI-relevant GCC features.11:32
apwyeah i don't think i've ever seen quite so many options passed to gcc by anything else11:33
Adri2000slangasek: 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
ubottuLaunchpad bug 328874 in samba "getent group crashes winbindd on domain controller" [Medium,Confirmed] https://launchpad.net/bugs/32887411:38
pittidoko, 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 painful11:51
dokopitti: sure, sounds fine11:52
StevenKpitti: Belocs died? I thought they were more active ...11:52
cjwatsonpitti: 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
pitticjwatson: seems so; right now, glibc upstream is pretty good at updating locales and such..11:55
cjwatsonDenis Barbier got fed up with something in Debian (I forget what) and left, which probably didn't help belocs11:55
pitticjwatson: I'm still fine with keeping the locales themselves separate11:55
pittiit's easier to update them that way11:55
cjwatsonpitti: as long as all the locale-gen stuff keeps on working the same way, I don't really care :)11:55
pittiokay, then I'll look into that11:56
pittimakes more sense than spending two hours on adding workaround patches11:56
StevenKcjwatson: Denis Barbier left? Hm. I missed that.11:57
* pitti -> lunch and appointment, will be back for release team meeting11:57
pittislangasek: 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
dokopitti, cjwatson: please accept python2.6 in NEW12:23
jdstrandKeybuk: 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 starts12:54
jdstrandKeybuk: ifup is called via start-stop-daemon, so the sleep doesn't affect boot time12:55
jdstrandKeybuk: it works great in almost all cases but one-- a system with apparmor enabled where the user disabled its initscript12:55
apwhow long after a PPA package is marked published should i expect it to show up in an apt-get update/upgrade ?12:56
jdstrandKeybuk: I'd ideally like to skip the checks after rcS completes12:56
jdstrandKeybuk: 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
apwjdstrand, runlevel perhaps?12:58
slytherinapw: #launchpad is the right channel to ask that question13:00
apwslytherin, ta13:00
ograjdstrand, does that take NM into account ? :)13:00
jdstrandogra: works great with nm, and resolvconf :)13:01
jdstrandapw: I thought about runlevel, but didn't think it would report 'S'. its manpage says it does, so that should work great13:01
jdstrandogra: it should work fine for anything that drops stuff into the various hooks directories too13:03
=== pochu_ is now known as pochu
ograsounds good13:03
jdstrandogra: 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
jdstrandogra: or if grabbing the source see debian/apparmor-profile13:05
sorenjdstrand: 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
jdstrandsoren: no, not yet. some could possibly be automated-- I'd have to think about it13:18
sorenjdstrand: It could be quite like the dh_installudev helper, I imagine.13:24
jdstrandsoren: the more I think about it, the more I think it is a good idea13:24
* soren takes a break13:24
sorenjdstrand: It's very convenient, especially if the paths should change at some point or they need particular permissions or whatever.13:25
* jdstrand nods13:25
jdstrandsoren: of course, it's still on my todo like to have a dh_ufw :)13:25
EagleScreenhello13:33
=== LucidFox_ is now known as LucidFox
EagleScreenthe 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
pochuis he aware that people use su-to-root in desktop files anyway?13:38
cjwatsonperhaps there should be a special syntax for this in .desktop files that doesn't involve an explicit auxiliary command13:38
cjwatsonand have the desktop figure out how to escalate privileges - that seems more elegant13:39
pochuor perhaps the freedesktop folks could resurrect xdgsu and say in the desktop standard that is the official way to gain su priviledges13:40
pochubut that is much to ask, I guess... :)13:40
cjwatsonor that, yes13:40
EagleScreeni am not sure, but may be polycikit will fix this kind of issues in a near future..13:40
jdstrandapw, Keybuk: fyi, runlevel doesn't have enough info yet to report 'S', but it will exit non-zero, which I can test for13:52
jdstrandapw: thanks for the suggestion13:52
ogracjwatson, 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
sorenogra: ...and server, IIRC.13:54
cjwatsonogra: it's cosmetic, it's just a script called "kdesudo" that happened to get inherited and that does nothing13:54
cjwatsonyou can ignore it13:54
ograok13:55
cjwatsonogra: I'll remove it since it does nothing for Ubuntu13:55
superm1slangasek, 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 yesterday14:01
rtgI need an archive admin to promote wireless-crda to main per this MIR: https://bugs.edge.launchpad.net/ubuntu/+bug/32580114:04
ubottuUbuntu bug 325801 in ubuntu "Main inclusion request: wireless-crda" [Undecided,In progress]14:04
devfil2Keybuk: can I work on uswsusp merge?14:19
slangaseksavvas: 232469 - exactly what cjwatson replied in the bug14:35
slangasekAdri2000: I think in fact that we'll have samba 3.3.0 in before FF14:36
slangasekpitti: shuffling> ack, will do14:36
slangaseksuperm1: rerunning mythbuntu cronjob14:38
superm1slangasek, thanks14:38
apwpitti, how do i find the errors from the backend of apport14:43
apwfrom the thing behing the (!)14:43
apwor how do i run the backend by hand or ...14:44
EagleScreennetworkmanager-gnome sometimes fail to connect to a WPA-Entrepise net14:53
=== bluesmoke is now known as Amaranth
=== thunderstruck is now known as gnomefreak
pittiapw: behind the "!"?15:09
apwthe ! appears on the gnome task bar you hit that, it dies horribly without telling your logging anywhere i can find15:10
pittiah15:10
pittiapw: the ! is from update-notifier15:10
apwhow does one do the same thing either getting a log, or from the command line or anything other than blind fixing15:10
pittiapw: you can run /usr/share/apport/apport-gtk -c /path/to/crashfile15:10
apwbut that has #!no at the top15:10
pitti?15:11
apwhmmm perhaps i fecked that up somehow15:11
* apw reinstalls15:11
pittiapw: so is update-notifier itself dying, or is /usr/share/apport/apport-gtk not starting?15:11
pitti$ head /usr/share/apport/apport-gtk15:11
pitti#!/usr/bin/python15:12
apwwell hard to say of course15:12
apwok then somehow thats me thats typed it, doh15:12
* apw will retest15:12
sorenCould a friendly AA please accept the axis2c binaries?15:18
sorenlibapache2-mod-axis2c, libaxis2c-bin, libaxis2c-dev, libaxis2c-doc, and libaxis2c0.15:19
seb128soren: to universe?15:23
sorenseb128: universe is fine (for now).15:24
seb128soren: done15:27
* soren hugs seb128 15:27
* seb128 hugs soren back15: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. Thanks15:30
evandshtylman_: https://wiki.ubuntu.com/JauntyUbiquityUsability - should give you a pretty good idea of what I'm up to15: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 me15: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? thanks15:35
evandshtylman_: 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
evandshtylman_: Everything that's done should be in the ubiquity bzr repository (lp:~ubuntu-installer/ubiquity/trunk)15:37
cjwatsonDST information> also country for the purposes of locale15: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 timezone15: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 consistent15:39
evandshtylman_: that's fixed in bzr.15:40
shtylman_evand: ok, cool15:41
evanda 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-gtk15:41
shtylman_is that the test procedure?15:43
evanddepends 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 globally15:45
evandI'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 it15:46
evandIf you don't already have a preferred virtualization environment, allow me to suggest KVM15:46
evandgood deal15:46
evandshtylman_: 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 progress15:47
sorenIf 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 do15:47
ScottKsoren: Yes it will.15:51
ScottKIt takes some time to cycle through, so it's not immediate.15:51
sorenScottK: Ah, I thought it was done as part of the ACCEPTing script or whatever type of magic wand is involved.15:52
ScottKNo, depwait packages get revisited on some periodic and then kicked to needs buiding of the dep is satisfied.15:53
sorenScottK: Thanks. I'll just click the rebuild button myself.15:53
sorenPatience has never been a thing of mine.15:53
ScottKYou may not want to do that.15:53
cjwatsonrebuild => score 015:53
ScottKThere's a soyuz bug where manual retries get scored to 015:53
ScottKYep.15:54
cjwatsonI can't decide whether that's actually a bug15:54
cjwatsonit has the useful effect of preventing people DoSing the buildds with repeated retries15:54
ScottKI filed a bug on soyuz earlier in the week and they accept it.15:54
cjwatsonsince any developer can do that, and it's a lot less visible than repeated uploads15:54
ScottKaccept/accepted.15:54
cjwatsontheir problem, then :)15:54
apwpitti, 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/resume15:54
ScottKcjwatson: 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
PecisDarbspitti: can be python be used in init.d script? one-liner for example?15:56
pittiPecisDarbs: in principle yes, but you really shouldn't; it's horribly expensive15:56
pittiPecisDarbs: also, you need to account for systems which have /usr on a separate partition, so you can't use it for rcS.d15:56
PecisDarbsok, then I have to try to do it in bash anyway15:57
pittiPecisDarbs: what do you want to do?15:57
pittiapw: will do after the meeting15:58
PecisDarbspitti: 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
pittiPecisDarbs: hm, that seems like something which could also be done in postinst?15:59
pittiit doesn't matter much if postinst is slow, but init script bites you on every boot15:59
cjwatsonhardware detection should be at run-time, surely15:59
pitti(it's a little less tolerant to hardware changes, though)15:59
ScottKTheMuso: Congratulations on a successful kernel build for hppa.15:59
PecisDarbsI try to extract two numbers for such line - http://pastebin.ca/133612216:00
Riddelldoko: I don't suppose you know anything about building apps with maven?16:00
PecisDarbsnumber after card and number after device16:00
pittiPecisDarbs: use awk or sed, they are much faster than calling python or perl16:01
cjwatsonif that format is reliable then you don't even have to use a subprocess at all16:01
pittiPecisDarbs: first iteration:16:02
pittiecho 'card 0: Intel [HDA Intel], device 6: Si3054 Modem [Si3054 Modem]' | sed -r 's/^card ([[:digit:]]+).*device ([[:digit:]]+).*$/\1 \2/'16:02
PecisDarbswow16: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
cjwatson0 616:03
PecisDarbsshell gurus :)16:03
PecisDarbsthanks16:03
pittiPecisDarbs: one thing, please call aplay -l with LC_ALL=C16:03
PecisDarbsright, localization issues...16:04
pittimine says "Karte" and "Gerät" :)16:04
PecisDarbslol16:04
PecisDarbsusers 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
dokoRiddell: please ask Koon. I think our current advice for packaging apps using maven: don't use maven.16:07
KoonRiddell: you want to build something or package something ?16:08
cjwatsondoko: *laugh*16:16
dokocjwatson: ?16:16
cjwatson"advice for using maven: don't use maven"16:17
lamontKeybuk: fixing the git tree now - I was tired last night when I wrote the email...16:26
waltersdoko: 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 adaptable16:29
Koonwalters: we have our own effort under way16:31
Koonhttp://wiki.debian.org/Java/MavenBuilder16:32
ScottKpitti and slangasek: Can we do out Dx bugs in Universe discussion now?16:32
waltersKoon: yay, a cdbs plugin16:32
slangasekScottK: if you can tolerate some latency due to my attempts to acquire breakfast16:33
pittiScottK: sure; so you have some concern with applying patches?16:33
ScottKOK16:33
Koonwalters: it's a slightly different design, with the same kind of problems in the end16:33
ScottKpitti: 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
waltersKoon: yeah16:34
ScottKTo the extent these things are incorporated in Universe packages, I think it should be upstream.16:34
=== dholbach_ is now known as dholbach
jdstrandmathiaz, 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 needed16:34
ScottKAlternatively if Canonical Dx will commit to maintain the packages, then I think my concern would be resolved.16:34
pittiScottK: they should indeed go upstream, no doubt16:35
Koonwalters: maven is orthogonal to the concept of linux distributions. we can hack around it, but in the end it could still fail.16:35
waltersKoon: yeah16:35
pittiScottK: in fact, the condition for applying those (to main as well) is that they are sent upstream and aren't Ubuntu specific16:35
KoonDeath to Maven!16:35
ScottKpitti: So I don't see a point in having a bunch of "bugs" against packages.16:35
waltersKoon: i have hopes the modularity effort upstream will result in at least filesystem-level standardization of these things16:35
ScottKThese aren't actually defects, but a difference in design.16:35
pittiScottK: it's for having a place to discuss, track, and attach them, as well as xref with upstream bugs16:35
pittiand it's still (arguably) an usability defect16:36
ScottKpitti: It's even more arguable that aspects of the proposed Dx design are a usability defect.16:36
ScottKIf you want to start that conversation ....16:36
pittiScottK: sure :)16:36
* ScottK doesn't16:36
* pitti doesn't either16:36
ScottKI think the most appropriate status is the Ubuntu task wontfix since it that's generally what will happen.16:37
ScottKThat doesn't stop some developer who feels motivated taking it on.16:37
slangasekjdstrand: uploading the SRUs is easy, sorting the patch is the hard (and first) part :-)  I'm happy to see it fixed, whoever does the work16:37
pittiScottK: having the bug with a patch doesn't mean that we have to upload it immediately16:38
ScottKIt does, however, keep the expectation correct about where change will happen.16:38
pittiScottK: if upstream takes teh patch, then we can close it once we got a new upstream version, for example16:38
persiapitti, 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
pittipersia: well, if there are MOTUs uploading patches just because they are there, without reading the bug, then we have a bigger problem16:40
ScottKI think linkage to a upstream bug task with the Ubuntu task wontfix expresses the general approach correctly.16:40
slangasekin that case, it sounds appropriate to un-tag them patch if that tag is currently set?16:40
seb128confirmed and wishlist would make sense16:40
slangasekor is there a concern that people will find the patches anyway?16:40
ScottKseb128: It's not a bug.16:40
ScottKI actually haven't seen any with a patch.16:40
seb128wishlist = change request16:40
persiapitti, 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
seb128persia: well they ought to read the comments in a bug before uploading no?16:41
seb128persia: should be easy to state there if something should not be uploaded16:41
ScottKI didn't see anything so far in the bugs about this ought to be done upstream.16:41
seb128or do we have people who upload without reading bug comments?16:41
pittipersia: I see16:41
persiaseb128, Yes, they ought.  A comment saying "This bug is for upstream tracking" would cover my concern.16:42
ScottKpersia: I agree.16:42
mathiazjdstrand: I don't have the time in the next few days to sort out the regression16:42
pittiand we shouldn't upload them straight away without the bug being filed upstream anyway16:42
persiaseb128, It's not upload, it's testing the patch, preparing a new candidate revision, pushing into the sponsors queue, etc.16:42
mathiazjdstrand: however I do hope to update openldap to 2.4.13 before FF16:42
jdstrandmathiaz: well, it makes sense that I would do it, I'm fairly familiar with it. upstream seems to have settled on a solution16:43
LaneyWho's to say that upstreams will accept the philiosophy behind these notification changes?16:43
ScottKpitti: I would also not want these bugs/patches upstreamed to Debian.16:43
slangasekmathiaz: does 2.4.13 include changes to the gnutls code to bring parity with the openssl implementation?16:43
slangasekmathiaz: I.e., explicitly enabling V1 sigs?16:43
slangaseks/sigs/certs/16:43
ScottKLaney: No one.  That's why we don't want to take on the possible long term maintenance of them in MOTU.16:43
jdstrandmathiaz: honestly, it'll be a struggle for me to get it sorted out in the next few days too16:43
pittiScottK: seems you are very fond of actions in notifications :)16:43
seb128what is this discussion about exactly?16:44
LaneyScottK: Good. So do we go with each upstream's wishes then?16:44
seb128refusing to do ubuntu changes to ubuntu packages to avoid work?16:44
slangasekmathiaz, jdstrand: I don't think "next few days" is necessarily the expectation either, fwiw16:44
rtgslangasek: 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
ScottKseb128: It's about Dx filing bugs against Universe packages for their pet project.16:44
ubottuLaunchpad bug 317270 in linux "[Studio XPS 16] touchpad doesn't return from resume" [Medium,In progress] https://launchpad.net/bugs/31727016:44
ubottuLaunchpad bug 320632 in xfree86-driver-synaptics "tap-to-click and edge-scrolling broken in Jaunty" [Medium,Confirmed] https://launchpad.net/bugs/32063216:44
seb128which are valid requests for ubuntu16:44
jdstrandslangasek, mathiaz: rest assured it hasn't dropped off for me-- I'll get to it16:44
slangasekseb128: er, if it's agreed that the patches should go upstream first, then such a refusal should be a no-op?16:45
seb128if you don't want to work on those feel free to not16:45
ScottKseb128: It's about not pushing maintenance work onto community developers that they are not resourced to handle.16:45
seb128nobody force community people to do anything16:45
cody-somervillepitti, 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
mathiazslangasek: I don't know if .13 has the gnutls fixes - .14 has them though.16:45
cody-somervillepitti, It isn't clear where the notification originates from16:45
seb128cody-somerville: those are bugs and should be channeled to the correct media which is not there16:45
mathiazslangasek: and IIUC upstream is in the process of pushing .14 out of the door16:46
ScottKseb128: We have plenty of pointless diff in Universe already without making it work.16:46
slangasekseb128: 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 this16:46
ScottKwork/worse16:46
mathiazslangasek: I don't know it if that will be done before FF though.16:46
seb128slangasek: whoever is doing the change is responsible for it usually16:46
jdstrandmathiaz: if we are talking about jaunty, don't we already have the new gnutls patches from debian already?16:46
jdstrandI haven't looked too closely, but thought I saw some patches16:47
slangasekseb128: in reality, I don't think that's the case over the long term16:47
slangasekmathiaz: well, we're talking about a major regression (bug), that doesn't need a freeze exception to get it fixed16:48
persiaseb128, That's often not the case in universe, where there is more significant turnover, and much less sense of ownership of packages.16:48
slangasekmathiaz: 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
seb128there 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 issue16:48
seb128that's not like there was hundred of changes16:49
slangasekseb128: who's paid to take responsibility for the packages in universe?16:49
ScottKseb128: There is no team paid to work on these packages.16:49
slangasekthat's the open question here16:49
=== fader is now known as fader|lunch
primes2hpitti: Sorry about build-time stuff on debdiff.16:49
mathiazslangasek: no. I haven't heard anything that specific16:49
slangasekmathiaz: ok; then .14 might be orthogonal...16:49
seb128slangasek: the dx team said they would provide patches, they will probably maintain those too no?16:49
seb128and if they don't that's only a couple of changes to maintain16:49
pittiprimes2h: don't worry, I figured it out :)16:50
seb128we do that for lot of other things16:50
pittiseb128: well, provide -> send to and argue with upstream16:50
seb128people add random .desktop without translations to universe packages for example16:50
primes2hpitti: Next time I'll check it better before posting...16:50
seb128if you really want to discuss MOTU efficiency better to start on real unrequired efforts16:50
ScottKseb128: 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
persiaseb128, Well, yes, but that's because I like to launch apps.16:50
slangasekseb128: 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 exist16:51
ScottKseb128: IMO I am.16:51
seb128persia: and you don't care about non english users16:51
seb128come on, we are speaking about 15 packages or so16:51
ScottKseb128: One can't add a non-existant translation.16:51
seb128if you want 0 delta to universe just say it16:51
seb128but that's not really such of an issue16:51
persiaseb128, 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
ScottKseb128: If Canonical will commit to maintaining the Universe diff for their Dx initiative, then I have no problem with it.16:52
ScottKSo far, Canonical has not agreed to do so.16:52
seb128there is nothing canonical specific there16:52
seb128those changes are for ubuntu consistency16:52
seb128if 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
seb128should I stop people to upload .desktop changes because I think those are wrong16:53
seb128etc16:53
cody-somervilleI don't think ScottK is trying to stop anyone from doing anything.16:54
seb128cody-somerville: it seems that he doesn't want of such changes in universe package because it means extra work16:55
cody-somervilleI 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
seb128who is responsive for any ubuntu change?16:55
ScottK-palmApparently I only get 2 hours of wifi @ McDonalds.16:55
seb128the people contributing to ubuntu ...16:56
cody-somervilleseb128, 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
LaserJockseb128: ultimately though MOTU is responsible16:57
seb128right as for any change16:57
LaserJockso we do need some concern about how things are going to be maintained, and commitments16:57
seb128should we declare a 0 change to universe rule to minimize work?16:57
cody-somervilleNo16:57
seb128lol16:57
LaserJockno, nobody said that16:58
seb128who is commiting for all the changes people are randomly doing now?16:58
LaserJocksometimes nobody16:58
LaserJockand that sucks16:58
seb128I can give you a list of change which add for no real win16:58
cody-somervilleBut 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
seb128so how is that case different?16:58
slangasekseb128: there have been ongoing conversations about this exact issue among MOTU before now16:58
LaserJockbecause, I think, that we are trying *not* to do that16:58
seb128I just think you pick the wrong target for this discussion16:58
seb128those changes are for look and feel consistency16:59
seb128and concern a small number of sources16:59
LaserJockI would feel much better with the Dx team making some commitment to the Universe changes16:59
ScottK-palmseb128: If Canonical wants a global design change implemented in Universe, they should maintain it.17:00
seb128nothing to do with canonical17:00
LaserJockI personally don't care either way on the change, so I'm not against the changes by any means17:00
LaserJocksure it is17:00
seb128the ubuntu team has decided to change the ubuntu desktop look17:00
ScottK-palmFrankly the communication between Dx and the community has been and IME continues to be very poor.17:00
LaserJockit's Canonical's team from what I can see17:00
seb128canonical is not revelant there17:00
seb128how is that revelant?17:01
seb128it could be a community spec17:01
ScottK-palmseb128: Where is the spec that approved this?17:01
LaserJockbecause none of them are Ubuntu developers17:01
seb128discussed at uds17:01
LaserJockwhich means volunteers have to take care of it17:01
LaserJockwhich can lead to more work and bitrot that we'd rather not have17:01
seb128ubuntu members will decide to use those changes or not17:01
ScottK-palmseb128: Discussed, but not in any regular session.17:01
seb128if they do it will go to ubuntu17:01
seb128right, and we will ship GNOME 2.26 too17:02
seb128but there was no session about it17:02
seb128and we didn't get specs about lpi changes either17:02
seb128etc17:02
ScottK-palmYes, Gnome updates happen every time.17:02
seb128don't try to make it looks like this is different of whatever has been made before or not an ubuntu change17:02
seb128that's the same sort of changes as lpi17:03
ScottK-palmI think it is very different.17:03
seb128brb17:03
pittiwell, 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
seb128re17:04
pochuwill those changes be forwarded upstream?17:04
seb128yes17:04
pittipochu: absolutely17:04
pittipochu: I consider this as a precondition for applying them at all17:04
ScottK-palmpitti 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
seb128no17:04
pittiScottK-palm: I object to this generality17:05
seb128why wontfix in ubuntu?17:05
pittiScottK-palm: unconditionally marking all of them as wontfix is pretty pointless and not really justifiable17:05
seb128ubuntu desktop will use the new notification for consistency having those changes would be nice17:05
pochufor 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 forwarded17:05
ScottK-palmBecause it's not the kind of change we should be doing.17:05
seb128no reason to wontfix if somebody wants to work on this17:05
pittimarking one as wontfix is okay if upstream rejects it, and it doesn't impact usability too much (or we don't care)17:05
seb128it's not up to you to decide what other people want to work on17:05
pochuthat would mean there's no need to maintain anything17:05
pochuseb128: pitti: cool17:05
ScottK-palmseb128: wontfix doesn't stop people working on anything.17:06
pittibut if upstream accepts the patch, then I don't see why it should be marked wontfix in ubuntu17:06
seb128it gives the messages than change will not be accepted17:06
seb128which is wrong17:06
LaserJock the point of wontfix on an Ubuntu task is to signify that we want it to go upstream first, then sync17:06
seb128no17:06
pittisince then we'd actively had to patch it out again, which would be nonsense17:06
seb128that's not what wontfix means17:06
pittiLaserJock: no, it isn't; it means that we don't want the change at all17:06
ScottK-palmWhat it does is set an appropriate expectation that this is not something we would likely do.17:06
LaserJockI think that's how it's being used17:06
seb128or we can start wontfix 90% of the bugs on launchpad17:06
seb128but that's something we want to do17:07
pittiLaserJock: we have hundreds of open bugs with an upstream task which just wait for a fix trickling through upstream, after all17:07
seb128you want universe application to not work nicely on the ubuntu desktop?17:07
pochuLaserJock: not really, I use it as saying "we won't implement it"17:07
pochuLaserJock: e.g. upstream disagrees, and we don't want to change behaviour, so we wontfix it17:07
pittipochu: but "we won't do the work" != "we won't change it when upstream does"17:07
ScottK-palmseb128: If we ar17:08
pochupitti: right right17:08
ScottK-palmurgh.17:08
LaserJockpochu: I can see that if there's no Debian task17:08
pochupitti: I see "wontfix" as "wontfix upstream & in ubuntu", otherwise triaged forever sounds good17:08
pochupitti: so I'm fine with leaving the Ubuntu tasks opened17:09
seb128wontfix = we will not accept such changes17:09
pochuright17:09
LaserJockno17:09
LaserJocknot exactly17:09
ScottK-palmseb128: Not at all.17:09
seb128that's how we use it for desktop right now17:09
LaserJockso?17:09
seb128well you can't say no17:09
LaserJockdesktop != MOTU17:09
ScottK-palmIt's not how it's generally ised in MOTU.17:09
LaserJockwe all have different triage/status rules17:10
ScottK-palmused ...17:10
seb128how do you use it?17:10
seb128wontfix = ubuntu will not work on that?17:10
seb128ie any bug sent upstream where you will wait for an upstream fix is wontfix?17:10
LaserJockif there are multiple tasks then won'tfix directs where the work is appropriate17:10
ScottK-palmseb128: For wouldn't accept the change, I'd use invalid.17:10
LaserJockso an open Debian task and a won'tfix Ubuntu task means "do it in Debian"17:10
* ScottK-palm needs to go.17:10
persiaseb128, Rather, a bug which won't be changed in variance to upstream is set that way.17:10
seb128LaserJock: so we should wontfix all the bugs forwarded upstream now?17:11
LaserJockseb128: if we're just waiting for a sync, I think that would be appropriate17:11
seb128ok17:11
LaserJockbut not a big deal as most of the time people get it17:11
persiaseb128, It's not the forwarding, it's forwarding with a statement that the Ubuntu behaviour won't vary from upstream.17:11
seb128cool, can close some ten thousand bugs17:11
ScottK-palmIf you won't fix it in Ubuntu, then say so.17:11
pittithat sounds like an entirely uncovered state, like "Waiting for upstream"17:12
LaserJockbut 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 appropriate17:12
seb128so basically you suggest keeping any bug we don't intend to fix in an ubuntu specific way as wontfix?17:12
persiaNo.17:12
pittiLaserJock: well, I disagree heavily, but it's also an entirely separate discussion17:12
seb128ie close 99% of the bugs since we rely on upstream to fix most of the bugs17:12
LaserJockpitti: no doubt :-)17:12
LaserJockseb128: right, and we don't17:13
persiaThe 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
seb128LaserJock: but you are suggesting that we should?17:13
LaserJockseb128: heavens no17:13
persiaThis is different from the set of bugs that are forwarded upstream, but for which we would accept a patch.17:13
LaserJockyou guys do what you want with your bugs17:13
LaserJockbut let us do what we want with our bugs17:13
seb128persia: why wouldn't we accept a patch to make notification consistent on the desktop?17:13
LaserJockseb128: if upstream rejects it I can see doing that17:14
seb128LaserJock: I'm a MOTU too and can upload to universe, that's as much my bugs than yours17:14
persiaseb128, I'm specifically not arguing that: I'm only trying to define the practice.17:14
LaserJockseb128: right ...17:14
seb128LaserJock: upstream will not accept lpi changes should we not use that in ubuntu either then?17:14
LaserJockseb128: and desktop bugs are as much mine as yours, but I respect your bug practices17:14
seb128seems you are trying to enforce a "ubuntu should have no distro specific changes" rule17:15
LaserJockno17:15
LaserJockI'm saying let the people who are responsible for the changes decide what they feel they should take17:15
pittiLaserJock: sounds again like the case-by-case basis :)17:15
pitti(which I feel good about)17:15
pittimuch less abstract discussion17:16
seb128right, me too17:16
seb128wontfix is just wrong there17:17
seb128it means "we will not accept patches to make this work"17:17
seb128and there is no reason we should refuse patches than make things work correctly on ubuntu if they don't17:17
LaserJockit makes sense to me anyway17:17
LaserJockbut I'm unlikely to be the person uploading it so ... :-)17:18
warren_hi17:18
pochuI don't think we should close those as wontfix17:18
pochuwaiting for upstream comments would be nice though17:18
LaserJockit really doesn't matter17:19
pochuI can imagine in many cases they will integrate the change17:19
LaserJockI assume the Dx people will track how things are going and set appropriate statuses with MOTu17:19
LaserJockthe point of the won'tfix stuff would be to direct people to Debian17:19
LaserJockso we don't get duplicative work or conflicts17:20
pochuhow is Debian related here?17:20
seb128LaserJock: what debian has to do with that?17:20
pochuDebian is not changing notification-daemon :)17:20
seb128LaserJock: the notification daemon will be jaunty specific17:20
LaserJockthis stuff isn't going to Debian at all?17:21
pochuLaserJock: it's not. it can go upstream though17:21
LaserJockumm17:21
pochufor "disable actions in notifications" changes17:22
LaserJockbut don't we usually get upstream through Debian?17:22
pochuno17:22
LaserJockso wouldn't it be appropriate to discuss such a change with them?17:22
cjwatsonwe often send things directly as well, or instead17:22
cjwatsonin cases where it's really just more efficient to talk directly with upstream17:22
LaserJocksure, if there's good relationships there, that makes sense17:22
persiaAnd in the case of things like GNOME, we often have a different integration cycle than Debian.17:23
LaserJocksure17:23
pochuor even when there are not. You just need to report a bug usually17:23
LaserJockbut generally in Universe we work tighter with Debian17:23
LaserJockperhaps it's just the packages that are being changed17:23
pochuwell yes17:23
shankhsdoes creating themes in ubuntu come under ubuntu development?17:23
pochubut I don't like when people think that "forward upstream" means "forward to Debian"17:24
pochuI mean, I prefer that you forward upstream or both upstream&Debian when it makes sense the latter17:24
slangasekpersia, 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
persiaslangasek, It was for a while.  I'll try to track down a current location.17:25
LaserJockit just makes sense to me17:25
seb128to me wontfix = not something that should go to ubuntu17:25
LaserJockright17:26
seb128I let things I don't intend to work on open so anybody else pick those17:26
LaserJockso it should be done upstream17:26
seb128or by a contributor17:26
LaserJockno17:26
LaserJockthat's the point of won'tfix17:26
LaserJockwould be to say, "this is what we'd like to do as a team"17:26
seb128well why should not we let people who want to work on those changes do it?17:26
LaserJockbecause it should go upstream17:27
persiaslangasek, 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
seb128what you want to do is universe applications no work correctly on the ubuntu desktop, that seems weird17:27
seb128LaserJock: the notification deamon is ubuntu specific17:27
seb128for now17:27
seb128it will be suggest as a freedesktop project but nobody else will use it this cycle17:27
slangasekseb128: 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 picture17:28
seb128slangasek: I'm not referring to any people17:28
seb128slangasek: 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 cost17:29
slangasekseb128: if there were a clear committment from the uploaders to maintain the delta, then I don't think there would be any issue here17:29
LaserJockslangasek: exactly, thanks for putting it better than I could have17:29
slangasekseb128: that's not the same thing as saying there's a committment to *shoulder* the maintenance cost17:29
seb128welcome to open source, we don't have any committment17:30
persiaOr 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
seb128we 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 wait17:30
persiaseb128, Indeed, and there are a number of us who have packages like that.17:31
seb128well that's not a reason to refuse changes which are useful17:31
slangasekseb128: 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
seb128again we are speaking about making ubuntu applications work correctly on the ubuntu desktop17:31
seb128so you say you prefer having those not work correctly just because volunteer might not keep updating changes?17:32
LaserJockI'd say yes17:32
seb128ie, you opt for having things not working because it could create work17:32
persiaFor 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
pittithat's a good policy indeed17:32
pittiand nobody questioned that, AFAICS?17:33
pitti(in fact, I do the same for main patches)17:33
persiaThere's been a couple minor quibbles, and some stuff gets through, but there seems to be broad consensus.17:33
slangasekseb128: also, a committment is not the same thing as a contractual guarantee17:33
seb128well, there is a difference between useless changes17:33
seb128and having ubuntu softwares working correctly on ubuntu17:33
seb128I puzzled that you guys suggest just letting things broken because carrying fix has a maintainship cost17:34
persiaseb128, 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
seb128well, if nobody is there to maintain the change and  that's an issue drop those17:34
seb128but why refusing correct fix because they might be extra work later?17:35
slangasekseb128: 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
persiaseb128, 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
LaserJockseb128: why is it hard to expect some commitment from the Dx team to maintain this stuff?17:36
pittislangasek: 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
seb128LaserJock: because you will not get those17:36
pittithe bar should at least be set to filing the patch upstream and discussing it there17:36
seb128slangasek: 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 changes17:37
LaserJockseb128: why not? it's their changes17:37
seb128LaserJock: because they don't have the ressources for that17:37
cjwatsonthe 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 either17:37
LaserJockseb128: they shouldn't make changes they can't maintain/support!17:37
cjwatsonbut we do expect them to justify them upstream and make adjustments as request17:37
cjwatsoned17:37
cjwatsonLaserJock: see my comparison with any other kind of patch submission upstream17:38
pochuI 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 them17:38
cjwatsonwe do not, in general, expect patch submitters to maintain the change once it is accepted17:38
cjwatson(upstream)17:38
pochuotherwise, for packages that have Ubuntu delta, I don't think this is a major problem17:38
seb128pochu: again we are speaking about a few applications, we do it for lpi already for example17:38
cjwatsonI 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
seb128what is the point of doing a distro if you can't make distro changes to have things working nicely and be consitant on your distro17:39
slangasekseb128: 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 changes17:39
pochuseb128: right, but for lpi changes we already have a delta or are ahead of Debian17:39
pochuat least AFAIK17:39
seb128pochu: in fact the lpi changes are higher in number than the notification ones will be17:39
cjwatsonanyway, I suppose I shouldn't dive into a debate when I have to run; bye ...17:40
pochuseb128: 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
seb128pochu: 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, too17:41
pochuseb128: do we?17:41
* seb128 should go too, that's a pointless discussion17:41
pochuseb128: I'm not opposing the patches. but I understand concerns about "fire & forget"17:41
pochuOTOH "fire & forget" is what we do a lot of times in Ubuntu...17:41
slangasekseb128: 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 basis17:42
pittiit seems that people are discussing about the extreme ends of "immediatly apply" vs. "mark as wontfix and reject"17:42
seb128pochu: 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, etc17:42
pittiwhy can't we at least have the patches in our bug tracker, and have maintainers decide for themselves?17:42
seb128slangasek: how canonical is revelant there?17:42
pochupitti: agreed17:42
seb128slangasek: that's only one contributor17:42
seb128the contributor could be whatever loco team writting patches17:42
slangasekseb128: 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 main17:43
* seb128 waits for archive reorganisation17:44
persiapitti, 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
seb128I can list you some packages in main which have nobody looking at them and some actively maintained in universe17:44
seb128I don't think the component argument is revelant there17:44
LaserJockseb128: well, you're a MOTU, you maintain it then17:45
LaserJockhmm, that could sound snotty17:45
LaserJockI didn't mean it that way17:45
jdongsnooty?17:46
LaserJockI meant snotty17:46
LaserJockbut since it's essentially a Desktop team change, perhaps the Desktop Team could commit to maintaining it?17:46
highvoltageheh. Ferris Beuler joke!17:47
=== asac_ is now known as asac
seb128LaserJock: why do you need somebody to commit to maintain it?17:47
seb128we have lpi changes in several packages and nobody commited to maintain anything17:48
LaserJockseb128: well, because it's an Ubuntu specific change17:48
LaserJockand that's bad, IMO17:48
pochuI think it's been already mentioned, but how many packages are we talking about?17:48
seb128same for random desktop files motus keep adding17:48
seb128LaserJock: what is the purpose of a distro if you can't make distro changes to have your distro be consistent17:48
LaserJockjust because it *has* been done doesn't mean that's the way we'd like it17:48
LaserJockyou *can* make distro changes17:48
persiaseb128, 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
seb128no you can't17:48
LaserJockbut you need to be responsibel for them!17:49
seb128wake up that's not how opensource work17:49
LaserJockwhatever17:49
seb128look at upstream project, people come contribute, get busy, and move to other things17:49
LaserJocksure17:49
seb128that's not a reason to reject contributions17:49
seb128just because they might get busy one day17:49
LaserJockyes, it is17:49
persiaNo, it's not.17:49
LaserJockif the team says "we're not sure we can maintain that"17:49
seb128welcome to the "do no change ever"17:49
LaserJockthey have every right to reject the change17:50
slangasekseb128: "might get busy one day" - that's a mischaracterization of the issue17:50
seb128LaserJock: that's not like motu was having universe under control17:50
seb128there is too much work to do for the number of people17:50
persiaThe 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
seb128well, delta to having thing work on our distro is useful17:50
LaserJockseb128: right, so we try to be smart about what work we make for ourselves17:51
seb128ok, forget about that17:51
=== fader|lunch is now known as fader
seb128I'm going to apply those changes and to maintain those, happy?17:51
seb128where maintain means I will probably have time every 3 years to reply to emails about it17:51
LaserJockwell, I would prefer the Dx team did it because you are so busy17:52
seb128that was an ironic comment17:52
LaserJockthat's why I asked if there's any commitment from them17:52
LaserJockthey shouldn't be making changes they can't maintian, IMO17:52
seb128you don't have anybody in motu who declare to be responsive for the changes done17:53
seb128motu should never do any change either17:53
slangasekMOTU collectively are responsible for them17:53
seb128and they will be responsive for those as for any other change17:53
LaserJockI take responsibility for every upload I make17:53
seb128and what if you run away next week or get a new job or for whatever reason stop contributing?17:53
slangasekwhich 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 resistance17:53
seb128that's life17:53
LaserJockthen I will step down right17:54
seb128does it mean you should stop you doing changes?17:54
LaserJockand hand my responsibilties off17:54
persiaseb128, That'd be a violation of the Code of Conduct, unless there was a transition effort.17:54
seb128persia: what do you mean?17:54
slangasekseb128: again, you're mischaracterizing the problem.  There's a difference between not being committed, and being unable to fulfill the committment due to changing circumstances17:54
seb128come 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
LaserJockseb128: that whole "Step down considerately" paragraph17:55
seb128slangasek: we always do things in a best effort way17:55
pochulooks like it's just 12 packages: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=dxteam17:55
persiaseb128, 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
seb128persia: ok, we don't live in the same opensource world17:55
slangasekseb128: yes - but where has anyone agreed to make that effort?17:56
slangasekfor the set of changes in question17:56
seb128slangasek: well, whoever writes the patch make the effort to get the thing done17:56
seb128when I write a patch for GNOME I don't agree to update the changes when they reorganize their code either17:56
slangaseknow, 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 workload17:57
seb128that's not how opensource work17:57
seb128I sponsor ton of changes without asking for commitment for the patch submitters17:57
seb128for -> from17:57
slangasekseb128: 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's17:57
seb128slangasek: ok, that's my point17:57
seb128slangasek: 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
seb128when I fix a bug I usually send a patch17:58
seb128and switch to something else17:58
persiaslangasek, 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
seb128persia: there is no upstream there ...17:59
slangasekseb128: right; I think the disconnect here is that you've been approaching these as "bugfixes", and others have been assuming "enhancements"... :)17:59
seb128persia: that's like waiting for upstream to take launchpad integration changes17:59
pochuwhat will happen if a package isn't patched to not display actions? will the notification keep working, just without the button?18:01
slangasekso 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
seb128slangasek: I was not sure of the discussion, I just disagree about MOTU wontfix useful changes just because they don't want to maintain those18:02
seb128pochu: no, it will have some ugly fallback mode really annoying18:02
persiaI'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
slangasekseb128: maintaining the changes is a collective responsibility, so FWIW I think it's reasonable that deciding to accept the delta is also a collective decision18:03
seb128persia: 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 thing18:04
slangasekwhich is different than saying I think the delta should not be accepted in this case18:04
seb128slangasek: 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 changes18:04
persiaseb128, Ah.  Thanks for the explanation.18:04
LaserJockseb128: I don't think anybody said that18:05
slangasekseb128: there's an awful lot of stuff in universe that looks ugly, for reasons unrelated to the notification spec :_)18:05
seb128persia: 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
persiaseb128, 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
seb128slangasek: and we usually don't refuse patches to fix those things18:05
slangasekseb128: if it meant redesigning upstream's UI, I expect we would18:06
LaserJockif somebody were to port a GTK1 app to GTK2 I'd tell them to go upstream18:06
pochuseb128: 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
seb128LaserJock: did you read what I just said?18:06
seb128pochu: that will open a dialog, the discussion is wether we want the few line patch to not open a dialog18:07
LaserJockseb128: yes, we do sometimes refuse fixes because they aren't very maintainable and should go upstream18:07
seb128which is what people are resistant to18:07
seb128LaserJock: there is no upstream there, grrrr18:07
LaserJockseb128: sure there is18:08
seb128LaserJock: no there is not18:08
seb128LaserJock: this notification daemon is new ubuntu code18:08
LaserJockright18:08
seb128it's different of the upstream one18:08
LaserJockbut the change comes from Dx and the packages we have to change have upstreams18:08
seb128why should upstream change their code to work on an ubuntu specific daemon?18:08
LaserJockwell, frankly that's why you don't *do* stuff like that in a distro18:09
LaserJockbut that's somewhat beside the point18:09
pittiseb128: please note that the fd.o libnotify protocol, as it is, doesn't guarantee availability of actions18:09
pittiseb128: also, the change is being made for an usability argument, not just because of our daemon18:09
pochuLaserJock: 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 functionality18:09
LaserJockpochu: sure18:09
LaserJockagain, I'm *not* against the change18:09
pochuthen?18:10
LaserJockI'm against a dump-and-forget mentality by Dx18:10
pochuchanges are going to be forwarded upstream18:10
seb128LaserJock: there is no such mentality18:10
pochuLaserJock: I see that mentality everyday in jaunty-changes18:10
seb128you are the one assuming there is one18:10
LaserJockseb128: you *told* me there was no commitment18:10
persiapochu, That's not an excuse: that's a target for correction.18:11
pochupersia: then we need specific maintainers for every package18:11
LaserJockDx is making a change that we would not have otherwise18:11
LaserJockso I do expect some commitment from them on at least helping us maintain it18:11
LaserJockwhen we need merges would they be willing to help with that?18:11
seb128LaserJock: commitment is strong, we work on a best effort basis usually18:11
pochuI hope so18:12
LaserJockok, so are they going to put effort into it or no?18:12
LaserJockmy impression was that they weren't18:12
seb128that's a different question than commitment18:12
seb128ask them18:12
pochuif 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 update18:12
seb128I'm wanting to put some effort in it18:12
seb128but I will not commit to do any work18:12
LaserJockpochu: exactly18:12
seb128I've enough to do18:12
ograLaserJock, 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
seb128and I work on best effort basis18:12
persiapochu, 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
LaserJockogra: no, but that's not the case here18:13
ograsure it is18:13
seb128pochu: we agreed to just drop the patch in such case if they don't update it18:13
LaserJocknot it isn't18:13
LaserJockthe distros would have a choice whethe to accept the notification system18:13
ograand ubuntu chose to18:13
LaserJockand they are unlikely to do so until the apps support it decently well18:13
pochuwe do integration work all the time18:14
pittiapw: the change needs some work, _("text") + self.report['FlagFile'] doesn't really work i18n wise18:14
LaserJockin this case the distro *is* the upstream and we have no choice18:14
pochuI really can't figure out what's wrong with patching 12 packages to work with the new system18:14
persiaseb128, 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
pittiapw: and we need to apply the same change to the qt version18:14
ograLaserJock, canonical != ubuntu18:14
LaserJockso they tell me18:14
apwpitti, thought you'd say that, whats the right way to fix that?18:14
apwthere is a qt version?18:15
pittiapw: I need to run now, but unless you beat me to it I can try and look into it on Monday18:15
ograthis system wasnt developed by the ubuntu distro team it has its own upstream ...18:15
ogratotally distinct18:15
apwpitti, will see how i get on, and sync with you on mon18:15
pittiapw: I'd check the value of self.report['FlagFile'] and based on that, use two different strings18:15
LaserJockok, then can Ubuntu refuse it then?18:15
apwok18:15
jcastroLaserJock: 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
pittiapw: also, the label in the glade file that you changed is still marked as translatable, but now just contains markup18:16
LaserJockI mean, I'm really not against the change. I think all 12 apps will end up patched18:17
pittiapw: that's fine, just remove the translatable="yes"18:17
LaserJockbut I don't like Canonical deciding something and then expecting MOTU to "just deal with it"18:17
LaserJockI'm hoping that's not what's going on18:17
jcastroLaserJock: well, if the bugs are linked we can at least keep track, banshee upstream for example accepted the patch18:17
LaserJockand mostly I'm happy with it18:17
seb128LaserJock: again there is no canonical there but ubuntu as a project and distro18:18
LaserJockwhatever18:18
jcastroit's an easy fix, filed in lp, filed upstream, and then we tag it and link it.18:18
seb128LaserJock: who contributes should not be an issue and ubuntu is still free to accept changes or not18:18
LaserJockthis is Canonical's team, I don't see how you get around that18:18
LaserJockbut you could do s/Canonical/Ubuntu team that's not MOTU/ if you like18:19
pochupitti: do you have a link to that fdo spec?18:19
LaserJockthe point is about how orthogonal teams in Ubuntu should work on things18:20
LaserJockand I generally feel like "deal with it" is not a great attitude18:20
seb128LaserJock: that's not really team revelant, motus dump work on other motus all the time18:20
LaserJockhopefully that's not what's going on, but saying that Dx has no commitment to the changes they make in Universe doesn't sound encouraging18:20
seb128some upload libraries soname changes which need transitions, etc18:20
LaserJockseb128: that's vastly different though18:21
seb128I've for sure no commitment to rebuild the whole archive because I do a soname change18:21
seb128I do try to do rebuilds though18:21
pochupitti: 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 not18:21
LaserJockthat's team work, so team members are accountable to other team members18:21
james_wpochu: it's a galago spec, not fdo at this point18:22
james_wpochu: it is *the* notification spec though still18:22
LaserJockanyway, I don't think there's much disagreement here18:22
directhexgalago?18:22
LaserJock12 packages isn't much work18:22
directhexo_o18:22
pochujames_w: ah, thanks18:22
james_whttp://www.galago-project.org/specs/notification/0.9/index.html18:22
pochujames_w: http://www.galago-project.org/specs/notification/, right?18:22
pochu:)18:22
james_wyou got it18:22
directhexi have a maintainer who wants to RM the galago bindings for mono, due to lack of users18:23
pochuah cool18:23
pochunotification-daemon's upstream wrote it18:23
james_wdirecthex: does banshee use them?18:23
LaserJockif MOTU end up having problem maintaining the diff and nock on Dx's door I hope they'd be willing to help18:23
pochuso18:24
directhexjames_w, no. nothing does. except beagle, optionally18:24
pochuthese are all upstream bugs18:24
pochuwe can't forward them upstream and fix them in Ubuntu at the same time18:24
james_wpochu: the ones currently reported are, yes18:24
directhexjames_w, iirc banshee uses its own notification thing, due to lack of features in the conventional gtk methods18: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_wpochu: though currently minor as there is only one implementation of the daemon so far18:25
pochujames_w: but bugs nevertheless :)18:25
persiapochu, 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
Adri2000slangasek: any change coming in debian we should wait for? or can we merge now? (do you want to do the merge?)18:25
pochupersia: so we can fix all these bugs in Ubuntu18:25
seb128LaserJock: it was agreed that if patches are not trivial to update and they are not responsive we would drop those18:25
seb128LaserJock: meanwhile they is no real reason to refuse written patches18:26
* pochu files a bug to one of his upstreams18:26
seb128LaserJock: that makes applications look better meanwhile and you can drop that later if required18:26
slangasekAdri2000: 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
persiapochu, 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_wpochu: if it is a C project then see the goobox bug for a patch that queries the capabilities18:26
Adri2000slangasek: okay18:26
pochujames_w: do you have an example for Python apps?18:27
james_wpochu: not yet18:27
pochujames_w: ok, let me know if/when you know of one. Will be helpful to my upstream :)18:28
directhexjames_w, and if banshee loses its actions in its notifications, i'll cry.18:28
devfil2pochu: emesene?18:30
james_wpochu: 'actions' in pynotify.get_server_caps()18:30
james_wpochu: after pynotify.init(...18:30
pochudevfil2: decibel-audio-player18:31
devfil2pochu: ok18:32
pochujames_w: thanks, I just found it too ;)18:32
pochuok, forwarded upstream18:35
pochuthe other one would be Liferea18:35
* pochu check the C patch18:35
savvasare .save files in /etc/apt/sources.list.d/ ignored?18:39
slangasekI wouldn't expect so18:39
savvashm.. I think Software Sources adds .save files in there, let me check again18:40
savvasyep18:40
cody-somervilleI think only files ending in .list got parsed18:43
cody-somerville*get18:43
savvashttp://paste.ubuntu.com/117765/18:44
savvasah .list files18:45
savvasthanks cody-somerville ! :)18:45
lamontKeybuk: I'm planning to push 2.14.2 to jaunty - does that make sense for the basis of your stuff?18:45
Keybuksure, that'd be good18:45
KeybukKarel hasn't made public his topic/blkid to master push18:45
devfil2Keybuk: can I work on uswsusp merge? It's a new upstream release18:47
Keybukdevfil2: you can do whatever you like ;)18:47
Keybukyou don't need my permission18:47
Keybukobviously things may change once I'm Emperor of the World18:48
devfil2Keybuk: I think it's good to ask the last uploader if you want to work on a merge/sync18:49
lamontKeybuk: I thought that happened with either the udev or upstart upload18:49
Keybukdevfil2: I uploaded it last?18:49
Keybuklamont: needs a util-linux-ng 2.15 upload first ;)18:50
devfil2Keybuk: yes, DaD reports that you are the last uploader18:50
devfil2you did a rebuild as I can see18:50
slytherincan any archive admin please process sync bug 326172? I am waiting for it to process fop merge.18:52
ubottuLaunchpad bug 326172 in xmlgraphics-commons "Please sync xmlgraphics-commons 1.3.1 (universe) from debian experimental" [Wishlist,Confirmed] https://launchpad.net/bugs/32617218: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
ScottKjames_w: I read your changes to the Debain Import spec and I think they are a definite improvement.  Thanks.19:08
cody-somervilleScottK, McDonald's kicked you out?19:08
ScottKcody-somerville: Only two hours of free wifi on one arch card per day.19:08
ScottKI had some other stuff to go do anyway.19:08
LaserJockkees: regarding smarty MIR, you really need the full templated wiki page for something that's already in Main?19:12
ebroderHmm...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
keesLaserJock: 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
jdongebroder: it is in the SOURCE NEW queue awaiting archive admin approval19:19
jdongebroder: all manually uploaded backports require intervention of the archive admins19:19
LaserJockkees: I guess so. I thought I was pretty thorough in the bug report but I can add the usual upstream/debian stuff19:19
LaserJockkees: I'm not a PHP person so I don't think I can really audit any of the code myself19:20
ebroderjdong: 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
keesLaserJock: yeah, no audit needed.  just getting the record of CVEs, bugs, activity level, etc.19:20
LaserJockkees: k, will do right now19:21
jdongebroder: is the queue, or is this process?19:21
ebroderThe queue19:21
keesLaserJock: great, thank you!19:21
jdongebroder: I think it is supposed to show up at https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=0&queue_text=19:23
jdonghttps://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1&queue_text=19:24
jdongthat one19:24
ebroderCool. Thanks19:24
Keybukgnargh! who took away Alt+F219:25
* Keybuk shakes his fast19:25
anderskRun ccsm and activate the Gnome Compatibility plugin.19:26
Keybukccsm is not installed19:29
anderskcompizconfig-settings-manager package.19:29
ivokshoce netko firefox-3.1.xpi?19:37
ivoksups...19:37
ScottKjdong and ebroder: Accepted.19:37
jdongneato :)19:38
ScottKjdong: Next time please Fix Committed and subscribe ubuntu-archive.19:42
jdongindeed, my bad.19:42
LaserJockkees: question on CVEs. There are 14 in the cve search, but most seem to just sort of indirectly mention smarty19:44
LaserJockkees: do you just want the ones where they say the vulnerability is directly in smarty?19:44
keesLaserJock: whatever is easiest19:48
keesLaserJock: just having a pointer to it is a good start19:48
LaserJockkees: well, am I supposed to be actually discussing these or is it merely informative for you?19:49
keesLaserJock: in a perfect world, the MIR would describe how all CVEs against smart are closed.19:50
keese.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
calcgrr 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 well19:54
calcmax distance is 3000ft and i am apparently at 4000ft for that service19:54
calcso i will be stuck with either slow service or have to switch to comcast :\19:54
ScottKNo Verizon where you are?19:54
calcScottK: no verizon anywhere nearby19:54
calcScottK: i think the closest place verizon has fios is about 250mi from here19:55
calcat&t is the ilec here unfortunately19:55
* ScottK is a big fan of FIOS.19:55
calcif i moved to another house i could get 18/1.5 from at&t, but where i currently am19:55
calcand comcast doesn't even have their fast speeds yet in houston aiui19:56
ScottKBefore I moved and had DSL, I found third party DSL providers could do faster than the telco.19:56
calcbut it would be a little faster than what i have now (3.0/0.5)19:56
calcScottK: this issue is a line length problem, i am 16K ft from the dsl location and 4K ft from the higher end equipment19:57
ScottKIf megapath dsl serves your area I highly recommend them.19:57
jsmidtIf 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
calcthe only way i could get higher speed is if they rerun my line from the telco building, which is very unlikely :(19:57
slytherinjsmidt: foo-0+gitxxxxxx19:57
jsmidtslytherin, thanks19:58
calcScottK: 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 away19:58
ScottKGood luck.19:58
ScottKIf 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
ScottKBeing able to remove libdb4.5 is blocked on this currenlty.20:03
LaserJockkees: hmm, yeah. moodle's smarty is older than our dapper version20:04
LaserJockkees: I think we'll be getting rid of some vulnerabilities ;-)20:04
keesLaserJock: yeah, no doubt at all.  :)20:08
MithrandirScottK: given-back on hppa20:08
ScottKMithrandir: Thanks.20:08
MithrandirScottK: you're aware it FTBFS on armel too?20:09
ScottKMithrandir: 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
LaserJockkees: secunia searches suck :/20:17
MithrandirScottK: ah, ok.20:21
ScottKNow that you mention it, I looked and I suspect a retry would work now.  I'll press that button.20:22
ScottKThere'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
keesLaserJock: yeah :(20:30
LaserJockkees: I tried smarty and Smarty and got nothing but I then found a link to one that had "Smarty" in the title20:34
LaserJockgo figure20:34
sbeattieScottK: bug 318866 verified.20:38
ubottuLaunchpad bug 318866 in kdeutils "printer-applet does not display when new printers get configured" [Undecided,Fix committed] https://launchpad.net/bugs/31886620:38
Riddellyay!20:39
LaserJockkees: all yours :-)20:46
keesLaserJock: cool, thx20:47
ScottKsbeattie: Great.  Thanks.20:59
ScottKpitti: 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
calcgrr at&t can't do anything to fix it unless they get a lot of complaints :\21:09
LaserJockcalc: a shell script?21:13
LaserJock:-)21:13
bryceinteresting; LP seems to be cutting off at displaying 80 comments21:20
TheMuso?c21:20
brycewish it was the 80 newest comments instead of the 80 oldest21:20
TheMusoScottK: thanks21:20
TheMusoAt 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
sistpotyRiddell: around...? would you agree to act as delegate for motu-release for universe kde package for jaunty again?22:00
Riddellsistpoty: sure22:01
sistpotyRiddell: thanks a lot!22:01
Luresistpoty: you have ScottK there too...22:01
=== wgrant_ is now known as wgrant
sistpotyLure: but I plan to abuse him for server again :P22:01
Luresistpoty: good plan ;-)22:02
sistpotysuperm1: how about you acting as delegate for mythbuntu for motu-release for jaunty?22:02
sistpoty(again)22:03
sistpotycody-somerville: same question for you in regards to xubuntu?22:03
sistpotyasac: 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 out22:07
sistpotyogra: up for ubuntu-mobile motu-release delegate again?22:08
sistpotyScottK: would you want to go for -server again?22:10
ScottKSure.22:10
sistpotyexcellent, thanks!22:10
sebnersistpoty the organisation horse/talent :D22:12
sistpotysebner: haha22:12
calcgah no timeline available for when they will be offering the test service22:17
calcthey only offer uverse with 27mbps sync speed currently, so you have to be really close to the office :-\22:17
calcdoesn'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 internet22:18
ebroderShould I subscribe...ubuntu-archive to bug #216761 to get it out of the unaccepted queue?22:28
ubottuLaunchpad bug 216761 in xen-3.3 "errors in xendomains init script" [Undecided,Confirmed] https://launchpad.net/bugs/21676122:28
ebroder(Err...unapproved, but whatever)22:28
maxbThere'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
ebroderOne might hope as much, but it has been there for a non-trivial amount of time22:31
* ScottK looks22:54
ScottKebroder: The SRU team is subscribed.  That's the appropriate team for htat.22:56
ebroderScottK: Ok, thanks22:57
brycekees: I have my fglrx system up and good to go, how can I help you on 323327 now?23:08
Kakinho:P23:09
Duff»mneptok«: plizzz private?23:10
directhexdon't you *hate* that?23:10
savvaseh?23:11
mneptokthat's a big red "NO GO," Houston.23:11
savvasoh, I thought directhex was referring to valentine's day :P23:12
kolbyhow important is the python programming language?23:15
ScottK4223:15
sistpotyheh23:15
slytherinkolby: important to whom?23:15
kolbyreally, though.  Would anyone agree that the C programming language is more valuable to the Open Source world than Python?23:16
ebroderMu23:16
kolbyperhaps people would be more interested in learning python before C.23:16
kolbyif people can quickly learn and use something when they become interested in it, that would be a valuable tool..23:17
ScottKkolby: This is all rather unrelated to Ubuntu developement.23:18
* ScottK suggest #ubuntu-offtopic.23:18
kolbyI'll continue this discussion there.23:18
ScottKThanks.23:19
keesbryce: yup, -> privmsg23:19
ion_\o/23:31
ScottKUrgh.  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 shotgun23:41
* ScottK hands it back since it's probably patent infested.23:42
directhexScottK, the point & click interface it provides may be covered by some xerox patents...23:43
ScottKWith a shotgun if it's point and click, that's a bug.23:43
directhexi never said i gave you any ammo...23:44
ScottKYou assume I don't already have some.23:45
TheMusoScottK: Or could it just be that that sparc box is slow?23:51
ScottKTheMuso: No, it's been several hours into the build and then been fewer hours into the build.23:51
TheMusoright23:51
ScottKI caught it needs building at one point.23:51
sistpotyTheMuso: feel free to (ab)use spooky for sparc test-builds, if you're in need for a sparc box23:51
TheMusosistpoty: Whats it specs? I'd rather not throw kernels at it if its not that beefy.23:52
* sistpoty checks23:52
sistpotyTheMuso: http://paste.ubuntu.com/117886/ (/me must admit that he's not familiar with what that actually means)23:53
TheMusoHrm me neither. :)23:54
sistpotyTheMuso: but it feels fast compared to sparky *g*23:54
TheMusosistpoty: 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
TheMusosistpoty: Ok thats good to know.23:55
sistpotyTheMuso: just ping around in #ubuntu-wire for an account then ;)23:55
TheMusoGreat.23:55
* TheMuso searches for give backs for ports on http://people.ubuntu.com/~ubuntu-archive/testing-ports/jaunty_probs.html.23:55
sistpotyTheMuso: erm. #ubuntuwire even23:56
TheMusoheh23:56
TheMusoScottK: the qt build on sparc is moving. I just refreshed its status page and the compilation has moved along.23:57
ScottKTheMuso: Yep.  It'll do that and then later it starts over.23:58
ScottKTheMuso: You can leave the KDE related ones to me.  They have an order they need to be done it.23:58
TheMusoScottK: Ok will do.23:58
TheMusoScottK: I knew you were doing them anyway, but I'm taking care of other stuff.23:59
Riddellyay for ScottK, saviour of KDE on ports23:59
ScottKOK.  Just don't want to waste time on slow archs ...23:59
* TheMuso nods.23:59
ScottKRiddell: 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!