| === cody-somerville_ is now known as cody-somerville | ||
| HorizonXP | i need to recompile a package. how do I figure out what configure options were being used in the default package? | 00:37 |
|---|---|---|
| RAOF__ | HorizonXP: Probably better asked in #ubuntu-motu, but the answer will be in debian/rules. | 00:37 |
| HorizonXP | RAOF__: thanks. but what's motu stand for? | 00:38 |
| === RAOF__ is now known as RAOF | ||
| NCommander | Any archive admins around? | 01:18 |
| calc | is the new motd package update information buggy? | 04:10 |
| calc | it claims i can update package but when i go and try to do so apt-get claims there is nothing to update | 04:10 |
| calc | apparently update-motd isn't being run when it should be | 04:11 |
| calc | hmm perhaps it just hadn't been 10m since i updated, i'll have to watch it more closely next time | 04:14 |
| pitti | Good morning | 06:19 |
| dholbach | good morning | 06:30 |
| * slangasek waves | 06:53 | |
| dholbach | hiya slangasek | 06:53 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | Is there a GUI tool to configure ufw in Ubuntu? | 07:46 |
| iulian | gui-ufw IIRC. | 07:54 |
| iulian | It's gufw. | 07:55 |
| tkamppeter | iulian, thanks. Strange is that it is in universe, but ufw is in main. So the standard installation ships with firewall but without config ttol. | 09:12 |
| stdin | ufw is a config tool | 09:13 |
| stdin | the firewall is in the kernel (iptables) | 09:13 |
| slangasek | tkamppeter: it's intended that the primary mode of operation for ufw should be entirely hands-off to where users don't have to configure it for the common case; the GUI wasn't part of the original spec (though eventually we ought to support full configuration through some GUI) | 09:56 |
| dholbach | thanks pochu :-) | 10:11 |
| pochu | yw :) | 10:12 |
| pochu | nice page btw | 10:12 |
| dholbach | it's been there for ages :) | 10:13 |
| dholbach | not exactly used muchly, I guess :) | 10:13 |
| pochu | was it linked from the header too? | 10:13 |
| dholbach | pochu: yes | 10:14 |
| cody-somerville | slangasek: Can you allow libxfcegui4 through the NEW binary queue? Its holding up the new xfce4.6 from building. | 10:19 |
| slangasek | cody-somerville: I'm processing the new queue this morning ,yes. | 10:19 |
| === asac_ is now known as asac | ||
| Riddell | kees: did you do the security review of quassel? bug 317892 | 10:38 |
| ubottu | Launchpad bug 317892 in quassel "Quassel main inclusion report" [Undecided,Incomplete] https://launchpad.net/bugs/317892 | 10:38 |
| Riddell | asac: poke on bug 314778 | 10:38 |
| ubottu | Launchpad bug 314778 in google-gadgets "Main inclusion for Google Gadgets" [Undecided,New] https://launchpad.net/bugs/314778 | 10:38 |
| * asac looks | 10:39 | |
| Riddell | asac: also polite poke on bug 319571 319998 320012 320028 :) | 10:40 |
| ubottu | Launchpad bug 319571 in policykit-kde "policykit-kde inclusion to the main repository" [Undecided,New] https://launchpad.net/bugs/319571 | 10:40 |
| asac | Riddell: please upload gadgets with the patch | 10:41 |
| Riddell | asac: ok | 10:41 |
| asac | Riddell: err | 10:41 |
| asac | +debian/google-gadgets/usr/lib/google-gadgets/modules/smjs*.so usr/lib/google-gadgets/modules | 10:41 |
| asac | isnt that exactly the part we dont want? | 10:42 |
| asac | Riddell: ^? | 10:43 |
| Riddell | asac: would have thought it was the gtkmozilla bits that were the problem | 10:45 |
| Riddell | asac: that file isn't linked to anything unusual | 10:45 |
| asac | Riddell: the problem is the js/ | 10:45 |
| asac | Riddell: its using the js glue that is shipped in source | 10:45 |
| asac | hence you wont see any libs with ldd | 10:45 |
| asac | Riddell: please check whether the smjs module interfaces with jsapi.h et al | 10:45 |
| Riddell | asac: yes looks like it does | 10:46 |
| asac | Riddell: the gtkmozembed stuff should be ok | 10:47 |
| asac | the ./extensions/smjs_script_runtime is the problem here | 10:47 |
| Riddell | asac: and remind me again what the problem is? | 10:48 |
| asac | Riddell: https://bugs.edge.launchpad.net/ubuntu/+source/google-gadgets/+bug/314778/comments/1 | 10:48 |
| ubottu | Launchpad bug 314778 in google-gadgets "Main inclusion for Google Gadgets" [Undecided,New] | 10:48 |
| Riddell | asac: so it does runtime loading of the mozjs library? | 10:50 |
| asac | Riddell: yes. it loads the mozjs library and assumes ABI/API stability - for which there exists no policy | 10:50 |
| Riddell | asac: they really should have used webkit :) | 10:51 |
| Riddell | asac: oh well, it doesn't work without that smjs bit so best just reject the MIR | 10:51 |
| asac | Riddell: what would be the loss if we dont have that in main= | 10:51 |
| asac | ? | 10:51 |
| Riddell | asac: people couldn't use google gadgets inside KDE's plasma, no major problem currently for users, might make upstream upset that they added support for something which doesn't get shipped but we can live with that | 10:52 |
| === dwatson is now known as davewatson | ||
| asac | Riddell: i talked to the google gadget guy about this a while a go | 10:56 |
| asac | at that time i didnt know it would become a kde lib | 10:56 |
| asac | Riddell: he understood the problem and said he didnt care for now. | 10:56 |
| Riddell | asac: that's fine, it's not a big loss at all | 10:56 |
| asac | Riddell: we also had discussion about this with spidermonkey folks ... who weren't aware that ABI/API policy is important to have. but now they know so hopefully they'll fix it soonish | 10:57 |
| asac | Riddell: complaining to them that something didnt made it into ubuntu might help to increase priortiy | 10:57 |
| asac | Riddell: so in case upstream gets upset tell them to file a bug about this against spidermonkey | 10:57 |
| asac | to reemphasize the point | 10:58 |
| Riddell | asac: can it be fixed? surely it would take mozilla to create the stable ABI? | 10:58 |
| Riddell | oh, spidermonkey is mozilla upstream | 10:58 |
| asac | Riddell: yes. | 10:58 |
| ogra | cjwatson, i'm a bit confused, looking at config.initramfs in busybox tells me that we dont enable stty, but trying out a debian etch arm initramfs in qemu stty is available, do we have a delta here (i cant seem to find a big difference) | 11:18 |
| * ogra is writing an initramfs script for arm that relies on stty in some functions | 11:18 | |
| ogra | no mention of stty in our changelog either | 11:19 |
| cjwatson | ogra: probably comes from some other package than busybox | 11:24 |
| ogra | (initramfs) help|grep stty | 11:24 |
| ogra | strings stty swapoff swapon sync sysctl syslogd tac tail tar | 11:24 |
| ogra | doesnt look like | 11:24 |
| ogra | though thats debian etch | 11:24 |
| cjwatson | don't know then, sorry. it's not in my initramfs according to 'help' | 11:25 |
| ogra | ah, k, probably debian just puts a different busybox in there | 11:26 |
| cjwatson | Debian doesn't have a busybox-initramfs | 11:26 |
| cjwatson | that's something jbailey added for us that never got merged | 11:26 |
| ogra | or *did* put a diffenrent one there | 11:26 |
| ogra | ah, right, that would explain it | 11:26 |
| * ogra would like to see stty enabled in ours then, do you think thats a prob ? | 11:27 | |
| cjwatson | ogra: no, could you please file a bug with the reasons so that we have a record though? | 11:35 |
| ogra | yep, though the spec that relates to isnt completely up to date yet but i can explain in the bug | 11:36 |
| soren | cjwatson: Waht do they have instead, then? | 11:52 |
| ogra | cjwatson, bug 321424 (sorry for the longish explanation, that will need to go into https://wiki.ubuntu.com/Specs/ARMSoftbootLoader actually) | 11:53 |
| ubottu | Launchpad bug 321424 in busybox "please enable stty in busybox initramfs" [Undecided,New] https://launchpad.net/bugs/321424 | 11:53 |
| ogra | soren, we'll need to talk about vm-builder arm images in berlin :) ... (i'd like to replace http://people.ubuntu.com/~ogra/arm/build-arm-rootfs by it if possible) | 11:54 |
| soren | ogra: Sure. | 11:54 |
| ogra | great | 11:54 |
| ogra | i'm not sure it can fulfill all purposes, but surely replace a lot already | 11:55 |
| cjwatson | soren: not sure, I think it's an ordinary unreduced busybox package | 11:55 |
| soren | cjwatson: Oh. | 11:55 |
| soren | cjwatson: I thought you meant they didn't have a busybox in their initramfs. :) | 11:56 |
| soren | It *did* sound odd :) | 11:56 |
| cjwatson | I really don't approve of this plan to run update-grub for arm | 11:56 |
| cjwatson | other architectures have their own bootloader configuration schemes; there is no reason why arm cannot | 11:56 |
| ogra | cjwatson, well, why reinvent the wheel ? | 11:56 |
| ogra | we can call it differently but its only a script | 11:57 |
| cjwatson | there is already more than one wheel of different shapes and sizes :-P | 11:57 |
| ogra | the advantage is that we dont have to modify the kernels at all | 11:57 |
| cjwatson | lazy | 11:57 |
| ogra | no, cautious about maintenance overhead | 11:57 |
| ogra | we have a workinf system, why not use it | 11:57 |
| cjwatson | also, if you focus on mimicking grub in every last detail, then you'll find that you get screwed when we switch to grub2 - suddenly you'll look old | 11:57 |
| ogra | *working | 11:57 |
| cjwatson | this is not a problem for powerpc (yaboot/kboot) hppa (palo) sparc (silo) ia64 (elilo) | 11:58 |
| cjwatson | implement your own configuration scheme - don't hijack grub's | 11:58 |
| cjwatson | at least not unless you are actually using grub | 11:58 |
| ogra | well, it doesnt need to be called menu.lst at all :) | 11:58 |
| cjwatson | the kernel hook for this stuff is trivial, which is why I said "lazy" | 11:59 |
| Keybuk | then the script does not need to be called update-grub | 11:59 |
| ogra | i wouldnt like to rewrite update-grub just to have something that produces the actually same output | 11:59 |
| ogra | Keybuk, thats what i say | 11:59 |
| doko_ | lool, seb128: plesae could you apply the two recent pulseaudio patches seen here (http://cvs.fedoraproject.org/viewvc/devel/gstreamer-plugins-good/) afaiu these are taken from upstream. | 12:00 |
| ogra | i want the identical functionallity with identical output and dont want to add a new source package for that to the archive, so we dont have to maintain the same thing twice | 12:00 |
| ogra | (and arm benefits from fixes of that script on x86) | 12:01 |
| cjwatson | you clearly aren't going to implement all of grub's commands | 12:01 |
| ogra | nah | 12:01 |
| cjwatson | I'm concerned that if you emulate update-grub, people will be misled | 12:01 |
| ogra | there is no grub shell | 12:01 |
| Keybuk | what if the fix on x86 changes the output in a way that you can't parse? | 12:01 |
| ogra | i fix the parser | 12:01 |
| Keybuk | I bet you won't | 12:01 |
| Keybuk | I'll bet you'll file a bug on update-grub | 12:01 |
| cjwatson | what if it's an emergency fix for i386 two days before release? | 12:02 |
| cjwatson | by the way, other bootloaders have a *much* simpler configuration file format than grub does | 12:02 |
| cjwatson | and of course grub2 has a completely different configuration file format | 12:02 |
| ogra | hmm, that would be bad indeed, but i doubt update-grub will just change its output format, i somewhat rely on the backwards compatibility it will have to have | 12:03 |
| cjwatson | it only needs to have backwards compatibility for grub itself | 12:03 |
| slangasek | and if we're talking about menu.lst, the format is a source of longstanding bugs in Ubuntu anyway | 12:03 |
| cjwatson | right, it's an awful thing to emulate | 12:03 |
| cjwatson | (I'm happy to add stty and have done so) | 12:04 |
| ogra | if you look at my script, all it does is read "default", "hiddenmenu", "timeout" and the various "kernel", "title" and "append" data | 12:04 |
| Keybuk | ogra: so you're _not_ handling the full grub configuration? | 12:04 |
| slangasek | asac: hmm, I think maybe in jaunty NM is finally really letting me store my wireless settings as a system connection ("available to all users"); in the process, it also seems to disappear from the list of connections I'm allowed to edit from the GUI :) | 12:04 |
| ogra | nah, its not a grub shell | 12:04 |
| Keybuk | then you shouldn't copy update-grub | 12:05 |
| ogra | but i rely on the format of menu.lst | 12:05 |
| Keybuk | write yourself a much simpler format | 12:05 |
| ogra | and it indeed helps to have it using kopt etc on the update-grub script side | 12:05 |
| slangasek | yes, those are the broken things that you should avoid emulating at all costs | 12:05 |
| ogra | i dont emulate anything on that side | 12:05 |
| ogra | i planned to raly on update-grub for this | 12:06 |
| slangasek | s/emulating/inheriting/ | 12:06 |
| ogra | *rely | 12:06 |
| cjwatson | you're talking as if update-grub is something good | 12:06 |
| cjwatson | it's actually a pile of historical cruft that is the source of many bugs | 12:06 |
| ogra | the only thing i care for is to parse the uncommented lines of menu.lst | 12:06 |
| slangasek | kopt is the single largest reason I want us to switch to grub2 | 12:06 |
| ogra | and i dont want to care for the side that generates it | 12:06 |
| cjwatson | carrying it over to a new architecture is saddling that architecture with a bunch of complex history right from the start | 12:07 |
| cjwatson | every single other architecture that doesn't use grub created its own simple file format | 12:07 |
| cjwatson | I see no reason for armel to be different | 12:07 |
| ogra | writing the whole update-grub side *additionally* is a waste of manpower imho | 12:07 |
| cjwatson | so don't do something as complex as update-grub | 12:07 |
| ogra | but indeed i can do that | 12:07 |
| cjwatson | there is absolutely no need for it | 12:07 |
| ogra | note that the script is also supposed to read syslinux.cfg (as i noted in the bug description) | 12:08 |
| slangasek | most of update-grub is a crutch for a broken file format. If you get your format right (by not copying grub's), you don't need it. | 12:08 |
| cjwatson | you've had a bad case of feature creep before you've even got started! | 12:08 |
| lool | ogra: Err right I have to agree with cjwatson about menu.lst parsing | 12:09 |
| lool | I thought that was just for experimentation | 12:09 |
| ogra | the trampoline initramfs script side doesnt care at all what is in the target system it just wants a kernel, initrd and append line from a file | 12:09 |
| cjwatson | syslinux's format is certainly more the sort of thing I would aim for if I were doing this, but I'd only implement *one* format | 12:09 |
| lool | ogra: Also I'm rather unconfortable with having a custom implementation of a boot menu based on stty | 12:09 |
| ogra | lool, well, i wanted to keep the implementation work as low as possible | 12:09 |
| lool | I'd rather either have it very dumb or integrate some lib such as libreadline or libncurses to do it | 12:09 |
| ogra | lool, well, the script is done | 12:10 |
| ogra | but i can throw it away if you prefer | 12:10 |
| lool | I can look at it and tell you whether I think we should throw it away; without looking at it I think we should, but perhaps I'll change my mind | 12:10 |
| asac | slangasek: so i guess the settings are properly saved? can any user use it afterwards? | 12:11 |
| lool | But I need to go for lunch | 12:11 |
| lool | bbl | 12:11 |
| ogra | lool, feel free to do so :) | 12:11 |
| slangasek | asac: they are properly saved; I'll let you know on next reboot whether it comes up automatically before login | 12:11 |
| ogra | lool, http://people.ubuntu.com/~ogra/arm/bootmenu (for post lunch inspection) :) | 12:11 |
| ogra | lool, it is executable on any x86 system in a terminal for testing atm ... | 12:12 |
| asac | slangasek: do you see the connection in the applet at all? or just not in the editor? | 12:12 |
| slangasek | asac: it shows up in the applet, just not in the editor | 12:13 |
| asac | ah ok. | 12:13 |
| slangasek | asac: but, er, killing nm-applet kills the connection | 12:13 |
| slangasek | so apparently upstream and I still have jarringly different definitions of a "system" connection. :P | 12:14 |
| cjwatson | hm, http://launchpadlibrarian.net/21642741/buildlog_ubuntu-jaunty-lpia.busybox_1%3A1.10.2-2ubuntu2_FAILEDTOBUILD.txt.gz looks like a libc6-dev/linux-libc-dev bug | 12:14 |
| cjwatson | busybox doesn't redefine iphdr | 12:14 |
| ogra | oh | 12:14 |
| * ogra wonders why that didnt show up before | 12:15 | |
| doko_ | TheMuso: any idea about http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=284 ? | 12:15 |
| cjwatson | linux-lpia only recently went to 2.6.28 | 12:15 |
| ubottu | icedtea.classpath.org bug 284 in IcedTea "fails to build with pulseaudio-0.9.14" [Normal,New] | 12:15 |
| cjwatson | so, recent change | 12:15 |
| ogra | ah, right | 12:15 |
| asac | slangasek: so what did you do: take a currently connected user connection and made a system one out of it;)? | 12:16 |
| cjwatson | amitk: could you look at http://launchpadlibrarian.net/21642741/buildlog_ubuntu-jaunty-lpia.busybox_1%3A1.10.2-2ubuntu2_FAILEDTOBUILD.txt.gz? it looks as if the lpia headers are a bit broken | 12:16 |
| slangasek | asac: right, my "auto" wireless connection still doesn't come up until nm-applet is launched. Gar. | 12:16 |
| slangasek | asac: yes, that's what I did. Is there any reason that shouldn't work? | 12:17 |
| cjwatson | amitk: oh, hmm, never mind, now I get an identical build failure on i386 too | 12:17 |
| slangasek | (it didn't interrupt my connection until killing nm-applet) | 12:17 |
| asac | slangasek: well. if you didnt reconnect, the connection would still be a user one | 12:17 |
| slangasek | asac: from a UI standpoint, that makes no sense whatsoever | 12:17 |
| slangasek | and from a functionality standpoint, I still want to punch NM for Doing It Wrong | 12:18 |
| ogra | cjwatson, our busybox isnt linked against klibc atm, right (so we need glibc in the initramfs) ? | 12:18 |
| asac | i think the idea is that you dont want to break network when user is flagging stuff as system | 12:18 |
| asac | once the applet disappears it should automatically go to the system one | 12:18 |
| slangasek | asac: but even after killing NM, nm-system-settings, and nm-applet, then restarting NM, the connection doesn't come up until I launch nm-applet | 12:19 |
| asac | slangasek: thats a bug. a system connection that is set to auto should show up. maybe it just takes a while= | 12:19 |
| slangasek | oh, and the user-level profile is back again | 12:19 |
| asac | ? | 12:19 |
| cjwatson | ogra: yes. everyone else is following the same trend | 12:19 |
| slangasek | asac: how long of a while should it take? If I launch nm-applet, the connection is instantaneous | 12:19 |
| asac | slangasek: it could be that starting applet triggers scanning. | 12:20 |
| cjwatson | ogra: because many initramfses need things like mdadm, devmapper utilities, or whatever as well, and as soon as you include one of them you need glibc anyway - or else you need two versions of everything, and the klibc one gets much less testing and ends up being buggier | 12:20 |
| asac | slangasek: but first thing you should check out is if it connects ata ll without nm-applet ;) | 12:20 |
| slangasek | asac: ah. how could I trigger a scan manually w/o nm-applet, to confirm whether that's the case? | 12:20 |
| slangasek | asac: ok, how long should I wait for it to connect w/o nm-applet before declaring it broken? | 12:21 |
| asac | slangasek: not through nm ... but you can send a dbus message to wpasupp | 12:21 |
| ogra | cjwatson, yes, i know the reason, but its unlikely we need it in that setup | 12:21 |
| asac | slangasek: assuming that you kill/restart all i would suggest that you tail the syslog | 12:21 |
| asac | and see if something is happening | 12:21 |
| cjwatson | ogra: I'm even less keen on using klibc extensively on arm | 12:21 |
| ogra | and we have very limited space in the flash usually | 12:21 |
| asac | should be easy to identify whether NM does something ... or just nothing | 12:21 |
| cjwatson | testing is light enough as it is | 12:21 |
| ogra | agreed | 12:22 |
| ogra | though 77k vs 1.1M is quite a difference | 12:24 |
| slangasek | Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): bringing up device. | 12:24 |
| slangasek | Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): preparing device. | 12:25 |
| slangasek | Jan 26 04:23:37 dario NetworkManager: <info> (wlan0): deactivating device (reason: 2). | 12:25 |
| slangasek | asac: ^^ | 12:25 |
| slangasek | asac: then some other stuff, again, doesn't bring the connection up until nm-applet is started | 12:26 |
| * pitti discovers https://addons.mozilla.org/en-US/firefox/addon/5817 (SQLite manager), nice tool | 12:27 | |
| slangasek | asac: should I file a bug report at this point with the full grep NetworkManager /var/log/syslog? | 12:33 |
| asac | slangasek: yes. can you also leave instructions which steps you used to create the system connection | 12:36 |
| slangasek | asac: sure. That part should either work or not, though, shouldn't it? I.e., if there's a config under /etc/Network/system-connections, that should do it? | 12:37 |
| asac | slangasek: in theory yes. but also attach that system connection file then please | 12:38 |
| asac | sanitize your psk or other secrets ;9 | 12:38 |
| slangasek | ok | 12:38 |
| asac | thanks | 12:39 |
| slangasek | asac: how about the nm/hal/openvpn bug, btw? Do you agree that keying on the device is correct, or disagree, or are you still thinking it over? | 12:46 |
| === Kmos_ is now known as Kmos | ||
| lool | ogra: it's not remotely as ugly as I feared, but I remain unhappy that we start a mini UI lib in shell and in the initramfs | 12:49 |
| lool | The sed foo is awful though | 12:50 |
| ogra | lool, hey, its my first attempt :) | 12:50 |
| ogra | i just wanted it to work for now ... beutification can happen later | 12:51 |
| lool | I'm referring to this line: cat ${FILE}|grep ^kernel|sed -s 's/^kernel//g'|sed -s 's/ /_/g'|sed -s 's/\t//g'|tr '\n' ' ' | 12:51 |
| ogra | yes | 12:51 |
| ogra | there are more like this | 12:51 |
| slangasek | sed -n -e's/^kernel//p' $FILE | ... | 12:51 |
| ion_ | slangasek: No, the following substitutions can be added to the same sed invocation as well. | 12:52 |
| Chipzz | lool: I was thinking the same thing :) | 12:52 |
| Chipzz | but hey, if it works, it's good enough for a first try :) | 12:52 |
| slangasek | ion_: not without quite a bit of pain, due to the /p | 12:52 |
| ion_ | slangasek: Easy: /foo/ { s/foo/bar/; ...; p } | 12:52 |
| ogra | right, after beautification it should be a single sed command | 12:53 |
| asac | slangasek: hmm. maybe we should look at the driver info field. In syslog NM spits out a driver for each device it looks at ... what do you see there? | 12:53 |
| asac | is that NULL? | 12:54 |
| ogra | lool, though if we drop the menu.lst support anyway we can as well drop the ugly stuff ;) | 12:54 |
| slangasek | asac: Jan 26 04:54:56 dario NetworkManager: <info> tap0: driver is 'NULL(info.linux.driver)'. | 12:56 |
| slangasek | asac: ... because that information comes from traversing net.originating_device :) | 12:56 |
| asac | slangasek: yeah. but now that i see that log entry i remember that there were even bogus drivers out there that didnt have a linux.driver | 12:56 |
| asac | so lets really use the parent | 12:57 |
| asac | and hardcode /computer | 12:57 |
| asac | i will ask upstream what they think | 12:57 |
| lool | ogra: I don't quite know what you had in mind with the _ transliteration, I don't see how you get the original _ back | 12:57 |
| lool | sed -rn '/^kernel[[:space:]]/ { s/kernel[[:space:]]+//; y/ /_/; p }' /boot/grub/menu.lst | 12:57 |
| lool | /vmlinuz-2.6.28-5-generic_root=/dev/mapper/raid1-root_ro___crashkernel=384M-2G:64M@16M,2G-:128M@16M | 12:57 |
| ogra | lool, its only substituted for the UI, that surely needs a cleaner solution | 12:58 |
| lool | ogra: But back to the stty concerns | 12:58 |
| ogra | tell me | 12:58 |
| lool | ogra: Consider ^?: that's not necessarily the backspace char in all terms AFAIK | 12:59 |
| ogra | well, it only has to work in intramfs | 12:59 |
| ogra | *init | 12:59 |
| lool | What if I press a function key? Is the sequence swallowed or does it generate stuff? | 12:59 |
| ogra | and i havent even tried it there yet | 12:59 |
| ogra | its swallowed | 13:00 |
| ogra | try it out :) | 13:00 |
| lool | How do you tell how many chars to swallow? | 13:00 |
| ogra | if there need to be adjustments for the tty in initramfs i'll do them | 13:00 |
| ogra | the dd only reads one byte ... | 13:00 |
| ogra | and i capture only the last piece of that | 13:01 |
| === davmor2 is now known as davmor2-lunch | ||
| lool | ogra: With bash I get garbage and can't do anything but ^C | 13:01 |
| lool | With busybox sh I don't get a kernel list | 13:01 |
| ogra | its not written in bash | 13:01 |
| * ogra tried with ash | 13:01 | |
| ogra | as thats the compiled in shell | 13:02 |
| ogra | you should also probably call it with LANG=C .... | 13:02 |
| ogra | there wont be translations in initramfs | 13:02 |
| lool | It flashes when I change lines with /bin/sh | 13:02 |
| ogra | it redraws, indeed, flashing isnt avoidable if you do it in shell ... that would require C | 13:03 |
| ogra | lool, thats not a final implementation and it only has to work in one single environment | 13:04 |
| ogra | its just a proof of concept weekend hackery | 13:04 |
| slangasek | asac: bug filed (321442) | 13:04 |
| lool | ogra: If I press B, the cursor goes down | 13:04 |
| ogra | right, thats a bug i will need to tackle ... but not really bad | 13:05 |
| lool | ogra: I think flashing would be avoided if you would draw on top of it and clearing until the end of the line instead of clearing the screen | 13:05 |
| ogra | it doesnt do any harm | 13:05 |
| lool | ogra: Anyway my point is your point: let's not reinvent the wheel | 13:05 |
| ogra | thats actually a good idea | 13:05 |
| lool | There are libs to do exactly this | 13:05 |
| lool | Starting with readline and ncurses | 13:05 |
| ogra | which we need to pull into a way to big initramfs | 13:06 |
| ogra | i strongly disagree | 13:06 |
| ogra | we dont have the space | 13:06 |
| ogra | if it needs to be in C thats fine, but adding additional libs is a nono imho | 13:06 |
| lool | So let's link it statically since this is basically part of the boot loader | 13:07 |
| ogra | which makes it big as well | 13:07 |
| ogra | no way how you link it, you will have added size | 13:07 |
| ogra | *s/way/matter/ | 13:08 |
| lool | But it will be maintainable, stable, and best of all maintained by someone else | 13:08 |
| ogra | my target was to eep it as small as possible and work with the available bits and pieces | 13:08 |
| ogra | *keep | 13:08 |
| ogra | size is our biggest concern in that whole setup | 13:08 |
| ogra | which is why i went with an ash script | 13:09 |
| lool | I don't think having a complex menu is critical | 13:09 |
| primes2h | pitti: Thanks for accepting my patch. | 13:09 |
| lool | For instance the MBR from the mbr package only allows you to press 1234AD or something similar | 13:09 |
| ogra | lool, surely not ... neither is line editing | 13:09 |
| lool | Do we need line editing? | 13:10 |
| ogra | if ou want to drop splash for a kernel line | 13:10 |
| ogra | if find the line editing one of the biggest grub features we have | 13:10 |
| lool | The more hacks keep piling, the more I think that the whole shim idea should die | 13:10 |
| ogra | if i mess up with a broken kernel *and* update-grub didnt do the right thing, i can still hit ESC and edit manually to get my system booting | 13:11 |
| ogra | lool, yes, but what do we do then ? | 13:11 |
| lool | If we had 1 MB to spend in the NOR flash for something, we could spend it in redboot drivers for the display and usb keyboard | 13:11 |
| lool | I realize it's not the same type of development, but I definitely think we're piling hacks to solve the problem in the wrong way | 13:11 |
| ogra | that doesnt help with an inaccessible flash | 13:11 |
| lool | An inaccessible flash? | 13:12 |
| ogra | my concern is that o enduser should have to use serial ports ... and we have boards where we dont have access to the flash at all | 13:12 |
| ogra | my current solution would allow you to boot a livesystem from USB or CD ... and would be able to fall back to an internal disc | 13:13 |
| lool | We don't know what space constraints or driver we have on other boards; we don't even know whether we will have the room to store a kernel or an initramfs in the flash | 13:13 |
| ogra | without having to add much more to the script (beyond stealing some detection mechanisms from casper) | 13:13 |
| ogra | i totally agree that all we do here should be done by the bootloader in a proper way | 13:15 |
| ogra | but as it is today we have at least three different boot methids and none of them will be able to grow the support we want | 13:15 |
| lool | ogra: What bothers me is that we're piling hack on hack to make this a more standard user friendly experience, but the result is a more fragile, more complex, and imperfect result | 13:16 |
| ogra | i dont see the fragility in my attampt though ... its not more fragile than casper | 13:16 |
| lool | This is combined with the fact that we're loading two kernels and using kexec | 13:16 |
| ogra | i have concerns about kboot and petitboot | 13:17 |
| ogra | kexec is a method even out kernel team uses | 13:17 |
| ogra | so it gets testing in the right place | 13:17 |
| lool | Consider 1) a safe validated kernel which we update from time to time in the flash, and QA before releasing Ubuntu and 2) one first static kernel, + special initramfs, with custom shell library to draw a menu and detect the root which kexecs another one | 13:17 |
| ogra | how do you achieve 1 ? | 13:18 |
| lool | kexec was broken a week ago and nobody noticed | 13:18 |
| ogra | i'm fully with you if you have a solution | 13:18 |
| lool | 1) is how we got the board | 13:18 |
| ogra | lool, dont forget i was the biggest opponent to the softbootloader in the beginning (if you remember) but not seeing any better solution made me change my mind | 13:19 |
| ogra | i think its a crazy solution that sucks ... but its the one that sucks least | 13:19 |
| ogra | at least if it comes to user experience, liveFS handling and updates | 13:20 |
| pitti | primes2h: thanks for fixing it :) | 13:22 |
| apw | tseliot, about? | 13:36 |
| === LucidFox_ is now known as LucidFox | ||
| tseliot | apw: ? | 13:39 |
| apw | tseliot, hi ... been looking at some panics which upstream is blaming on the nvidia driver | 13:41 |
| apw | wanting to go back to the users and ask them what drivers they are using and get them to test with the latest | 13:41 |
| tseliot | apw: in which distribution? | 13:41 |
| apw | and am coming up short understanding how we decide which one is installed | 13:41 |
| * directhex is wondering when to expect an nvidia driver with support got gtx 285 and 295 | 13:41 | |
| apw | ubuntu, intrepid and jaunty | 13:41 |
| apw | and i guess it makes sense to say ... have you heard anything on them | 13:42 |
| apw | these are all Eeek! jobs | 13:42 |
| tseliot | apw: I wrote nvidia-common for that | 13:42 |
| apw | aha, so like linux-meta? | 13:42 |
| tseliot | well, it depends on the modaliases generated by each driver version | 13:43 |
| tseliot | and these modalias files can be found in /usr/share/jockey/modaliases/ | 13:43 |
| tseliot | so that I can see whether a driver supports a certain pci-id of a card or not | 13:43 |
| tseliot | if more than one driver supports the same card or more than one card is available then nvidia-common decides which driver version is better for you | 13:44 |
| apw | so they should have all of the versions of nvidia driver listed on the depends line, and be using the latest of those that supports their card | 13:44 |
| apw | and is there anything newer than 180 that they could test with to help elimintate/confirm the driver as the issue? | 13:45 |
| tseliot | only the nvidia-VERSION-modaliases packages | 13:45 |
| apw | tseliot, ahh i miss understood. so what decides which actual packages are installed | 13:46 |
| tseliot | no, not yet | 13:46 |
| tseliot | apw: in Jockey, do you mean? | 13:46 |
| * apw actually isn't sure what Jockey is :/ | 13:47 | |
| tseliot | Jockey (aka Restricted Drivers Manager) | 13:47 |
| apw | oh i see | 13:47 |
| apw | so jockey decides which drivers to install based on the modalias info | 13:47 |
| apw | so the statment "they should have the latest which supports their card" is accurate? | 13:47 |
| apw | and right now that includes everything upto 180 and that is the latest | 13:48 |
| tseliot | Jockey uses nvidia-common to do that and adds a small [Recommended] tag to the driver it deems more appropriate | 13:48 |
| tseliot | yes, if you have only one card | 13:48 |
| apw | yeeks, more than one, error :) | 13:48 |
| tseliot | and yes 180 is the latest | 13:48 |
| tseliot | well, you could have 2 cards | 13:48 |
| directhex | even better, 2 cards with no common driver support | 13:49 |
| tseliot | which are both supported by the same driver (which is not the latest) | 13:49 |
| tseliot | but one card supports the latest version | 13:49 |
| tseliot | and nvidia-common will choose the driver which supports both | 13:49 |
| apw | i presume if there is no common driver jockey throws in the towel | 13:50 |
| tseliot | or, in the case suggested by directhex, the card supported by the latest driver wins | 13:50 |
| tseliot | ^^ | 13:50 |
| apw | ahh | 13:50 |
| directhex | it's a real scenario! | 13:50 |
| tseliot | I think it makes sense to use the newer card | 13:50 |
| apw | when did 180 release? date wise? | 13:50 |
| apw | yeah given an impossible situation that seems logical choice | 13:51 |
| directhex | [root@clearspeed ~]# lspci | grep nVidia | 13:51 |
| directhex | 07:00.0 VGA compatible controller: nVidia Corporation Unknown device 05e7 (rev a1) | 13:51 |
| directhex | 0c:02.0 VGA compatible controller: nVidia Corporation NV34 [GeForce FX 5200] (rev a1) | 13:51 |
| apw | heh | 13:51 |
| tseliot | 180.22 was released on 01-08-09 | 13:52 |
| apw | so i assume we see the nvidia drivers in dkms land | 13:52 |
| tseliot | http://www.nvnews.net/vbulletin/showthread.php?p=1897256 | 13:52 |
| tseliot | apw: ? | 13:52 |
| apw | tseliot, given a machine how do i find out which driver jockey has chosen | 13:53 |
| tseliot | type: dkms status | 13:53 |
| tseliot | which, in my case, says: nvidia, 180.22, 2.6.28-5-generic, i686: installed | 13:53 |
| apw | nice .. will ask for that | 13:54 |
| tseliot | apw: keep in mind that nvidia has yet to release a driver which works well with Jaunty's Xserver | 13:55 |
| apw | mostly i have intrepid users complaining, but i see a common thread of Tained: P in the panics, and upstream is attributing the current spate of Eeek! with nvidia being installed | 13:55 |
| apw | so i want to ask those affected if they have nvidia and if so which version | 13:56 |
| tseliot | ok | 13:56 |
| apw | to see if they are all that or not | 13:56 |
| apw | would be nice to find half don't have it to elminate that | 13:56 |
| tseliot | yes, but it could also depend on the BIOS | 13:56 |
| tseliot | which not always plays well with the nvidia driver | 13:57 |
| * directhex blames kernel panics on sky2.ko | 13:57 | |
| stefanlsd | im using jaunty with the 180 nvidia drivers and the ignoreABI setting, no problems so far | 14:00 |
| apw | tseliot, is there any workable alternative OSS driver for any of these cards, even if its a lot crap without 3d or whatever, that we could use for elimination purposes? | 14:00 |
| tseliot | apw: "nv" | 14:00 |
| apw | so i could also ask them to try running with that instead | 14:01 |
| apw | that sounds like a good plan | 14:01 |
| apw | then we'll have something contrete as a test plan | 14:01 |
| tseliot | stefanlsd: yes, I was referring to something which doesn't require the IgnoreABI option | 14:01 |
| tseliot | good | 14:01 |
| === davmor2-lunch is now known as davmor2 | ||
| directhex | tseliot, is 180.22 coming to intrepid-updates? it seems odd to have 180.11 beta in there | 14:02 |
| tseliot | directhex: I would like to use the backports for future driver updates | 14:03 |
| directhex | or perhaps superm1 should be asked instead | 14:03 |
| tseliot | using -updates can break things | 14:03 |
| directhex | tseliot, well, either way. actually, i want >180.22 since i'm interested in buying a gtx285 :p | 14:03 |
| apw | its sounding like directhex should be directnv | 14:04 |
| tseliot | I'm a bit busy but I'll update the drivers in jaunty and intrepid ASAP | 14:04 |
| tseliot | hehe | 14:04 |
| apw | tseliot, that might help me diagnose this kernel issue too ... | 14:04 |
| apw | could you let me know when you get an updated version in, subscribe me to the bug or whatever (apw in launchpad) | 14:05 |
| tseliot | apw: ok | 14:05 |
| apw | you are a star | 14:05 |
| apw | tseliot, this is bug #252977 if you are interested | 14:06 |
| ubottu | Launchpad bug 252977 in linux "Hardy and Intrepid freeze with kernel error: "Eeek! page_mapcount(page) went negative! (-1)"" [High,Incomplete] https://launchpad.net/bugs/252977 | 14:06 |
| tseliot | apw: now, that I think about it, I'll have to use -updates in intrepid because I need to fix another bug. I'll let you know when it's done | 14:09 |
| apw | thanks | 14:09 |
| maxb | nvidia-180 in -updates is a bit of a special case because it's an outright new package, hence less breakage potential | 14:11 |
| ebroder | Where can I find a package that actually activates a trigger? All of the initramfs-tools-related packages I can find just call `update-initramfs -u` instead of having a DEBIAN/triggers file | 14:20 |
| slangasek | ebroder: if you have a look inside the update-initramfs script, I believe you'll see that this script turns the call into a trigger centrally | 14:24 |
| ebroder | slangasek: Yeah, I got that. Is that the only supported way to do triggers, though? | 14:24 |
| maxb | ebroder: man deb-triggers | 14:24 |
| slangasek | ebroder: no, it's just convenient in this case because it lets us use triggers without having to fix up all the third-party kernel packages | 14:25 |
| slangasek | s/use triggers/get the full benefit of triggers/ | 14:25 |
| ebroder | maxb: I don't have a deb-triggers manpage | 14:25 |
| ebroder | slangasek: Right - I'm working on some site-local packages where I want to use triggers, and at the moment the triggers don't seem to be triggering, and I'm looking for an example to compare to | 14:25 |
| maxb | ebroder: the manpage should be shipped in dpkg-dev package | 14:26 |
| ebroder | maxb: Ok - I see it, but it didn't in Hardy | 14:27 |
| ebroder | Yeah - I think I'm doing this right. I have one package that has "activate $trigger". Another package has "interest $trigger" and does something in the postinst if $1 is "triggered" | 14:30 |
| lool | seb128, doko: I don't intend to look at GStreamer patches; would be best if either slomo or one of you would | 14:30 |
| ebroder | I should be able to test the trigger with "dpkg-trigger --no-await $trigger", right? Because that returns 0 but doesn't do anything | 14:30 |
| ebroder | Both /var/lib/dpkg/info/$package.triggers and /var/lib/dpkg/triggers/$trigger have the correct information | 14:32 |
| slomo | lool, seb128, doko_: i can take a look at any patches now... where are they? ;) | 14:32 |
| seb128 | doko_, lool, slomo: I don't intend to look at gstreamer changes either, we are on sync with debian and that would nice to stay this way | 14:35 |
| lool | 13:00 < doko_> lool, seb128: plesae could you apply the two recent pulseaudio patches seen here (http://cvs.fedoraproject.org/viewvc/devel/gstreamer-plugins-good/) afaiu these are taken from upstream. | 14:36 |
| lool | slomo: ^ | 14:36 |
| pitti | asac: do you still think that jaunty-desktop-network-changing is something for jaunty? it's still in 'discussion' state | 14:38 |
| slomo | doko_, seb128, lool: yeah, i'll include this two patches in the debian package... i had them already on my list but as another large gst-pulseaudio patch is pending for upstream inclusion (with many bugfixes and some new features) i wanted to wait until that patch is finished too | 14:39 |
| seb128 | slomo: ok thanks | 14:40 |
| lool | slomo: Great | 14:40 |
| asac | pitti: not sure. what i am doing is going through the list of apps, verifying their exact behaviour and report bugs/suggest fixes while testing. | 14:44 |
| lool | Perhaps a stupid question but why is linux in hardy's NEW for a bunch of arches without actually any NEW package? | 14:48 |
| slangasek | well, AFAICS they are new packages, they just aren't correctly labeled as such? | 14:52 |
| lool | Oh ok; there's a red NEW aside of NEW packages in other sources | 14:52 |
| lool | But not in the linux one | 14:53 |
| slangasek | yes, I'm not sure what it is that sometimes confuses soyuz about this | 14:53 |
| slangasek | but there aren't currently any lpia 2.6.24-23 packages in -proposed, for instance | 14:53 |
| lool | slangasek: Hmm I think there are some | 14:54 |
| lool | slangasek: Not quite sure what you mean actually | 14:54 |
| lool | slangasek: Do you mean *only* in proposed? | 14:55 |
| slangasek | yes | 14:55 |
| lool | Ok; I'm fine with the -updates one actually since the latest lum-2.6.24 is still for -23 | 14:56 |
| slangasek | well, still needs to get processed. :) | 14:58 |
| lool | slangasek: Oh since we're on that topic... ;-) | 14:59 |
| === a|wen- is now known as a|wen | ||
| * slangasek tweaks the kernel-overrides script a bit more, so it can handle this case of new-but-not-new binaries | 15:15 | |
| Luke | asac: you around? | 15:37 |
| Luke | asac: I have an issue I want to discuss with you before submitting it as a bug | 15:38 |
| asac | Luke: go ahead | 15:40 |
| Luke | asac: in /etc/hosts our local ip/hostname gets defined | 15:41 |
| Luke | asac: this causes problems when on a corporate network where we are assigned our own ip | 15:41 |
| Luke | asac: so some software at our company was using some java "get next available port" call which was returning the local IP "hardcoded" in /etc/hosts/ instead of grabbing the real one from ifconfig or whatever is appropriate | 15:42 |
| Luke | asac: so i'm wondering what the benefit of the "hardcoded" ip and hostname are vs. just removing it and having it be automatic | 15:42 |
| slangasek | Luke: the general solution is to assign your local hostname to 127.0.1.1 | 15:43 |
| Luke | still... that requires user intervention | 15:43 |
| slangasek | instead of to an IP that's associated with a connection that may not always be up | 15:43 |
| slangasek | why does it require user intervention? That's the default in the installer. | 15:43 |
| Luke | what's the default in the installer? | 15:43 |
| slangasek | to attach your hostname to the 127.0.1.1 IP. | 15:43 |
| Luke | right.. which is wrong | 15:44 |
| slangasek | um, no | 15:44 |
| Luke | ok that isnt helpful. i'll wait for alex | 15:45 |
| slangasek | if your java app is assuming that it can *listen* for incoming connections by resolving the hostname and binding to that IP, that's a bug in your java program, frankly | 15:46 |
| Luke | good point | 15:46 |
| Luke | i'll relay that back | 15:46 |
| cjwatson | ebroder: if you want an example of file triggers rather than explicitly-activated triggers, see man-db | 15:47 |
| slangasek | i.e., is there a known reason why this app doesn't follow the conventional default behavior of listening on all addresses (by binding to 0.0.0.0)? | 15:47 |
| cjwatson | Luke: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/8980/comments/30 describes the constraints we are satisfying right now | 15:48 |
| ubottu | Launchpad bug 8980 in network-manager "hostname -f does not return a proper FQDN" [Medium,Confirmed] | 15:48 |
| asac | Luke: i think the problem is in the java app as slangasek said. | 15:48 |
| Luke | i'm talking to the guy now that wrote it | 15:48 |
| Luke | this is why I came to IRC before filing a bug. I never claimed that ubuntu was wrong. I was simply looking for the pros and cons | 15:49 |
| cjwatson | 15:44 <Luke> right.. which is wrong | 15:49 |
| cjwatson | :-) | 15:49 |
| Luke | the ip is wrong | 15:49 |
| Luke | not the setup | 15:49 |
| cjwatson | which IP? | 15:49 |
| Luke | the local vs our network ip | 15:49 |
| slangasek | perhaps it's not the IP your app wants, but that doesn't make it "wrong". :) | 15:49 |
| Luke | i meant it's not the desired IP of they were looking for | 15:50 |
| cjwatson | right | 15:50 |
| Luke | exactly | 15:50 |
| Luke | thus the overhead of IRC | 15:50 |
| Luke | try to deal | 15:50 |
| cjwatson | we're dealing fine :) | 15:50 |
| slangasek | mathiaz: hi! I assigned an open-iscsi SRU bug to you because you had done the upload that fixed it in jaunty; if you don't have time for this SRU, please let me know and I'll look for someone else to take it | 15:51 |
| mathiaz | slangasek: ok - I'll look at the bug and let you know. | 15:52 |
| dholbach | ember: do you know if the libbrasero-media package is used by anything already? | 15:53 |
| Luke | cjwatson: thanks for that launchpad btw. that's a perfect description | 15:53 |
| cjwatson | Thomas Hood is a good guy | 15:54 |
| Luke | cjwatson: hows things going with dell? | 15:54 |
| Luke | i think I worked with you when I was at dell | 15:54 |
| calc | slangasek: rene just brought up something i hadn't realized | 15:56 |
| cjwatson | no major problems I know of | 15:56 |
| calc | slangasek: stlport is only enabled on i386 because it needs it to be able to use extensions, so when we disabled it we broke extensions (at least some unknown subset in any case) | 15:57 |
| slangasek | calc: yes, I read that mail. When was stlport disabled? That doesn't ring a bell | 15:59 |
| calc | slangasek: early in jaunty release cycle someone mentioned i forgot to disable it so i disabled it | 16:04 |
| calc | slangasek: i believe it had been disabled for intrepid also due to space reasons but we didn't catch the problem with it at that time | 16:04 |
| slangasek | ah | 16:04 |
| calc | it was enabled in jaunty due to a reworking of the rules file and i didn't notice it was enabled, but now after seeing email from rene it seems it should be enabled for compat reasons | 16:05 |
| calc | is stlport small enough to be made to fit somehow? | 16:06 |
| ScottK | jcastro: When you moved wiki.ubuntu.com/ContributingToDebian to Debian/ForUbuntuDevelopers there was at least one sub-page that got missed: https://wiki.ubuntu.com/ContributingToDebian/PythonModulesTeam | 16:06 |
| ScottK | jcastro: It seems a bit out of place now, so I was wondering if you'd move that too. | 16:06 |
| calc | it appears to only be ~ 200KB | 16:06 |
| ScottK | JFTR, I'm not a fan of wiki reorgs and stuff like this is one reason why. | 16:06 |
| jcastro | ScottK: sure, I'll do it now, thanks for the headsup | 16:07 |
| primes2h | pitti: Do you know where jockey emblems come from in nautilus? | 16:09 |
| pitti | primes2h: already fixed in trunk, will upload soon | 16:11 |
| primes2h | pitti: Great, now I'm working on gnome-icon-theme to fix some emblems with the untranslatable problem as well, moreover I found out that installing gnome theme you have 32x32 emblems untranslatable as well (they appear in Properties->Emblems right clicking on a folder) | 16:15 |
| === dholbach_ is now known as dholbach | ||
| * calc wonders why debian has a newer version of bzr than ubuntu | 16:39 | |
| slangasek | ehm... because someone forgot to ask for a post-DIF sync? :) | 16:40 |
| calc | well its in experimental in debian but i thought we kept our version up to date | 16:40 |
| calc | i guess we can sync to experimental also | 16:41 |
| pitti | calc: yes, we can! | 16:41 |
| pitti | (*ahem*) | 16:41 |
| calc | lol | 16:42 |
| DGMurdockIII | hi | 16:42 |
| DGMurdockIII | how do i go about getting hardware supported | 16:42 |
| DGMurdockIII | how good is bluetooth suport OTB | 16:43 |
| calc | DGMurdockIII: best way is to write drivers if they don't exist :) | 16:44 |
| calc | thats what i do :) | 16:44 |
| DGMurdockIII | there is a linux driver for what i want supported | 16:45 |
| DGMurdockIII | i just want it to be added | 16:45 |
| calc | ah, probably should talk to the kernel ubuntu-kernel people then if it is part of the kernel anyway | 16:45 |
| calc | if it isn't you would need someone to package it | 16:45 |
| DGMurdockIII | http://www.bigfootnetworks.com/Support/index.php?_m=downloads&_a=viewdownload&downloaditemid=65&nav=0,2,8 | 16:45 |
| calc | DGMurdockIII: so find out if it is being added to the kernel since it is gpl or create a package for it if it is not packaged | 16:47 |
| DGMurdockIII | the ubuntu kernel or linux kernal | 16:48 |
| calc | DGMurdockIII: either | 16:51 |
| DGMurdockIII | is there a channel for the linux kernnel | 16:51 |
| calc | not public afaik | 16:52 |
| calc | iirc linuxnet (or whatever its called) isn't public | 16:52 |
| calc | its been a few years since i last logged on though | 16:52 |
| calc | there is a linux kernel bugzilla | 16:52 |
| DGMurdockIII | where the bugzilla | 16:59 |
| cjwatson | DGMurdockIII: did you try googling for "linux kernel bugzilla"? | 17:03 |
| DGMurdockIII | https://bugs.launchpad.net/ubuntu/+source/linux/+bug/277749 | 17:04 |
| ubottu | Launchpad bug 277749 in linux "Killer nic network card not detected" [Undecided,Invalid] | 17:05 |
| calc | DGMurdockIII: yes they closed the bug because you never answered their question | 17:12 |
| seb128 | tkamppeter, pitti: bug #320873 claims an intrepid cups update broke things | 17:14 |
| ubottu | Launchpad bug 320873 in cups "CUPS update breaks Evince printing to SMB printer(s)" [Undecided,New] https://launchpad.net/bugs/320873 | 17:14 |
| pitti | seb128: marked as regression, thanks | 17:38 |
| LordMetroid | So I decided to try to write a patch for the bug I previously reported | 17:48 |
| LordMetroid | I can't fins the glib source through google... what am I to do? | 17:48 |
| LordMetroid | ohh wait a minute, this link seems promising | 17:49 |
| cjwatson | LordMetroid: if you really mean glib (a library of useful C routines used by GTK+ among others) then 'apt-get source glib2.0'. If you mean glibc (the GNU C library), then 'apt-get source glibc'. | 17:50 |
| LordMetroid | thank you | 17:52 |
| LordMetroid | The glib source is totally incomprehensible unless you are acquainted with it... Ohh, well. Maybe I'll get back to this bug patching when I feel more encouraged. | 18:36 |
| LordMetroid | I had hoped I could fix the bug sooner rather than later though :( | 18:36 |
| dg | any idea when a fix for this might get released: https://bugs.launchpad.net/ubuntu/+source/gitweb/+bug/317052 ? | 18:40 |
| ubottu | Launchpad bug 317052 in gitweb "gitweb multiple remote command injections (CVE-2008-5516 CVE-2008-5517)" [Undecided,Confirmed] | 18:40 |
| dg | i attached a patch and nominated it for release, not sure what more I'm supposed to do.. | 18:40 |
| Edico | hello | 18:41 |
| Edico | why ubuntu doesn't have default aliases configured for the shell? | 18:43 |
| Edico | is should have | 18:43 |
| Edico | It's so odd for a linux distribution to came default with desktop effects and without a minimum aliases set! | 18:47 |
| maxb | Edico: Desktop effects are a feature. Shell aliases are personal preferences. So no, I don't think it odd. | 18:51 |
| directhex | Edico, i think ubuntu should have "sl" installed by default | 18:53 |
| maxb | :-) | 18:53 |
| Edico | maxb, it should have a default aliases set for user@host colors, when I give few commands with a more output it's hard to see from where becomes a command | 18:54 |
| maxb | Edico: You are effectively saying that Ubuntu "should" conform to your personal preferences | 18:54 |
| directhex | to be fair, uncommenting force_color_prompt=yes in bashrc is the first thing i do on a new ubuntu install | 18:55 |
| Edico | no, I say that it should have set for a easyer output understanding | 18:55 |
| maxb | Well, which is easier is a matter of subjective opinion | 18:57 |
| Edico | I think the effects are a matter of prefference and aliases set for easier understanding of the output, because it takes much longer time fo find from where it begins the output and the mark is user@host , it should be colored at least the user@host | 19:00 |
| LaserJock | I think colors can mess up some apps | 19:09 |
| cjwatson | Edico: set it according to your own preferences. (My preferences are no colour in the prompt; it distracts from useful colour-coding in things like ls.) | 19:19 |
| cjwatson | Edico: plus prompt colours tend to only work with one of white-on-black and black-on-white; there are many Ubuntu users preferring either one of those | 19:19 |
| Edico | cjwatson, let you writed this # uncomment for a colored prompt, if the terminal has the capability; turned | 19:25 |
| Edico | # off by default to not distract the user: the focus in a terminal window | 19:25 |
| Edico | # should be on the output of commands, not on the prompt | 19:25 |
| Edico | #force_color_prompt=yes | 19:25 |
| Edico | ? | 19:25 |
| Edico | cjwatson, you should make a poll to see how many people are sharring your way of thinking | 19:28 |
| Edico | you would be very surprise | 19:28 |
| lfaraone | cjwatson: personally, I'm with EagleScreen | 19:42 |
| lfaraone | cjwatson: * Edico | 19:42 |
| EagleScreen | sorry, whay are yoy saying about me? | 19:42 |
| EagleScreen | I just have entered :) | 19:43 |
| maxb | EagleScreen: looks like just auto-completion of nickname gone wrong | 19:45 |
| EagleScreen | okay | 19:46 |
| cjwatson | Edico: I'm entirely happy with the status quo, and so am not motivated to start a poll about changing it :-) | 19:46 |
| maxb | I notice linux-doc hasn't been upgraded when I went intrepid->jaunty, should I be directing my bug at linux-doc or update-manager ? | 19:47 |
| maxb | (And has anyone ever managed to figure out exactly when apt will be willing to remove a package?) | 19:47 |
| maxb | (as part of an upgrade, I mean) | 19:47 |
| cjwatson | Edico: and no, it was not I who wrote the text you quote, although I agree with it. I cannot see the justification for several pages of IRC argument over deleting a single # character from a configuration file, particularly since if you're using a terminal that shouldn't be so big a deal | 19:47 |
| cjwatson | desktop effects are a completely different kettle of fish, since we do not want to expect users to edit configuration files to configure their desktop | 19:49 |
| cjwatson | but shell users are, on the whole, rather more flexible people | 19:50 |
| directhex | i'm inflexible! | 19:53 |
| * Spads touches his toes | 19:53 | |
| Edico | cjwatson, it more easy for an noob linux user to find preference > appearance > visual effects than to find how to configure his shell, and if that user wants to learn linux on ubuntu it would have a difficult task to read the output after some commands with lot of output | 19:55 |
| cjwatson | Edico: sorry, I really don't buy that | 20:04 |
| cjwatson | pressing enter a few times to space things out if you want to is hardly a big deal, and certainly easier than trying to see the command output when Exciting Colours in the prompt are competing for your attention | 20:05 |
| === hunger_t is now known as hunger | ||
| YokoZar | Against what package would a bug in Gnome's save dialog go? | 20:37 |
| directhex | gtk | 20:38 |
| cjwatson | yeah, that's GtkFileChooserDialog, isn't it? the source package name is gtk+2.0 though | 20:39 |
| YokoZar | cjwatson: Yeah...apparently the bug I found was also reported earlier but marked invalid. https://bugs.edge.launchpad.net/ubuntu/+source/gtk+2.0/+bug/230618 | 20:42 |
| ubottu | Launchpad bug 230618 in gtk+2.0 "no focus on file name in save-as dialog" [Low,Invalid] | 20:42 |
| Necrosan | Who maintains sparc64? | 20:43 |
| cjwatson | Necrosan: the ubuntu-sparc64 team, in theory, although sparc is no longer a supported architecture and it's not especially active | 20:44 |
| cjwatson | https://launchpad.net/~ubuntu-sparc64/+members | 20:44 |
| Necrosan | cjwatson: The repos are messed up bad for Intrepid. | 20:44 |
| Necrosan | I must be the only person attempting to use X11. :) | 20:45 |
| Necrosan | Putting jaunty on to see if the problems are fixed.. | 20:47 |
| cjwatson | Necrosan: sparc is not all that heavily used. You say that the repositories are messed up, which sounds like there's some structural problem rather than just package bugs; what's the problem exactly? | 20:49 |
| Necrosan | cjwatson: if you have a sparc64 system, try installing linux-sparc64-smp | 20:49 |
| Necrosan | Unmatched deps like crazy. Also get problems with some Xorg stuff. | 20:50 |
| Necrosan | Looks like on jaunty repos the problem doesn't exist. | 20:51 |
| maxb | I am purely guessing here, but I suppose the problem is that there wasn't enough developer time among sparc porters to get it sorted in time for intrepid? | 20:53 |
| cjwatson | Necrosan: I don't | 20:54 |
| cjwatson | though that does not stop me looking at broken dependencies | 20:54 |
| Necrosan | ah | 20:54 |
| Necrosan | I dunno exactly what the problem is, but figured it would be worthwhile letting someone know. | 20:55 |
| gQuigs | who would have to approve a feature? https://wiki.ubuntu.com/Specs/no-input-recovery | 20:55 |
| gQuigs | looking for comments and suggestions as well | 20:55 |
| Necrosan | cjwatson: xserver-xorg-video-sunffb is broken also | 20:56 |
| Necrosan | All the problems seem to stem from virtual packages | 20:56 |
| lfaraone | How hard is it to get a package blacklisted? | 21:08 |
| cjwatson | blacklisted from what? | 21:09 |
| cjwatson | Necrosan: the problem with linux-sparc64-smp is that linux-ubuntu-modules-2.6.25-2-sparc64-smp doesn't exist | 21:09 |
| lfaraone | cjwatson: from debian automagic imports. I want a package dropped from the archive, and I think I have a good reason. | 21:10 |
| Necrosan | cjwatson: Yep, figured that out. | 21:10 |
| Necrosan | cjwatson: Try the sunffb one I referenced. | 21:10 |
| cjwatson | and xserver-xorg-video-sunffb is built for the wrong X ABI | 21:11 |
| Necrosan | yup. | 21:11 |
| cjwatson | lfaraone: file a bug report on the package and subscribe the ubuntu-archive team | 21:11 |
| Necrosan | I tried using -ignoreABI, no dice. | 21:11 |
| cjwatson | won't help dependencies anyway | 21:11 |
| cjwatson | does it work in jaunty? | 21:11 |
| Necrosan | Updating now, I'll keep you posted. | 21:11 |
| cjwatson | in principle I think we could consider a stable update to make stuff installable | 21:11 |
| Necrosan | s/updating/upgrading | 21:11 |
| cjwatson | Necrosan: checking it out quickly with chdist | 21:13 |
| Necrosan | Awesome, thank you. :) | 21:13 |
| Necrosan | It looks like -cgsix and friends are installing, didnt see -sunffb though. | 21:13 |
| cjwatson | linux-sparc64-smp is still uninstallable; somebody should file a bug on linux-ports | 21:16 |
| cjwatson | xserver-xorg-video-sunffb is still uninstallable | 21:16 |
| Necrosan | :/ | 21:17 |
| Necrosan | What's the problemnow with sunffb? ABI crap still? | 21:17 |
| Necrosan | And can I rebuild it manually without building all of X11? | 21:17 |
| tjaalton | Necrosan: it needs some work to make it build | 21:18 |
| Necrosan | tjaalton: have you done it? | 21:19 |
| tjaalton | no | 21:19 |
| cjwatson | Necrosan: still the same thing | 21:19 |
| Necrosan | cjwatson: It hasn't been updated from the intrepid package? | 21:19 |
| Necrosan | I notice -cgsix now will auto install.. wonder how -sunffb slipped through. | 21:19 |
| Necrosan | (Does ubuntu even run on sun4ms?) | 21:20 |
| cjwatson | Necrosan: the source has been updated, but it failed to build | 21:20 |
| tjaalton | -sunffb 1.2.0 might compile | 21:20 |
| cjwatson | it didn't last time, https://launchpad.net/ubuntu/+source/xserver-xorg-video-sunffb/1:1.2.0-0ubuntu2 | 21:21 |
| === fta_ is now known as fta | ||
| cjwatson | /bin/sh: ../configure: not found | 21:21 |
| Necrosan | I sawsome patches that are ubuntu specific while browsing jaunty stuff | 21:21 |
| Necrosan | Heh. | 21:21 |
| cjwatson | rather blatantly, too ;-) | 21:21 |
| Necrosan | yep, those are the diffs | 21:21 |
| tjaalton | oh right | 21:21 |
| cjwatson | that at least doesn't look tricky but I have no idea about whether anything else will break | 21:21 |
| mathiaz | should file located in /etc/default/ only be used and relied upon by init script? | 21:21 |
| cjwatson | Necrosan: it slipped through because it's not something we QA centrally (since it isn't supported) | 21:22 |
| cjwatson | so it's dependent on people being motivated to fix it, and we won't delay releases due to it being broken | 21:22 |
| Necrosan | cjwatson: Understandable | 21:22 |
| mathiaz | or daemons in /usr/{s}bin could also use the content of /etc/default/service? | 21:22 |
| cjwatson | mathiaz: I don't think we have a rule on it, but my intuition is that if you want to do the latter you should have the init script read /etc/default/whatever and pass things to the daemon | 21:23 |
| cjwatson | if nothing else, that will probably be less code since you can just source the file in the init script rather than having to write configuration file parsing in C | 21:23 |
| Necrosan | tjaalton: you're the maintainer for sunffb it looks like? | 21:23 |
| tjaalton | Necrosan: not really, just tried to make it build.. | 21:24 |
| cjwatson | mathiaz: /etc/default/ was created specifically for the use of init scripts, so I'd be wary about using it outside that context | 21:24 |
| cjwatson | (see policy 9.3.2) | 21:24 |
| Necrosan | tjaalton: Forget to run autoconf? ;l) | 21:24 |
| mathiaz | cjwatson: right - but using /etc/default/service_name as the only configuration file for the service is the recommended way of doing things? | 21:24 |
| mathiaz | cjwatson: is *not* the recommended way | 21:24 |
| mathiaz | cjwatson: ok - thanks for your input. | 21:24 |
| tjaalton | Necrosan: don't remember anymore what problems there were, but hopefully debian will have it soon and then we can sync it | 21:25 |
| cjwatson | well, look, if the daemon wasn't going to have any configuration file anyway, but is controlled entirely by its command-line options, then it's OK to have the behaviour of the init script in passing those options be controlled by a file in /etc/default/ | 21:25 |
| Necrosan | cjwatson: just an FYI, aptitude is smart enough to work around the linux-sparc64-smp problem | 21:25 |
| Necrosan | tjaalton: ah. i think debian may have it already | 21:25 |
| cjwatson | mathiaz: but it is usually not the best idea | 21:25 |
| tjaalton | Necrosan: actually they don't | 21:26 |
| cjwatson | Necrosan: how on earth can it "work around" an entirely uninstallable dependency? | 21:26 |
| cjwatson | Necrosan: that sounds like a bug in aptitude, not a feature :) | 21:26 |
| Necrosan | cjwatson: Hehe. It was smart enough to figure all it needed was the image.. | 21:26 |
| cjwatson | but it's installing a package without all its dependencies satisfied | 21:26 |
| cjwatson | it has no right to work that out for itself | 21:26 |
| Necrosan | Heh, it suggested I do that.. I did, it worked. :) | 21:26 |
| cjwatson | unless it's really getting it from some other repository and you didn't notice | 21:27 |
| mneptok | don't mistake "too stupid to relaize that ..." for "so smart it worked around it" ;) | 21:27 |
| cjwatson | Necrosan: well, it's in clear violation of policy | 21:27 |
| cjwatson | I know it happens to be convenient in this case | 21:27 |
| Necrosan | ah. | 21:27 |
| Necrosan | I can see how that could cause problems. | 21:27 |
| cjwatson | furthermore, dpkg would normally refuse to configure such a package, unless passed --force-depends, which is generally not a great idea | 21:28 |
| Necrosan | IIRC, I just ran "sudo aptitude install linux-sparc64-smp" | 21:29 |
| Necrosan | and it "figured" it all out | 21:29 |
| Necrosan | apt-get wouldn't do it. | 21:29 |
| cjwatson | are you sure that you don't have some other stuff in sources.list, other than the main archive? | 21:29 |
| Necrosan | main, universe restricted and multiverse | 21:29 |
| cjwatson | I didn't mean main in that sense. Nothing other than deb http://ports.ubuntu.com/ubuntu-ports intrepid main ...? | 21:30 |
| Necrosan | backports, proposed and security | 21:30 |
| Necrosan | and updates. | 21:30 |
| cjwatson | none of which change linux-sparc64-smp or its dependencies | 21:30 |
| Necrosan | yeah | 21:30 |
| cjwatson | if you still have a transcript of what it did, please file a bug on aptitude | 21:31 |
| Necrosan | I just put intrepid on it a fewhours ago. | 21:31 |
| Necrosan | I will be re-running it again when jaunty finishes | 21:31 |
| Necrosan | I'll post a bug then.. | 21:31 |
| mneptok | !info linux-sparc64-smp | 21:31 |
| ubottu | Package linux-sparc64-smp does not exist in intrepid | 21:31 |
| mneptok | ^^^^ | 21:31 |
| cjwatson | it might have worked here, but other packages would have broken later | 21:31 |
| cjwatson | mneptok: the bot is buggy | 21:31 |
| cjwatson | linux-sparc64-smp | 2.6.25.2.3 | intrepid | sparc | 21:31 |
| cjwatson | sayeth the master archive | 21:31 |
| cjwatson | mneptok: perhaps the bot does not look at ports architectures | 21:32 |
| mneptok | cjwatson: yeah, but in this case it backs up our claim, so i'll choose to believe it. :P | 21:32 |
| cjwatson | the package is available, just uninstallable | 21:32 |
| cjwatson | anyway, off ... | 21:32 |
| kirkland | rtg: pgraner: fyi, guys, i uploaded an ecryptfs-utils to jaunty earlier today that adds the userspace support for filename encryption | 21:33 |
| joe-mac | is it considered a bug if .sudo_as_admin_successful isn't rm'd by bash logout when you end a session? | 21:35 |
| joe-mac | IMO the /etc/skel's bash log out should test -e for the file and rm it | 21:36 |
| andersk | No, .sudo_as_admin_successful is supposed to stay there so you don't get the annoying message telling you how to use sudo every time you open a terminal. | 21:36 |
| Necrosan | I love that message! :) | 21:36 |
| soren | joe-mac: That would sort of defeat the purpose of having the file to begin with, wouldn't it? | 21:37 |
| joe-mac | so andersk | 21:39 |
| joe-mac | i log out out a system, but someone somehow gets access to my account, then they can sudo -i without a pass? | 21:39 |
| joe-mac | a session's credentials should not stay if you log out, period | 21:40 |
| joe-mac | i'll just add it to my skel, just wanted to make sure you guys didn't think it was a bug, thanks | 21:40 |
| Necrosan | joe-mac: uh | 21:40 |
| Necrosan | you don't know how sudo functions apparently..that file does NOT enable passwordless sudo | 21:40 |
| andersk | Right. .sudo_as_admin_successful does not have any effect on anything other than that message. | 21:41 |
| kash | so this networkmanager + wpa-enterprise thing, what's the hold-up? | 21:41 |
| kash | bug 263963 | 21:41 |
| ubottu | Launchpad bug 263963 in linux "[iwl*] intel drivers take overly long to associate to WPA for some hardware" [High,Confirmed] https://launchpad.net/bugs/263963 | 21:41 |
| joe-mac | Necrosan: then school me | 21:42 |
| Necrosan | joe-mac: not sure how ubuntu does it, but on openbsd its a random interval of 5-10 minutes after the last use it will ask for a password. | 21:43 |
| Necrosan | I'm sure it's configurable. | 21:43 |
| Necrosan | Logging out SHOULD reset it by default | 21:43 |
| joe-mac | Necrosan: yes and if i log out of a session, and go back in, the sudo as admin is still there, and i can sudo -i | 21:43 |
| joe-mac | ok, and i agree, but it doesn't. it's not huge, but still a risk | 21:44 |
| Necrosan | joe-mac: That file has nothing to do with sudo other than showing youamessage. | 21:44 |
| Necrosan | joe-mac: The interval must stick after logout, probably as a feature. | 21:44 |
| Necrosan | I think it even works like that on openbsd | 21:44 |
| Necrosan | check out /var/run/sudo | 21:45 |
| andersk | By default, your sudo credentials are tied to a particular username and tty with a 15 minute timeout. You can explicitly invalidate them with `sudo -k`. The .sudo_as_admin_successful file is irrelevant. | 21:48 |
| Necrosan | there you go. | 21:48 |
| andersk | If you want sudo to always prompt you, you can set timestamp_timeout=0 in /etc/sudoers (man sudoers). | 21:48 |
| Necrosan | Or he could throw sudo -K/k in his profile | 21:49 |
| joe-mac | ah ok, i figured that a pam module used that file or something, never looked into it, thanks | 21:51 |
| joe-mac | it's not so much i want sudo to always prompt me, in fact that's super annoying, i just think it shouldn't persist after logging out, but i am not the supreme overlord or anything so | 21:54 |
| Necrosan | joe-mac: add sudo -k to your profile, it will always prompt you then after a logout. | 21:57 |
| joe-mac | yea, going to push it out to our skel folder, thanks Necrosan! | 21:58 |
| soren | Necrosan: That's a horrible way to "fix" that. | 21:58 |
| joe-mac | well it's not like a huge gaping hole | 21:58 |
| joe-mac | someone would have to get back into the same tty | 21:58 |
| Necrosan | soren: How would you do it,then? | 21:59 |
| joe-mac | like if you walked away from your box after re logging in or something | 21:59 |
| soren | Necrosan: I wouldn't. | 21:59 |
| soren | Necrosan: Probably. | 21:59 |
| Necrosan | soren: you talking about sudo or sparc crap? | 21:59 |
| soren | Necrosan: If I would, I'd tie it to logging *out*, not *in. | 21:59 |
| joe-mac | that's what he saidm, didn't he? | 21:59 |
| Necrosan | soren: Either way will work.. | 21:59 |
| joe-mac | well, i assumed he meant bash_logout | 21:59 |
| Necrosan | Logout would be better. | 21:59 |
| soren | Necrosan: Erm.. No. Doing it on login only makes it more difficult for well-behaved logins. | 22:00 |
| soren | Doing it on logout actually does something to increase security. | 22:00 |
| soren | It makes sure that once you log out, the credentials tied to your login on the given tty are cleared. | 22:01 |
| Necrosan | Yes, agreed. | 22:01 |
| Necrosan | But putting it in .profile won't hurt anything, unless the shell getschanged to something that doesn't source the profile | 22:01 |
| soren | Doing it on login only ensures that if they're still there when you log in properly, using your proper .bashrc, etc. etc., it's cleared. | 22:02 |
| Necrosan | (which would req. root/sudo access anyway) | 22:02 |
| soren | Or someone grabs a pty in some other way. | 22:02 |
| Necrosan | I suppose. | 22:02 |
| joe-mac | yea i can't immediately think of an exact attack vector besides walking up to a tty that you walk away from after you've just logged back in, like "o crap i forgot something at my desk", but the risk however slight still remains | 22:03 |
| soren | Or if the malicious user from another terminal just removes that bit from the .profile before he fires up terminals until he hits the same pty. | 22:03 |
| Necrosan | soren: How is that possible without access to the file? | 22:03 |
| soren | ...but in that case you're rather screwed anyway. (Malicious user with physical access to the machine) | 22:04 |
| Necrosan | yeah | 22:04 |
| soren | Necrosan: Why wouldn't he have access to the file? | 22:04 |
| Necrosan | soren: I didn't think you were insinuating he left something with his username logged in on another tty. | 22:04 |
| soren | Necrosan: It's apparantly given that said user can somehow log in as you, and thus gain your previously granted sudo-without-password privileges. | 22:05 |
| soren | Necrosan: That's the presumed attack vector, correct? | 22:05 |
| Necrosan | soren: You'd have to be pretty careless to get done like that. | 22:05 |
| Necrosan | soren: Yes. | 22:05 |
| soren | Necrosan: Good. | 22:05 |
| kees | i tried to convince kernel upstream to put consoles into /sys so udev could wipe sudo tickets when a tty closed. didn't go so well | 22:06 |
| joe-mac | no | 22:06 |
| soren | If he can do something like that at will, why couldn't he just use the first couple of attempts to clear out these "sudo -k" things from .bash_* ? | 22:06 |
| joe-mac | this is how it would go | 22:06 |
| Necrosan | soren: I agree, in theory. But more than likely, if he's logging out he'll be sure to close all other ttys. | 22:06 |
| Necrosan | Especially if he's concerned about sudo's default behavior. | 22:07 |
| soren | Necrosan: Who says he's logging out? | 22:07 |
| lamont | why do I hate it so much when an upstream makefile does >/dev/null 2>&1 ? | 22:07 |
| Necrosan | soren: He did. | 22:07 |
| Necrosan | To sum it up, I agree, it is much safer to put it in logout script | 22:07 |
| joe-mac | you log in you're the admin in a server room, WAHHHH the loud fans everywhere make it so you don't hear the ninja-like attacker hanging out in the corner. you go to take a piss and you remember to log out before doing so, but curiously enough you leave your phone on the sink in teh bathroom but you don't realize til you log back in. you say crap and go away without logging out this time. the ninja emerges, has enough time to sudo -i o | 22:07 |
| Necrosan | Them ninjas are shady. | 22:08 |
| soren | If there's ninja's in your server room, you've got much bigger problems than stale sudo tickets. | 22:08 |
| Necrosan | haha | 22:08 |
| soren | Seriously. | 22:08 |
| joe-mac | well, i specifically don't haev to worry abotu ninjas because i am a ninja-viking-pirate hybrid, but most admins aren't, so i worry about them. | 22:09 |
| joe-mac | i can actually see a very similar situation happening in a data center i've been in where it really is obscenely loud, large, and the distance from the bathroom to the data center is pretty long | 22:10 |
| soren | kees: Why didn't they like it? | 22:10 |
| kees | felt it was too much overhead | 22:10 |
| * kees thinks the world needs more ninja-viking-pirate hybrid sysadmins | 22:12 | |
| soren | kees: Hm... udev has rules for pty's? They never trigger, though, but they're there. That seems rather odd. | 22:14 |
| kees | soren: yeah, dunno. i didn't have the intestinal fortitude to dig into it :P | 22:22 |
| directhex | poke poke | 22:27 |
| kash | superpoke | 22:28 |
| directhex | i still need to hear a decision on dh7.1 | 22:28 |
| directhex | i suppose that means cjwatson | 22:28 |
| * Laney pokes too | 22:28 | |
| directhex | with your pokes combined, i am captain pokings! | 22:29 |
| directhex | captain pokings, he's our hero, gonna poke core-devs down to zero! | 22:29 |
| directhex | he's our pokings, magnified | 22:29 |
| Necrosan | heh | 22:29 |
| directhex | and he's fighting on young meebey's side! | 22:30 |
| directhex | and that's as much of THAT piece of my youth as i remember | 22:30 |
| directhex | or care to admit to remembering | 22:30 |
| Necrosan | I never liked the "heart" guy | 22:31 |
| Necrosan | "heart" is not an element. | 22:32 |
| directhex | there were only limited ways to fit all the token ethnicities | 22:33 |
| kirkland | bryce: is the nvidia-glx graphics drivers known to work in jaunty? i haven't managed much success to this point | 22:35 |
| kirkland | s/is the/are the/ | 22:35 |
| bryce | kirkland: I believe they work if you use the IgnoreABI option | 22:35 |
| bryce | we should be getting ABI-compliant versions of some/all the -nvidia drivers soonish (matter of weeks maybe) | 22:36 |
| directhex | bryce, oh? this is from the horse's mouth? | 22:36 |
| kirkland | bryce: where does that go? what's the syntax? | 22:36 |
| kirkland | bryce: i mean, what section of xorg.conf? | 22:36 |
| TheMuso | doko_: no idea at this point, 0.9.14 was a bugfix release. | 22:37 |
| bryce | kirkland, actually -ignoreABI is an X flag, not an xorg.conf option | 22:38 |
| kirkland | bryce: ah, startx -- -ignoreABI ? | 22:38 |
| johanbr | It also works if you stick it in the ServerFlags section in xorg.conf | 22:39 |
| bryce | kirkland: yep, or in the appropriate gdm conf file | 22:39 |
| bryce | johanbr: aha ok | 22:39 |
| tseliot | yep, ServerFlags should be ok | 22:39 |
| TheMuso | doko_: and unfortunately I haven't quite been able to work out the C function equivalents with the symbol references in that error. | 22:39 |
| bryce | Option "IgnoreABI" "boolean" | 22:39 |
| bryce | Allow modules built for a different, potentially incompatible version of the X server to load. Dis- | 22:39 |
| bryce | abled by default. | 22:39 |
| bryce | yep you're right | 22:39 |
| TheMuso | doko_: I think I've worked out one of them, but not the other. | 22:39 |
| TheMuso | doko_: And there has been no change to that function from 13 to 14 releases of pulseaudio. | 22:40 |
| Riddell | tkamppeter: there is code in system-config-printer's applet for authentication, how do I set the print server to need authentication? | 22:43 |
| kirkland | bryce: hmm, still not having any success here | 22:45 |
| bryce | tseliot: ideas? | 22:45 |
| tkamppeter | Riddell, you have to edit cupsd.conf setting The AuthType of a resource (ex: <location /printers/myqueue>) to "Basic". See the documentation on localhost:631 about cupsd.conf. | 22:46 |
| tseliot | kirkland: what driver did you install? | 22:46 |
| tseliot | kirkland: 180? 177? | 22:47 |
| kirkland | tseliot: i'm trying 180 now | 22:47 |
| tseliot | kirkland: install 180 and reboot | 22:48 |
| tseliot | I don't know why but sometimes IgnoreABI doesn't seem to work if I change driver unless I reboot | 22:48 |
| tseliot | kirkland: let me know if you still have problems with the driver | 22:49 |
| kirkland | tseliot: okay, so i need apt-get install --reinstall nvidia-glx-180 ? | 22:50 |
| tseliot | apt-get install --reinstall nvidia-glx-180 nvidia-180-kernel-source | 22:50 |
| tseliot | and reboot | 22:50 |
| tseliot | kirkland: also make sure that DefaultDepth is set to 24 in your xorg.conf | 22:51 |
| kirkland | tseliot: hmm, interesting, i don't have nvidia-180-kernel-source installed ... is that perhaps missing as a dependency?> | 22:51 |
| kirkland | tseliot: i have the -96-kernel-source installed | 22:52 |
| tseliot | kirkland: Depends: nvidia-180-kernel-source (>= 180.22) | 22:52 |
| tseliot | remove -96 | 22:52 |
| kirkland | tseliot: removing nvidia-glx-96 is throwing dpkg-divert errors | 22:55 |
| kirkland | tseliot: missing /usr/lib/xorg/modules/extensions/libGLcore.so | 22:55 |
| tseliot | kirkland: can you file a bug report about it, please? | 22:56 |
| kirkland | tseliot: you bet, thanks. | 22:56 |
| tseliot | good | 22:57 |
| kirkland | tseliot: how can i easily just use the vesa driver in the mean time? | 22:57 |
| tseliot | simply set the driver to "vesa" in the Device section of you xorg.conf | 22:57 |
| kirkland | tseliot: right, even that's failing for me | 22:58 |
| tseliot | kirkland: is xserver-xorg-core installed? | 22:58 |
| kirkland | tseliot: hmm, no, it's been removed | 22:59 |
| tseliot | kirkland: yes, because the other nvidia driver conflict with the new xorg abi | 22:59 |
| kirkland | tseliot: not by me, consciously, i might add | 22:59 |
| kirkland | tseliot: okay, so i need to remove some stuff? | 22:59 |
| kirkland | tseliot: or has the nv driver gotten any better? | 22:59 |
| kirkland | tseliot: can i just use that one? | 23:00 |
| tseliot | simply install xserver-xorg-core | 23:00 |
| tseliot | and you'll be able to use nvidia -180 | 23:00 |
| kirkland | k | 23:00 |
| kirkland | oh | 23:00 |
| tseliot | or nv or whatever you prefer | 23:00 |
| kirkland | okay | 23:00 |
| Necrosan | Yep, aptitude still doing the same thing in Jaunty/sparc64, cjwatson | 23:03 |
| maxb | Anyone else seeing update-manager disinclined to install a lot of libx11 / libxcb updates? | 23:05 |
| Turl | just found 2 broken packages, libx11-6 and libxcb-xlib0-dev | 23:10 |
| Turl | can you look into them? | 23:10 |
| * ScottK is gonna guess that bryce already knows all about it. | 23:11 | |
| bryce | hadn't heard that | 23:12 |
| bryce | link me? | 23:12 |
| maxb | I don't think it's broken packages, per se. Just lacking whatever Replaces: magic is needed to convince apt that it's alright to remove the libxcb-xlib ones which have gone away | 23:12 |
| Turl | libxcb-xlib0-dev: Depende: libxcb-xlib0 (= 1.1-1.1) pero no es instalable | 23:13 |
| Turl | libx11-6: Depende: libxcb-xlib0 pero no es instalable | 23:13 |
| Turl | pero no es instalable=but it's not installable, depende=depends | 23:13 |
| Turl | then, there are packages missing replaces magic, as maxb said | 23:14 |
| * maxb wonders why a "Partial upgrade" thinks it should remove powermanagement-interface along with the two xcb-xlib packages | 23:16 | |
| Necrosan | looks like ports.* is down | 23:17 |
| Necrosan | back | 23:17 |
| Necrosan | What package do I need to compile X drivers? Getting the RANDR error, not sure what its called in jaunty. | 23:21 |
| dtchen | Turl: why would it need a Replaces? | 23:22 |
| Necrosan | ah, xorg-dev. | 23:22 |
| dtchen | slangasek: thanks for clarifying the ia32-libs mess =) | 23:22 |
| YokoZar | dtchen: so, are you gonna find me some magic multi-arch implementing developers? | 23:23 |
| dtchen | YokoZar: in what context? | 23:23 |
| dtchen | Turl: AFAICT, libxcb1 does the right thing in its Conflicts | 23:24 |
| Turl | dtchen: because other packages depend on it? if you don't add the replaces, you should make the other packages depend on the new lib | 23:24 |
| YokoZar | dtchen: so we can get rid of ia32-libs the proper way ;) Reading the mailing list it seems at least 3 grad students have written papers about how wonderful and proper a good multi-arch implementation would be, but no one's actually written enough code we can use | 23:24 |
| dtchen | Turl: the latter must happen regardless | 23:25 |
| Turl | dtchen: then I'll have to wait I guess | 23:25 |
| maxb | update-manager baffles me. It's computing a dist-upgrade that involves removing a random extra package for no sane reason, compared with 'apt-get dist-upgrade' | 23:27 |
| ScottK | In general it should have reasons. | 23:27 |
| ScottK | It has a lot of special cases. | 23:27 |
| ScottK | It may be a reason you don't know about. | 23:27 |
| dtchen | FWIW, i didn't experience any odd things with aptitude upgrade just a few moments ago using us.archive.u.c | 23:28 |
| maxb | I experienced the oddity on only one machine of two, which have generally been upgraded in-sync :-/ | 23:28 |
| cjwatson | directhex: remind me tomorrow? | 23:32 |
| StevenK | slangasek: If you're still around, can you review ubuntu-netbook-remix-default-settings in the source NEW queue? | 23:32 |
| maxb | Oh, nifty. It was an update-manager quirk added in the small window between me jauntifying one machine and jauntifying the other, then taking effect at the next dist-upgrade that occurred. | 23:33 |
| directhex | cjwatson, will do | 23:33 |
| * directhex battles the last mono 2.0 transition app | 23:33 | |
| calc | shouldn't launchpad-integration binary spwan firefox and return to the command line? | 23:36 |
| calc | if firefox isn't already running launchpad-integration does not return | 23:36 |
| === cody-somerville_ is now known as cody-somerville | ||
| ScottK | calc: launchpad integration isn't just used by Firefox. | 23:47 |
| alex-weej | i did some translations of nautilus' en_GB to use proper UTF-8 quotes | 23:48 |
| alex-weej | how long does it take to review stuff like this? | 23:49 |
| alex-weej | (did it like 2 weeks ago i think) | 23:49 |
| alex-weej | and how does the work filter back upstream? | 23:49 |
| Necrosan | ffb_driver.c:117: error: ‘PACKAGE_VERSION_MAJOR’ undeclared here (not in a function) | 23:50 |
| Necrosan | woohoo. Any ideas anyone? | 23:50 |
| ScottK | alex-weej: AFAICT, it's "whenever reviewers get around to it" and "it doesn't". I | 23:51 |
| ScottK | I'm not an expert about translations, but that's my impression. | 23:51 |
| Necrosan | got it. xutils-dev | 23:52 |
| alex-weej | hm. damnit. | 23:52 |
| alex-weej | it's so easy to translate with launchpad | 23:52 |
| Necrosan | Maybe not. Crap. | 23:52 |
| Necrosan | Any ideas, anyone? | 23:52 |
| alex-weej | well actually i could have saved myself a lot of time by using find/replace in gedit | 23:53 |
| alex-weej | but nm | 23:53 |
| bryce | Necrosan: what are you having trouble with in X-land? | 23:54 |
| Necrosan | bryce: sunffb | 23:55 |
| bryce | hum sun | 23:55 |
| Necrosan | apparently i can define the crap in file, but xutil-dev should include the macros to properly adjust it.. | 23:56 |
| Necrosan | hm | 23:56 |
| Necrosan | got it,needed autogen re ran | 23:58 |
| Riddell | kees: what happened to your quassel review? bug 317892 | 23:58 |
| ubottu | Launchpad bug 317892 in quassel "Quassel main inclusion report" [Undecided,In progress] https://launchpad.net/bugs/317892 | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!