[00:00] <RainCT> canesin: What makes it a bit more complicated right now is that Maverick is in "Feature Freeze", which means no new stuff is allowed in. If there is a good reason to have this new paraview version, you can file a bug and explain why it'd be good to have and how risky it might break as opposed to the current version (this is called a Feature Freeze Exception request)
[00:07]  * zooko reads about backports
[00:08] <zooko> Neat.
[01:11] <micahg> bdrung: did I read somewhere about a new vlc PPA?
[01:12] <bdrung> micahg: not on my blog, but i have setup one
[01:12] <micahg> bdrung: stable releases?
[01:12] <bdrung> micahg: nope, bleeding edge (1.2.0~git)
[01:13] <micahg> bdrung: :(, any chance of a stable PPA?
[01:13] <micahg> or should I backport on my own?
[01:13] <bdrung> micahg: https://edge.launchpad.net/~videolan/+archive/master-daily
[01:14] <bdrung> micahg: you can ask me nicely when i am back from my vacation and i will setup one
[01:14] <micahg> bdrung: I can help maintain if you want :)
[01:16] <bdrung> micahg: if you want to build your own one locally, grab the maverick git branch and use this patch: http://pastebin.com/E4eb2CSE
[01:18] <micahg> bdrung: is that for Lucid or maverick
[01:19] <bdrung> micahg: that is for lucid
[01:19] <micahg> bdrung: k, thanks
[01:19] <bdrung> micahg: for maverick you can just use the maverick branch :)
[01:19] <bdrung> micahg: but instead of a vlc ppa, we could backport vlc 1.1.3-1+exp1ubuntu1 with the posted patch
[01:20] <micahg> bdrung: do you want to backport for every release?
[01:20] <bdrung> micahg: no, for lucid
[01:20] <micahg> bdrung: I meant for Lucid for every release :)
[01:20] <bdrung> micahg: if it's not too much work.
[01:21] <bdrung> micahg: at least one backport would be nice (look at the 1.1.0-1 changelog)
[01:21] <micahg> bdrung: I'm not in a position to join backporters yet, but you could :)
[01:24] <bdrung> micahg: i want to try to backport something. for self consumption i have a backports PPA: https://launchpad.net/~bdrung/+archive/backports
[01:24] <micahg> bdrung: I have one as well :)
[01:25] <micahg> bdrung: the only problem with sending vlc to backports is to keep it updated if there's a security vulnerability
[01:26] <bdrung> micahg: if we backport the same version that will end up in maverick the workload will not be increased that much
[01:27] <micahg> bdrung: well, I think with backports, tis better to update than patch, but I could be wrong
[01:27] <micahg> can we even patch stuff in backports?
[01:28] <bdrung> micahg: dunno. backporting the fixed version is probably the way to go
[01:30] <micahg> bdrung: are you waiting to see if you can sync from expermental before uploading to maverick?
[01:30] <micahg> bdrung: nm, I remember the issue now
[01:31] <bdrung> micahg: i am waiting for siretart to upload the packages to sid and experimental
[01:31] <micahg> bdrung: ah, ok
[01:31] <bdrung> micahg: then i will upload the package to maverick
[01:32] <bdrung> micahg: i will sync the experimental package once x264 is accepted in debian
[01:32] <bdrung> micahg: if this needs as long as mplayer, it will be in one year ;)
[02:06] <bdrung> micahg: time to say goodbye. i will be on vacation tomorrow
[02:06] <micahg> bdrung: enjoy your vacation, anything I can keep an eye on for you while you're goine?
[02:07] <bdrung> micahg: the sponsor queue :)
[02:07] <micahg> bdrung: I can't do much with it, but I'll watch my stuff :)
[02:07] <bdrung> micahg: everything that is listed on https://wiki.ubuntu.com/BenjaminDrung
[02:07] <micahg> bdrung: vlc's the only think I can do anything with
[02:07] <micahg> oh, eclipse too
[02:08] <bdrung> micahg: you could talk with nthykier on #debian-java - we need to sync -6 (once released). and there are new reports that it doesn't work
[02:09] <micahg> bdrung: k, what tz is he in?
[02:10] <bdrung> micahg: mine - utc + 0200
[02:11] <micahg> bdrung: will try him in the morning then
[02:11] <bdrung> micahg: he lives in Denmark
[02:13] <micahg> bdrung: k, well, enjoy, I'll keep an eye on vlc and eclipse then, if siretart doesn't get to it until tomorrow, can I assume you're gone and do the merge?  Do we need an FFe?
[02:13] <bdrung> micahg: i probably check my mails in between. otherwise i will have ~2000 mail when i come home
[02:13] <micahg> nm, you did the merge, I mean upload :)
[02:13] <micahg> bdrung: k, I won't worry about that one then
[02:14] <micahg> but will try to get 3.5.2-6 for eclipse in
[02:14] <bdrung> micahg: if i am gone, you can ask siretart to do the maverick upload (it's prepared in the maverick branch)
[02:15] <bdrung> micahg: i talked with the release team. we don't need a FFe for vlc
[02:15] <micahg> bdrung: k, you know I have upload rights for it, right?
[02:15] <bdrung> micahg: have you access to the git repository?
[02:16] <micahg> bdrung: pkg-multimedia?
[02:16] <bdrung> micahg: yes
[02:16] <micahg> bdrung: yes, I'm a junior dev
[02:18] <bdrung> micahg: k, then you could do it, too
[02:19] <micahg> bdrung: k, if I have any questions, I'll ask siretart
[02:19] <bdrung> yes
[02:26] <micahg> bdrung: I"ll be back in about an hour, you can always send email to my nick at ubuntu dot com if you need something
[02:26] <micahg> bdrung: once again, enjoy your vacation :)
[03:11] <lfaraone> How can I figure out why a package that was in Lucid and is in Sid is not in maverick? searching for "packagename remove from maverick" does not give me antyhing usesul.
[03:11] <lfaraone> *anything useful
[03:15] <bdrung> lfaraone: which package?
[03:15] <lfaraone> bdrung: libunicode-map8-perl-dfsg was formally in main.
[03:16] <lfaraone> bdrung: now it's not shipped. libunicode-map8-perl (which is in sid) was in dapper but no other release after that.
[03:16] <bdrung> lfaraone: https://launchpad.net/ubuntu/+source/libunicode-map8-perl-dfsg/+publishinghistory
[03:16] <bdrung> (From Debian) [auto-cruft] obsolete source package
[03:16] <lfaraone> makes sense, there's no libunicode-map8-perl-dfsg in debian, because it's libunicode-map8-perl. But libunicode-map8-perl isn't there either <_<;
[03:17] <bdrung> lfaraone: then request a sync of libunicode-map8-perl and provide all information for a FFe
[03:18] <lfaraone> bdrung: working on it.
[03:18] <bdrung> good night
[03:18] <lfaraone> bdrung: thanks
[03:18] <bdrung> you're welcome
[05:00] <LucidFox> I wonder if it's possible to have the same package version in Debian and Ubuntu while building with indicator libraries only on Ubuntu
[05:01] <LucidFox> Something like, Build-Depends: libappindicator-dev | not-ubuntu
[05:05] <micahg> LucidFox: worth a simple delta
[05:07] <LucidFox> micahg> Even when I'm the maintainer in both? -_-
[05:08] <micahg> LucidFox: yes :), unless there's already a convention for what you're proposing :)
[05:08] <micahg> LucidFox: maybe ask in #debian-ubuntu
[05:15] <wgrant> Or push indicators into Debian :)
[05:15] <wgrant> Although I get the feeling that anybody trying that would not survive for long.
[05:15]  * micahg thinks someone was working on that
[05:16] <micahg> wgrant: http://lists.debian.org/debian-devel/2010/06/msg00293.html
[05:50] <nigelb> LucidFox: might want to talk to kartik and evgeni @ debian end of things
[07:36] <Zhenech> lucidfox, huh? (I'm evgeni)
[07:41] <lucidfox> Zhenech> Well, I just had an idea, to avoid introducing deltas, to have the same source package build with Ubuntu-specific libraries under Ubuntu and without them under Debian
[07:42] <Zhenech> lucidfox, from what I've observed, the deltas are usually only the thing that ubuntu ships the packages as -0ubuntu1 earlier as we ship the -1
[07:43] <lucidfox> Zhenech> Erm
[07:43] <Zhenech> from the packaging point of view the deltas are zero
[07:43] <micahg> Zhenech: depends on the package
[07:43] <lucidfox> Thing is, suppose I'm the maintainer of a package in both Debian and Ubuntu, and I want -1 sync as is from Debian, but build with indicator libraries
[07:43] <Zhenech> debian has indicator libraries
[07:44] <Zhenech> so you could build on both systems with indicator?
[07:44] <Zhenech> (or is it something that needs your patched gtk to work with?)
[07:44] <lucidfox> libindicate, yes, libappindicator, no
[07:45] <Zhenech> ah, gimme a sec
[07:45] <Zhenech> do you mean https://launchpad.net/indicator-application ?
[07:46] <lucidfox> yep
[07:46] <lucidfox> Well, I suppose I could cheat and write something like libappindicator-dev | build-essential
[07:46] <Zhenech> thats ugly :)
[07:46] <lucidfox> to make it, essentially, a "soft build-dependency"
[07:47] <Zhenech> mh, maybe we should just pull appindicator to debian :)
[07:48] <micahg> Zhenech: there was a thread on debian devel a couple months ago about it
[07:49] <Zhenech> i added it to our wiki page as to be worked on :)
[07:51] <micahg> dholbach: good morning
[07:51] <dholbach> good morning
[07:52] <dholbach> hi micahg
[07:52] <micahg> dholbach: is there anywhere to track the progress of the new harvest?
[07:52] <dholbach> micahg, "bzr branch lp:harvest; less harvest/INSTALL" I'm afraid
[07:53] <micahg> dholbach: oh, is there a working copy up somewhere?  can I set up my own copy somewhere?
[07:53] <dholbach> we want to fix https://bugs.edge.launchpad.net/harvest/+bugs?field.importance=Critical and then get it deployed
[07:54] <micahg> dholbach: ooh, so soon?
[07:54] <dholbach> the new harvest has been in the making for quite lon
[07:54] <dholbach> g
[07:54] <dholbach> we can always get up new improvements later on
[08:07] <Zhenech> trying to build indicator-application
[08:10] <Zhenech> Couldn't find include 'Gtk-2.0.gir' (search path: ['.', '/usr/share/gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0'])
[08:10] <Zhenech> meh
[08:12] <Zhenech> gtk gir is in gir-repository-dev in debian
[08:15] <Zhenech> ok it at least built
[08:44] <and471> if I file a merge request for a package in ubuntu, do I subscribe ubuntu-sponsors to the bug report, or set ubuntu-sponsors as the reviewer of the merge request?
[08:45] <geser> I'd do both (if a bug exists but don't file a new one)
[08:45] <and471> ok
[08:45] <and471> vish, looks like geser agrees with you :)
[08:46] <vish> :)
[08:46] <vish> and471: iirc, only the bugs show-up in the sponsors list..
[08:49] <geser> vish: depends on which list you look: only the bug gets shown on LP but both get listed on http://qa.ubuntu.com/reports/sponsoring/
[08:50] <vish> geser: ah, neat..! that list is what is in the topic.. hence i had told him to do both :)
[08:50] <vish> wasnt sure which they might look at..
[08:51] <geser> probably depends on each sponsor
[08:58] <AnAnt> Hello
[08:59] <bilalakhtar> geser: but, for branch merges, I have always been told to set reviewer but never sponsor.
[09:00] <bilalakhtar> sorry
[09:00] <bilalakhtar> I have always been told to set reviewer but never subscribe to bugs
[09:00] <bilalakhtar> in case of branch merges ^^
[09:00] <geser> have you been told any reason?
[09:02] <geser> perhaps it changed in the last couple of months, but when I did my last branch merging, I also subscribed the sponsors team to the bug because of the poor visibility of merge requests at that time
[09:03] <vish> i dont see why doing both is gonna harm though..
[09:03] <vish> if some one reviews the bug they'd also be checking the merge of the list
[09:03] <vish> s/reviews/sponsors
[09:03] <geser> I wouldn't file a new bug but if a bug already exists, I see no reason why not subscribe the sponsors
[09:03] <vish> yeah , not a new bug
[09:06] <coolbhavi> geser, another thing after a sync request some update will be there say a ftbfs fix and I test that bug and update saying that this is a ftbfs fix for the present version reported in the sync will a sync always be uploaded in the original reporters name?
[09:09] <geser> I'm not sure
[11:35] <bilalakhtar> Rhonda: I forgot to ping you yesterday!
[11:35] <Rhonda> Oh, right!
[11:36] <bilalakhtar> Rhonda: np, give me another time to ping!
[11:42] <Rhonda> Will be offline the next week? :)
[14:14] <AnAnt> Hello
[14:26] <canesin> Hi all
[14:26] <canesin> =) .. here I'm again..
[14:26] <AnAnt> Hello
[14:27] <canesin> I have run the: grab-merge command and get :
[14:27] <canesin> *** WARNING ***
[14:28] <canesin> It looks like this package is maintained in revision control:
[14:28] <canesin> than i trow some git and svn adress
[14:28] <canesin> You almost certainly don't want to continue without investigating.
[14:29] <canesin> ???
[14:29] <canesin> Can some one help to merge that package ?? it is paraview..
[14:33] <tumbleweed> canesin: you *probably* don't need to worry about it. Many Debian Developers maintain their packages in version control systems, and ubuntu packages we've forked can be maintained in bzr branches on lp
[14:35] <canesin> tumbleweed: okay.. so I want to merge that package .. what should I do now ??
[14:35] <canesin> tumbleweed: I have run the grab-merge tool...
[14:36] <tumbleweed> canesin: if the Vcs URLs mentioned are *.debian.org you can ignore it (esp if it's a universe package)
[14:37] <canesin> tumbleweed: they are .debian.org
[14:37] <canesin> tumbleweed: so what now ??
[14:37] <tumbleweed> canesin: carry on with the merge
[14:38] <tumbleweed> canesin: you are aware that we are in feature freeze? (and so you'll need a freeze exception for merges that aren't purely for bug fixes)
[14:39] <canesin> tumbleweed: this is a major scientific application.. it is in 3.8.1 in Debian unstable.. and in years old 3.4.0 in Ubuntu
[14:39] <canesin> tumbleweed: to be true.. I believe all changes in the ubuntu one do not apply anymore to the current version
[14:39] <tumbleweed> you'll probably get your exception then, but you still need to file for it in your merge bug https://wiki.ubuntu.com/FreezeExceptionProcess
[14:40] <tumbleweed> yes, your merge should be for maverick. If a newever version is necessary in lucid too, follow the backporting process (once it's in maverick)
[14:41] <canesin> I have to wait for maverick launch ??
[14:47] <tumbleweed> canesin: no, you have to merge the new version of whatever this is into maverick, then you can get it backported to lucid (if it's needed there too)
[15:18] <AnAnt> Hello
[17:14]  * fabrice_sp has just seen that p.u.c knows about maverick packages now! Hurrahhh
[18:22] <ari-tczew> packages.ubuntu.com fixed \o/
[18:23] <ChogyDan> ari-tczew: yay!
[18:26] <ari-tczew> it's a pity, that scarcely now. I always use packages.ubuntu.com during stricte development cycle (till FeatureFreeze)
[21:02] <micahg> siretart: since bdrung is afk, I was going to try to update vlc this weekend in maverick, he finished everything in the git repo, but I have to reversion it since you changed the upload to experimental to be -2, will you be around this weekend at all if I run into any issues?
[22:34] <micahg> sistpoty: sorry thunderbird took so long, I was sick half the week
[22:35] <sistpoty> micahg: no worries (I mainly wanted it to not being dragged after beta), and big thanks for working on it!
[22:35] <micahg> sistpoty: np, do you need any help with release stuff for mozilla related apps this time around?
[22:36] <sistpoty> micahg: looks like noone cared about delegates yet :/
[22:36] <sistpoty> micahg: however if there's mozilla releated stuff to approve, I assume you'll offer to help, right?
[22:36] <micahg> sistpoty: I still want to try to get a few packages updated before beta if I can
[22:37] <micahg> sistpoty: sure, I'm a dev this time around as well :)
[22:37] <sistpoty> micahg: great, thanks!