[00:05] <bdrung_> Zhenech: the subject would be "override: mozilla-pwdhash:web/optional"?
[00:07] <Zhenech> seems so
[00:07] <Zhenech> goin to bed now
[00:07] <Zhenech> n8
[00:09] <bdrung_> Zhenech: done
[00:09] <bdrung_> Zhenech: gn8
[01:25] <pochu> Ampelbein: nice work on seahorse :D
[01:27] <Ampelbein> pochu: Well, since I cleaned up the bugs in ubuntu before, I figured I could go and see in the debian bugtracker what can be closed ;-)
[01:27] <jtimberman> Any motu available to review (and advocate? :)) stompserver: http://revu.ubuntuwire.com/p/stompserver
[01:57] <hyperair> Zhenech: if you're still around, gaeny-plugins got built just before the new geany was released, and now needs a binNMU =\
[02:47] <LLStarks> can an opinion on this bug? https://bugs.launchpad.net/synaptic/+bug/416267
[02:47] <LLStarks> *i get an opinion
[06:09] <Majost> Is packages.ubuntu.com down?
[06:09] <binarymutant> yes on my end
[06:09] <Majost> huh
[06:09] <binarymutant> yes it's down
[06:10] <Majost> just wanted to make sure it was a planned or know thing
[06:10] <Majost> ;)
[06:10] <Majost> known too
[07:03] <dholbach> good morning
[07:21] <lidaobing> dholbach, morning
[07:21] <dholbach> hey lidaobing!
[07:22] <lidaobing> dholbach, hello
[07:22] <dholbach> how are you doing today?
[07:22] <lidaobing> working
[07:22] <lidaobing> it's afternoon here
[07:23] <dholbach> so you had a good day so far? :)
[07:23] <dholbach> hey noodles775!
[07:23] <noodles775> Hiya dholbach :)
[07:23] <lidaobing> dholbach, yes
[07:24] <dholbach> great :)
[07:24] <dholbach> lidaobing: how's ibus coming along? when do you think it can become the default? :-)
[07:25] <lidaobing> sounds the MIR process has been finished for ibus
[07:25] <dholbach> oh nice
[07:25] <lidaobing> still some bug on ibus, but less bug than scim
[07:25] <dholbach> so we get it all into main and by default for karmic?
[07:26] <dholbach> what's going to happen to the scim world?
[07:26] <lidaobing> I don't know whether it's default, freeflying should know it
[07:26] <lidaobing> Suzhe on longer work on scim
[07:27] <dholbach> we could probably ask Arne
[07:27] <lidaobing> and no active maintainer on that project (but still live)
[07:27] <dholbach> that's really exciting
[07:27] <lidaobing> what's Arne working on?
[07:28] <dholbach> he's been working on fonts and to some degree on input methods
[07:28] <dholbach> it really sounds like you guys should be in touch :)
[07:28] <dholbach> he's ArneGoetje on #ubuntu-devel
[07:28] <lidaobing> dholbach, good
[07:29] <dholbach> can you join  #ubuntu-devel ?
[07:31] <dholbach> lidaobing: ^
[07:41] <highvoltage> anyone else having trouble reaching http://packages.ubuntu.com?
[07:42] <Zhenech> yes
[07:43] <jtimberman> highvoltage: it was down earlier.
[07:54] <Zhenech> hyperair, so what should I do? :)
[07:59] <hyperair> Zhenech: request a binNMU... wait, is a DD's privileges required for this?
[07:59] <Zhenech> hyperair, no, its maintainers task :)
[07:59] <hyperair> alright, i'll do that then =)
[08:00] <Zhenech> fine :)
[08:00] <Zhenech> but where is new geany? i dont see any
[08:00] <Zhenech> wait
[08:01] <Zhenech> okok, I see it XD
[08:01] <Zhenech> then
[08:01] <Zhenech> you need a = dep in the plugins
[08:01] <Zhenech> if that will break with every new geany upload
[08:02] <hyperair> it shouldn't have broken =\
[08:03] <hyperair> i'll go poke the upstream
[08:04] <Zhenech> oke
[08:04] <Zhenech> sudo make me a coffee
[08:04] <Zhenech> *waits*
[10:06] <garyvdm> Hi - I'm trying to dput to a launchpad ppa. It stops on the .orig.tar.gz:  on 467k/468k. I left it for 5 min, but it did not continue.  Here is pastebin of my console: http://paste.ubuntu.com/256786/
[10:06] <garyvdm> Is there any thing I can try to get it to go?
[10:07]  * garyvdm crossposts to #launchpad
[10:08] <garyvdm> Hi - I'm trying to dput to a launchpad ppa. It stops on the .orig.tar.gz: on 467k/468k. I left it for 5 min, but it did not continue. Here is pastebin of my console: http://paste.ubuntu.com/256786/
[10:08] <garyvdm> Is there any thing I can try to get it to go?
[10:13] <lucas_> mmh, what's the current recommended procedures to requests syncs from debian?
[10:13] <lifeless> lucas_: requestsync...
[10:13] <lifeless> garyvdm: #launchpad perhaps
[10:13] <lucas_> thanks
[10:13] <lifeless> docs in the policy manual/wiki as usual
[10:14] <noodles775> garyvdm: Apparently a few people have experience that same issue in the past, and it has usually been related to a router bug...
[10:14]  * noodles775 looks for the bug.
[10:15] <noodles775> garyvdm: https://bugs.edge.launchpad.net/soyuz/+bug/251685
[10:18] <noodles775> garyvdm: ah, so according to the bug there is also an issue on the lp server, but it's not yet clear what it is (nor is there a workaround in the bug :/ ).
[10:19] <lucas_> mmh, isn't someone interested in packaging ubuntu-dev-tools and its deps into debian?
[10:21] <Laney> lucas_: you guys want that?
[10:25] <DktrKranz> Laney: could be interesting to have some, Ubuntu developers working on debian boxes could benefit from such a tool
[10:27] <azeem_> maybe it makes sense to submit generally-useful scripts/tools to the devscripts package (if there are any)
[10:28] <DktrKranz> well, there are several
[10:28] <DktrKranz> requestsync is very useful
[10:28] <azeem_> Ubuntu-specific however?
[10:29] <DktrKranz> it is, but it can be used by Debian maintainers to request syncs for their packages
[10:29] <azeem_> well, maybe having them in devscripts would be fine as well, dunno; however it would be easier to maintain them seperately
[10:29] <azeem_> ok
[10:30] <DktrKranz> it requires some deps (launchpad-integration), but I think this can be included in Debian anyway
[10:30] <DktrKranz> it's not Ubuntu-specific, LP is intended for several projects, not just Ubuntu
[10:35] <ScottK> DktrKranz: Requesting syncs from Debian into Ubuntu is Ubuntu specific.
[10:36] <lucas_> well, I don't have any ubuntu box currently, so it would clearly be very useful for me to have ubuntu-dev-tools in debian :-)
[10:36] <lucas_> but that's a selfish motivation
[10:36] <ScottK> Certainly.
[10:37] <ScottK> (that's a reasonable thing to want)
[10:37] <DktrKranz> ScottK: I meant Launchpad is not Ubuntu-specific
[10:37] <ScottK> I just don't think it goes in devscripts.
[10:37] <ScottK> True
[10:37] <lifeless> I think it would be great to have ubuntu-dev-tools packaged in debian - as ubuntu-dev-tools :)
[10:37] <lifeless> DktrKranz: actually, it *is* Ubuntu specific
[10:38] <lifeless> DktrKranz: it builds on launchpad specific libraries, but its tailored to ubuntu's process which is not the same as other users of launchpad may choose to do
[10:38] <DktrKranz> I'm not sure of that, think about specific projects and their bugtracker, for instance
[10:38] <lucas_> it's probably better to have ubuntu-dev-tools in debian *AND* try to get useful scripts integrated into devscripts
[10:38] <lifeless> DktrKranz: I'm sure of it ;)
[10:38] <lifeless> lucas_: ack; I think you'll find there are various patches in devscripts already with ubuntu support/things
[10:38]  * ScottK agrees with lucas
[10:40] <DktrKranz> well, we could file some ITPs notifying debian-devel, just to see other opinions
[10:41] <lucas> that would mean packaging python-launchpadlib, python-launchpad-bugs and ubuntu-dev-tools, right?
[10:42] <lucas> u-d-t has a dependancy on reportbug (>= 3.39ubuntu1). does it require an ubuntu-specific patch?
[10:44] <ScottK> There's a submittodebian (or similar) script that's probably not relevant.
[10:44] <dholbach> lucas: no, I think that was when the user tags were introduced in Ubuntu before Debian
[10:44] <sebner> ScottK: aloha! Do you remember that we were removing boson since it didn't build? Debian made some uploads and it now builds again (here in Karmic), I'm against a re-including since one point was also dead upstream (last release in 2006) and no svn activities for nearly a year or something like that. What do you think?
[10:44] <ScottK> sebner: Did someone ask for it?
[10:44] <geser> lucas: u-d-t doesn't use python-launchpad-bugs anymore (the dependency got dropped in trunk)
[10:45] <ScottK> sebner: if it's maintained in Debian and there's user interest, I think it's fine.
[10:45] <lucas> geser: nice
[10:47] <sistpoty|work> ScottK, sebner: boson is actively maintained in debian nowadays, and iirc it has also seen upstream activity again
[10:47] <DktrKranz> geser: it would help switching to python-support
[10:48] <sebner> sistpoty|work: uhh, nice
[10:48] <sebner> sistpoty|work: huhu btw :D
[10:48] <sistpoty|work> huhu sebner ;)
[10:49] <sebner> sistpoty|work: not on SF svn though. Last commit 15 months ago
[10:49] <sistpoty|work> sebner: then I didn't recall correctly :P
[10:50] <sebner> heh
[10:51] <sebner> ScottK: Debian maintainer is active, a user added a comment on LP telling that it builds which indicates user interest. So I'll sync and the best is that it doesn't need fakesyncs then ^^
[10:54] <geser> DktrKranz: as you have commit rights to the u-d-t trunk you're free to change it to python-support
[10:55] <ivoks> any ideas how to solve stuff like:
[10:55] <ivoks> dpkg-shlibdeps: error: no dependency information found for debian/tmp/usr/lib/libfenced.so.3 (used by debian/cman/usr/sbin/gfs_controld).
[10:59] <DktrKranz> geser: ok, I'll have a try
[11:01] <sistpoty|work> ivoks: hm... what does objdump -p gfs_controld | grep NEEDED output?
[11:02] <ivoks> sistpoty|work: libfenced.so.3 among others
[11:02] <ivoks> sistpoty|work: and debian/tmp/usr/lib/libfence
[11:02] <ivoks> sistpoty|work: exists
[11:02] <ivoks> gr...
[11:03] <ivoks> debian/tmp/usr/lib/libfenced.so.3
[11:03] <sistpoty|work> ivoks: using debhelper? is libfenced.so.3 installed in a package (then debhelper should actually get it right, see dh_shlibdeps man-page, example)
[11:03] <ivoks> no, libfenced.so.3 isn't part of any package
[11:03] <ivoks> hm...
[11:11] <rowinggolfer> my application installs an icon to /usr/share/icons/hicolor/scaleable
[11:11] <geser> have you a dh_makeshlibs call in your debian/rules?
[11:12] <rowinggolfer> do I need to run a post install script.
[11:12] <ivoks> geser: yes
[11:12] <rowinggolfer> the icon works, but only after restarting x.
[11:12] <ivoks> the same debian/ worked with a bit older upstream version
[11:12] <rowinggolfer> not a big problem... but It would be preferable if I could have the icon from the get go
[11:13] <ivoks> 3.0.1 vs 3.0.0
[11:35] <lucas> azeem_: are you in contact with Matthias Jahn?
[11:35] <rowinggolfer> anybody ??
[11:36] <slytherin> rowinggolfer: I don't think it is necessary. Are you testing the application on karmic?
[11:37] <rowinggolfer> popey did.
[11:38] <rowinggolfer> this is just a general packaging question I guess
[11:38] <popey> rowinggolfer: i have another karmic machine I can test on a bit later, its never seen your app so the icon wont be there
[11:38] <rowinggolfer> wrong place?
[11:38] <sistpoty|work> rowinggolfer: take a look at man dh_icons ;)
[11:38] <rowinggolfer> sistpoty|work: thanks!
[11:39] <sistpoty|work> np
[11:40] <azeem_> lucas: why?
[11:40] <lucas> azeem_: he maintains python-httplib2, which is totally outdated in debian (and is a dep for python-launchpadlib)
[11:40] <lucas> azeem_: and you co-maintain 3 packages with him
[11:40] <azeem_> haven't seen him in ages TBH
[11:41] <lucas> ok
[11:46] <slytherin> rowinggolfer: right, I got confused. I believe dh_desktop was deprecated but dh_icons is still needed.
[11:47] <rowinggolfer> slytherin: sistpoty|work thanks dudes.
[11:47] <sistpoty|work> you're welcome ;)
[11:49] <DktrKranz> lucas: are you going to orphan python-httplib2
[11:50] <rowinggolfer> one other newbie packaging question if I may......
[11:51] <rowinggolfer> how to install to Applications/Programming
[11:51] <rowinggolfer> it keeps ending up in "other"
[11:53] <rowinggolfer> the .desktop file is
[11:53] <rowinggolfer> Categories=Application;Programming;
[11:53] <rowinggolfer> yet it goes to "other"
[11:53] <rowinggolfer> what am I doing wrong?
[11:54] <lucas> DktrKranz: yes, just did it
[11:55] <sistpoty|work> rowinggolfer: I don't think these catagories actually are valid. Take a look at http://standards.freedesktop.org/menu-spec/latest/apa.html
[11:56] <sistpoty|work> rowinggolfer: also, I guess desktop-file-validate <desktopfile> might tell you if there's s.th. wrong with it
[11:56] <DktrKranz> lucas: do you plan to maintain it? Otherwise, I'll be happy to do it under DPMT
[11:57] <lucas> DktrKranz: that would be great ; I don't plan to maintain it
[11:57] <lucas> I X-Debbugs-Cced debian-python@
[11:58] <DktrKranz> I'll look at it then, thanks :)
[12:01] <slytherin> rowinggolfer: For Programming use category 'Development'.
[12:03] <rowinggolfer> ta
[12:24] <rowinggolfer> slytherin: ok.. new packages all built and working. many thanks.
[12:26] <EagleScreen> In the case of a package that require a sync, but before it was a merge, should be last Ubuntu changelog entries ignored, keept Debian maintainer, and keept "unstable" release?
[12:28] <EagleScreen> I mean "unstable" target release in the debian/changelog
[12:30] <geser> rowinggolfer: you can check you .desktop file with desktop-file-validate for conformance
[12:34] <EagleScreen> I understand that a sync does not require nothing of work by contributors, only merges, isn't it?
[12:35] <geser> EagleScreen: you should do a check if it builds in karmic before requesting a sync
[12:36] <sebner> EagleScreen: and if it's really a sync and doesn't contain any remaining or new changes
[12:36] <sebner> huhi geser :D
[12:36] <geser> Hi sebner
[12:36] <geser> EagleScreen: and soon if it can by synced or a FF exception is needed
[12:37] <EagleScreen> thanks i think i messed a little the sync and the merge stuff, i have attached a pair of debdiff to a sync bug, lol
[12:37] <EagleScreen> and I merged in it the Debian and Ubuntu changelogs
[12:38] <rowinggolfer> geser: great tip, thanks
[12:39] <EagleScreen> after Feature Freeze, packages that does not contains new upstream version, cannot be synced?
[12:39] <rowinggolfer> prog/pyapptemplate-0.0.1/desktop/pyapptemplate.desktop: warning: value "Application;Development;" for key "Categories" in group "Desktop Entry" contains a deprecated value "Application"
[12:39] <rowinggolfer> interesteing
[12:39] <rowinggolfer> that explains it.
[12:42] <sebner> EagleScreen: even new upstream version is allowed if the new release contains *only* bugfixes. Other than that you are fine with non-upstream changes. Though they should be worth a sync, fixig RC bugs etc
[13:01] <kklimonda> what to do if a wrong (older) version was synced from debian? should i open new bug report or change bug status from fix released to confirmed?
[13:03] <slytherin> EagleScreen: when doing merges, use grab-merge script. It merges changelog properly.
[13:03] <slytherin> kklimonda: new bug.
[13:03] <EagleScreen> yes i used it
[13:03] <EagleScreen> but i messed the concepts and i did a merge for a sync
[13:03] <kklimonda> ok thanks
[13:05] <kklimonda> slytherin: could you create a bug for me?
[13:05] <kklimonda> I wont be at home before 27th and preparing right sync request from a phone wont be easy ;)
[13:07] <kklimonda> or anyone else - package python-cherrypy3
[13:08] <EagleScreen> i used to think that a package cannot have "unstable" in changelog target release and a change in the chagelog was needed to karmic, that is because Launchpad reject them when uploading to ppa, but now I see that it is possible in Ubuntu Archive
[13:16] <EagleScreen> i have a simple program that is a python script, how must I proceed to learn to package it?
[13:18] <juanje> Hi, one more advocate needed for nautilus-md5sum - anyone available to review? http://revu.ubuntuwire.com/p/nautilus-md5sum
[13:30] <jjmontes> hi
[13:30] <jjmontes> is this a correct way to ask about packages and meta-packages?
[13:43] <RoAkSoAx> DktrKranz, heya!! hey I have a small question: by this "No need to install PKG-INFO in .egg-info directory." you mean there's no need to install PKG-INFO at all, or just under .egg-info directory?
[13:44] <DktrKranz> no need at all
[14:01] <RoAkSoAx> DktrKranz, ok awesome!! thanks for the review!! I've uploaded my changes :)
[14:02] <DktrKranz> good
[14:23] <AnAnt> Hello, why does request-sync in karmic use LP lib by default ?
[15:19] <geser> AnAnt: for some tests is uses the LP API but I'm working on it (not using LP API without --lp)
[15:19] <geser> AnAnt: e.g. it uses LP API to check for sponsorship
[15:21] <slytherin> AnAnt: You mean for filing request or for retrieving information?
[15:26] <slytherin> a bit offtopic, does anyone know how to create a syntax highlighting template for vim?
[15:27] <geser> look at the existing ones and read the vim help
[15:32] <AnAnt> slytherin: what I try to do is this: requestsync -s irssiscripts karmic
[15:32] <ryanakca> shadeslayer: OK. So, apt-get the sources for the package. Then go into the sources directory and look at the contents of the debian/ subdirectory.
[15:32] <AnAnt> I filed a bug already
[15:33] <ryanakca> shadeslayer: also, try building hello-<VERSION>.dsc using pbuilder.
[15:33] <shadeslayer> AnAnt: oh btw PC beep works ;)
[15:33] <AnAnt> LP 416955
[15:33] <AnAnt> shadeslayer: oh really ? how's that ?
[15:33] <shadeslayer> AnAnt: modprobe i guess
[15:33] <AnAnt> shadeslayer: I mean, what did you do ? an upgrade or what ?
[15:33] <shadeslayer> ryanakca: ok...ill just finish with the updates
[15:34] <shadeslayer> AnAnt: no upgrade,just rmmod and modprobe a few times and got it to work
[15:34] <AnAnt> shadeslayer: ?!
[15:34] <shadeslayer> AnAnt: rmmod pcspkr;sudo modprob pcspkr
[15:34] <AnAnt> shadeslayer: does the beep sound regular ?
[15:35] <AnAnt> shadeslayer: yeah I understand, I did that several times, but no use, it only works if I rmmod pcspkr
[15:36] <shadeslayer> AnAnt: regular??? lol....it sounds like a high pitched siren if you know what i mean
[15:36] <ryanakca> shadeslayer: you can apt-get source even while updates are running. And you can run it as non-root (in fact, you should)
[15:36] <AnAnt> shadeslayer: and the beep sounds awkward: http://launchpadlibrarian.net/30543548/beep.ogg
[15:36] <shadeslayer> ryanakca: ah..ok
[15:37] <shadeslayer> AnAnt: nope...
[15:37] <shadeslayer> AnAnt: how do you record a beep btw?
[15:37] <AnAnt> shadeslayer: that's not what you get ?
[15:37] <shadeslayer> AnAnt: nope
[15:38] <AnAnt> shadeslayer: well, I put the mic on the speakers, and the room was quiet at that time
[15:38] <shadeslayer> AnAnt: i have inbuilt ones and the beep is really loud.... :P
[15:38] <AnAnt> shadeslayer: you can control the beep, from alsamixer
[15:38] <AnAnt> I mean beep volume
[15:38] <shadeslayer> AnAnt: lemme check
[15:39] <shadeslayer> AnAnt: yep
[15:40] <slytherin> AnAnt: Just in case you haven't noticed already, monajat is in archives. :-)
[15:40] <AnAnt> slytherin: oh thanks !
[15:40] <AnAnt> slytherin: I hope I can get the python one soon !
[15:40] <AnAnt> slytherin: there's a bug in the java one, turns out that it does not non-free font after all !
[15:40] <slytherin> what bug?
[15:40] <AnAnt> slytherin: there's a bug in the java one, turns out that it does *need* non-free font after all !
[15:41] <AnAnt> slytherin: remember the font issue ?
[15:41] <slytherin> Yes I do. But I though ttf-libration should be good enough.
[15:41] <shadeslayer> ryanakca: im on a crappy connection (128 kbps)
[15:41] <AnAnt> slytherin: nope, turned not good !
[15:42] <AnAnt> slytherin: anyways, the python version is almost there
[15:42] <AnAnt> slytherin: it uses notify OSD instead
[15:42] <slytherin> AnAnt: I had advised cutout long time ago to use font family name (Sans) instead of a specific font (Arial).
[15:42] <slytherin> AnAnt: you can still try patching the source to use font family.
[15:42] <AnAnt> slytherin: I tried patching the java code to user Sans or Serif, but still the problem remained
[15:43] <AnAnt> slytherin: so I gave up on it
[15:43] <slytherin> When I had patched it, it looked good to me, at least with default Sans font.
[15:44] <AnAnt> slytherin: sometimes the text is big, bigger than the window, hence some words get chopped !
[15:45] <AnAnt> anyways, someone volunteered to rewrite in python, and there's a working version, just an issue (that maybe I can ignore now) is left is that the text is sometimes too big, that notify OSD truncates it
[15:45] <AnAnt> so I want to find out a way to detect maximum text size before truncation
[15:46] <slytherin> which version of notify-osd are you using?
[15:46] <AnAnt> shadeslayer: so, for every reboot, you keep rmmod'ing & modprobe'ing till beep works ?!
[15:47] <AnAnt> slytherin: the one in karmic
[15:47] <slytherin> ok
[15:48] <AnAnt> slytherin: 0.9.17-0ubuntu1
[15:48] <shadeslayer> AnAnt: nope....
[15:49] <shadeslayer> AnAnt: it works by deafult
[15:49] <AnAnt> shadeslayer: are you sure there wasn't some pulseaudio option to tweak ?
[15:50] <shadeslayer> AnAnt: pretty sure
[15:50] <AnAnt> no work here !
[15:51] <shadeslayer> AnAnt: how long will you be around?
[15:51] <AnAnt> shadeslayer: dunno, why ?
[15:52] <AnAnt> shadeslayer: prolly, not much though
[15:52] <shadeslayer> AnAnt: i have some upgrades coming through (150 MB) as soon as they are done ill upload a recording
[15:53] <AnAnt> shadeslayer: upload it where ?
[15:53] <shadeslayer> AnAnt: somewhere on the interwebs
[15:54] <shadeslayer> AnAnt: the upgrade will be done in about 40 mins and another 10 mins to record and upload
[15:57] <AnAnt> shadeslayer: I'll probably leave in few mins, can you send me a message over LP about the link ?
[16:02] <shadeslayer> AnAnt: okies
[16:02] <AnAnt> thanks
[17:45] <jtimberman> mathiaz: going through chef now, just added the patch description, it went missing after i set my quilt_patches env variable correctly and recreated the patches.
[17:50] <mathiaz> jtimberman: right - that's what I thought.
[18:06] <lamalex> hey guys, does anyone know if python-clutter will be updated for karmic to the latest release?
[18:09] <jtimberman> mathiaz: new upload
[18:27] <mathiaz> jdstrand: kirkland: http://paste.ubuntu.com/257042/ - should the copyright file mention only copyrights shipped as part of the *source* package?
[18:28] <kirkland> mathiaz: as opposed to?  dependent packages?  linked packages?  binary packages?
[18:28] <jdstrand> mathiaz: umm, yes? I'm not sure I understand the question. the binaries contain differently licensed stuff?
[18:28] <mathiaz> or should it also cover things that are shipped by the binary package (build during the process)
[18:28] <mathiaz> or should it also cover things that are shipped by the binary package (build during the build process)
[18:29] <mathiaz> in the example above: openqrm-initrd-default.tgz is build during the build process
[18:29] <mathiaz> it contains some code from busybox which is not in the source package
[18:29] <mathiaz> should it mentionned in the copyright file?
[18:29] <mathiaz> should it be mentionned in the copyright file?
[18:30] <jdstrand> mathiaz: the library linking needs to be compatible, but to be redistributable, the copyright only needs to reference what is shipped in the source package aiui
[18:30] <jdstrand> mathiaz: perhaps run it by a license junkie too?
[18:32] <azeem_> mathiaz: how does it contain code which is not in the source package?
[18:32] <azeem_> is that code downloaded from elsewhere during the build?
[18:32] <mathiaz> azeem_: from build dependencies
[18:33] <azeem_> ah
[18:34] <jdstrand> mathiaz: it would not hurt to reference that, but I don't think it is required, personally. when you do 'apt-get source <pkg>' you'll get only the stuff from the copyright
[18:35] <jdstrand> or rather, from the non-busybox included source
[18:41] <ivoks> i need help :/
[18:41] <ivoks> source is building a private library
[18:41] <ivoks> and then both me and dpkg-shlibdeps get confused
[18:41] <ivoks> :)
[18:42] <ivoks> i've added path to the LD_LIBRARY_PATH
[18:42] <ivoks> but now it dies with
[18:43] <ivoks> error: no dependency information found for library (used by binary)
[18:57] <ScottK> Laney: For ghc6, how do we get ia64 fixed?
[18:58] <hyperair> ivoks: nyou shouldn't be playing around with LD_LIBRARY_PATH when dealing with dpkg-shlibdeps
[19:01] <ivoks> hyperair: why?
[19:01] <hyperair> ivoks: because it won't be set when the user runs it?
[19:01] <hyperair> ivoks: unless you've got some wrapper shell script that sets the env vars =\
[19:02] <ivoks> my problem is this:
[19:02] <ivoks> dpkg-shlibdeps: error: couldn't find library libfenced.so.3 needed by debian/cman/usr/sbin/gfs_controld (ELF format: 'elf64-x86-64'; RPATH: '').
[19:02] <hyperair> alright, and where is that library?
[19:02] <ivoks> there's no debian/cman/DEBIAN/shlibs
[19:02] <ivoks> it's in debian/tmp/usr/lib
[19:02] <hyperair> hmm
[19:02] <hyperair> i haven't heard of a problem like that =\
[19:06] <ivoks> argh...
[19:07] <ivoks> libfence and libfenced :)
[19:07] <hyperair> ?
[19:07] <ivoks> there are both libfence and libfenced libraries
[19:07] <hyperair> i see
[19:08] <ivoks> but libfenced wasn't installed in any of the packages
[19:08] <hyperair> haha i see
[19:08] <ivoks> i'm not sure what should i do with it
[19:08] <hyperair> ?
[19:08] <hyperair> how are you splitting your pacakges?
[19:08] <ivoks> upstream:
[19:08] <ivoks> If you think this library is installed on your cluster, you are wrong.
[19:08] <ivoks> :)
[19:08] <ivoks> that's in headers
[19:09] <ivoks> You have never seen it, it doesn't exist, you'll never talk about it or ponder to use it.
[19:09] <ivoks> hyperair: there's only libfence package
[19:10] <hyperair> O_o
[19:10] <hyperair> talk to upstream about it
[19:10] <hyperair> it obviously needs to be distributed
[19:10] <ivoks> right
[19:12] <hyperair> if it shouldn't be distributed, they should have statically compiled it into one of the libraries or the binary
[19:25] <jtimberman> mathiaz: latest chef upload should fix the outstanding issues in your comment.
[19:29] <ivoks> hyperair: thanks for help
[19:31] <ivoks> hyperair: upstream uses the same library in different ways for different stages of source in svn
[19:31] <ivoks> hyperair: so that's why they didn't build it in staticaly
[19:46] <hyperair> ivoks: well is it supposed to be distributed or not, then?
[19:47] <ivoks> it is
[19:47] <ivoks> but it shouldn't be used for development
[19:47] <ivoks> it was confusing explanation :)
[20:10] <mathiaz> kirkland: how do you fix the possible bashisms: kill -1 $pid ?
[20:10] <kirkland> mathiaz: /bin/kill
[20:10] <kirkland> mathiaz: don't use the shell builtin kill
[20:11] <hyperair> that's a bashism?
[20:12] <hyperair> the manpage seems to indicate that -1 is allowed
[20:13] <mathiaz> hyperair: the man page of kill or of bash/dash?
[20:13] <hyperair> man page of kill
[20:13] <hyperair> it's SIGHUP is it not?
[20:13] <mathiaz> hyperair: right you're looking at the /bin/kill man page then.
[20:13] <hyperair> mmhmm, so how's that a bashism?
[20:14] <mathiaz> hyperair: kill -1 $pid is using the builtin bash kill command
[20:14] <hyperair> well yes, but it acts like /bin/kill doesn't it?
[20:14] <hyperair> are there any differences?
[20:14] <hyperair> as in, behavioural differences
[20:14] <hyperair> if there aren't, then it shouldn't be a problem, should it?
[20:15] <mathiaz> hyperair: the problem is that the dash builtin kill command may be different from the bash builtin kill command
[20:15] <hyperair> it's different, but is there a difference in behaviour?
[20:15] <hyperair> i believe both are made to be compatible to /bin/kill
[20:15] <mathiaz> hyperair: if you run a script with #!/bin/sh you'll run with dash, not bash under a default ubuntu system
[20:16] <hyperair> it's standardized, no?
[20:16] <hyperair> i'm very well aware, you don't have to fill me in on those nitty gritty details
[20:16] <hyperair> i'm saying that dash's kill and bash's kill both are compatible to /bin/kill style arguments, so there is no point in going out of your way to not use the builtin
[20:17] <hyperair> or do you want to override all your echos with /bin/echo as well?
[20:17] <hyperair> and /bin/cat?
[20:17] <hyperair> no wait, cat doesn't have a builtin
[20:20] <mathiaz> hyperair: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396821
[20:20] <mathiaz> hyperair: https://wiki.ubuntu.com/DashAsBinSh - has a section about this
[20:21] <hyperair> so kill -[0-9] is a bashism? =\
[20:21] <hyperair> does it not work in dash?
[20:21] <mathiaz> hyperair: it may work - it's just not documented under dash
[20:21] <hyperair> bah.
[20:21] <Elbrus> If I upgrade a package in Debian with translation improvements, till when can it be merged for Karmic? (WinFF)
[20:22] <hyperair> i think it's a false alarm
[20:22] <hyperair> Elbrus: as soon as it gets ACCEPTed into debian, and as long as we aren't in a more major freeze than feature freeze
[20:23] <Elbrus> hyperair: thanks
[20:49] <zooko> Greetings, people of #ubuntu-motu!
[20:50] <zooko> I seek Ubuntu developers to serve as advocates to upload Tahoe-LAFS into Karmic.
[20:50] <zooko> Tahoe-LAFS is an open source secure cloud storage system.
[20:50] <zooko> We need two people willing to sign on as recommending it in order for it to be uploaded into Karmic.
[20:52] <zooko> If you are authorized to be an advocate for such a package, please write to zooko@zooko.com or join #tahoe on irc.freenode.net.  Thank you!
[21:00] <porthose> zooko, https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages, https://wiki.ubuntu.com/MOTU/Packages/REVU btw Feature Freeze is 27 August
[21:01]  * zooko reads.
[21:02] <jtimberman> mathiaz: for the log file deletion, /var/log/chef/something*, where something is the logfile name appropriate to the package (indexer, server, client)
[21:02] <jtimberman> correct?
[21:03] <zooko> porthose: okay, thanks.  I'll upload it to REVU.  Dustin Kirkland told me that I'll need two advocates eventually.
[21:03] <zooko> Actually I'll ask Brian Warner to upload it to REVU -- he is more expert at Debian packaging than I am.
[21:04] <porthose> :)
[21:04] <pochu> zooko: yes, you need two advocates in REVU, but you can get them (you usually do so) after you have uploaded the package there
[21:06] <porthose> zooko, FYI you will need a launchpad account if you don't have one already :)
[21:07] <iulian> zooko: Please let me know when the package is uploaded to revu.
[21:09] <zooko> porthose, julian: okay, thanks!
[21:09] <zooko> Brian is at a get-together/lunch event right now but I expect he'll upload it later today.
[21:12] <mathiaz> jtimberman: yes - the log files are already set correctly in the logrotate file
[21:12] <jtimberman> mathiaz: sorry, i mean the log file deletion in the postrm script.
[21:13] <mathiaz> jtimberman: yes - I meant that the pattern for each package is already set in the logrotate file
[21:13] <mathiaz> jtimberman: ie you know which log filenames should be deleted
[21:15] <jtimberman> yeah.
[21:42] <jtimberman> mathiaz: left a comment, too long to paste in irc :)
[21:44] <mathiaz> jtimberman: looks good
[21:45] <jtimberman> cool, uploading
[21:54] <jtimberman> mathiaz: thom advocated stompserver as well, early this morning with a note about uploading but i still see it in the advocated list.
[21:55] <mathiaz> jtimberman: https://launchpad.net/ubuntu/+source/stompserver/
[21:55] <mathiaz> jtimberman: ^^ that page exists - means that stompserver has been uploaded to the arhive
[21:55] <jtimberman> mathiaz: ah! thanks :)
[21:56] <mathiaz> jtimberman: it's in the NEW queue now - needing a source review of an Archive Admin
[21:56] <jtimberman> mathiaz: cool.
[22:10] <mathiaz> jtimberman: the chef-indexer init script stop action doesn't seem to work correclty
[22:10] <mathiaz> jtimberman: chef-indexer is not killed
[22:11] <jtimberman> Hmm.
[22:11] <jtimberman> checking
[22:12] <jtimberman> mathiaz: when running /etc/init.d/chef-indexer stop?
[22:12] <mathiaz> jtimberman: yes
[22:12] <mathiaz> jtimberman: the chef-indexer process is still around even though the init script reported a success
[22:12] <jtimberman> Hmm.
[22:14] <jtimberman> i'm not seeing that on my local karmic system.
[22:15] <mathiaz> jtimberman: let me double-check
[22:17] <jtimberman> http://paste.ubuntu.com/257160/
[22:17] <mathiaz> jtimberman: http://paste.ubuntu.com/257161/ - I have this error now
[22:18] <jtimberman> mathiaz: and if i purge the packages, it stops indexer.
[22:19] <jtimberman> looks like libstomp didn't get reinstalled, though i'm not sure why it would complain about rubygems.
[22:21] <mathiaz> jdstrand: http://paste.ubuntu.com/257163/
[22:21] <mathiaz> jtimberman: ^^
[22:21] <mathiaz> jdstrand: nevermind
[22:22] <jtimberman> mathiaz: libstomp-ruby isn't already installed is it?
[22:23] <mathiaz> jtimberman: nope - it's a brand new vm
[22:23] <jtimberman> hmm.
[22:23] <jtimberman> 'chef' depends on libstomp-ruby
[22:23] <mathiaz> jtimberman: hm - I've only installed chef-indexer
[22:23] <mathiaz> jtimberman: doesn't make sense to have chef-indexer without chef?
[22:24] <mathiaz> jtimberman: installing libstomp-ruby list erubis as the next missing dep
[22:24] <jtimberman> 'erubis' or liberubis-ruby?
[22:24] <mathiaz> jtimberman: http://paste.ubuntu.com/257164/
[22:25] <mathiaz> jtimberman: installing liberubis-ruby fixes the issue
[22:25] <mathiaz> jtimberman: and chef-indexer starts correclty
[22:27] <jtimberman> updated the depends for libchef-ruby
[22:27] <jtimberman> argh, merb rejected due to no LICENSE file :/
[22:28] <mathiaz> jtimberman: in the upstream tarball?
[22:28] <jtimberman> guess so
[22:28] <jtimberman> rather, its empty
[22:29] <jtimberman> and there's object files in the source tarball.
[22:29] <jtimberman> part of the webrat spec testing, which isn't in the resulting packages
[22:39] <jtimberman> mathiaz: stompserver rejected too :( - the stompserver user is added during postinst but is not removed on purge
[22:39] <jtimberman> in postrm.
[22:40] <mathiaz> jdstrand: are you reviewing this?^
[22:40] <jdstrand> yeah
[22:40] <jtimberman> oh! hi jdstrand :)
[22:40] <mathiaz> jdstrand: for the user not being removed on purged, I discussed that with slangasek yesterday
[22:40] <jdstrand> o/
[22:40] <mathiaz> jdstrand: and he (and liw) said that it was better to not remove the user
[22:41] <jdstrand> why?
[22:41] <mathiaz> jdstrand: http://irclogs.ubuntu.com/2009/08/20/%23ubuntu-devel.html
[22:41] <mathiaz> jdstrand: 16:34
[22:45] <mathiaz> jtimberman: found issue with /usr/bin/chef-i
[22:46] <mathiaz> jtimberman: found the issue with chef-indexer
[22:46] <mathiaz> jtimberman: the shebang line is /usr/bin/env ruby
[22:46] <mathiaz> jtimberman: that seems to break the init script
[22:46] <jtimberman> mathiaz: ahh.
[22:46] <mathiaz> jtimberman: changing it to /usr/bin/ruby1.8 works
[22:47] <jtimberman> mathiaz: as in s/env ruby/ruby1.8/ ?
[22:47] <mathiaz> jtimberman: yes
[22:47] <jtimberman> jdstrand: stompserver license information is in the readme.txt (/usr/share/doc/stompserver/README.txt.gz)
[22:48] <mathiaz> jtimberman: you probably wanna drop a line about this in the debian/copyright
[22:48] <jdstrand> mathiaz: I'm not sure I agree with that. that uid isn't going to be the same across systems, so the NFS concern is too conservative. plus at worst you end up with some uid's that don't map to a username. imo, it's cleaner to remove it
[22:48] <jdstrand> that said, if you actively decided against remove it, that is different than forgeting to, and I won't block on it
[22:49] <mathiaz> jdstrand: could uid be recycled?
[22:49] <jdstrand> mathiaz: if it is removed? sure
[22:49] <jtimberman> mathiaz: adding under stompserver's debian/copyright, License section: From README.txt (/usr/share/doc/stompserver/README.txt.gz).. MIT License..etc
[22:49] <mathiaz> jdstrand: so one could end up with a uid reused for two system users
[22:50] <mathiaz> jdstrand: whith the latter having access to files from the former
[22:50] <jdstrand> jtimberman: that would be much clearer-- normally one looks for a LICENSE or COPYING file, so if it is in a different place, just mention it in debian/copyright
[22:50] <jtimberman> fwiw, chef-indexer isn't likely to be installed on more than one system in a particular network, its pretty specific with the chef-server.
[22:50] <jtimberman> jdstrand: will do.
[22:51] <jdstrand> mathiaz: if the concern is regarding NFS, you already have that problem because it is a dynamically allocated uid. that uid might be allocated differently on another client
[22:51] <mathiaz> jdstrand: I agree with the remote uid issue
[22:52] <jtimberman> oh you're not talking about indexer - stompserver.
[22:52] <jdstrand> mathiaz: why is it creating files all over the place so they can't be cleanly removed on purge anyway?
[22:52] <mathiaz> jdstrand: you mean things in /var/lib/stompserver for example?
[22:53] <jdstrand> mathiaz: anyway, like I said, if you actively omitted it from postrm, then I won't block on it
[22:53] <jdstrand> we are in the realm of opinion here, I don't think policy has anything to say on it
[22:53] <mathiaz> jdstrand: cool. Thanks - it was discussed.
[22:53] <mathiaz> jdstrand: yop - it's a grey area.
[22:54] <jtimberman> jdstrand: for merb's license, can i add a similar line to debian/copyright to point at the LICENSE file as installed in one of the packages?
[22:54] <jdstrand> mathiaz: yeah, /var/lib/stompserver should be cleaned automatically or at least the user notified that it is not. if the former, removing the user makes sense, if not, then leaving the user makes sense
[22:55] <jdstrand> jtimberman: merb had a blank LICENSE file correct? why not just add something to that?
[22:55] <jdstrand> jtimberman: either that or explain what you mean by 'installed in one of the packages'
[22:56] <jtimberman> jdstrand: i don't think the blank LICENSE file is put anywhere in the packaging, is it?
[22:56] <mathiaz> jdstrand: I asked about that too
[22:57] <mathiaz> jdstrand: 16:42
[22:57] <jdstrand> mathiaz: yes, I saw that. it all depends on what the package does
[22:58] <jdstrand> mathiaz: another gray area where one needs to decide
[22:58] <mathiaz> jdstrand: yes - stompserver is a message server. messages are stored in /var/lib/stompserver IIUC
[22:58] <jdstrand> mathiaz: for example, I don't leave firewall file around on purge in ufw (purge is purge afterall)
[22:59] <jdstrand> mathiaz: but, it would be disappointing to see my mysql blown away so easily
[22:59] <mathiaz> jdstrand: well purge is remove configuration files
[22:59] <mathiaz> jdstrand: it doesn't say about user generated data that cannot be recreated easily
[22:59] <jdstrand> mathiaz: that was basically my point
[23:00] <mathiaz> jdstrand: right - slapd asks whether you wanna delete your database on package purging.
[23:00] <jdstrand> mathiaz: the packager decides, and depending on what decisions are made, it might influence other decisions, like removing the system user
[23:00]  * mathiaz nods
[23:00]  * jdstrand nods
[23:00] <jdstrand> :)
[23:00]  * jtimberman nods
[23:00]  * jtimberman nods off.
[23:00] <jtimberman> :D
[23:00]  * mathiaz waves
[23:01] <mathiaz> jdstrand: so for stompserver: don't delete user data and keep the system user around - is that a satisfactory combination?
[23:01] <jdstrand> jtimberman: LICENSE is blank in the merb_1.0.12-0ubuntu1 source
[23:01] <jdstrand> jtimberman: that is confusing to say the least
[23:02] <mathiaz> jtimberman: does it make sense to have chef-server running *without* chef-indexer?
[23:02] <jtimberman> mathiaz: no, indexer is part of the reason to run a chef-server in the first place
[23:02] <jdstrand> jtimberman: merb has a lot of subdirs, and pointing to one of them in debian/copyright doesn't feel right. why does merb-core's licensing have anything to do with merb-slices?
[23:02] <jtimberman> mathiaz: the chef-indexer program is actually shipped with the chef-server gem in our gem distribution method
[23:02] <jdstrand> (rhetorical question)
[23:02] <jdstrand> jtimberman: the cleanest thing is to put something in LICENSE imho
[23:03] <jtimberman> jdstrand: whats the best way to handle that? add it to the source dir i'm running dpkg-buildpackage from, patch via quilt, or put in the orig.tar.gz?
[23:03] <jtimberman> I'm fine with putting something in the top-level LICENSE file and since its MIT, that's okay :)
[23:04] <jdstrand> mathiaz: re stompserver> it makes sense to me. like I said, I just wanted to make sure it was thought about. leaving cruft like uid's for no good reason is annoying :)
[23:04] <jdstrand> jtimberman: orig.tar.gz
[23:04] <jdstrand> jtimberman: if it is done in packaging it really isn't all that different from mentioning it in debian/copyright
[23:05] <jdstrand> jtimberman: so having the upstream source include it is best
[23:05] <mathiaz> jdstrand: ok - thanks the feedback.
[23:05] <mathiaz> jdstrand: was this the only reason for rejecting stompserver?
[23:05] <jdstrand> mathiaz: no, it was the license file
[23:06] <jdstrand> mathiaz: I would have accepted it, but questioned the uid otherwise
[23:06] <jdstrand> (policy doesn't speak to this issue, and it's gray, so I wouldn't block on it)
[23:07] <mathiaz> jdstrand: ok. I'll sponsor a new version of stompserver once jtimberman uploads a new version.
[23:07] <jtimberman> jdstrand: stompserver uploaded with the note in debian/copyright about location of the MIT license being the README.txt.
[23:07] <jtimberman> mathiaz: uploaded :)
[23:07] <mathiaz> jtimberman: to REVU?
[23:07] <jtimberman> yes
[23:08] <jtimberman> mathiaz: like just finished when i sent that.. should be on a few minutes
[23:11] <jtimberman> merb uploaded as well
[23:20] <mathiaz> jtimberman: did you remove the object files from merb .orig.tar.gz?
[23:23] <mathiaz> jtimberman: and since you're repacking the orig.tar.gz I'd mention it in the changelog.
[23:23] <mathiaz> jtimberman: The reasons for differing tarballs must be in debian/changelog
[23:25] <jtimberman> mathiaz: where in the policy is that, so i can reference it in the changelog
[23:25] <mathiaz> jtimberman: https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews#Tips
[23:26] <mathiaz> jtimberman: I don't where in the Policy it's written though.
[23:26] <mathiaz> jtimberman: mention that the upstream LICENSE file is empty and was replaced with the License and that object files have been removed.
[23:27] <mathiaz> jtimberman: from the upstream tarball.
[23:38] <jtimberman> mathiaz: that look okay for changelog: http://paste.ubuntu.com/257188/
[23:40] <mathiaz> jtimberman: http://paste.ubuntu.com/257191/
[23:41] <mathiaz> jtimberman: s/remove/removed/
[23:42] <mathiaz> jtimberman: http://paste.ubuntu.com/257193/
[23:42] <jtimberman> mathiaz: ok, rebuilding and uploading in a minute
[23:51] <jtimberman> merb uploaded
[23:52] <RoAkSoAx> requestsync is not working right guys?
[23:54] <Laney> ScottK: I don't know. We're looking into this on the Debian side too but it's looking unlinkely for 6.10.4 :(
[23:54] <ScottK> Laney: So what's the plan in Debian?  AFAIK you can't get to testing without IA64.
[23:55] <Laney> Right, testing migration is blocked and may have to stay so
[23:55] <Laney> I don't know of the details but I think there's some upstream issue here
[23:56] <jtimberman> mathiaz: jdstrand: stompserver and merb uploaded back to REVU w/ the fixes discussed.
[23:58] <Laney> ScottK: I'm planning on kicking off a thread on debian-haskell about this, but the outcome is likely to be "wait for upstream", sadly
[23:58] <jtimberman> mathiaz: chef-indexer init script seems to be doing the right thing for me.
[23:59] <ScottK> Laney: Ouch.