[02:48] <cyberixae> packages.ubuntu.com is down
[02:48] <cyberixae> Should someone be notified to kick the server?
[02:50] <ScottK> cyberixae: It's hosted in the Canonical data center, so probably #canonical-sysadmin
[02:59] <cyberixae> The admins are working on it
[06:15] <fabrice_sp> Good morning! A small question: is it still possible to request a sync for a main package? Or main is frozen?
[06:17] <StevenK> fabrice_sp: Sure it is
[06:18] <StevenK> Debian Import Freeze just means we aren't doing it automatically
[06:18] <fabrice_sp> StevenK, so FeatureFreeze is when main is also frozen?
[06:19] <fabrice_sp> I thought main was frozen before universe...
[06:32] <StevenK> fabrice_sp: We aren't past Feature Freeze yet?
[06:34] <fabrice_sp> StevenK, according to the Release Schedule (https://wiki.ubuntu.com/KarmicReleaseSchedule), Feature Freeze is suppose to happen on the 27th of August. Or there is something I understand wrongly?
[06:34] <StevenK> fabrice_sp: And you were asking about syncing a package in main now?
[06:34]  * StevenK is evidently missing something
[06:36] <fabrice_sp> StevenK, I thought that Feature Freeze was only for Universe and that main was frozen before (at DIF time)
[06:37] <StevenK> fabrice_sp: No, that isn't right
[06:37] <fabrice_sp> that's why I was asking if it still possible to ask for a sync in main
[06:37] <fabrice_sp> now, I know ;-)
[06:37] <fabrice_sp> thanks for your answer
[06:37] <fabrice_sp> s
[07:06] <dholbach> good morning
[07:18] <fabrice_sp> good morning dholbach :-)
[07:18] <dholbach> hey fabrice_sp
[07:30] <\sh> moins
[07:37] <micahg> hi \sh
[08:24] <quadrispro> jdstrand: hi Jamie!
[08:26] <quadrispro> jdstrand: I'm reading your email about h264enc, I used debhelper 7 and the .PHONY line is unnecessary :) (what lintian version are you using? lintian didn't give me any error message)
[08:28] <POX> ScottK: FTR: DH_PYCENTRAL=nomove should be used in very rare cases and adding it after merging a package is very bad idea
[08:45] <slytherin> Laney: You worked on backporting the yahoo protocol change to pidgin, right?
[08:47] <sn9> well, that won't be in dapper now...
[08:47] <sn9> or hardy
[09:03] <siretart> revu is going down for maintenance!
[09:17] <qiyong> pastebin
[09:17] <qiyong> !pastebin
[09:20] <slytherin> sn9: Why not hardy? Hardy is the last LTS, what the are users running hardy supposed to do?
[09:31] <siretart> revu back on-line
[09:34] <slytherin> mr_spot_: ping
[09:34] <mr_spot_> pong
[09:38] <mr_spot_> slytherin, have you got more advice on my package in revu?
[09:39] <slytherin> mr_spot_: I was wondering how it is different than the official mixer applet. I didn't see any screenshots on home page.
[09:41] <mr_spot_> ocau.com/pix/hobk5
[09:42] <slytherin> mr_spot_: looks similar (to me) to the official one. Does it have any advantages over official gnome mixer applet?
[09:43] <Daviey> Hi, Does someone fancy sponsering an SRU upload to -proposed for Hardy for me? :)
[09:43] <Daviey> (You know you want to, go-an)
[09:43] <Daviey> bug #394696
[09:43] <mr_spot_> slytherin, you mean the one named "Volume Control" in the add to panel dialog?
[09:44] <mr_spot_> slytherin, or is there another gnome volume applet that i don't know about?
[09:45] <slytherin> mr_spot_: in jaunty - gnome-volume-control-pulse
[09:45] <slytherin> That is the package name
[09:47] <mr_spot_> slytherin, just to confirm, the one that puts a speaker icon in the notification area? that one simply shows me a single volume slider
[09:48] <slytherin> mr_spot_: Yes, you are talking about the one installed by default. The package I mentioned is in universe, not installed by default. That package contains another volume control applet which uses pulseaudio. Try it yourself and you will know.
[09:49] <slytherin> mr_spot_: And you have to right click on it and then 'Open Volume COntrol'.
[09:51] <Laney> slytherin: I gave up on hardy
[09:52] <Laney> i was going to -backports it but didn't get round to it yet
[09:53] <mr_spot_> slytherin, http://paste.ubuntu.com/216773/ is what i just had a look at, the gnome-volume-control-applet binary in the package is the one i ran that gave me the notification icon.
[09:54] <slytherin> Laney: Putting my users hat, In my opinion the fix should get backported to hardy.
[09:54] <slytherin> mr_spot_: did you logout and login after you installed the package? :-)
[09:54] <mr_spot_> it was already installed
[09:55] <Laney> slytherin: Yes, it should. But I couldn't get it to work
[09:55] <Laney> they completely rewrote the authentication method
[09:56] <mr_spot_> slytherin, mtime on the .deb in my apt archive dir is jul 1, and i have logged in and out many times since then :)
[09:57] <mr_spot_> slytherin, can you show me a screenshot of what you think i should be seeing?
[10:00] <slytherin> mr_spot_: I don't have access to a jaunty system right now. :-(
[10:02] <mr_spot_> slytherin, well the main point is that with my applet, adjusting application volume, moving applications to different devices, etc can all be done with a single click on the applet, without launching a separate mixer
[10:02] <mr_spot_> slytherin, it was a result of getting annoyed by having to launch pavucontrol just for a simple adjustment so frequently
[10:03] <mr_spot_> slytherin, it also has recording similarly accessible from a single click on the panel
[10:03] <slytherin> mr_spot_: I can understand. But as I said, it does not offer any advantage over the official applet which can also use pulseaudio to do all the things you mentioned.
[10:09] <Laney> Daviey: you need motu-sru ack. Ping me when youi get it and I'll upload if you like
[10:20] <Daviey> Laney: You know motu-sru is *three* people?
[10:21] <Laney> yes
[10:21] <Laney> :(
[10:21] <Daviey> :((
[10:23] <Laney> well you could hassle an ubuntu-sru person if you dare ;)
[10:23] <Daviey> Laney: Well i can never say no to a dare!
[10:24] <therm> Hi@all
[10:26] <therm> someone out there likes reviewing my packages? http://revu.ubuntuwire.com/p/h2database http://revu.ubuntuwire.com/p/willuhnutil http://revu.ubuntuwire.com/p/willuhndatasource http://revu.ubuntuwire.com/p/swtcalendar (advocated on time)
[11:09] <pochu> ouch, 2MB email on the list :/
[11:50] <dholbach> pochu: sorry, I didn't realise when I was moderating it through
[12:24] <pochu> dholbach: it's ok for me, I didn't have to pay for the extra bandwith :)
[12:24] <pochu> it's just that I seem to hit a thunderbird bug or something that makes loading big emails take a lot of time
[12:24] <pochu> asac: ^ have you heard about such a problem with tb?
[12:27] <asac> pochu: a regression? otherwise i wouldnt be shocked
[12:28] <asac> pochu: you could verify whether its still a problem with tbird 3 dailies: https://edge.launchpad.net/~ubuntu-mozilla-daily/+archive/ppa ... its safe to use them because it copies your profile (e.g. no data loss ;))
[12:28] <asac> anyone has seen norsetto?
[12:28] <ScottK> He seems rarely on IRC anymore.
[12:28] <asac> yeah ok. i will write him a mail then.
[12:29] <asac> just wondered if anyone knows anything
[12:31] <pochu> asac: he's blogged something recently, but haven't seen here around
[12:31] <pochu> asac: no regression, it's happening for a really long time :) I'll try with TB3, thanks
[12:34] <asac> pochu: let me know. if its still a problem with tb3 we should file a bug (at least i can make upstream look at tb3 bugs)
[12:35] <pochu> cool
[12:35] <pochu> asac: btw I don't know if I'll do the liferea merge... don't have a karmic system around and am somewhat busy these days
[12:35] <pochu> should be easy though if you drop the hildon patch
[12:35] <asac> pochu: is that merge a "webkit" merge?
[12:35] <pochu> yes
[12:36] <asac> pochu: is webkit alternative or only rendering engine in thereß
[12:36] <pochu> as in, 1.4 still uses xulrunner, and 1.6 (to be merged) uses webkit
[12:36] <asac> pochu: is there anything we want to keep?
[12:36] <pochu> the only one
[12:36] <asac> patches?
[12:36] <asac> (besides hildon)
[12:36] <pochu> asac: the ubuntu_feedlists patch, I guess :)
[12:36] <asac> ah right
[12:36] <asac> ok cool. i will check that out then
[12:37] <pochu> thanks :)
[12:37] <pochu> hmm
[12:37] <asac> thanks for the heads up
[12:37] <pochu> I think there was one patch about focus or something
[12:37] <pochu> if you switch to another workspace and click on the tray icon, liferea doesn't show up
[12:37] <pochu> that's not integrated upstream, I should look into that
[12:37] <asac> oh shit
[12:38] <pochu> it was a one liner IIRC
[12:38] <asac> pochu: so this package doesnt have a patch system? i have bunch of merge conflicts in normal files
[12:38] <pochu> asac: it uses quilt
[12:38] <asac> http://paste.ubuntu.com/216869/
[12:38] <pochu> huh, looks weird?
[12:39] <pochu> those files are touched by the xulrunner patch I think
[12:39] <asac> well.  there wont be conflicts if changes would have been in the patches
[12:39] <pochu> (autogenerated files after running autoreconf)
[12:39] <asac> yeah. but that should go to a patch too :)
[12:39] <pochu> it should be using a patch system for sure
[12:39] <ScottK> asac: I see those every now and then.  IME it generally means merge-o-matic has gone insane.
[12:39] <asac> xslt?
[12:39] <pochu> yeah indeed :/
[12:39] <asac> hmm
[12:40] <asac> even a conflict in AUTHORS ;)
[12:40] <pochu> lol
[12:40] <pochu> that is *not* autogenerated =)
[12:41] <asac> i guess this means i am going to lunch now ;)
[12:52] <hhb> hi all
[12:53] <hhb> is there an easy way to make a custom version of an ubuntu package?
[12:54] <hhb> i don't have any packaging background, but i'd like to set up my own ppa with a nautilus binary based on my own branch
[12:55] <hhb> i read through the packaging guide, but that's mostly creating own packages, which seems to be a cumbersome process
[12:55] <pochu> apt-get source $package; add a patch in debian/patches; dpkg-buildpackage -S -sa; dput to launchpad
[12:55] <pochu> briefly that's it :)
[12:56] <hhb> how does one "add a patch in debian/patches" ?
[12:56] <hhb> just copy the diff in there?
[12:56] <pochu> yes
[12:56] <pochu> you may need to edit debian/patches/00list or debian/patches/series though
[12:57] <pochu> and that's if there already is a patch system for that package
[12:57] <pochu> !patches
[12:57] <hhb> ah, okay
[12:57] <hhb> that doesn't sound too hard :-)
[12:57] <hhb> thanks
[12:58] <pochu> hhb: if you get into trouble, see https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[12:58] <VK7HSE> me-tv-0.9.6+rev529.tar.gz     watch file uses https://launchpad.net/me-tv/+download http.*me-tv-(\d+\.\d+\.\d+\+rev\d*)\.tar\.gz   is this correct ???
[12:59] <VK7HSE> my question is to to format the watch file is using...
[12:59] <hhb> pochu: awesome, thanks. that'll hopefully get me started :-)
[12:59] <pochu> hhb: yeah, if you still have problems, feel free to ask here :)
[12:59] <pochu> VK7HSE: can you rephrase the question?
[12:59] <VK7HSE> ok...
[13:00] <VK7HSE> right the source tar.gz is in the following format   me-tv-0.9.6+rev529.tar.gz
[13:00] <VK7HSE> and the watch file has been set (by me) to use  https://launchpad.net/me-tv/+download http.*me-tv-(\d+\.\d+\.\d+\+rev\d*)\.tar\.gz
[13:00] <VK7HSE> but...
[13:00] <VK7HSE> it reports back saying...
[13:01] <VK7HSE> uupdate: new version number not recognized from given filename
[13:01] <VK7HSE> Please run uupdate with the -v option
[13:01] <pochu> so run it with -v and check what's going on :)
[13:04] <VK7HSE> well to over ride the watch file I would issue... uupdate -v 0.9.6+rev529 me-tv_0.9.6+rev529.tar.gz   now that works... but there's still an issue with the watch file (this is what I'm trying to sort out!)
[13:05] <slytherin> VK7HSE: what is that http.* in the watch file?
[13:05] <pochu> slytherin: it needs to find a link in that page
[13:05] <VK7HSE> the source is hosted on launchpad..
[13:05] <pochu> so that's "http(some url)/filename.tar.gz"
[13:06] <VK7HSE> I've not uploaded this just yet as I want to sort this watch file issue!
[13:07] <pochu> I get this
[13:07] <pochu>    https://launchpad.net/me-tv/+download http.*me-tv-(\d+\.\d+\.\d+\+rev\d*)\.tar\.gz
[13:07] <pochu> uscan warning: In debian/watch,
[13:07] <slytherin> ahh, didn't know launchpad needed special handling
[13:07] <VK7HSE> even if I shorten it to just ...   https://launchpad.net/me-tv/+download http.*me-tv-(.*)\.tar\.gz  it sill doesn't like it :(
[13:07] <pochu>   no matching hrefs for watch line
[13:08] <slytherin> asac: When is xulrunner-dev likely to depend on xulrunner-1.9.1-dev? Accordingly I will have to change build-deps/deps while merging swt-gtk.
[13:08] <VK7HSE> I altered the watch file in the last beta I built... but this is the first source code to use that format!  (+revxxx)
[13:09] <pochu> VK7HSE: this one works:
[13:09] <pochu> https://launchpad.net/me-tv/+download http://launchpad.net/me-tv/.*/\+download/me-tv-(.+)\.tar\.gz
[13:10] <pochu> VK7HSE: there's no "rev" tarball there, it's normal it doesn't work...
[13:11] <VK7HSE> realise the lack of source tarball! I was testing it locally!
[13:12] <VK7HSE> but you say that the above is what it "should" resolve to?
[13:12] <VK7HSE> hang on I'll upload the source... and test again... if I still have any issues I'll come bak :)
[13:13] <therm> someone out there likes reviewing my packages? http://revu.ubuntuwire.com/p/h2database http://revu.ubuntuwire.com/p/willuhnutil http://revu.ubuntuwire.com/p/willuhndatasource http://revu.ubuntuwire.com/p/swtcalendar (advocated on time)
[13:13] <asac> slytherin: why do you want to change the build-depends when merging?
[13:14] <asac> slytherin: i am preparing the porting stuff here: https://edge.launchpad.net/~mozillateam/+archive/ffox35
[13:14] <asac> slytherin: it already has -dev package there
[13:14] <slytherin> asac: the build depends currently is xulrunner-dev which pulls in xulrunner-1.9-dev.
[13:15] <asac> slytherin: yes, thats good.
[13:15] <asac> slytherin: keep it that way
[13:16] <asac> as soon as xulrunner-dev is in we can just reupload
[13:16] <asac> slytherin: the respin worked in the ppa, so i dont expect any problems
[13:17] <slytherin> asac: Ok. I will do merge as it is then and will only do a rebuild later.
[13:18] <asac> slytherin: yeah thats good
[13:19] <asac> slytherin: i will probably upload all after i uploaded xulrunner-dev
[13:19] <bluekuja> asac, gonna use the "." instead of "+"
[13:19] <asac> bluekuja: if that works ;)
[13:19] <bluekuja> asac, let me see
[13:19] <asac> bluekuja: verify with --compare-versions
[13:19] <asac> ;)
[13:19] <asac> and yes, - in the upstream version is a mess. on next chance try to get rid of that
[13:20] <asac> e.g. when upstream goes to 1.3.4
[13:20] <asac> err 1.3.5-...
[13:20] <bluekuja> asac, 1 lt 2 --> yes 2 lt 1 --> nothing
[13:20] <asac> yes. lt means less than
[13:20] <bluekuja> asac, so "." works
[13:21] <asac> yeah
[13:21] <bluekuja> asac, updating branch
[13:21] <asac> bluekuja: good. please also do the .bzr-builddeb/default.conf while you are at it
[13:21] <bluekuja> asac, k
[13:21] <asac> bluekuja: and uncommit the stuff from the upstream branch ;)
[13:21] <asac> nice
[13:22] <asac> slytherin: is swt-gtk used by eclipse?
[13:22] <asac> or does eclipse package use its own in-source copy?
[13:22] <bluekuja> asac, yep
[13:24] <slytherin> asac: I am not sure. I haven't taken look at eclipse packaging.
[13:24] <asac> slytherin: ok. thought it was related enough that you might know something ;)
[13:25] <asac> was worth a try
[13:25] <slytherin> asac: eclipse was recently updated by doko. You may want to ask him.
[13:26] <asac> it was updated?
[13:26] <jdstrand> quadrispro: hi, so I used an older version of lintian, and I realize that the package may build without it, but section 4.9 of the Debian Policy states "Both the binary-arch and binary-indep targets must exist. If one of them has nothing to do (which will always be the case if the source generates only a single binary package, whether architecture-dependent or not), it must still exist and must always succeed." http://www.debian.org/doc/debian
[13:26] <asac> bug 285486
[13:26] <asac> !info eclipse
[13:26] <asac> no bot in this channel?
[13:26] <asac> ah
[13:27] <asac> heh it failed everywhere
[13:27] <slytherin> asac: right, it is FTBFS
[13:28] <bluekuja> asac, what was the command for revid?
[13:28] <asac> bluekuja: bzr log --show-ids
[13:28] <bluekuja> ty
[13:29] <VK7HSE> back again!
[13:29] <VK7HSE> here is my source ... http://launchpad.net/me-tv/stable/0.9/+download/me-tv-0.9.6%2Brev529.tar.gz
[13:30] <bluekuja> asac, done
[13:30] <bluekuja> asac, have to leave, bbl, write me a mail when done
[13:31] <bluekuja> asac, as revid I used rev3 ID
[13:31] <bluekuja> asac, into upstream.source branch of course
[13:31] <asac> bluekuja: thats wrong
[13:31] <asac> ah
[13:31] <asac> yeah
[13:31] <asac> thought you used "3"
[13:31] <asac> if its the long id its ok
[13:31] <bluekuja> asac, yes, used the long id of the rev3
[13:32] <bluekuja> (upstream.source)
[13:32] <bluekuja> the one for upload
[13:32] <bluekuja> asac, write me a mail
[13:32] <bluekuja> bbl
[13:39] <asac> pochu: they added a bunch of debian rss feeds; i guess we want to replace them?
[13:40] <pochu> asac: Debian or upstream ones?
[13:41] <asac> pochu: debian example feeds
[13:41] <quadrispro> jdstrand: yes, but.. it uses DH7, you could find a template in /usr/share/doc/debhelper/examples/rules.tiny
[13:41] <pochu> asac: I don't mind :)
[13:42] <quadrispro> and as you can see, there's no PHONY line :)
[13:42] <asac> pochu: i keep the "debian package a day"
[13:42] <asac> but drop debian planet, debian times, etc.
[13:42] <pochu> asac: that's in planet ubuntu anyway
[13:42] <pochu> asac: so you could just disable it from series
[13:44] <jdstrand> quadrispro: I'm not arguing that it doesn't build. I'm saying that regardless of what dh does, it isn't policy compliant.
[13:48] <DktrKranz> jdstrand: dh7 runs binary-* itself in its sequences, so it should be fine even if build-{binary,arch}: is not mentioned
[13:50] <maxb> quadrispro: I was wondering about that.... should we still aim to use a .PHONY in dh7 packages for strict correctness?
[13:50] <jdstrand> I would argue yes, until policy is updated with an exception
[13:51] <jdstrand> otherwise it causes confusion, like this
[13:51] <quadrispro> maxb: IMHO we don't, newer lintian doesn't give any warning
[13:51] <maxb> I guess it's a sufficiently tiny corner case that it's really not worth the clutter
[13:52] <jdstrand> lintian is just a tool to help identify violations of policy and other errors
[13:52] <jdstrand> but it is not policy
[13:53] <DktrKranz> it's not about policy, it's about lintian unability to parse dh7 internals. dh7 always executes binary-*, unless you manually override it
[13:53] <quadrispro> jdstrand: I've found this http://www.debian-administration.org/users/dkg/weblog/31
[13:54] <DktrKranz> e.g. by declaring no-op binary-*: target
[13:54] <jdstrand> quadrispro: I'm familiar with dh7 and 'dh $@'
[13:55] <jdstrand> I also understand that it does build
[13:55] <jdstrand> and lintian can be made to detect dh7 type stuff. that is fine
[13:55] <jdstrand> however, to me, it is about policy, because policy atm clearly states it is required
[13:57] <jdstrand> if an exception clause can be made to policy stating that it isn't required (and it seems it should indeed do just this), then it would be ok, IMHO
[13:57] <ScottK> jdstrand: It's required, but not necessarily explicitly.  Lots of CDBS packages don't mention it in rules.  It's not clear to me this is different?
[13:58] <jdstrand> I don't think it is different. perhaps they are wrong too?
[13:58] <jdstrand> *shrug*
[13:59] <ScottK> My view has been they need to exist and be called, not that they must exist in a file called debian/rules.
[13:59] <ScottK> Dunno.
[13:59] <jdstrand> well, they don't need to be called-- eg, binary-arch for _all packages
[13:59] <DktrKranz> jdstrand: it's not explicitly declared in rules, but dh expand "%:" to call it at runtime, that way policy is respected.
[14:00] <DktrKranz> and, if there are cases where one of binary-{arch,indep} must not be invoked, they can be bypassed easily
[14:02] <jdstrand> my point is this: policy says one thing, dh is doing something else via magic. if I say "ok, fine, do it" it will only come up again some time in the future and this same conversation will come up. A bug should be made against policy to allow this
[14:02]  * DktrKranz believes something has been filed already
[14:03] <jdstrand> that said, I am not the judge and jury of this issue. While I feel strongly it needs a .PHONY line, another AA may not
[14:04] <jdstrand> but just shoving this through will not help anyone done the line
[14:04] <jdstrand> s/done/down/
[14:05] <quadrispro> ehm... what I have to do with h264enc? can i re-upload it to the NEW queue without any change? or.. what??
[14:05] <jdstrand> how is adding a .PHONY line wrong?
[14:06] <jdstrand> it is policy compliant, clear, and will build
[14:06] <jdstrand> I would happily process it with that line
[14:07] <geser> jdstrand: Hi, re the python-repoze.who-plugins rejection: debian/copyright has a stanza for repoze.who.plugins.ldap-1.0 being licenced as GPL-3+. And I assume the URL for the licence text of the other modules at the beginning of the other modules isn't sufficient, right?
[14:08] <jdstrand> geser: the license text at the beginning of (all of?) the other modules states LICENSE is included in the source. there is no LICENSE file
[14:08] <jdstrand> (other than the aforementioned GPL3 one)
[14:09] <geser> jdstrand: http://packages.debian.org/changelogs/pool/main/p/python-repoze.who-plugins/current/copyright The second paragraph has an url to http://www.repoze.org/LICENSE.txt which is later referenced as "BSD-repoze"
[14:10] <geser> so I should talk to the debian maintainer to get a copy of the file into the .orig.tar.gz?
[14:14] <jdstrand> geser: yes. eg in friendlyform.py: "A copy of the license should accompany
[14:14] <jdstrand> # this distribution
[14:14] <jdstrand> "
[14:14] <jdstrand> geser: this is likely going to come up when Debian reviews it as well
[14:15] <asac> pochu: ok i sync-merged picking the few changes we had manually. uploaded
[14:15] <geser> jdstrand: it's already in Debian experimental.
[14:16] <ScottK> geser: It does have to include a full copy of the license in the tarball.
[14:16] <jdstrand> geser: yeah, but does experimental go through the same review as the main archive? (I don't know)
[14:16] <jdstrand> regardless, you need the license
[14:16] <geser> jdstrand: what is missing for the ldap module? it looks correctly mentioned in the copyright file to me
[14:16] <ScottK> In theory it does, in practice it seems not always.
[14:16] <jdstrand> geser: iirc nothing
[14:17] <jdstrand> geser: I was simply stating that there was only one license file included in the tarball, and it was gpl3 for ldap
[14:17] <geser> jdstrand: will mail the DD about the missing licence text then only. thanks
[14:18] <geser> jdstrand: ah, I misunderstood your mail then
[14:18] <jdstrand> geser: sorry for the confusion
[14:27] <geser> jdstrand: one copy of the license text in the .orig.tar.gz would be enough or better place it in every module directory?
[14:31] <quadrispro> jdstrand: http://home.alessiotreglia.com/karmic/pool/h264enc_8.9.3+dfsg-0ubuntu1/h264enc_8.9.3+dfsg-0ubuntu1.buildlog
[14:31] <quadrispro> that's the PHONY line I use:
[14:31] <quadrispro> ".PHONY: build clean binary-indep binary-arch binary install"
[14:32] <quadrispro> debian/rules -> http://paste.ubuntu.com/216934/
[14:32] <quadrispro> in this way, I can't use DH7
[14:35] <huats> iulian: ping
[14:35] <huats> are you around ?
[14:36] <sebner> quadrispro: you only need get-orig-source in the .PHONY line
[14:37] <jdstrand> binary-arch should be there
[14:37] <jdstrand> in .PHONY
[14:38] <sebner> jdstrand: dunno, for cli not ^^
[14:38] <jdstrand> it is a shell script
[14:38] <jdstrand> meh
[14:39] <jdstrand> this is what I'm saying-- policy says one thing, debhelper is doing magical other things
[14:52] <jdstrand> quadrispro: '.PHONY: binary-indep' works. I fully realize that build, binary-arch, binary and install are not present, and according to policy should be. .PHONY seems to disable debhelper's special magic for any targets listed in .PHONY. as such, dh7 cannot be done in a policy-compliant was, afaict. this is unfortunate and clearly a bug in debhelper, debian-policy or both
[14:54] <jdstrand> quadrispro: I was not aware of this situation, which was frankly my point-- we (you, me, archive admins in Debian and Ubuntu) shouldn't have to know that there is an undocumented exception for debhelper
[14:54] <james_w> jdstrand: I think that it could just be in the reading of policy
[14:55] <jdstrand> james_w: possibly
[14:55] <james_w> "required" probably means "known to make if you execute the file"
[14:55] <mr_spot_> can i get someone to review pulseaudio-mixer-applet again? i also have a question about copyright in a comment on my new upload. http://revu.ubuntuwire.com/p/pulseaudio-mixer-applet
[14:55] <james_w> which they definitely are
[14:56] <james_w> and "%:" means that every target will be present
[14:56] <jdstrand> james_w: yes, pragmatically speaking
[14:56] <james_w> it's silly that lintian complains if that is the case
[14:57] <jdstrand> james_w: it's silly we must infer 'known to make if you execute the file' from policy that simply says 'must' and 'required'
[14:57] <james_w> it's certainly not complained about cdbs packages, so it should probably be extended to not complain about dh 7
[14:57] <james_w> possibly
[14:57] <james_w> it would be better to be explicit
[14:57] <jdstrand> james_w: based on feedback here, newer lintian doesn't complain
[14:57] <james_w> oh, good
[14:58] <james_w> we should probably get lintian updated on that machine, it's bit me before
[14:59] <jdstrand> james_w: while perhaps I am, I find it hard to believe I am the only one who is not aware of the latest debhelper features (or any other debian/rules symantics) that are not policy compliant on the surface
[14:59] <james_w> I'm sure you are not
[15:00] <quadrispro> ehm... I've re-uploaded h264enc with some changes, but they are'nt correct, please reject it
[15:00] <quadrispro> aren't *
[15:00] <jdstrand> while I surely will remember this situation personally, as I'm sure quadrispro will also, debian policy is supposed to help prevent this frustration
[15:01] <jdstrand> quadrispro: rejected
[15:01] <jdstrand> I suppose since I'm the only one fired-up about it, I'll file a bug
[15:01] <pochu> asac: \o/
[15:02] <quadrispro> thanks jdstrand, can i re-upload it with DH7 support or... what? :)
[15:02] <jdstrand> quadrispro: yes
[15:02] <jdstrand> just reupload
[15:02]  * jdstrand is fairly miffed at the time wasted on this
[15:04] <asac> pochu: can you do the ifupdown merge for me now ;)? jk
[15:04] <quadrispro> jdstrand: done, thanks for your work :)
[15:05] <jdstrand> quadrispro: sorry for putting you through this
[15:05] <pochu> asac: lol
[15:05] <jdstrand> I'm determined to not have this happen to someone in the future
[15:06] <quadrispro> jdstrand: no prob, it was an interesting discussion
[15:06] <pochu> asac: I'll look at integrating the intltool-update in Debian, and the systray patch upstream though :)
[15:06] <asac> pochu: that would be awesome
[15:08]  * quadrispro taking out for ice cream
[15:12] <DktrKranz> jdstrand: mind give me a link when you file it? TIA
[15:12] <jdstrand> DktrKranz: sure thing
[15:34] <bddebian> Heya gang
[15:51] <geser> Hi bddebian
[15:52] <bddebian> Heya geser
[16:02] <mr_spot_> anybody able to review my package again? http://revu.ubuntuwire.com/p/pulseaudio-mixer-applet
[16:03]  * ScottK waves to bddebian.
[16:03] <therm> could someone take a look at one of my packages? http://revu.ubuntuwire.com/p/h2database http://revu.ubuntuwire.com/p/willuhnutil http://revu.ubuntuwire.com/p/willuhndatasource http://revu.ubuntuwire.com/p/swtcalendar (advocated on time)
[16:09] <bddebian> Hi ScottK
[16:15] <sebner> bddebian: \o/
[16:17] <gaspa> do someone run piuparts on ubuntu?
[16:18] <slayton> is there a program that can create a document illustrating the dependency hierarchy of a series of packages?
[16:19] <ScottK> Not automatically, AFAIK.
[16:19] <bddebian> Hi sebner
[16:19]  * sebner heart bddebian is a debian ftp-trainee *cough* *cough*
[16:19] <ScottK> Ohhh.
[16:20] <sebner> *heard
[16:20] <sebner> xd
[16:20] <pochu> all our packages belong to him ;)
[16:21] <sebner> ehehehe
[16:21] <\sh> what? bddebian will be ftp-master in no time?
[16:22]  * geser points to https://wiki.ubuntu.com/BddebianIsAGod
[16:22] <james_w> slayton: apt-cache dotty?
[16:23] <slayton> james_w, oh great thanks!
[16:23] <\sh> geser: yeah I know that page ;) I myself said he is "God" long ago ;) http://www.sourcecode.de/node/123
[16:23] <james_w> also debtree
[16:23] <james_w> also http://www.gnowledge.org/debmap_view?objid=python
[16:25] <pochu> geser: that page offends my beliefs. Please remove it
[16:25] <\sh> rotfl
[16:25] <sebner> geser: uhh, /me considers to add himself if bddebian cleans out the packages with @ubuntu adress from debian new :P :P :P
[16:25] <sebner> \sh: \o/
[16:25] <sebner> pochu: bddebian is the one and only *hehe*
[16:26]  * nhandler goes to check on his NEW packages
[16:26] <bddebian> \sh: Not yet, just an assistant
[16:27] <Laney> \sh: bah, the links are broken
[16:27] <Laney> I want to read your inspirational post!
[16:28] <\sh> Laney: http://www.sourcecode.de/node/122 <- this one
[16:28] <james_w> RainCT: around?
[16:28] <Laney> aha
[16:28] <\sh> Laney: I'll blame drupal for not converting old entries to new pathauto fame
[16:28] <Laney> the link goes to 123
[16:29] <james_w> RainCT: I'm reviewing zeitgeist, it's not all LGPL, but I'm guessing you know this, as debian/copyright also points to common-licences/GPL-3
[16:29] <\sh> Laney: 122 is the right one..
[16:29] <Laney> yeah
[16:29] <Laney> just telling you, as 123 is 404
[16:29] <Laney> ;)
[16:29] <james_w> RainCT: but I don't think the situation is expressed clearly there, which makes me think I will reject
[16:30] <james_w> RainCT: what do you think?
[16:30] <\sh> Laney: the link on 123 is 404...right...but that's one problem of drupal...need to fix it soon
[16:30] <Laney> alrighty
[16:35] <RainCT> Hey james_w
[16:35] <james_w> hi RainCT, how you doing?
[16:36] <RainCT> james_w: I'm fine, thanks. I mentioned GPL-3 in debian/copyright because the LGPL build upon the GPL.
[16:36] <RainCT> *builds
[16:36] <james_w> ah
[16:36] <james_w> I'll reject it then, with a clearer statement on what I feel is missing
[16:36] <james_w> sorry to disturb you
[16:37] <RainCT> Uhm, and what's missing?
[16:41] <james_w> I'm not sure it's missing, as much as incorrect headers, but I can't make that call
[16:41] <james_w> mail sent now
[16:42] <RainCT> james_w: Oh right, the headers are incorrect.
[16:42] <james_w> good :-)
[16:46] <cyberixae> What is the plan for hurd package?
[16:47] <cyberixae> I suppose it's not installable alongsided Linux, and Ubuntu is probably not going to switch kernel in near future, so what's the catch?
[16:47] <ScottK> What makes you think there is any plan at all?
[16:48] <cyberixae> The package being included in Universe
[16:48] <cyberixae> Is its inclusion just a mere theoretical effort?
[16:48] <gaspa> cyberixae: which package??
[16:48] <ScottK> It was probably autosync'ed from Debian.
[16:48] <cyberixae> http://packages.ubuntu.com/source/karmic/hurd
[16:49] <cyberixae> I understood that autosynced packages are still manually selected.
[16:49] <ScottK> No
[16:49] <RainCT> james_w: OK, I've fixed debian/copyright and updated the files upstream. Given that the release hasn't been announced yet we'll probably issue a new tarball including some new stuff
[16:50] <ScottK> RainCT: Please don't reuse the same version number.
[16:50] <james_w> RainCT: cool, feel free to ping me for fast-tracking through NEW
[16:50] <james_w> assuming you addressed all my issues :-)
[16:50] <RainCT> james_w: Great, thanks :)
[16:50] <geser> cyberixae: at the beginning of every development cycle, every package which is not blacklisted or has any Ubuntu changes will get imported automatically from Debian unstable
[16:50] <cyberixae> oh
[16:50] <RainCT> ScottK: For any particular reason? I don't know of any distro including it yet
[16:51] <cyberixae> So I should really ask Debian what their plan is.
[16:51] <ScottK> RainCT: It's just bad practice.  Has anyone downloaded it?
[16:51] <maco> Debian Hurd has existed for a while
[16:51] <cyberixae> I know they've provided a Hurd distro for some time
[16:51] <RainCT> ScottK: LP shows 10 downloads.
[16:51] <maco> there's also Debian BSD, isn't there?
[16:51] <cyberixae> But they didn't use the have hurd kernel in their Linux repos
[16:51] <ScottK> RainCT: So I think that's enough reason.
[16:54] <maco> enough reason to what?
[16:55] <Laney> to bump the version number
[16:55] <ScottK> Reissuing tarballs with the same version number is just really wrong.
[17:06] <jdstrand> DktrKranz, james_w: fyi: debian bug #536790
[17:06] <james_w> thanks
[17:08] <DktrKranz> ty
[17:08]  * DktrKranz subscribes to it
[17:09] <jdstrand> np
[17:43] <dduck> hi
[17:43] <dduck> do you know if the major bugs in ext4 are fixed in ubuntu jaunty?
[17:43] <dduck> i had an electrical cut yesterday and wanted to know if this could kill my filesystem when ext4 is used
[17:43] <dduck> or even kill the hard drive
[17:48] <RainCT> ScottK: You cna be happy, we've just decided we'll add some more features and label the new tarball as 0.2 ;)
[17:50] <ScottK> RainCT: Excellent.
[17:50] <ScottK> It's good engineering practice.
[17:50] <ScottK> Even if it hurts sometimes.
[17:58] <VK7HSE> If there are any ubuntu sponsors that wouldn't mind having a look Bug #398888
[18:35] <aboudreault> Hi. How could I be a maintainer of a few ubuntu packages ?
[18:35] <neversfelde> if someone from the MOTU SRU team is present, it would be great if you could have a look at bug #221531
[18:36] <aboudreault> Can I upload a more recent version of a package X, if it is curently synchronized with Debian unstable ?
[18:36] <neversfelde> aboudreault: I think the MOTU docs are a good point to start https://wiki.ubuntu.com/MOTU
[18:36] <aboudreault> all right. thanks
[18:50] <fabrice_sp> Hi. Do somebody know why the sponsored sync are using my gmail account (for example this one: https://lists.ubuntu.com/archives/karmic-changes/2009-July/004008.html), but all the other sponsored upload are changed-by my ubuntu email? Can I do something with my kaunchpad account to fix that and use only my ubuntu.com address?
[18:56] <maxb> fabrice_sp: I'd take a guess that it's because your gmail address seems to be the primary one on your launchpad account
[18:56] <maxb> Or at least I'm assuming the fact that it's the first listed on https://launchpad.net/~fabricesp means it's primary
[18:56] <fabrice_sp> maxb, I think you're right. I'll check
[18:56] <maco> you cannot set your ubuntu one as primary
[18:56] <maco> baaaad idea
[18:57] <maco> then when you get emails to the ubuntu one, theyll be forwarded...to the ubuntu one
[18:57] <maco> and not reach you
[18:57] <maco> i mean, lp allows it, but itll break your mail forwarding
[18:58] <pochu> I have had my ubuntu one by default for years
[18:58] <fabrice_sp> but you can set it as preferred. Is it the same?
[18:58] <pochu> fabrice_sp: yes
[18:58] <fabrice_sp> I had my gmail.com as preferred, and I've just changed to ubuntu
[19:00] <fabrice_sp> I'll test to send an email to the ubuntu.com one, just to check what happen! :-)
[19:07] <fabrice_sp> mail forwarding is still working. Let's see what happen on next sponsored sync request. Thanks maxb and pochu !
[19:08] <maxb> fabrice_sp: I seem to recall reading somewhere that the updating of @ubuntu.com forwarding is a cronjob - you'd better test if it's still working in a day's time, and again a few days later.
[19:09] <maxb> "If you change your Launchpad ID or primary email address, there will also be up to 48 hour delay until this takes effect. " -- https://wiki.ubuntu.com/UbuntuEmail
[19:09] <maxb> fabrice_sp: ^
[19:10] <maxb> "As the alias forwards email to your primary address on LP - please do not set your primary email address for Launchpad to your Ubuntu email address. If you do, this will either result in a loop or your email alias will simply not be created. This is a known problem, please see bug #5292 for more information. "
[19:11]  * pochu feels lucky ;)
[19:12]  * fabrice_sp is looking at the bug report
[19:17]  * fabrice_sp is changing back his preferred email address...
[19:17] <pochu> heh
[19:50] <or4n9e> I have a question about casper
[19:51] <or4n9e> ubuntu is capable of persistent liveusb utilizing an ext2/3 partition for persistent storage and a fat32 for the system
[19:51] <or4n9e> could one create an img file of a ready liveusb stick utilizing dd if=/dev/sdb of=image.img
[19:52] <or4n9e> AND, and that's the tricky part, is casper capable to create the ext2/3 partition "expandable" depending on the actual size of the stick the is copied to?
[19:52] <or4n9e> the image
[19:53] <or4n9e> I know that openSUSE's kiwi system is capable to do this but I'm unable to find appropraite infos about casper on the web
[21:01] <gaspa> geser: ftbfs states "Last update: 2009-07-10 00:19:26 +0000"
[22:03] <geser> gaspa: I know. edge is still not updated, so the API bug still exists
[22:03] <gaspa> geser: ah, right.
[22:04] <gaspa> I tried to convince myself that it was already fixed. :p