[00:01] munckfish: Anyhow, like I said, a "debootstrap --variant=buildd" with the build-deps installed after the fact (copy 'em straight from the "apt-get install" in the launchpad build log, if you want to make sure you're getting exactly the same build environment), should reproduce it. [00:01] munckfish: Making sure to "linux32 chroot" not just "chroot", if you're on a 64-bit machine. [00:01] -m elf32ppclinux comes from LDFLAGS in ps3-kboot/kboot-11/Makefile [00:02] cjwatson: dare we just kill that variable I wonder? [00:03] just looking for where the other one comes from [00:03] but yeah, I have to say that -m elf32ppclinux doesn't sound very sane for a 32-bit kernel; does it make sense for the userspace bits though? [00:04] s/32/64/ I assume you mean? [00:05] 32-bit -> 64-bit I meant, yes [00:17] cjwatson, infinity: as far as I understood it only the kernel needs to be 64 bit, everything else can be 32. [00:17] I'm trying to work out [00:17] how LDFLAGS ends up with the two -m [00:17] I think the [00:18] munckfish: I have a feeling I'm almost there ... [00:18] first -m [00:18] is constructed in /arch/powerpc/Makefile [00:18] e.g. [00:18] line 67 [00:18] override LD += -m elf$(CONFIG_WORD_SIZE)ppc [00:19] yeah, ahead of you :-) [00:19] (though keep going) [00:19] megabyte405: you asked for a review of the abiword 2.6 package, where is this? [00:19] megabyte405: is http://launchpadlibrarian.net/13344323/updatetoabi26.debdiff.gz the most current (eew, giant debdiff)? [00:19] If the second one is being used for userspace overrides, it can probably be dropped entirely, since -m32 is the default anyway. [00:20] munckfish: the other one comes from kboot-11/Makefile, of course [00:20] infinity: right [00:20] wasabi: did you find out what was wrong with pam on your console? something that wouldbe an Ubuntu bug? [00:20] I'm just waiting for linux.tar.bz2 to unpack, to test this hypothesis [00:20] slangasek: the abiword bug is 202174 but since it involves a new upstream package the debdiff is only of academci interest. You'll want to see my ppa, linked in that bug or https://launchpad.net/~abiryan/+archive/ [00:21] erm, bug 202174 [00:21] Launchpad bug 202174 in abiword "Please update to version 2.6" [Medium,New] https://launchpad.net/bugs/202174 [00:21] cjwatson: Infinitely curious why this doesn't trigger on davis, but even an infinity amount of curiosity is not enough for me to take the time out to find out why... [00:21] bingo [00:21] there we go :) I have a fairly complete summary in the bug comments there. [00:21] s/infinity/infinite/ [00:21] my tests were with debian/rules binary; fakeroot debian/rules binary [00:21] er, s/binary/build/ first one there [00:22] megabyte405: ah, ok, was reading from the bottom and missed the link to your ppa, thanks [00:22] dpkg-buildpackage produces different behavior from debian/rules build, I take it? [00:22] but if you use 'dpkg-buildpackage -b' instead, then LDFLAGS is exported by dpkg-buildpackage, and even though it gets reset, the exportedness survives [00:22] Ah-ha. [00:22] Yay for the "new" dpkg. [00:22] slangasek: np [00:22] LDFLAGS in kboot-11/Makefile was only meant to be local to that Makefile [00:22] 'unexport LDFLAGS' right after it should fix this [00:23] (that's the most minimal fix; removing LDFLAGS altogether may well also work but is a bigger change) [00:23] * slangasek mutters at the unseasonable hail [00:23] cjwatson: Okay, if this is under control, I'm going to wipe out my test env and turn adare back on. [00:23] yep, I have it reproduced on davis now [00:24] just testing the unexport approach [00:26] cjwatson: so how do you want to proceed? do you want to add this to my disable cross-compile patch ? [00:26] yeah, that does the trick [00:26] I think that's probably best [00:27] slangasek: I'm out - if you need something email me at abiryan at ryand dot net [00:27] megabyte405: ok, cheers :) [00:29] munckfish: shall I go ahead and do that? I'm happy to now that we see the problem, and I'm pretty confident that it will yield a working image since it's solely working around the build strangeness without which you produced a working image [00:30] cjwatson: pls go for it [00:30] It's late here anyway so I wouldn't be able to address this till tomorrow morning at best anyway [00:31] ok [00:31] Sorry I couldn't fix it on my own, I know you didn't want to get distracted too much by this project at the mo [00:33] well, this was a pretty tricky one to see [00:33] you get to test the result though :) [00:34] cjwatson: yeah, next job is to dive into the Xorg prob [00:34] ok I have to go sleep now [00:34] or I'll be useless to my employer [00:35] munckfish: Don't worry too much about it. Every time a member of the distro team accuses my buildds of causing a build failure and we later prove it's a packaging bug, I get a free beer so, in essence, you're just contributing to my alcoholism. [00:35] munckfish: Clearly a win. [00:35] infinity: :) [00:36] cjwatson, infinity: good night guys, thx for all the help. I look forward to testing the ps3 Xorg problem. cheers! [00:36] munckfish: sleep well :) === heno is now known as heno_away [01:15] kees: does apparmor support subprofiles, like when /bin/foo launches /bin/bar, use this profile, but otherwise leave /bin/bar alone? [01:17] jdong: yup -- through the exec, either inherit or switch profiles [01:18] jdong: oh, but you mean "only isolate /bin/bar if /bin/foo launched it" ? [01:18] kees: right, parent-aware profiles [01:18] jdong: not in a simple fashion, no. see if anyone is around on #apparmor, though. they might be able to discuss "changehat" and other odd things [01:19] (#apparmor is on oftc, btw, sorry) [01:19] kees: meh I'll go for a simplicity workaround. I'm trying to write a clamscan apparmor profile specific to dealing with my mail [01:20] the amount of security bugs found in clamav's unpackers really concerns me [01:20] heh, no kidding. [01:20] btw, whoever in u-m-s is listening, bug 184238 needs sponsorship and is wanted for Hardy release.... [01:20] Launchpad bug 184238 in transmission "Menu entry should be named "Transmission BitTorrent Client" Instead of only the unclear "Transmission"" [Medium,Confirmed] https://launchpad.net/bugs/184238 [01:21] kees: how safe are apparmor restrictions? I'd expect as long as a root account isn't compromised I'd be totally safe, and even some forms of root compromise are not problematic? === lamont` is now known as lamont [01:23] any root compromise would allow /etc/init.d/apparmor stop. [01:23] jdong: in theory, AA profiles are as strong as the kernel. :P I've done things like run /bin/bash as root listening on an open port, and no one could do anything with it since they didn't have an exec prvis [01:23] *privs [01:25] I hope you locked it down more than that; bash doesn't need to exec subprocesses in order to (say) overwrite files [01:25] crimsun: well to call apparmor stop I think writing to sysfs is necessary to clear out the profile [01:26] an unrestricted root compromise, sure you're totally screwed :) [01:28] cjwatson: right, of course -- I didn't let it do anything. [01:29] jdong: I think there is a changehat syntax for profile names... it's been a while since I've looked at that. [01:30] crimsun: yeah, without the write perms to the aa security tree in /proc you can't shut it down. [01:30] kees: yeah the syntax for profiles is pretty easy, the question is how much effort it'd take for me to hook that into my scripts [01:30] kees: and whether or not it's easier than just hardlinking a new clamscan ;-) [01:30] (rhetorical, most likely) [01:30] jdong: if you run with clamd (and use clamc for the scanning) you could probably just isolate clamd itself. [01:31] using clamc is way faster too. ;) [01:31] that's another good idea :) [01:39] AAAH OH FSCK!!! [01:39] ??? [01:40] * jdong angrily aliases rm to rm --one-file-system [01:40] follow up lesson: ALL mountpoints should go in /media! [01:40] ouch [01:40] alright, damage control time... fortunately XFS ain't too fast deleting files [01:42] jdong: :( [01:42] RAOF: this kinda thing also makes me worried about gvfs.... [01:42] because I simply mounted a sshfs in a temp workdir in my ~/ [01:42] but if someone tried to rm -rf a homedir with a gvfs FUSE auto mountpoint.... [01:43] Awkward, yeah. [01:45] More than awkward. [01:45] That'd be a fairly critical bug. [01:46] Fujitsu: well we do it for Hardy by default.... ~/.gvfs often contains fuse mounts of stuff you've browsed in nautilus [01:46] and for things like ssh:// it's identical to a sshfs backend in functionality [01:47] So I note. This is probably a severe problem. [01:47] I don't expect ~/.* to include my server's filesystem. [01:47] right [01:47] but SOMEONE's gonna argue that this is somehow a feature :) [01:48] And a lot more people are going to lose their remote home directories. [01:49] yeah I'm concerned. I wouldn't ever expect a recursion down my home directory to include network shares I've browsed. [01:49] even if removal is not invovled, it's still an annoyance that things like Baobab will recurse down a 7.5TB SFTP server I browsed 10 minutes ago. [01:50] Haha. [01:51] It is very convenient, but also dangerous... [02:07] is volumeid meant to be removed? [02:08] yes, by udev. [02:08] ok, cool [02:55] anybody around who could help me figure out valgrind output? [02:55] I'm trying to find memory leaks in seahorse [02:55] In Soviet Russa, ValGr... oh never mind. [02:55] I ran valgrind --tool=memcheck --leak-check=yes seahorse [02:56] this sounds more interesting than an English paper :) [02:56] * jdong sits and watches [02:56] and I get: [02:56] definitely lost: 72,750 bytes in 160 blocks. [02:56] indirectly lost: 124,747 bytes in 3,902 blocks. [02:56] possibly lost: 332,563 bytes in 278 blocks. [02:57] is that memory leaking? [02:59] it's memory not freed on exit [02:59] but I'm not sure how accurate valgrind's leak checking is [03:00] slangasek: is there a recommended way to do it? [03:00] * StevenK wonders how he can find all the packages that install a particular alternative [03:00] LaserJock: way to do what? [03:00] to find memory leaks? [03:00] yeah [03:01] understanding the code :) [03:01] yikes [03:01] ;-) [03:01] the variable should be locally scoped, in this case [03:02] so you should have a finite number of ways to leave that scope [03:02] and you just need to make sure the memory is freed, or control of the memory is passed somewhere else, before leaving the scope [03:05] slangasek: hmm, I guess I would have thought it was in a local scope already :/ [03:06] yes, that's what I mean - so there's a finite number of places the memory can leak [03:06] i.e., anywhere that you leave that scope without taking care of the memory [03:26] slangasek: so would freeing the memory within the for loop instead of outside be better? [03:28] I don't see how you would particularly leave the scope without freeing the memmory unless you crash somewhere in there [03:28] gosh I need to learn C [03:30] Hey, does anyone in here know how the subset of packages that get put in add/remove are chosen? [03:30] what characteristics do those packages have [03:30] lamalex: I think in general it's packages that have .desktop files [03:31] does it have its own cache somewhere? If I wanted to do something with just those packages do you know of a clean way? [03:32] lamalex: look in /usr/share/app-install/desktop/ [03:32] slangasek: valgrind is pretty good [03:32] slangasek: 'definitely lost' is: memory that was allocated, and there are no pointers to it, but free(base) was not called. [03:33] LaserJock: thanks [03:33] slangasek: I believe 'indirectly lost' is memory that is pointed too from definitely lost memory [03:36] hmm, i'd be surprised if this read from desktop files, but it's a place to start, thanks for the help [03:36] lamalex: what do you mean? [03:37] lamalex: what is it that you're trying to do? [03:37] well to read all of those files for the package descriptions would be slow [03:37] lamalex: it caches them [03:37] are you familar with gnome do? [03:37] sure [03:37] gnome do apt plugin [03:37] but indexing 23000 packages is not reasonable [03:37] hmm [03:38] so I was going to choose the subset of packages in add/remove [03:38] i figured it was running off of an sqlite db or something [03:39] see /var/cache/app-install/ [03:41] heh and the problem with binary files is you can't cat them :P === thegodfather is now known as fabbione [03:58] morning [03:59] morning [03:59] emgent: early bird or late night owl? [04:00] fabbione: lol [04:01] i dont like sleep :P [04:03] Hobbsee: have you time for some ACK ? [04:03] slangasek: yes [04:18] * Hobbsee waves to fabbione [04:21] hey Hobbsee [04:24] LaserJock: well, the point is I haven't had a chance to look at this code myself yet to /know/ whether there are memory leaks... [04:25] slangasek: sure, I'm just not sure [05:56] slangasek: it looks ok to me, but I'm not confident as you pointed out problems with my first upload [05:57] should I leave it for somebody else? [05:57] I just don't want it to fall through the cracks === Whoopie_ is now known as Whoopie === asac_ is now known as asac [07:04] morning [07:04] again [07:04] nevermind [07:04] wrong window [07:04] remorning. [07:05] Mourning. [07:12] Good morning [07:12] hey pitti [07:13] guten morgen, pitti [07:13] hey, is anyone offering to be a projective missile? [07:15] Hobbsee: eh? [07:15] * Hobbsee needs to use something big as a projective missile. [07:15] * fabbione doesn't really know what "projective missile" means in this case [07:15] fabbione: heard of a missile? [07:16] fabbione: something large that you throw at someone, or something. it goes through the air. [07:16] yeah i heard about that ;) [07:17] yeah. i need one. [07:17] what for? [07:18] my boss. [07:18] he fails in crucial ways about "notifying people about important changes in the workplace" [07:18] * Hobbsee has no idea if, and when, the power will go out tonight there. [07:18] Latest Google Tech Talk on the future of Linux: http://www.youtube.com/watch?v=4A6ImflixL8 [07:19] * Hobbsee is going to be absolutely stuffed, along with my coworkers, if the power *does* go out while we're still there. Although we certainly won't get hungry. [07:19] Hobbsee: you really don't need a missile for that [07:20] it would be a waste of good resources to kill a fly [07:21] Hobbsee: And why would the power go out? [07:21] TheMuso: planned maintenance on the local power station. [07:21] Oh. [07:21] TheMuso: one says it only happens on monday at 10pm, the other says it happens on both monday and tuesday at 10pm. [07:21] Oh right. [07:22] I wouldn't have found out about either notice, if i hadn't been browsing back through the supervisor book, over the last week, nor reading random pieces of paper in teh managers office. [07:22] * Hobbsee does *not* call this decent warning. [07:22] especially seeing the rosters still schedule us all to finish after that point. [07:23] * Hobbsee looks for her torch [07:33] pitti: langpacks ;) [07:33] anything left we need to figure? [07:35] Riddell: kubuntu offline startpage localization :) ... did you figure why the links are broken? [07:37] asac: I'll have a deeper look after I went through my email [07:37] asac: but it looks fine so far [07:37] asac: what is 'revpath'? [07:37] pitti: did you rerun the command i gave you to tsee if it works now properly with your permissions? [07:38] pitti: psst. :) [07:38] pitti: i didn't know about it until i found that its missing on rookery [07:38] pitti: davidm made use of it ... i had to copy the binary from ronne [07:39] ugh [08:17] slangasek: great, thanks for the merge [08:18] mjg59: regarding https://bugs.launchpad.net/bugs/157691 - is there any way we can make detection of the graphics driver a bit more robust? autodetection is becoming common these days i guess.. [08:18] Launchpad bug 157691 in hotkey-setup "Hardy/Gutsy crashes when the lid is closed on a HP 6710b, HP 6510b and HP 2510p" [Undecided,Fix released] [08:43] hum. are there no daily builds today? [08:44] no, we're ramping up for candidate images [08:44] too bad. oh well, i guess i get to try the candidate image for mythbuntu then :) [08:50] slangasek: seb128 and I just agreed on how to fix camera handling eventually; we can't fix nautilus properly, so we'll enable it in gnome-volume-manager again [08:50] slangasek: I'd like to upload this change now, so that it will work again in RC; ok for you? [08:50] slangasek: (simple gconf default change in the .schema file, no code changes) [08:52] pitti: corresponding bug #? [08:52] good morning [08:52] seb128: what's the bug# for that? [08:52] bug #208467 [08:52] Launchpad bug 208467 in nautilus "Camera Device button "Open F-spot Photo Manager" doesn't work" [High,Confirmed] https://launchpad.net/bugs/208467 [08:53] thanks; I'll add a g-v-m task and an explanation [08:53] thank you [08:54] slangasek: I've uploaded a new gtk, I synced the new debian revision which fixes the gtk im setting change patch backported some time ago (1 liner) and the dbg packages to work again (not really required since the dbgsym works alright) [08:55] slangasek: the update should not be an issue but it's not a priority either, feel free to accept it or not [08:58] pitti: yep, go for it [08:58] seb128: ok, putting it in the "later" pile for now, thanks :) [08:58] slangasek: ok ;-) === heno_away is now known as heno === mirco_ is now known as MacSlow [09:40] morning [09:41] why would f-spot depend on sqlite and sqlite3 at the same time? [09:42] slangasek: vdr-plugin-console and -osdserver are waiting on the queue, uploads approved by sistpoty [09:42] slangasek: fixes FTBFS [09:42] sabdfl: database upgrade support :/ [09:43] tjaalton: can you give me a pointer to this approval? [09:43] slangasek: a sec [09:44] slangasek: http://irclogs.ubuntu.com/2008/04/11/%23ubuntu-motu.html towards the end [09:47] tjaalton: right, accepted [09:47] slangasek: cool, thanks [09:58] slangasek: ah, right. read from the old, write to the new. yowser [10:02] mvo: is bug 211978 an issue for hardy? [10:02] Launchpad bug 211978 in update-manager "do-release-upgrade -d doesn't work immediately after running do-release-upgrade" [High,In progress] https://launchpad.net/bugs/211978 [10:03] hey sabdfl, how are you? [10:04] pitti: Hey, time for a dorky CDBS question? [10:04] StevenK: I'll answer eventually [10:04] pitti: its fixed in hardy [10:05] mvo: ah, can you please close it then? thanks *hug* [10:05] hi [10:05] I know a little python and C and was thinking of maybe contributing [10:05] :/ [10:06] pitti: Heh. CDBS is symlinking the Debian changelog only, and I thought there was a magic button to make it symlink the entire doc dir? [10:06] StevenK: it never symlinks entire directories, since that's evil with dpkg's handling of dirs vs. symlinks [10:06] StevenK: it will symlink individual files in doc/pkg/ if they are identical in any of its direct dependencies [10:06] except copyright [10:07] pitti: Should I ignore lintian's bleating that the Debian changelog is a symlink? [10:07] StevenK: I do, anyway :) [10:07] Heh [10:09] :/ [10:13] pitti: "/usr/share/doc/package may be a symbolic link to another directory in /usr/share/doc only if the two packages both come from the same source and the first package Depends on the second. " Straight from Debian Policy? [10:15] soren: right, but dpkg wreaks havoc if you ever replace the symlink with a proper dir again [10:15] so I don't do it === hunger_t is now known as hunger [10:16] s|k: anything in particular you'd like to work on? [10:16] s|k: usually people do not contribute "to C programs", but to a set of packages that interest them :) [10:16] pitti: Oh, really? I did not know that. [10:16] pitti: Surely that can be fixed? [10:16] soren: that's rather deliberate, I think [10:17] pitti: Surely that can be fixed? :) [10:17] soren: e. g. you might have /usr/share point to a different partition if your /usr becomes full, and similar situations [10:17] you want dpkg to honor the symlink [10:17] pitti: by working on the project itself? [10:18] FYI - addressed concerns in the abiword 2.6 bug [10:18] pitti: Hmm... Sounds reasonable, I suppose. [10:18] as in work on epiphany or something and not ubuntu [10:18] s|k: of course we always welcome people who want to work in a 'horizontal' approach, i. e. fix lots of bugs in lots of different packages [10:18] I see [10:18] s|k: in fact we probably have too few of those :) [10:18] so is it mostly C? [10:18] s|k: if you take the horizontal approach please make sure to send patches upstream :) [10:19] s|k: What I'm trying to say is, we usually don't "dump" work on new contributors; you should rather know what you enjoy working on [10:19] I see [10:19] s|k: I'd say the vast majority of packages are C, but there's a good chunk of Python, Perl, and C# nowadays [10:19] s|k: really varies from project to project - find something that interests you, then use your skills: unlike a job where you have your skills and might be told what "interests you" [10:19] and c++ too [10:19] right ^ [10:20] I see [10:20] s|k: if you want to work on little chunks in various packagages to use and improve your C skills, you might consider looking into fixing confirmed/triaged bugs [10:20] ok, those are listed on launchpad? [10:21] how well do I have to know stuff like gobject and gtk+? Pretty well huh? [10:21] s|k: https://wiki.ubuntu.com/UbuntuDevelopment is a good introduction and link collection about how to get into Ubuntu development, the necessary packaging bits, how to apply patches, etc. [10:21] anybody else seeing evince get stuck during the document loading? [10:22] yeah I have that page open in my tab [10:22] sabdfl: I do [10:22] s|k: people usually learn those while they work on something [10:22] sabdfl: changing the window's size usually help to unstuck it [10:22] sabdfl: hm, works fine for me; only on some documents, or on all of them? pdf? ps? [10:23] seems to be on all the .pdf's i've opened recently [10:23] sabdfl: sometimes, it doesn't actually get stuck it just doesn't update the drawing [10:23] sabdfl: if you minimize it then restore it it works again [10:23] interesting - yes, that works [10:23] could it be a compiz interaction? [10:24] I am sure that is where the blame will end up [10:25] s|k: if you just find something that interests you (an itch to scratch, so to speak) the skills will come with a bit of googling and some experimentation. Remember, nobody needs to know how many builds don't compile on your machine as you learn :) [10:29] pitti, hi [10:29] megabyte405: ok :) [10:29] hey tkamppeter! made it back in one piece? [10:30] yes, pitti, I arrived yesterday, with United. [10:30] sabdfl: could be, I am using metacity on my desktop [10:31] pitti, it is about bug 195782. [10:31] Launchpad bug 195782 in hplip "Users not automatically added to "scanner" group: No scanning functions of HP multi-function in Hardy" [Undecided,New] https://launchpad.net/bugs/195782 [10:32] The HP devices get there "scanner" capability without problem, but there seems to be nothing which sets the permissions then. [10:33] Permissions must be set that both "lp" and the user who is currently logged in on the desktop have read and write access. [10:33] tkamppeter: that needs a hal debug output, I'm afraid (https://wiki.ubuntu.com/DebuggingHal) [10:33] tkamppeter: I thought it worked for you? [10:34] pitti, I checked only the "lshal" output and that was OK. [10:34] you didn't actually try to scan something? [10:34] tkamppeter: well, my scanner (not HP) has the same property, it works fine for it [10:35] so there's something wrong in hal and the auto-ACL magic [10:40] pitti, I have also removed the UDEV rules files of HPLIP, as they should not be needed any more. [10:45] carlos: will Rosetta exports have XPI stuff for dapper to gutsy, too? if so, I need to filter them out in langpack-o-matic (since we don't want them for stables) [10:46] pitti: that's up to asac to decide it [10:46] if we import them, yes, it will [10:46] carlos: ok, so I better filter them out on my side? [10:47] pitti: not really, unless we really import them [10:47] if we import them, I guess is because we need them [10:47] so we won't for dapper to gutsy? asac? [10:47] so if you filter them out... we don't need them and thus, don't neeed to import it in first place :-P [10:47] right [10:51] pitti: he? i don't think this is an issue is it? if the translation is in langpacks users will auto get that? [10:52] asac: but we don't want that for dapper to gutsy [10:52] it conflicts with the mozilla-firefox-locale packages [10:52] and we haven't tested it [10:52] maybe later, but not right now [10:52] pitti, I have tried the debug logging of hald, but I did not find anything useful in there. The word "scanner" does not appear. [10:53] tkamppeter: do you see anything matching 'acl'? [10:53] i don't understand why suddently _gutsy_ pops up while we are preparing hardy? [10:53] tkamppeter: in particular, the setfacl call? [10:53] if you just want to know if we want rosetta exports in gutsy: no! [10:53] asac: right, that was my question; whether i need to special-case hardy in langpack-o-matic or not [10:54] pitti: yes ... all this should not happen right now for anything else than hardy [10:54] pitti: we don't even have ffox 3 in << hardy [10:54] and no templates for gutsy afaict [10:56] pitti, there are calls of the /usr/lib/hal/hal-acl-tool [10:56] tkamppeter: can you put the log somewhere? [10:59] pitti, you can see it as http://www.linux-foundation.org/~till/tmp/hal.log now. [11:02] ci-tracker.c:366: Error doing GetSessionForUnixProcess on ConsoleKit: org.freedesktop.DBus.GLib.UnmappedError.CkManagerError.Code0: Unable to lookup session information for process '5747' [11:02] tkamppeter: ^ do you have a consolekit sessin? ck-list-sessions [11:03] Session1: [11:03] uid = '1000' [11:03] realname = 'Till Kamppeter,,,' [11:03] seat = 'Seat1' [11:03] session-type = '' [11:03] active = TRUE [11:03] x11-display = ':0' [11:03] x11-display-device = '/dev/tty7' [11:03] display-device = '' [11:03] remote-host-name = '' [11:03] is-local = TRUE [11:03] on-since = '2008-04-14T14:37:30Z' [11:03] idle-since-hint = '2008-04-14T16:39:45Z' [11:03] ok, that's fine [11:03] pitti, is that the expected output? [11:03] tkamppeter: do you still have process 5747? [11:05] ps auxwww | grep 5747 [11:05] root 5747 0.0 0.1 134944 3100 ? Ssl Apr14 0:05 /usr/sbin/NetworkManager --pid-file /var/run/NetworkManager/NetworkManager.pid [11:05] till 14546 0.0 0.0 5164 852 pts/0 R+ 12:05 0:00 grep 5747 [11:06] tkamppeter: ah, that shuold be unrelated then [11:06] tkamppeter: at which point did you plug in/switch on the scanner? [11:09] pitti, now I have uploaded a file hal2.log to the same place. There is the plugging at or at least near the beginning. [11:10] hey [11:10] pitti, sorry, I will retry [11:10] tkamppeter: but lshal does have the 'scanner' and 'access_control' properties? [11:10] tkamppeter: and info.callouts.add = {'hal-acl-tool --add-device'} ? [11:11] tkamppeter: hal2.log doesn't exist; but maybe post your lshal output first? [11:13] I need some quick advice: my ubuntu derivative is currently using a xubuntu-7.10-alternate CD which adds the necessary packages for my project. our client decided to go with IceWM instead of XFce, and there are some hardware limitations in the project. Now that it's time to migrate to 8.04, should I rebase using a ubuntu or xubuntu CD? iow, are there any significant differences in the alternate CD installers between the two? [11:14] jordi: alternate should be very much the same. Different package selections, naturally [11:14] I chose xubuntu previously for xfce, but now that I'm not going to use it, I wonder if I should just go with the (better supported?) Ubuntu CD [11:14] Mithrandir: *nod* [11:14] Mithrandir: what about LTS support for xubuntu main packages? [11:14] 5 years as well, for those that differ from Ubuntu? [11:14] jordi: xubuntu is in universe now [11:15] oh [11:15] see, that's a good reason to go with Ubuntu. :) [11:15] so kubuntu and ubuntu remain in main now? [11:15] yes, and the edubuntu bits [11:15]