[04:33] <Emulashun> "sr0: CDROM not ready.  Make sure there is a disc in the drive." -- anyone know why this happens in Ubuntu 8.10 (2.6.27) and if there is a workaround? this happens if the device is physical OR loop mounted
[06:29] <ramirand> Hi - I was encountering a problem with tightvncserver in Ubuntu 8.10 64-bit, so I grabbed the source and fixed it. Is it appropriate to patch that in Ubuntu? Or should I feed the patch to someone at the debian level?
[06:56] <greg-g> ramirand: is the issue with packaging or the actual program?
[06:56] <greg-g> if it is the actual program, sending the patch to those developers would be best, that way everyone gets the fix
[07:06] <savvas> heh
[07:35] <maco> sorry for the psycho-joins. the irssi instances from holding down my shortcut keys (held down because they didnt spawn immediately) spawned faster than i could manually kill them.
[07:36] <Hobbsee> maco: oh good.  so you're not being murdered, and using them as your call for help.
[07:36] <maco> yay for ps, grep, and kill -9?
[07:36] <Hobbsee> yup
[07:37] <maco> oh, and pipes. pipes were highly useful.
[07:57]  * jpds favours the 'killall' but ...
[07:58] <maco> jpds: i wasnt
[07:58] <maco> i wasnt sure if killall or pkill would work without the full command
[07:58] <maco> because i didnt want to kill all of my terminals, just the terminals that had irssi inside them, and im not sure exactly what sort of regex matching killall and pkill do
[07:58] <jpds> Ah, ok.
[07:59] <jpds> killall irssi?
[08:00] <maco> well the process is terminator, i think
[08:01] <maco> because i ran it with "terminator -m -e irssi"
[08:02] <maco> so i dont know if id need to "killall terminator" or "killall irssi" (or pkill of each of those) or if itd have to be the full command...so i ps'd, grep'd, and awk'd out a list of PIDs then piped it to "xargs kill -9"
[09:12] <askand> Hello, rececntly brasero was but in backports, it should be removed from there due to a halfserious bug that changes the language of nautilus and it is not possible to change it back
[09:13] <maco> you're sure brasero did that?
[09:13] <maco> and do you mean hardy or intrepid backports?
[09:14] <askand> maco: intrepid, yes I am sure. I installed 0.91 from getdeb a while ago and my language was changed, I had no idea on why. I was told to reinstall brasero from repos and my language was back. Today I installed 0.91 from backports and again my language is gone
[09:14] <askand> sorry that is 0.9.1
[09:14] <maco> oh. ouch.
[09:14] <askand> yea..
[09:15] <askand> It is a bug only affecting those using another language than english so that would explain not many people have noticed until now I guess :)
[09:15] <maco> lemme see who backported that...
[09:17] <askand> maco: Sure, according to getdeb libbrasero-media package is guilty
[09:19] <maco> askand: thank you. i'll tell one of the backports maintainers
[09:20] <askand> maco: glad to help
[09:27] <maco> askand: is it changing the language throughout gnome, or *just* in nautilus, by the way?
[09:27] <maco> either way its a problem, just wondering the extent
[09:39] <askand>  maco: it is just nautilus and not all of nautilus
[09:39] <askand> maco: for example things in the contextmenu when rightclicking files has changed
[09:40] <askand> maco: and a lot of dialogs, for example "Are you sure you want to permanently delete xxx"
[09:48] <askand> maco: And it wont show until nautilus is restarted
[09:49] <maco> ok
[09:50] <maco> i just told an archive admin. he said to file a bug to document why he's removing it, so i did that.
[10:08] <askand> maco: great, is it possible to downgrade versions with an update?
[10:08] <maco> yes
[10:09] <maco> if you download the old version you can use dpkg to install it like this: sudo dpkg -i --force-downgrade brasero-oldversion.deb
[10:09] <maco> obviously, insert the right filename
[10:09] <askand> maco: ah thanks
[10:11] <Hobbsee> or just apt-get install foo=1.3.4-0ubuntu1 or whatever
[10:11] <Hobbsee> if you still have it in your apt cache
[10:12] <maco> Hobbsee: good to know!
[10:12] <Hobbsee> indeed :)
[10:12] <maco> i just read through the list of dpkg --force-things in the manpage so many times its the way i automatically think of
[10:13] <Hobbsee> you usually don't want to use force ;)
[10:13] <maco> heh its how i downgraded away from the screwed up synaptics driver that was in jaunty last week
[10:13] <maco> then did an aptitude hold to avoid it coming back
[10:14] <Hobbsee> better to do a dpkg hold, as it works across apt too
[10:14] <Hobbsee> echo packagename hold | sudo dpkg --set-selections
[10:15] <maco> meh i use aptitude for everything anyway. dont you need dselect for --set-selections to make any sense thoug?
[10:21] <Hobbsee> not sure
[10:21] <Hobbsee> i don't use dselect
[10:39] <askand> maco: Am I further needed here about the braserobug, otherwise I leave and wish you a good day :)
[10:40] <maco> nope
[10:40] <maco> thats enough info
[11:08] <ziroday> Hi, I'm seeing a bug with my touchpad mouse buttons. Basically where the left click sporiadically acts like a middle click. Which packages should I report that against?
[11:09] <maco> ziroday: jaunty? its reported
[11:10] <maco> ziroday: the xserver-xorg-input-synaptics v 0.99.3 caused it, but the -2ubuntu2 release should cler it up
[11:10] <ziroday> maco: ooh looks like I've been looking at the wrong bug
[11:11] <ziroday> maco: where was it reported?
[11:13] <maco> bug 320639
[11:15] <ziroday> maco: ah, well I had the touchpad acting strange too but I thought that was just me imagining things. That bug report doesn't mention left click acting like middle click randomly though. Should I comment there or file a new report for that?
[11:15] <maco> i think it does...
[11:16] <ziroday> maco: ah I see it, my bad skim reading :(
[11:16] <ziroday> maco: how can I see what model of touchpad I have?
[11:17] <maco> er....lshal maybe?
[11:18] <ziroday> maco: found it, you are a genius
[11:21] <ziroday> maco: thank you so much!
[11:22] <maco> np
[11:41] <Laibsch> I wonder if somebody has an idea how to replace my "universal one-liner" for compiling foreign packages and upload them to a particular series in my PPA (question 51583 which has been broken by bug 315643)
[11:42] <Laibsch> I want to compile for example debian packages in my PPA without making any changes (including changelog)
[11:43]  * Hobbsee notes that makes as little sense to her today as it did yesterday.
[11:43] <Hobbsee> perhaps saying what the universal one liner actually expanded to might help
[11:44] <Hobbsee> autoppa might be what you're after
[11:45] <Laibsch> Autoppa looks interesting, but it's not what I am looking for
[11:46] <Laibsch> Hobbsee: https://answers.launchpad.net/soyuz/+question/51583
[11:46] <Laibsch> Can you take a look
[11:46] <Laibsch> ?
[11:46] <Laibsch> dpkg-genchanges -S -sa > ../tmp.changes &&  debsign -k$GPGkeyid ../tmp.changes &&  dput $target ../tmp.changes
[11:46] <Laibsch> that is my one-liner
[11:47] <Laibsch> It does not have anything package-specific in it, so I can call it up in any unpacked source directory from bash-history without changing anything in it
[11:48]  * Hobbsee sighs at that bug.
[11:48] <Laibsch> Recently, Launchpad started to refuse tmp.changes -> bug 315643 (which will likely not be fixed in a way that helps me)
[11:48] <Laibsch> Hobbsee: the bug or the question?
[11:49]  * Hobbsee doesn't agree that dput should be used to show what is or isn't legal syntax, for any given upload destination.  each program does one task, and does it well, right?
[11:49] <maxb> Well... dput already has the "is the .changes signed" check
[11:50] <Hobbsee> exactly
[11:50] <Laibsch> Maybe you can leave a comment to that effect in the bug?
[11:50] <savvas> Laibsch: if you don't introduce any changes in the ubuntu package, you don't need to alter the changelog, keep the debian version, isn't that right?
[11:50] <maxb> Laibsch: Write a small script that computes an appropriate filename using dpkg-parsechangelog. Sorry, no more oneliner, but it was a pretty complex one anyway
[11:51] <maxb> savvas: Yeah, but you still need to create a .changes
[11:51] <maco> Laibsch: i think she's saying she doesnt see any reason why dput should be forced to check such a silly thing
[11:51] <Laibsch> sava
[11:52] <Laibsch> savvas: you can determine with the changelog of which release pocket the upload goes into
[11:52] <Hobbsee> and you'd think that dpkg-source would be forced to output such a file.
[11:52]  * Hobbsee checks debian policy
[11:54] <maxb> Hm. <https://help.launchpad.net/Packaging/PPA#Using%20packages%20from%20other%20distributions> is mysteriously silent on where you're supposed to get the .changes from
[11:54] <maco> debuild -S?
[11:54] <Hobbsee> yes
[11:54] <Hobbsee> (it's autogenerated)
[11:55] <maxb> For which you need to unpack the source, no? And if you've done that, why not edit the changelog anyway?
[11:56] <Laibsch> I usually unpack the source
[11:56] <Laibsch> editing the changelog is one more unneccessary step
[11:56] <Laibsch> And I prefer for completely unchanged uploads to not touch it
[11:57] <Hobbsee> hrm.  can't find a mandate for how the .changes file should be named in debian policy
[11:57] <maxb> fair enough, but dch makes it so very easy
[11:57] <Laibsch> debuild -S runs into trouble at times.  For example I had "debuild -S -sa" fail on me for some Java package which actually needed some package from build-depends just for that task which was not installed on my box
[11:58] <Hobbsee> well, yes, you'll need to have all the build dependancies to build a package...
[11:58] <Hobbsee> it's not wrapped around like pbuilder
[11:58] <Laibsch> Up until that point I thought the build-depends were only really necessary when actually compiling and creating the package
[11:59] <Laibsch> Hobbsee: yes, a lesson I learned
[11:59] <Hobbsee> oh, i see what you mean
[11:59] <Hobbsee> the source build dependancies.
[11:59] <Hobbsee> yes, they're not anywhere, which can be a slight pain
[11:59] <maxb> Only needed for the clean stage, right?
[12:00] <savvas> has anyone seen a bug report/wishlist for a hand mouse pointer for pdfs in evince?
[12:00] <Hobbsee> maxb: hrm?
[12:01] <maxb> Theoretically it should be possible to build a source package without invoking any debian/rules stuff if you know it's pristine, right?
[12:02] <Hobbsee> er, yes.  although pristineness probably doesn't matter?
[12:03] <Hobbsee> Laibsch: so, you're trying to build a whole bunch of packages, for which you already have the old source.changes files, or need to generate them?
[12:03] <Laibsch> I need to generate them
[12:03] <Laibsch> My workflow is usually like this
[12:04] <Laibsch> dget -ux $dsc
[12:04] <Laibsch> cd $packagename
[12:04] <Laibsch> plus my one-liner above
[12:04] <Hobbsee> oh
[12:06] <Hobbsee> dpkg-buildpackage -S -sa -rfakeroot -k<key ID> && cd .. && dput *.changes?
[12:06] <Hobbsee> personally, though
[12:06] <Hobbsee> i'd grab the dsc's i needed (probably by another script)
[12:07] <Laibsch> You mean, you'd grab the *.changes you needed?
[12:08] <Hobbsee> wait.
[12:08] <Laibsch> will dpkg-buildpackage succeed even if you don't have build-dependencies installed?
[12:08]  * Laibsch has some doubts
[12:08] <Hobbsee> no
[12:09] <Laibsch> See, my one-liner was quite universal in that respect
[12:09] <Hobbsee> no, hang on.
[12:09] <Laibsch> I think I even used dpkg-buildpackage before that, and debuild -S -sa and even before that, but I was annoyed by the long time that took
[12:11] <Hobbsee> for i in `basename .dsc *.dsc`; do dpkg-genchanges $i.dsc > $i_source.changes && debsign -k <foo> $i_source.changes && dput $i_source.changes; done ?
[12:11] <Laibsch> bug 276391 could serve as a test case. I'd want to be able to prepare and upload that package without having to install java-gcj-compat-dev.
[12:11] <Hobbsee> or something along those lines?
[12:11] <Laibsch> Hobbsee: Yes, that could probably do
[12:11] <Laibsch> And I might use
[12:12] <Hobbsee> that gets you out of building it.
[12:12] <Laibsch> I just liked the simpleness before.
[12:12] <Hobbsee> which avoids the source build dep problem.
[12:12] <Laibsch> Thanks for helping out
[12:12] <Hobbsee> actually, it's pretty close to what you had ;)
[12:12] <Laibsch> I'll experiment along your suggestion
[12:12] <Laibsch> I needed no real variables
[12:12] <maxb> Hobbsee: dpkg-genchanges wants a source-tree, not a .dsc
[12:12] <Laibsch> $target was usually hardy for me
[12:12] <Hobbsee> maxb: oh, does it?  bugger.
[12:13] <Hobbsee> erm.  not bugger.
[12:13] <Laibsch> $key was of course my key
[12:13] <Laibsch> no problem, dget -ux $dsc unpacks the stuff
[12:13] <Laibsch> I have the source unpacked
[12:15] <Hobbsee> that's a point
[12:15] <Hobbsee> so you could do some sed'ery to figure out what the directory below is, in name
[12:15] <Hobbsee> that's a bit of a pain
[12:15] <Laibsch> yes
[12:16] <Laibsch> Indeed
[12:16]  * Hobbsee wonders if pbuilder's a bit of a solution
[12:16] <Laibsch> not always
[12:16] <Laibsch> think openoffice.org which would kill my machine
[12:16] <Hobbsee> doesn't look like you can get pbuilder to build source only.
[12:17] <Laibsch> And btw, I think your solution doesn't really work: http://rafb.net/p/l6CgDD78.html is my /usr/src
[12:17] <Laibsch> tons of dsc files in there
[12:18] <Laibsch> I cannot even guarantee there will be only on dsc for every package name
[12:18] <Hobbsee> oh, right
[12:18] <Hobbsee> i was assuming you were only doing a whole bunch once, and moving / deleting them after uploading
[12:18] <Laibsch> so, I'm still screwed :-/
[12:18] <maxb> Also, it turns out the dpkg-genchanges actually requires a *built* source tree
[12:18] <Laibsch> no, I keep most of them around.  Some of them I maintain officially and want to be able to do updates later
[12:19] <maxb> Because it wants to read debian/files
[12:19] <Laibsch> Or I do prepare a number of SRU debdiffs for the same package in parallel
[12:21] <Laibsch> Is there any good reason these LP people require this particular file name?
[12:21] <Laibsch> Maybe we can get them to revert their decision?
[12:22] <Laibsch> This seriously gets in my way
[12:23] <Hobbsee> i've got no idea
[12:23] <Hobbsee> i can't seem to find it in debian policy that changes files *must* be labelled in a particular way
[12:23] <Hobbsee> it seems to specify the contents of the files, but not the filenames themselves
[12:24] <Hobbsee> if you can find the answer to that, one way or the other, then you'll have a good answer on whether htey will have to revert it (to follow policy), or whether they'll keep it
[12:24] <Laibsch> My hunch is that there is no such policy in debian
[12:25] <Laibsch> But maybe they did that to prevent my tmp.changes for package X overwriting that from user Y for package Z in the upload area.  Not sure.
[12:26] <Hobbsee> well, if there's no such policy, then you could probably argue that it should be reverted.
[12:26] <maxb> Laibsch: http://rafb.net/p/EMBTvT39.html <-- script that does the job
[12:26] <Hobbsee> i thought it all went directly into librarian, and everything gets a different sequence #
[12:27] <maxb> It does - there's an existing soyuz bug open complaining that you have to do the entire upload in a single FTP connection
[12:27] <maxb> (Which doesn't seem all that onerous to me, personally)
[12:30] <Laibsch> maxb: Thanks a lot.
[12:30] <Laibsch> Quite some black magic involved there
[12:31] <Laibsch> what's dsc=${dsc##*/} ?
[12:31] <maxb> hehe
[12:31] <Laibsch> Does that work in the course of multiple unpacked source directories?
[12:32] <maxb> Well, it could use some refinement - at the moment it will trample over existing unpacked source
[12:32] <maxb> And it ought to clean up the temporary source unpacks too
[12:33] <maxb> ${dsc##*/} is the value of $dsc with the longest prefix matching the pattern */ removed
[12:40] <Laibsch> Hm, I have to admit this is too heavy for me at this time of day.
[12:42] <andresmujica> yaww.. morning
[13:33] <mvo> bdmurray: I wonder if we could have a bughelper recipt for https://bugs.edge.launchpad.net/ubuntu/+source/xine-lib/+bug/323073
[13:47] <hggdh> pedro_, ping
[13:48] <pedro_> hggdh: hey
[13:48] <hggdh> pedro_, good morning. Could you please renew my membership on bug-control?
[13:49] <pedro_> hggdh: yes sr, give me a min please
[13:52] <pedro_> hggdh: its going to expire in June -> 2009-06-05
[13:52] <hggdh> ??
[13:52] <pedro_> hggdh: did you get any email saying that is about to expire?
[13:52] <hggdh> pedro_, yes, let me check it again
[13:53] <pedro_> hggdh: https://edge.launchpad.net/~ubuntu-bugcontrol/+members
[13:53] <hggdh> pedro_, sorry, it is on bugswaud
[13:53] <hggdh> bugsquad
[13:53] <pedro_> hggdh: aha, i think you can do that, it's an open team
[13:54] <pedro_> hggdh: could you try? otherwise i'll renew it
[13:54] <hggdh> pedro_, sorry, I did not expect a renewall on bugsquad. I am getting there now
[13:57] <hggdh> pedro_, done. I am really sorry
[13:57] <pedro_> hggdh: no problem ;-)
[14:09] <calc> yipee OOo is back over 90% watched bugs :)
[16:51] <davideotape1> Hi guys
[17:01] <rainmanp7> Yo :) hello Good afternoon
[17:01] <hyperair> good morning
[17:01] <hyperair> it's 1am here heh
[17:04] <kyselejsyrecek> and 6p.m. here, :D hi
[17:04] <rainmanp7> Ok question :)
[17:06] <rainmanp7> I have 2 wireless adapters i need to get working there 2 different models how can I go about getting them supported into ubuntu ?
[19:27] <nuubuntu> anyone got any adive on a fix for the wifi issue w/ acer 5515 and ubuntu 8.10