[06:53] <pochu> is Marc Deslauriers here?
[06:55] <persia> pochu: Goes by mdeslaur usually.
[07:03] <pochu> mdeslaur: hey
[07:04] <pochu> mdeslaur: I see you've uploaded a new revision of liferea
[07:04] <pochu> mdeslaur: I wonder if this change doesn't introduce regressions:
[07:04] <pochu>   * debian/patches/01_ubuntu_feedlists: updated some outdated feeds
[07:04] <pochu>     (LP: #341969)
[07:04] <pochu> mdeslaur: can you still reorder the feeds in the left pane by drag and dropping them?
[07:05] <ejat> can someone porting this http://paste.ubuntu.com/387442/
[07:05]  * persia notes that mdeslaur's reported timezone in LP is UTC -5, so there may be a delay for a response
[07:26] <lucent> I was advised to ask my question here. "Where do I learn modern methods for generating a debian package from source code?"
[07:27] <lucent> searching Google turned up some pretty dated methods for me
[07:35] <randomaction> modern, as in debhelper 7?
[07:36] <lucent> would the steps to create a package for Ubuntu be any different than the steps outlined in maint-guide ?
[07:36] <lucent> and really I am familiar with creating packages for a system, it is that I am new to how to make a proper package for apt/deb and Ubuntu
[07:37] <lucent> with Gentoo some years ago I learned about installing a package with a modified destination dir, and accounting for differences in the build system with the destination rootfs
[07:38] <lucent> apt/deb is still kind of foreign to me
[07:38] <randomaction> we have a https://wiki.ubuntu.com/PackagingGuide
[07:38] <lucent> okay, I missed that one. I will look at it now.
[07:41] <randomaction> and there's a session log at https://wiki.ubuntu.com/MeetingLogs/devweek0909/PkgFromScratch
[07:41] <randomaction> which could also be helpful
[07:41] <lucent> noted. great!
[07:45] <randomaction> and manual page for debhelper is a valuable source of detailed technical information
[07:46] <randomaction> and Debian policy, of course
[08:20] <dholbach> good morning
[08:21] <abogani> dholbach: to you
[08:23] <dholbach> hi abogani
[10:00] <directhex> bugger. need to un-register for UDS sponsorship
[10:00] <rawang> hello, does anybody know if my package A depends on a just python module(a directory), but the module have to different implementation and they are not coexisted (have same directory but two different implementations.) how to write Depends field in debian/control file?
[10:02] <rawang> oh, my package A is a python package
[10:02] <lifeless> rawang: so, A uses B, where B is a python package
[10:02] <lifeless> but there are two different package names both of which contain B ?
[10:03] <rawang> yep, but B have 2 implementations.
[10:03] <rawang> yep
[10:03] <lifeless> what are the package names for them
[10:04] <rawang> lifeless, let me say more clearly, my python package strongwind needs pyatspi, at-spi and at-spi2 ship the same directory
[10:04] <rawang> strongwind could work on at-spi OR at-spi2
[10:04] <lifeless> at-spi doesn't look like it has python in it
[10:04] <rawang> ok, the python package is python-pyatspi
[10:04] <lifeless> what is the actual package name
[10:05] <lifeless> and the othe rpackage name
[10:05] <rawang> python-pyatspi2, which is built by myself
[10:05] <lifeless> depends: (python-pyatspi | python-pyatspi2)
[10:05] <rawang> ah, got it
[10:06] <lifeless> uhm, the syntax may be a little wrong - check policy if needed
[10:06] <rawang> could a append version?  like depends (python-pyatspi >= 1.28 | python-pyatspi2 >= 0.1.7)  ?
[10:06] <lifeless> but seriously consider not using the same python module name for pyatspi2; its almost guaranteed to end badly
[10:06] <lifeless> yes, that can be done
[10:07] <lifeless> python-pyatspi (>= 1.28) | ..
[10:07] <rawang> lifeless, python-pyatspi and python-pyatspi2 could not be coexist
[10:08] <lifeless> right, which means you'll have to change 5 other packages to be able to have people install python-pyatspi2
[10:08] <lifeless> also
[10:08] <rawang> because some files are conflicts,  (has same 'pyatspi' dir )
[10:08] <lifeless> it means that python-pyatspi2 will *not follow* the python packaging policy
[10:09] <lifeless> the package name for a python package 'pyatspi' is 'python-pyatspi'
[10:09] <rawang> lifeless, yes, i did, my package name is python-pyatspi2, what's the problem with that? :)
[10:10] <lifeless> the python package you install is 'pyatspi', Debian python policy is that your dedbian package name must therefore be 'python-pyatspi'
[10:10] <lifeless> thats the problem.
[10:10] <lifeless> if you call the python package you install 'pyatspi2' its all ok.
[10:11] <lifeless> or if you call your debian package name 'python-pyatspi' its also ok (though you still need to replace the package in the distro, and thats non going to be simple as you have radically different version numbers)
[10:12] <rawang> lifeless, i'm sorry I don't understand. :(   python-pyatspi2 is follow the python- prefix policy
[10:12] <lifeless> the policy is not just a prefix
[10:12] <lifeless> its an exact match
[10:13] <rawang> lifeless, ok.....    so what's your suggestions? :)
[10:14] <lifeless> I gave them to you
[10:14] <rawang> named it as pyatspi2 ?
[10:14] <lifeless> either generate a python module 'pyatspi2'
[10:14] <lifeless> or patch pyatspi
[10:14] <rawang> oh
[10:14] <lifeless> actually, thats a new suggestion :)
[10:14] <lifeless> those are your best options.
[10:15] <rawang> could you please look at it to see if there is a problem, of course if you have time. :)   https://launchpad.net/~raywang/+archive/uia2atk/+sourcepub/982612/+listing-archive-extra
[10:15] <lifeless> I'm just entering a meeting sorry
[10:16] <rawang> lifeless, ok, sorry :)
[10:16] <rawang> and thanks a lot!
[10:17] <duanedesign> i made a fix on a typo bug. DL source made a patch and uploaded it to a bug upstream. Now the bug has been commented on. Not sure what that means. http://sourceware.org/bugzilla/show_bug.cgi?id=11330
[10:18] <Laney> it means it was fixed
[10:19] <duanedesign> Laney: ok i just wanted to make sure that i did the right thing and that wasnt someone 'fixing' what i did :)
[10:19] <duanedesign> thank you
[12:44] <mdeslaur> pochu: hmm...let me check that. It would be the _other_ changelog entry that would have introduced the regression.
[12:48] <mdeslaur> pochu: yes, it appears to have introduced a regression. I'll fix it or revert it today.
[13:19] <wrapster> how do i downgrade a pkg version?
[13:19] <wrapster> I mean lets say I have P-5 pkg installed.. How do i install P-4 if i want to?
[13:20] <Laney> find a deb and dpkg --install it
[13:20] <Laney> add a repo which contains it and apt-get install pkg=version
[13:20] <Laney> it might be in /var/cache/apt/archives if you had it installed before
[13:21] <wrapster> ok
[13:24] <nigelb> bdrung: the epiphany-extensions-more removal bug, you want me to change it to sync request?
[13:25] <bdrung> nigelb: yes
[13:25] <nigelb> just a doubt though
[13:25] <bdrung> nigelb: it will require a feature freeze exception
[13:25] <nigelb> I checked live.gnome.org and it said that the epiphany-extensions-more won't work with 2.28 and above
[13:26] <bdrung> nigelb: look at http://packages.debian.org/changelogs/pool/main/e/epiphany-extensions-more/current/changelog
[13:27] <nigelb> the javascript based ones are a bit unstable
[13:27] <nigelb> (as per upstream)
[13:28] <bdrung> nigelb: then it's up to you - do we want to distribute possible unstable extensions or none instead?
[13:28] <nigelb> one side is - I'd rather have something than nothing.  second side - I'd like the LTS to be stable :)
[13:29] <nigelb> what would be the usual protocol? to sync it anyway and let the user decide?
[13:29]  * bdrung agrees.
[13:30] <Laney> you could disable the unstable ones
[13:30] <bdrung> nigelb: i doubt that we have a protocol for that
[13:30] <nigelb> Laney: you mean sync it and let the user decide since she/he can disable it anyway?
[13:31] <Laney> no, I mean *you* disable the extensions which aren't suitable for production use
[13:31] <Laney> you don't want to mislead users
[13:32] <nigelb> there is epiphany extensions an epiphany extensions more
[13:32] <Laney> that doesn't make it clear that they are experimental
[13:32] <nigelb> the more package is the one with trouble.  its not just an extention.  the javascript based stuff is entire unstable is what upstream says
[13:33] <nigelb> s/entire/entirely
[13:33] <Laney> I dunno, I'd think hard about whether you want to put it in lucid at all
[13:33] <nigelb> me too
[13:34] <nigelb> here's the upstream page: http://live.gnome.org/Epiphany/ThirdPartyExtensions/Epiphany228AndLater
[13:40] <nigelb> I'm -1 because of this unstability, though upstream seems to say we'd have better luck with 2.29.5 and above (we're at 2.29.91)
[13:46] <nigelb> bdrung: so, we keep it or remove it?
[13:50] <nigelb> I'm trying to investigate why the 'imagemagick' dependency for 'shutter' package was dropped to recommends in debian.  Not having 'imagemagick' around is causing it to be not installed.  Where can I look to figure this out?
[13:55] <bdrung> nigelb: upstream says: "Unfortunately you are highly likely to have Epiphany crash on you if you use these extensions with Epiphany 2.28.0"
[13:56] <nigelb> ugh! my bad
[13:56] <nigelb> I'll change to sync request :)
[13:56] <bdrung> nigelb: if you want to gain extra points, test the extensions :)
[13:57] <nigelb> I will :)
[13:57] <nigelb> this is going to take the whole evening though ;)
[13:58] <nigelb> I'll test it first and then decide :)
[13:58] <bdrung> great, thanks
[13:58] <nigelb> any thoughts on the shutter thing?
[13:59] <nigelb> ah, I see debian bug 567612
[14:12] <umang> Hi, I want to know whether a package (pbuilder) is eligible for a backport request. Is the right place?
[14:17] <ScottK> umang: It could be.  Do you want to backport it to get a bug fix or because there's a new feature you'd like to use?
[14:20] <umang> ScottK, I guess that would be a bug fix (I've figured out a work around). I know backports aren't for bugfixes, but I've read that the latest pbuilder should be in backports. ATM, pbuilder cannot create a base tarball with the default settings, that means pbuilder doesn't work unless you find out what to change.
[14:20] <umang> s/figured/found out about/
[14:20] <ScottK> umang: What do you have to change?
[14:21] <umang> ScottK, pbuilder doesn't ask debootstrap to include apt, but it needs apt to function.
[14:21] <umang> (Fixed in the latest version, currently in sid and squeeze I believe)
[14:22] <ScottK> umang: Is it fixed in Lucid?
[14:22] <umang> ScottK, yes.
[14:23] <umang> Lucid has 0.196, which has the fix.
[14:23] <nigelb> umang: you mean to say pbuilder chroot does not have apt in below lucid?
[14:24] <umang> nigelb, http://packages.debian.org/changelogs/pool/main/p/pbuilder/current/changelog (last but one point).
[14:24] <nigelb> umang: ah :)
[14:24] <umang> :)
[14:25] <nigelb> okay, there is a dependency problem in shutter, the bug has been filed against debian and maintainer has marked as high.  Should I wait and reqeust sync or fix in ubuntu directly?
[14:25] <slytherin> umang: I believe this is a rare use case and not a general scenario. I have been using pbuilder since hardy and this suddenly not a bug in general usage.
[14:26] <Laney> no, there was a change (I believe apt stopped being Essential: yes) in Debian which broke it
[14:26] <umang> slytherin, but that means there is no way to get the latest pbuilder in karmic?
[14:26] <ScottK> slytherin: Laney's right.  It's a real (but new) problem.
[14:27] <slytherin> Oh. Then the issue does not affect karmic. Hence the backport will not serve any real purpose.
[14:27] <umang> Does that make it ineligible for backports?
[14:27] <ScottK> umang: File a bug against karmic-backports, indicate (assuming it does) that the new pbuilder builds, installs, and runs on Karmic and I'll approve it.
[14:27] <ScottK> slytherin: It does if you want to make a Lucid chroot.
[14:27] <Laney> it affects building sid chroots on karic
[14:28] <ScottK> (or Sid, I don't recall if Lucid is affected too)
[14:28] <Laney> I just hacked my debootstrap scripts to make it work
[14:28] <umang> Laney, Can't expect everyone to do that, no?
[14:28] <Laney> no, I didn't say that I do
[14:29] <umang> ScottK, so I build it from source on Karmic, (take the source package from Lucid) and see if it builds and works. If it does then I file a bug?
[14:29] <slytherin> ScottK: I have crated lucid chroot long time back. Was this broken recently?
[14:29] <ScottK> umang: Yes.
[14:29] <ScottK> slytherin: I don't recall for sure if Lucid is affect. Sid/Squeeze definitely are.
[14:29] <umang> ScottK, OK. I'll do that tomorrow morning (free internet usage :P )
[14:29] <ScottK> OK.
[14:30] <umang> Thanks all! :)
[15:07] <RoAkSoAx> ScottK, do you nthink this two bugs should be SRUs instead of backports? bug 530945 and bug 530972
[15:07] <ScottK> Looking
[15:11] <ScottK> RoAkSoAx: Commented both.
[15:11] <RoAkSoAx> ScottK, thank you :)
[16:12] <RoAkSoAx> ScottK, in the case for the SRUs, should I attach a diff showing the changes between the version in karmic with the one in lucid, or should I just specify to push the lucid package into karmic?
[16:12] <ScottK> You should have a minimal diff for just the SRU worthy change
[16:14] <RoAkSoAx> ScottK, so only show the part of the changed to fix the bug?
[16:15] <ScottK> Yes.  For the SRU we just want the patch that fixes the bug, not the entire new version.
[16:15] <RoAkSoAx> ScottK, what if the entire new version is a bugfix release?
[16:16] <RoAkSoAx> we still place the patch fixing it i guess
[16:16] <ScottK> For SRU we only fix important bugs.  We want the minimal fix to deal with the SRU worth problem.
[16:16] <ScottK> There are a few packages that have exceptions to this, but that has to be tech board approved.
[16:17] <RoAkSoAx> i see
[17:17] <slytherin> RoAkSoAx: backport the patch form new release to release in repositories.
[17:19] <RoAkSoAx> slytherin, i cannot do that with usbmount exactly because upstream did various changes adding new features, so I;m just using the original patch in debian BTS
[17:20] <slytherin> RoAkSoAx: You don't want those features right? Only the fix for a bug.
[17:22] <RoAkSoAx> slytherin, well I requested a backport mainly because of that fix, but new upstream also contains new features like support for UUIDs, but that's not essential I guess
[17:22] <slytherin> RoAkSoAx: Ok. I thought you were discussing SRU.
[17:23] <RoAkSoAx> slytherin, i first requested a backport, now I'm chagning it to SRU just to fix the bug
[17:44] <pochu> mdeslaur: if you get to fix it, let me know, since we reverted it upstream :)
[17:44] <mdeslaur> pochu: I reverted it for now
[17:45] <mdeslaur> pochu: thanks for the head's up!
[18:02] <pochu> mdeslaur: no problem
[18:39] <RoAkSoAx> ScottK, done with SRUs, could you please take a look at them? bug #530945 and bug #530972
[18:41] <ScottK> RoAkSoAx: I'm not on the SRU team.
[18:42] <RoAkSoAx> ScottK, oh thought u were lol :) sorry about that then
[18:59] <jdong> RoAkSoAx: both are now ACKed, thanks for taking care of the SRU :)
[19:00] <RoAkSoAx> jdong, glad to help :)
[19:36] <\sh> micahg: thx for the backports :)
[19:45] <RoAkSoAx> \sh, did a small test with pacemaker/ldirectord/ipvsadm works nice :)
[19:45] <\sh> RoAkSoAx: ah well...we are setting it up now :)
[19:46] <RoAkSoAx> awesome
[19:46] <RoAkSoAx> anways I have the setup here : https://wiki.ubuntu.com/ClusterStack/LucidTesting#Load%20Balancing%20with%20Pacemaker/ldirectord
[19:46] <\sh> so heading now for home...;)
[19:47] <RoAkSoAx> ok have a good one
[19:47] <RoAkSoAx> im off tyo lunch
[19:48] <micahg> \sh: thanks for the blog post :)
[19:53] <DreamDemon> There is a problem with the way a pacgage works with the current server ( karmic 9.10) kernel works
[19:53] <DreamDemon> package*
[19:54] <DreamDemon> ipset will NOT work with a default install even though the package is avail thru universe via apt-get
[19:55] <DreamDemon> This causes problems with mass white/black listing block CIDR addresses for multiple countries as iptables takes entirely too long to process large requests as such
[19:56] <DreamDemon> eg: blacklist of all countries except US, HU, DK, DE, GB = approx 100k lines of CIDR adresses
[19:56] <DreamDemon> eg2: whitelist countries US, HU, DK, DE, GB = approx 30k lines of CIDR adresses
[20:17] <vincs> Hi everyone.
[20:19] <vincs> I am an beginer at packing and I have some questions on uploading to revu. Is it the rigth channel to ask them ?
[20:20] <highvoltage> it's the perfect channel to ask in
[20:27] <vincs> I have upload a package. (debuild -S  -sa --lintian-opts -i; cd ..; dput revu mypackage.changes)
[20:28] <vincs> I have some changes to do.
[20:28] <vincs> Let's say only on the rule file.
[20:29] <vincs> Should I basicaly edit rules file and upload changes?
[20:30] <vincs> (I forgot the get-orig-source rule)
[20:30] <vincs> Or should I also change the changelog file ?
[21:26] <RainCT> So Canonical is going purple?
[21:26] <lucas> purple?
[21:26] <RainCT> https://wiki.ubuntu.com/Brand
[21:27]  * sebner facepalms
[21:34] <oojah> I've got a program I'm converting to use upstart instead of sysvinit. In the packaging, what's the recommended way of creating the symlink that is /etc/init.d/<name> -> /lib/init/upstart-job ?
[21:36] <ScottK> cody-somerville: Is blue a traditional xfce color?
[21:36] <Laney> oojah: You should use dh_link
[21:37] <cody-somerville> ScottK, Yes.
[21:37] <ScottK> cody-somerville: Thanks.
[21:37] <ScottK> jono: Was someone from Kubuntu involved in this rebranding effort (if so, who)?
[21:37] <jono> ScottK, Riddell
[21:37] <ScottK> jono: Thanks.
[21:39] <oojah> Laney: Great, thanks.
[21:45] <strycore> Hi
[21:45] <strycore> I'd like to learn how to fix bug 531629
[21:46] <strycore> the virtual package is outdated
[21:46] <sebner> ScottK: do you look for a person to complain to ?^^
[21:47] <ScottK> sebner: No.  I'm looking to find out the plan for Kubuntu since jono's announcement didn't have Kubuntu material in it.
[21:47] <jono> ScottK, just no completed Kubuntu logo tet
[21:47] <jono> yet
[21:47] <ScottK> Ah.  OK.
[21:47] <jono> the logo font is still in the works, so not all the letters are complete yet
[21:48] <sebner> tell me mighty jono, why purple xD
[21:48] <jono> when the font is done, a logo will be shortly arriving :)
[21:48] <ajmitch> zul: another php extension rebuild for you ^
[21:48] <jono> sebner, I think it looks cool :)
[21:48] <jono> thats the not the reason though
[21:48] <jono> :)
[21:48] <sebner> jono: is that our feminine side :P
[21:51] <vorian> I think the purple is hot
[21:51] <vorian> & very close to blue :)
[21:52] <sebner> better than brown but still ..
[21:52] <DktrKranz> sebner: turn off monitor, and you'll see the real dark theme ;)
[21:53]  * sebner likes dark themes *muaahaahahaha*
[21:54]  * ajmitch has the sparkly coloured lines theme on the laptop, it's so vibrant & jumpy...
[22:13] <milli> ScottK: I'm hoping and praying that Rails 3.0 releases before lucid is done, since it would be a real shame to not have Rails 3 for the next 6 years...
[22:19] <micahg> is anything in universe extended to the 5 yr support window?
[22:23] <ScottK> micahg: It's all community supported and so to the extent the community supports it, the window is the same as Main.
[22:23] <micahg> ScottK: k, so in theory anything that's server only could br patched for 5 yrs?
[22:24] <ScottK> micahg: Yes.
[22:25] <ScottK> Personally, I'm still supporting clamav on Dapper.
[22:25] <micahg> ScottK: cool, thanks
[22:25] <micahg> ScottK: can we backport universe packages as well in -backports?
[22:28] <ScottK> micahg: Yes.
[22:29] <micahg> very cool :)
[22:29]  * micahg thinks he'll be testing backports for Lucid for a while :)
[23:12] <crimsun> perhaps we need a "sponsor day" or something suitably silly
[23:13] <jdong> if bug days are called hug days, I *cringe* at the non-PG name for sponsor bribing days
[23:13] <jdong> (kidding!)
[23:30] <ScottK> No you aren't.
[23:44] <persia> crimsun: Why a "sponsor day"?  Lately the universe queue rarely grows beyond 10 bugs.
[23:44] <crimsun> persia: it's half tongue-in-cheek
[23:45] <persia> Oh, heh.
[23:45] <crimsun> I'll gladly switch places with someone to work on it, though :-)
[23:46] <persia> Given how you used to be too busy with stuff to help with the old-style bug days (when we actually got stuff fixed), I don't imagine many could take your place, even for a day.
[23:46] <crimsun> nah, just need a lot of incentive^Wcoffee^Wtea
[23:46]  * persia remembers "I already have a bug, thanks" being the response to bug day findings back then
[23:48] <crimsun> hmm, armel buildds now fail after encountering implicit declaration warnings, correct?
[23:49] <persia> I didn't think they had any special logic that differed from other buildds.
[23:49] <crimsun> yeah, they do (and ia64 as well)
[23:50] <crimsun> otherwise I wouldn't have located those bugs in pulse.  D'oh, bad memory.
[23:50] <crimsun> arb is such a crufty source package
[23:51] <persia> heh