| kees | Riddell: still pending | 00:00 |
|---|---|---|
| kees | Riddell: I'm working on kernel and openjdk updates at the moment | 00:00 |
| calc | ScottK: no i mean the fact that it launches a browser but does not return | 00:00 |
| calc | ScottK: and since firefox when launched does not return it keeps launchpad-integration running iff firefox isn't running already | 00:01 |
| ScottK | I see. | 00:01 |
| calc | ScottK: i'm talking about the launchpad-integration binary not library interface | 00:01 |
| ScottK | Yes. | 00:01 |
| ScottK | Our KDE packages use it too. | 00:03 |
| Necrosan | lessee if it works. | 00:04 |
| * calc kicks ATT | 00:04 | |
| calc | too much packet loss for me to reach lp | 00:05 |
| * calc sees if he can leech off someone else's wifi for a few min | 00:06 | |
| Necrosan | great,now X is crashing. | 00:09 |
| bryce | Necrosan: progress ;-) | 00:13 |
| StevenK | bryce: Are you around? | 00:15 |
| bryce | StevenK: yes | 00:15 |
| StevenK | bryce: So, do you know libx11-dev is broken? :-) | 00:16 |
| bryce | nope; bug #? | 00:16 |
| StevenK | bryce: libx11-dev Depends on libxcb-xlib0-dev, libx11-6 Depends on libxcb1, libxcb-xlib0-dev pulls in libxcb-xlib0 and libxcb1 and libxcb-xlib0 Conflict | 00:16 |
| bryce | StevenK: hmm let me look | 00:18 |
| slangasek | dtchen: sure - I would've had the bug fixed by now, too, if it weren't for the fact that ia32-libs is such a seeping horror that requires every single lib it builds against to be in sync before you can upload... | 00:19 |
| Turl | can anyone help me? I installed realvnc but it doesn't include Xvnc, needed to run it | 00:20 |
| Turl | sorry, wrong channel :p | 00:20 |
| Turl | this should go in #gentoo | 00:20 |
| bryce | hmm, according to the libx11 control file, libx11-dev depends on libxcb1-dev. Where does libxcb-xlib0-dev come from? | 00:20 |
| StevenK | bryce: apt-cache show in my jaunty chroot says libxcb-xlib0-dev | 00:21 |
| slangasek | StevenK: mm, not sure that I'll have a chance to get to that today, we'll see | 00:21 |
| StevenK | bryce: Double checking | 00:22 |
| bryce | StevenK: ok this may be beyond my packaging-fu but it looks like the *old* libx11-dev depended on libxcb-xlib0-dev (up to libx11-1.1.5), but the new one does not have that dependency any longer | 00:22 |
| bryce | presumably something should be added to clue apt in of the change? | 00:23 |
| StevenK | bryce: Mmmm. I just updated against archive.u.c, so looks like libx11-6 and libx11-dev are out of sync on my mirror | 00:23 |
| * StevenK kicks his mirror and tells it to update | 00:24 | |
| bryce | aha | 00:24 |
| slangasek | right, libx11 was just uploaded today | 00:24 |
| slangasek | it was dep-wait on libxcb which was dep-wait on xcb-proto; I fixed that so I could upload ia32-libs :P | 00:25 |
| bryce | slangasek: ahaaa | 00:25 |
| StevenK | Ahhh | 00:25 |
| directhex | ahhhhhhhhh | 00:26 |
| directhex | sorry, i felt left out | 00:26 |
| slangasek | ahhhh the atmosphere | 00:27 |
| slangasek | hah, there we go, after I kill the reference to libxcb-xlib0 in ia32-libs, it finally builds :P | 00:27 |
| Necrosan | tjaalton: sunffb still crashes even with that patch applied. | 00:30 |
| Necrosan | Oh boy. | 00:36 |
| mib_zo2qpbqm | Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai | 00:38 |
| mib_zo2qpbqm | Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai | 00:38 |
| mib_zo2qpbqm | Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai | 00:38 |
| mib_zo2qpbqm | Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai | 00:38 |
| mib_zo2qpbqm | Hi, I was curious as to everybody's opinion on a very important and controversial issue. That particular issue is, what is the best way to store and ferment/cure your own urine. I have been storing my urine in water bottles, one gallon jugs, and cups mostly. I have many bottles stored inside my room and outside as well as outside. My dad at first, did not accept of the idea of me storing my urine in large contai | 00:38 |
| slangasek | !ops mib_zo2qpbqm | 00:38 |
| ubottu | Error: I am only a bot, please don't think I'm intelligent :) | 00:38 |
| Hobbsee | sigh. | 00:38 |
| directhex | yay for Hobbsee | 00:38 |
| ajmitch | ah, mibbit | 00:38 |
| Necrosan | http://pastebin.com/m638bda5d | 00:38 |
| slangasek | hrm, is that not the right command? | 00:38 |
| Necrosan | Any ideas on that crash? | 00:38 |
| * directhex offers Hobbsee some cake | 00:39 | |
| Hobbsee | slangasek: you want !ops, or !ops | foo | 00:39 |
| slangasek | ah | 00:39 |
| Hobbsee | directhex: thanks! | 00:39 |
| slangasek | thx | 00:39 |
| Hobbsee | slangasek: if it's obvious, just go for !ops | 00:39 |
| cody-somerville | How long does it take a build to publish? | 00:56 |
| cody-somerville | (primary archive) | 00:56 |
| cody-somerville | It finished building 38 minutes ago | 00:56 |
| Keybuk | just past the top of the next hour | 00:56 |
| Keybuk | plus ~1 hour for publishing | 00:56 |
| Keybuk | if it finished 38 minutes ago, it will be in the next publishing run, so another hour and a bit to go at least | 00:57 |
| cody-somerville | ... | 00:58 |
| * Keybuk takes away cody-somerville's sugar | 01:02 | |
| * slangasek injects the sugar into his own eyeballs | 01:07 | |
| Keybuk | slangasek: oh? | 01:07 |
| slangasek | wanna try? | 01:07 |
| Keybuk | no, I don't think it would do them any good :p | 01:08 |
| slangasek | oh, ok | 01:15 |
| slangasek | dtchen: there we go, ia32-libs all fixored | 01:16 |
| mathiaz | slangasek: about bug 321689 - it seems that some packages from -proposed have been included in 8.04.2 -server isos. | 02:35 |
| ubottu | Launchpad bug 321689 in openldap "openldap (slapd) installation fails" [Undecided,Confirmed] https://launchpad.net/bugs/321689 | 02:35 |
| stdin | and the alternate ISOs | 02:44 |
| ebroder | Can someone accept the Hardy backport of remctl 2.13-2? | 02:49 |
| ebroder | (Intrepid would be cool as well, but I'm not using Intrepid right now, so I care less :-P) | 02:50 |
| Hobbsee | ebroder: accepted. | 03:00 |
| ebroder | Thanks | 03:01 |
| === ScottK3 is now known as ScottK-desktop | ||
| * NCommander debates if he wants to just buy a time capsule or similar NAS, or roll my own ... | 03:19 | |
| TheMuso | 6/c | 03:29 |
| TheMuso | NCommander: roll your own. :p | 03:29 |
| NCommander | TheMuso, any recommands on how to do it? | 03:29 |
| TheMuso | NCommander: nope :p | 03:29 |
| * NCommander falls over | 03:30 | |
| ebroder | Time Capsules don't suck, for the record | 03:33 |
| TheMuso | ebroder: They probably would if one couldn't access them with Linux. | 03:38 |
| ebroder | TheMuso: That's fair. I still don't use Linux for desktop systems, though :) | 03:38 |
| * TheMuso pats his file server. More extendable than any time capsuel, and can currently store 2.5 times more data than the biggest time capsuel without any additional HDs connected. | 03:39 | |
| * TheMuso is assuming that the biggest time capsuel is 1TB. | 03:40 | |
| ebroder | That's right | 03:40 |
| TheMuso | Oh and no redundancy. I'm using Linux s/w raid here as well. | 03:40 |
| ebroder | Yeah, yeah - I could spend a few hours making something more awesome, but I decided it was worth the convenience to never have to think about it again | 03:41 |
| * TheMuso nods. | 03:43 | |
| YokoZar | Is there a discrete file that refers to the current user's home folder? I'd like to symlink to it without using environment variables. | 05:07 |
| StevenK | ~ will probably get expanded by the shell | 05:08 |
| StevenK | YokoZar: But symlinks don't get resolved, it's a static link | 05:09 |
| === Pricey is now known as Guest75242 | ||
| YokoZar | StevenK: Hmm, how do I make a link to "~" then without just making a link to whatever user is typing ln -s ~ | 05:10 |
| persia | YokoZar, From where are you symlinking? | 05:12 |
| === lucas is now known as Guest20605 | ||
| === Hobbsee_ is now known as Hobbsee | ||
| calc | did freenode just explode? | 05:21 |
| * calc had thought it was just his crappy dsl until he saw how many joins there are | 05:21 | |
| Hobbsee | calc: clarke did, at least, yes. | 05:21 |
| stdin | several times it seems | 05:21 |
| calc | at&t is coming out tomorrow to fix my line, heh | 05:22 |
| Hobbsee | hrm, now connecting from amsterdam. OK then. | 05:22 |
| dholbach | good morning | 05:25 |
| === mneptok_ is now known as mneptok | ||
| === bluesmoke is now known as Amaranth | ||
| slangasek | mathiaz: hrm, investigating | 05:49 |
| slangasek | mathiaz: sigh, not good :( | 05:52 |
| === Hobbsee` is now known as Hobbsee | ||
| tjaalton | Necrosan: file a bug with the log attached | 06:44 |
| ebroder | I just found a regression in a package I got backported. What's the right process here? | 06:48 |
| ebroder | remctl-server 2.13-2 in depends on netbase >= 4.31, but Hardy only has 4.30ubuntu1 | 06:49 |
| ebroder | The change is significant - 4.31 added a new line to /etc/services | 06:49 |
| Hobbsee | jdong: oh, crackporter.... | 06:49 |
| ScottK | ebroder: Didn't you say you'd tested this before it was approved? | 06:50 |
| * ebroder sighs | 06:50 | |
| ebroder | I tested the client | 06:50 |
| ebroder | ...and also the new python-remctl package, because I knew how to use that one | 06:51 |
| * ScottK headdesk. | 06:51 | |
| ebroder | Yeah...I know | 06:51 |
| dholbach | bug 308800 | 06:51 |
| ubottu | Launchpad bug 308800 in intrepid-backports "Please backport remctl 2.13-2 from Jaunty to Hardy and Intrepid" [Wishlist,Fix released] https://launchpad.net/bugs/308800 | 06:51 |
| * ScottK sighs. | 06:52 | |
| Zetto | Someone can include Bug #251173 in the milestone of jaunty-alpha-5 ? | 06:52 |
| ubottu | Launchpad bug 251173 in netbeans-ide "Update NetBeans to 6.5" [Undecided,Confirmed] https://launchpad.net/bugs/251173 | 06:52 |
| ScottK | ebroder: The process is file a new bug against hardy backport explaining the problem (please subscribe me to it). | 06:52 |
| Hobbsee | Zetto: no. and it didn't need to go across 3 channels either, btw. | 06:52 |
| ebroder | ScottK: Ok. I'll do so, and include the fix. I'm really sorry | 06:52 |
| Zetto | Hobbsee, ok | 06:52 |
| ScottK | ebroder: Then see if you can figure the best solution. | 06:52 |
| ScottK | ebroder: OK. That's good. | 06:53 |
| ScottK | ebroder: I don't feel so bad about mistakes as long as you clean up after yourself. | 06:53 |
| ScottK | In the meantime, it's nearly 2AM here, so I'm going to bed. | 06:53 |
| * ScottK will consider what to do in the morning. | 06:53 | |
| ebroder | I'm pretty sure I can do the fix in 2 lines | 06:54 |
| ScottK | Great. | 06:54 |
| YokoZar | An Intrepid Ibex: http://img.waffleimages.com/b44642ef0d1f06ead5848f4a7a844773a369702c/00035152.jpg | 07:35 |
| Amaranth | YokoZar: hahahaha | 07:42 |
| Amaranth | funniest thing I've seen all day :) | 07:42 |
| iulian | Heh | 07:46 |
| pitti | Good morning | 07:53 |
| StevenK | Morning pitti! | 07:53 |
| Hobbsee | hey there pitti! | 07:53 |
| RAOF | Howdie all! | 07:54 |
| * pitti waves to Australia | 07:55 | |
| pitti | sorry, -EHEMISPHERE | 07:55 |
| * pitti ɐıןɐɹʇsnɐ oʇ sǝʌɐʍ | 07:55 | |
| * RAOF wonders idly how that works. | 07:57 | |
| persia | The magic of unicode. | 07:57 |
| * Hobbsee gets boxes, and is sad. | 07:57 | |
| RAOF | Why does unicode appear to have RTL, upside down, latin? | 07:57 |
| slangasek | it appears to have it because it does in fact have it | 07:58 |
| StevenK | Hm, works for me | 07:58 |
| persia | Actually, some letters are supported poorly: it's just people looking through the available glyphs, and picking some that looked right. Lots of them are math symbols, etc. | 07:58 |
| RAOF | I mean: Why does unicode have RTL, upside down, latin? | 07:58 |
| RAOF | Also, who'd like to make f-spot installable again in half an hour or so? | 07:58 |
| StevenK | pitti: Could I monopolise some of your time to NEW two things today? | 08:01 |
| StevenK | pitti: I uploaded both of them, so I can't do it. ubuntu-netbook-remix-default-settings, which is tiny, and desktop-switcher | 08:03 |
| pitti | StevenK: ah, uploaded those yourself? sure | 08:03 |
| pitti | StevenK: u-n-r-d -> main or universe? | 08:05 |
| pitti | StevenK: u-n-r-d does not have a COPYING | 08:07 |
| pitti | StevenK: please fix the short description of desktop-switcher | 08:09 |
| soren | How long does it take for stuff to go through source NEW these days? I see there's a bit of a queue. | 08:11 |
| slangasek | RAOF: "latin small letter turned r/t/a/e" are all used in phonetics | 08:11 |
| pitti | StevenK: desktop-switcher needs to build a .pot during package build (intltool-update -p --verbose) | 08:12 |
| soren | Ah, it seems the oldest stuff in there is from the 23rd, so not too long, I guess :) | 08:12 |
| RAOF | slangasek: Oh, of course. | 08:13 |
| pitti | StevenK: d-s accepted, u-n-r-d rejected due to missing COPYING | 08:13 |
| dholbach | HAHAHAHAHA :-) | 08:32 |
| dholbach | https://launchpad.net/~sorens-target-audience | 08:32 |
| dholbach | https://launchpad.net/~we-love-pitti | 08:32 |
| dholbach | https://launchpad.net/~dholbach-huggers | 08:32 |
| dholbach | looks like we have a bunch of fanclubs already | 08:33 |
| pitti | lol | 08:34 |
| ion_ | :-) | 08:34 |
| pitti | what would we do without Launchpad? | 08:34 |
| ion_ | pitti: There’s a better rotated i: ᴉ | 08:34 |
| pitti | ion_: tell that to the guys at http://www.sevenwires.com/play/UpsideDownLetters.html :) | 08:35 |
| StevenK | pitti: Right, I'll fix up desktop-switcher | 08:44 |
| StevenK | pitti: u-n-r-d-s re-uploaded as 0.1 | 08:46 |
| StevenK | pitti: u-n-r-d-s is fine as universe | 08:47 |
| mvo | u-n-r-d-s? that sounds like a long name :) | 08:47 |
| StevenK | ubuntu-netbook-remix-default-settings | 08:48 |
| tkamppeter | pitti, hi | 08:53 |
| pitti | hey tkamppeter | 08:53 |
| tkamppeter | pitti, s-c-p needs a new Python library, see bug 321785, should I simply upload it (going into Universe NEW) or should I upload it into REVU? | 08:54 |
| ubottu | Launchpad bug 321785 in ubuntu "pysmbc library needed for system-config-printer to support browsing for SMB printer shares" [Medium,In progress] https://launchpad.net/bugs/321785 | 08:54 |
| tkamppeter | pitti, it is a simple package like python-cups and it is also from Tim Waugh. | 08:55 |
| StevenK | pitti: http://paste.ubuntu.com/110194/ for proposed changes to desktop-switcher | 08:55 |
| pitti | tkamppeter: if it's lintian clean, and you are reasonably sure about the packaging, just upload it; if you have some doubts and would like to get feedback, use REVU | 08:59 |
| pitti | StevenK: s/Allows the user to// IMHO, but the intltool stuff looks fine | 09:00 |
| StevenK | pitti: Hmmm, yeah | 09:01 |
| StevenK | "allows the user" is a little redudant :-) | 09:01 |
| slangasek | tjaalton: do you have any further insights into bug #270259, given that it failed SRU verification? | 09:02 |
| ubottu | Launchpad bug 270259 in acpid "Leaks file descriptors and eventually runs out" [Medium,Fix released] https://launchpad.net/bugs/270259 | 09:02 |
| tkamppeter | pitti, thanks. It is Lintian-clean (both source and binary) and it works (I can browse for SMB shares with s-c-p), so I will upload it. | 09:04 |
| tjaalton | slangasek: no.. but it hasn't caused problems here anymore (running on ~300 desktops) | 09:04 |
| tjaalton | so it definately fixed _something_ | 09:04 |
| slangasek | tjaalton: do you know what the python test program is that Paul refers to? | 09:05 |
| slangasek | oh, probably the one in the bug description | 09:06 |
| tjaalton | yes | 09:06 |
| tjaalton | haven't tried it myself | 09:06 |
| slangasek | I can reproduce the problem using that script, even on jaunty | 09:09 |
| tkamppeter | pitti, package is uploaded now, its name is python-smbc. | 09:11 |
| tjaalton | maybe the rate of leaks is now smaller, but still not fully fixed | 09:11 |
| StevenK | slangasek: Also reproduced in Intrepid. | 09:13 |
| StevenK | tjaalton: It doesn't seem to be smaller. | 09:14 |
| StevenK | tjaalton: I just connected eight times and closed the socket, and acpid has another 8 FDs open | 09:14 |
| tjaalton | StevenK: ok, but we haven't had any "/var full" incidents since the update (on our local repo) | 09:15 |
| StevenK | /var full is a side-effect, not the cause | 09:15 |
| tjaalton | of course | 09:15 |
| tjaalton | caused by the logfile bombing | 09:15 |
| StevenK | So it's pointless to declare that since /var hasn't filled up, it's fixed the problem. | 09:16 |
| tjaalton | well it's certainly better for us | 09:16 |
| tjaalton | I would've seen that many times during these couple of months | 09:17 |
| StevenK | slangasek: Should we slam that bug back to Confirmed and open a task for Intrepid? | 09:17 |
| slangasek | AFAICS, the rate of leaks is still one socket per socket - so the leak doesn't look slower to me... | 09:17 |
| slangasek | StevenK: I wouldn't bother with a separate intrepid task at this point, let's worry about jaunty and hardy first | 09:17 |
| slangasek | ah - I see, the patch only causes acpid to notice the closed socket when it tries to write to it and gets an EPIPE | 09:20 |
| slangasek | so if there are no ACPI events happening, the sockets stay open :) | 09:20 |
| * slangasek generates an ACPI event and sees the socket close | 09:22 | |
| StevenK | How does one generate an ACPI event? | 09:22 |
| slangasek | StevenK: I closed my laptop lid. <shrug> :) | 09:22 |
| StevenK | Hmm. My desktop doesn't have a laptop lid :-) | 09:22 |
| StevenK | Meh. It's not like 8-10 open FDs is going to kill anything | 09:23 |
| pitti | seb128: ah, I found out why consolidating is so slow; there are tons of bugs which do not have the 'apport-retrace' tag any more | 09:23 |
| seb128 | pitti: how come? | 09:23 |
| pitti | if only I'd know | 09:24 |
| * pitti retags them | 09:24 | |
| pitti | seb128: I added logging for that case yesterday | 09:24 |
| seb128 | pitti: it seems the retracer just don't add this tag by looking at the recent emails I got | 09:25 |
| pitti | seb128: the retracer isn't supposed to | 09:26 |
| seb128 | pitti: what is supposed to? | 09:26 |
| pitti | seb128: when filing the bug it should already be there | 09:26 |
| seb128 | pitti: need-arch-retracing is there when filling the bug | 09:26 |
| seb128 | and apport-crash | 09:27 |
| pitti | seb128: right, and the apport-crash tag is set with the very same call | 09:27 |
| seb128 | pitti: you said apport-retrace before though? | 09:27 |
| pitti | many of those are very old bugs, though (1xxxxx) | 09:27 |
| seb128 | pitti: wasn't that supposed to be set on succeful retracing? | 09:27 |
| pitti | maybe the triagers just removed the tag | 09:27 |
| pitti | seb128: sorry, 'apport-crash' I mean | 09:27 |
| seb128 | I doubt of that | 09:27 |
| seb128 | do you have desktopish bug number? | 09:28 |
| pitti | http://pastebin.com/f2806928a | 09:28 |
| seb128 | urg | 09:29 |
| pitti | I'll fix them once for now | 09:29 |
| pitti | and then observe when it happens again | 09:29 |
| pitti | 1.500 bugs point towards a system problem, not to triagers removing it | 09:29 |
| pitti | seb128: no wonder that it takes 2:40 hours with that long list.. | 09:30 |
| seb128 | pitti: did you fix those already? | 09:31 |
| pitti | seb128: it's currently running, from the top | 09:31 |
| pitti | but tagging 1600 bugs will also take that long, I expect 2:30 hours | 09:31 |
| seb128 | pitti: weird, bug #315307 is tagged but at the bottom of our list | 09:31 |
| ubottu | Launchpad bug 315307 in gnome-settings-daemon "gnome-settings-daemon crashed with SIGSEGV in gnome_rr_config_match() (dup-of: 314406)" [Medium,Invalid] https://launchpad.net/bugs/315307 | 09:31 |
| ubottu | Launchpad bug 314406 in gnome-desktop "xrandr plugin of g-s-d crashes on startup" [Medium,Fix released] https://launchpad.net/bugs/314406 | 09:31 |
| seb128 | pitti: that's a duplicate though | 09:31 |
| pitti | oh, hang on | 09:32 |
| seb128 | pitti: do you handle duplicates incorrectly? | 09:32 |
| seb128 | our list -> your list | 09:32 |
| pitti | seb128: right, I assume some/many of those are duplicates | 09:32 |
| pitti | however, yesterday I found three bugs which weren't, but didn't have an apport-crash tag | 09:33 |
| seb128 | pitti: maybe those were manual untagging | 09:33 |
| pitti | so it seems I need to clean up the dup db and throw out the bugs which were marked as dupe | 09:34 |
| seb128 | I though using duplicates was useful | 09:34 |
| seb128 | sometimes the duplicates have a different or better stacktrace and it's useful to have this one is the database | 09:35 |
| pitti | yes, but not as master bug | 09:35 |
| seb128 | right | 09:35 |
| pitti | right, but then I should update the master bug number | 09:35 |
| seb128 | right | 09:36 |
| pitti | since the dupes won't appear on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=apport-crash | 09:36 |
| pitti | which is what I am using to find out all non-fixed bugs | 09:36 |
| pitti | ok, gives me something to work on | 09:36 |
| pitti | but first, sponsoring o'clock | 09:36 |
| seb128 | brb, restarting session | 09:36 |
| StevenK | pitti: Oh, the other thing to please check for me is human-netbook-theme. | 09:44 |
| slangasek | tjaalton: looking at the acpid source makes me sad :( | 09:46 |
| tjaalton | slangasek: I can understand.. | 09:48 |
| slangasek | especially the part where they give each client an associated regexp of .* and then do regexp matching to decide whether to pass the event to the client | 09:51 |
| tjaalton | uh :) | 09:52 |
| slangasek | tjaalton: btw, do you know why libxcb1 declares a Conflicts: on libxcb-xlib0? I don't see any filesystem-level overlapping | 09:59 |
| slangasek | the Conflicts: without a Replaces: causes libx11-6 and libxcb1 to be held back on upgrades | 09:59 |
| asac | ArneGoetje: 214519 ... is there anything in the pipeline for that dictionary or shall i just sponsor? | 10:01 |
| tjaalton | slangasek: hmm, no I don't.. I'll ask jcristau | 10:03 |
| ogra | Keybuk, !! | 10:11 |
| ogra | Keybuk, http://launchpadlibrarian.net/21658731/buildlog_ubuntu-jaunty-armel.openjdk-6_6b14-0ubuntu10_FAILEDTOBUILD.txt.gz why does udev fail here ? | 10:12 |
| ogra | cat: /sys/kernel/uevent_seqnum: No such file or directory | 10:12 |
| ogra | invoke-rc.d: initscript udev, action "restart" failed. | 10:12 |
| ogra | dpkg: error processing udev (--configure): | 10:12 |
| * ogra saw that error in local image setups before, but it didnt fail back then ... | 10:13 | |
| === Johnm_ is now known as johnm | ||
| ArneGoetje | asac: I don't have anything in the pipeline for that one... I just saw it in my bugmail. | 10:20 |
| asac_ | ArneGoetje: thx | 10:21 |
| asac_ | will proceed then | 10:21 |
| ArneGoetje | asac_: ok, go ahead. Thanks :) | 10:21 |
| slangasek | anyone here with broadcom wireless who could test out whether the jockey SRU in hardy-proposed makes it work? | 10:34 |
| === asac_ is now known as asac | ||
| slangasek | (bug #289845) | 10:34 |
| ubottu | Launchpad bug 289845 in jockey "WL and B44 Not Properly Configured" [Undecided,Fix committed] https://launchpad.net/bugs/289845 | 10:34 |
| seb128 | hum | 10:37 |
| davmor2 | slangasek: any preference on architecture? | 10:37 |
| seb128 | did anybody get xorg speed issues on intel in jaunty since recents updates? | 10:37 |
| seb128 | ie opening new dialogs or switching workspace has several second lags | 10:37 |
| slangasek | davmor2: no, just whether you have one of the wireless chips that didn't work previously | 10:38 |
| Milosz | Is there a way to see download statistics for packages somewhere? | 10:38 |
| davmor2 | slangasek: I can't remember I have a feeling in hardy I had to use ndiswrapper | 10:39 |
| directhex | Milosz, sort of | 10:39 |
| directhex | Milosz, popcon.ubuntu.com - but that only counts users with the "popcon" package installed | 10:39 |
| davmor2 | slangasek: I'll fire it up and see anyway | 10:40 |
| Milosz | Hmm ok I was there, and didn't find the package I was looking for | 10:40 |
| Milosz | i'll check again | 10:40 |
| Milosz | directhex, thanks | 10:40 |
| seb128 | tjaalton, tseliot: ^ did you read my xorg question? any known recent speed issue on jaunty intel? | 10:42 |
| tseliot | seb128: I've noticed that too but I don't know what's causing the problem | 10:44 |
| davmor2 | slangasek: I have the same chipset as in the bug and on today iso it works fine from cd do you want it installing and testing? | 10:50 |
| slangasek | davmor2: what do you mean by "today's iso"? I'm looking for a test of the hardy SRU, and there are no hardy ISOs from today... :) | 10:51 |
| davmor2 | slangasek: iso is the one from the 21st I hit the sta driver in jockey and wireless networks appears I select the connection and the t'interweb works :) | 10:55 |
| slangasek | 'sta' driver? | 10:55 |
| slangasek | davmor2: sounds like a positive result, then - could you post that information to the bug, please? | 10:56 |
| davmor2 | slangasek: listed as Broadcom STA wireless driver in jockey | 10:56 |
| slangasek | ah, so it is | 10:57 |
| * apw wonders who has the best view of how the kernel/hal/Xorg/gnome-power-manager fit together, as we are seeing double and tripple suspends in response to a button led suspend | 10:57 | |
| slangasek | apw: https://wiki.ubuntu.com/Hotkeys/Architecture, https://wiki.ubuntu.com/Hotkeys/Troubleshooting for a starting point | 10:58 |
| slangasek | davmor2: oh, this bug only affects machines that also have the b44 driver - is that the driver for your ethernet on this machine? | 10:59 |
| davmor2 | slangasek: http://www.davmor2.co.uk/hplappy.html seems to be the same chipset as the initial reporter | 11:02 |
| cq | hm, any idea why ubuntu has a much larger /lib than a debian install? | 11:03 |
| slangasek | well, the ethernet is listed as forcedeth there, so I guess it's not the same enough | 11:03 |
| slangasek | davmor2: thanks for testing, but I guess the results are inconclusive except to show that there's not a regression | 11:03 |
| tjaalton | seb128: yes, bug 320813 | 11:03 |
| ubottu | Launchpad bug 320813 in mesa "[GM45] with EXA compiz animations cause temporary freezes" [High,Confirmed] https://launchpad.net/bugs/320813 | 11:03 |
| seb128 | tjaalton: thanks | 11:04 |
| apw | oh its this fix to X to make the sleep button work | 11:04 |
| seb128 | tjaalton: any idea if that will be fixed quickly in jaunty or how to workaround? | 11:04 |
| tjaalton | seb128: no proper workaround I'm afraid | 11:04 |
| apw | now how can i find that | 11:04 |
| tjaalton | seb128: well, don't suspend :) | 11:04 |
| tjaalton | that's known to trigger it | 11:05 |
| seb128 | tjaalton: I didn't suspend, that's a fresh boot from today | 11:05 |
| cjwatson | cq: all sorts of possible reasons (different kernel module sets, firmware, things like FUSE and NTFS moved into /lib to support using them in early boot, etc.). Why? | 11:06 |
| tjaalton | seb128: ok, so it's triggered by something else then | 11:06 |
| tjaalton | seb128: check dmesg if there's anything suspicious | 11:06 |
| cq | cjwatson, i just moved my system to LVM (tmp, swap, usr, var, home) and have a too-small root partition for the Ubuntu lib | 11:07 |
| cjwatson | cq: that's life, sorry | 11:07 |
| cq | cjwatson: no kidding, I was just wondering if that was a design decision, and if so why.... supporting more at boot makes sense | 11:07 |
| cjwatson | personally I have never recommended separate /usr and /var | 11:07 |
| cjwatson | well, not separate /usr anyway | 11:08 |
| cjwatson | I can understand separate /var for log files and so on | 11:08 |
| cq | why not? meaning /usr on root, or together with var? | 11:08 |
| * slangasek separates /usr to avoid overhead of encryption | 11:08 | |
| tjaalton | separate /usr is UNIX legacy :) | 11:08 |
| cjwatson | cq: it's not a design decision in itself, but is the likely consequence of other design decisions | 11:08 |
| cjwatson | separate /usr *should* be supported, I agree, but is an excellent way to ensure that you're first to run into a slew of bugs | 11:08 |
| cjwatson | so if you like that sort of thing, great | 11:08 |
| seb128 | tjaalton: nothing special there from a quick glance | 11:09 |
| slangasek | hrm, I can't remember the last time I ran into a bug because of it :) | 11:09 |
| tjaalton | seb128: ok, and I bet nothing in the xorg log either | 11:09 |
| seb128 | no | 11:10 |
| seb128 | nor in syslog | 11:10 |
| cjwatson | I remember in particular that hwclock behaved differently for a while if you had a separate /usr | 11:10 |
| cjwatson | and of course encrypted filesystems were broken at some point (was it edgy? feisty?) | 11:10 |
| cjwatson | the first release after we introduced vaguely working support for them post-usplash, anyway | 11:11 |
| seb128 | ok, restarting my box and having lunch too, bbl | 11:11 |
| === Guest44711 is now known as jelmer | ||
| tjaalton | seb128: I'm pretty certain that it's the new drm patches that got in -5.15, since I had been running the same userland for a week without problems | 11:12 |
| cq | before running gparted, is there a way to defragment the drive? | 11:18 |
| apw | presumably you could just test by booting back to the -4 kernel wnhich should still be installed | 11:18 |
| BUGabundo | cq ext doesnt fragment | 11:18 |
| cq | ok, so I can just resize the partition to as small as the existing data permits? | 11:19 |
| BUGabundo | although fsck does some file reording with -D | 11:19 |
| cq | plus a safety margin... | 11:19 |
| BUGabundo | yeah, u need a margin | 11:19 |
| cq | it wants 15gb, i give it 30 :) | 11:27 |
| BUGabundo | lol | 11:27 |
| BUGabundo | what does df -h say» | 11:27 |
| cq | nothing right nowm its still resizing down from 900GB :) | 11:29 |
| BUGabundo | rofl | 11:29 |
| apw | one or two cylinder groups to check | 11:29 |
| cq | the weird part is, according to DF it should only have used 500MB | 11:31 |
| apw | superm1, you did some changes to X to get XF86Battery key working on bug #281134 wanted to talk to you about the XKeySymDB update that that brought | 11:41 |
| ubottu | Launchpad bug 281134 in xkeyboard-config "Intrepid regression: XF86Battery hotkey doesn't work" [Undecided,Fix released] https://launchpad.net/bugs/281134 | 11:41 |
| cjwatson | gah. of course it would be too easy if random packages didn't break the installer build :-/ | 11:46 |
| === sabdfl1 is now known as sabdfl | ||
| ogra | cjwatson, i see d-i still on the ftbfs list, i though the udebs were there and would fix it ? | 11:53 |
| ogra | ah, your latest upload seems to attack that, i see | 11:54 |
| cq | I have a kubuntu X server problem... maybe you guys have an idea | 11:55 |
| cq | I boot the machine, get to the login screen, log in, and the resolution is set too low. Then I click on system settings -> display, and hte display goes dark and then adjusts to the correct resolution... | 11:55 |
| StevenK | pitti: So, if I can tempt you to look at the archive again -- desktop-switcher has built everywhere so needs review for binary NEW. I've not uploaded -0ubuntu2 with the .pot fix, I was waiting for -0ubuntu1 to get out of NEW first. Then there's the new u-n-r-d-s and human-netbook-theme in source NEW. :-) | 11:55 |
| cq | next boot, same story. | 11:56 |
| pitti | StevenK: W: desktop-switcher: script-with-language-extension usr/bin/gconf-panel-saving.sh | 11:56 |
| pitti | :) | 11:57 |
| StevenK | Meh, it's a warning :-P | 11:57 |
| pitti | StevenK: h-n-t needs to grow .icon files for translated emblems, and needs to drop build/ from the orig.tar.gz (the latter is more relevant for NEW, since it ships binary files in the tar.gz) | 12:00 |
| StevenK | There's a build directory!? How did I miss that? | 12:00 |
| pitti | StevenK: cf. the recent changes to human-icon-theme from primes2h | 12:01 |
| StevenK | pitti: I wonder if we can just have h-n-t depend on human-icon-theme | 12:01 |
| pitti | StevenK: it does already? | 12:01 |
| pitti | StevenK: (and please fix debian/rules clean to remove build) | 12:01 |
| pitti | StevenK: d-s binary NEWed, u-n-r-d-s isn't in the queue (forgot to remove the .upload file?), rejected h-n-t for the binary stuff | 12:03 |
| * StevenK kicks dput | 12:03 | |
| StevenK | pitti: I'll deal with d-s armel when it turns up since you've accepted the rest | 12:04 |
| StevenK | pitti: u-n-r-d-s reuploaded. | 12:05 |
| ogra | cant you generate longer abbreviations ? :P | 12:07 |
| StevenK | ogra: I can expand it out if you want | 12:07 |
| ogra | well, u-nerds sounds funny actually :) | 12:08 |
| ogra | now that i read it aloud | 12:08 |
| pitti | Keybuk: any idea what else in bug 283316 could call vol_id or scsi_id? what udevmonitor incantation would you recommend for debugging this? | 12:09 |
| ubottu | Launchpad bug 283316 in udev "CD-ROM tray closes automatically after eject" [High,Confirmed] https://launchpad.net/bugs/283316 | 12:09 |
| StevenK | pitti: Er, what translatted emblems? | 12:10 |
| StevenK | pitti: I'm not so clear on theme packages, so you can explain the first part with butchers paper and crayon? | 12:10 |
| pitti | StevenK: bug172353 | 12:10 |
| pitti | bug 172353 | 12:10 |
| ubottu | Launchpad bug 172353 in human-icon-theme "Human theme has non-translatable emblem names." [Low,Fix released] https://launchpad.net/bugs/172353 | 12:10 |
| pitti | has the details | 12:10 |
| StevenK | Ah, okay | 12:10 |
| StevenK | pitti: Which bit of h-n-t has emblems? | 12:13 |
| StevenK | pitti: Since maybe they can get stripped | 12:13 |
| pitti | StevenK: ah, sorry; it doesn't ship its own icons, sorry; ignore me | 12:13 |
| StevenK | pitti: Right, so the build directory is the only thing. Cool. | 12:14 |
| StevenK | pitti: u-n-r-d-s? :-P | 12:16 |
| tkamppeter | I have uploaded Ghostscript 8.64RC1 and it builds perfectly on PCs (i386 and x86_64) but fails on all non-PC architectures (sparc, powerpc, lpia, ia64, hppa) not being able to install its needed libraries due to inconsistencies in the repositories. | 12:20 |
| Keybuk | pitti: hal? | 12:20 |
| ddeath | Hi | 12:20 |
| ddeath | What do you can tell me about dekstop sharing on Ubuntu? | 12:20 |
| ddeath | I have new idea to do it. | 12:21 |
| tkamppeter | The following packages have unmet dependencies: | 12:21 |
| tkamppeter | freeglut3-dev: Depends: xlibmesa-gl-dev but it is not going to be installed or | 12:21 |
| tkamppeter | mesag-dev or | 12:21 |
| tkamppeter | libgl-dev | 12:21 |
| tkamppeter | Depends: xlibmesa-glu-dev or | 12:21 |
| tkamppeter | libglu-dev | 12:21 |
| pitti | Keybuk: I mean, the udev rules still call vol_id if there are tracks, I just wonder how to check that in an udev debugging output log | 12:21 |
| Keybuk | ogra: because it can't restart the running udev on the buildd I guess | 12:21 |
| ddeath | Why I must share whole desktop, nor only certain application | 12:21 |
| Keybuk | pitti: udevadm monitor --udev should tell you | 12:21 |
| Keybuk | it'll show you the tracks in the env | 12:21 |
| StevenK | Keybuk: I didn't think the buildds used udev ? | 12:22 |
| ogra | Keybuk, hmm, any way to avoid that in the package ? | 12:22 |
| ogra | Keybuk, i would exect the buildd env to be in a chroot, udevs shouldnt restart in a chroot | 12:22 |
| ogra | *udevd | 12:22 |
| ogra | *expect | 12:23 |
| * ogra needs type training :( | 12:23 | |
| Keybuk | in this case, it looks like it's failing even before that because the chroot doesn't have /sys mounted | 12:23 |
| Keybuk | or has an ancient kernel | 12:23 |
| pitti | Keybuk: thanks, asked for that and test with hal stopped | 12:25 |
| cjwatson | ogra: ignore d-i, I'm looking at it | 12:25 |
| ogra | cjwatson, yeah, i saw that after asking :) | 12:26 |
| ddeath | Hi everybody | 12:29 |
| StevenK | pitti: *prod* h-n-t uploaded | 12:34 |
| pitti | StevenK: both done | 12:37 |
| StevenK | pitti: As in ACCEPTed? | 12:38 |
| pitti | yes | 12:38 |
| StevenK | pitti: Ahh, thanks :-) | 12:38 |
| === davmor2 is now known as davmor2-lunch | ||
| directhex | cjwatson, poke poke r.e. debhelper 7.1. 7.1 (in experimental) broke something that pkg-mono has been using for a few years to handle package versioning. since all current mono development is happening in experimental, this has forced the need for "mono" and "cli-common" to be altered with workarounds. net result: either jaunty needs dh7.1 too, or all jaunty mono from now on needs to be merged rather than synced, to revert those 7. | 12:43 |
| directhex | 1 workarounds (and cli-common-dev absolutely NOT updated) | 12:43 |
| StevenK | pitti: Both of them are in binary NEW | 12:44 |
| StevenK | directhex: Are they using a compat level of 6 or below? | 12:44 |
| directhex | StevenK, no. 7.0 is used extensively | 12:45 |
| StevenK | directhex: The version has a little to do with the compat level | 12:46 |
| StevenK | directhex: If you've been using the behaviour for a few years, you'd be stuck in compat 5 or so? | 12:46 |
| directhex | StevenK, yes, it looks like mono and cli-common have a compat of 5. | 12:47 |
| StevenK | directhex: If debhelper 7.1 has broken compat 5, then file a bug on debhelper | 12:48 |
| seb128 | tjaalton: the way to trigger the xorg slowness on my laptop is to restart the session | 12:48 |
| directhex | <meebey> compat is used for extra features in existing debhelper files, which is not the case here | 12:53 |
| cjwatson | has anyone asked joeyh about it? | 12:53 |
| StevenK | It should not break backward compatibility | 12:53 |
| cjwatson | meebey's description is inaccurate, TBH | 12:53 |
| directhex | there's some new syntax in 7.1+1 afaik | 12:53 |
| cjwatson | compat has been used in the past to cope with changes that required breaking backward compatibility | 12:53 |
| StevenK | Since doing so could render large parts of the archive insta-FTBFS | 12:54 |
| cjwatson | it is NOT just for new features | 12:54 |
| tjaalton | seb128: ok.. | 12:54 |
| soren | seb128: Killing gnome-power-manager doesn't help? | 12:54 |
| cjwatson | directhex: can you give me a precise reference - what change was required in mono? | 12:54 |
| seb128 | soren: I doubt of it, I'm on ac and I don't have any processus eating cpu | 12:54 |
| soren | seb128: Doesn't matter. | 12:55 |
| soren | seb128: It doesn't use much CPU, it just keeps Xorg *really* busy. | 12:55 |
| soren | seb128: I'm on AC as well and had the same problem. | 12:55 |
| seb128 | I though that issue was trigerred by power management events, ie changing backlight or ac to battery | 12:55 |
| seb128 | and it was already there one week ago | 12:55 |
| seb128 | I just started having the issue with the upgrade I did yesterday | 12:56 |
| soren | Ah. | 12:56 |
| === Guest69572 is now known as jrib | ||
| meebey | cjwatson: you think the init() change was a bug? | 12:57 |
| StevenK | meebey: I think so too. | 12:58 |
| meebey | thing is, debhelper never had a proper interface for non-debhelper parameters | 12:58 |
| meebey | so cli-common-dev used parameters that are used by existing debhelper tools | 12:58 |
| meebey | could call it "internal usage" | 12:59 |
| meebey | non-debhelper in this context means dh-scripts not part of the debhelper source package | 12:59 |
| meebey | now with dh7.1, joeyh added an API for it, init() takes an argument now | 12:59 |
| tjaalton | seb128: disabling vblank again might fix it for now | 13:00 |
| seb128 | tjaalton: how do I do that? | 13:00 |
| tjaalton | seb128: build mesa with the patch from the previous version | 13:00 |
| seb128 | tjaalton: ok, that could take a while, maybe I'll try later ;-) | 13:02 |
| tjaalton | seb128: sure | 13:02 |
| meebey | the change in dh7.1 was a backwards compatiblity breakage without doubt, but relying on parameters maybe handled by debhelper or not was not that nice either | 13:02 |
| PecisDarbs | hi people, what does linux-image-virtual means and why it doesn't have all ata kernel drivers? It is on purpose? | 13:02 |
| meebey | so cli-common-dev < 0.6 needs dh < 7.1 | 13:02 |
| StevenK | meebey: Or you needed to bump compat to 8 due to the change and still deal with the old behavior | 13:03 |
| StevenK | meebey: Since breaking debhelper can make large parts of the archive insta-FTBFS | 13:03 |
| tjaalton | seb128: http://git.debian.org/?p=pkg-xorg/lib/mesa.git;a=blob_plain;f=debian/patches/102_dont_vblank.patch;h=99000f2f819dade994f3b221e48c456a3dfccff0;hb=4f2e014fcd7c6fa58172c768f843e678c1332ea0 | 13:03 |
| tjaalton | seb128: that's the actual patch | 13:04 |
| meebey | StevenK: AFAIK compat was never used for internal changes, only for source package that use debhelper directly, which is not the case for cli-common-dev | 13:04 |
| seb128 | tjaalton: ok | 13:04 |
| meebey | StevenK: cli-common-dev doesn't use debhelper, it extends debhelper | 13:04 |
| lamont` | WTF piece of braindamage in network-mangler causes it to generate resolv.conf files with both 'domain' and 'search' directives? | 13:04 |
| StevenK | meebey: Hmm. It provides a dh_ ? | 13:04 |
| meebey | StevenK: yes | 13:04 |
| === lamont` is now known as lamont | ||
| meebey | StevenK: dh_makeclilibs which causes the pain now | 13:05 |
| meebey | StevenK: -m is ignored means it generates no minimum version for clilibs | 13:05 |
| tjaalton | seb128: I could build it myself later | 13:06 |
| meebey | StevenK: I fixed that in cli-common-dev, that it registers the parameter it needs and that fixes it | 13:06 |
| meebey | StevenK: didn't upload yet though | 13:06 |
| seb128 | tjaalton: do you get the bug to test that change? | 13:06 |
| StevenK | Mmmmmm | 13:06 |
| tjaalton | seb128: yep | 13:06 |
| seb128 | ok good, I will let you try then, I've enough other things to do today ;-) | 13:06 |
| StevenK | Right, that is a completly different issue ... | 13:06 |
| tjaalton | seb128: the kernel was ruled out, at least the recent changes didn't break it | 13:07 |
| tjaalton | seb128: me too.. damn ITIL web course (using flash of course) | 13:07 |
| junyer | hi | 13:08 |
| meebey | StevenK: a bit odd is thought hat debhelper still registers some parameters for all tools :) | 13:08 |
| junyer | who's the best person to hassle about the autofs{,5} packages? | 13:09 |
| meebey | StevenK: a bit inconsistent :-P | 13:09 |
| meebey | like -V IIRC | 13:09 |
| mok0 | We're seeing more and more packages coming from VCS repos and with no upstream tarball. I'm looking for suggestions on how to make the watch file work for those | 13:10 |
| junyer | (specifically, with regard to autofs v4 EOL) | 13:12 |
| directhex | wsvn! | 13:12 |
| cjwatson | meebey: ah, so the problem is with debhelper extensions not ordinary debhelper use. hmm. | 13:17 |
| cjwatson | meebey: it feels to me that there ought to be a way to make the new code in cli-common-dev backwards-compatible, even if we can't make debhelper backwards-compatible | 13:17 |
| cjwatson | meebey: actually, surely it already is | 13:18 |
| meebey | cjwatson: well I didn't change any parameter usage code | 13:19 |
| cjwatson | meebey: if it's just a matter of passing an extra argument to init(), you can do that without breaking old debhelper | 13:19 |
| meebey | cjwatson: I only registered the parameters, thats all | 13:19 |
| cjwatson | since old debhelper's init() ignored @_ | 13:19 |
| meebey | cjwatson: so perl wouldn't cry? | 13:19 |
| cjwatson | no | 13:19 |
| cjwatson | init isn't prototyped so it won't check | 13:19 |
| meebey | so cli-common-dev works with old debhelper then | 13:20 |
| cjwatson | I haven't checked this, but my perl's pretty good | 13:20 |
| meebey | didn't know perl was that hacky^Wrelaxed | 13:20 |
| junyer | teeheehee | 13:20 |
| cjwatson | meebey: depends whether you use prototypes or not; if you use prototypes it's stricter. joeyh is a bit old-school and often doesn't, though | 13:34 |
| cjwatson | directhex: so it sounds as if this is not a major problem; we just take new cli-common-dev and don't worry | 13:35 |
| directhex | cjwatson, well, i'll try a test build of mono 2.0.1-3 which would exhibit a problem | 13:35 |
| directhex | if there were one to exhibit | 13:35 |
| directhex | but first, i must buy some bubble wrap | 13:35 |
| meebey | so I can lower the build-dep of mono on debhelper | 13:43 |
| directhex | meebey, test build needed, to be 101% certain | 13:44 |
| directhex | but first, bubble wrap! | 13:44 |
| meebey | directhex: you can do that, just need to check any deps if they have versions or not | 13:45 |
| lool | cjwatson: I had to repush xine-lib still for bug #290768 as a security update was just released | 13:49 |
| ubottu | Launchpad bug 290768 in xine-lib "C format string specifications mismatch in translations crashes libxine based apps in some loales" [Undecided,Fix committed] https://launchpad.net/bugs/290768 | 13:49 |
| lool | cjwatson: 1.1.15-0ubuntu3.1intrepid1 is in unapproved | 13:50 |
| === davmor2-lunch is now known as davmor2 | ||
| superm1 | apw, yeah, what about it? | 14:03 |
| apw | superm1, do you know if htat might have included the XF86Sleep symbol? | 14:04 |
| mdeslaur | siretart: I noticed you were the one who merged xine-lib the last. There are security issues in xine-lib in Jaunty. Either I apply the security patches to it, or someone merges from unstable. What do you think would be best? | 14:04 |
| superm1 | apw, no it didn't. Here's the diff: http://launchpadlibrarian.net/20150384/libx11_2%3A1.1.5-2ubuntu1_2%3A1.1.5-2ubuntu1.1.diff.gz | 14:06 |
| superm1 | apw, i believe upstream renamed the keys between intrepid and jaunty however | 14:06 |
| apw | ++XF86Suspend:1008FFA7 | 14:06 |
| apw | ++XF86Hibernate:1008FFA8 | 14:06 |
| apw | it did bring the one i meant (and missstated), thanks for the diff | 14:06 |
| apw | i think that is the cause of strange bug i have with machines double suspending | 14:07 |
| apw | (or even tripple) | 14:07 |
| superm1 | apw, do you mean hibernating or suspending? | 14:07 |
| apw | i mean suspend in this case | 14:07 |
| apw | you iht FN-f4 and my T30 suspends 3 times | 14:07 |
| apw | ie suspends again twice after waking | 14:07 |
| superm1 | apw, on jaunty or intrepid? | 14:07 |
| apw | and a number of other platforms report double suspend | 14:07 |
| apw | on jaunty | 14:07 |
| superm1 | apw, well on jaunty that's a little more explainable i think. hal sends those as dbus events and gnome power manager reacts to them | 14:08 |
| superm1 | apw, so are there multiple users logged in? | 14:08 |
| ogra | apw, there is some discussion on the hal ML about having keys captured multiple times on IBM HW (not sure thats related) | 14:08 |
| StevenK | pitti: *prod* please release h-n-t and u-n-r-d-s from binary NEW. And webfav is in source NEW. And that's the last one, I swear! | 14:08 |
| apw | superm1, no not multiple users | 14:09 |
| apw | what we see at gnome-power-manager is a hal key coming in and an XF86Suspend X event coming in and _both_ being executed | 14:09 |
| seb128 | StevenK: didn't you have ubuntu-archive powers? | 14:10 |
| apw | for my T30 there is something even odder going on in that HAL produces two keys from different places | 14:10 |
| superm1 | apw, then what you'll want to do is put a dbus monitor on the bus and see how many times the event is being sent | 14:10 |
| apw | but i suspect that is a separat bug | 14:10 |
| apw | which event the suspend event? | 14:10 |
| StevenK | seb128: I still do, I don't like pulling stuff I've uploaded out of binary or source NEW. | 14:10 |
| StevenK | seb128: Second pair of eyes, etc, etc | 14:10 |
| seb128 | StevenK: binary new is usually no issue | 14:10 |
| apw | they are real complete and separate suspend/resume cycles | 14:10 |
| superm1 | apw, gnome-power-manager shouldn't be reacting to the X event, only the dbus event | 14:10 |
| apw | well it has code in it to react? | 14:10 |
| seb128 | StevenK: we usually don't NEW our source uploads but I consider binaries as being no issue | 14:11 |
| apw | which now works as the keysymbol now exists :) | 14:11 |
| StevenK | seb128, pitti: Okay, I'll deal with binary NEW. | 14:11 |
| StevenK | seb128: Review webfav in source NEW? :-) | 14:11 |
| superm1 | apw, it has code to react that's commented out | 14:11 |
| seb128 | StevenK: not now I'm busy on some other things right now, will do tomorrow during my archive day if nobody else did before ;-) | 14:11 |
| apw | superm1, will check, didn't look commented out, and produces mssages in my logs | 14:12 |
| superm1 | apw, hm, well XF86Battery is commented out in 2.24.0-0ubuntu13. if the others aren't, then they should be | 14:13 |
| apw | / gpm_button_xevent_key (button, XF86XK_Suspend, GPM_BUTTON_SUSPEND); | 14:18 |
| apw | gpm_button_xevent_key (button, XF86XK_Sleep, GPM_BUTTON_SUSPEND); /* should be configurable */ | 14:18 |
| apw | so ... Suspend is commented out but Sleep is not, and its Sleep that we see in the logs ... interesting | 14:19 |
| apw | i wonder what that means | 14:19 |
| apw | superm1, so is key handling moving frmo hal direct to X do you know? | 14:22 |
| superm1 | apw, so what changed here is that X no longer has an exclusive hold on the key. that's why HAL can send the dbus event | 14:25 |
| superm1 | apw, i believe this is the model that is going to stick, but you might check with pitti on it if he knows where HAL is headed about this | 14:26 |
| apw | so you think it is hal which is the new event here | 14:26 |
| pitti | I'm not actually sure | 14:27 |
| superm1 | i'm sure it is. that's what preempted my dropping 79-enable-battery-hotkey.patch | 14:27 |
| superm1 | when I pressed XF86Battery, I saw two popups. this was because I saw one dbus event from HAL and one grabbed keypress | 14:27 |
| apw | superm1, so by that same theory we should be suppressing XF86Sleep in g-p-m as hal is doing the job now | 14:28 |
| superm1 | apw, so i think in the short term, if any of those keys are still grabbed by gnome-power-manager that also get dbus events, you should throw a patch together that comments out the keys that are also sent by HAL. | 14:28 |
| superm1 | apw, yeah | 14:28 |
| apw | superm1, will give that a go as step one for these people, thanks | 14:29 |
| apw | for me i still have an issue in that now hal is producing keys i get two, and they both look rea; | 14:29 |
| apw | real ... | 14:29 |
| apw | they pop out two different hal channels, not sure if thats a kernel issue or hal | 14:29 |
| superm1 | apw, so the weird thing though is that only a few machines are seeing this? you should be able to reproduce it on any machine I would think | 14:29 |
| apw | but one bit a a time | 14:29 |
| apw | superm1, not convinced it isn't every machine yet | 14:30 |
| apw | as its only showing up on jaunty | 14:30 |
| apw | and it only hits you if you hit the key, and my key didn't work on intrepid | 14:30 |
| superm1 | apw, well it will only show up in jaunty, that's when the HAL change happend | 14:30 |
| apw | so i never used it, it was only when people reported the double and i found it differeed | 14:30 |
| apw | for menu driven suspend and key that i tried my key again | 14:30 |
| apw | so i gained a working key at the saem time it broke | 14:31 |
| apw | if you get me | 14:31 |
| apw | anyhow superm1 you have been most helpful as always | 14:32 |
| superm1 | apw, no problem, i've somehow gotten more involved in this hotkey mess :) | 14:32 |
| apw | its all those cute keys they keep adding to those dells that does it | 14:33 |
| directhex | meebey, what's the telltale sign whether this works or not? how would i spot a "bad" build in this context? missing versions on arch-all package deps? | 14:47 |
| apw | so i have just apt-get source gnome-power-manager and it tells me to use bzr, and spits out a bzr command to use which doesn't work | 14:51 |
| apw | any idea how i find out where it really is in launchpad | 14:52 |
| james_w | "doesn't work"? what was the command? | 14:55 |
| siretart | mdeslaur: please merge unstable. there is little point in staying at 1.1.14 | 14:56 |
| apw | Please use: | 14:56 |
| apw | bzr get bzr+ssh://bazaar.launchpad.net/~ted-gould/gnome-power/ubuntu-packaging | 14:56 |
| apw | was what it told me | 14:56 |
| apw | apw@dm$ bzr get bzr+ssh://bazaar.launchpad.net/~ted-gould/gnome-power/ubuntu-packaging | 14:57 |
| apw | bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~ted-gould/gnome-power/ubuntu-packaging/". | 14:57 |
| apw | and that is what it says when you try it | 14:57 |
| mdeslaur | siretart: you wouldn't feel like doing it, would you? :) | 14:57 |
| apw | james_w, i though that there was a short form now like lp://gnome-power/trunk | 14:58 |
| james_w | apw: seems like you want https://code.edge.launchpad.net/~gnome-power-manager-team/gnome-power/ubuntu-packaging-2.24 | 14:58 |
| siretart | mdeslaur: I'll try to find time to merge it this evening, ok? | 14:58 |
| apw | james_w, how on earth did you figure that out? | 14:58 |
| james_w | "bzr branch lp:~gnome-power-manager-team/gnome-power/ubuntu-packaging-2.24" will get you that | 14:58 |
| mdeslaur | siretart: that would be great! :) | 14:58 |
| james_w | apw: https://code.launchpad.net/gnome-power | 14:59 |
| james_w | apw: if you are changing something in the package would you update the URLs in debian/changelog then please? | 14:59 |
| apw | james_w, sure thing | 14:59 |
| cjwatson | (debian/control) | 15:00 |
| james_w | tedg: could you confirm that lp:~gnome-power-manager-team/gnome-power/ubuntu-packaging-2.24 is the branch to use to make changes in jaunty? | 15:00 |
| james_w | err, yeah, debian/control of course | 15:00 |
| apw | there is also a real trunk | 15:00 |
| seb128 | james_w: control.in in desktop packages if you want to keep your changes after a clean target run ;-) | 15:00 |
| james_w | lp:gnome-power is the upstream code | 15:01 |
| james_w | seb128: ah, of course :-) | 15:01 |
| tedg | james_w: Uhm, I believe it should be. But I merged the Debian SVN into there accidentally -- so it got downgraded to 2.22 :( | 15:01 |
| james_w | oops | 15:01 |
| tedg | james_w: So, yes, but it's FU right now. | 15:01 |
| seb128 | brb, xrandr screwed the usuable screen region when switching and there seems to be no other way that a reboot | 15:02 |
| apw | tedg, does that mean that we don't have the code we have in jaunty to modify? | 15:02 |
| tedg | apw: Well, what is current in Jaunty is an older revision on that branch. | 15:03 |
| tedg | apw: But there is a lot of other work on that branch that I don't want to loose. | 15:03 |
| tedg | apw: For instance, merging in all the mactel's team work. | 15:03 |
| apw | tedg, ok so if i want to make a change destined for jaunty, where should i base my branch | 15:04 |
| apw | i presume i should base from whats in jaunty to provide maximum flexibilty for where it gets merged to | 15:05 |
| apw | i presume we tag those branches when we cut releases? | 15:05 |
| apw | (where releases means something for upload) | 15:05 |
| tedg | apw: I don't usually tag. There's not enough revisions that I've done that. debcommit should though... | 15:07 |
| tedg | apw: Anyway, r108 of that branch is what is in Jaunty. | 15:07 |
| apw | so you would recommend branching from there | 15:08 |
| apw | so say it was 100% important we could release from that branch etc | 15:08 |
| apw | and if not it should merge just fine into your jaunty head | 15:08 |
| tedg | Yeah, I would say that if you branched from there, then we should be able to merge everything in -- that's Bazaar's job, right? :) | 15:09 |
| apw | yeah we should indeed. all changes should be against the last version so they can be merged in any order, imo | 15:10 |
| lool | §wo, 1 | 15:21 |
| lool | Ups | 15:21 |
| pirroh | hi, could someone with ubuntu+1 paste me the output of cat /proc/sys/fs/epoll/max_user_instances ? thanks a lot | 15:22 |
| pochu | pirroh: maybe try #ubuntu+1 | 15:28 |
| pirroh | pochu: thanks for the hint | 15:29 |
| meebey | directhex: unversioned deps on limono*-cil packages | 15:46 |
| directhex | meebey, doesn't matter. won't build. "Unknown option: internal-mono" | 15:47 |
| meebey | directhex: which dh did you use? | 15:47 |
| directhex | 7.0.foo. whatever's in jaunty | 15:48 |
| directhex | 7.0.17ubuntu2 | 15:48 |
| meebey | thats just for mono | 15:48 |
| meebey | special case | 15:48 |
| meebey | as it passes --internal-mono | 15:48 |
| meebey | so that requires dh7.1 | 15:48 |
| meebey | but non-mono would not | 15:48 |
| directhex | :| | 15:48 |
| meebey | cli-common-dev 0.6 would be backwards compatible with dh7.0 | 15:49 |
| meebey | but cli-common-dev 0.5 is not forward compatible with dh7.1 | 15:50 |
| meebey | and in the case of the mono source package, it's not backward compatible with dh7.0 | 15:50 |
| directhex | is there no way to make it backward compatible? i had hoped to avoid merging | 15:51 |
| meebey | so the issue is that ubuntu has no dh7.1 so mono can be synced? | 15:51 |
| cjwatson | well, debhelper 7.1 is only in experimental and so makes us nervous | 15:51 |
| cjwatson | we *could* include it | 15:51 |
| meebey | directhex: there is but that would need ugly conditional calls in mono's rules file | 15:51 |
| meebey | to pass the internal-mono parameter differently depending on the used debhelper version | 15:51 |
| meebey | :-P | 15:51 |
| meebey | is there sane way to check the debhelper version within debian/rules? | 15:52 |
| meebey | mono's source package is already full of hacks, so another hack wouldn't be too hurtful :-P | 15:54 |
| Laney | meebey: dpkg-query -f "${Version}" -W debhelper | 15:58 |
| meebey | Laney: with '' that looks good | 16:02 |
| meebey | Laney: thanks | 16:02 |
| === dendrobates- is now known as dendrobates | ||
| meebey | wrapped with dpkg --compare-version I guess thats a decent way to check for dh >= 7.1 | 16:02 |
| tkamppeter | pitti, I have prepared an SRU for bug 277404 and bug 303691 (in the cups package). The previous SRU of CUPS is still in -proposed. Should I already upload the new SRU? | 16:05 |
| ubottu | Launchpad bug 277404 in cups "hp laserjet postscript text print does not print some characters" [Undecided,Fix released] https://launchpad.net/bugs/277404 | 16:05 |
| ubottu | Launchpad bug 303691 in cups "Intrepid, print broken with Minolta PagePro 8L printer" [Medium,In progress] https://launchpad.net/bugs/303691 | 16:05 |
| pitti | tkamppeter: just commit it for now, the current one should go to -updates first; then we can pile up more fixes | 16:05 |
| tkamppeter | What do you mean with "commit". The changes for Jaunty are already committed to the BZR. Now I mean the upload of the package 1.3.9-2ubuntu8. | 16:07 |
| pitti | tkamppeter: to the intrepid barnch | 16:07 |
| pitti | tkamppeter: lp:~ubuntu-core-dev/cups/intrepid/ | 16:08 |
| tkamppeter | pitti, there I do not have access (core-dev only). Can you take the debdiff from one of the bugs and commit? Thanks/\ | 16:08 |
| pitti | tkamppeter: you can read from it and put your changes to your own branch, then I just need to pull from that | 16:09 |
| pitti | tkamppeter: i. e. "bzr get lp:~ubuntu-core-dev/cups/intrepid/", commit, "bzr push lp:~till-kamppeter/cups/intrepid" | 16:09 |
| Necrosan | cjwatson: ping | 16:30 |
| cjwatson | Necrosan: yes? | 16:31 |
| pitti | tkamppeter: want to join the desktop team meeting? (#ubuntu-desktop) | 16:32 |
| === dholbach_ is now known as dholbach | ||
| apw | tedg, looking at what is in bzr and what is in jaunty i don't think your bzr tree is up to date | 16:34 |
| tedg | apw: :( Someone must have updated it out of tree then. | 16:35 |
| apw | your tree and the changed in the apt-get source seems to diverge at 2.24.0-0ubuntu8, the tip there is ubuntu12 | 16:35 |
| apw | so should i sync that first? | 16:35 |
| apw | sadly there are a few commits there and as there is no real info it may be hard to split them into real commits | 16:35 |
| tedg | apw: Sure, that'd be great. | 16:36 |
| cjwatson | you could fetch the individual revisions of the source package along the way from https://launchpad.net/ubuntu/+source/gnome-power-manager | 16:36 |
| cjwatson | those would probably be good enough as individual commits | 16:36 |
| apw | ok will load the changed up into a branch off 0ubuntu8 ... | 16:36 |
| cjwatson | (not perfect obviously) | 16:36 |
| apw | cjwatson, ahh yes, better than trying to do it manually | 16:36 |
| apw | thanks for that gem | 16:36 |
| cjwatson | james_w also has a 'bzr import-dsc' tool that can automate the import from source packages | 16:37 |
| cjwatson | though it requires slightly careful driving sometimes | 16:37 |
| ScottK | mvo: Compiz is going to need a rebuild against kde 4.2.0 for libplasma changes. I didn't do it with the others, because I thought it best to leave it to someone more focused on the package. The new kde4libs hasn't built yet on lpia, powerpc, ia64, or hppa due to uninstallable build-deps. In other packages I just versioned the libplasma-dev build-dep to 4.2.0 so it wouldn't build against the old one accidentally. | 16:42 |
| Riddell | compiz uses plasma? | 16:43 |
| mvo | ScottK: thanks, I will update the bzr tree and upload it | 16:44 |
| mvo | that is the kde side of compiz :) I have little clue about that | 16:45 |
| ScottK | Riddell: Yeah. Compiz-kde does. | 16:49 |
| ScottK | mvo: I did about a dozen and a half packages last night and today and so far all but one were good as no change rebuilds. | 16:49 |
| mvo | ScottK: excellent, thanks | 16:50 |
| === BenC1 is now known as BenC | ||
| === smarter_ is now known as smarter | ||
| ScottK | cjwatson: I've been following your edits of the archive-reorg spec on the wiki. Is this idea of essentially promoting all MOTU to core-dev something that there is a hard consensus around or do you think it's still up for discussion? | 17:04 |
| cjwatson | it may not be clear from the spec as written, but the current consensus as I understand it is to have a transition process where many MOTU are given full archive access and many are moved into layer-specific teams | 17:05 |
| cjwatson | ScottK: do you have an objection to it? | 17:06 |
| ScottK | cjwatson: It sounded to me from reading the spec like it was all MOTU and automatic. | 17:06 |
| ScottK | cjwatson: That I'd object too. | 17:06 |
| cjwatson | ~[6~[6~that's an error | 17:06 |
| ScottK | OK. | 17:07 |
| cjwatson | (sorry for load-induced garbage) | 17:07 |
| ScottK | No problem. | 17:07 |
| ScottK | I guess i don't understand why we don't keep MOTU as a generalist entry point to deal with all unseeded packages. | 17:07 |
| ScottK | That's essentially what MOTU covers now. | 17:07 |
| * ogra collects the garbage for possible later use | 17:07 | |
| cjwatson | oh, the spec does not call for the disbandment of MOTU | 17:08 |
| ScottK | Well that's another misimpression I have then. | 17:08 |
| cjwatson | it's still clearly useful as a mentoring organisation, particularly for generalists | 17:08 |
| cjwatson | but I don't think it needs to have lower access control than current ubuntu-core-dev in order to achieve that | 17:08 |
| ScottK | Hmmm. | 17:08 |
| cjwatson | in other words, people who only want to work on packages not in any layer are entirely free to continue to do so, and I expect will | 17:09 |
| ScottK | Right, but we generally have expected core-dev to understand more about integration and care for the whole distro. | 17:10 |
| cjwatson | but I don't think that *has* to be the only identity of MOTU; even at the moment it seems to be more than that | 17:10 |
| ScottK | It seems then that we are losing that disctinction then. | 17:10 |
| cjwatson | well, I think that distinction has been blurred over time anyway | 17:10 |
| cjwatson | MOTU's application process involves much more teaching than it used to | 17:10 |
| cjwatson | and we already expect MOTU to exercise a degree of discretion, don't we? | 17:11 |
| ScottK | A degree. | 17:11 |
| === bluesmoke is now known as Amaranth | ||
| cjwatson | I don't think that the boundary between main and universe is anywhere close to the line between "this stuff is fairly isolated" and "this stuff will break the world if you get it wrong" any more | 17:12 |
| cjwatson | which makes it ... well, a bit artificial | 17:12 |
| cjwatson | and maybe it isn't worth trying to enforce that in the same way any more | 17:12 |
| ScottK | Perhaps. | 17:12 |
| pitti | tkamppeter (CC: Keybuk, seb128): Do you see any chance of the printer applet being rewritten in C, or be spawned on demand? it imposes quite a high startup cost when you log into GNOME | 17:13 |
| ScottK | I do think a half-step to general upload rights (i.e. unseeded) is a good idea. | 17:13 |
| ScottK | I'm less concerned about what we call it. | 17:13 |
| pitti | jockey does as well, I'll address that in jaunty | 17:13 |
| ion_ | pitti: If you’re going to rewrite jockey in C, you might find the code in hardware-connected useful. | 17:13 |
| cjwatson | ScottK: my perception is that there are very few packages for which I would be concerned about granting access to most of today's MOTU, given the number of eyeballs on jaunty today and the opportunity for social approaches to mistakes | 17:15 |
| pitti | ion_: no, not that, just don't start it by default each and every time | 17:15 |
| cjwatson | ScottK: I don't think that necessarily means that everyone is obliged to work on everything, any more than today's MOTU necessarily work on everything to which they technically have access | 17:16 |
| ion_ | pitti: Ah | 17:16 |
| cjwatson | and so it's a question of how much time we lose due to the distinction drawn four and a half years ago, when Ubuntu was a much simpler place | 17:16 |
| ScottK | cjwatson: Right, well there's a transition issue to deal with. | 17:17 |
| ScottK | If we conclude that someone is not ready for general acces, but doesn't have a particular focus interest, do they have no upload rights? | 17:17 |
| cjwatson | I'm not sure, but that's a good question | 17:18 |
| cjwatson | ScottK: I've made a FIXME note in the spec | 17:19 |
| ScottK | When I think about the path in the future to core-dev, I can see a specialist working to branch out, but I don't know how a generalist could get limited upload rights to prove themselves in the current plan. | 17:19 |
| ScottK | cjwatson: Thanks. | 17:19 |
| ScottK | At least as I understand it anyway. | 17:20 |
| cjwatson | the original notion of limited rights to universe while we figured out trust issues was based, I think, on the notion that most users would only install packages from main | 17:20 |
| cjwatson | I'm not sure that that's true any more, and so I wonder whether this is actually a good proving groundd | 17:21 |
| cjwatson | -d | 17:21 |
| cjwatson | given that it does offer very direct access to users' systems | 17:21 |
| cjwatson | and hence a level of trust that, in practice, is really not that far off core ... | 17:21 |
| ScottK | I think a slight redefinition covers it then. | 17:23 |
| ScottK | core is packages installed by default and not in packages installed on selected systems. | 17:24 |
| ScottK | I do think we need a route in for generalists. | 17:24 |
| ScottK | If we don't then we've traded one problem for the opposite. | 17:24 |
| cjwatson | thing is, I don't actually think the opposite problem is a problem | 17:25 |
| cjwatson | Debian does not have people wildly uploading rubbish, and to be honest, even though the Debian process is overly lengthy, there are plenty of Debian developers who are fairly amateur | 17:26 |
| cjwatson | (and also of course lots of excellent ones!) | 17:26 |
| ScottK | True. | 17:26 |
| ScottK | But Debian has a tradition of people being focused on specific packages that they get to know well. | 17:26 |
| ScottK | People understand there is a higher threshold for not messing up when you NMU someone elses package. | 17:26 |
| ScottK | That same extra consideration doesn't exist in Ubuntu. | 17:27 |
| cjwatson | "installed by default" is a far too movable feast in Ubuntu | 17:27 |
| cjwatson | I don't think it's something we can base access control on, not to mention that many Ubuntu users have a hit-list of things they install anyway right after installation | 17:28 |
| ScottK | OK. | 17:28 |
| ScottK | I'll just take a step back and say we ought to have a clear path for generalists. | 17:29 |
| cjwatson | so, route in for generalists: what aren't we solving by means of sponsorship, PPAs, branch reviews, and our existing mentoring facilities? | 17:29 |
| ScottK | I guess if you view the entire notion of limited upload rights first as obsolete, nothing. | 17:29 |
| cjwatson | well, I'm exploring | 17:30 |
| cjwatson | not based on the conviction that limited upload rights *are* obsolete, but based on removing the conviction that they're necessary | 17:30 |
| ScottK | OK. | 17:31 |
| apw | tedg, how is one meant to use this bzr checkout of gnome-power ? i had expected d/r patch to make me some source but it does not | 17:32 |
| ScottK | Taking that one step further then, if you're willing to go straight from no upload rights to full (almost) upload rights for generalists and trust them not to mess where they don't know enough, why have teams and limits at all? | 17:32 |
| ScottK | I'm not sure that the case doesn't apply equally well to specialists. | 17:32 |
| cjwatson | I guess because the process for gaining access to those teams could potentially be simpler and shorter | 17:33 |
| ScottK | just exploring .... | 17:33 |
| tedg | apw: I copy the debian directory in to the source tree cp -a branch/debian gnome-power-manager-2.24.2/ | 17:33 |
| cjwatson | you only have to investigate their specialist abilities, and not so much their ability to cope when thrown something they don't understand | 17:33 |
| ScottK | Perhaps. | 17:33 |
| apw | tedg, hmmm ok | 17:33 |
| apw | this bzr integration really isn't that smooth is it | 17:34 |
| ScottK | OTOH, if I'm a server guy working on a server app not seeded, I don't need access to upload everything. | 17:34 |
| cjwatson | apw: once we deploy bzr across the board, we will not be using this scheme where the branch doesn't come with all the source | 17:34 |
| tedg | apw: Well, yes and no. If you use the package-import.u.c stuff you get everything directly, but then there's no separation between upstream VCS, upstream tarball, and the ubuntu package. | 17:35 |
| cjwatson | apw: we'll just be putting all the upstream source in the branch | 17:35 |
| apw | i would have expected this branch to be a branch off your upstream branch, and as a result have the source | 17:35 |
| apw | but no matter, if thats how it works, its how it works | 17:35 |
| cjwatson | that's how the new world order will work | 17:35 |
| apw | just not at allll obvious | 17:35 |
| seb128 | if you don't have very fast internet access bad luck for you | 17:36 |
| cjwatson | the only downside is performance, but that's outweighed by avoiding all the setup problems | 17:36 |
| * tedg is still resisting the new world order | 17:36 | |
| cjwatson | seb128: I'm on a 512KB link (at best, often much slower) *shrug* | 17:36 |
| cjwatson | so don't talk to me about slow links :) | 17:36 |
| cjwatson | err, I mean 512kilobits | 17:36 |
| cjwatson | it was 100 kilobits for a while there | 17:36 |
| seb128 | cjwatson: which means getting a non trivial source is going to take a while compared to apt-get | 17:37 |
| cjwatson | I'm not a fast-link fascist, I'm a make-the-tools-not-suck fascist | 17:37 |
| cjwatson | seb128: I'd gladly trade that for the time spent helping people battle with the tools and being turned off Ubuntu development as a result | 17:38 |
| ScottK | cjwatson: Thanks for the discussion. I'll sit back and see how the spec evolves .... | 17:38 |
| cjwatson | not to mention the time spent battling with the tools myself | 17:38 |
| seb128 | cjwatson: apt-get source, change, dput is not that much battle, for me it's using bzr which is the battle ... but let's see how it goes when we have an established workflow | 17:39 |
| cjwatson | for non-trivial source packages, it's going to take a while to test-build anyway and after the initial pull everything is much faster thereafter; and I can always go and get a cup of coffee | 17:39 |
| cjwatson | apt-get source, fiddle about to put debian/ into the right place, test-build, curse when I discover there are some files missing from the checkout, etc. | 17:39 |
| cjwatson | I wouldn't say it was a battle if it weren't for me, every time I try to work with a package that isn't full-source | 17:39 |
| seb128 | I don't mean the debian directory in bzr, I mean what we have now when not using bzr ;-) | 17:39 |
| cjwatson | ah | 17:40 |
| seb128 | I just find work harder to do every time I've to change a package in bzr | 17:40 |
| cjwatson | personally I'd like to explore putting .bzr in the source package to resolve that problem, perhaps using dpkg-source v3 | 17:40 |
| seb128 | that would be nice | 17:40 |
| seb128 | once of the issue right now is that we don't have standard locations | 17:41 |
| cjwatson | James' work is solving that | 17:41 |
| cjwatson | once we get the necessary LP facilities | 17:41 |
| seb128 | ie, you apt-get source, get a bzr get command to use, use it, ran bzr commit and bzr push and you get an error saying you need a location | 17:41 |
| seb128 | which is usually where I get stucked and ask mvo for help to figure what location to use ;-) | 17:41 |
| cjwatson | we'll be able to run 'bzr checkout lp:ubuntu/+trunk/packagename' or similar | 17:41 |
| cjwatson | same schema for everything | 17:42 |
| ScottK | seb128: I recently learned about bzr push :parent. | 17:42 |
| ScottK | That pushes it back where you got it from. | 17:42 |
| cjwatson | 'bzr push' without arguments does that if you only just did 'bzr get' | 17:42 |
| seb128 | cjwatson: no it doesn't | 17:42 |
| seb128 | not when using get, maybe when using checkout or mirror or something else | 17:43 |
| seb128 | I know some are alias for others but I usually use get which is what apt-get source suggest and get stucked | 17:43 |
| seb128 | btw speaking about bzr | 17:44 |
| cjwatson | hmm, ok, I thought it did | 17:44 |
| cjwatson | I always use checkout if I possibly can | 17:44 |
| seb128 | why does running "bzr get lp:~mvo/+junk/compact-dpkg-status" wants me to enter my ssh passphrase and how do I tell it I just want an anonymous checkout? | 17:44 |
| cjwatson | don't you run an ssh agent? | 17:45 |
| seb128 | I do | 17:45 |
| seb128 | but I would expect that to not use http to do the checkout | 17:45 |
| seb128 | -not | 17:45 |
| cjwatson | lp always uses bzr+ssh or sftp; I think bzr+ssh is actually faster than http for checkout, although I could be wrong and haven't timed it recently | 17:46 |
| seb128 | hum, ok | 17:46 |
| cjwatson | at any rate I'd expect it to be potentially faster since it's using a customised protocol | 17:46 |
| cjwatson | obviously there are the extra round-trips for auth but that should be dominated by large branches | 17:47 |
| cjwatson | seems pretty similar here for lp:~ubuntu-desktop/vte/ubuntu vs. http://bazaar.launchpad.net/~ubuntu-desktop/vte/ubuntu, though | 17:47 |
| cjwatson | at any rate, it would be possible to add that feature but it would require modifying the bzr launchpad plugin | 17:48 |
| seb128 | that's not really an issue, I was just curious about why the ssh key was used I though http was used for checkouts | 17:49 |
| seb128 | ah | 17:49 |
| seb128 | apt-get source suggests "bzr get http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main" | 17:49 |
| seb128 | that might be why push doesn't work | 17:49 |
| seb128 | it's suggesting the http url | 17:49 |
| cjwatson | that's entirely dependent on what's in debian/control | 17:50 |
| cjwatson | you can use debcheckout -a <package>, which always gives you an authenticated checkout if it can | 17:51 |
| cjwatson | which means you have the best of both worlds - a URL in debian/control that you can paste into a web browser, and an easy way to get an authenticated checkout if you want | 17:51 |
| seb128 | right | 17:51 |
| seb128 | I guess most of my issues using bzr is just that I'm not really used to this worklow and we don't really have one consistant way to do things | 17:52 |
| cjwatson | I agree that the inconsistency is a pain | 17:52 |
| cjwatson | from my POV, the things that are inconsistent from what I'm used to are a pain, of course, so I will express annoyance at different things | 17:52 |
| cjwatson | e.g. I swear out loud pretty much every time I have to deal with anything called 90_autoreconf.patch :-) | 17:53 |
| seb128 | ;-) | 17:53 |
| seb128 | I'm pondering changing those to run autotools are build time | 17:53 |
| seb128 | but I'm not sure that would be better, that leads to another class of issues | 17:53 |
| seb128 | ie, things stop working when a new libtool gets uploaded and ftbfs | 17:54 |
| seb128 | hum, bzr is still slooow | 17:54 |
| seb128 | apt-get source update-manager -> 23 seconds | 17:55 |
| seb128 | bzr -> 6 minutes 22 seconds | 17:56 |
| cjwatson | james_w: this all reminds me, should we make debuild -S run bzr bd -S if appropriate (.bzr-builddeb exists, plugin available)? | 17:57 |
| cjwatson | that's one irregularity in my workflow at the moment | 17:57 |
| apw | tedg, ok i have pulled in all of the changes that have been applied to gnome power via direct uploads, and pushed them as a branch and proposed it for merge: https://code.launchpad.net/~apw/gnome-power/incorporate-direct-uploads/+merge/3160 | 17:57 |
| seb128 | ie, 16 times slower | 17:57 |
| apw | tedg, i would note that you have rebased to a newer upstream since this branch was made so the merge will be hairy | 17:57 |
| cjwatson | bzr is certainly never going to be even close to as fast as apt-get source for me, since I have a local mirror of the latter; but I don't usually find that it gets in my way that much, I can always go and triage a few more bugs or something | 17:58 |
| seb128 | well, I know I find the 7-8 minutes to get gtk to be a while already | 17:59 |
| seb128 | but it would take over an hour using bzr | 17:59 |
| cjwatson | how many people bzr get gtk when they don't work on it regularly though? | 17:59 |
| Keybuk | seb128: provided you've done the switch to libtool 2.2 you should be fine | 17:59 |
| Keybuk | the whole reason I pushed hard to get to 2.2 was that libtool 1.5 was the last of the tools that didn't believe in upgradability | 18:00 |
| seb128 | Keybuk: I'm not, I still downgrade to libtool 1.5 to autoreconf gtk because otherwise it doesn't build | 18:00 |
| Keybuk | autoconf 2.6x, automake 1.6+, libtool 2.2 and gettext all should upgrade gracefully | 18:00 |
| cjwatson | seb128: re autoreconf.patch, I think the main thing that causes me problems is that often they aren't actually autoreconf, and don't describe the command you need to run to update them in the patch | 18:00 |
| cjwatson | so I run autoreconf -iv and get an enormous diff from hell | 18:00 |
| seb128 | cjwatson: we often have autoconf changes which are just an autoconf run to update configure due to lpi changes | 18:01 |
| cjwatson | (sometimes just because diff hunks are in a different order or something, but it's pretty hard to tell) | 18:01 |
| cjwatson | seb128: right, but they usually don't say that in the patch so how am I supposed to know :( | 18:01 |
| seb128 | otherwise we used to run aclocal, autoconf, automake, etc in order but we learnt to use autoreconf recently and use that now ;-) | 18:01 |
| Keybuk | seb128: you shouldn't _have_ to run autoreconf for those ;) | 18:01 |
| Keybuk | just build-depend on autoconf | 18:01 |
| seb128 | cjwatson: yeah, we should document the patches | 18:02 |
| seb128 | the naming gives an hint, autoconf against autoreconf | 18:02 |
| james_w | cjwatson: we could. I'm not sure it's worth the "wtf?" for those who don't really realise what's going on though. | 18:02 |
| james_w | cjwatson: and the two tools aren't completely command-line compatible. | 18:03 |
| seb128 | Keybuk: well, what I said before, I'm considering changing that but I'm not convinced by running autotools at build time, that can lead to surprises | 18:03 |
| james_w | cjwatson: is it just that you are used to typing "debuild -S", or something else? | 18:03 |
| cjwatson | james_w: yes | 18:03 |
| cjwatson | (the former) | 18:03 |
| cjwatson | oh, also, I think that in general devscripts should be able to do the right thing across the board | 18:05 |
| seb128 | Keybuk: where autotools patches made with a known to work version are using not an issue ;-) | 18:05 |
| Keybuk | seb128: if it leads to surprises, I promise to investigate and fix any autotools bugs I find | 18:05 |
| cjwatson | which seems to suggest that if it sees a tree containing .bzr-builddeb it should build it appropriate | 18:05 |
| cjwatson | ly | 18:05 |
| james_w | cjwatson: I don't think we can guarantee that, so it's a tricky path to start down | 18:05 |
| cjwatson | I like the idea of devscripts as unifying wrapper scripts, which by and large they are | 18:05 |
| seb128 | Keybuk: ok good to know, the issues are usually not autotools though bug configure doing stupids things which used to work but are not documented and stop working in some new version | 18:05 |
| cjwatson | it could even refuse to build something containing .bzr-builddeb and tell you what to do, although that wouldn't be optimal | 18:05 |
| seb128 | bug configure -> but configures | 18:05 |
| Keybuk | seb128: true, but I've found that most software is quite easy to fix | 18:05 |
| cjwatson | the problem I have is finger macros that do debuild -S and then I find some cruft in the debdiff and have to rebuild | 18:05 |
| Keybuk | admittedly, sometimes you have to repackage the tarball :-/ | 18:05 |
| seb128 | Keybuk: the "m4_ifdef([LT_OUTPUT], [LT_OUTPUT])" trick you gave me the other time seems to be usually a good way to fix issues | 18:07 |
| * Keybuk can't remember what that one was for ;) | 18:07 | |
| seb128 | gtk has still something which it doesn't like in libtool2 though, I need to investigate, I might ping you back about it | 18:07 |
| seb128 | I still downgrade to libtool 1.5 to relibtoolize this one for now | 18:08 |
| Keybuk | ohhh | 18:10 |
| Keybuk | I remember | 18:10 |
| Keybuk | that was extraordinarily cunning of me ;) | 18:10 |
| cody-somerville | lol | 18:12 |
| Keybuk | not only will that make libtool 2.2 generally work like 1.5 with its early libtool generation, | 18:13 |
| Keybuk | but it will still work if someone uses libtool 1.5, | 18:13 |
| Keybuk | *and* if someone has both, it'll make them use 2.2 | 18:14 |
| Keybuk | I deserve some kind of award for that one <g> | 18:14 |
| liw | hmm. I'm renaming package foo to bar. foo has a state file I need to copy to the new location in bar. bar Conflicts and Replaces foo. shouldn't bar's prerm script be called by dpkg during the upgrade? | 18:14 |
| cjwatson | why would bar's prerm script be called, rather than foo's? | 18:17 |
| cjwatson | at no point in this procedure is bar removed ... | 18:17 |
| cjwatson | (or even an old version of bar "removed" in order to unpack a new one) | 18:18 |
| liw | that's what I thought Debian Policy 6.6, point 3, subpoint 3 says (http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html) | 18:18 |
| cjwatson | are we looking at the same point? | 18:19 |
| cjwatson | "Otherwise (i.e., the package was completely purged): " | 18:19 |
| liw | "Conflictor's-prerm remove in-favour package new-version" | 18:20 |
| cjwatson | do you mean point 2 subpoint 3? | 18:20 |
| liw | er, point 2, subpoint 3 | 18:20 |
| cjwatson | ah. that's talking about the package being removed, not the package being installed. the term "conflictor" is a bit confusing. | 18:20 |
| cjwatson | but the ambiguity is cleared up at the top of that point, I think ('If a "conflicting" package is being removed at the same time ...') | 18:21 |
| liw | ok, so I don't need to (rather, can't) do anything in bar's prerm | 18:21 |
| cjwatson | does foo remove its state file on remove, rather than on purge? | 18:22 |
| liw | only on purge | 18:23 |
| cjwatson | you can probably retrieve it in bar's preinst then | 18:23 |
| ScottK | cjwatson: WRT bar and debuild, it seems to me that changinging what it's done into something different would be a suprise. Wouldn't it be better to just have a different command for doing it the bzr way, that way the finger macros don't get tempted? | 18:23 |
| cjwatson | I say "probably" because if the user told their package manager to purge foo at the same time, I don't think the ordering of foo purge vs. bar unpack is defined | 18:24 |
| cjwatson | ScottK: well, at least in the (simple) cases I've encountered, the only effective difference is to exclude .bzr-builddeb from the source package | 18:24 |
| cjwatson | ScottK: but debuild is *supposed* to be a clever wrapper that figures out what to do and does the right thing | 18:24 |
| liw | cjwatson, in this case I'm happy enough with a best-case effort to save the file in question, so that's OK | 18:25 |
| ScottK | OK. | 18:25 |
| cjwatson | ScottK: the surprise, for me, is when it doesn't :-) | 18:25 |
| cjwatson | if I wanted a stupid tool I'd just use dpkg-buildpackage | 18:25 |
| ScottK | As long as we preserve the non-bzr case to work correctly, I'm happy. | 18:25 |
| ScottK | Right. ;-) | 18:25 |
| * pochu feels stupid - I use dpkg-buildpackage a lot ;) | 18:25 | |
| cody-somerville | ScottK, bzr merge makes doing merges from Debian super easy | 18:26 |
| cody-somerville | ScottK, Have you tried it? | 18:26 |
| ScottK | cody-somerville: I haven't. | 18:26 |
| ScottK | I don't generally have a lot of trouble with the output of MoM/DaD. | 18:26 |
| cjwatson | pochu: stupid tool doesn't imply stupid user/developer :-) | 18:27 |
| cody-somerville | ScottK, its nice when there is no output of MoM or DaD | 18:28 |
| cody-somerville | ScottK, ie. new upstream releases that are in Debian SVN but not uploaded because Debian is frozen | 18:28 |
| [swb] | hey guys, wondered if anyone would be interested in trying to reproduce a bug in gnome panel behaviour for me | 18:33 |
| [swb] | its pretty annoying | 18:33 |
| ScottK | [swb]: #ubuntu-bugs is probably a better channel for that. | 18:34 |
| [swb] | ahh ok | 18:34 |
| iulian | [swb]: You might want to file a bug as well. | 18:35 |
| === calc_ is now known as calc | ||
| Necrosan | cjwatson: doh,still around? | 18:45 |
| cjwatson | Necrosan: yes? | 18:49 |
| Necrosan | ill paste log of aptitude | 18:55 |
| didrocks | cjwatson: thanks for the sponsorship :) | 18:58 |
| === warp10_ is now known as warp10 | ||
| === DktrKranz2 is now known as DktrKranz | ||
| Roby | save the pervs! http://www.ihateyounatalie.com/?id=1175538 | 19:54 |
| iulian | Eh? | 19:55 |
| cjwatson | coo, I didn't know the XFS lots-of-NULs bug had been fixed | 19:59 |
| cjwatson | http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F | 19:59 |
| cjwatson | good news for anyone trying to use apt on it, I guess ;-) | 19:59 |
| ion_ | Oh, neat. | 20:02 |
| directhex | hmph, mere mortals aren't meant to get neat features from XFS. that's what SGI support contracts are for! | 20:06 |
| slangasek | cjwatson: wow, they're just getting rid of all of XFS's distinguishing features these days, aren't they? :) | 20:09 |
| lfaraone | Hi, are we going to have gnome 2.26 in jaunty? | 20:10 |
| cjwatson | I would assume so since Ubuntu releases always come with the newest version of GNOME | 20:11 |
| lfaraone | cjwatson: ok, so when will .26 prerel packages start shipping in Jaunty? (before FF I hope, I have packages which depend on bindings there) | 20:12 |
| pochu | lfaraone: they are already in the archive | 20:18 |
| pochu | 2.25.5 mostly | 20:18 |
| lfaraone | pochu: the spesific package I'm eyeing is http://packages.ubuntu.com/jaunty/python-gnome2-desktop | 20:21 |
| lfaraone | pochu: "Package: python-gnome2-desktop (2.24.1-0ubuntu1) " | 20:21 |
| seb128 | lfaraone: what is the question exactly? I just joined the channel | 20:23 |
| lfaraone | seb128: When is the python-gnome2-desktop containing the sugar evince bindings (which are shipping in 2.26, or so upstream sugar tells me) going to land in Jaunty? (well before FF I hope) | 20:24 |
| seb128 | lfaraone: when upstream roll a tarball which has the code changes | 20:25 |
| lfaraone | seb128: ok, arn't .25 tarballs already out for tyhat package? | 20:26 |
| seb128 | lfaraone: there is a 2.25.1 which has no interesting changes (ie a waf build system update, a small fix and a configure option bugfix) | 20:26 |
| lfaraone | seb128: kk, understood. | 20:27 |
| Chipzz | waf - because auto* doesn't work | 20:27 |
| Chipzz | </sarcasm> | 20:27 |
| * Chipzz sighs | 20:27 | |
| Amaranth | cmake - because auto* is slow :) | 20:28 |
| Chipzz | Amaranth: nuke libtool if you don't want slow | 20:29 |
| Chipzz | or annoying and pointless .la files | 20:29 |
| Amaranth | Chipzz: If I could figure out how | 20:29 |
| Amaranth | I've given up on understanding that system, I just copy/paste from other people :P | 20:30 |
| Chipzz | I was not saying auto* was easy :) | 20:30 |
| Chipzz | it does, however, get a lot of stuff right that I doubt other systems do | 20:30 |
| Chipzz | I wonder how many of the alternatives to auto* can do out-of-tree building | 20:31 |
| Amaranth | Chipzz: That's all cmake can do | 20:37 |
| superm1 | slangasek, i've cleaned up most of hotkey-setup and moved things into hal-info (in Ubuntu and submitted upstream). I forget what the contingency plan was for thinkpad stuff though, so i'll leave that bit to you thinkpad owners okay? | 20:37 |
| slangasek | superm1: hrm, I was still working on getting a bzr repo set up so that we'd have fine-grained regression tracking | 20:41 |
| slangasek | superm1: I don't suppose you did something like that while cleaning it up? :) | 20:42 |
| superm1 | slangasek, no... can't say I did. I hand checked each of the lines to make sure they were in an FDI file | 20:42 |
| slangasek | ok | 20:42 |
| slangasek | so what's left in the new hotkey-setup package - ibm.hk and thinkpad-keys.c? | 20:43 |
| slangasek | and lenovo.hk | 20:43 |
| superm1 | slangasek, that and a call to set DOS on Intel or AMD /proc/acpid/video/VID* to 7 (enable keys) | 20:43 |
| * lfaraone pokes GNOME with a sharp stick. | 20:44 | |
| slangasek | superm1: alrighty | 20:44 |
| lfaraone | seb128: any chance I could get you to include some SVN'd patches that arn't yet tarballed? :P | 20:44 |
| superm1 | slangasek, i'm not sure why that needs to be done in an init script though about enabling hotkeys for video switching. would probably make more sense to just set the kernel to default to them enabled | 20:44 |
| slangasek | superm1: probably; but twiddling in an init script is a lot more lightweight than getting a kernel patch accepted upstream, so I guess it was meant to be a stopgap and was never followed up | 20:45 |
| superm1 | slangasek, yeah probably in that case | 20:46 |
| seb128 | lfaraone: that can always be done but that doesn't seem to be anything really useful in an unstable distribution where nothing uses the new code yet | 20:50 |
| seb128 | lfaraone: next tarballs are due monday I would rather wait for them to roll a tarball | 20:50 |
| lfaraone | seb128: well, we _would_ be using it if we could upload the package. | 20:50 |
| seb128 | lfaraone: we being? | 20:51 |
| lfaraone | seb128: but we can't do that until evince is up to date. | 20:51 |
| lfaraone | seb128: ubuntu-sugarteam. | 20:51 |
| seb128 | lfaraone: you are welcome to work on the change and request sponsoring | 20:51 |
| slangasek | bryce: huh, does bug #217908 really affect 8 different source packages? | 20:51 |
| ubottu | Launchpad bug 217908 in xserver-xorg-video-openchrome "Images in Firefox and Opera are extremely pixeled when zoomed" [Undecided,Confirmed] https://launchpad.net/bugs/217908 | 20:51 |
| seb128 | lfaraone: the ubuntu desktop team is already overworked so we will not take on extra work only to backport something a few days before a new tarball | 20:52 |
| bryce | slangasek: yuck | 20:52 |
| lfaraone | seb128: ok, sorry. | 20:52 |
| mathiaz | slangasek: are aware of bug 321689 - which is a result of having -proposed packages in 8.04.2 -server isos? | 20:52 |
| ubottu | Launchpad bug 321689 in openldap2.3 "openldap (slapd) installation fails" [Undecided,Confirmed] https://launchpad.net/bugs/321689 | 20:52 |
| slangasek | mathiaz: yes, the openldap2.3 SRU has just been pushed in response | 20:53 |
| seb128 | lfaraone: nothing to be sorry about I'm just telling you I'm not interested to work on the change now but I'm happy to review work if you want to work on it an request sponsoring | 20:53 |
| seb128 | lfaraone: otherwise wait a week or so for the update | 20:53 |
| mathiaz | slangasek: ok. that should fix the problem for openldap. | 20:54 |
| mathiaz | slangasek: are we respinning the isos? | 20:54 |
| slangasek | mathiaz: no, we're trying to get all the SRUs that crept on from -proposed validated and pushed out instead | 20:55 |
| mathiaz | slangasek: ok. | 20:55 |
| bryce | slangasek: yeah someone went package crazy there | 20:55 |
| slangasek | since that's something that needs to happen anyway, and rolling new ISOs won't roll back the installs that are already in the wild | 20:55 |
| slangasek | bryce: yes, yes they did :-) | 20:56 |
| bryce | slangasek: guessing they suspected it to be an X problem but didn't figure out which package, so just shotgunned a bunch of X packages | 21:02 |
| slangasek | bryce: and then someone marked the bug 'confirmed' on half of them? :) | 21:02 |
| bryce | can I blame my scripts? ;-) | 21:03 |
| slangasek | sure :) | 21:03 |
| bryce | slangasek: wow this is an interesting bug | 21:27 |
| bryce | slangasek: okaaay, I think I got it | 21:35 |
| bryce | slangasek: in this case it probably is alright for this to be open against all these drivers | 21:35 |
| bryce | the issue is that there needs to be a repeat mode implemented in each of the video drivers to display images correctly | 21:36 |
| bryce | currently they say they support it, but they don't do so properly, which confuses higher level things like cairo | 21:37 |
| slangasek | bryce: ah - so should the bug against cairo and xulrunner be closed...? | 21:37 |
| bryce | anyway, it looks like Thomas Jaeger has this bug pretty well under control, I don't think we need to tweak it | 21:37 |
| bryce | slangasek: I think we can leave it as is; those will also need to be touched once the drivers are fixed up | 21:37 |
| slangasek | bryce: darn. :) ok, what should I do with the jaunty nomination - is this a realistic target for jaunty? | 21:38 |
| bryce | it makes for a messy bug, but it's a messy problem, and it seems people are making the best of it | 21:38 |
| bryce | I think it is realistic; already Tom posted one patch, it sounds like he plans to get patches done for each driver, and then we can switch cairo | 21:39 |
| bryce | hmm | 21:40 |
| bryce | it probably doesn't really matter to have jaunty nominations for all of this | 21:40 |
| bryce | and the hardy nominations are probably right out... this doesn't feel like a viable sru thing; it requires twiddling too many different packages | 21:40 |
| slangasek | well, I'd like to either approve or decline the nomination, and that applies to all packages with an open task - we can 'wontfix' any that aren't jaunty targets afterwards if necessary | 21:41 |
| bryce | slangasek: I'd say decline them all. | 21:41 |
| bryce | progress can just be tracked with the regular non-targeted tasks | 21:41 |
| bryce | most of these are obscure drivers anyway, who cares about -i128 :-) | 21:42 |
| bryce | s/most/several/ | 21:42 |
| slangasek | bryce: done, thanks | 21:46 |
| bryce | I'll update the description too | 21:48 |
| slangasek | did jaunty change something wrt touchpad handling? | 21:49 |
| slangasek | my laptop's left mouse button has gone batshit suddenly; not sure if it's hardware or software | 21:50 |
| slangasek | only the one on the touchpad is affected, the nipple-complementing one works fine | 21:51 |
| bryce | lots of fixes have gone into input stuff, and we did just put in a new xserver recently, so I'd guess it's software more likely | 21:51 |
| slangasek | doh | 21:51 |
| bryce | heh, you'd be more happy if it were hardware, eh? ;-) | 21:51 |
| slangasek | not really, but at least then it would just be me :) | 21:52 |
| bryce | booting an intrepid livecd and seeing if it can be reproduced would probably help rule in or out the recent changes (assuming you can reproduce it reliably boot-to-boot currently) | 21:54 |
| slangasek | I haven't yet rebooted since noticing the problem; part of my ongoing love for gnome session saving | 21:55 |
| === bluesmoke_ is now known as Amaranth | ||
| ebroder | ScottK: have you had a chance to look at #321763 yet? | 22:14 |
| === nhandler_ is now known as nhandler | ||
| slangasek | seb128: sent a follow-up to bug #267018; I'm wondering why you thought it was fixed in jaunty, maybe it would help to talk through this in realtime? | 22:37 |
| ubottu | Launchpad bug 267018 in gnome-settings-daemon "regression: g-s-d no longer handles Fn+F7 as xrandr --auto" [Low,Confirmed] https://launchpad.net/bugs/267018 | 22:37 |
| seb128 | slangasek: because the gnome-settings-daemon 2.25.3 NEWS lists an add support for fn-f7 keys in the list of changes | 22:39 |
| slangasek | hmm | 22:40 |
| slangasek | seb128: I don't know what that refers to, but the default keybinding for the xrandr plugin is still wrong | 22:40 |
| slangasek | AFAICS it should be 'XF86Display', not 0xdc or whatever | 22:40 |
| seb128 | slangasek: http://svn.gnome.org/viewvc/gnome-settings-daemon?view=revision&revision=622 | 22:41 |
| slangasek | seb128: well, I think that's unrelated to this bug, though maybe it's related to the bug I'm about to file regarding a regression in the behavior of the xrandr plugin | 22:42 |
| seb128 | wh | 22:43 |
| seb128 | which one? | 22:43 |
| seb128 | slangasek: try desactiving the xrandr keybinding, that's an ubuntu patch and it might be hijacking the new upstream option | 22:45 |
| seb128 | ups | 22:45 |
| seb128 | slangasek: wait | 22:45 |
| seb128 | slangasek: http://bugzilla.gnome.org/show_bug.cgi?id=568713 | 22:45 |
| slangasek | seb128: now when I press XF86Display in jaunty, video comes up on the external monitor, with the same resolution as the LCD instead of with the preferred resolution as shown by xrandr | 22:45 |
| ubottu | Error: Could not parse XML returned by Gnome: timed out (http://bugzilla.gnome.org/xml.cgi?id=568713) | 22:46 |
| seb128 | http://bugzilla.gnome.org/show_bug.cgi?id=568713 | 22:46 |
| ubottu | Error: Could not parse XML returned by Gnome: timed out (http://bugzilla.gnome.org/xml.cgi?id=568713) | 22:46 |
| seb128 | stupid bugzilla is being slow again apparently | 22:46 |
| seb128 | slangasek: ok so the keybinding does something? | 22:46 |
| slangasek | seb128: if I set the keybinding to XF86Display, it does something that's wrong and a regression from intrepid | 22:47 |
| slangasek | if I delete the override of the keybinding, it does nothing | 22:47 |
| slangasek | I think I've /also/ seen 568713, but that's a separate bug | 22:47 |
| seb128 | slangasek: the patch makes the keybinding call xrandr --auto | 22:47 |
| slangasek | that's a patch that's in the Ubuntu package? | 22:48 |
| seb128 | slangasek: apt-get source gnome-settings-daemon and look to 19_extra_keybindings.patch | 22:48 |
| seb128 | yes | 22:48 |
| slangasek | the behavior of g-s-d does *not* match the behavior of xrandr --auto | 22:48 |
| seb128 | what upstream does seems to be activating the clone mode when using the keybinding | 22:48 |
| ion_ | What key is XF86Display? | 22:49 |
| slangasek | ion_: whichever key the input layer says it is | 22:50 |
| slangasek | on thinkpads, Fn+F7 | 22:50 |
| ion_ | I mean typically. Ah, that one. | 22:50 |
| slangasek | seb128: strange; the behavior of g-s-d definitely doesn't match the behavior of xrandr --auto | 22:51 |
| seb128 | slangasek: maybe the upstream code triggers first but that's weird that disabling the keybinding would stop the action then | 22:52 |
| slangasek | how is the upstream code triggered? | 22:53 |
| slgce | where do i find su source code? til now i just found sudo ones | 22:54 |
| seb128 | slangasek: I'm looking to that, I would say that gnome-settings-daemon listen for key events | 22:55 |
| slangasek | slgce: su is part of the 'login' package. | 22:56 |
| slangasek | seb128: bug #322111 filed for this | 22:56 |
| ubottu | Launchpad bug 322111 in gnome-settings-daemon "gnome-settings-daemon xrandr plugin gets wrong resolution on external monitor" [Undecided,New] https://launchpad.net/bugs/322111 | 22:56 |
| slgce | slangasek, thank you, I'll take a look right now | 22:56 |
| seb128 | slangasek: http://svn.gnome.org/viewvc/gnome-settings-daemon/trunk/plugins/xrandr/gsd-xrandr-manager.c?view=markup&pathrev=622 | 22:57 |
| seb128 | gsd_xrandr_manager_init () | 22:57 |
| seb128 | guint keyval = gdk_keyval_from_name (VIDEO_KEYSYM); | 22:57 |
| seb128 | where | 22:57 |
| seb128 | #define VIDEO_KEYSYM "XF86Display" | 22:57 |
| slangasek | seb128: hmm, ok | 22:57 |
| seb128 | slangasek: doing fn-f7 on my laptop crashes g-s-d which seems to indicate that I run into the bug indicated before | 22:59 |
| slangasek | yeah, I can trigger that bug too by pressing Fn+F7 repeatedly :) | 23:00 |
| seb128 | ok, which means the upstream code get called | 23:00 |
| slangasek | sure | 23:00 |
| slangasek | but, if I disable the gconf keybinding, whatever that upstream code does has no effect here | 23:00 |
| seb128 | that's because it crashes ;-) | 23:01 |
| seb128 | ah, if you disable it | 23:01 |
| seb128 | that's weird | 23:01 |
| seb128 | why would that impact on the upstream code | 23:01 |
| slangasek | no, I know when g-s-d crashes or not, I can tell by the color of my window borders. :) | 23:01 |
| slangasek | perhaps what's happening is that xrandr --auto is being called first, and *then* the upstream code runs and screws up the resolution of the external monitor? | 23:02 |
| slangasek | but the upstream code by itself fails to ever do anything to bring up the external monitor? | 23:02 |
| seb128 | that could be | 23:02 |
| seb128 | I'll upload a version which drops the ubuntu change and include the svn fix tomorrow | 23:02 |
| seb128 | so we will have a better idea of what the upstream code do | 23:03 |
| slangasek | seb128: well, in a quick reading of the upstream code, it says that it's meant to cycle through "profiles" - so where would I define these profiles? | 23:04 |
| slangasek | that's something new, that doesn't seem to be connected to the existing configuration tools | 23:04 |
| seb128 | slangasek: http://svn.gnome.org/viewvc/gnome-settings-daemon/trunk/plugins/xrandr/gsd-xrandr-manager.c?view=markup&pathrev=622 look to generate_fn_f7_configs (GsdXrandrManager *mgr) | 23:05 |
| seb128 | slangasek: it does xinerama, clone, etc configs there | 23:05 |
| slangasek | hmm | 23:06 |
| slangasek | so maybe it's just crashing before it gets to the profile that does what I want | 23:06 |
| seb128 | right | 23:06 |
| seb128 | there is no hurry and I was about to go to bed but I will look at it tomorrow | 23:07 |
| seb128 | feel free to backport the svn fix and drop the patch and upload if you want to do that now | 23:07 |
| slangasek | yes, don't let me keep you - good night! | 23:07 |
| seb128 | otherwise wait for the update tomorrow | 23:07 |
| slangasek | ok, I'll test that here if I get a chance | 23:07 |
| seb128 | thanks and good evening to you ;-) | 23:07 |
| === sabdfl1 is now known as sabdfl | ||
| ScottK | ebroder: Not yet. On my list for tonight. | 23:36 |
| ebroder | Great. Let me know if you need anything | 23:36 |
| junyer | hi | 23:40 |
| junyer | i'm looking for anyone who might deal with the autofs and autofs5 packages | 23:41 |
| junyer | (mostly concerning the autofs v4 EOL) | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
