[12:33] <keescook> leonel: great!
[12:46] <crimsun> keescook: no runes, no.  I do it manually.
[12:48] <keescook> crimsun: would you mind looking over http://revu.tauware.de/details.py?upid=5419 since I'm still a bit new to REVU work?
[12:49] <crimsun> sure
[12:49] <crimsun> (will do)
[12:49] <fernando> exists other way to upload to revu instead ftp?
[12:55] <crimsun> keescook: looks good, did you have any particular question(s) about it/protocol?
[12:56] <keescook> mostly I just wanted to know what the process was since I was the 2nd person +1 it.  should I upload it?
[12:56] <crimsun> keescook: if you'd like, certainly
[12:56] <crimsun> it has the equivalent of three ACKs
[12:56] <keescook> ah, needs 3 not 2?
[12:56] <crimsun> (only requires 2)
[12:56] <keescook> okay
[12:56] <crimsun> I reviewed it last for the debian/control:Depends addition
[12:57] <keescook> and is it just you that cc's motu with REVU uploads, or is that something everyone up'ing from REVU should do?
[12:57] <crimsun> yes, if you upload a new source package originating from revu, archive it, and send an email to the ubuntu-motu ML
[12:58] <keescook> okay, will do
[12:58] <crimsun> thanks
[01:00] <persia> crimsun: 3 ACKs?  I thought the two ACKs needed to be for the same revision.  Is this not the case?
[01:00] <crimsun> ?
[01:01] <keescook> persia: right, I think crimsun ack a totally different version
[01:01] <persia> (05:56:30) crimsun: it has the equivalent of three ACKs
[01:01] <crimsun> 18:55 < crimsun> keescook: looks good
[01:01] <crimsun> 18:56 < crimsun> I reviewed it last for the debian/control:Depends addition
[01:01] <crimsun> that constitutes an ACK
[01:02] <crimsun> the ttf-bitstream-vera addition came from my previous on-IRC review with Mario
[01:02] <persia> crimsun: Ah.  The IRC ACK.  Thanks.
[01:02] <crimsun> np
[01:23] <leonel> we need to fix the kernel   so  when a kernel update is done  there's no need to reboot  to use the new kernel :)
[01:25] <keescook> crimsun: how do I "archive" the REVU entry?
[01:25] <crimsun> go to the main page, find the entry, click Archive on the far right.
[01:25] <keescook> oh, durr.  heh, I was hunting around on the upload page.  :)
[01:26] <crimsun> ;)
[01:37] <crimsun> insecure temp file creation, eh?  I'm suddenly reminded why we stopped shipping alsaconf.
[01:55] <nesl247> Hi folks. Is there any guide to creating packages, other than the one that contains hello-debhelper or whatever the package was called?
[02:00] <crimsun> nesl247: guide?  Meaning the Ubuntu Packaging Guide and the Debian Policy Manual & Debian New Maintainers' Guide & Debian Developer's Reference?
[02:00] <nesl247> Whatever the one linked in the how to become a motu one, is one that I never want to see. One that I looked at already
[02:00] <crimsun> (and I really think that ought to be New Maintainer's to be consistent with Developer's, but whatever.)
[02:01] <crimsun> nesl247: constructively, what did you find horrible about it?
[02:02] <nesl247> It's completely useless
[02:02] <nesl247> It's says a bunch of times, this is an example package, we have no need for file x, y, and z
[02:02] <nesl247> And is too basic to actually learn to package
[02:02] <nesl247> Because it has like no deps, nothing at alll
[02:02] <nesl247> all*
[02:03] <crimsun> ok.  Can you recommend a better package with which to begin - one that will appeal to both novice packagers and seasoned non-Debian packagers?
[02:03] <nesl247> Any package
[02:03] <nesl247> tar, alsa, compiz, doesn't matter
[02:04] <crimsun> I'm going to blithely ignore the "alsa" option, because that's utterly unrealistic.
[02:04] <nesl247> And the guide doesn't go into detail enough
[02:04] <nesl247> It should basically walk you through step by step, line by line
[02:05] <nesl247> crimsun: I haven't seen alsa's packaging, so I wouldn't know
[02:05] <crimsun> ok, I'm sure there are several developers here who can work with you on improving the reference if you desire.
[02:05] <crimsun> well, I _am_ familiar with it.  I maintain it in Ubuntu.
[02:06] <bluekuja> lionel, ping
[02:06] <crimsun> maybe we can pick one package from each big language team, so to speak
[02:07] <nesl247> I'd much rather you guys spend time on redoing the ubuntu packaging system all together heh
[02:07] <crimsun> say, quodlibet for Python, pavucontrol for C, etc.
[02:07] <minghua> I'd rather not.
[02:07] <nesl247> I've never seen anything so complicated.
[02:08] <crimsun> that's not an Ubuntu issue.  You want to talk to the dpkg development team in Debian, since we use dpkg and apt-based tools.
[02:09] <nesl247> I'm not trying to start a flamewar, and am truely interested, so please don't bite my head off, but have you guys ever considered using something different?
[02:09] <crimsun> for this group of universe maintainers?  As a group it has never crossed "our" mind.
[02:09] <crimsun> for Ubuntu development, certainly it has crossed the minds of at least a couple Canonical employees who work on Ubuntu.
[02:09] <minghua> if you derive from debian, you must use debian packaging, I don't think there is negotiation room for that
[02:10] <persia> minghua: One could do something like alien (although I'd be opposed).
[02:10] <crimsun> people have suggested ebuilds, conary, checkinstall (?!), forgetting packages altogether and dumping crap wherever...
[02:10] <minghua> persia: you forgot to mention checkinstall...
[02:10] <crimsun> (don't worry, I just did.)
[02:10] <nesl247> Who says you have to use debian packaging?
[02:11] <persia> minghua: There's a reason for that :)
[02:11] <minghua> crimsun: :-)
[02:11] <nesl247> Just because you originally started as a debian fork, doesn't mean you can't change.
[02:11] <crimsun> nesl247: Debian is our source pool.  It would be foolish to dump it.
[02:11] <nesl247> I was just curious. I know the complication of packaging has turned me off from ever creating a deb
[02:11] <crimsun> Consider how many source packages are synced (unchanged in Ubuntu) directly from Debian main.
[02:12] <nixternal> there is no way in hell I could keep up with bdmurray with the triage man...I have gone 8 hours straight and finally cleaned up kdepim
[02:13] <crimsun> take a look at the bottom left pie chart at http://merges.ubuntu.com/universe.html
[02:13] <nixternal> I find it funny that if you ask someone for more info, they won't answer for months, but as soon as you "close" a report, they respond within 10 minutes
[02:13] <crimsun> nixternal: of course.  That's why I always reject immediately. ;)
[02:13] <crimsun> j/k
[02:13] <nixternal> hahaha
[02:13] <persia> nixternal: That's why they get closed after a month or two of not responding to "Needs Info" :)
[02:13] <nixternal> I need to go through kdelibs next
[02:14] <nixternal> persia: I do the same....30 days and no response, the is long enough, closed, reopen if issue still exists..kthxbye ;)
[02:14] <crimsun> nesl247: as you might infer, completely obliterating that navy blue (or some shade thereof, I'm a bit colour-stupid) portion would be unwise.
[02:14] <nixternal> man, testing kdepim bugs, I crashed KMail a hundred times, destroyed my smtp settings
[02:15] <nesl247> crimsun: huh?
[02:15] <crimsun> 20:13 < crimsun> take a look at the bottom left pie chart at 
[02:15] <crimsun>                  http://merges.ubuntu.com/universe.html
[02:15] <nesl247> Oh
[02:18] <snerfu> I took the battle for wesnoth and retooled it to be a wastelands style game.
[02:20] <snerfu> I wonder if googlepages would be a good place to host it.
[02:22] <persia> Would anyone be willing to lead me through the process of sponsoring requests for SRU updates (into -proposed)?
[02:22] <crimsun> persia: sure.
[02:22] <crimsun> err, I need more tea, though.
[02:23] <persia> crimsun: Thanks.  When you get your tea, could we look at bug 69151?
[02:23] <ubotu> Launchpad bug 69151 in dvdauthor "Edgy: dvdauthor: segfault" [Undecided,Confirmed]  https://launchpad.net/bugs/69151
[02:26] <apachelogger> http://pastebin.kubuntu-de.org/1203
[02:26] <crimsun> persia: ok, so the patch needs some review.  First it needs indication of origin.
[02:26] <apachelogger> :S
[02:26] <apachelogger> any idea why this is happening?
[02:27] <crimsun> persia: origin needs to be noted either in the patch itself or in debian/changelog
[02:27] <persia> crimsun: OK.  Are there restrictions on Origin (must be backported from development or upstream) or are locally produced patches acceptable?
[02:28] <crimsun> persia: the latter
[02:28] <persia> OK.  So the patch generator could just report that they created a new patch as well.
[02:28] <crimsun> persia: absolutely
[02:28] <crimsun> just as long as the patch pedigree is unquestionable.
[02:29] <persia> Next, I'm guessing that it needs to be listed as "edgy-proposed" (looking in more detail, this might not really be a SRU request, but I'd like to keep it as an example).
[02:29] <crimsun> persia: right, for the distribution
[02:30] <crimsun> it's a suitable SRU candidate, as it would appear to resolve a fairly major issue
[02:30] <persia> So, assuming that the patch is acceptable, would I verify that the patch submitter was willing to follow the SRU process (as "Needs Info"), and just upload to proposed, or are there additional steps required?
[02:32] <crimsun> just upload, correct  (noting the version would need to be fixed -5ubuntu0.1)
[02:32] <minghua> persia: just curious -- is this bug fixed in feisty/gutsy?
[02:33] <persia> OK.  That's easier than I thought.  I was a little worried about "The sponsor of the upload is responsible for testing the update." from MOTU/SRU, as I don't use most of the pending packages, and wasn't sure how to test.
[02:33] <crimsun> persia: you are responsible, yes, but that comes after an ubuntu-sru member has stated that it's available in -proposed for testing, after which you'd send an email to the ubuntu-motu ML to request testers
[02:33] <persia> minghua: This is an old bug, and that probably needs investigation.  I haven't looked yet, but if I don't see something obvious, I'll ask the patch submitter to investigate more deeply when preparing new sponsorship requests.
[02:34] <persia> crimsun: OK.  So I send the mail to ubuntu-motu, rather than the patch submitter?
[02:34] <crimsun> persia: asking for testers, correct
[02:35] <crimsun> yes, the universe SRU procedure was overhauled as the MOTU Council's first item of business
[02:35] <crimsun> or was it the second?  I'm losing my memory.
[02:36] <crimsun> anyhow, one of the major complaints was that there was too much red tape in universe SRUs, so MC tried to change that - hopefully for the better
[02:36] <persia> crimsun: OK.  Thanks.  I think I need to organise some stable test environments before actually sponsoring these, but I can now triage them (and further reduce the sponsors queue).
[02:36] <crimsun> persia: yep, thanks!
[02:36] <crimsun> tritium: :)
[02:36] <persia> I'd prefer to dump responsibility for chasing testers on the contributor, but I understand the decision :)
[02:44] <persia> Grr..  https://launchpad.net/ubuntu/dapper-updates/+source/foo should go somewhere.
[02:44] <crimsun> wishlist!
[02:44] <persia> crimsun: Malone or Soyuz?
[02:45] <crimsun> launchpad
[02:46] <crimsun> apachelogger: it's in rejected; I can't move it because I don't have the powah
[02:52] <cypherbios> Hi. I'm packaging an application using python-distutils (aka setup.[py,cfg] ) and the localization files (.mo) are going to a wrong place (going to /usr/share/locale/$LANG instead of /usr/share/locale/$LANG/LC_MESSAGES). Anyone knows what could it be?
[02:56] <persia> Ah.  Never mind.  Those URLs shouldn't work.  That information is contained in .../dapper/... as a separate pocket.
[02:56] <crimsun> cypherbios: is the Makefile correct?
[02:57] <crimsun> or if it doesn't use a Makefile, is the install target for the po data correct?
[02:57] <cypherbios> crimsun: oh. I think is it...
[02:57] <cypherbios> crimsun: but the Makefile seems to be correct:
[02:58] <cypherbios> %.mo : %.po
[02:58] <cypherbios> 	mkdir -p $(subst .po,,$<)/LC_MESSAGES/ 
[02:58] <cypherbios> 	msgfmt $< -o $(subst .po,,$<)/LC_MESSAGES/$(DOMAIN).mo
[02:58] <crimsun> hmm, yes.
[02:59] <cypherbios> crimsun: the build log shows me this:
[02:59] <cypherbios> creating /home/cypher/aptoncd-dev/packaging/debian/0.1.91-1/tmp/aptoncd-0.1.91/debian/aptoncd/usr/share/locale/pt_BR
[02:59] <cypherbios> copying build/mo/pt_BR/LC_MESSAGES/aptoncd.mo -> /home/cypher/aptoncd-dev/packaging/debian/0.1.91-1/tmp/aptoncd-0.1.91/debian/a
[02:59] <cypherbios> ptoncd/usr/share/locale/pt_BR
[03:00] <cypherbios> crimsun: the build/ directory has the correct directory tree, but copies to a wrong directory...
[03:01] <crimsun> hmm
[03:01] <crimsun> type subst
[03:02] <crimsun> shell builtin?
[03:03] <cypherbios> crimsun: what? I didn't understand...
[03:05] <crimsun> ah, right, make.
[03:06] <cypherbios> crimsun: the lines above I've retired from the .build file
[03:06] <crimsun> yes, I somehow ignored that you pasted from a Makefile instead of shell script (?!)
[03:06] <crimsun> (long day)
[03:07] <cypherbios> :)
[03:11] <crimsun> will have to look at the source package.  Doesn't seem immediately obvious from here.
[03:11] <crimsun> (more tea)
[03:37] <leonel> keescook: for bug 119386  does not apply to  dapper and edgy   tested the bad.rar file  and  no problems there  and  the CVEs say that are for  clamav 90.  The temp files bug is  for the  function  cli_gentempstream  which does not exist  in clamav 88 
[03:37] <ubotu> Launchpad bug 119386 in clamav "Remote Attack in RAR Files and Insecure Temporary Files Creation" [Undecided,Confirmed]  https://launchpad.net/bugs/119386
[03:38] <Simon80> if a new package gets into debian, will it automatically sync into Ubuntu?
[03:41] <bryyce> often, but not always
[03:42] <bryyce> see http://merges.ubuntu.com/main.html
[03:42] <keescook> leonel: ah! great, thank you.
[03:45] <joejaxx> Simon80: you have to request it i believe
[03:46] <Simon80> hrm, ok, thanks
[03:55] <minghua> bryyce: I doubt that merge page answers Simon80's question
[03:55] <minghua> Simon80: it eventually will, but may take quite some time
[03:55] <Simon80> alright
[03:56] <Simon80> cause I saw an update get in faster than this new package I'm watching
[03:58] <minghua> Simon80: yeah, unchanged packages (without ubuntuX in the version number) get synced automatically, new packages need manual approval to get synced, IIRC
[03:58] <Simon80> but they usually get approved?
[03:58] <Simon80> not that I'm desperate for this package to get in :D
[04:00] <Fujitsu> New packages will automatically sync unless they're in contrib or non-free, but they have to go through source and binary NEW like anything else.
[04:01] <minghua> Simon80: at this stage, yes, they usually get approved
[04:01] <minghua> Fujitsu: you can't really call stuck in NEW as "get synced", can you? :-)
[04:02] <minghua> Fujitsu: but thanks for the clarification
[04:02] <Fujitsu> minghua: Why not? There's no manual process that has to be performed by us.
[04:03] <minghua> Fujitsu: okay, I see what you mean.  I wasn't really thinking of the "re-sync with debian, drop all ubuntu changes" type of sync
[04:04] <Fujitsu> Neither was I. I was thinking of the brand new package in Debian type.
[04:04] <Fujitsu> minghua: ^^
[04:05] <minghua> Fujitsu: then what are you referring by "no manual process that has to be performed by us"?  which other syncs need manual process?
[04:06] <Fujitsu> minghua: You said `new packages need manual approval to get synced'. You meant NEWing?
[04:06] <minghua> Fujitsu: and by "us" do you mean MOTUs, or developers in general, especially ftp-masters (or what do they call it, archive admins?)?
[04:06] <Fujitsu> `us' meaning not archive admins.
[04:06] <Fujitsu> I should have probably clarified that.
[04:07] <minghua> Fujitsu: no, I was wrong on that statement, I thought some archive admin needs to enable syncing new packages instead of just packages already in ubuntu
[04:08] <Fujitsu> Well, they have to run a separate script to import new ones rather than just the normal autosync, but it's done regularly like the normal one.
[04:08] <Fujitsu> So it's not really manual.
[04:09] <Fujitsu> Just done less regularly.
[04:10] <minghua> Fujitsu: I am confused.  Except the "dropping all ubuntu changes, resync with debian" type, neither new packages nor updated packages need our (non archive admin) manual processing. Is that correct?
[04:10] <Fujitsu> Right (until DebianImportFreeze)
[04:11] <Simon80> I can't wait
[04:11] <Simon80> DebianImportFreezeParty!!!!!
[04:12] <Simon80> PartyDownLikeThereIsNoMoreUbuntuReleases!
[04:12] <minghua> granted, you usually don't need a strong reason for parties, but still
[04:12] <Simon80> yeah, I was going to say
[04:12] <Simon80> whatever you can use to justify it
[04:12] <Simon80> one can take a cue from ncix.com, who are perpetually holding a sale, and I'm not exaggerating
[04:13] <Simon80> last one I checked on was called the "Pre-Summer" sale or something
[04:13] <Simon80> yep
[04:15] <Fujitsu> Hm, I really shouldn't have been coding this weather station communication program at 2am. Converting miles->kilometres by dividing by 1.6 is really not the way to go.
[04:16] <Simon80> well, obviously, you multiply by (1/1.6), to save repeated division
[04:17] <Simon80> if you don't do that, the wasted cpu resources will cause the weather station to asplode
[04:17] <Fujitsu> Of course.
[04:18] <Simon80> what were you referring to there? I don't actually see the problem
[04:18] <minghua> you should multiply by 1.6
[04:18] <Simon80> oh, right
[04:18] <Simon80> this is why I need sleep
[04:18] <minghua> or it that "multiply with"?
[04:20] <Fujitsu> 'by' is correct, I believe.
[04:20] <minghua> thanks Fujitsu
[06:33] <nixternal> anyone know which package would control issues on external usb devices/drives that are formatted ext3/reiser and not allowing people to execute? 
[06:33] <nixternal> would the be kernel related? udev?
[06:34] <nixternal> I can't confirm this, as all of my external usb devices/drives are ext3 and I have none of the issues that everyone responded to in this one report
[06:37] <persia> nixternal: There are a large number of packages installed.  Unfortunately, it takes significant investigation of a broken system to determine the culprit.  You might add mount and friends to your list as well, or even the desktop volume management systems, which might pass frustrating flags under certain conditions.
[06:37] <nixternal> true
[06:37] <persia> Um  s/installed/possibly related/
[06:39] <nixternal> seeing as they are external usb devices, I was thinking pmount as well
[06:42] <persia> nixternal: Maybe.  Is pmount there by default?  It's not installed for me (and I automount USB devices without trouble).
[06:45] <minghua> persia: that's very strange.  do you have ubuntu or kubuntu?
[06:45] <persia> minghua: Um...  ubuntu-minimal plus packages I like :)
[06:46] <persia> I'm using GNOME, so it's probably more similar to ubuntu.
[06:47] <minghua> persia: Hmm, actually I am probably wrong.  I though gnome-volume-manager will eventually pull in pmount.
[06:48] <minghua> persia: it seems, at least in Debian unstable now, g-v-m use gnome-mount instead.
[06:48] <persia> gnome-volume-manager -> gnome-mount -> dbus/hal
[06:48] <minghua> let me check etch
[06:49] <persia> minghua: I think it used to be that way - and that I used to have pmount installed, but I no longer remember the transition.
[06:50] <minghua> persia: yes.  in Debian etch, g-v-m 1.15.5 still depends on pmount
[06:50] <minghua> (etch has gnome 2.14/2.16 mix by the way)
[06:50] <persia> minghua: That makes sense.  I think it's that way in edgy, but I'm not sure about feisty.
[06:51] <minghua> feisty is 2.18, isn't it?  then it should already be using gnome-mount, as Debian unstable has 2.18.
[06:51] <persia> minghua: Yep.  I just checked, and feisty indeed uses gnome-mount.
[06:52] <persia> On the other hand, I think kubuntu uses pmount to serve kdebase-kio-plugins
[06:54] <minghua> kdebase is one of the only two packages that depend on pmount in Debian unstable right now
[06:55] <minghua> (in etch it is four)
[07:01] <persia> Odd.  Debian bug 391502 appears to tell the story, but it looks like pmount really shouldn't be required.
[07:01] <ubotu> Debian bug 391502 in kdebase "Incorrect dependency on pmount" [Serious,Closed]  http://bugs.debian.org/391502
[07:03] <persia> nixternal: Do all the users with that problem use KDE?  It seems that there was a patch applied to Debian that might have leaked, which could cause odd issues.
[07:03] <nixternal> no
[07:03] <nixternal> they use kde and gnome
[07:04] <persia> In that case, it's down into ubuntu-minimal territory.  mount, udev, linux, and freinds.
[07:05] <persia> Or perhaps hal, if these are all desktop mounts.
[07:05] <nixternal> hal or pmount
[07:05] <persia> nixternal: I doubt pmount, just because it's only in kubuntu - the GNOME users wouldn't encounter the problem with pmount.
[07:06] <nixternal> orly
[07:06] <minghua> persia: shouldn't, yes; but unfortunately the reality still requires a dependency according to the bug
[07:06] <nixternal> interesting
[07:06] <persia> minghua: Yep.
[07:07] <minghua> nixternal: bug number?
[07:07] <nixternal> man, I gotta find it now :)
[07:07] <minghua> stabbing in dark, I would bet on hal
[07:07] <persia> minghua: Be prepared - there are at least three or four separate master bugs currently building about user mount issues, which may not all be the same.
[07:08] <minghua> I usually don't touch packages I don't understand anyway
[07:08] <minghua> (not that I can touch hal/udev/etc., of course)
[07:08] <nixternal> bug 108214
[07:08] <ubotu> Launchpad bug 108214 in pmount "cannot execute programs/scripts from USB drives (including reiserfs and ext)" [Low,Confirmed]  https://launchpad.net/bugs/108214
[07:08] <nixternal> while you are at it, change it from pmount :)
[07:09] <StevenK> That bug smacks of the device being mounted noexec
[07:09] <minghua> nixternal: why should I reassign from pmount?
[07:10] <_Enchained> hi all
[07:10] <persia> minghua: Try hal.  I suspect linux.fstab.options
[07:10] <nixternal> because if pmount is kubuntu only, then it wouldn't be the reason for the issues..because people are reporting it in ubuntu as well
[07:10] <_Enchained> Someone to review a few packages ?
[07:10] <_Enchained> I have 4 or 5 waiting on Revu
[07:10] <minghua> nixternal: okay, haven't read the "happens in ubuntu as well" part yet
[07:11] <persia> _Enchained: Please post the URLs (I recommend one every few hours until they've all been posted), and announce the status ("New Package", "Seeking Advocate for new upload", "Seeking second advocate").  Please only post each new upload once per day.
[07:12] <nixternal> minghua: maybe I thought I saw the Ubuntu stuff because the pmount was ubuntu-meta, but I changed the package
[07:12] <_Enchained> http://revu.tauware.de/details.py?upid=5348
[07:12] <_Enchained> http://revu.tauware.de/details.py?upid=5349
[07:12] <_Enchained> http://revu.tauware.de/details.py?upid=5350
[07:13] <_Enchained> those 3 are similar
[07:13] <minghua> nixternal: finished reading, no where in the bug report says it happens to gnome users as well
[07:13] <_Enchained> and should be fine
[07:13] <nixternal> minghua: re ^^
[07:13] <Hobbsee> _Enchained: do you need teh b5i2iso.install file?
[07:13] <_Enchained> and another I've just send : http://revu.tauware.de/details.py?upid=5430
[07:14] <_Enchained> Hobbsee yes It install the binary ^^
[07:14] <Hobbsee> shouldnt the rules automatically do that?
[07:14] <minghua> nixternal: let's keep it assigned to pmount then :-)
[07:14] <_Enchained> or maybe I should rename it just "install" ?
[07:14] <Hobbsee> i thought you only needed a .install file when there were multiple binaries
[07:14] <nixternal> minghua: ditto :)
[07:14] <Hobbsee> i wouldnt have thought you needed it *at all*
[07:14] <Hobbsee> but check it
[07:15] <_Enchained> Hobbsee no. make only create a binary and then we must move it
[07:15] <persia> Hobbsee: Depends on how broken upstream is.  For a good makefile, you're right.  For annoying upstream with a lousy makefile, not so much.
[07:15] <Hobbsee> persia: ah, fair enough
[07:15] <minghua> Hobbsee: depend on where your "make install" installs to
[07:16] <minghua> I user debian/install file even for one-binary package with same upstream source, just to reuse the code
[07:16] <_Enchained> The three *2iso are little utils that just create a binary in the current folder
[07:17] <Hobbsee> persia: i'm about to test build - did you want to look that one first over as well, then i can upload it?
[07:17] <persia> Hobbsee: Which?
[07:17] <Hobbsee> persia: http://revu.tauware.de/details.py?upid=5348
[07:18] <persia> Hobbsee: Sure.
[07:18] <Hobbsee> thanks
[07:18] <_Enchained> :) thx
[07:18] <Hobbsee> (no point downloading it twice)
[07:18] <persia> Hobbsee: I'm trusting you to build and run all the lintian & linda checks on the binary.  I'll just chase copyright, rules, etc.
[07:18] <Hobbsee> persia: yeah
[07:19] <Hobbsee> no problem
[07:21] <persia> _Enchained: Does your package brak any other packages?
[07:21] <persia> s/brak/break/
[07:21] <_Enchained> how could it do this ?
[07:21] <Hobbsee> maintainer mangling hanst been done
[07:22] <minghua> it's so fun to see RMS startled by Debian package naming systems :-)
[07:23] <persia> _Enchained: Some packages conflict with others in odd ways (e.g. serial2net and teg used the same default high port for years), or have conflicting dependencies (e.g. cyrus21-imap & cyrus-imap).
[07:23] <_Enchained> I think it doesn't
[07:23] <_Enchained> but how can I be sure of that ?
[07:24] <Hobbsee> it'll be picked up when the archive scripts are run
[07:24] <persia> Hobbsee: I'm not advocating.  Commenting...
[07:24] <Hobbsee> persia: OK
[07:24] <Hobbsee> er, bugger it.  i hit enter on dput
[07:28] <persia> Hobbsee: Aside from maintainer, the only other issue that blocked me was section.  Not a big deal.
[07:28] <Hobbsee> oh yes, dammit.  i noticed that, then forgot
[07:28] <Hobbsee> _Enchained should be the one feeling pressured :P
[07:28] <_Enchained> Hobbsee : what is Maintainer mangling ?
[07:29] <_Enchained> I don't feel under pressure ;)
[07:29] <Hobbsee> _Enchained: https://wiki.ubuntu.com/DebianMaintainerField
[07:29] <Hobbsee> persia: i believe you meant the priority field?
[07:29] <persia> _Enchained: You should.  A not ideal package with your name attached was just uploaded.  Now it must be fixed :)
[07:29] <Hobbsee> persia: utils is a valid section field.
[07:30] <Hobbsee> and is correct, iirc.
[07:30] <persia> Hobbsee: Right.  I can't seem to type what I'm thinking :)
[07:31] <Hobbsee> _Enchained: persia: http://revu.tauware.de/details.py?upid=5349 seems to have the same problems.
[07:31] <Hobbsee> i wonder if we actually have the maintainer stuff documented anywhere
[07:31] <_Enchained> the 3 *2iso are similar ;)
[07:32] <persia> Hobbsee: Do you have a script to undo it?  There's a couple bugs in DaD I want to fix, but haven't gotten around to writing the undo script yet.
[07:32] <_Enchained> So, I must find someone with a unbut.com email ?
[07:32] <Hobbsee> persia: to undo it?  no
[07:32] <persia> _Enchained: See the URL Hobbsee posted.  There are default maintainers, if the XSBC-Original-Maintainer field is populated.
[07:33] <persia> Hobbsee: Alas.  Thanks anyway.
[07:33] <Hobbsee> _Enchained: 
[07:33] <Hobbsee> #
[07:33] <Hobbsee> If the package is in universe or multiverse, the Maintainer field will be set to Ubuntu MOTU Developers <ubuntu-motu@lists.ubuntu.com>
[07:33] <Hobbsee> #
[07:33] <Hobbsee> If the Maintainer field is modified, the old value will be saved in a field named XSBC-Original-Maintainer
[07:33] <_Enchained> persia debian/b5i2iso.manpages <- just a file which contains the name of the manpage file ?
[07:33] <StevenK> _Enchained: Right
[07:33] <_Enchained> ok
[07:34] <_Enchained> Hobbsee so I put my email adress in XSBC-Original-Maintainer and MOTU Developers <ubuntu-motu@lists.ubuntu.com> in Maintener field ...?
[07:34] <man-di> moin
[07:34] <Hobbsee> yep
[07:34] <_Enchained> ok thx
[07:34] <Hobbsee> Ubuntu MOTU... that is
[07:36] <Hobbsee> yep, same things apply for all three of them.
[07:36] <Hobbsee> _Enchained: priority should be "optional"
[07:37] <_Enchained> ok
[07:37] <Hobbsee> according to the debian new maintainers guide
[07:37] <persia> _Enchained: I've just checked 5430 as well: That one needs the same work.
[07:38] <_Enchained> which persia ?
[07:38] <_Enchained> maintener and ?
[07:38] <persia> nautilus-wallpaper
[07:38] <_Enchained> (what work)
[07:38] <_Enchained> priority optional ?
[07:38] <Hobbsee> nautilus-wallpaper has other errors too
[07:38] <Hobbsee> yeah
[07:38] <_Enchained> and Maintener field
[07:39] <persia> _Enchained: At a minimum maintainer and priority optional.  You probably also want to build the binary and run lintian and linda against the arch.changes file for more hints.
[07:39] <_Enchained> for nautilus-wallpaper It wanted to install some doc files in a wrong path
[07:39] <_Enchained> so I rm them in rules :s
[07:40] <_Enchained> I don't know what is the better way to fix this
[07:40] <persia> _Enchained: That's the right way.
[07:45] <persia> nixternal: The mounting issue is new behaviour for feisty, right?
[07:45] <nixternal> they say it is, however I can't reproduce it
[07:45] <nixternal> my build directories are all on a usb 500gb drive
[07:45] <nixternal> all of my repos and what not. and then my gpg key is on a usb stick as well...all ext3 partitions
[07:46] <persia> nixternal: I had a user last night who was looking at it, but it was on someone else's computer, and they only had a couple hours.
[07:52] <superm1> persia, keescook wasn't sure on the process to upload mythbuntu-gdm-theme after he looked it over and gave it another +1 after you.  Would you be able to upload it?
[07:52] <persia> superm1: He was around earlier, and I thought he uploaded.  Did you check the NEW queue?
[07:52] <superm1> persia, let me double check
[07:53] <persia> superm1: If it's really not uploaded, I'll upload, but I don't like rejections :)
[07:53] <superm1> persia, ah yes he did.
[07:53] <superm1> my mistake :)
[07:53] <superm1> i havent been around the last few hrs
[07:54] <persia> superm1: https://lists.ubuntu.com/archives/ubuntu-motu/2007-June/001708.html
[07:54] <persia> No worries.
[07:55] <Hobbsee> sigh. dad's whining about the amount of stuff being downloaded.
[07:55] <persia> Hobbsee: You need to move to a country without foolish quotas.
[07:55] <Hobbsee> persia: i know.  i plan to.
[07:56] <Hobbsee> persia: just a) where?  b)  after uni  and c) where do i find the resources to do it?
[07:57] <persia> Hobbsee: Choose a) based on your first impressions from a 30-year old tour book.  Nothing else will keep you more than a year or two.  For c) apply for an overseas job, and request relocation sponsorship.
[07:57] <Hobbsee> persia: a 30 year old tour book, hey?
[07:58] <Hobbsee> yeah, the relocation sponsorship would be the smartw ay to go
[07:58] <persia> Hobbsee: The alternative is a one-way discount fare :)
[07:59] <Hobbsee> persia: true that
[08:00] <man-di> Hobbsee: germany is nice, except when you live here...
[08:00] <Hobbsee> man-di: heh, why so?
[08:00] <Hobbsee> man-di: so is anywhere, i suspect
[08:00] <man-di> Hobbsee: I live here for 33 years and I want to learn to know something else
[08:00] <Hobbsee> ahhh
[08:01] <Hobbsee> i suspect that applies to anywhere - which is a good incentive to move every ~10 years or whatever, i guess :P
[08:02] <TheMuso> Heya folks.
[08:02] <man-di> Hobbsee: I guess so
[08:02] <Hobbsee> hi TheMuso!
[08:02] <persia> hi TheMuso
[08:03] <_Enchained> Hobbsee persia Can you take a look at http://revu.tauware.de/details.py?upid=5431 ?
[08:03] <_Enchained> I've updated it
[08:03] <_Enchained> If it's ok I do the same changes to the others
[08:05] <Hobbsee> _Enchained: looks good to me.  persia?
[08:05] <persia> _Enchained: I get a build failure.  I think you want debian/b5i2iso.1 in debian//b5i2iso.manpages.
[08:06] <_Enchained> oops yes
[08:06] <Hobbsee> ah there we go, it failed while i was on the phone
[08:08] <_Enchained> the debian/foo.manpages works only with cdbs ?
[08:08] <persia> _Enchained: Also, as a wishlist item, an upstream changelog would be good (but no worries if it doesn't exist).
[08:09] <persia> _Enchained: Debhelper too, but you need to include h_installman -p<package> in debian/rules
[08:09] <persia> s/h_installman/dh_installman.
[08:09] <Hobbsee> see, this is why i hate reviewing.
[08:10] <Hobbsee> people always find other stuff that i never remember about
[08:10] <persia> Hobbsee: That's why it takes two :)
[08:10] <_Enchained> -p is to use the foo.manpages file ?
[08:11] <persia> _Enchained: -p is to specify the package to install in.  For single binary sources, it's optional.
[08:11] <_Enchained> ok
[08:22] <_Enchained> persia Hobbsee I can't dput the new version oO
[08:22] <_Enchained> Error '553 Could not create file.' during ftp transfer of b5i2iso_0.2-0ubuntu1.dsc
[08:28] <persia> _Enchained: It's not that we're ignoring you, just that we don't have a solution.  You might try uploading again, or poking a REVU admin (if there is one around).
[08:29] <_Enchained> I'll try later
[08:30] <_Enchained> 08:30am ...time to sleep lol
[08:32] <Hobbsee> persia: you're not a REVU admin?
[08:33] <Hobbsee> _Enchained: please try uploading again - i've removed the offending files
[08:33] <persia> Hobbsee: heh.  I've only been reviewing two weeks :)  These things take a while.
[08:34] <Hobbsee> persia: ask siretart about it.
[08:34] <Hobbsee> he doesnt bite
[08:37] <_Enchained> Hobbsee it's ok
[08:37] <_Enchained> uploaded
[08:38] <Hobbsee> persia: if you could review again, and give me links to any that you ack, i'll try to look when i get home again
[08:38] <persia> Hobbsee: Sure.
[08:38] <Hobbsee> thanks
[08:41] <Hobbsee> bye all
[08:43] <persia> _Enchained: http://revu.tauware.de/details.py?upid=5432 advocated.  Which were the other ones, or are you sleeping now?
[08:44] <_Enchained> ok I do the same modif
[08:44] <_Enchained> on the others
[08:45] <persia> _Enchained: No rush.  If you want to get to them this afternoon, that's fine too.
[08:45] <_Enchained> no it's ok
[08:45] <_Enchained> Strangly I'm not so tired
[08:45] <_Enchained> ^^
[08:54] <_Enchained> persia I've updated pdi2iso and cdi2iso
[08:56] <persia> _Enchained: OK.  I'll take a look in a minute.  Thanks.
[08:58] <Lutin> hey there
[09:00] <_Enchained> yep Lutin 
[09:03] <Lutin> hey _Enchained 
[09:12] <persia> _Enchained: http://revu.tauware.de/details.py?upid=5433 commented.  Should be easy to fix.
[09:15] <_Enchained> ok persia updated
[09:15] <persia> _Enchained: http://revu.tauware.de/details.py?upid=5434 has the same problem.
[09:16] <_Enchained> ok
[09:16] <persia> _Enchained: And even though I advocated before, I realise that b5i2iso does as well.  Please fix that too :)
[09:16] <_Enchained> ok
[09:24] <_Enchained> persia http://revu.tauware.de/details.py?upid=5436
[09:25] <_Enchained> http://revu.tauware.de/details.py?upid=5432
[09:25] <_Enchained> and the other you already commented it :)
[09:26] <persia> _Enchained: 5432 still doesn't install the upstream changelog.
[09:27] <_Enchained> oops
[09:28] <persia> Fujitsu: The secret is: once you get it working, never, ever restart X :)
[09:29] <DarkMageZ> that sounds like a windows excuse
[09:30] <Lutin> persia: btw, what bug in DaD were you interested in fixing ?
[09:31] <persia> Lutin: Two actually: the one about having conflicts with change build-deps, and the one about not noticing syncs.  I think both of these will go away if DaD unmangles the maintainer (saving the name of the Ubuntu team) prior to diff3, and then remangles afterwards (if appropriate).
[09:33] <Lutin> persia: the changelog will remain in the patch though
[09:33] <persia> Lutin: I've just not gotten around to adding a unmangle function to process/merge and testing yet.
[09:33] <_Enchained> persia It doesn't upload
[09:33] <_Enchained> same as before
[09:34] <_Enchained> :/
[09:34] <persia> Lutin: Depends.  I've had changelogs merged to Debian :) (although I admit this is rare)
[09:34] <_Enchained> Is there a revu admin ?
[09:35] <persia> Lutin: Also, when reviewing REPORT, seeing only a changelog entry makes it clear - less investigation is required to ensure that a sync can be performed.
[09:37] <Lutin> persia: don't catch your last point (or actually can't catch how it is related to REPORT)
[09:38] <_Enchained> persia I have the same problem. I go to sleep. If you see a revu admin, ask for him to remove the bad package and ping me. I'll upload again
[09:38] <_Enchained> (or tell to Lutin)
[09:39] <persia> _Enchained: Sleep well.  Upstream changelog isn't blocking anyway: only a good thing to have.
[09:39] <jamyskis> hi all...does anyone know if there is a decent howto anywhere on how to replace packages with newer versions of the program in *my own repository*? Is it just as simple as creating a new deb and updating the packages_i386.db or is it more complicated?
[09:41] <persia> jamyskis: Depends on your local repository format, but basically just upload an updated .deb to that repository.
[09:42] <jamyskis> persia: it's just that i read something about diff files and such like, but I can simply replace it and people who have my repo in their sources.list will get an update notification?
[09:42] <superm1> jamyskis, followed by dpkg-scanpackages or falcon update or the repository update
[09:42] <DarkMageZ> jamyskis, to create a repository http://ubuntuforums.org/showthread.php?t=60130
[09:42] <superm1> jamyskis, what do you use for managing your repository?
[09:42] <persia> Lutin: For syncs, I think you're right, but I still think unmangling and remangling would prevent things like vcf:debian/control.
[09:43] <jamyskis> superm1 i saw a howto somewhere on how to create a repo and created a bash script from it
[09:43] <persia> jamyskis: What you've read about diff files is probably procedural documentation for updating the Ubuntu repositories, to which you may not have direct upload permission.  For a local repository, you have permission, and don't need to follow that procedure.
[09:44] <superm1> jamyskis, well i'm not sure how in depth or complicated your current setup is with it.  I would highly recommend you look into falcon for managing a personal repository though.  It makes life very simple
[09:44] <jamyskis> persia: that's good to know :) thanks
[09:44] <DarkMageZ> jamyskis, guide to making/altering packages http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
[09:44] <jamyskis> superm1: I'll look into it :) thx
[09:45] <jamyskis> DarkMageZ: that's how i learnt how to create debs, but the creating a repo thread in the forum i've bookmarked for future ref...thx
[09:45] <superm1> jamyskis, it would be a good idea to look into getting these changes into the ubuntu versions of the packages too, so people on a larger scale can benefit.
[09:46] <Lutin> persia: wep, that'd be possible. (just thought that adding one more check in the diff3 loop could easily prevent from merging the changelog if it is the only different file)
[09:46] <DarkMageZ> superm1, do you know if falcon ever got fixed to work on feisty?
[09:46] <jamyskis> superm1: none of my packages are in the ubuntu repos at the moment...i sent my package naughts-and-crosses to MOTU but it was rejected, I need to take a closer look at the reason why
[09:47] <superm1> DarkMageZ, i've got it working on my copy of feisty, it was a matter of replacing a shebang at the top /usr/bin/falcon only I think
[09:47] <persia> Lutin: That'd be neat.  Then if the maintainer was on complete autopilot, it would be an undocumented fakesync, which wouldn't be entirely bad (although not ideal).
[09:47] <superm1> Seveas was pretty close to something with falcon 2 though recently, 
[09:48] <superm1> but you'd have to check with him on *how* close :)
[09:49] <superm1> jamyskis, I don't see it up on revu.  How did you submit it?
[09:49] <jamyskis> is there a website somewhere for falcon?
[09:50] <persia> jamyskis: http://launchpad.net/falcon
[09:50] <superm1> jamyskis,  https://launchpad.net/falcon 
[09:50] <superm1> its not in apt (unfortunately), but there are several third party repos that have a deb of it available
[09:50] <Lutin> persia: sure
[09:51] <persia> Lutin: I keep getting other things stuck in my queue above DaD, so probably won't get something put together for another week or so, at a minimum.  If you have time before then, and want to fix it, feel free :)
[09:52] <Lutin> persia: btw, I'm leaving on monday for 6 weeks, so if you feel uncomfortable with parts of the code, please send me an email (with a clear title :) ) rather than using irc
[09:52] <Lutin> or ping Adri2000 :)
[09:53] <jamyskis> i can't even remember my revu password and i'm having a job recovering it
[09:53] <persia> Lutin: Ah.  I guess it's mine then :)  The code seems pretty sensible, but thanks.  I'll publish a branch if I have something I think works, for review (probably by Adrien, as you'll be away).
[09:53] <persia> Have a good trip.
[09:53] <persia> jamyskis: You only need the password to comment.  If you're stuck, just upload.
[09:54] <jamyskis> its ok i've got the password now
[09:54] <jamyskis> hold on
[09:54] <jamyskis> i'll dig up falcon in a second
[09:55] <jamyskis> superm1: naughts-and-crosses revu submission -> http://revu.tauware.de/details.py?upid=4533
[09:56] <Lutin> persia: ok. thanks! :)
[09:56] <superm1> jamyskis, I'm not a motu (yet), but I can look over a few things if you'd like some input on it
[09:57] <jamyskis> superm1: that would be great, i'll sort out falcon first and then if you'd like we can work over the sub together
[09:57] <jamyskis> thanks
[09:57] <superm1> jamyskis, first off as bddebian was saying, is this intended to be a native ubuntu package
[09:58] <jamyskis> superm1 i think the mistake i made there was the name was wrong
[09:58] <jamyskis> naughts-and-crosses_0.83.tar.gz is supposed to be naughts-and-crosses_0.83.orig.tar.gz
[09:58] <superm1> okay from looking over debian/copyright, you are getting sources from an upstream site
[09:58] <superm1> you will need to provide that .orig.tar.gz
[09:58] <superm1> and change the version number
[09:59] <superm1> to append a -0ubuntu1 instead
[09:59] <jamyskis> what does that mean?
[09:59] <superm1> that means to grab the upstream tar.gz archive
[09:59] <superm1> and rename it appropriately
[09:59] <superm1> so it can be used for building the package
[10:00] <superm1> in this case, i believe it would be naughts-and-crosses_0.83.orig.tar.gz
[10:00] <jamyskis> ok :)
[10:00] <superm1> since that is the upstream version
[10:00] <superm1> so then debian/changelog's entry needs to show up as 0.83-0ubuntu1
[10:00] <jamyskis> looking at the manpage issue i need to learn how to write manpages
[10:01] <superm1> Next off, debian/copyright needs a short header of the license being used (in this case the GPL)
[10:01] <superm1> if you look at the source for pretty much any GPL app in ubuntu/debian, the debian/copyright file will always include a preface describing that license
[10:01] <superm1> followed by that reference to where it is stored on the system
[10:01] <jamyskis> ok noted
[10:02] <superm1> this was the page i was directed at for learning to write debian/copyright better:
[10:02] <superm1> http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html
[10:02] <superm1> it includes a very good example
[10:03] <LaserJock> anybody up?
[10:03] <persia> Hi LaserJock
[10:03] <superm1> next off, debian/rules, you might consider looking into using debhelper instead for a lot of those things
[10:03] <superm1> morning LaserJock 
[10:03] <superm1> rather than manual copying like you are
[10:04] <jamyskis> i actually found debhelper more difficult than doing it from scratch
[10:04] <LaserJock> anybody have an idea where I can go to figure out how to change the screen brightness on my laptop?
[10:04] <LaserJock> this is driving me nuts
[10:04] <persia> LaserJock: Are there dedicated hot keys that don't work?
[10:04] <superm1> LaserJock, what brand laptop?
[10:05] <LaserJock> superm1: Toshiba
[10:05] <superm1> LaserJock, there is an app in synaptic, the name slips my mind right now
[10:05] <LaserJock> persia: yep, and I can't find any place to do it otherwise
[10:05] <superm1> that allows those hotkeys to work
[10:05] <superm1> (for most toshibas)
[10:05] <persia> LaserJock: Ah.  I'm not sure for Toshiba, but I had to install a special utility for an old Sony I had.
[10:06] <LaserJock> superm1: I found a couple, but they can't find some kernel module
[10:06] <superm1> jamyskis, well you will have to make sure that if you are doing it by hand rather than debhelper, that you are actually catching all the docs and such
[10:06] <superm1> i can see you aren't installing AUTHORS
[10:06] <superm1> INSTALL README
[10:07] <LaserJock> is there a way to look at possible kernel modules to load?
[10:07] <LaserJock> I *think* I need to find some acpi video module
[10:07] <superm1> LaserJock, if they ship a modules-source, possibly build using module-assistant
[10:07] <LaserJock> superm1: they say it isn't necessary :/
[10:07] <superm1> hm
[10:08] <persia> LaserJock: The available kernel modules are under /lib/modules/...
[10:08] <LaserJock> I'm trying toshset
[10:08] <LaserJock> and it gives me: required kernel toshiba support not enabled.
[10:08] <superm1> jamyskis, really it would be a good idea to try to do debian/rules with debhelper or cdbs possibly though.  it is a lot easier for a maintainer to read,update, and revu
[10:08] <persia> LaserJock: Try `modprobe toshiba_acpi`, maybe?
[10:09] <jamyskis> superm1: ok, I'll give it a go...I'm a little concerned about the manpage issue, and I don't know what FSSTND-dir-in-usr usr/doc/ means
[10:09] <jamyskis> superm1: the rest i can figure out
[10:10] <persia> jamyskis: FSSTND-dir-in-usr is complaining that nothing should be in /usr/doc (use /usr/share/doc/<package>/ instead).
[10:10] <LaserJock> persia: heh, I get a Fatal error, no such device :(
[10:11] <LaserJock> I'm guessing that's my problem
[10:11] <persia> LaserJock: Cool!  You don't really have a Toshiba then :)
[10:12] <persia> LaserJock: Rather, you probably have a new one for which the kernel has yet to provide support.
[10:12] <LaserJock> this laptop is nearly 3 years old
[10:12] <jamyskis> superm1: ok, thanks for the help, I'm going to occupy myself with debhelper, I'll come back if I have any probs
[10:12] <superm1> LaserJock, after searching apt, your using fnfxd, i would guess
[10:12] <superm1> great jamyskis, good luck :)
[10:12] <LaserJock> superm1: fnfxd doesn't work
[10:12] <jamyskis> thanks :)
[10:12] <persia> LaserJock: Alternately, you mentioned a need for video ACPI before, did you try loading .../kernel/drivers/acpi/video.ko?
[10:12] <LaserJock> also get kernel related errors
[10:13] <LaserJock> persia: I do have a video module loaded
[10:13] <LaserJock> I'm assuming that's the one
[10:13] <LaserJock> but /proc/acpi/video/ is empty
[10:13] <superm1> LaserJock, it appears toshset installs /usr/share/doc/toshset/supported-models.txt.  Long shot, but are you on the list :)
[10:14] <persia> LaserJock: You might want to file a bug.  If you can collect enough information about your hardware, it can usually be fixed by adjusting the hints in a few files, but knowing which files is hard.
[10:16] <LaserJock> superm1: not on the list
[10:16] <LaserJock> ok, I'm going to reboot
[10:16] <LaserJock> as sometimes I know that does things
[10:16] <LaserJock> like turns on my sound card
[10:17] <persia> Grumble.  I was *using* LP.
[10:19] <jussi01> good evening all
[10:22] <LaserJock> well, sound's back on
[10:22] <persia> Hi jussi01
[10:22] <LaserJock> but:
[10:22] <LaserJock> FATAL: Error inserting toshiba_acpi (/lib/modules/2.6.20-16-generic/kernel/drivers/acpi/toshiba_acpi.ko): No such device
[10:22] <jussi01> hello persia
[10:22] <persia> LaserJock: Are you ready to dive into the kernel-source?
[10:23] <LaserJock> so the kernel doesn't even know my laptop is a toshiba :(
[10:23] <superm1> LaserJock, what does dmesg say after you do that modprobe?
[10:23] <LaserJock> persia: for Fn keys? I'm not sure
[10:24] <LaserJock> superm1: nothing
[10:25] <LaserJock> nothing relevant I should say
[10:26] <LaserJock> well, this is just retarded
[10:26] <LaserJock> I hate Toshiba, and I hate laptops
[10:28] <crimsun> which model Toshiba do you have, for starters?
[10:28] <LaserJock> A65-126
[10:28] <crimsun> bios revision?
[10:28] <LaserJock> no clue
[10:28] <crimsun> use `sudo dmidecode`
[10:29] <LaserJock> 1.90
[10:29] <crimsun> now download and execute http://www.linux-sound.info/alsa/scripts/alsa-info.sh , then tell me the url.
[10:30] <LaserJock> that is something else crimsun 
[10:31] <LaserJock> http://pastebin.ca/552401
[10:32] <crimsun> you likely need to blacklist snd-atiixp-modem
[10:33] <LaserJock> Processor:         unknown
[10:33] <LaserJock> ^^ that's a good sign ;-)
[10:33] <jamyskis> superm1: does the package absolutely have to have a manpage?
[10:33] <crimsun> I'm also not convinced you're 1) using the most current & Linux 2.6-known-good bios revision, 2) you aren't using a bad DSDT
[10:33] <superm1> jamyskis, it doesn't *have* to have one, but its a good idea to write one
[10:34] <jamyskis> superm1: i'm trying to get my head around the syntax - whoever designed this syntax should be shot
[10:34] <LaserJock> crimsun: how do I check 1 & 2
[10:34] <persia> jamyskis: If there is a user accessible binary, almost none of the reviewers will advocate without a manpage.
[10:34] <superm1> jamyskis, see the app manedit
[10:34] <crimsun> you can start with: echo blacklist snd-atiixp-modem|sudo tee -a /etc/modprobe.d/blacklist
[10:34] <superm1> or similar apps
[10:34] <superm1> makes the whole process a lot less painful
[10:35] <jamyskis> superm1: looks like it too :) thanks
[10:35] <LaserJock> crimsun: and what is that supposed to fix?
[10:35] <Seveas> superm1, pretty close means that I'm redoing bits of the configuration things and then beta 1 is done
[10:36] <crimsun> LaserJock: I don't know offhand if it will fix anything, because at best it can only help resolve sound issues if your DSDT isn't broken.
[10:36] <crimsun> See http://acpi.sourceforge.net/dsdt/view.php?manufacturer=Toshiba
[10:36] <superm1> Seveas, very exciting :)
[10:36] <crimsun> Unfortunately, your specific model isn't listed, but you can see from that list that Toshibas, well, suck.
[10:37] <Burgundavia> indeed
[10:37] <Burgundavia> my laptop doesn't even report battery discharge rate
[10:37] <crimsun> it's also their use of Microsoft's ASL compiler
[10:38] <Burgundavia> its acpi even baffles mjg59
[10:38] <LaserJock> rebooting, brb
[10:42] <LaserJock> crimsun: http://pastebin.ca/552421
[10:43] <LaserJock> I still don't know why it won't let me modprobe toshiba_acpi
[10:43] <LaserJock> I guess my model is just not supported?
[10:44] <persia> LaserJock: Either your model isn't supported, or your DSDT is confusing the kernel.  Probably the former.
[10:45] <crimsun> LaserJock: I'm not sure what that output is supposed to tell me.  Is audio audible or inaudible?
[10:45] <LaserJock> well, right no it is
[10:45] <persia> LaserJock: You could probably fix it, if you were willing to determine what bits to poke in drivers/acpi/toshiba_acpi.c
[10:45] <LaserJock> *now
[10:46] <crimsun> ok, well, I don't care if your science packages asplode on your Toshiba.  I only care for sound.  ;-)
[10:46] <Burgundavia> crimsun: is my broken acpi related to why mics plugged into the front mic jack don't work?
[10:47] <LaserJock> crimsun: the audio problem comes and goes
[10:47] <crimsun> LaserJock: again, impossible to diagnose unless you establish for certain that your ACPI and DSDT are known-good.  And knowing it's a Toshiba, well, fat chance.
[10:47] <LaserJock> crimsun: it seems to actually be better in Ubuntu than in Windows, but sometimes it still boots/resumes without sound
[10:48] <LaserJock> I"m not as worried about sound as finding some way to change the LCD brightness
[10:48] <crimsun> Burgundavia: possible but improbable, but I don't know if your DSDT used the Microsoft ASL compiler.
[10:48] <crimsun> s/used/was created by/
[10:50] <crimsun> LaserJock: suspend<->resume issues introduce a completely new vector; it'd be nice to know if sound is audible consistently now.
[10:50] <LaserJock> crimsun: I'll run it for a while and report back if it is a problem again
[10:51] <crimsun> I hate Toshiba P100s.  All of them known to exist use broken DSDTs, and it really creates dozens of new bugs for me every week.
[10:52] <LaserJock> oh, awesome
[10:52] <LaserJock> I see a note that my model of Toshiba doesn't have a toshiba BIOS
[10:52] <crimsun> :)
[10:52] <persia> LaserJock: See, you don't really have a Toshiba :)
[10:53] <LaserJock> well, they certainly could have fooled me
[10:53] <crimsun> normally I smile when I read that someone has a Toshiba, because that pretty much means I can reject the sound bug outright.
[10:53] <superm1> and clearly they did :)
[10:53] <LaserJock> I even paid to get the stupid thing repaired
[10:53] <persia> That's called "Marketing".
[10:54] <crimsun> well, if anyone has horrid marketing, Creative Labs certainly is in the top three ignoble list.
[10:54] <LaserJock> and my wife wonders why I want to get a new laptop, shesh
[10:54] <crimsun> don't you already have an Apple running OS X?
[11:02] <LaserJock> crimsun: that's my work computer
[11:02] <LaserJock> I've just got crappy machines at home
[11:03] <jamyskis> debhelper is a bloody nightmare
[11:07] <jamyskis> superm1: when it says that the extended description line is too long, does it mean the summary in the control file?
[11:07] <superm1> jamyskis, it should be less than 80 columns
[11:07] <superm1> if its more, then wrap to the next line instead
[11:08] <jamyskis> superm1: can you have blank lines in the extended description`
[11:08] <jamyskis> ?
[11:09] <superm1> You can make a blank line show up by " ."
[11:09] <superm1> let me pastebin for a better explanation. 
[11:09] <jamyskis> ok
[11:10] <superm1> jamyskis, like this http://pastebin.ca/552458
[11:10] <superm1> on line 8 you just put the period
[11:10] <superm1> and then carry on as normal for other lines
[11:10] <jamyskis> got it
[11:12] <jamyskis> superm1, i built the package complete with manpage (named manpage.1) but typing man naughts_and_crosses doesn't work - im not sure if it installed or not
[11:12] <superm1> jamyskis, you have to include a debian/manpages
[11:12] <superm1> that lists what manpages get installed 
[11:12] <superm1> for debhelper to pick up
[11:12] <superm1> you can see a list of installed files in the resultant package using "dpkg -L"
[11:13] <superm1> after its installed
[11:13] <man-di> or dpkg -c ...deb (for uninstalled packages)
[11:13] <superm1> man-di, oooh didn't know you could do that :)
[11:14] <man-di> superm1: hehe, easier to check stuff before installing and something wents wrong
[11:15] <superm1> jamyskis, also make sure that you included a dh_installman 
[11:15] <superm1> in debian/rules
[11:16] <jamyskis> superm1: i have the problem that my makefile was automatically generated and it sends the docs to /usr/doc and i'm trying to adjust my makefiles
[11:16] <jamyskis> superm1: but im not sure how
[11:17] <superm1> jamyskis, well don't make the changes to the Makefile unless you intend to release those changes in the upstream version too.  all your changes should be done in the debian/ directory
[11:18] <superm1> if you must edit the Makefile, do so using a dpatch
[11:18] <jamyskis> how do you do that?
[11:18] <man-di> What nick has Arthur Loiret again?
[11:18] <LaserJock> dang, this laptop sounds like an airplane taking off :/
[11:18] <jamyskis> i have two variables in the configure script i need to change...how would i do that in the debian directory?
[11:18] <persia> man-di: bashelier
[11:19] <\sh> jamyskis, via autofoo magic
[11:19] <man-di> jamyskis: perhaps configuring with --mandir=... --infodir=.... helps you
[11:19] <man-di> persia: thanks
[11:19] <man-di> bashelier: ping
[11:19] <bashelier> man-di: pong
[11:20] <man-di> bashelier: I just replied to your mail
[11:20] <DarkSun88> Hi all
[11:20] <man-di> bashelier: to make it more clear: replace ${Source-Version} by ${source:Version} or ${binary:Version}
[11:21] <man-di> bashelier: to make the package binNMU safe
[11:21] <bashelier> man-di: thanks, I'll also try to update my lintian version :)
[11:21] <man-di> bashelier: http://wiki.debian.org/binNMU explains this a bit
[11:22] <bashelier> man-di: I'm reading, thanks a lot
[11:25] <siretart> we don't do binNMUs in ubuntu, but sourceful uploads with no changes outside debian/changelog, but in debian, binNMUs are quite important
[11:25] <man-di> siretart: this is about sponsoring a package for Debian
[11:26] <man-di> siretart: and the later sync
[11:26] <man-di> so it should be okay for Debian first
[11:26] <siretart> oh. I see
[11:26] <siretart> that's correct
[11:27] <siretart> it's still imporant to know that in debian, arch: all packages never build on buildds, and in ubuntu, they always are, and always on i386
[11:27] <siretart> and this is where much confusion comes from
[11:27] <man-di> siretart: thats known at least to me
[11:28] <man-di> but thanks for reminding
[11:28] <man-di> I know Debian und Ubuntu are handling some stuff quite differently
[11:28] <man-di> and both hat their reasons for doing so
[11:29] <man-di> siretart: another question: do you know then the bandwith problem on tiber will be solved? the java package comparison is not updated anymore
[11:30] <siretart> man-di: no not yet, I want to look at debconf more into it
[11:30] <man-di> ah, okay
[11:30] <siretart> I thought a reboot might fix it, but it didn't :/
[11:30] <man-di> what is the problem at all? network driver collapsing?
[11:31] <siretart> not sure. I might need to get a support ticket from serverpronto
[11:33] <Fujitsu> man-di: I've got a few of those running on the ServerPronto box that I administer. I can easily set it up there if you wish.
[11:36] <man-di> Fujitsu: that would be great, all I need is what http://tiber.tauware.de/~lucas/versions/java.html shows
[11:36] <jamyskis> superm1: should the directory in the source directory for manpages be called man manpage or manpages?
[11:37] <man-di> Fujitsu: just an updated version
[11:37] <superm1> jamyskis,  the file should be debian/manpages
[11:37] <superm1> and it just lists all shipped manpages
[11:37] <jamyskis> superm1: i have the file debian/manpages which has manpage.1 in it
[11:37] <superm1> such as debian/foo.1
[11:37] <jamyskis> superm1: but i don't know where manpage.1 should go
[11:37] <jamyskis> dh_installman complained it couldn't find it
[11:38] <superm1> right, you need to refer to it as debian/foo.1 rather than foo.1
[11:40] <bashelier> man-di: uploaded, shall I send you an other mail ?
[11:40] <jamyskis> superm1: got you...just an administrative question, I've put the name of the distribution as gutsy because i thought the deb would be included in 7.10's repos
[11:40] <jamyskis> superm1: should i ignore the warning that the distribution name is invalid?
[11:41] <superm1> jamyskis, yes
[11:41] <superm1> jamyskis, its just because of the version of linda/lintian on the revu machine doesn't recognize it
[11:41] <man-di> bashelier: yes, please
[11:41] <superm1> so not a big deal
[11:42] <jamyskis> ok...hopefully this will be the last pbuilder i run now...
[11:43] <bashelier> man-di: done
[11:43] <man-di> bashelier: thx
[11:43] <jamyskis> superm1: thanks for your patience by the way, I've just noticed that this has been going for two hours now
[11:43] <superm1> jamyskis, not a problem, glad to see these things being fixed so we can get this into the archive :)
[11:43] <superm1> jamyskis, i am going to get to bed though now, its a bit early in the morning where i am
[11:44] <jamyskis> superm1: as soon as I've got this fixed i'll get to work on my other game :)
[11:44] <jamyskis> superm1: ok then good night and thanks again :)
[11:44] <superm1> night all
[11:44] <persia> jamyskis: Once you've got a package you think works, please upload again, and annouce the URL here.  You'll likely get another review, and perhaps advocation.
[11:45] <jamyskis> persia: will do
[11:49] <jamyskis> ok that didn`t work either :( despite adding --docdir=$${prefix}/share/docs to the ./configure in debian/rules it's still installing the docs in /usr/docs
[11:50] <jamyskis> ok its not docs it doc
[11:50] <jekil> hello
[11:51] <jamyskis> hi jekil
[11:52] <persia> jamyskis: Is /usr/doc defined in ./configure?
[11:52] <jamyskis> persia: yes
[11:52] <persia> With which variable name?
[11:53] <jamyskis> persia: docdir (not by my doing, I must add, as I developed the game using the Anjuta IDE and Anjuta created the makefile for me) 
[11:54] <persia> jamyskis: No worries about how it was generated: I just wanted to make sure that you were passing the right argument.  I've seen some odd ./configure files :)
[11:55] <jamyskis> persia: :)
[11:56] <jamyskis> its still installing to /usr/doc
[11:56] <persia> jamyskis: As I see it, if ./configure isn't accepting the argument, you have four options, as a matrix.  Either as upstream or in a dpatch, either patch configure to parse --docdir= or define docdir as /usr/share/doc/ directly.
[11:56] <man-di> jamyskis: does configuring with --docdir=/usr/share/doc help?
[11:57] <persia> jamyskis: There are also less clean solutions, like adding a mv command to binary/install, but you really don't want to do that.
[11:57] <jamyskis> persia: I'll try a manual source install
[12:01] <jamyskis> persia: manual source install didn't work either
[12:02] <jamyskis> persia: would it help if i set docdir in the configure manually in both the source directory and the orig.tar.gz?
[12:02] <jamyskis> i have no idea how to use dpatches
[12:04] <jamyskis> persia: ok this gets weirder - ill show you something in the pastebin hold on
[12:05] <jamyskis> persia: http://pastebin.ca/552514 <- excerpt from the original configure file...what do you notice?
[12:05] <persia> jamyskis: As upstream, you'll want to bump the version number for the configure change (and perhaps want to adjust config.in instead).  As the packager, you'll want to `man dpatch.make` and look at https://wiki.ubuntu.com/MOTU/School/PatchingSources
[12:06] <Fujitsu> Wow, tiber's 'net connection really is slow.
[12:06] <persia> jamyskis: Ah.  Try passing --datarootdir=/usr/share :)
[12:06] <persia> Wait, that's already there.  Now I'm confused.
[12:06] <jamyskis> persia: it already is :)
[12:06] <jamyskis> persia: exactly
[12:07] <jamyskis> persia: that's why i don't get it...when i do it through debhelper it installs the docs to /usr/doc, if i do a manual source install it installs them to /usr/local/doc
[12:07] <jamyskis> i don't get it
[12:07] <persia> jamyskis: Try a local build, and track down what actually gets put in the Makefile.  Perhaps you can backtrack what is happening.
[12:09] <jamyskis> persia: http://pastebin.ca/552518
[12:10] <jamyskis> persia: yet when i "make install" it installs the docs to /usr/local/doc/naughts_and_crosses
[12:10] <persia> jamyskis: That's built with `./configure; make` or with `debuild`?
[12:10] <jamyskis> persia: ./configure/make
[12:11] <persia> jamyskis: You'll probably want to look at the install: rule of your Makefile.  I suspect something odd.
[12:11] <jamyskis> persia: prefix is set as /usr/local so it should be installing the docs in /usr/local/share/doc/naughts_and_crosses by default
[12:14] <jamyskis> PACKAGE_DOC_DIR=/usr/local/doc/naughts_and_crosses
[12:15] <persia> jamyskis: That sounds like an upstream bug to me :)  Nice work in finding it.
[12:17] <jamyskis> persia: thanks although its my program
[12:17] <jamyskis> :)
[12:18] <persia> jamyskis: When you are both upstream and the packager, it's a little easier, because you don't have to patch - you can just release a new version :)
[12:18] <jamyskis> persia: true, I'm just left a little confused how I can solve this because this is a problem with automake
[12:19] <geser> jamyskis: look in Makefile.am: naughts_and_crossesdocdir = ${prefix}/doc/naughts_and_crosses
[12:22] <jamyskis> geser: change that to ${prefix}/share/doc/naughts_and_crosses?
[12:22] <jamyskis> upstream and package?
[12:23] <geser> that would install it in the correct place but it still would ignore the --docdir value
[12:24] <jamyskis> that'll do for the time being
[12:24] <jamyskis> i just want to get this deb package sorted
[12:25] <geser> don't forget to regenerate Makefile.in (or patch it also)
[12:26] <geser> when I look at Makefile.in, it looks like docdir is defined but not used
[12:27] <Kmos> geser: http://revu.tauware.de/details.py?upid=5429 -> please commment this one
[12:27] <Kmos> *comment
[12:30] <geser> Kmos: for merges 1 ACK is enough, but I can still look at it
[12:30] <persia> Kmos: For new upstream merges, you only need one advocate (prior to UVF).  Once you get an advocation, if it's not uploaded, you should bug your advocate :)
[12:30] <jamyskis> i don't believe this - it's STILL installing to /usr/doc
[12:31] <jamyskis> ok i and my wireless mouse need a rest
[12:31] <jamyskis> ill be back later on
[12:32] <geser> jamyskis: did you update Makefile.in and re-run configure to update also Makefile?
[12:33] <geser> Kmos: you should ask keescook (or some other core-dev) for uploading it as gqview is in main
[12:34] <crimsun> I'll look.
[12:34] <Kmos> crimsun: you can upload it ?
[12:34] <crimsun> I have to look first.
[12:34] <Kmos> ok :)
[12:35] <Kmos> crimsun: thx
[12:35] <jamyskis> geser: i did and its still doing it
[12:35] <jamyskis> geser: i'll come back to it later
[12:35] <geser> hmm
[12:35] <jamyskis> geser: thx again
[12:35] <Kmos> ubuntu-main-sponsors is a mailing list ? i can't found it
[12:35] <crimsun> it's an LP team
[12:36] <crimsun> https://launchpad.net/~ubuntu-main-sponsors
[12:36] <Kmos> thx
[12:48] <crimsun> guess uploads are being queued again.
[12:48] <crimsun> are these outages being announced somewhere?
[12:53] <Fujitsu> crimsun: No, but I suspect they now think we're used to them going into big black holes regularly.
[01:00] <man-di> I have added my gpg key to launchpad and added myself to "Contributors of packages for ubuntu universe". What else do I need to do to be able to upload to REVU?
[01:01] <persia> man-di: Sleep on it (or bug an admin) to get the keys synced.
[01:03] <man-di> cool, thats all?
[01:04] <persia> man-di: Yep.  It's a low barrier to entry :)
[01:04] <Kmos> crimsun: any news ?
[01:06] <korobase_> Hi,all. I am new here!
[01:06] <persia> Hi korobase_
[01:07] <crimsun> ~$ sudo -u revu1 revu-key update
[01:07] <korobase_> :persia.Can I ask you some questions?
[01:07] <crimsun> running.  It will take a while due to tiber being a bit sluggish over the network.
[01:08] <Kmos> :)
[01:08] <persia> korobase_: You'll get a better response by just asking the channel in general, but I might answer.
[01:08] <crimsun> Kmos: see my statement 20 minutes ago.
[01:08] <korobase_> ok,good.
[01:08] <Kmos> [11:48]  <crimsun> guess uploads are being queued again.
[01:08] <Kmos> but you can't approved it and it goes to queue ?
[01:09] <crimsun> Kmos: I've already uploaded it.  I have nothing to do with it beyond that.
[01:09] <Kmos> crimsun: ah!.. thc
[01:09] <Kmos> crimsun: ah!.. thx
[01:09] <Kmos> :)
[01:10] <korobase_> I want to find a mentor. Any one can help me?
[01:11] <Kmos> bug 3222
[01:11] <ubotu> Launchpad bug 3222 in vim "gvim is hidden in menu" [Medium,Confirmed]  https://launchpad.net/bugs/3222
[01:11] <Kmos> i think it's already fixed..
[01:12] <Kmos> someone else can confirm it
[01:12] <persia> korobase_: A mentor is not a requirement to help, but you might be interested in https://wiki.ubuntu.com/MOTU/Mentoring/Contributor
[01:35] <jekil> i cant upload to revu because i get this error http://rafb.net/p/Q5kI5H94.html
[01:36] <persia> jekil: Is this for a package you recently uploaded?
[01:37] <jekil> persia: because in the last upload my gprs connection going down, so it's a partial upload, but i can't overwrite
[01:37] <persia> jekil: OK.  I just wanted to make sure.  When that happens, ask here for someone to delete the old upload from REVU (you need to specify the package name).
[01:38] <jekil> persia: thanks
[01:38] <jekil> so, anyone can delete tablelist old upload from revu?
[01:38] <persia> jekil: Not anyone, but many people (more than just REVU admins).
[01:39] <persia> jekil: Sorry ignore that :)
[01:43] <Hobbsee> hey all
[01:44] <persia> hi Hobbsee
[01:44] <Hobbsee> :)
[01:47] <persia> The really fun part of looking at bugs nobody wanted to sponsor for the last 8 months is the number of removal requests I get to file :)
[01:47] <Hobbsee> hehe
[01:47] <Hobbsee> eyah - a lot of them i either dont understand, or cant tell if they're still relevant
[01:48] <Hobbsee> 8 months, hey?
[01:48] <persia> Hobbsee: Sort by "recently changed".  Most of the ones at the top should be fine for upload.
[01:49] <persia> That's not so bad - there used to be ones from 2005 around :)
[01:49] <persia> ?
[01:49] <Hobbsee> true that - they changed the ones assigned to MOTU to being subscribed to u-u-s
[01:51] <DarkMageZ> if you don't understand a bug. then ask in the bug for a better explaination.
[01:52] <Hobbsee> well, the diff was more the problem
[01:52] <Hobbsee> "how does this solve the problem, and does it do it in a sane way?"
[01:52] <persia> Hobbsee: Ask the requestor.  It's their responsibility to provide enough information to be sponsored.
[01:54] <Hobbsee> true that
[01:54] <Hobbsee> that's what i usually do
[01:54] <Hobbsee> but large buglists have a habit of making me go "i'm not actually getting this down, there's no point in continuing"
[01:54] <persia> Hobbsee: It's not a large buglist :)
[01:55] <Hobbsee> no, but anything over 1 page == large
[01:55] <persia> Hobbsee: It's 1/3 of a page.
[01:55] <Hobbsee> true.  last i looked at it and worked on it was a while ago
[01:56] <StevenK> Uh oh
[01:56] <Hobbsee> hehe
[01:58] <StevenK> You forgot the trademark
[01:58] <persia> StevenK: Doesn't it take at least a day or two to register a trademark?  I think that's a new one.
[01:58] <crimsun> things are accelerated in Hobbsee time.
[01:58] <Hobbsee> 
[01:59] <Hobbsee> indeed.
[01:59] <Hobbsee> using HobbseeLogic
[01:59] <Hobbsee> in the HobbseeWorld
[01:59] <Hobbsee> and 25 is a cube in HobbseeWorld, dammit!!!!
[01:59] <imbrandon> moins all
[01:59] <Hobbsee> morning redneck.
[01:59] <imbrandon> heh heya
[01:59] <StevenK> Hah
[02:00] <imbrandon> you seem in rare form today 
[02:00] <imbrandon> hehe
[02:00] <Hobbsee> in rare form?  why so?
[02:00] <Hobbsee> imbrandon: i've been dealing in kde buglists and such.
[02:00] <imbrandon> ahh
[02:03] <apachelogger> is revu server not accepting uploads or something?
[02:05] <Fujitsu> apachelogger: What's it not doing?
[02:05] <persia> apachelogger: It's been working for several people in the last few hours.  What problem are you experiencing?
[02:06] <apachelogger> persia: 12 hours ago I tried to upload kopete-thinklight -> didn't wanna upload
[02:06] <persia> Nafallo: Does bug 114301 still need sponsorship, or will the bzr commit get released to gutsy in due time?
[02:06] <ubotu> Launchpad bug 114301 in gajim "Bug in fr.po translation that breaks invitation" [Low,Fix committed]  https://launchpad.net/bugs/114301
[02:06] <apachelogger> 3 hours later I uploaded a fixed version of kde3-theme-domino
[02:06] <apachelogger> didn't show up in webinterface yet
[02:06] <apachelogger> same for libprojectm
[02:07] <persia> apachelogger: Odd.  I saw several updates to packages about 5 hours ago, showing in the webinterface.  Ping an Admin.
[02:08] <Hobbsee> i saw kde3-theme-domino sitting there, iirc
[02:10] <apachelogger> Hobbsee: not the fixed version though
[02:10] <Hobbsee> ahh
[02:10] <Hobbsee> oh
[02:10] <apachelogger> :)
[02:11] <Hobbsee> that's weird
[02:11] <Hobbsee> did anyone here upload krawlsite?
[02:12] <apachelogger> me
[02:12] <Hobbsee> or swfdec?
[02:12] <apachelogger> not me
[02:12] <Hobbsee> or libprojectm_0.99-0ubuntu1_source.changes ?
[02:12] <apachelogger> me
[02:12] <persia> Kmos: Sorry for the long delay.  3222 is an odd bug.  It might be worth referencing https://blueprints.launchpad.net/ubuntu/+spec/menu-items-revisited or https://blueprints.launchpad.net/ubuntu/+spec/better-structured-game-menu as plans toward a solution.
[02:12] <Hobbsee> apachelogger: okay, wait ~5 mins, i think it is, and it should magically appear
[02:13] <apachelogger> Hobbsee: ok :)
[02:13] <Hobbsee> apachelogger: you didnt drop out of the REVU group on LP, i assume?
[02:15] <Hobbsee> that's weird.
[02:15] <Hobbsee> !revu
[02:15] <ubotu> REVU is a web-based tool to give people who have worked on Ubuntu packages a chance to "put their packages out there" for other people to look at and comment on in a structured manner. See https://wiki.ubuntu.com/MOTU/Packages/REVU
[02:15] <Hobbsee> very odd.
[02:16] <apachelogger> Hobbsee: hopefully not
[02:16] <Hobbsee> -g
[02:16] <apachelogger> https://launchpad.net/~apachelogger/+participation
[02:16] <Hobbsee> yeah
[02:16] <Hobbsee> oh well
[02:17] <Kmos> CVE-2005-1790
[02:17] <ubotu> Microsoft Internet Explorer 6 SP2 6.0.2900.2180 and 6.0.2800.1106, and earlier versions, allows remote attackers to cause a denial of service (crash) and execute arbitrary code via a Javascript BODY onload event that calls the window function, aka "Mismatched Document Object Model Objects Memory Corruption Vulnerability." (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-1790)
[02:17] <Kmos> persia: nice
[02:19] <Kmos> persia: i've added the blueprint to that bug
[02:22] <Kmos> asac: bug 26038
[02:22] <ubotu> Launchpad bug 26038 in mozilla "[CVE-2005-1790]  DoS against Mozilla-based browsers" [High,Confirmed]  https://launchpad.net/bugs/26038
[02:22] <Kmos> asac: isn't this fixed ?
[02:28] <DarkMageZ> Kmos, according to the bug report it hangs 1.5. but it does appear to hang firefox 2.0.0.4 here. so unless someone can confirm that it's not killing dapper anymore.
[02:28] <DarkMageZ> doesn't appear to hang 2.0.0.4 *
[02:28] <Kmos> dapper has v2.0.0.4 ?
[02:29] <DarkMageZ> na, feisty has 2.0.0.4. but dapper has 1.5 which the bug says is affected.
[02:29] <Kmos> it says fix released on debian
[02:29] <Kmos> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340282
[02:29] <ubotu> Debian bug 340282 in mozilla-browser "[CVE-2005-1790]  DoS against Mozilla-based browsers" [Grave,Closed]  
[02:29] <apachelogger> Hobbsee: already found the problem?
[02:30] <Hobbsee> apachelogger: did it publish?
[02:30] <Hobbsee> apachelogger: well, i found that the uploads got rejected
[02:30] <apachelogger> nope :(
[02:31] <apachelogger> hm, I knew revu would hate me for all the uploads ;-)
[02:34] <Hobbsee> i wonder
[02:34] <Hobbsee> if the keys in the keyring are being updated - are they throwing the old keys out, and adding new ones, or what?
[02:35] <Kmos> lionel: bug 5106
[02:35] <ubotu> Launchpad bug 5106 in jabberd2 "jabberd2 s2s crashes shortly after startup" [Medium,Unconfirmed]  https://launchpad.net/bugs/5106
[02:35] <Kmos> lionel: can you do a sync for debian ?
[02:35] <StevenK> It is probably grabbing all the keys from LP, throwing them together and replacing the current keyring at the end.
[02:35] <Kmos> *from
[02:36] <Kmos> lionel: can you do a sync from debian ? it has version s10 in experimental
[02:36] <lionel> Kmos: it is fixed in Debian ?
[02:36] <lionel> yes, we can sync from Debian
[02:36] <Kmos> lionel: yes, it is
[02:36] <lionel> Kmos: can you make a sync request, I'll ack it
[02:36] <Hobbsee> StevenK: that's what it's looking like to me
[02:37] <Kmos> "2.0s11 seems to be in Debian experimental now if someone wants to request a UVFe."
[02:37] <Kmos> s11
[02:37] <lionel> yeah, I have seen
[02:37] <Hobbsee> apachelogger: oh, i see the problem
[02:38] <DarkMageZ> Kmos, firefox 1.5.0.12 from mozilla just hung on me using that poc. ubuntu's firefox package in dapper is messy, so it's difficult to see the individual debian/ubuntu patches. i doubt it has been fixed in dapper.
[02:39] <Kmos> DarkMageZ: i marked it was fixed
[02:39] <Hobbsee> er, this thing is seriously weird.
[02:39] <Kmos> lionel: can i assign the sync to you ?
[02:40] <lionel> yeah, np
[02:40] <Kmos> ok, thx
[02:40] <Hobbsee> hobbsee@tiber:~$ gpg --list-public-keys 7D2BCE85  C3F159CA 945348A4
[02:40] <Hobbsee> gpg: error reading key: public key not found
[02:41] <Hobbsee> hobbsee@tiber:~$ gpg --list-keys 7D2BCE85  C3F159CA 945348A4
[02:41] <Hobbsee> gpg: error reading key: public key not found
[02:41] <apachelogger> sry, got disconnected
[02:41] <Hobbsee> someone who's better at gpg...what does that mean?
[02:41] <Hobbsee> is that the public key of what tiber considers it's owner, or of the individual people's keys?
[02:42] <StevenK> Well, the first question is where does the keyring updater script put the keyring?
[02:42] <Hobbsee> some temporary location and then moves it, it seems.
[02:42] <StevenK> Moves it where, though?
[02:42] <geser> Hobbsee: are you doing it as the right user?
[02:42] <StevenK> Since I suspect it isn't ~hobbsee/.gnupg
[02:42] <geser> else it checks your pubring on tiber
[02:43] <Hobbsee> geser: yes.  /srv/revu1-production/uploaders.gpg
[02:43] <Hobbsee> sorry, StevenK /srv/revu1-production/uploaders.gpg
[02:43] <StevenK> Hobbsee: gpg --keyring /srv/revu1-production/uploaders.gpg ....
[02:45] <Hobbsee> then it asks me to type a message
[02:45] <Hobbsee> it appears that the keyserver is timing out.
[02:45] <StevenK> gpg --keyring /srv/revu1-production/uploaders.gpg --list-keys 7D2BCE85
[02:46] <Hobbsee> StevenK: no root
[02:46] <jrib> in REVU, is the login usually the email?
[02:47] <persia> jrib: It is always the email on the key.
[02:47] <Hobbsee> the primary, i think
[02:48] <persia> Right.  Sorry.
[02:48] <Kmos> lionel: bug 119545
[02:48] <ubotu> Launchpad bug 119545 in jabberd2 "Please sync jabberd2 2.0s11 from Debian unstable" [Undecided,Confirmed]  https://launchpad.net/bugs/119545
[02:48] <jrib> Thanks, I wasn't sure if I had just forgotten the login name.  Can someone check if the recover lost password feature is working?  It doesn't give me any text to decrypt
[02:48] <persia> jrib: Have you uploaded anything?
[02:48] <jrib> persia: many months ago
[02:49] <lionel> Kmos: thanks, I'll have a look in a few min
[02:49] <persia> jrib: You only need to log in to comment on your uploads.  If your account got lost for some reason (I don't know why it would), a new upload should regenerate it.
[02:49] <jrib> persia: ah ok, thanks
[02:50] <apachelogger> :S
[02:51] <Hobbsee> apachelogger: i'ts timing out, so i think it hasnt actually imported your key.
[02:51] <Hobbsee> either that, or has stuffed up somewhere, and isnt actually copying over *anyone's* key to the correct place
[02:52] <Hobbsee> apachelogger: what's the full name on your key?
[02:53] <Hobbsee> oh wait, nvm
[02:53] <Hobbsee> it's not done alphabetically anyway, it seems
[02:53] <apachelogger> *backspace*
[02:59] <geser> Hobbsee: what happens when you try to add his key to the keyring?
[02:59] <Hobbsee> geser: havent tried.  not sure i have the permissions to.
[02:59] <Hobbsee> especially as the keyring is in a different place, it looks like
[03:00] <Hobbsee> which i likely dont have write access to
[03:00] <Hobbsee> apachelogger: of?
[03:01] <apachelogger> to never be able to upload
[03:01] <Hobbsee> nah, siretart will be able to fix it
[03:01] <apachelogger> cause I'm packaging pure amarok love right now :)
[03:01] <jekil> this lintian error is related to what? manpage-has-useless-whatis-entry
[03:02] <apachelogger> jekil: http://lintian.debian.org/reports/Tmanpage-has-useless-whatis-entry.html
[03:02] <Hobbsee> apachelogger: oh?  which version?
[03:03] <apachelogger> Hobbsee: not amarok, but visualization for amarok
[03:03] <apachelogger> Hobbsee: http://xmms-projectm.sourceforge.net/
[03:03] <Hobbsee> apachelogger: neat.  email it to me, if you like, when you're done
[03:03] <apachelogger> k, thx :)
[03:05] <persia> jekil: You need to provide a little more information about the program in the short description.  Try to use keywords that will help people using apropos to find man pages.
[03:05] <jekil> persia: thanks
[03:05] <jrib> If I am trying to package something that does not provide tarballs (I had to do an svn co), do I create a tar.gz of the checkout?  Also, what should I calll the directory of the checkout, should I rename it to  program-revision_number  or  program-date?  Anyone know where the documentation is for this?
[03:06] <StevenK> jrib: Create a tarball of an export.
[03:06] <StevenK> jrib: Since a checkout will have .svn directories everywhere.
[03:06] <jrib> good point
[03:06] <Hobbsee> hi chuck 
[03:07] <persia> jrib: See https://wiki.ubuntu.com/MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball (look for the cvs example).
[03:08] <jrib> persia: thanks
[03:08] <persia> jrib: Don't forget debian/README.Debian-source :)
[03:18] <mumbly> hi
[03:19] <lionel> hi mumbly
[03:25] <_Enchained> Hobbsee hi. can you remove again the b5i2iso package ? I can't upload it (same error than this morning)
[03:27] <Hobbsee> still waiting on the key resync
[03:27] <Hobbsee> did the fix this morning work though?
[03:27] <_Enchained> what fix ?
[03:28] <_Enchained> the others seem ok. I just forgot to include the upstream changelog in this one.
[03:29] <Hobbsee> _Enchained: shoudl be gone
[03:33] <_Enchained> again :/
[03:33] <_Enchained> should I use dcut ?
[03:33] <StevenK> Not for REVU
[03:33] <_Enchained> ok
[03:35] <Hobbsee> no
[03:58] <RainCT> persia: about bug 117180, the new upstream version is in Debian experimental
[03:58] <ubotu> Launchpad bug 117180 in desktop-file-utils "Encoding is deprecated" [Wishlist,In progress]  https://launchpad.net/bugs/117180
[03:59] <luisbg> what do I need to tweak in a package if it uses cmake instead of makefile?
[03:59] <RainCT> persia: the only difference I see (beside the maintainer) is that there's a debian/defaults.list file on Ubuntu but not on Debian (don't know if it was there on the old debian version or it was added by Ubuntu)
[04:00] <RainCT> persia: if it wasn't there too on the old Debian version, does it need a merge to add that file?
[04:01] <persia> RainCT: I'm looking.
[04:01] <apachelogger> hm
[04:01] <apachelogger> anyone knows what to do against rpath issues?
[04:01] <apachelogger> W: libvisual-projectm: binary-or-shlib-defines-rpath ./usr/lib/libvisual-0.4/actor/actor_projectM.so /usr/lib/X11
[04:02] <mr_pouit> you can try to add --disable-rpath to ./configure args
[04:02] <persia> apachelogger: http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html has a section on rpath
[04:03] <apachelogger> persia: thx
[04:04] <apachelogger> persia: considering I unerstand this properly ... rpath is only a real issue when it defines /usr/lib?
[04:06] <persia> apachelogger: Um.  I read it as rpath is a problem unless it is a private library, with no -dev package, and no other users.  Try to avoid rpath unless something bad happens without it.
[04:07] <apachelogger> persia: well, how to get rid of that thing?
[04:08] <persia> RainCT: I think it needs to be a merge.  Check with the person who always handles this package to see if there are other pending changes.
[04:09] <persia> apachelogger: if it's completely private, it might not be a problem, if you can guarantee it's completely private.  In that case, you can use a lintian override.  To get rid of it, try mr_pouit's suggestion first.  If that doesn't work, check the build system to see what needs to get passed where (or patched).
[04:10] <apachelogger> k, thx
[04:11] <persia> RainCT: Sorry - the some changelog entries are missing, which makes it confusing.  You need to coordinate with the last uploader.
[04:17] <Nafallo> persia: will not need sponsorship since I'm a MOTU myself. I think the change is currently to small to be an upload by itself. Please leave feedback on that though.
[04:19] <persia> Nafallo: Thanks for the update.  I'm going to drop it from the U-U-S queue, assuming that your last comment is sufficient feedback and that the fix will be applied in gutsy.
[04:19] <Nafallo> persia: it will, thanks.
[04:20] <persia> Yay!  Only 18 left :)
[04:20] <man-di> persia: ping eclipse
[04:21] <man-di> persia: tell me if you need more infos
[04:21] <persia> man-di: Already looking at it (LP auto-emails bug subscribers).
[04:22] <man-di> persia: can you look at https://bugs.launchpad.net/ubuntu/+source/libcommons-dbcp-java/+bug/119560 ?
[04:22] <ubotu> Launchpad bug 119560 in libcommons-dbcp-java "Please sync libcommons-dbcp-java 1.2.1-5 from Debian unstable" [Undecided,Unconfirmed]  
[04:22] <man-di> the version is in debian incoming currently
[04:25] <man-di> persia: sorry to create you so much troubles
[04:26] <Hobbsee> persia: not the request sync script?
[04:27] <man-di> Hobbsee: script?
[04:27] <Hobbsee> requestsync, yes.
[04:27] <persia> man-di: The goal is something like bug 114137 (which also isn't perfect).  You need a short summary of why a sync is better than a merge, and the new debian changelog (for eclipse only 3.2.2-1).  I think the current state of the eclipse bug is fine, but 119560 is hard to read.
[04:27] <ubotu> Launchpad bug 114137 in thuban "Please sync thuban 1.2.0-1 (universe) from Debian unstable (main)" [Wishlist,Fix released]  https://launchpad.net/bugs/114137
[04:27] <persia> Hobbsee: I don't like requestsync.  I think my bug is better.
[04:28] <Hobbsee> heh
[04:28] <Hobbsee> then you havent requested enough syncs yet :P
[04:28] <persia> man-di: No trouble.  If I tell you how to make a good sync, I have less to do :)
[04:29] <persia> Hobbsee: For me, it's easier to use LP than requestsync, as my local mail is broken, and I usually already have the Debian changelog in front of me from determining that I can do a sync.
[04:29] <geser> persia: what don't you like on requestsync?
[04:29] <persia> geser: 1)  It requires working local mail.  2)  The formatting on LP later is ugly.  3)  It doesn't provide enough guidelines about what should be included in Rationale.
[04:30] <persia> geser: Other than those, it's nearly perfect, especially with the recent patches.
[04:30] <Hobbsee> persia: ah, fair enough
[04:30] <Hobbsee> it requires smtp.
[04:31] <Hobbsee> persia: uh...you're not changing the smtp server are you?
[04:31] <luisbg> do you guys have your pbuilders built for gutsy or for feisty?
[04:31] <persia> luisbg: I have sbuild for both.
[04:31] <luisbg> persia, building it for gusty stalls to me :S
[04:31] <Hobbsee> i have a gutsy and feisty pbuilder
[04:31] <geser> persia: afaik 1) is wrong as it delivers the mail directly to fiordland.ubuntu.com
[04:31] <persia> Hobbsee: I haven't actually used requestsync since Dapper - it's just too ugly.
[04:32] <RainCT> persia: where can I see who was the last uploader?
[04:32] <Hobbsee> persia: well, there were great improvements since then.
[04:32] <Hobbsee> RainCT: aptitude changelog foo
[04:32] <persia> RainCT: aptitude changelog packagename
[04:32] <RainCT> ah yes :p
[04:32] <RainCT> thanks
[04:33] <persia> Hobbsee: I still don't like the formatting, and LP is easy for me, as I already have the package bugs page open and the changelog in front of me.  I won't tell anyone else not to use requestsync, but I'm not likely to be convinced for a while yet :)
[04:33] <Hobbsee> heh
[04:33] <Hobbsee> fair enough
[04:33] <jekil> any revu admin here?
[04:34] <persia> luisbg: Build it for feisty, and dist-upgrade to gutsy once it's built.
[04:34] <Hobbsee> jekil: yes, but i believe it's stuffed.  technicla term.
[04:34] <luisbg> persia, will do, thanks
[04:35] <persia> luisbg: Just be careful with the naming.  Some of the automated scripts assume the name and the release match, so you might need to adjust a couple things.
[04:36] <luisbg> persia, what differences does a package need in the rules file if built with cmake instead of make?
[04:37] <persia> luisbg: Trivially, an extra 'c'.  More specifically, with CDBS you need to overload the build, and with debhelper you need to adjust the rules to use the cmake conventions instead of the make conventions.
[04:38] <luisbg> hmmmm feisty stalls in the same place, just after Get:6 http://archive.ubuntu.com feisty/multiverse Packages [148kB] 
[04:38] <persia> luisbg: Also, you'll often get a better, faster response when asking questions in general, rather than to specific individuals.
[04:38] <luisbg> persia, may I pm you?
[04:38] <persia> luisbg: OK, but I don't use pbuilder, so I'm not necessarily the best person to ask about it :)
[04:38] <luisbg> it's not about pbuilder, it's about adjusting the rules
[04:41] <man-di> persia: so do you want me to give additional infos to one of the bugs?
[04:42] <persia> man-di: Sorry.  I've become distracted.  Please, for bug 119560, but rather different information than more (use "Edit Description").
[04:42] <ubotu> Launchpad bug 119560 in libcommons-dbcp-java "Please sync libcommons-dbcp-java 1.2.1-5 from Debian unstable" [Undecided,Unconfirmed]  https://launchpad.net/bugs/119560
[04:47] <Kmos> someone can explain me why flite 1.2 was named flite 1.2-release2.2
[04:47] <Kmos> ?
[04:47] <Kmos> https://bugs.launchpad.net/ubuntu/+source/flite/1.2-release-2.2
[04:48] <Kmos> http://www.speech.cs.cmu.edu/flite/packed/flite-1.2/
[04:48] <Kmos> doesn't have that on .tar.gz
[04:53] <luisbg> :S my pbuilder create is getting stalled at 99% everytime, doesn't matter if it's for gutsy or feisty or with multiverse or not
[04:53] <DarkMageZ> Kmos, that naming convention was imported from debian like that. feel free to burn them :P
[04:54] <Kmos> DarkMageZ: yeah.. =)
[04:54] <Kmos> i'm doing the package now
[04:55] <man-di> persia: comment to 119560 added
[04:57] <Kmos> persia: i can't change flite to flite (1.3-0ubuntu1) ?
[04:57] <persia> man-di: Thanks.  I'll take this.  Please consider using "Edit Description" next time, to update the full text of the bug, and make it clearer to read.
[04:58] <Kmos> !info flite
[04:58] <ubotu> flite: A small run-time speech synthesis engine. In component universe, is extra. Version 1.2-release-2.2 (feisty), package size 216 kB, installed size 444 kB
[04:58] <persia> Kmos: I don't really care about the tar.gz name, and think upgrades are good, but please try to keep the source package and binary package names in sync with Debian.
[04:58] <Kmos> persia: ok
[04:59] <man-di> persia: ah, now I got what you meant. sorry for being slow...
[04:59] <persia> Kmos: Sorry.  I misunderstood.  Changing the version to 0ubuntu1 will be a good thing :)
[04:59] <Kmos> ah.. ok =)
[04:59] <Kmos> +--  7 lines: flite (1.2-release-2.2) unstable; urgency=low -- Clment Stenac
[04:59] <Kmos> this is the latest changelog
[05:01] <Kmos> what differs from X-Original-Maintainer to XBSC-Original-Maintainer
[05:02] <Kmos> how to know what to use?
[05:03] <persia> Kmos: Use XSBC-Original-Maintainer.  The first draft of DebianMaintainerField was vague, and we spent a week or so experimenting before we decided on that.
[05:03] <Kmos> ah.. ok
[05:06] <persia> Kmos: To explain in more detail, X means that devscripts shouldn't complain, B means copy it to the binary, S means copy it to the .dsc, and C means copy it to the changes.  I think there's something in MOTU/FAQ about it.
[05:06] <Kmos> i'll see that later
[05:06] <Kmos> thx
[05:06] <Kmos> so by default use always XSBC for Ubuntu
[05:08] <Kmos> https://launchpad.net/+builds/
[05:08] <Kmos> is so slowly today
[05:08] <Kmos> :)
[05:15] <man-di> does a sync request needs to be ACKed by two MOTUs?
[05:15] <lionel> man-di: only one
[05:16] <man-di> lionel: thx
[05:16] <lionel> np :)
[05:16] <man-di> persia: thx for ACKing both packages
[05:16] <persia> man-di: No more cookies for you today.  For the rest, you have to subscribe U-U-S like everyone else :)
[05:17] <man-di> persia: Thank you very much
[05:32] <siretart> Hobbsee: huh?
[05:32] <Hobbsee> siretart: seems like REVU is broken - it's timing out to the keyserver when the keyring resyncs, and people are getting uploads into rejected/ when tehy used to be able to upload to revu
[05:33] <siretart> damn
[05:33] <siretart> I'll look into it in a sek
[05:35] <persia> OK.  Triage and cleanup of the U-U-S queue is complete.  Someone else please sponsor (or otherwise make go away) the remaining bugs :)
[05:36] <man-di> persia: I can file new ones and subscribe U-U-S easily
[05:36] <man-di> ;-)
[05:37] <persia> man-di: That would be welcome :)
[05:38] <bashelier> thanks for audiere man-di ;)
[05:39] <Kmos> siretart: revu has some auto-expire system to delete packages ?
[05:39] <Kmos> it's so slowly last days
[05:40] <Hobbsee> Kmos: it's not out of space
[05:40] <Hobbsee> hehe
[05:40] <man-di> persia: thx
[05:40] <man-di> bashelier: thx
[05:44] <jekil> revu is broken? clik here: http://revu.tauware.de/lostpw.py?email=alessandro@lonerunners.net
[05:46] <persia> jekil: Yes.  It's being worked on.
[05:46] <jekil> oh thanks
[05:46] <siretart> Kmos: the hardware has problems
[05:46] <Kmos> siretart: that's bad
[05:47] <Hobbsee> siretart: is PPA  and such expected to take it over?
[05:47] <Hobbsee> seeing as you were working on that
[05:47] <Kmos> siretart: which type?
[05:48] <siretart> Hobbsee: I'm still thinking about that. PPAs currently don't over any UI at all, and it is unlikely to get one which is able to replace REVU soon
[05:48] <siretart> Hobbsee: however, I've been started to think how REVU2 could fetch sources from ppa's and offer commenting functionality and run lintian/linda and such
[05:49] <siretart> Hobbsee: if you want to help coding, sure!
[05:49] <siretart> Kmos: bandwith is slow
[05:49] <Hobbsee> siretart: darn.  i've lost the web address to get to PPA's now
[05:49] <Hobbsee> siretart: ahh.  sounds interesting
[05:49] <Hobbsee> i dont have the coding knowledge, sorry
[05:49] <persia> Huh?  PPAs work?  How?
[05:49] <shawarma> siretart: Oh, you're actually helping out with the PPA coding, too?
[05:50] <Hobbsee> ah, found the bugger.
[05:50] <Hobbsee> persia: http://ppa.dogfood.launchpad.net/hobbsee/
[05:51] <siretart> shawarma: no, I'm not
[05:51] <shawarma> siretart: Ah, ok.
[05:51] <siretart> shawarma: the ppa's offer an interface to apt. I'm thinking how revu could exploit that
[05:52] <shawarma> siretart: Oh, right. I got lost in your conversation there.
[05:52] <shawarma> Quick question:
[05:53] <siretart> hm. revu's bandwith is like 10-20k/s, and I have no idea why. the interface is at 100mbit/FD
[05:53] <shawarma> What's the syntax for having a Depends: on e..g package foo version >= 2.5-1  AND < 2.6 ?
[05:53] <StevenK> Specify it twice
[05:53] <shawarma> Is it Depends: foo (>= 2.5-1), foo (<< 2.6) ?
[05:53] <siretart> right
[05:53] <StevenK> shawarma: Yup
[05:53] <shawarma> Or can I join them somehow?
[05:53] <shawarma> Ok, great. Thanks.
[05:53] <siretart> no
[05:54] <Kmos> siretart: maybe it needs a restart :) only 20 kb/s lol..
[05:55] <Kmos> system is updated? something is wrong
[05:55] <siretart> Kmos: its uptime is 5 days, and the problems where already there before the reboot
[05:57] <Kmos> :(
[05:57] <Kmos> it uses apache or lighttpd ?
[05:58] <siretart> apache, revu is implemented in mod-python
[05:58] <siretart> need to run now, will look at it again in debcamp
[05:59] <siretart> sorry
[06:22] <man-di> https://bugs.launchpad.net/ubuntu/+source/libapache2-mod-jk2/+bug/29605 is fixed by removing libapache2-mod-jk2. The last version this was included was breezy. Can someone please how to close this properly?
[06:22] <ubotu> Launchpad bug 29605 in libapache2-mod-jk2 "mod_jk2 is deprecated, mod_jk is newer (and for apache2)" [Medium,Unconfirmed]  
[06:22] <Hobbsee> man-di: as in, how to close it, or what to say?
[06:22] <man-di> what settings to use for closing
[06:23] <man-di> and: Am I allowed to close this at all?
[06:23] <persia> man-di: You are allowed to close.  If it is fixed in the archives, please set to fix released, and report with which version is was fixed in a comment.
[06:23] <Hobbsee> man-di: yes, you can close it, click on libapache2-mod-jk2 (Ubuntu), and change the status, and hit "save changes"
[06:24] <persia> man-di: If it is not fixed (and doesn't apply because it was breezy), please reject with that as an explanation.
[06:26] <man-di> persia: it was fixed by the removal
[06:27] <persia> man-di: In that case, reject it.
[06:27] <persia> man-di: And comment that it is rejected because it no longer applies to a package in the ubuntu archives.
[06:29] <persia> man-di: On a more general note, you might want to ask (at a more active time) about bug management in #ubuntu-bugs.  Also, the topic of that channel has some useful links for how to manage bugs.
[06:30] <man-di> persia: too late, I closed it already
[06:30] <man-di> persia: thanks for the hint
[06:30] <persia> man-di: Great!  Thanks.
[06:36] <man-di> lionel: you merged libapache-mod-jk last time?
[06:37] <man-di> lionel: I wonder why you put the following change into it:
[06:37] <man-di> -	cd build/docs && lynx -dump -nolist changelog.html > changelog
[06:37] <man-di> +	cd build/docs/miscellaneous && lynx -dump -nolist changelog.html > ../changelog
[06:39] <sacater> is it possible to 'upgrade' from an ubuntu install to a tribe CD without having to re-install ubuntu
[06:39] <sacater> i would prefer to upgrade throught the stages
[06:40] <Hobbsee> sacater: yes.  dist-upgrade.
[06:40] <sacater> Hobbsee: ooooh
[06:40] <Hobbsee> sacater: but you likely dont want to update to a snapshot.
[06:40] <Hobbsee> you want to keep going for the moving target.
[06:41] <sacater> Hobbsee
[06:42] <sacater> thank yee
[06:42] <Hobbsee> :)
[07:24] <jrib> how can I figure out what version of python-support I need to depend on to byte-compile a python module if I know that the module requires python >= 2.3?
[07:30] <geser> jrib: afaik linda or lintain will warn about the version of python-support if missing
[07:30] <geser> if you depend on python-support doing the .egg-info renaming, you need to depend on pyhton-support >= 0.6.4
[07:31] <jrib> geser: thank you
[07:50] <jrib> I get "dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}" when I try to build my package, why?  Here's what my control looks like atm: http://paste.ubuntu-nl.org/24878/
[07:52] <jekil> where i must install a software that must be installet right this: http://rafb.net/p/VUi1nc57.html
[07:53] <geser> jrib: you don't call dh_shlibdeps in debian/rules?
[07:54] <jrib> geser: hmm, I
[07:55] <jrib> I'm using cdbs and have  include /usr/share/cdbs/1/rules/debhelper.mk  , I think that is supposed to call the dh_ stuff automatically.  Or am I wrong?
[07:55] <Hobbsee> jrib: in theory, that's true
[07:55] <geser> you are right
[07:55] <geser> jrib: aren't you packaging a python app?
[07:55] <jrib> geser: yeah
[07:56] <jrib> a module
[07:56] <geser> ok, a module might need it
[07:58] <jrib> geser: I tried reading the man page that describes it but wasn't sure I understood it so decided to leave it in.  I think you may be right that it isn't needed though.  The module is pure python
[08:02] <jrib> interesting... even if I remove it I still see the warning in my pbuilder, must just be a quirk of some kind
[08:06] <geser> as long as your python module doesn't link against other libs, you can ignore the warning
[08:07] <leonel> hello hello !
[08:57] <leonel> keescook: I've upgraded feisty's clamav  to the patched version  on another feisty   and  keeps  failing  with the  bad.rar     But the clamav I've builded with  pbuilder after patchin  and made the  debdiff  works  fine  ..
[09:06] <nixternal> effie_jayx: I notice you are Kubuntu on your laptop...how come your daughter isn't :)
[09:07] <effie_jayx> nixternal,  hehe... kde is a killer on that omnibook
[09:07] <nixternal> KDE is killer on everything!!!
[09:07] <effie_jayx> i tired it one... and it was just too slow
[09:08] <nixternal> the only de that I noticed was slow for me ever, was enlightenment
[09:08] <nixternal> KDE has always been super fast for me, but then again I usually tweak a few things as well
[09:08] <effie_jayx> well kde would eat up 90 ram for sure...
[09:08] <nixternal> I don't need all the bling bling junk, it just gets in the way
[09:08] <effie_jayx> and it only has 128 megs
[09:08] <nixternal> oh ya
[09:09] <effie_jayx> mine has a gig so I'm cool for kde
[09:09] <nixternal> you got Edubuntu on that laptop for her is it just Ubuntu?
[09:09] <leonel> keescook: the patched and builded here works  fine   and the updated from security  keeps  failing 
[09:09] <effie_jayx> nixternal,  it's xubuntu with the extra software
[09:09] <nixternal> ahhh, cool
[09:10] <effie_jayx> the edu packages...
[09:10] <effie_jayx> she is one ubuntu freak
[09:10] <effie_jayx> :D
[09:10] <effie_jayx> she just doesn't know the name ;)
[09:11] <effie_jayx> nixternal,  but once I ran a live cd of kurumin... with kde and edu packages on a pentium 1 133mhgz and 256 ram
[09:11] <leonel> keescook: did I made something  wrong ?
[09:18] <alefteris> where can i ask some newbe questions about packaging?
[09:19] <geser> #ubuntu-motu :)
[09:20] <effie_jayx> and taht would be here :D
[09:21] <yosch> raphink: ping
[09:23] <keescook> leonel: I'm not sure; it should be the same results.  Can you email me the "bad" RAR?
[09:24] <alefteris> what i do when the original source i want to packages is in .zip instead of tar.gz? I convert it my self and continue as usual?
[09:25] <geser> alefteris: yes
[09:25] <alefteris> ok thanks
[09:47] <jrib> my upload to revu doesn't seem to be showing up (uploaded 15 minutes ago)
[09:48] <bmm> dput gave no error messages?
[09:48] <Hobbsee> jrib: revu is a bit broken
[09:48] <jrib> Nope, ended with: Successfully uploaded packages.    Not running dinstall.
[09:48] <jrib> Hobbsee: ok, so should I just try again some other day?
[09:49] <Hobbsee> yeah, i think so
[09:49] <Hobbsee> give it a few days, at least
[10:09] <leonel> keescook: what's your email ?
[10:10] <leonel> keescook:  kees@ubuntu.com ?
[10:22] <leonel> keescook: just  reinstalled  clamav  and all worked  fine ...
[10:44] <blueyed> I want to provide a debdiff for bug 66278: should I use 0.97-20ubuntu8 or 0.97-20ubuntu7.1 for the version (it's for gutsy)
[10:44] <ubotu> Launchpad bug 66278 in grub "[patch]  update-grub: savedefault can cause problems" [Undecided,Confirmed]  https://launchpad.net/bugs/66278
[10:46] <Kmos> blueyed: always the latest one
[10:47] <blueyed> Kmos: it's currently 0.97-20ubuntu7 - my question is how should I increase it in the changelog.
[10:47] <Kmos> 0.97-20ubuntu8
[10:48] <blueyed> thanks.
[10:48] <Kmos> i think it's that
[10:48] <Kmos> because the version number wasn't changed
[10:50] <Kmos> yeah, it's 
[10:50] <Kmos> 0.97-20ubuntu8
[10:50] <Kmos> https://bugs.launchpad.net/ubuntu/+source/grub/0.97-20ubuntu7
[10:58] <sacater> going away for 2 weeks, toodles
[10:58] <crimsun> bye.
[11:04] <StevenHarperUK_> Hi : i'm looking for help to get my Python Project into a DEB package, I have made a Setup.py that is making a bdist, but i need to know how is the best way to do the next step
[11:11] <cypherbios> StevenHarperUK_: have you already read the Debian Python Policy?
[11:12] <StevenHarperUK_> Can you give me a URL please
[11:13] <crimsun> http://www.debian.org/doc/packaging-manuals/python-policy/  and http://wiki.debian.org/DebianPython/NewPolicy
[11:13] <cypherbios> that's right
[11:14] <StevenHarperUK_> I have spent abut 6-7 hours on this
[11:14] <StevenHarperUK_> Ill read all that then :p
[11:14] <cypherbios> StevenHarperUK_: it's a good point to start ;)
[11:14] <StevenHarperUK_> ta
[11:15] <cypherbios> crimsun: oh, I still having that problem with .mo files, would you take a look at source if I put it into somewhere you can get?
[11:16] <crimsun> sure
[11:17] <cypherbios> thanks, I'm going to upload somewhere
[11:18] <crimsun> I'm a bit scattered this evening - lots of kids running around, so I may not respond immediately
[11:20] <cypherbios> crimsun: no problem, no hurry
[11:26] <cypherbios> crimsun: http://www.cypherbios.org/aptoncd/0.1.91-1/
[11:26] <cypherbios> crimsun: when you have the chance... thanks :)
[11:42] <jekil> where i must install a software that must be installet right this? http://rafb.net/p/VUi1nc57.html