| jbebel | Did the amd64 partman-base fail to build? It didn't show up in the pool. | 00:45 |
|---|---|---|
| === sconklin is now known as sconklin-away | ||
| cr3 | anyone happen to be running lucid desktop in virtual box? I'd really appreciate having the output of a command from that environment | 01:18 |
| jbebel | cr3, I have a lucid desktop in vbox. | 01:31 |
| cr3 | jbebel: awesome! could you send me the output from running the command /usr/share/checkbox/scripts/udev_resource? | 01:41 |
| jbebel | cr3, http://paste.ubuntu.com/406265/ | 01:47 |
| cr3 | jbebel: excellent, that confirms a bug reported. can you also pastebin the output of: ls /sys/devices/virtual/dmi/id | 01:52 |
| jbebel | cr3, http://paste.ubuntu.com/406267/ | 01:54 |
| cr3 | jbebel: would you mind if I asked you to make a modification to /usr/share/checkbox/scripts/udev_resource and try again? | 02:09 |
| jbebel | Sure | 02:09 |
| cr3 | jbebel: simply replace line 392 with: type = int(self._attributes.get("chassis_type", "0")) | 02:10 |
| cr3 | jbebel: then, try running again and let me know if you still get an exception | 02:11 |
| jbebel | No exception | 02:12 |
| cr3 | jbebel: awesome! I'll submit that fix | 02:12 |
| nixternal | Hobbsee: 20:27:44 [ nixternal] I miss hobbsee - we need you back :~( | 02:28 |
| === samferry is now known as sam_ | ||
| === sam_ is now known as samferry | ||
| ScottK | +1 for Hobbsee's return. | 03:20 |
| lifeless | she's gone? | 03:24 |
| ajmitch | just a bit inactive, I thought | 03:29 |
| ScottK | Quite a bit. | 03:31 |
| === \vish is now known as vish | ||
| === ArneGoet1e is now known as ArneGoetje | ||
| AlTheKiller | Hi, is there a quick way to determine what configure flags were used to build a package? | 04:29 |
| hdon | hi all. i am having a problem building a release version of Go on Ubuntu Karmic: http://pastebin.mozilla.org/711474 | 05:15 |
| hdon | it looks like /usr/include/gnu/stubs.h are trying to include "gnu/stubs-32.h" and not finding it | 05:15 |
| nixternal | slangasek: for that bug 551290 - that means I need to lame out the theme right? can't use no good colors | 07:02 |
| ubottu | Launchpad bug 551290 in kubuntu-default-settings "[lucid] Kubuntu theme on nvidia card too ugly" [High,Triaged] https://launchpad.net/bugs/551290 | 07:02 |
| pitti | Good morning | 07:06 |
| nixternal | mornin' pitti | 07:07 |
| slangasek | nixternal: well, I don't know how Keybuk intends to handle selecting a different image for VGA vs. drm; perhaps you should wait and see what develops there | 07:09 |
| nixternal | oh, well that is good to know.... | 07:10 |
| pitti | hi nixternal | 07:10 |
| nixternal | so I take it aubergine was a nightmare on nvidia crap hardware? | 07:10 |
| tjaalton | slangasek: hey, got a minute for the backport ffe? | 07:10 |
| slangasek | tjaalton: looking at it now | 07:10 |
| tjaalton | slangasek: cool, thanks | 07:11 |
| slangasek | nixternal: no, aubergine still looks fine in VGA, but the logo is dithered | 07:11 |
| nixternal | damn, gotta DMB meeting at 10am....just my luck, I volunteered to chair...10am is to early | 07:11 |
| nixternal | slangasek: hrmm | 07:11 |
| nixternal | so much for my theme where distro logos come in, and then get smashed by the kubuntu logo :p | 07:12 |
| apachelogger | good plan it was though | 07:14 |
| nixternal | hehe | 07:16 |
| dholbach | good morning | 07:58 |
| slangasek | ArneGoetje, pitti: livefs build failure today, file conflict between language-pack-gnome-de and language-pack-de (/usr/share/locale-langpack/de/LC_MESSAGES/clutter-1.0.mo) | 08:01 |
| * slangasek waves to dholbach | 08:01 | |
| dholbach | hola slangasek | 08:03 |
| ArneGoetje | slangasek: gaa... another template moved... shall clutter be in -gnome or in the common langpacks? | 08:09 |
| slangasek | ArneGoetje: wherever you think it belongs? :) | 08:12 |
| ArneGoetje | slangasek: I don't know clutter. Is that a gnome specific thing or a generic thing? | 08:13 |
| slangasek | ArneGoetje: it's GTK-specific, but not very GNOME-specific; it does appear to be in both ubuntu-desktop and ubuntu-netbook, and not in kubuntu-netbook, though, so I guess -gnome is the right answer | 08:15 |
| ArneGoetje | slangasek: ok, thanks | 08:15 |
| ArneGoetje | slangasek: that needs new -base language-packs. I will rebuild them. | 08:17 |
| free | pitti: creating a symlink /usr/lib/dbus-1.0/dbus-daemon-launch-helper -> /lib/dbus-1.0/dbus-daemon-launch-helper solves the hardy-to-lucid upgrade problem (new processes can't connect to dbus anymore after the upgrade) | 08:45 |
| free | pitti: do you want me to file a bug or can you just make a new revision of the dbus package? | 08:45 |
| lifeless | persia: ping | 08:49 |
| dholbach | persia: "The DMB currently meets every two weeks in #ubuntu-meeting at 15:00 UTC." isn't very clear (https://wiki.ubuntu.com/DeveloperMembershipBoard) - should that be "ever 2nd and 4th tuesday of the month" - also does fridge say 14 utc | 08:51 |
| dholbach | or geser, soren, stgraber, cody-somerville ^ :) | 08:52 |
| geser | dholbach: fridge got confused with the DST change, the DMB meeting is still at 15:00 UTC | 09:13 |
| dholbach | ara: ^ | 09:14 |
| geser | dholbach: as the DMB meetings alternate with TB meetings, you would also have to set the TB meetings to 1st and 3rd Tuesday to let it work without collisions | 09:16 |
| dholbach | geser: I don't know - I was just looking at the page and thought it's a bit unclear | 09:17 |
| pitti | free: can you please file a bug and assign to canonical-desktop-team? | 09:17 |
| pitti | free: great to hear that it worked! | 09:17 |
| dholbach | either you explain the rule or mention when the next meeting is going to be :) | 09:17 |
| geser | dholbach: else the schedule shifts in months with 5 tuesdays (like this month where the DMB meetings happened on 1st, 3rd and 5th Tuesday) | 09:19 |
| dholbach | ah | 09:19 |
| * Ng wonders why we don't just run fsck -y when it says it needs to be run manually | 09:20 | |
| geser | dholbach: mentioning the next meeting seems to be easier (would mentioning it on the Agenda page be clear enough?) | 09:20 |
| Ng | exactly who ever runs fsck and doesn't just say yes to all the things it wants to fix? ;) | 09:20 |
| Ng | other than Ted | 09:20 |
| dholbach | geser: yeah, probably | 09:20 |
| alkisg | Hi, could someone help with bug #491940? | 09:41 |
| ubottu | Launchpad bug 491940 in ltsp "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/491940 | 09:41 |
| alkisg | I've committed a patch in LTSP that would solve the problem, if the corresponding patch that I sent to gnome-session was accepted. | 09:41 |
| alkisg | The gnome-session patch was neither accepted nor explicitly rejected. In any case, the problem remains: | 09:41 |
| alkisg | LTSP clients in Lucid have non-working reboot/shutdown menus. They were working in previous releases with a similar patch in fusa. | 09:41 |
| alkisg | As a teacher I think this is really inconvenient for schools, so I'd appreciate it if someone could direct me to a way to deal with this problem. | 09:41 |
| dholbach | thanks geser | 09:43 |
| lifeless | persia: ping ;) | 09:48 |
| pitti | amitk: do you still remember the power saving UDS discussion? one point was "do not enable fingerprint readers unless fprint/thinkfinger are installed", which unfortunately was only put on the beta-2 list | 09:58 |
| pitti | amitk: however, there is no specific module for those which could be blacklisted with a modprobe.d file (unless tf/fprint are available) | 09:59 |
| pitti | amitk: is there some better way to not enable those? | 09:59 |
| lifeless | pitti: are fprint and thinkfinger quivalent ? | 10:03 |
| pitti | amitk: also, I don't see the device appear in powertop at all; 80% of wakeups are "rescheduling interrupts" and "load balancing" and "extra timer interrupt" (which all seem kernel related), and 8% is touchpad; the rest seems negligible | 10:04 |
| pitti | lifeless: in terms of using the fingerprint scan device they should be? | 10:04 |
| lifeless | cool | 10:04 |
| lifeless | I'll go for thinkfinger then as it has thinkfinger-tools | 10:04 |
| pitti | lifeless: I tried tf in the past, and it worked; fprint is allegedly a more flexible platform, but I haven't ever tried it | 10:05 |
| pitti | but I have never actually used this thing | 10:05 |
| lifeless | pitti: I has a new laptop ;) | 10:06 |
| lifeless | actually has three buttons on the touchpad again (yay!) | 10:06 |
| pitti | I type my user name faster than I can swipe my finger, and a fingerprint reader isn't for authentication | 10:06 |
| lifeless | but also a fpr reader | 10:06 |
| lifeless | its not for auth? | 10:06 |
| pitti | lifeless: wohoo; another three years over? which one did you get? | 10:06 |
| lifeless | x201s/8G/128G SSD | 10:07 |
| pitti | lifeless: my latitude 430 has an fp reader as well | 10:07 |
| pitti | lifeless: is that a thinkpad? | 10:07 |
| lifeless | yes | 10:07 |
| lifeless | pitti: I know, my old D430 is on the floor beside me | 10:07 |
| pitti | amitk: http://paste.ubuntu.com/406418/ for the record; it's actually a little disappointing, in jaunty/karmic I got it down to 10 W | 10:08 |
| pitti | lifeless: for warming your feet now? :-) | 10:08 |
| lifeless | pitti: :> | 10:08 |
| lifeless | npviewer.bin die die die | 10:09 |
| pitti | lifeless: not for auth> your fingerprints are all over the place, and also conveniently located on the keys, the laptop cover, the wrist rests, etc; not much different than writing your password on a post-it note on the monitor | 10:09 |
| lifeless | I thought that the point was to check for a pulse at the same time | 10:09 |
| pitti | the ones that they built into notebooks don't have life sign detection | 10:10 |
| lifeless | :> | 10:10 |
| pitti | they are by and large just an optical scanner | 10:10 |
| lifeless | ah | 10:10 |
| lifeless | fail | 10:10 |
| lifeless | 42% of wakeups 'Load balancing tick' | 10:11 |
| lifeless | 18% iwlagn interrupt | 10:11 |
| lifeless | 11% firefox | 10:11 |
| pitti | I disabled firefox, network, empaty, and almost everythign else except gnome-terminal for that run | 10:11 |
| lifeless | this machine is sitting at 12W with nothing disabled | 10:12 |
| lifeless | screen at 60% or so | 10:12 |
| cjwatson | lifeless: don't suppose you happened to run across any decently-priced non-Thinkpad SSD laptops ... | 10:13 |
| * cjwatson looking for recommendations right now | 10:14 | |
| lifeless | cjwatson: johnf here in sydney is very happy with an hp netbook w/ssd | 10:14 |
| lifeless | being extremely cheap as a result of being a netbook | 10:14 |
| cjwatson | mm, HP was on my list, although I don't want a netbook - might look into what else they have | 10:14 |
| lifeless | cjwatson: I'm not a IBM fanboy per se, but I'm quite happy with this. | 10:16 |
| lifeless | why are you excluding thinkpads ? | 10:16 |
| cjwatson | I despise the Esc key placement | 10:16 |
| cjwatson | (trivial I know, but it has long annoyed me) | 10:16 |
| * RAOF opens his thinkpad to check the Esc key... | 10:17 | |
| pitti | swapping esc and caps lock in ~/.xmodmap FTW | 10:17 |
| lifeless | cjwatson: ah yes. its been pissing me off just enough to be a PITA, but not enough to want to return an otherwise great machine. | 10:17 |
| pitti | (for all of us happy vim users) | 10:17 |
| cjwatson | pitti: ah, the thing is, I like Caps Lock as well | 10:19 |
| pitti | cjwatson: oh; I don't know many people who do | 10:19 |
| cjwatson | anyway, I suppose this is OT, sorry | 10:19 |
| lifeless | heh | 10:19 |
| lifeless | tumbleweeds if we were not talking | 10:19 |
| RAOF | Hardware lust is *always* on topic. :) | 10:19 |
| pitti | at least it never seemed important enough to me to give it such a good and comfortable position on a keyboard.. | 10:19 |
| pitti | cjwatson: partman-multipath wants to go back to universe, 's ok? | 10:32 |
| tjaalton | nooo | 10:32 |
| tjaalton | though I've not had a chance to try it yet | 10:32 |
| pitti | hm, then perhaps some dependency was dropped? | 10:32 |
| cjwatson | wonder how that fell out, I thought I'd seeded it | 10:32 |
| cjwatson | I don't think anything ever depended on it | 10:32 |
| tjaalton | cjwatson: do you know if someone has tested it on lucid yet? | 10:32 |
| cjwatson | tjaalton: I don't know | 10:33 |
| cjwatson | not that it's changed much? | 10:33 |
| cjwatson | I'm just going to seed it, it's been in main since jaunty | 10:33 |
| tjaalton | yeah it worked fine then, will reinstall the shell server with lucid this summer | 10:34 |
| tjaalton | it handles ~800 unique sessions just fine | 10:34 |
| pitti | cjwatson: related to that, libudev0-udeb wants demotion as well, that doesn't look intended? | 10:34 |
| cjwatson | does anything depend on it? | 10:38 |
| cjwatson | nothing in the core installer uses libudev | 10:38 |
| cjwatson | I assumed it was there because udev-udeb linked against it | 10:38 |
| Keybuk | I think I compile udev-udeb static | 10:39 |
| cjwatson | it's not static, but nothing in udev-udeb seems to use libudev | 10:41 |
| cjwatson | even in the main udev package, it's only input_id | 10:41 |
| pitti | I checked ldd, and it doesn't lik against libudev-udeb | 10:41 |
| pitti | cjwatson: input_id was fixed in the last upload, or should have been at least | 10:41 |
| pitti | yep, seems fine | 10:41 |
| cjwatson | I didn't know it was a bug, but OK | 10:41 |
| pitti | ok, so it seems that can safely go | 10:42 |
| mdz | pitti: hi, I noticed you were looking at apport stuff this morning. did you have a chance to look over my Java crash handler? | 10:42 |
| pitti | tseliot: is nvidia-185-modaliases current or obsolete? (it wants to go to universe) | 10:42 |
| pitti | mdz: not yet, sorry; I'm afraid this has to wait for a bit (it will take me some time to learn about java stuff) | 10:43 |
| pitti | mdz: but if it works for you, I'm happy to merge it | 10:43 |
| tseliot | pitti: it's a transitional package and I think we need it in main/restricted (why universe??) | 10:43 |
| pitti | tseliot: well, s/universe/not main/ | 10:44 |
| pitti | tseliot: ah, ok, so we should seed it | 10:44 |
| * tseliot nods | 10:44 | |
| pitti | tseliot: done | 10:46 |
| tseliot | pitti: thanks | 10:46 |
| mdz | pitti: it's not ready to merge yet; it's just some dead code in the source tree right now (doesn't get tested or installed) | 10:47 |
| cjwatson | TheMuso: could you look at bug 551515 and decide whether it makes sense? | 11:04 |
| ubottu | Launchpad bug 551515 in casper "[Lucid] need little modify the ubiquity-hooks/30accessibility script with gdm accessibility setting configuration part in Blindness profile" [Undecided,New] https://launchpad.net/bugs/551515 | 11:04 |
| === MacSlow is now known as MacSlow|lunch | ||
| nosse1 | Hello. How can I debug upstart during system startup? I cant inject strace in the init="" kernel string, because that results init/upstart not to become process num 1 | 12:00 |
| marufaberlin | is there a channel for ubuntu app development? i'm trying to implement a virtual semantic file system for ubuntu | 12:00 |
| nosse1 | Yes, See #ubuntu-app-devel | 12:01 |
| TheMuso | cjwatson: It makes sense to me, I'm not sure whether the proposed solution is sane however. | 12:01 |
| marufaberlin | thanks :) | 12:01 |
| TheMuso | cjwatson: I need to talk to the desktop fols about this, and will follow up and make changes if necessary. | 12:03 |
| TheMuso | folks | 12:03 |
| cjwatson | TheMuso: thanks | 12:04 |
| Keybuk | nosse1: what are you trying to debug? | 12:05 |
| nosse1 | Keybuk: Upstart. I have a ARM target which fails sometime during upstart | 12:05 |
| Keybuk | nosse1: no, what problem are you trying to debug | 12:06 |
| Keybuk | it's unlikely you have a problem with the init daemon itself | 12:06 |
| nosse1 | Keybuk: Yes, upstart is probably not the culprit. I'm working on an initial bringup of Ubuntu to a new target, so it's likely that its something in relationshop with the kernel | 12:07 |
| nosse1 | Keybuk: However init="/sbin/init --verbose" does not reveal anything useful | 12:08 |
| Keybuk | nosse1: again, what problem are you trying to debug? | 12:08 |
| nosse1 | My target system won't boot. It hangs somewhere between init and the console login | 12:08 |
| Keybuk | with --verbose, what is the last message on the console that you see? | 12:09 |
| nosse1 | It varies. Sometimes it hangs in the middle of a output line, like "init: module-init-tools state changed from waiting to s" | 12:12 |
| \sh | is there a special irc channel for ubuntu one? | 12:12 |
| Keybuk | nosse1: did you try booting without "quiet" to get kernel messages? | 12:13 |
| nosse1 | Keybuk: Yes I'm on a embedded target, so quiet is not enabled per default | 12:14 |
| nosse1 | No special message there | 12:14 |
| Keybuk | if output is stopping mid-way through a line, it really sounds like a deeper problem | 12:14 |
| nosse1 | I suspect a syscall crashing the system, and I hoped strace could point me in the right direction | 12:14 |
| Keybuk | you can't strace init | 12:15 |
| Keybuk | and, even if you could, init doesn't make many interesting syscalls; fork() and exec() are all it really does | 12:15 |
| nosse1 | if I can get strace to follow those forks and execs then that is what I want :) | 12:16 |
| Keybuk | right, but you can't strace init | 12:16 |
| nosse1 | How is that? strace -p1 wont work? | 12:17 |
| Keybuk | right | 12:17 |
| Keybuk | the kernel won't let you do it | 12:17 |
| nosse1 | ah | 12:17 |
| nosse1 | I'll start peeling of services and see if I can come any closer | 12:18 |
| nosse1 | upstart will only consider *.conf in /etc/init right? I can rename them to foobar.conf.nope to disable them? | 12:19 |
| Keybuk | right | 12:20 |
| alkisg | Hi, could someone help with bug #491940? | 12:46 |
| ubottu | Launchpad bug 491940 in ltsp "Patch for LTSP clients to properly reboot/shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/491940 | 12:46 |
| alkisg | I've committed a patch in LTSP that would solve the problem, if the corresponding patch that I sent to gnome-session was accepted. | 12:46 |
| alkisg | The gnome-session patch was neither accepted nor explicitly rejected. In any case, the problem remains: | 12:46 |
| alkisg | LTSP clients in Lucid have non-working reboot/shutdown menus. They were working in previous releases with a similar patch in fusa. | 12:46 |
| alkisg | As a teacher I think this is really inconvenient for schools, so I'd appreciate it if someone could direct me to a way to deal with this problem. | 12:46 |
| seb128 | alkisg, the gnome-session change you suggest seems rather an hack that's the correct way | 12:48 |
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | alkisg, it seems to need some work but that will not be changed in lucid now | 12:49 |
| alkisg | seb128: I wouldn't call it a hack - it's the standard way we use in LTSP for the server to communicate to the client | 12:49 |
| alkisg | seb128: so the desision is to have broken menus for LTSP clients? Isn't LTSP in main? | 12:50 |
| seb128 | alkisg, did you address the comments on the bug? | 12:50 |
| alkisg | Yes, all of them. | 12:50 |
| seb128 | k so maybe somebody will review it | 12:50 |
| * alkisg doesn't think so, else he wouldn't ask here... | 12:50 | |
| seb128 | that's not a decision rather than how things are turning | 12:50 |
| alkisg | seb128: why not just accept the patch? | 12:51 |
| seb128 | to be honest I don't think so either | 12:51 |
| alkisg | Is it so horrible? | 12:51 |
| seb128 | because it's a hack | 12:51 |
| alkisg | Then all of LTSP is a hack | 12:51 |
| alkisg | Because that's the way localapps are implemented in LTSP | 12:51 |
| seb128 | and we have other issues we need to work on now | 12:51 |
| seb128 | and nobody in the desktop team seems to be interested in doing ltsp work | 12:51 |
| alkisg | seb128: I was directed to do it this way by the indicator-applet maintainer | 12:51 |
| alkisg | And chrisccoulson has said "yeah, no problem" - so I thought everything was ok | 12:52 |
| seb128 | ok, so good | 12:52 |
| alkisg | I don't know why setting an xprop to be picked up by the ltsp display manager is considered such a bad practice... | 12:52 |
| seb128 | why do you ask on IRC if everything is ok? | 12:53 |
| alkisg | Because it isn't | 12:53 |
| alkisg | He probably changed his mind or something... | 12:53 |
| alkisg | But I don't know what is wrong, or how would I correct it | 12:54 |
| alkisg | Setting xprops is the standard way we use in LTSP to communicate something to the client. Leaving broken menus sound much worse to me. | 12:54 |
| seb128 | alkisg, reality is that the team is busy with other things right now so review will take a while | 12:54 |
| chrisccoulson | hi | 12:54 |
| seb128 | hey chrisccoulson | 12:54 |
| alkisg | Hi chrisccoulson | 12:55 |
| alkisg | Sorry if I'm insisting on this too much, but it is a big problem in classrooms | 12:55 |
| alkisg | And that xprop will only be set for LTSP clients, so I can't imaging how would that affect normal installations... | 12:56 |
| alkisg | *imagine | 12:56 |
| seb128 | it's not a matter of affecting normal installation | 12:56 |
| seb128 | but to have new codepath | 12:56 |
| seb128 | new potential bugs | 12:56 |
| seb128 | divergence with upstream and debian | 12:56 |
| seb128 | etc | 12:56 |
| seb128 | + it requires somebody to review the change and test those | 12:57 |
| alkisg | That path was suggested by the indicator-applet maintainer exactly because it's a modification to an *existing* ubuntu patch | 12:57 |
| seb128 | and I'm not sure anybody in the desktop team has access to ltsp setups for testing | 12:57 |
| alkisg | seb128: many people have tested it and reported that it's OK in the bug report | 12:57 |
| seb128 | ok, good | 12:57 |
| seb128 | so wait to see if somebody review it now | 12:57 |
| alkisg | (I had uploaded a patched gnome-session in my ppa for some months) | 12:57 |
| seb128 | I'm not really interested by arguing there, I was just giving reason on why it might take a while | 12:58 |
| seb128 | anyway | 12:58 |
| seb128 | back to work | 12:58 |
| alkisg | I'm pretty sure that if I just wait, nothing will happen, so LTSP will just have broken menus | 12:58 |
| chrisccoulson | the patch is incorrect anyway, if it's the same one as posted in the description of the bug report (i don't know if you already discussed that) | 12:58 |
| alkisg | seb128: ok, thank you for your time | 12:58 |
| chrisccoulson | (i commented on the bug explaining why) | 12:58 |
| alkisg | chrisccoulson: how is it incorrect? | 12:58 |
| alkisg | I answered to your comments in the bug report | 12:58 |
| chrisccoulson | i explained already on the bug report. the additional hook is in the wrong place | 12:58 |
| alkisg | You're saying that it won't work from the session dialog, but it does | 12:58 |
| alkisg | That place was suggested by tedg | 12:59 |
| alkisg | I just did the ltsp part... | 12:59 |
| alkisg | It even works if an app directly calls dbus | 13:00 |
| alkisg | (e.g. italc) | 13:00 |
| chrisccoulson | alkisg, i don't see how it works from the session dialog if you added the extra code to gsm_manager_request_{shutdown,reboot} | 13:03 |
| chrisccoulson | those are only callable from the dbus interface | 13:04 |
| alkisg | chrisccoulson: 5-6 persons in the bug report are verifying that it does, though | 13:04 |
| seb128 | you don't use the same session dialogs | 13:04 |
| seb128 | chrisccoulson means the one you get without the indicator | 13:04 |
| alkisg | I'm pressing the shutdown button of my dialog | 13:04 |
| chrisccoulson | the patch in your ppa must be different to the one in the bug then if that works | 13:05 |
| alkisg | The session dialog comes up, I select power off, and it does | 13:05 |
| chrisccoulson | because the one in the bug definately doesn't work | 13:05 |
| alkisg | In previous Ubuntu versions, a patch was accepted in fusa that it was working only in fusa | 13:06 |
| alkisg | Even if that patch works from the applet + the dbus calls, why would the previous one be accepted, and this one not? | 13:06 |
| alkisg | Is leaving non-working menus better? | 13:06 |
| alkisg | Because in my classroom I'm ashamed to have to explain to my students why the menus are not working... | 13:06 |
| seb128 | nobody denies there is an issue | 13:08 |
| seb128 | but the fact that it was fixed in a broken way before doesn't mean we should keep carrying broken changes | 13:08 |
| alkisg | OK, so I'm asking: what would be a better way? | 13:08 |
| seb128 | not sure, I don't know about ltsp and how it's working | 13:09 |
| seb128 | and why such hacks are required | 13:09 |
| dnivra | Hello. Can someone tell me which package does "network proxy" belong to? | 13:09 |
| cjwatson | dnivra: run "network proxy", then in a terminal run 'xprop | grep WM_CLASS', click on "network proxy" window, and you get: | 13:10 |
| cjwatson | WM_CLASS(STRING) = "gnome-network-properties", "Gnome-network-properties" | 13:10 |
| alkisg | I'm upstream for LTSP, and I'm not aware of any other better way. | 13:10 |
| alkisg | It's even better than the one used in previous ubuntu versions | 13:10 |
| alkisg | So I'm not sure what more can be done from the LTSP side... | 13:10 |
| cjwatson | dnivra: then 'dpkg -S bin/gnome-network-properties' and you get gnome-control-center | 13:10 |
| cjwatson | dnivra: so the package name is gnome-control-center | 13:10 |
| seb128 | alkisg, k, still arguing there is of no real use | 13:11 |
| seb128 | alkisg, what is needed is somebody having free slot to review your change and work on the issue | 13:11 |
| seb128 | alkisg, you will not get that by arguing on IRC | 13:11 |
| dnivra | cjwatson, that was quick even before I could understand what you were saying. let me try to do it. thanks a lot! | 13:11 |
| alkisg | OK, thank you seb128 for your time. I just had to do a last try, as I think the issue is too important to go unnoticed | 13:11 |
| * alkisg resigns from this issue, I'll just keep a patched gnome-session in my ppa for greek schools. | 13:12 | |
| seb128 | alkisg, did you try to understand chrisccoulson's comments on the bug? | 13:13 |
| alkisg | seb128: to the best of my ability... | 13:13 |
| seb128 | and to address those rather than reply that it works as it is now | 13:13 |
| cjwatson | dnivra: I just wanted to explain the general method because that way you can find out the answer to future questions of the same form | 13:13 |
| alkisg | seb128: that code path was suggested by tedg, which works on that stuff. I don't - I'm working on LTSP. I don't think I can find a better codepath myself. | 13:14 |
| dnivra | cjwatson, thank you. it was real new info. off to the man page to make more sense of the commands used. | 13:14 |
| seb128 | alkisg, ted works on the indicators not on gnome-session | 13:14 |
| alkisg | chrisccoulson: if you think there's a better codepath somewhere, could you please give me some hint? | 13:15 |
| cjwatson | (I'm assuming that the first field in WM_CLASS is always the command name; it generally seems to be but I haven't actually gone and checked the specification for this) | 13:15 |
| alkisg | (and, is that actually the problem? Or is it the xprop?) | 13:15 |
| seb128 | alkisg, we will try to review the bug before lucid but schedule is tight and that's low priority on the tasklists | 13:15 |
| alkisg | seb128: I know - I filed it there months ago, though... :-/ | 13:15 |
| seb128 | well as said before nobody in our team uses ltsp or has configuration to work on those changes | 13:16 |
| seb128 | we just agreed that we don't like the current way the change are done on the bug | 13:16 |
| alkisg | Anyway, that's about as much as I can do about it, I don't think I'm able to do anything more. Thank you all very much for your time. | 13:17 |
| seb128 | alkisg, sorry to be really helpful there, as said it's on our list it's just not high ranked for now | 13:17 |
| seb128 | we might look at it before lucid still though | 13:18 |
| alkisg | chrisccoulson: if you find time to come up with something that needs testing, there are many teachers here available for testing ltsp. | 13:18 |
| alkisg | OK. Thanks again. | 13:18 |
| chrisccoulson | alkisg, i don't really have any time to spare atm | 13:20 |
| alkisg | chrisccoulson: I understand - but if you could only clarify this: if a better code path is found so that it also works from the session dialog, would that be enough to get it accepted? | 13:21 |
| alkisg | (because if it's the xprop usage, I don't think we can find any other way unless we patch dbus itself...) | 13:22 |
| === sconklin-away is now known as sconklin | ||
| === ctrlsoft is now known as Guest30384 | ||
| === Guest30384 is now known as jelmer | ||
| marjo | cjwatson: http://people.canonical.com/~marjomercado/isotestingbugs.html updated per your request | 14:16 |
| cjwatson | thanks! | 14:16 |
| happyaron | cjwatson: hi, could you have a look at bug 476269 ? | 14:21 |
| ubottu | Launchpad bug 476269 in ubiquity "Chinese, Brazilian Portuguese, and English variant translations aren't shown during Karmic and Lucid installation" [Undecided,Confirmed] https://launchpad.net/bugs/476269 | 14:21 |
| free | pitti: bug filed, https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/551672, and thanks for your hints! | 14:22 |
| ubottu | Ubuntu bug 551672 in dbus "Can't connect to d-bus after upgrading from Hardy to Lucid" [Undecided,New] | 14:22 |
| cjwatson | happyaron: not right now, but I've put it on my list to do in time for beta-2 | 14:22 |
| pitti | free: thanks! | 14:22 |
| happyaron | cjwatson: good to hear that, many thanks! | 14:23 |
| mdz | mvo: on a related note, do you have a guess about bug 545790? (seen in the same upgrade) | 14:32 |
| ubottu | Launchpad bug 545790 in dpkg "package PACKAGE failed to install/upgrade: error writing to '<standard output>': Success" [High,Confirmed] https://launchpad.net/bugs/545790 | 14:32 |
| mvo | mdz: it may well be a dupe, I have not checked carefully yet. but it does make sense that the frontend goes away and dpkg gets unhappy afterwards | 14:33 |
| mdz | mvo: I think it's a dpkg bug that it doesn't show the error code (probably EPIPE or so) | 14:36 |
| mdz | it's doing printf (without checking the error code), followed by fflush and ferror | 14:37 |
| mdz | then assuming errno is something useful | 14:37 |
| mdz | ferror explicitly doesn't set errno, though | 14:39 |
| === dendrobates is now known as dendro-afk | ||
| mpt | davmor2, hi | 14:49 |
| davmor2 | mpt: hello | 14:49 |
| mpt | davmor2, <https://wiki.ubuntu.com/SoftwareCenter> has lots of test cases embedded in it. (I keep them there so that I can keep them in sync with the rest of the spec). Is it ok if I replace the contents of <http://testcases.qa.ubuntu.com/System/SoftwareCenter> with instructions on finding them? | 14:50 |
| davmor2 | mpt: 2 ticks I'll have a quick look | 14:51 |
| mpt | davmor2, I could add "sc-nnn"-type numbers to each of them if that would help | 14:53 |
| davmor2 | mpt: okay so your page the cases don't really leap out. So the obvious way would be as you say to tie it in with sc-nnn. I'm not sure how that would tie in then with qa.testcases. ara ^ any idea | 14:56 |
| mpt | davmor2, search for "Test case:" - there's 17 of them | 14:57 |
| mpt | I'll number them | 14:57 |
| ara | mpt, the problem is that those test cases make no sense without the spec | 14:59 |
| mpt | ara, hm, that's probably true for the first couple. I can reword them. | 15:00 |
| mathiaz | Riddell: hi! Does kubuntu use autofs to mount usb drives? bug 545384 | 15:01 |
| ubottu | Launchpad bug 545384 in autofs "automatic mounting of removable devices doesn't work in KDE" [Undecided,New] https://launchpad.net/bugs/545384 | 15:01 |
| davmor2 | mpt: as a side note it may be easier from a testers view point if all the test were together in one section too, or maybe at the bottom of each section rather than just randomly in the general text, I hope that makes sense | 15:06 |
| ara | mpt, nevertheless, I like having all the testcases in the same place. do you know if moinmoin <<include>> statements work across different instances? | 15:06 |
| davmor2 | ara: schwuk might know | 15:07 |
| mpt | davmor2, ara: The accuracy of a test case is inversely proportional to the square of the distance between that testcase and the specification for the feature. | 15:09 |
| mpt | As we get more specification coverage, I expect we'll have more test cases in specifications | 15:09 |
| mpt | especially for specifications that are in use-case format | 15:09 |
| mpt | So, I guess we should figure out a way to extract and syndicate them on qa.ubuntu.com | 15:09 |
| ara | mpt, agree | 15:10 |
| ara | mpt, right now we include pieces of other testcases into a new one, but always within testcases.qa, I don't know if it would work from content outside | 15:10 |
| Riddell | mathiaz: it uses hal I think | 15:11 |
| Riddell | not sure what hal uses | 15:11 |
| davmor2 | ara, mpt: why not name one case sc-010 and see if you can pull it in | 15:13 |
| mpt | davmor2, ara: https://wiki.ubuntu.com/SoftwareCenter?action=diff&rev2=360&rev1=359 | 15:15 |
| ara | mpt, davmor2: right now I cannot try. I will try asap | 15:16 |
| mpt | ok, for now I've just added a link and string to search for | 15:18 |
| Keybuk | http://reprog.wordpress.com/2010/03/30/a-brief-yet-helpful-lesson-on-elementary-resource-locking-strategy/ | 15:18 |
| Keybuk | ^ Hilarious, yet insightful | 15:18 |
| pitti | *chuckle* | 15:34 |
| mdz | ara: I see a lot of bug reports where people copy and paste the output of "lsb_release" and "apt-cache policy <package>", even though they are using apport which includes this information for them. are there instructions somewhere which tell them to do this? | 15:34 |
| mdz | ara: (random example: bug 548428) | 15:34 |
| ubottu | Launchpad bug 548428 in chromium-browser "Error 107 (net::ERR_SSL_PROTOCOL_ERROR): Unknown error" [High,Triaged] https://launchpad.net/bugs/548428 | 15:34 |
| ara | mdz, yes, launchpad tell them to add that information | 15:35 |
| mdz | ara: maybe it shouldn't say that if there is already apport info attached (I find it makes the report harder to read) | 15:36 |
| mathiaz | james_w: hi! Could you import the latest version of the openldap package in the packaging branch? | 15:39 |
| === dendro-afk is now known as dendrobates | ||
| james_w | mathiaz: it's working on it now | 15:46 |
| mathiaz | james_w: thanks | 15:47 |
| mdz | Keybuk: wow, the more links you click, the deeper the sexism goes | 15:48 |
| mdz | reddit is pretty low | 15:48 |
| jdong | mdz: I hope I'm reading it correctly (with my sarcasm detector going off...) | 15:49 |
| Keybuk | mdz: I don't see any evidence of sexism in the author's post | 15:49 |
| mdz | Keybuk: the original article is some mild condescension and implied feminine irrationality | 15:50 |
| mdz | then the comments kick it up a notch... then the reddit comments go even further | 15:51 |
| mdz | s/is/has/ | 15:51 |
| mdz | there's a theorem in here somewhere | 15:51 |
| Keybuk | mdz: you are a very strange person. The original article that I read has a lot of implied geek irrationality in the face of the poor guy's suffering wife trying to get him to not apply computer science problems to making dinner | 15:51 |
| james_w | mathiaz: done | 15:52 |
| jdong | I thought it came across witty like the last xkcd | 15:52 |
| mdz | Keybuk: yes, I am, but I don't think this is an example of it. :-) | 15:53 |
| mdz | I'll save the deconstruction for some other time or channel | 15:54 |
| jcastro | mvo: squid guy mail reminder! | 15:57 |
| mvo | jcastro: *cough* right | 15:59 |
| mvo | sorrrrry | 15:59 |
| jcastro | mvo: it's ok I'll just bug you until you do it, heh. Also, I submitted a branch to add more mirrors. | 16:01 |
| mvo | jcastro: cool | 16:02 |
| === nosse1 is now known as nosse1_noob | ||
| === deryck is now known as deryck[lunch] | ||
| Riddell | ArneGoetje: ping | 16:20 |
| Riddell | ArneGoetje: you said ubuntu desktop is changing to liberation and I said I'd enquire if that's something we want in Kubuntu. turns out we do want it. what needs doing? | 16:20 |
| cody-somerville | Aren't you suppose to be able to click through notify-osd notifications? I just tried to and it wasn't letting me. :/ | 16:20 |
| mrand | pitti: Mythtv packages are still struggling to get good backtraces. It looks like compile-type=debug doesn't help. We recently had the opportunity to have two bugs filed on the exact same problem on same machine with same version. One with debug packages, one without: Bug 549593 and https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/549459 retracer didn't add any value on either bug, and non-dbg trace was useless. | 16:23 |
| mrand | So still looks like we need our purpose built -dbg packages. superm1 was wondering if you had any ideas? | 16:23 |
| ubottu | Ubuntu bug 549459 in mythtv "mythfrontend.real crashed with SIGSEGV in QX11PixmapData::x11ConvertToDefaultDepth() (dup-of: 549593)" [Medium,Triaged] | 16:23 |
| ubottu | Ubuntu bug 549593 in mythtv "mythfrontend.real crashed with SIGSEGV in QX11PixmapData::x11ConvertToDefaultDepth()" [Medium,Triaged] | 16:23 |
| ubottu | Launchpad bug 549593 in mythtv "mythfrontend.real crashed with SIGSEGV in QX11PixmapData::x11ConvertToDefaultDepth()" [Medium,Triaged] https://launchpad.net/bugs/549593 | 16:23 |
| LaserJock | any java folks about? | 16:24 |
| highvoltage | as if they'll admit it :) | 16:28 |
| === sconklin is now known as sconklin-away | ||
| geser | LaserJock: nobody is in #ubuntu-java? | 16:29 |
| cjwatson | Keybuk: how does http://paste.ubuntu.com/406585/ look to you? | 16:30 |
| Keybuk | cjwatson: bug# ? | 16:31 |
| LaserJock | geser: ah, good point | 16:31 |
| cjwatson | Keybuk: don't have one, I encountered it locally and started fixing it first | 16:31 |
| Keybuk | what was the bug? | 16:31 |
| cjwatson | server install, removed 'splash' from command line, stuck on tty7 after boot; strace revealed that plymouth was segfaulting, further investigation revealed it was segfaulting on trying to access VGA registers | 16:32 |
| cjwatson | sorry, plymouthd segfaulting not plymouth | 16:33 |
| Keybuk | if you removed splash, why would plymouth be trying to use the vga16fb renderer? | 16:33 |
| cjwatson | that I don't knoww | 16:33 |
| cjwatson | *know | 16:33 |
| Keybuk | moving all that code into activate() breaks a lot of the design separation of the plugin | 16:35 |
| Keybuk | I wouldn't want to do that | 16:35 |
| Keybuk | VT activation is supposed to be trivial, not complex | 16:35 |
| cjwatson | ok, so I should be investigating why the vga16fb renderer is being used instead? | 16:35 |
| jumper_ | hi | 16:36 |
| Keybuk | cjwatson: right, it might be a simple bug that on_vt_active_changed is being called in the first place | 16:36 |
| cjwatson | right, I can look into that then. thanks! | 16:36 |
| Keybuk | that being said | 16:37 |
| Keybuk | the vga calls should probably be guarded by the map_address != MAP_FAILED check anyway | 16:37 |
| cjwatson | (or 0; or else initialise map_address to MAP_FAILED when creating the backend) | 16:37 |
| Keybuk | right that too | 16:38 |
| Keybuk | though also arguably all that vga stuff should move to the top of flush_head() | 16:40 |
| Keybuk | after the set_mode :p | 16:40 |
| Keybuk | that's actually probably the right thing | 16:40 |
| Keybuk | (as well as finding out why vga16fb was used in the first place) | 16:40 |
| Damascene | https://bugs.launchpad.net/ubuntu/+source/vte/+bug/263822 | 16:41 |
| ubottu | Ubuntu bug 263822 in vte "RTL (right to left) support in terminal (BiDi)" [Low,Triaged] | 16:42 |
| cjwatson | Keybuk: AFAICS, it isn't really being used, it's just that open_device sets up the on_active_vt_changed callback, and that's called unconditionally at startup | 16:42 |
| Damascene | please help with work around | 16:42 |
| Keybuk | cjwatson: the callback shouldn't be called unless a VT change happens? | 16:42 |
| Keybuk | james_w: why didn't evan's upload end up in lp:ubuntu/plymouth ? | 16:48 |
| james_w | good question, let me look | 16:48 |
| james_w | it's currently not touching plymouth as you pushed over the top of it apparently | 16:49 |
| Keybuk | yes, you said to | 16:49 |
| james_w | right | 16:49 |
| james_w | I'm just double checking everything then I'll tell it that that is ok and it should carry on | 16:50 |
| === beuno is now known as beuno-lunch | ||
| james_w | Keybuk: should be there now | 16:59 |
| james_w | and it didn't even overwrite your branch!!!!!! | 16:59 |
| === deryck[lunch] is now known as deryck | ||
| zul | does anyone have a suggestion for a way for not removing a user's user database when going from one version to the next (for reference: https://bugs.edge.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/506985) | 17:01 |
| ubottu | Ubuntu bug 506985 in rabbitmq-server "Upgrade from rabbitmq-server 1.54 -> 1.7.0 wiped users and vhosts" [High,Confirmed] | 17:01 |
| ArneGoetje | Riddell: just seed ttf-liberation in Kubuntu | 17:11 |
| Riddell | ArneGoetje: and fontconfig will magically use that as the default? | 17:11 |
| ArneGoetje | Riddell: default for what? | 17:11 |
| Riddell | for "Sans" and "Serif" fonts | 17:12 |
| ArneGoetje | Riddell: no, it won't. Since DejaVu has a better coverage, they will still be the default | 17:12 |
| Riddell | ArneGoetje: so ubuntu's gnome has a settings override somewhere to make liberation the default? | 17:13 |
| ArneGoetje | Riddell: if you want the Liberation fonts to be the desktop defaults, you'll need to add a fontconfig snippet. | 17:13 |
| === yofel_ is now known as yofel | ||
| ArneGoetje | Riddell: no, we don't use it as default in Ubuntu. It's just installed by default, so that users can use it on the LiveCD and in their installation, e.g. in openoffice.org | 17:14 |
| cjwatson | Keybuk: according to strace, the VT switch in question is simply due to plymouthd itself calling VT_ACTIVATE 7 | 17:14 |
| Riddell | ArneGoetje: ah ok | 17:15 |
| barry | pitti: ping | 17:15 |
| pitti | barry: pong | 17:16 |
| barry | pitti: hi! what i can i do to convince you to approve bug 541990? :) | 17:16 |
| ubottu | Launchpad bug 541990 in computer-janitor "[FFe] Upgrade Computer Janitor to 2.0 (dbus edition)" [Undecided,Incomplete] https://launchpad.net/bugs/541990 | 17:16 |
| Keybuk | cjwatson: which should be in map_to_device, which is after the ioperms call | 17:17 |
| pitti | barry: ah, I'll respond to that soon, just didn't get to it yet today | 17:17 |
| pitti | barry: (like review the branch, etc.) | 17:17 |
| Keybuk | james_w: yays, etc. | 17:17 |
| ev | james_w: thanks! | 17:18 |
| cjwatson | Keybuk: the only match for VT_ACTIVATE is in src/libply-splash-core/ply-terminal.c:set_active_vt | 17:18 |
| pitti | barry: for now, maybe you can make the backend crash and check whether the frontend does something sensible, like shutdown cleanly or respawn it, etc.? | 17:18 |
| cjwatson | oh, the call to ply_terminal_activate_vt | 17:18 |
| Keybuk | james_w: why did the importer add a .pc directory? | 17:18 |
| barry | pitti: cool, thanks. :) it's a bit of a short day for me today, but i will be around all day tomorrow to answer any questions | 17:18 |
| cjwatson | ply_terminal_activate_vt is also called from ./src/plugins/splash/{text,ubuntu-text,details}/plugin.c | 17:19 |
| pitti | barry: oh, and can you please expand on the string changes? they seem unrelated to the architecture change, etc. | 17:19 |
| Keybuk | cjwatson: which, if used, should mean that vga16fb has been unloaded | 17:19 |
| pitti | barry: can these perhaps be reverted? string changes are expensive and detrimental at this point | 17:19 |
| cjwatson | ah, that's a piece of information I didn't know | 17:19 |
| Keybuk | cjwatson: if we have a bug where falling back to, or even forcing the use of, a text plugin still means the graphical renderer is loaded/active - then we have a bug ;) | 17:20 |
| barry | pitti: sure. i'll do so in the bug task | 17:20 |
| cjwatson | Keybuk: right. perfect. | 17:20 |
| Keybuk | cjwatson: so the vga bits are definitely in the wrong place, I'll move those into flush_head as soon as james_w can clean up the mess the importer just made of the branch <g> | 17:21 |
| Keybuk | cjwatson: but I think there's still this other bug where vga16fb is being loaded when it shouldn't be | 17:21 |
| Keybuk | (or not unloaded) | 17:21 |
| === sconklin-away is now known as sconklin | ||
| === yofel is now known as yofel_ | ||
| === yofel_ is now known as yofel | ||
| === nosse1_noob is now known as nosse1 | ||
| Keybuk | james_w: *prod* | 17:47 |
| === beuno-lunch is now known as beuno | ||
| cjwatson | Keybuk: should pressing Ctrl-t (which toggles between PLY_TERMINAL_MODE_{TEXT,GRAPHICS}) also toggle whether the renderer plugin is unloaded/loaded? | 17:49 |
| Keybuk | cjwatson: no | 17:50 |
| Keybuk | Ctrl-T is one of those curious debugging key presses nobody's supposed to know about ;) | 17:50 |
| cjwatson | the reason I ask is that ply_terminal_set_mode (PLY_TERMINAL_MODE_TEXT) would be an awfully convenient place to hook the unload in, since it's already called by all the text plugins | 17:51 |
| Keybuk | err | 17:52 |
| Keybuk | I suspect you're going too far here | 17:52 |
| cjwatson | I don't see how to avoid problems when the splash is selected explicitly, without involving something that the splash plugin calls | 17:52 |
| Keybuk | I don't think you're following me | 17:55 |
| Keybuk | or maybe I'm not understanding you | 17:56 |
| cjwatson | well, we need to either load the renderer plugin only once we're definitely running a splash that requires graphics, or unload the renderer plugin once we're definitely running a splash that requires text? | 17:57 |
| Keybuk | no, not necessarily | 17:57 |
| nixternal | Keybuk: your post on kms couldn't come at a better time :) what is your view on the themes for plymouth? I created the Kubuntu theme, and people with nvidia are crying foul with their wonderful $500 video cards displaying the most expensive set of 16 colors ever...should the theme be fairly lame to suit everyone, or should we keep a rockin' theme and tell the nvidia users with the issues to change to nouveau (as I am assuming nouveau do | 17:57 |
| Keybuk | cjwatson: it may be simply true that the renderer is always loaded | 17:58 |
| Keybuk | and thus the code in vga16fb is a mistake | 17:58 |
| nixternal | ooh, I walked in at the perfect time here | 17:58 |
| Keybuk | on looking closely, none of the other renderers assume the renderer is actually doing anything at vt activate time | 17:58 |
| cjwatson | Keybuk: oh, well that was the assumption I started with, but you said that was wrong :-) | 17:58 |
| Keybuk | cjwatson: ah, never assume that I'm always right :p | 17:58 |
| cjwatson | so in that case, testing whether the vga registers are already mapped in activate() would be sufficient | 17:59 |
| Keybuk | nixternal: in theory, you should be able to have a 16-color alternative to your theme by checking the color depth and stuff - but since we don't have one for ubuntu, I've never tested that - and the renderer might not work right | 17:59 |
| Keybuk | cjwatson: yeah | 17:59 |
| cjwatson | I don't think there's any need to map them right there, it'll presumably be done later if necessary | 17:59 |
| Keybuk | cjwatson: or, as I said earlier, comparing to the other renderers - that kind of thing is probably better off done in flush_head() | 17:59 |
| Keybuk | right, indeed, if you're right and the renderer is always loaded - then it'd be dangerous to map them there | 17:59 |
| cjwatson | flush_head> mm, right, I see | 18:00 |
| cjwatson | especially seeing as that would put it right before setting KD_GRAPHICS | 18:00 |
| Keybuk | cjwatson: which is where all the mode set stuff is actually done | 18:00 |
| Keybuk | yes | 18:00 |
| Keybuk | and we probably really want to set the vga regs after setting KD_GRAPHICS | 18:00 |
| Keybuk | in case the switch to that corrupts them again | 18:00 |
| cjwatson | point | 18:00 |
| cjwatson | well, it's only the ioperm and mmap that were missing really | 18:00 |
| cjwatson | that could be done before KD_GRAPHICS | 18:01 |
| Keybuk | I think the ioperm and mmap are done in the right place | 18:01 |
| Keybuk | they're done on map_to_device | 18:01 |
| Keybuk | I think it's the vga regs fiddling that's in the wrong place | 18:01 |
| Keybuk | instead of on vt activation, they should be done on flush head | 18:01 |
| Keybuk | which would put them in the right place | 18:01 |
| Keybuk | (and would still mean they're called on vt activate, since activate calls the flush head function if the device was mapped) | 18:02 |
| cjwatson | oh! right, I see what you mean now | 18:02 |
| cjwatson | the last piece then would be http://paste.ubuntu.com/406626/ to ensure that the existing guard in activate behaves correctly | 18:03 |
| Keybuk | yes | 18:03 |
| Keybuk | agree | 18:03 |
| Keybuk | the same change will need to be made to drm and frame-buffer probably :p | 18:04 |
| cjwatson | frame-buffer looks OK | 18:05 |
| cjwatson | I'm going to freely admit to not understanding drm | 18:05 |
| cody-somerville | pitti, I just got from Apport: "The problem report is damaged and got not be processed. IOError(13, 'Permission Denied')." | 18:05 |
| cody-somerville | pitti, I wonder if its because the application crashed again after that report was generated. | 18:06 |
| === MacSlow is now known as MacSlow|capoeira | ||
| cody-somerville | pitti, Eww... the dialogue telling me some packages are out of date doesn't show up in my taskbar or task switcher. | 18:06 |
| * cody-somerville goes and files a bug about that one. | 18:06 | |
| Keybuk | cjwatson: are you sure? frame-buffer looks to have the exact same bug to me | 18:08 |
| cjwatson | oh, the map_address bit, duh | 18:08 |
| Keybuk | activate() will call flush_head() if it hasn't been mapped to the device yet | 18:08 |
| Keybuk | (cause I stole most of the code out of frame-buffer to write vga16fb obv.) | 18:09 |
| Keybuk | drm looks ok though | 18:09 |
| Keybuk | since it just iterates the list of heads | 18:09 |
| cjwatson | yes, you're right of course | 18:09 |
| Keybuk | which is empty | 18:09 |
| cnd | pitti: I'm trying to propose new changes for linux-firmware-nonfree using bzr+lp. I branched lp:ubuntu/linux-firmware-nonfree, made commits, pushed to ~chasedouglas/lucid/linux-firmware-nonfree, but now when I go to propose a merge back into lp:ubuntu/linux-firmware-nonfree it says "This branch is not mergeable into lp:ubuntu/linux-firmware-nonfree" | 18:09 |
| cjwatson | shall I commit this and send upstream, or would you rather wait for VCS fiddling first? | 18:09 |
| cnd | pitti: any ideas? | 18:10 |
| Keybuk | cjwatson: commit and send upstream ;-) | 18:10 |
| Keybuk | I'm not sure whether the .pc issue is deliberate or not - seems to do no harm | 18:10 |
| cjwatson | .pc is a difficult issue with 3.0 (quilt) packages; I commented on it in my blog recently | 18:11 |
| cjwatson | if you don't include it (which is my practice), then you have to run a rune after VCS checkout in order to be able to work on the quilt patches, although everything else works OK | 18:11 |
| cjwatson | if you include it, then you end up with weird extra junk in commits | 18:12 |
| cjwatson | (that touch the quilt patches) | 18:12 |
| Keybuk | do you have to bzr add the stuff inside it? | 18:12 |
| Keybuk | it's confusing me because I don't have quilt patches | 18:12 |
| cjwatson | mm, the difficult thing here is that you have format 3.0 (quilt) and you have a delta against upstream, so dpkg-source thinks it needs to generate an automatic quilt patch expressing the upstream diff | 18:13 |
| cjwatson | unless you're actually going to maintain those patches as quilt patches, then TBH I think you would be better off declaring format 1.0 right now | 18:14 |
| cjwatson | you're in a sort of halfway house | 18:14 |
| Keybuk | I can't declare format 1.0 though | 18:15 |
| Keybuk | because some of the added files are .pngs | 18:15 |
| cjwatson | oh. joy | 18:15 |
| geser | pitti: if you have some time: could you check if lp-shell from lp:ubuntu-dev-tools still works for you as expected? I've pimped it a little bit: it now supports all known LP instances, all known API versions, anonymous login and tab-completion for objects :) | 18:15 |
| Riddell | pitti: seems lex79 found the cause of bug 528907 | 18:16 |
| ubottu | Launchpad bug 528907 in hal "unable to mount disks in dolphin / hal permission denied" [High,In progress] https://launchpad.net/bugs/528907 | 18:16 |
| cjwatson | Keybuk: it would help to put 'single-debian-patch' in debian/source/options, so that the patch name doesn't change with every upload | 18:16 |
| Keybuk | cjwatson: can you do that ;-) | 18:16 |
| cjwatson | sure | 18:16 |
| cjwatson | I'm not really sure what will happen with the .pc file - I suspect you may find it's better off removed, but I guess there's no harm experimenting | 18:17 |
| Keybuk | if I remove it, the importer will just keep putting it back, no? | 18:18 |
| cjwatson | only for uploads not tagged in bzr | 18:19 |
| Keybuk | exactly | 18:19 |
| Keybuk | so better to just leave it and ignore it, surely? | 18:19 |
| cjwatson | maybe, I'm concerned that it will get stale in some odd ways | 18:20 |
| cjwatson | like I say though, it would probably be interesting to try it out and see what the failure modes are anyway | 18:20 |
| Keybuk | if there's an issue with this being there, then the importer shouldn't add it ;-) | 18:20 |
| cjwatson | 10% of Debian is using 3.0 (quilt) now, a bunch of them probably non-trivially, and we need to gain experience of various ways of handling this in bzr | 18:20 |
| Keybuk | I do find it sad/amusing/depressing/typical that Debian standardised on the most painful patch management system they could find (quilt) | 18:21 |
| Keybuk | surprised Format 3.0 didn't mandate YADA as well | 18:21 |
| cjwatson | hm, I actually find quilt works pretty well for this myself, YMevidentlyV :-) | 18:21 |
| cjwatson | the only thing I ever found painful about it totally went away when I discovered 'quilt shell' | 18:21 |
| Keybuk | it probably depends whether you separate changes out into little discreet boxes | 18:22 |
| Keybuk | or just commit as you go | 18:22 |
| cjwatson | I think dropping .pc is probably the right answer, but if we do that then we need to solve http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204 somehow, either in dpkg-dev or somewhere else | 18:23 |
| ubottu | Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open] | 18:23 |
| maco | Keybuk: i found a website thats like a cheat sheet for how to survive adding a patch to a package using quilt. was VERY happy | 18:23 |
| Keybuk | cjwatson: but as we just did; I can't drop it - any upload will mean the importer puts it back | 18:25 |
| Keybuk | so the importer should not add it | 18:25 |
| cjwatson | Keybuk: dropping .pc: I mean in the importer | 18:25 |
| Keybuk | ah right | 18:26 |
| cjwatson | but, right now, if the importer drops it, you can only work on an auto-imported 3.0 (quilt) package properly if you happen to have a copy of my dpkg-quilt-setup rune lying around | 18:26 |
| cjwatson | or something equivalent | 18:26 |
| Keybuk | that also seems pessimal | 18:26 |
| cjwatson | (the importer would need to .bzrignore it as well) | 18:26 |
| Keybuk | since the idea is that bzr co and dpkg-source -x give identical results | 18:26 |
| Keybuk | (since one day we won't have sources to -x) | 18:26 |
| cjwatson | somebody on debian-dpkg@ suggested that maybe there should be a quilt command to set up the .pc directory, in which case perhaps we could nobble bzr to call it on checkout | 18:28 |
| Keybuk | I guess the other side | 18:29 |
| Keybuk | does the importer import the result of unpacking the package | 18:29 |
| Keybuk | or the result of dpkg-source -x? | 18:29 |
| Keybuk | because if the latter, then the patches *are already applied* | 18:29 |
| cjwatson | the patches really ought to be already applied. this is good, it makes bzr blame useful | 18:29 |
| Keybuk | which surely makes quilt annoyingly hard, since you have the "can't reverse the patch because it's changed since" problem | 18:29 |
| cjwatson | no | 18:30 |
| cjwatson | works fine | 18:30 |
| Keybuk | how does it work fine? | 18:30 |
| Keybuk | let's say I checkout a source | 18:30 |
| Keybuk | and I edit it | 18:30 |
| Keybuk | and I upload | 18:30 |
| cjwatson | you refresh the patch after making your changes | 18:30 |
| Keybuk | where does my diff go? | 18:30 |
| Keybuk | no quilt commands involved in the above | 18:31 |
| cjwatson | let me rephrase: if you're actually *using* quilt, rather than trying to ignore it, then it works fine | 18:31 |
| Keybuk | I'm neither actually using quilt, or trying to ignore it | 18:31 |
| cjwatson | in your case, dpkg-source would generate one of these automated patches | 18:32 |
| cjwatson | so it would end up in debian/patches/debian-changes, as well as applied to the checkout | 18:32 |
| Keybuk | should we not rename that to ubuntu-changes for our uploads OOI? | 18:32 |
| Keybuk | a package could then conceivably have debian-changes & ubuntu-changes | 18:32 |
| Keybuk | ok, that makes sense | 18:32 |
| cjwatson | I don't have much of an opinion but my "gratuitous incompatibility" light is going off :-) | 18:32 |
| Keybuk | but then don't you run into the issue where, in order to refresh a patch, you first have to pop all the others off | 18:33 |
| pitti | geser: great work! looks fine here | 18:33 |
| Keybuk | and you have to push them all back again | 18:33 |
| cjwatson | if we did that, it should be done upstream and wired into dpkg's vendor mechanism | 18:33 |
| lex79 | pitti: should I disable also 01_at_console.patch ? | 18:33 |
| Keybuk | otherwise you can end up committing some very very weird changes | 18:33 |
| pitti | lex79: noo | 18:33 |
| Keybuk | cjwatson: I don't think it's any different to our dch behaviour | 18:33 |
| cjwatson | yes, but personally I'm fine with that | 18:33 |
| pitti | lex79: this would break everything | 18:33 |
| lex79 | ok | 18:33 |
| cjwatson | it means that I keep useful patch files that are forwardable upstream as coherent units | 18:33 |
| pitti | cnd: hm, not really; james_w might? | 18:33 |
| cjwatson | and can be described with DEP-3 headers | 18:34 |
| pitti | cody-somerville: hm, mind filing a bug with the details, which app crashed, etc.? | 18:34 |
| Keybuk | cjwatson: right, what I mean is you might accidentally commit an intermediate step? | 18:34 |
| cjwatson | I've found this invaluable in getting a handle on openssh's upstream delta | 18:34 |
| * pitti -> off for supermarket/dinner, bbl | 18:34 | |
| Keybuk | I could commit the result of popping patches | 18:34 |
| Keybuk | rather then the result of refreshing a patch partway down the stack | 18:34 |
| cjwatson | mm, perhaps there should be some kind of pre-commit hook to prevent that | 18:34 |
| Keybuk | right, that's along the lines I was thinking | 18:34 |
| Keybuk | have bzr check whether the package is sane | 18:35 |
| cjwatson | different from dch> I think the difference is that dpkg already has a vendor mechanism, so it would be worth using it | 18:35 |
| Keybuk | cjwatson: I don't disagree | 18:35 |
| cjwatson | so that our derivatives automatically get debian-changes ubuntu-changes mint-changes or whatever | 18:35 |
| Keybuk | I'm just thinking that in practice, where a package has debian-changes already | 18:35 |
| Keybuk | we really don't want to modify that patch | 18:35 |
| Keybuk | that's wrong | 18:35 |
| Keybuk | we want to add ubuntu-changes on top | 18:35 |
| Keybuk | and in very much practice, our packages should have ubuntu-changes where there were none before | 18:35 |
| cjwatson | I don't really have practical experience of this, since everything I've touched using 3.0 (quilt) has been using specifically named patches instead | 18:36 |
| Keybuk | because otherwise Debian will whinge about us claiming they changed things that we really changed :p | 18:36 |
| Keybuk | I guess it varies with workflow | 18:36 |
| Keybuk | all my packages are directly based off trunk/release branches | 18:36 |
| Keybuk | so I can pull/merge directly from HEAD, etc. | 18:36 |
| cjwatson | frex, ubuntu/openssh has 39 Debian patches, and then a "# Ubuntu additions" section at the end of debian/patches/series with two Ubuntu patches at the end | 18:36 |
| Keybuk | so for me, I find that treating the ubuntu branch simply as a branch is the best way | 18:36 |
| Keybuk | so the commits I commit to ubuntu are directly equivalent to the commits that I would commit to trunk anyway | 18:37 |
| Keybuk | so are thus directly equivalent to the patches I'd send upstream | 18:37 |
| Keybuk | in theory, I could run "git format-patch" over an ubuntu branch of a package I maintain, and mail the lot upstream | 18:37 |
| cjwatson | I tend to 'quilt new foo.patch; quilt shell; bzr merge; exit; quilt refresh' | 18:37 |
| Keybuk | except bzr doesn't have that command ;) | 18:37 |
| cjwatson | bzr send --git | 18:37 |
| Keybuk | cjwatson: nowhere near the same thing | 18:38 |
| cjwatson | yeah, ok :) | 18:38 |
| Keybuk | huh - you add a merge as a patch?! :p | 18:38 |
| cjwatson | sorry, reflex response | 18:38 |
| cjwatson | I do that because it means I can tell apart things that aren't backports from upstream from things that are | 18:38 |
| Keybuk | funny isn't it | 18:38 |
| Keybuk | we've invented a brand new system | 18:38 |
| cjwatson | and I can put a DEP-3 header at the top of the patch saying it's a merge from upstream and where it comes from and why | 18:38 |
| Keybuk | a single way of doing bzr based source packages | 18:39 |
| Keybuk | and the two of us already do them in wildly different ways <g> | 18:39 |
| cody-somerville | pitti, kk, will do | 18:40 |
| Keybuk | dpkg-source: info: building plymouth using existing ./plymouth_0.8.1.orig.tar.gz | 18:40 |
| Keybuk | dpkg-source: error: cannot read plymouth-0.8.1.orig.B9r5y0/debian/patches/debian-changes-0.8.1-1ubuntu3: No such file or directory | 18:40 |
| Keybuk | cjwatson: ^ | 18:40 |
| cjwatson | oh, I forgot to change series, sorry | 18:40 |
| Keybuk | another bzr wishlist, bzr commit --amend ;) | 18:40 |
| cjwatson | fixed | 18:41 |
| Keybuk | WFM now | 18:42 |
| cjwatson | http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/lucid/man-db/lucid/annotate/head%3A/debian/patches/man-l-assertion.patch - I find this more useful documentation than a simple merge, FWIW | 18:42 |
| cjwatson | particularly given the lack of useful cherry-pick recording in zr | 18:42 |
| cjwatson | bzr | 18:42 |
| Keybuk | but surely that's the same text you'd put in the commit log? | 18:42 |
| Keybuk | I guess again it depends on your POV :p | 18:45 |
| cjwatson | Keybuk: it's more usefully exposed to people coming along and looking later - I had very clear feedback from a number of people about openssh that the commit log was too hard to wade through when they were trying to audit changes | 18:45 |
| cjwatson | all the information was there, but it was hard to find | 18:45 |
| james_w | sorry, was at lunch | 18:45 |
| Keybuk | cjwatson: patches in ubuntu for me are either backports from trunk, or too scraggy to go upstream yet | 18:46 |
| Keybuk | but I look at trunk first | 18:46 |
| Keybuk | I 95% of the time work on trunk | 18:46 |
| Keybuk | and get around to updating the packaging branch later | 18:46 |
| Keybuk | even with Plymouth, I do all my testing on plymouth upstream GIT, not the ubuntu package branch :p | 18:46 |
| james_w | the importer aims to import the same as dpkg-source -x, but I realise that format 3.0 makes this bad in some cases | 18:46 |
| james_w | but not doing it is also bad | 18:46 |
| james_w | cnd: so you apparently pushed in to the lucid project on LP | 18:47 |
| james_w | cnd: you need to push to ~chasedouglas/ubuntu/lucid/linux-firmware-nonfree/<some descriptive branch name> | 18:48 |
| cnd | james_w: ok, I'll give that a try | 18:48 |
| cnd | james_w: looks like that fixed it, thanks :) | 18:57 |
| james_w | np | 18:58 |
| cjwatson | Keybuk: I expect that the convergence between our two ways of working will be via looms | 18:58 |
| cjwatson | Keybuk: and some kind of per-thread rather than per-commit log, to generate the DEP-3 header | 18:59 |
| cjwatson | but I'm not up for using those in production yet | 18:59 |
| Keybuk | heh | 19:02 |
| Keybuk | I still think that "bzr loomify" should output something | 19:06 |
| Keybuk | e.g. | 19:06 |
| Keybuk | $ bzr loomify | 19:06 |
| Keybuk | Welcome to the age of the Great Guilds! | 19:07 |
| Keybuk | -- | 19:07 |
| Keybuk | ^ lifeless: you should make it so ;-) | 19:07 |
| cjwatson | Keybuk: is there an upstream patch pending somewhere for the vga16fb renderer? | 19:07 |
| Keybuk | cjwatson: no, not yet | 19:08 |
| cjwatson | ok, I'll just send this for frame-buffer then | 19:08 |
| Keybuk | yup :) | 19:08 |
| zul | slangasek: can you have a look at #506985 and comment on it please? when you get a chance of course | 19:09 |
| slangasek | Keybuk: bug #551062 = 530779 - where does that leave us for lucid? Should the upstart task be targeted to lucid, or do we need to remove / suppress the nih_warn() from mountall? | 19:31 |
| ubottu | Launchpad bug 551062 in plymouth "mountall: Could not connect to plymouth (dup-of: 530779)" [High,Triaged] https://launchpad.net/bugs/551062 | 19:31 |
| ubottu | Launchpad bug 530779 in upstart "init: does not wait for parent to exit when following forks" [Medium,Triaged] https://launchpad.net/bugs/530779 | 19:31 |
| slangasek | (there's also the infinitesimal risk that the race catches just not the initial plymouth connection attempt, but also a subsequent one when mountall has something important to say) | 19:31 |
| slangasek | s/just not/not just/ | 19:31 |
| slangasek | zul: looking | 19:31 |
| zul | slangasek: thanks | 19:32 |
| slangasek | Keybuk: oh; reading more closely, I see you're taking out the initial connect, ok - when is that landing? | 19:32 |
| === radoe_ is now known as radoe | ||
| cody-somerville | nixternal, You wrote '4' instead of 'for'. How ghetto! :P | 19:36 |
| sladen | ha. "A spiffy aubergine paint job won't sell cars whose clutch, brake and accelerator pedals have been shuffled about and mounted in the passenger-side footwell." | 19:36 |
| LaserJock | I don't know, maybe Toyota should try it | 19:37 |
| LaserJock | "we know your brakes and accelerators don't work properly, but it's aubergine!!" | 19:38 |
| Keybuk | slangasek: tomorrow I think | 19:38 |
| slangasek | "clutch"? how insulting, Ubuntu is clearly an automatic and *still* gets better gas mileage | 19:38 |
| slangasek | Keybuk: ok | 19:38 |
| Keybuk | I think it's pretty hard for the real mountall-has-something-important to miss the connection being opened | 19:39 |
| slangasek | Keybuk: with the current architecture, I agree; when you've redone the main loop, I don't know :) | 19:40 |
| slangasek | zul: sorry, I was assuming I'd find an FFe here, and it's not :) what part do you want comments on? | 19:41 |
| Keybuk | slangasek: that bit shouldn't change ;) | 19:41 |
| zul | slangasek: i was wondering how you handle it? | 19:42 |
| slangasek | Keybuk: do you want me to undupe 551062 and assign it to mountall so you can get the credit in the QA team's kudos report? :) | 19:42 |
| slangasek | zul: hm, at the moment I'm not sure how you're hitting this code path - karmic shipped with rabbitmq-server 1.6.0, which is supposed to be supported; hardy didn't ship it; 1.5.4 shipped with jaunty, but jaunty->lucid upgrades are never supported | 19:43 |
| zul | slangasek: i think the LOSA are installing it manually on the servers | 19:44 |
| Keybuk | slangasek: not really ;) | 19:45 |
| Keybuk | it's only another bug number to waste half an hour trying to look up before inevitably mistyping it in the changelog anyway <g> | 19:46 |
| slangasek | Keybuk: heh | 19:46 |
| slangasek | Keybuk: would be real easy to look up, it'd be assigned to you and targeted to beta2 :-P | 19:46 |
| Keybuk | slangasek: I have 2,400 unread mails in my LP folder | 19:46 |
| Keybuk | I daren't go in there | 19:46 |
| Keybuk | as far as I know, there are dozens of bugs assigned to me and targeted | 19:46 |
| Keybuk | I treat such things like I treat bank statements | 19:47 |
| Keybuk | if I don't open them and look, then I sleep better at night | 19:47 |
| slangasek | zul: so in that case, I think a reasonable solution within the distro is to make sure the package complains loudly and the admin should fix it up by hand; I don't think the distro package should be trying to find a general solution for a very specific backport scenario | 19:48 |
| zul | slangasek: great thats what we thought as well | 19:49 |
| slangasek | Keybuk: surely it's more effective to open them and ask your teammates^W friends to take some bugs^W^W^W^W for a loan /before/ you're overdrawn :) | 19:50 |
| Keybuk | yeah but then I have to pay them back later ;) | 19:51 |
| slangasek | heh | 19:51 |
| Keybuk | I really don't look at LP much | 19:51 |
| Keybuk | I write down bugs in a notebook, and work off that day-to-day | 19:51 |
| Keybuk | I find new bugs by going through the bug list of packages I care about | 19:51 |
| Keybuk | so I really don't pay much attention to the whole assigned to thing | 19:51 |
| Keybuk | I used to | 19:52 |
| Keybuk | but then LP got a whole lot slower | 19:52 |
| Keybuk | and mdz insisted we all be bug contacts for packages | 19:52 |
| Keybuk | so now I just get too much e-mail to read | 19:52 |
| Keybuk | I worked it out, if I actually read every mail from LP, I'd finish for the day without ever getting any work done | 19:52 |
| * slangasek notes that https://bugs.launchpad.net/ubuntu/lucid/+bugs?field.assignee=scott is quite quick to load (and quite short) :) | 19:53 | |
| Keybuk | slangasek: also I find ignoring things has a useful side-effect | 19:53 |
| Keybuk | people then *talk to me* about their bugs directly :p | 19:53 |
| Keybuk | what's even funnier about that list is that the only bug on it has apparently been fixed by someone other than me <g> | 19:54 |
| slangasek | Keybuk: yeah - can I upload that? It's causing problems for kirkland in upgrade testing | 19:56 |
| Keybuk | slangasek: you haven't even committed it yet fwict, despite what the bug status says | 19:56 |
| slangasek | hmm | 19:56 |
| Keybuk | oh, no, it is there | 19:56 |
| slangasek | ok | 19:56 |
| Keybuk | but yes, sure, upload away | 19:57 |
| kirkland | slangasek: cheers, dude, thanks! | 19:57 |
| slangasek | Keybuk: btw, at a glance it appears to me that plymouth now fails entirely on an initramfs-less system, due to relying on /dev/pts; any thoughts on resolving this? | 19:59 |
| Keybuk | slangasek: it shouldn't fail - it should just not redirect console | 20:00 |
| slangasek | Keybuk: oh, then I think the fallback is broken | 20:00 |
| slangasek | before upgrading initramfs-tools, I saw plymouth fail in both the initramfs *and* the root | 20:01 |
| Keybuk | please debug and fix ;) | 20:02 |
| slangasek | yep, will look | 20:03 |
| cjwatson | Keybuk: just to be clear, is the vga16fb flush_head fix on your plate, or on mine? | 20:14 |
| Keybuk | cjwatson: oh, it can be on mine if you like | 20:14 |
| cjwatson | I'm happy either way, just don't want it to get lost | 20:14 |
| Keybuk | but if you have the patch just commit to our branch | 20:14 |
| cjwatson | ok, I have the test case in front of me so I'll JFDI then | 20:15 |
| cjwatson | (this is all in aid of making sure we have init.d output on server, if you hadn't guessed) | 20:15 |
| Keybuk | except for the lack of init.d output ;) | 20:15 |
| sebner | jdstrand: thanks for you work on twiki and moin :) | 20:16 |
| cjwatson | yeah, but you explained the bit that was involved there on Friday | 20:16 |
| cjwatson | so I can at least advance-test it | 20:16 |
| Keybuk | yeah, either adding console output to the rc.conf or changing the default | 20:16 |
| jdstrand | sebner: sure thing! :) | 20:16 |
| jdstrand | sebner: thanks for your work on them :) | 20:16 |
| * sebner hugs jdstrand :) | 20:16 | |
| jdstrand | :) | 20:17 |
| cjwatson | Keybuk: BTW, moving all this into flush_head isn't going to make it ridiculously slow or anything is it? | 20:17 |
| Keybuk | no | 20:17 |
| Keybuk | it's just making sure that the VGA is in the right drawing mode | 20:17 |
| cody-somerville | mvo, Is there any way to tell apt to forget about conflicts and what not and just download everything? | 20:18 |
| mvo | cody-somerville: like every package in the repository? | 20:18 |
| cody-somerville | mvo, No, just the packages requested and all the other packages it would normally download as dependencies or recommends. | 20:19 |
| slangasek | cjwatson, Keybuk: that doesn't happen to fix any of our vga16fb segfaults, does it? | 20:20 |
| Keybuk | slangasek: that might be the segfault yes | 20:20 |
| mvo | cody-somerville: you could just do "apt-get install -d 4g8 -o Dir::state::status=/tmp/empty-file" | 20:20 |
| cjwatson | slangasek: it fixes *a* vga16fb segfault | 20:20 |
| slangasek | ok :) | 20:20 |
| cjwatson | slangasek: I couldn't accurately tie it down to the ones I saw in LP | 20:20 |
| mvo | cody-somerville: then it will act as if you had a empty system | 20:21 |
| cjwatson | slangasek: if you can, feel free to annotate | 20:21 |
| slangasek | cjwatson, Keybuk: also, is there an outcome to the 3.0 (quilt) workflow discussion that I should be aware of when working on this package in the future? | 20:21 |
| cjwatson | it should be pretty clear, the segfault was in activate() when calling vga_* | 20:21 |
| cody-somerville | mvo, but it'll still die if you try to specify packages that conflict each other. | 20:21 |
| Keybuk | slangasek: no, I think we fixed it | 20:21 |
| slangasek | "fixed it" - so I just do what I was doing before and everything is Happi? | 20:21 |
| Keybuk | yes | 20:21 |
| zyga | hello | 20:21 |
| mvo | cody-somerville: well, you could dividie it into non-conflicting partitions? what is the use-case? a python-apt script can do with that as well | 20:22 |
| slangasek | Keybuk: ok, cool | 20:22 |
| Keybuk | well, cjwatson adding more quilt options | 20:24 |
| Keybuk | so you should be safe to ignore the .pc thing | 20:24 |
| Keybuk | though I expect it'll get wildly out of date repeatedly | 20:24 |
| Keybuk | but that shouldn't matter too much, since the source uploads will be fine | 20:24 |
| cjwatson | yeah, all I really did was keep importer-induced skew to a minimum | 20:25 |
| cjwatson | cody-somerville: you could use 'aptitude download', if all you want is "give me the .debs damnit" | 20:26 |
| cody-somerville | Interesting idea. | 20:27 |
| mvo | oh yeah, aptitude download will work too, if you just need a single deb | 20:27 |
| cody-somerville | Ah | 20:27 |
| cody-somerville | I want dependencies and recommends to get downloaded automatically too. | 20:27 |
| psusi | so... what is replacing hal? | 21:07 |
| soren | psusi: Monkeys. | 21:08 |
| psusi | lol... seriously... wasn't it responsible for say, auto mounting a usb stick and launching a nautilus window to browse it? | 21:08 |
| psusi | what does that now? | 21:08 |
| psusi | nevermind.... reading about it now on the wiki... devicekit eh? hrm... | 21:15 |
| cnd | slangasek: I'm looking into bug 551527, where nouveau through display port hangs plymouth | 21:15 |
| ubottu | Launchpad bug 551527 in linux "Dualhead NVidia Mac Mini (3,1) does not boot on clean Lucid beta 1 install" [Undecided,Confirmed] https://launchpad.net/bugs/551527 | 21:15 |
| cnd | got any ideas what could be going wrong? | 21:15 |
| cnd | it could also be nouveau + external monitor, I'm not real sure | 21:16 |
| slangasek | cnd: is that bug #533135? | 21:16 |
| ubottu | Launchpad bug 533135 in plymouth "System fails to boot with plymouth installed (nouveau driver with >1 display)" [Medium,Triaged] https://launchpad.net/bugs/533135 | 21:16 |
| cnd | slangasek: ahh, should have done a dupe search first... | 21:17 |
| cnd | slangasek: anything I can do to help? | 21:17 |
| slangasek | cnd: sure, you can dive into the DRM driver and figure out what's going wrong :) | 21:18 |
| cnd | heh, I was afraid of that :) | 21:18 |
| slangasek | the plymouth DRM backend is only used on nouveau with multiple display outputs | 21:18 |
| cnd | slangasek: how can I debug plymouth to figure out what it's doing? | 21:18 |
| slangasek | UTSL | 21:18 |
| cnd | hmmm, ok | 21:19 |
| slangasek | there are some debugging options you can set on the kernel commandline, but I don't know how useful any of them are going to be to you for this | 21:19 |
| slangasek | plymouth:debug, e.g. | 21:19 |
| slangasek | cnd: actually, assuming plymouth:debug tells you anything useful about DRM, adding plymouth:debug=file:/dev/plymouth-drm-debug.log to the kernel commandline is probably a good place to start | 21:22 |
| cnd | slangasek: thanks, I'll look into that | 21:22 |
| cnd | I'll also try the latest upstream nouveau, which will be a challenge in and of itself due to kernel->userspace abi changes :( | 21:23 |
| gtlz | alright, who broke gnome in lucid | 21:38 |
| medex | How come something like this "sudo bash -s "echo bird | passwd root; su"" drops one to a root prompt? | 21:40 |
| meanburrito920 | Does anyone here know how many slots Ubuntu has for GSoC students? | 21:54 |
| tjaalton | seems like armel buildd's fail to generate -dbg packages | 21:54 |
| jpds | meanburrito920: Best person to talk to is dholbach. | 22:11 |
| lifeless | persia: pnig | 22:23 |
| Gaming4JC | Hey all, I want to know why wvdial was dropped from LiveCD and if we can get it back before Lucid launch. | 22:37 |
| Gaming4JC | https://bugs.launchpad.net/ubuntu/+source/wvdial/+bug/400573 | 22:37 |
| ubottu | Ubuntu bug 400573 in wvdial "[include in live-cd] wvdial (1.60.1+nmu2)" [Wishlist,New] | 22:37 |
| Gaming4JC | 93 million Americans still use dial-up (recent survey at a webmaster site) and no one can connect on ubuntu without going on a package hunt in the repos from a windows box. | 22:38 |
| Gaming4JC | such a pity. | 22:38 |
| beuno | Gaming4JC, I'm pretty sure finding a package is going to be the least of their problems if they have dial up | 22:39 |
| beuno | oooops, sorry, thought this was on a different channel | 22:39 |
| beuno | ignore me, please | 22:39 |
| Gaming4JC | I use dial-up and let me tell you, once you've removed those packages it's a complete pain. lol. :P | 22:39 |
| Gaming4JC | kk | 22:39 |
| beuno | I thought this was in #ubuntuone | 22:40 |
| beuno | I'm tired :) | 22:40 |
| Gaming4JC | ah :) | 22:40 |
| slangasek | Gaming4JC: it was dropped because there's no UI for it, so it's not useful to have it installed by default. It might make sense to put it back in the package repo that ships on the CD so that users who need it (and can make heads or tails of it) can install it from there | 22:42 |
| Gaming4JC | that would be the least you could do. :) | 22:43 |
| Gaming4JC | Also, gnome-ppp is a great gui - I've no idea why it's not on the repo either | 22:43 |
| slangasek | that's for the desktop team to say; though it's a little late in the cycle to be evaluating new UI components for release-worthiness | 22:43 |
| LaserJock | I'm guessing the least they could do is remove wvdial from the archives altogether, hello tarball :-) | 22:43 |
| slangasek | actually, the *least* I could do would be to ignore this discussion entirely, but that wouldn't be very helpful :) | 22:44 |
| beuno | slangasek, that ship has sailed | 22:44 |
| slangasek | beuno: not necessarily, I could ignore the discussion going forward :-) | 22:45 |
| * beuno senses an infinite loop approaching | 22:46 | |
| Gaming4JC | Laserjock: I presume they have plans on that. :P | 22:46 |
| Gaming4JC | lol | 22:46 |
| snow_ | hi | 22:52 |
| slangasek | cjwatson: ^^ do you see any reason not to put wvdial in the ship-live seed? (Unfortunately, there doesn't seem to be an analogous component in platform to add this to) | 22:52 |
| cjwatson | it sounds exactly the sort of thing that's meant to live in that category | 22:52 |
| Caesar | There's something all shagged with the GNOME packages right now, right? | 22:53 |
| cjwatson | "stuff you need to get online" | 22:53 |
| Caesar | I'm seeing gnome-panel being uninstallable, but I'm failing to see the good reason yet | 22:53 |
| slangasek | cjwatson: yah. Only concern is that wvdial + deps is ~920k | 22:54 |
| * slangasek scopes out where we are wrt langpack seeding | 22:55 | |
| Gaming4JC | only 920 oh so precious kb. :) | 22:55 |
| slangasek | Gaming4JC: it's a CD, after all; space is not an infinite resource | 22:56 |
| slangasek | Gaming4JC: we *do* include wvdial on the DVD | 22:56 |
| Caesar | slangasek: are CDs (not DVDs) still the primary unit of concern? | 22:56 |
| Caesar | This whole offline sneakernet thing seems so last decade anyway | 22:56 |
| slangasek | Caesar: it appears to be so for Gaming4JC, else I don't think he would be inquiring :) | 22:56 |
| Gaming4JC | :) | 22:56 |
| slangasek | Caesar: anyway, if you're on dial-up, I'm doubly-sure you don't want to download a DVD ISO | 22:57 |
| Caesar | slangasek: yeah. I guess there's still people without infrastructure to net boot | 22:57 |
| Gaming4JC | totally agree. :D | 22:57 |
| Gaming4JC | lol | 22:57 |
| Caesar | There needs to be some sort of WAN PXE boot | 22:57 |
| slangasek | (the size difference between CD and DVD does have a non-negligible impact on our milestone validation) | 22:57 |
| DktrKranz | slangasek: hi! if you plan to do some archive-admin work, mind adding python-multiprocessing to sync-blacklist, so we know for sure we won't get it in Lucid + 1? TIA | 22:59 |
| slangasek | Gaming4JC: ultimately, it would be far better if we could replace wvdial, with its entire set of NIH library dependencies, with a network-manager component that does the job; we don't seem to have such a thing in the archive today | 22:59 |
| slangasek | DktrKranz: noted | 22:59 |
| DktrKranz | thanks | 22:59 |
| * Caesar glances over at libnih | 22:59 | |
| slangasek | Caesar: it's so ironic it's hip | 22:59 |
| Caesar | :-) | 23:00 |
| Gaming4JC | slangasek: Yes, that would be more logical. However, gnome-network-manger has several bug reports filed against it for not supporting dial-up anymore either as you probably know. | 23:00 |
| slangasek | Caesar: anyway, the whole upstart package is smaller than libwvstreams4.6-extras :) | 23:00 |
| * Gaming4JC considers this unbelievable... | 23:00 | |
| Gaming4JC | :P | 23:00 |
| Caesar | slangasek: fair enough | 23:01 |
| slangasek | Gaming4JC: to be honest, my solution to the last problem I had with dial-up was to talk my dad into getting DSL | 23:01 |
| slangasek | Gaming4JC: and that was with gutsy - so no, I'm not current wrt bug reports on gnome-network-manager | 23:01 |
| Gaming4JC | slangasek: I'd love to. Sadly, where I live we have no mobile, broadband, or dsl access. | 23:02 |
| Gaming4JC | I gave up after asking my local government who also said "we can't do anything". | 23:02 |
| Gaming4JC | :P | 23:02 |
| slangasek | ah, clearly you need to put in a bid for Google Fiber | 23:03 |
| Gaming4JC | oh and just ask my neighbors about Huesnet, it's pretty epic when I'm still online and they aren't. ^^ | 23:03 |
| Gaming4JC | Google Fiber? :D | 23:03 |
| * Gaming4JC googles | 23:03 | |
| Gaming4JC | off-topic: THAT LOOKS SWEEEETTTT | 23:06 |
| Gaming4JC | lol | 23:06 |
| * Gaming4JC signs up :D | 23:06 | |
| * Gaming4JC is sad to find... the deadline is up | 23:06 | |
| Gaming4JC | :'( | 23:06 |
| === sconklin is now known as sconklin-gone | ||
| slangasek | that, and I hear the application process involves either a) debasing yourself on Youtube, or b) getting your mayor to shamelessly rename your community after Google for a day... :) | 23:07 |
| Gaming4JC | "We'll collect responses until March 26, and will announce our target communities later this year. Stay tuned." | 23:09 |
| Gaming4JC | Is that typical or what <_< | 23:09 |
| Gaming4JC | *sigh* | 23:09 |
| Gaming4JC | lol | 23:09 |
| Gaming4JC | Hmm another question, any chance of getting "dexux" package into the online repo? :) | 23:15 |
| Gaming4JC | http://ubuntuforums.org/showthread.php?t=369504 | 23:16 |
| slangasek | Gaming4JC: the numbers seem to work out; doing a test build now, if it fits as expected then wvdial will be on the CD for beta2 | 23:16 |
| Gaming4JC | slangasek: Thanks, if it does you're a life saver. :D | 23:16 |
| slangasek | Gaming4JC: dexux> you should file a bug against ubuntu in Launchpad and tag it 'needs-packaging' | 23:18 |
| Gaming4JC | slangasek: Okie dokie. :) | 23:18 |
| slangasek | Riddell, nixternal: does Kubuntu have any replacement for wvdial's functionality on the desktop, or would we ideally seed it in ship-live over there as well? | 23:18 |
| slangasek | ah, liveCD build snagged on the gnome installability issue, which I shall now investigate | 23:19 |
| nixternal | cody-somerville: yeah, I saw that earlier after I sent out the email....Hey, I am from Chicago, we are a bit ghetto here :) | 23:19 |
| cody-somerville | :) | 23:20 |
| nixternal | slangasek: i don't know if kde still has a wvdial frontend/functionality...haven't used wvdial since...ummm...the 90s maybe :) | 23:20 |
| * nixternal looks | 23:20 | |
| slangasek | nixternal: well, it's not currently using wvdial /on/ the CD, but there might be a replacement I'm unfamiliar with | 23:21 |
| Gaming4JC | KDE use k-ppp, I think that's the a frontend for wvdial but I haven't used it much to know. Also, k-ppp was removed recently as well... | 23:21 |
| nixternal | yeah, that was it...ok, so it is still around then | 23:22 |
| slangasek | Caesar: so I assume your gnome installability problem is on amd64? | 23:22 |
| cjwatson | kppp is still in the archive for lucid | 23:22 |
| slangasek | cjwatson: can you bump the build score for gnome-panel/amd64? | 23:22 |
| nixternal | yeah, kppp is installed out of the box with kubuntu | 23:22 |
| cjwatson | it does not appear to depend on wvdial | 23:22 |
| cjwatson | slangasek: done | 23:23 |
| slangasek | ta | 23:23 |
| * Gaming4JC might switch to Kubuntu... if it comes with working kppp | 23:23 | |
| Gaming4JC | lol | 23:23 |
| Gaming4JC | Ubuntu is so much nicer though ^_^ | 23:24 |
| slangasek | DktrKranz: blah, so why does python-multiprocessing keep getting reuploaded to Debian and when is it going away? | 23:29 |
| slangasek | DktrKranz: blacklisted | 23:30 |
| Caesar | slangasek: yes, amd64 | 23:35 |
| Caesar | (we only tend to care about amd64 these days) | 23:35 |
| Caesar | Aha, I see | 23:36 |
| Caesar | So I need to wait for the next archive run? | 23:37 |
| Caesar | Is there somewhere I can get visibility into the autobuilder-equivalents, for future enlightenment? | 23:37 |
| cjwatson | it should all be visible - which bit? | 23:38 |
| cjwatson | https://launchpad.net/ubuntu/+source/gnome-panel had links to build records, in this case | 23:38 |
| * Caesar looks | 23:39 | |
| cjwatson | or rmadison -u ubuntu is useful | 23:39 |
| Caesar | Yeah, I used rmadison after slangasek mentioned amd64 | 23:39 |
| cjwatson | and https://launchpad.net/builders/ has a buildd activity overview | 23:39 |
| === MacSlow|capoeira is now known as MacSlo | ||
| === MacSlo is now known as MacSlow | ||
| Caesar | I mean I'd naively assume from what I saw with rmadison that the next archive run would solve my problem, but I wanted to know how to be sure | 23:40 |
| cjwatson | anything uploaded (unless it needs to go through NEW) before the top of the hour will be in ACCEPTED for the publisher run at :03 | 23:40 |
| cjwatson | and should generally be world-visible by :45 or so | 23:41 |
| Caesar | Very cool | 23:41 |
| Caesar | So the archive changes hourly? | 23:41 |
| jpds | It gets published hourly. | 23:42 |
| cjwatson | this applies except in the hour of 0400 (and possibly 0500) UTC, when it tends to be busy generating Contents files instead | 23:42 |
| Caesar | We really need to do something about our internal mirroring :-( | 23:42 |
| jpds | [Mirrors are generally asked to sync every 6 hours]. | 23:42 |
| Caesar | jpds: right | 23:43 |
| Caesar | But if our last 6 hourly sync was bogus, we have a long time until it gets de-bogusified | 23:43 |
| jpds | Caesar: How are you mirroring? rsync? | 23:46 |
| Caesar | jpds: currently HTTP, but I want to get it swapped over to rsync in the next couple of days | 23:48 |
| lifeless | oh oh oh I smell beta tester | 23:49 |
| Caesar | FYI it looks like lithium.canonical.com doesn't have its rsync configured the same way as drescher, prat and jackass. #ubuntu-mirrors for that? | 23:53 |
| elmo | the configs are identical AFAICT | 23:55 |
| elmo | what are you seeing? | 23:55 |
| Caesar | elmo: no banner from lithium | 23:56 |
| elmo | lala | 23:56 |
| elmo | fixed | 23:56 |
| Caesar | :-) | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!