=== robbiew is now known as robbiew-afk
=== robbiew-afk is now known as robbiew_
[00:49] <xnox> Hello anyone familiar with Edubuntu seed inclusion process?
[00:49] <xnox> I want to get 3 packages into it =)
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[00:58] <ockham> hi, is anybody experiencing this: http://pastebin.com/d275a5d95 when trying to package something user pbuilder?
[01:00] <cjwatson> ockham: looks like you've broken /bin/sh in your chroot.  Make it a symlink to dash
[01:00] <cjwatson> (or maybe dash doesn't handle downgrades properly, I don't know for sure)
[01:00] <cjwatson> "unable to execute installed post-installation script: No such file or directory" means in this case that it can't find the #! interpreter, which is /bin/sh here
[01:00] <cjwatson> for /var/lib/dpkg/info/dash.postinst
[01:05] <ockham> cjwatson: thanks for the hints. this should actually be a pretty clean lucid pbuilder chroot, so i'm a bit afraid of having to tweak it manually
[01:06] <ockham> is there any way to cleanly re-create the chroot?
[01:06] <crimsun> it looks like dash's prerm is kinda "oops".
=== ArneGoet1e is now known as ArneGoetje
[01:14] <xnox> where was the announcment of the Developer Memberhip Board voting results send?
[01:15] <micahg> xnox: u-d-a and it was posted on teh fridge
[01:17] <xnox> micahg: aha thanks =) stragily I'm not subscribed to u-d-a....
[01:17] <xnox> Anyhow when is the next meeting?
[01:17] <xnox> the helpful 15UTC every two weeks is quite vague.... =)
[01:18] <micahg> feb 2
[01:18] <xnox> Ok thanks
[01:18] <micahg> xnox: if you're ever wondering when the meetings are, check the fridge calendat
[01:18] <micahg> *calendar
[01:19] <xnox> Ok I will in the feature. Thank you
[02:58] <maxb> james_w: What's happened to all the debian branches for source package subversion? They are apparently deleted from launchpad?!
=== asac_ is now known as asac
=== micahg1 is now known as micahg
[06:57] <xnox> In the new merges page
[06:57] <xnox> there is bugs column with bugs assigned
[06:57] <xnox> how do i edit it? or link bugs there?
[07:02] <ScottK> The script looks up merge/sync bugs on Launchpad automatically.
[07:06] <xnox> Kk cool =)
[07:06] <xnox> so it will pick mine up next time it scans ;-)
[07:11] <dholbach> good morning
[07:15] <xnox> dholbach: 0/
[07:16] <dholbach> hi xnox
[07:16] <xnox> =) hope your having nice morning ;-)
[07:18] <dholbach> yeah... it will be even better when I've had my first cup of coffee :-)
[07:18] <dholbach> thanks xnox :)
[07:19]  * xnox is a bit too far to make dholbach coffee
[07:20] <dholbach> no worries :)
=== Guest90451 is now known as Zic
[07:42] <xnox> dholbach: thank you for ACKed on my syncs ;-) \0/
[07:44] <dholbach> :-)
[07:51] <MFen> are there any subtle changes in cdbs between jaunty and karmic?
[07:51] <MFen> a python-distutils.mk package i was able to build while running jaunty, will not build in karmic
[07:51] <MFen> it doesn't even attempt to run setup.py
[07:52] <MFen> my rules file: http://paste.pocoo.org/show/167874/
[07:53] <MFen> it builds a package, which contains nothing except the entries in debian/dirs plus copyright, changelog.
[08:18] <pitti> Good morning
[09:06] <tseliot> pitti: any ideas as to what causes this error? dbus.exceptions.DBusException: org.freedesktop.PolicyKit1.Error.Failed: Error parsing subject struct
[09:07] <pitti> tseliot: yes, in fact I do
[09:07] <pitti> tseliot: weird, I fixed that in early lucid already
[09:07] <tseliot> what is it?
[09:07] <tseliot> I'm still getting it here
[09:07] <pitti> a missing parameter in the self.polkit.CheckAuthorization() call
[09:07] <pitti> the karmic version didn't supply start-time
[09:07] <pitti> but it's required with lucid's policykit
[09:08] <tseliot> oh, so I guess I'll have to fix screen-resolution-extra
[09:08] <pitti> tseliot: http://bazaar.launchpad.net/%7Ejockey-hackers/jockey/trunk/revision/583
[09:08] <pitti> tseliot: ah; right
[09:08] <pitti> I thought it was from jockey
[09:08] <pitti> tseliot: above patch should pretty much work for s-r-e, too
[09:09] <tseliot> pitti: ok, thanks a lot
=== njpatel_ is now known as njpatel
[09:46] <MFen> figured it out. it didn't like that my package was named -dev
[10:03] <geser> has someone any idea what happen there? http://launchpadlibrarian.net/38059356/buildlog_ubuntu-lucid-sparc.ncmpc_0.16-1_FAILEDTOBUILD.txt.gz
[10:04] <geser> I've seen this in several FTBFS build logs from 18 Jan and 19 Jan
[10:16] <mvo> ev: hi, did anything change in recent ubiquity (between alpha-2 and now) that could explain why mat_t sees bug #510033 and I don't see it?
[10:16] <ubottu> Launchpad bug 510033 in ubiquity "It's not possible to install mp3 codecs on a fresh install" [Medium,In progress] https://launchpad.net/bugs/510033
[10:16] <mvo> ev: it looks like for him no apt-get update was run in-target during the install, but for me that worked fine (with a daily)
[10:18]  * ev digs
[10:19] <mvo> ev: there was a similar issue in karmic when on a fresh install universe package lists were not available, this is why even wrote a small patch :/
[10:23] <mat_t> mvo: I can test it with daily if that helps
[10:23] <mvo> mat_t: that would be nice. I will still add code to gnome-codec-install for the case when the system is installed without network and later gets connectivity
[10:24] <mat_t> mvo: yes, definitely
[10:24] <mat_t> mvo: thanks a lot for looking at it!
[10:24] <seb128> mvo, could be that he was not online during install?
[10:25] <mat_t> seb128: yes, I wasn't
[10:25] <ev> that would do it then
[10:26] <mvo> mat_t: oh? you wrote "Note: the same error occurs regardless of whether internet connection is established or not"
[10:26] <mat_t> mvo: yes, but I did not account for the installation process
[10:26] <mvo> aha, ok
[10:27] <mvo> ev: sorry for the noise then
[10:27] <mat_t> I only referred to what happened post-installation
[10:27] <ev> no worries
[10:27] <mvo> that explains it
[10:27] <mat_t> :)
[10:28] <mat_t> mvo: so will your patch cater for this scenario?
[10:29] <mvo> yes
[10:30] <mat_t> mvo: brilliant
[10:31] <ttx> seb128: should bug 508297 rather be considered a gtk+2.0 regression ? Should I open a gtk task ?
[10:31] <ubottu> Launchpad bug 508297 in xchat "[lucid] channels do not change color anymore" [High,Confirmed] https://launchpad.net/bugs/508297
[10:31]  * xnox has sent application to become Ubuntu Contributing Developer
[10:34] <seb128> ttx, reassign to gtk rather than opening a new task
[10:35] <ttx> seb128: done
[11:22] <mvo> ev: what is the issue with Ensure that Jockey's apt-cache is up-to-date after install ? (just curious)
=== njpatel_ is now known as njpatel
=== dholbach_ is now known as dholbach
[11:26] <ev> If you're referring to the switch of blueprints, it only becomes an issue when we have a jockey page in ubiquity.  The issue itself is that the jockey backend caches apt-cache lookups, so if you run apt-get update (via "update this installer", for example) while the backend is running, and you get to the jockey page, it wont be using the updated apt cache.
[11:27] <ev> it's not a major deal, as the backend goes away after 10 minutes
[11:27] <ev> mvo: ^
[12:28] <mvo> ev: aha, thanks. I was just curious if its some limitation in python-apt or apt
[12:28] <ev> nope :)
[12:45] <lamont> I wonder... if I drop a karmic libc6 on a hardy system (well, chroot), do things blow up?
[12:47] <directhex> very likely
[12:49] <slangasek> ttx, kirkland: do you recall what the issue was in hardy that caused all instances of scsi-modules-$version-di in the archive to be pulled into the server CD, and is that resolved in post-hardy versions?
[12:50] <slangasek> (it's prompting me to do some needful NBS pruning of kernel binaries in hardy-{proposed,updates,security} which we don't have an automatic way of taking care of - but it would be good if we didn't have to worry about this before lucid point releases)
[12:50] <ttx> slangasek: that doesn't ring any bell
[12:50] <slangasek> ok
[12:50] <lamont> directhex: that was kind of my thinking
[12:50] <lamont> I may just do intrepid/jaunty vms as interim steps in my search for the bug
[12:51] <directhex> lamont, i had enough explosions with sid libc on non-sid debian to not trust it
[12:51] <ttx> slangasek: we should now be able to get rid of cglib2.1, btw
[12:51] <slangasek> lamont: I'm not aware of any specific reasons it would explode
[12:51] <lamont> directhex: ah - very good data point, ta
[12:51] <slangasek> ttx: woohoo! :)
[12:51] <ttx> slangasek: eucalyptus now build/runs from libcglib-java
[12:51] <ttx> (2.2)
[12:51] <lamont> slangasek: coolness.
[12:52] <slangasek> lamont: I may just be exposing my own ignorance, though :)
[12:52] <ttx> slangasek: there are a few universe packages that still depend on libcglib2.1-java but libcglib-java provides it.
[12:53] <ttx> slangasek: let me know if there is anything more I should do on that subject
[12:53] <lamont> slangasek: you're the one who encourages boy scouts to throw gasoline on the fire, aren't you?
[12:53] <directhex> on debian it's usually locales that go to poop when you update libc... but ubuntu's locales are handled differently
[12:53] <ttx> not sure how automatic those removals are
[12:54] <slangasek> ttx: semi-automatic
[12:54] <ttx> Question about main: when a source package gets promoted into main, do all the resulting binaries also end up in main ? Or do they each need to be pulled by something ? i.e. can a main source package have main and universe binaries ?
[12:54] <slangasek> yes, a main source package can have both main and universe binaries
[12:55] <ttx> slangasek: ok, cool.
[12:55] <lamont> and if you find a universe source with main packages, then you have found a bug.  or warty.
[12:55] <ttx> lamont: heh
[12:56] <ScottK> That can still happen if a binary starts being provided by a different source.
[12:56] <lamont> 'twas one of those lolwut? moments
[12:56] <ScottK> It happened for a bit recently with the switch to distribute from python-setuptools source.
[12:58] <slangasek> ScottK: that should show up on components-mismatches, though?  Or was this "old package forgot to say that it no longer owned it"?
[13:41] <barry> mvo: ping
=== marjo_ is now known as marjo
[13:56] <tseliot> cjwatson: currently we don't pass the vga= parameter to vga16fb, right? Any ideas as to how bug #509328 can be fixed without this parameter?
[13:56] <ubottu> Launchpad bug 509328 in nvidia-graphics-drivers "Lucid Alpha2: Plymouth does not work with the current nvidia driver" [Medium,Confirmed] https://launchpad.net/bugs/509328
[13:56] <cjwatson> tseliot: that's correct, because using vesafb breaks suspend/resume
[13:56] <cjwatson> tseliot: I believe the plan of record is to fall back to vga16fb, not vesafb
[13:58] <tseliot> cjwatson: right but currently vga16fb doesn't seem to allow plymouth to work. Is there some parameter we can pass vga16fb?
[13:58]  * tseliot wasn't suggesting that we use vesafb
[13:58] <slangasek> pass it to do what?
[13:59] <cjwatson> tseliot: that I don't know, Keybuk probably would
[13:59] <tseliot> cjwatson: ok, I'll send him an emai. Thanks
[13:59] <cjwatson> I assume that plymouth explicitly rejects it or something at the moment, since vga16fb should present a framebuffer much like anything else
[14:00] <cjwatson> or that we aren't arranging for vga16fb to be loaded if nothing better is available
[14:00] <tseliot> ok
[14:02] <slangasek> from bug #506717 and an examination of the initramfs scripts, I believe vga16fb should be getting loaded correctly in the initramfs
[14:03] <ubottu> Launchpad bug 506717 in plymouth "[Lucid] plymouth does not display when using nvidia drivers" [High,New] https://launchpad.net/bugs/506717
[14:03] <slangasek> i.e., the affected users have it loaded /after/ boot, and the only thing that loads it is the alias, so it should load just as well from the initramfs
[14:05] <tseliot> right
[14:26] <xnox> Check out http://bzr.debian.org/bzr/users/xnox-guest/merges/
[14:26] <xnox> =)
[14:26] <xnox> It's a webpage =)
[14:27] <xnox> Revamped new merges page
[14:27] <xnox> a little bit =)
[14:27] <xnox> http://bzr.debian.org/bzr/users/xnox-guest/merges/index.html
=== dendrobates is now known as dendro-afk
=== dmart_ is now known as dmart
=== dholbach_ is now known as dholbach
=== highvolt1ge is now known as highvoltage
=== tkamppeter_ is now known as tkamppeter
[15:02] <smoser> kees, you have a minute? i've a questoin about ssh known hosts format
=== dendro-afk is now known as dendrobates
=== yofel_ is now known as yofel
=== herb__ is now known as herb
=== beuno is now known as beuno-lunch
=== BenC1 is now known as BenC
[16:58] <kees> smoser: hello!  I'm here now, going through IRC backlogs.  :)
[16:59] <smoser> kees, i bothered jdstrand , he answered. i was somewhat worried that in my known hosts file the 3rd field always started with same 28 chars or so
[17:00] <smoser> it appears to be key header, which always base64 encodes the same, so not an issue (at least i dont think so)
[17:01] <Laibsch> lool: ping.  Do you have a minute?
[17:02] <kees> smoser: ah-ha, yes. that's correct (key header)
[17:03] <smoser> i was afraid i was getting little or no randomness in key generation
[17:06] <lool> Laibsch: Depends how long the minute  ;)
[17:17] <ccheney> doko: did the build work?
[17:24] <doko> ccheney: the build takes about 40h ...
[17:29] <ccheney> doko: oh so won't be done until tomorrow i suppose?
[17:30] <ccheney> doko: was the problem in the past it failed to build or the resulting binaries just failed to work? if failed to build it sounds like it still going is a good sign :)
=== beuno-lunch is now known as beuno
[18:01] <Laibsch> lool: ping.  I sent you one more question.  If you another minute...
[18:08] <MacSlow> bryce_, pitti, seb128: today's updates removed xserver-xorg-video-intel on an intel-GPU based system... any idea why?
[18:26] <hunger> Is there a way to speed up key processing of plymoth in lucid? Entering the passphrase for my disks is really annoying now.
[18:33] <mathiaz> slangasek: hi - re bug 507778
[18:33] <ubottu> Launchpad bug 507778 in acpid "Please merge acpid (1:2.0.0-1) from Debian testing" [Undecided,New] https://launchpad.net/bugs/507778
[18:33] <mathiaz> slangasek: does it make sense to pull 2.0.0 in lucid LTS?
[18:43] <slangasek> mathiaz: I haven't looked at what's different in 2.0.0
[18:44] <slangasek> mathiaz: though I do know there are some changes in the Debian package that will need to be gone over carefully in a merge
[18:45] <mathiaz> slangasek: the debian changelog entry says: New Upstream version from new source tree that already incorporates the
[18:45] <mathiaz> slangasek: netlink patch..
[18:45] <mathiaz> slangasek: I'm not sure how stable is this *new* tree with regards to LTS
[18:48] <mathiaz> slangasek: AFAICT there isn't any major packaging change - kacpimon is a new binary package that has been added
[18:50] <slangasek> yes, I don't know either
[18:51] <mathiaz> kees: jdstrand: mdeslaur: what's your opinion on bug 510732?
[18:51] <ubottu> Launchpad bug 510732 in openssh "OpenSSH server sshd_config PermitRootLogin -> NO" [Wishlist,Incomplete] https://launchpad.net/bugs/510732
[18:51] <kees> mathiaz: we defer to cjwatson.  I would support the change, though.
[18:52] <mathiaz> kees: could you add a comment to the bug?
[18:54] <kees> cjwatson: so, what do you think about this ^^ ?  It's been a long-standing request, and I kind of like it.
[18:54] <kees> mathiaz: what do you think of it?
[18:54] <jdstrand> mathiaz: I'm with kees. I too like it, but realize it cuts down on usability
[18:54] <kees> mathiaz: the logic has been that rootlogin isn't possible by default because there is no root password.
[18:55] <mathiaz> kees: yes - that was my first answer
[18:55] <jdstrand> people argue that if they enable the root account, they want to use it
[18:55] <mathiaz> jdstrand: and it's true that the choice to be made is between usability and multiple layer of security
[18:55] <kees> right
[18:56] <jdstrand> that said, it is something I typically change on machines I administer (and if I can get away with it, AllowUsers)
[18:56]  * kees ♥ AllowUsers
[18:56] <jdstrand> (not suggesting we try to do anything with AllowUsers)
[18:57] <jdstrand> *totally*
[18:57] <kees> so, here's a thought...
[18:57] <kees> we have an implicit possible with gdm to disallow the root user to log in, even if they have a password set.
[18:57] <kees> perhaps we should duplicate this with SSH?
[18:58] <mathiaz> kees: an implicit possible with gdm to disallow the root user?
[18:58] <jdstrand> interesting thought, though there is a similar discussion with sudo and gksudo
[18:58] <mathiaz> kees: what do you mean by that?
[18:58] <kees> mathiaz: oh, er, total typo.  s/possible/policy/
[18:58] <ScottK> Aren't there system risks with running Gnome/KDE as root?
[18:58] <jdstrand> it is interesting in this case that the gui app is more restrictive
[18:58] <kees> ScottK: yes, very much
[18:58]  * ScottK wouldn't see blocking root login as primarily a security issue
[18:58] <ScottK> It's a this won't work issue
[18:59] <kees> ScottK: right, that's why gdm blocks root.
[18:59] <mathiaz> kees: right. there seem to be a policy mismatch here
[18:59]  * slangasek runs GNOME as gdm
[18:59] <jdstrand> it is a known account which makes it particularly easy to brute force (and everyone wants it)
[18:59] <mathiaz> kees: that being said, openssh is not installed by default on desktops
[18:59] <kees> but I'm saying that it might make sense to carry that logic to SSH
[18:59] <ScottK> So it's tangential to the security issue
[18:59] <kees> slangasek: so did I briefly :)
[18:59] <mathiaz> kees: what the reason for disabling root login in gdm?
[18:59] <jdstrand> ScottK: I don't think it is tangential
[19:00] <mathiaz> kees: it seems that the target users are different here
[19:00] <ScottK> There's no system reliabilty reason to avoid ssh as root.
=== elmo_ is now known as elmo
[19:00] <jdstrand> ScottK: if you have an enabled root account *and* allow root passwords (also the default), then it makes it possible to brute force
[19:00] <mathiaz> kees: gdm policy is to disallow end users to shoot themselves in the foot
[19:00] <kees> mathiaz: AIUI, lots of system files can get trashed.  gnome/kde don't support it, etc.
[19:00] <ScottK> jdstrand: Certainly, but that's not why gdm doesn't allow root loging
[19:00] <ScottK> login
[19:00] <mathiaz> kees: are users installing openssh more literate?
[19:01] <jdstrand> ScottK: oh, I thought we were talking about ssh still
[19:01] <mathiaz> kees: ie they know more about the root account
[19:01] <mathiaz> kees: and when they enable the root account they know what they're doing?
[19:01] <kees> mathiaz: I would say a greater percentage of people installing openssh-server understand the root account
[19:01] <jdstrand> running the whole X/Gnome stack is a lot of code that wasn't really written with running as root in mind
[19:01] <kees> mathiaz: and I don't think that people enabling the root account know what they're doing always, which is why I think there's value in making the SSH default be tighter
[19:02] <jdstrand> again, I'm for it, but defer to cjwatson
[19:03] <mathiaz> kees: the other argument for defaulting PermitRootLogin to no is that's what upstream recommends in their documentation
[19:03] <mathiaz> (even though the default is yes)
[19:04] <kees> mathiaz: yeah, agreed.  mostly we would need to convince cjwatson.  :)
[19:04] <ScottK> Sounds like upstream should change then
[19:11] <kees> mathiaz: http://cheezburger.com/View.aspx?aid=3094191616
[19:12] <mathiaz> kees: lol
[19:13] <mathiaz> kees: that's *very* helpful in taking a good decision :)
[19:13] <kees> mathiaz: yeah, I've been using that site for diagrams a lot lately, super easy
[19:13] <mathiaz> kees: the whole question is actually about the *size* of the different circles
[19:14] <mathiaz> kees: if blue > brown, then default PermitRootLogin to yes
[19:14] <mathiaz> kees: if blue < brown, then default PermitRootLogin to no
[19:14] <kees> mathiaz: exactly.
[19:15] <kees> mathiaz: actually, maybe not.
[19:15] <mathiaz> kees: AFAICT the *current* representation relies on the number of letters in the circle label
[19:15] <kees> PermitRootLogin to no protects the dark green area.
[19:16] <mathiaz> kees: minus the blue area
[19:16] <kees> mathiaz: yup.  comment posted to the bug detailing this logic.
[19:17] <mathiaz> kees: awesome!
[19:18] <mathiaz> kees: jdstrand: thanks for taking the time to look at this
[19:19] <kees> mathiaz: sure, no problem.  it's come up before, but the brute-forcing attempts have been getting stronger lately, so it's valuable to revisit it.
[19:19] <kirkland> slangasek: i don't recall that at all, sorry
[19:22] <jdstrand> mathiaz: np! :)
[19:34] <xteejx> NCommander: Hi, I was told by charlie-tca that you were the best person to speak to about helping to build packages for the Ubuntu PS3 port (PowerPC)
[19:35] <xteejx> I want to contribute
=== gnomefreak76 is now known as gnomefreak
=== mrpouit is now known as mr_pouit
=== ajmitch_ is now known as ajmitch
=== arand__ is now known as arand
[20:22] <jonathan_> Wow this is busy
=== cjohnston is now known as notcjohnston
=== notcjohnston is now known as cjohnston
[20:37] <lool> Laibsch: It's ok, don't ask to ask, just leave me your questions and I should get to them
[20:37] <Laibsch> lool: I don't ask to ask, but I was under the impression that a ping here grabs your attention while simply writing to you in an ongoing chat doesn't
[20:38] <Laibsch> just wanted to make sure our discussion isn't lost in the void
[20:53] <statik> hey, anyone available to sponsor a merge? I filed the proposal about 4 days ago. I'm not in any particular hurry, just don't want it to rot: https://code.edge.launchpad.net/~statik/ubuntu/lucid/protobuf/merge-bug502654/+merge/17571
[20:54] <lool> Laibsch: it's actually exactly the same, except I get two red channels instead of one  :-)
[20:55] <Laibsch> lool: OK, thanks
[20:58] <ScottK> statik: At this point in the cycle, that's not so long.
[20:59] <statik> ScottK: i can only imagine. i'm buried in work myself and i don't have to deal with sponsoring :)
[21:26] <lamont> where does sound-juicer get track names from?  (and more to the point, when it decides that the musicbrains answer is available, how do I tell it "no, that's wrong"?
[21:26] <lamont> and yeah, echan and all that
[21:30] <ion> siretart: Debian seems to have fix for the gst-plugins-bad0.10 FTBFS.
[21:35] <TheMuso> lamont: musicbrainz for one
[21:36] <TheMuso> lamont: And very likely cddb/freedb.
[21:39] <lamont> TheMuso: well, it's telling me that musicbrains doesnt have it, so I expect "not that"
[21:39] <lamont> more to the point, sometimes it's getting it very right, other times wildly wrong - for the same CD set...
[21:39] <lamont> ergo, I want a way to influence it's voting...
[21:40] <TheMuso> lamont: heh right.
[21:40]  * TheMuso has found that the shell script abcde is the most flexible method of ripping for his needs.
[21:42] <lamont> does it get track info?
[21:43] <lamont> actually, is there any way to have that data encoded on the CD? or is it all magic lookups based on hashes?
[21:44] <TheMuso> lamont: Yes it gets track info, I think it may have some support for musicbrainz, but it mostly uses freedb. Note that there is no GUI for abcde.
[21:44] <TheMuso> lamont: I don't think this can retrieve cd-text.
[21:49] <lamont> ok
[21:49] <lamont> thanks
[21:51] <chrisccoulson> is there any reason why fuse-utils provides a /sbin/mount.fuse helper but no umount.fuse helper?
[21:52] <cjwatson> kees: convince upstream.  I'm not going to deviate from them
[21:55] <cjwatson> kees: and frankly, I'm fed up with having the discussion every ten minutes
[21:55] <cjwatson> (this isn't getting at you, but at the people who won't read)
[23:35] <ockham> hi, is there any easy way to rename a manpage when installing it using debian/<package>.manpages?
=== robbiew is now known as robbiew_