=== mdomsch_ is now known as mdomsch_zZzZ [06:53] is Marc Deslauriers here? [06:55] pochu: Goes by mdeslaur usually. [07:03] mdeslaur: hey [07:04] mdeslaur: I see you've uploaded a new revision of liferea [07:04] mdeslaur: I wonder if this change doesn't introduce regressions: [07:04] * debian/patches/01_ubuntu_feedlists: updated some outdated feeds [07:04] (LP: #341969) [07:04] mdeslaur: can you still reorder the feeds in the left pane by drag and dropping them? [07:05] 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] I was advised to ask my question here. "Where do I learn modern methods for generating a debian package from source code?" [07:27] searching Google turned up some pretty dated methods for me [07:35] modern, as in debhelper 7? [07:36] would the steps to create a package for Ubuntu be any different than the steps outlined in maint-guide ? [07:36] 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] 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] apt/deb is still kind of foreign to me [07:38] we have a https://wiki.ubuntu.com/PackagingGuide [07:38] okay, I missed that one. I will look at it now. [07:41] and there's a session log at https://wiki.ubuntu.com/MeetingLogs/devweek0909/PkgFromScratch [07:41] which could also be helpful [07:41] noted. great! [07:45] and manual page for debhelper is a valuable source of detailed technical information [07:46] and Debian policy, of course [08:20] good morning [08:21] dholbach: to you [08:23] hi abogani [10:00] bugger. need to un-register for UDS sponsorship [10:00] 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] oh, my package A is a python package [10:02] rawang: so, A uses B, where B is a python package [10:02] but there are two different package names both of which contain B ? [10:03] yep, but B have 2 implementations. [10:03] yep [10:03] what are the package names for them [10:04] lifeless, let me say more clearly, my python package strongwind needs pyatspi, at-spi and at-spi2 ship the same directory [10:04] strongwind could work on at-spi OR at-spi2 [10:04] at-spi doesn't look like it has python in it [10:04] ok, the python package is python-pyatspi [10:04] what is the actual package name [10:05] and the othe rpackage name [10:05] python-pyatspi2, which is built by myself [10:05] depends: (python-pyatspi | python-pyatspi2) [10:05] ah, got it [10:06] uhm, the syntax may be a little wrong - check policy if needed [10:06] could a append version? like depends (python-pyatspi >= 1.28 | python-pyatspi2 >= 0.1.7) ? [10:06] but seriously consider not using the same python module name for pyatspi2; its almost guaranteed to end badly [10:06] yes, that can be done [10:07] python-pyatspi (>= 1.28) | .. [10:07] lifeless, python-pyatspi and python-pyatspi2 could not be coexist [10:08] right, which means you'll have to change 5 other packages to be able to have people install python-pyatspi2 [10:08] also [10:08] because some files are conflicts, (has same 'pyatspi' dir ) [10:08] it means that python-pyatspi2 will *not follow* the python packaging policy [10:09] the package name for a python package 'pyatspi' is 'python-pyatspi' [10:09] lifeless, yes, i did, my package name is python-pyatspi2, what's the problem with that? :) [10:10] the python package you install is 'pyatspi', Debian python policy is that your dedbian package name must therefore be 'python-pyatspi' [10:10] thats the problem. [10:10] if you call the python package you install 'pyatspi2' its all ok. [10:11] 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] lifeless, i'm sorry I don't understand. :( python-pyatspi2 is follow the python- prefix policy [10:12] the policy is not just a prefix [10:12] its an exact match [10:13] lifeless, ok..... so what's your suggestions? :) [10:14] I gave them to you [10:14] named it as pyatspi2 ? [10:14] either generate a python module 'pyatspi2' [10:14] or patch pyatspi [10:14] oh [10:14] actually, thats a new suggestion :) [10:14] those are your best options. [10:15] 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] I'm just entering a meeting sorry [10:16] lifeless, ok, sorry :) [10:16] and thanks a lot! [10:17] 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:17] sourceware.org bug 11330 in ld "ld manual page has typo" [Minor,Resolved: fixed] [10:18] it means it was fixed [10:19] Laney: ok i just wanted to make sure that i did the right thing and that wasnt someone 'fixing' what i did :) [10:19] thank you === yofel_ is now known as yofel [12:44] pochu: hmm...let me check that. It would be the _other_ changelog entry that would have introduced the regression. [12:48] pochu: yes, it appears to have introduced a regression. I'll fix it or revert it today. [13:19] how do i downgrade a pkg version? [13:19] I mean lets say I have P-5 pkg installed.. How do i install P-4 if i want to? [13:20] find a deb and dpkg --install it [13:20] add a repo which contains it and apt-get install pkg=version [13:20] it might be in /var/cache/apt/archives if you had it installed before [13:21] ok [13:24] bdrung: the epiphany-extensions-more removal bug, you want me to change it to sync request? [13:25] nigelb: yes [13:25] just a doubt though [13:25] nigelb: it will require a feature freeze exception [13:25] I checked live.gnome.org and it said that the epiphany-extensions-more won't work with 2.28 and above [13:26] nigelb: look at http://packages.debian.org/changelogs/pool/main/e/epiphany-extensions-more/current/changelog [13:27] the javascript based ones are a bit unstable [13:27] (as per upstream) [13:28] nigelb: then it's up to you - do we want to distribute possible unstable extensions or none instead? [13:28] one side is - I'd rather have something than nothing. second side - I'd like the LTS to be stable :) [13:29] what would be the usual protocol? to sync it anyway and let the user decide? [13:29] * bdrung agrees. [13:30] you could disable the unstable ones [13:30] nigelb: i doubt that we have a protocol for that [13:30] Laney: you mean sync it and let the user decide since she/he can disable it anyway? [13:31] no, I mean *you* disable the extensions which aren't suitable for production use [13:31] you don't want to mislead users [13:32] there is epiphany extensions an epiphany extensions more [13:32] that doesn't make it clear that they are experimental [13:32] 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] s/entire/entirely [13:33] I dunno, I'd think hard about whether you want to put it in lucid at all [13:33] me too [13:34] here's the upstream page: http://live.gnome.org/Epiphany/ThirdPartyExtensions/Epiphany228AndLater [13:40] 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] bdrung: so, we keep it or remove it? [13:50] 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] 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] ugh! my bad [13:56] I'll change to sync request :) [13:56] nigelb: if you want to gain extra points, test the extensions :) [13:57] I will :) [13:57] this is going to take the whole evening though ;) [13:58] I'll test it first and then decide :) [13:58] great, thanks [13:58] any thoughts on the shutter thing? [13:59] ah, I see debian bug 567612 [13:59] Debian bug 567612 in shutter "missing dependency on imagemagick" [Important,Open] http://bugs.debian.org/567612 [14:12] Hi, I want to know whether a package (pbuilder) is eligible for a backport request. Is the right place? === kirkland` is now known as kirkland [14:17] 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] 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] s/figured/found out about/ [14:20] umang: What do you have to change? [14:21] ScottK, pbuilder doesn't ask debootstrap to include apt, but it needs apt to function. [14:21] (Fixed in the latest version, currently in sid and squeeze I believe) [14:22] umang: Is it fixed in Lucid? [14:22] ScottK, yes. [14:23] Lucid has 0.196, which has the fix. [14:23] umang: you mean to say pbuilder chroot does not have apt in below lucid? [14:24] nigelb, http://packages.debian.org/changelogs/pool/main/p/pbuilder/current/changelog (last but one point). [14:24] umang: ah :) [14:24] :) [14:25] 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] 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] no, there was a change (I believe apt stopped being Essential: yes) in Debian which broke it [14:26] slytherin, but that means there is no way to get the latest pbuilder in karmic? [14:26] slytherin: Laney's right. It's a real (but new) problem. [14:27] Oh. Then the issue does not affect karmic. Hence the backport will not serve any real purpose. [14:27] Does that make it ineligible for backports? [14:27] 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] slytherin: It does if you want to make a Lucid chroot. [14:27] it affects building sid chroots on karic [14:28] (or Sid, I don't recall if Lucid is affected too) [14:28] I just hacked my debootstrap scripts to make it work [14:28] Laney, Can't expect everyone to do that, no? [14:28] no, I didn't say that I do [14:29] 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] ScottK: I have crated lucid chroot long time back. Was this broken recently? [14:29] umang: Yes. [14:29] slytherin: I don't recall for sure if Lucid is affect. Sid/Squeeze definitely are. [14:29] ScottK, OK. I'll do that tomorrow morning (free internet usage :P ) [14:29] OK. [14:30] Thanks all! :) === Lutin is now known as Guest49002 [15:07] ScottK, do you nthink this two bugs should be SRUs instead of backports? bug 530945 and bug 530972 [15:07] Launchpad bug 530945 in keepalived "Please backport keepalived 1.1.17-2 to Karmic from Lucid" [Medium,Confirmed] https://launchpad.net/bugs/530945 [15:07] Launchpad bug 530972 in usbmount "Please backport usbmount 0.0.19.1 to karmic from lucid" [Medium,Confirmed] https://launchpad.net/bugs/530972 [15:07] Looking [15:11] RoAkSoAx: Commented both. [15:11] ScottK, thank you :) [16:12] 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] You should have a minimal diff for just the SRU worthy change [16:14] ScottK, so only show the part of the changed to fix the bug? [16:15] Yes. For the SRU we just want the patch that fixes the bug, not the entire new version. [16:15] ScottK, what if the entire new version is a bugfix release? [16:16] we still place the patch fixing it i guess [16:16] For SRU we only fix important bugs. We want the minimal fix to deal with the SRU worth problem. [16:16] There are a few packages that have exceptions to this, but that has to be tech board approved. [16:17] i see [17:17] RoAkSoAx: backport the patch form new release to release in repositories. [17:19] 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] RoAkSoAx: You don't want those features right? Only the fix for a bug. [17:22] 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] RoAkSoAx: Ok. I thought you were discussing SRU. [17:23] slytherin, i first requested a backport, now I'm chagning it to SRU just to fix the bug === nxvl_ is now known as nxvl [17:44] mdeslaur: if you get to fix it, let me know, since we reverted it upstream :) [17:44] pochu: I reverted it for now [17:45] pochu: thanks for the head's up! [18:02] mdeslaur: no problem === yofel_ is now known as yofel [18:39] ScottK, done with SRUs, could you please take a look at them? bug #530945 and bug #530972 [18:39] Launchpad bug 530945 in keepalived "[SRU] keepalived in karmic" [Medium,Confirmed] https://launchpad.net/bugs/530945 [18:39] Launchpad bug 530972 in usbmount "[SRU] usbmount in karmic" [Medium,Confirmed] https://launchpad.net/bugs/530972 [18:41] RoAkSoAx: I'm not on the SRU team. [18:42] ScottK, oh thought u were lol :) sorry about that then [18:59] RoAkSoAx: both are now ACKed, thanks for taking care of the SRU :) [19:00] jdong, glad to help :) [19:36] <\sh> micahg: thx for the backports :) [19:45] \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] awesome [19:46] 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] ok have a good one [19:47] im off tyo lunch [19:48] \sh: thanks for the blog post :) [19:53] There is a problem with the way a pacgage works with the current server ( karmic 9.10) kernel works [19:53] package* [19:54] ipset will NOT work with a default install even though the package is avail thru universe via apt-get [19:55] 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] eg: blacklist of all countries except US, HU, DK, DE, GB = approx 100k lines of CIDR adresses [19:56] eg2: whitelist countries US, HU, DK, DE, GB = approx 30k lines of CIDR adresses [20:17] Hi everyone. [20:19] 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] it's the perfect channel to ask in [20:27] I have upload a package. (debuild -S -sa --lintian-opts -i; cd ..; dput revu mypackage.changes) [20:28] I have some changes to do. [20:28] Let's say only on the rule file. [20:29] Should I basicaly edit rules file and upload changes? [20:30] (I forgot the get-orig-source rule) [20:30] Or should I also change the changelog file ? [21:26] So Canonical is going purple? [21:26] purple? [21:26] https://wiki.ubuntu.com/Brand [21:27] * sebner facepalms [21:34] 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/ -> /lib/init/upstart-job ? [21:36] cody-somerville: Is blue a traditional xfce color? [21:36] oojah: You should use dh_link [21:37] ScottK, Yes. [21:37] cody-somerville: Thanks. [21:37] jono: Was someone from Kubuntu involved in this rebranding effort (if so, who)? [21:37] ScottK, Riddell [21:37] jono: Thanks. [21:39] Laney: Great, thanks. [21:45] Hi [21:45] I'd like to learn how to fix bug 531629 [21:45] Launchpad bug 531629 in xdebug "xdebug can't be installed : wrong virtual package" [Undecided,New] https://launchpad.net/bugs/531629 [21:46] the virtual package is outdated [21:46] ScottK: do you look for a person to complain to ?^^ [21:47] 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] ScottK, just no completed Kubuntu logo tet [21:47] yet [21:47] Ah. OK. [21:47] the logo font is still in the works, so not all the letters are complete yet [21:48] tell me mighty jono, why purple xD [21:48] when the font is done, a logo will be shortly arriving :) [21:48] zul: another php extension rebuild for you ^ [21:48] sebner, I think it looks cool :) [21:48] thats the not the reason though [21:48] :) [21:48] jono: is that our feminine side :P [21:51] I think the purple is hot [21:51] & very close to blue :) [21:52] better than brown but still .. [21:52] 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] 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] is anything in universe extended to the 5 yr support window? [22:23] micahg: It's all community supported and so to the extent the community supports it, the window is the same as Main. [22:23] ScottK: k, so in theory anything that's server only could br patched for 5 yrs? [22:24] micahg: Yes. [22:25] Personally, I'm still supporting clamav on Dapper. [22:25] ScottK: cool, thanks [22:25] ScottK: can we backport universe packages as well in -backports? [22:28] micahg: Yes. [22:29] very cool :) [22:29] * micahg thinks he'll be testing backports for Lucid for a while :) [23:12] perhaps we need a "sponsor day" or something suitably silly [23:13] if bug days are called hug days, I *cringe* at the non-PG name for sponsor bribing days [23:13] (kidding!) [23:30] No you aren't. [23:44] crimsun: Why a "sponsor day"? Lately the universe queue rarely grows beyond 10 bugs. [23:44] persia: it's half tongue-in-cheek [23:45] Oh, heh. [23:45] I'll gladly switch places with someone to work on it, though :-) [23:46] 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] 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] hmm, armel buildds now fail after encountering implicit declaration warnings, correct? [23:49] I didn't think they had any special logic that differed from other buildds. [23:49] yeah, they do (and ia64 as well) [23:50] otherwise I wouldn't have located those bugs in pulse. D'oh, bad memory. [23:50] arb is such a crufty source package [23:51] heh