[00:16] <jbicha> wow, no amd64 builders for PPAs :(
[00:17] <penguin42> wasn't the some maintenance of that due to happen this week?
[03:36] <pitti> Good morning
[03:37] <ajmitch> hi pitti
[04:45] <tjaalton> slangasek: excellent, thanks. yeah I bet the peformance could be better..
[07:07] <dholbach> good morning
[07:19] <shadeslayer> wohooo
[07:19] <shadeslayer> dholbach: morning :)
[07:20] <dholbach> hey shadeslayer :)
[07:20] <shadeslayer> o/
[07:20] <shadeslayer> cjwatson: can't build ISO's, X stack went kaput :P
[07:20] <shadeslayer> it's one problem after another it seems ;)
[07:22] <pitti> http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html does not have X.org any more, though
[07:22] <pitti> (it has mostly NBS binaries)
[07:23] <shadeslayer> http://paste.kde.org/538460/ < most certainly broken ( try installing xserver-xorg-video-geode )
[07:23] <shadeslayer> possibly something hasn't been published
[08:07] <brendand> i am trying to do a net install on some servers, and it seems like since yesterday, dhcp configuration is failing
[08:07] <brendand> is anyone aware of this issue?
[08:13] <pitti> infinity: hm, still so many disabled PPA builders?
[08:15] <seb128> pitti, I'm talking about it on #is
[08:15] <seb128> pitti, we got 3 back
[08:15] <seb128> pitti, so progress ;-)
[08:16] <pitti> nice
[08:16] <pitti> still, three amd64 builders which all build "private jobs"
[08:16] <pitti> (and only 3 available)
[08:17] <pitti> but as long as it's known, I'm fine
[08:20] <seb128> pitti, they are working on it apparently, fingers crossed
[08:32] <cjwatson> shadeslayer: I'm working my way through analysing a stack of failures right now, including that one
[08:34] <cjwatson> My inbox was pretty unhappy this morning
[08:44] <dholbach> ev, mpt: it'd be great if you could have a look at http://benjaminkerensa.com/2012/08/23/canonical-privacy-policy-for-zeitgeist-is-insufficient and see if there's anything you would add
[08:45] <seb128> dholbach, ev, mpt: the title seems misleading, the guy is rather concerned about the "datas sent to canonical" part and unsure if that includes zg datas since they are in the same settings panel
[08:46] <dholbach> yes - that's what I tried to explain in the last comment
[08:47] <ev> seb128, dholbach: I could be mistaken, but I think mpt was already working with Andrew Sinclair on the text
[08:47] <mpt> Yes, he's just being very slow.
[08:47] <seb128> it would probably be good if somebody commented on the launchpad bug saying that it's being worked?
[08:48] <mpt> sure
[08:48] <seb128> mpt, thanks
[08:52] <seb128> pitti, 9 amd64 builders
[08:52] <pitti> I saw \o/
[09:31] <hrw> question: how to make package which uses cdbs to generate dbgsym?
[09:33] <seb128> hrw, dbgsym are nothing to do with the source, just install pkg-create-dbgsym
[09:33] <seb128> it will create the ddebs for you
[09:34] <hrw> seb128: if package calls dh_strip
[09:34] <seb128> right
[09:34] <hrw> ah.. wrong build I looked at. sorry
[10:38] <rsalveti> tjaalton: mind reviewing bug 1040405 ?
[10:39] <rsalveti> there's also another patch for xf86-video-omap to properly use the platformProbe call
[10:40] <rsalveti> which makes the probe a lot easier, and without conflicting with the fbdev device (which checks for the platform slot before initializing itself, same as it was doing already for pci based devices)
[10:43] <rsalveti> tjaalton: and at the bottom of bug 1015292 you can see the debdiff for xf86-video-omap
[10:43] <rsalveti> would be nice if you could also review it
[10:44] <rsalveti> just tested both at my panda, and worked nicely (by autoloading just the omap driver)
[10:56] <dholbach> dpm, ogra_: do you think you can update https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable with a session title? :)
[10:57] <dpm> dholbach, yeah, let me think of something later on today. TBH, I got inspired by ogra_'s title, so I thought I'd use a similar one until I've got something set up ;)
[10:58] <dholbach> yeah, I know - ogra_ is a very deep source of inspiration
[10:58] <dholbach> :-P
[10:58] <dpm> absolutely
[11:00] <bdrung> dholbach: should i add ubuntu-packaging-guide to packaging-dev?
[11:00] <dholbach> bdrung, ah yes - if that's possible, that'd be great
[11:00] <tjaalton> rsalveti: great, thanks
[11:03] <bdrung> dholbach: shouldn't we get this package into debian, too?
[11:04] <dholbach> if anybody wants to help with doing that, that'd be great - yeah :)
[11:04] <bdrung> dholbach: i offer my help
[11:04] <dholbach> :-D
[11:10] <Andy80> dholbach, hi! even this link http://developer.ubuntu.com/packaging/singlehtml from this page http://developer.ubuntu.com/resources/tools/packaging/ is broken.
[11:10] <dholbach> Andy80, yes - it's on my list :)
[11:10] <Andy80> cool ;)
[11:12] <Andy80> dholbach, I'm re-reading for the *n time the packaging docs. There is a python application that I use that is not available in repositories yet. I want to start with that... it's just a simple one :) p.s: no, not telling the name in public or someone faster than me will package it removing me the motivation to learn :D
[11:15] <dholbach> Andy80, keep your motivation, but ask if you run into trouble, ok? :)
[11:16] <Andy80> dholbach, sure :)
[11:23] <Andy80> the first thing I don't understand is this command: bzr dh-make hello 2.7 hello-2.7.tar.gz - what it does exactly? What if my source code is not on bazaar?
[11:25] <dholbach> Andy80, AFAIK it will import the hello-2.7.tar.gz tarball you have on your disk locally into a fresh and new bzr branch
[11:25] <dholbach> and give you some initial packaging
[11:25] <dholbach> if it's not clear enough in the guide, please file a bug :)
[11:26] <Andy80> dholbach, ah ok. yeas it makes sense... I mean, the person who is packaging is supposed to upload the sources and debian/ folder on launchpad so other people can check it.
[11:27] <Andy80> I will just read for now since as I told you my app is not compilable with "make", it's a Python app and I want to read the differences explained here: http://developer.ubuntu.com/packaging/html/python-packaging.html before executing any command
[11:28] <Andy80> (other than this I'm not at home right now and I don't have my .gnupg and .ssh with me .... so better not to upload anything)
[11:28] <dholbach> you can build it locally by running: bzr bd
[11:30] <Andy80> ok, I finish reading in the mean time, thanks :)
[11:45] <TJ-> Have there been any changes from Precise onwards that would affect mmap() - in particular that could cause it to run out of VMA on amd64 for quite modest requests to map a device file?
[12:37] <Guest47874> !lista
[12:46] <Andy80> about this document http://developer.ubuntu.com/packaging/html/python-packaging.html - to package a Python application I do have to use dh_python2 instead of dh_make ? Does my app need to have a setup.py already? What if it's just one *.py file and I need the debian/install to copy it to /usr/bin folder? Thanks
[12:47] <cjwatson> dh_python2 and dh_make are quite different categories of things, despite the similar name
[12:47] <cjwatson> dh_python2 is a tool run as part of the execution of debian/rules
[12:48] <cjwatson> dh_make is a tool that writes out template packaging files for you to modify, including debian/rules
[12:49] <cjwatson> if it's just one .py file, you should likely install it by hand in an override_dh_auto_install: rule in debian/rules rather than listing it in debian/install, since dh_install (which processes debian/install) will preserve the extension and policy says that programs in /usr/bin/ should not have a scripting language extension such as .py
[12:55] <tjaalton> slangasek: uploaded mesa, libxatracker linking seems ok to me at least on amd64
[13:05] <mr_pouit> seb128: hey, you wrote about indicators only in your mail ("they will still keep gtk2 versions of
[13:05] <mr_pouit> the libraries")
[13:05] <mr_pouit> seb128: yet libido is gone for gtk2 I think
[13:06] <Andy80> cjohnston, thanks in the mean time! I need to go home, I email me the chat history and I'll continue it later. Se you later and thanks :)
[13:06] <seb128> mr_pouit, well, I meant public libraries (the ones for applications to use, like libappindicator)
[13:07] <mr_pouit> (yeah, of course, ido isn't a public library in /usr/lib I guess)
[13:07] <mr_pouit> meh :(
[13:08] <mr_pouit> seb128: any more surprise? :P (so I know how many packages I need to reintroduce for Lubuntu/Xubuntu)
[13:10] <seb128> mr_pouit, surprise: you can count on any indicator-*-gtk2 to go away if there are still some in quantal
[13:11] <mr_pouit> seb128: yeah, I know, but any more surprise starting with lib* ? ;-)
[13:11] <xnox> bryceh: are you ~bryce? anyway love your e2fsprogs upload =)
[13:11] <seb128> mr_pouit, no, is libido even having an user out of indicator-sound?
[13:12] <seb128> mr_pouit, but you are right, it should probably have been made a private lib to indicators
[13:13] <seb128> mr_pouit, sorry about that
[13:15] <mr_pouit> (no big issue, that's just one more thing to do before indicator-sound-gtk2 is back)
[13:32] <smoser> anyone else seen delayed response on middle mouse paste in ubuntu?
[13:32] <smoser> its happening more an dmore that i highlight copy and something (likely from firefox) , hit middle mouse to paste it, hit enter, and then the paste happens.
[13:33] <smoser> this often results in me trying to execute whatever i copied and pasted rather than giving it as input to some command.
[14:03] <tjaalton> rsalveti: the changes looked good, uploaded
[14:04] <rsalveti> tjaalton: great, thanks!
[14:12] <mvo> ev: if you have time for the software-center polkit branch review that woudl rock, I would love to get it in today
[14:13] <ev> mvo: will do!
[14:33] <vibhav> Are there any WNPP bugs in Ubuntu?
[14:33] <cjwatson> "needs-packaging" is the equivalent
[14:33] <cjwatson> (tag)
[14:34] <vibhav> cjwatson: yeah, but are there any "RFA" bugs?
[14:35] <cjwatson> Not as far as I know.
[14:38] <vibhav> thanks
[14:47] <xnox> vibhav: all packages are team maintained in ubuntu. You can look for "needs-packaging" tag & merges.ubuntu.com for things to do.
[14:48] <xnox> as well as *wishlist* bugs, cause that's usually new feature requests.
[15:04] <slangasek> pitti: (grr) the retracer invalidated my bug because it was a package that depended on initscripts and it didn't have current dbgsyms for initscripts (bug #1040680)
[15:06] <alo21> hi all
[15:07] <alo21> can I send a package in Upstream when I fix some bugs (not security)?
[15:17] <rsalveti> hallyn: hey, mind reviewing the merge proposal https://code.launchpad.net/~fboudra/qemu-linaro/new-upstream-release-1.1.50-2012.08-0ubuntu1/+merge/120592 ?
[15:18] <rsalveti> fabo worked on updating the qemu to the latest one available from linaro
[15:18] <rsalveti> and would be nice if someone else could also review and test it
[15:18] <rsalveti> so we can try to land at quantal asap
[15:18] <pitti> slangasek: it currently invalidates bugs if the retraced stack trace is bad and there are obsolete or missing packages; I guess in this case the retracing failed due to another reason, though (sometimes the memory is just too corrupted, and sometimes I have the feeling gdb is just not trying hard enough..)
[15:19] <pitti> hmm, libdbus doesn't like to be symbolic?
[15:38] <slangasek> pitti: ah, ok
[15:42] <hallyn> rsalveti: sure
[15:42] <rsalveti> hallyn: thanks!
[15:51] <TJ-> Has anyone seen/heard of problems with the nvidia driver 295+ failing some mmap() requests?
[15:51] <hallyn> rsalveti: I'm not sure, but debian/patches/define_AT_EMPTY_PATH.patch *may* not be needed any more.  The fix to libc may have gotten into q.
[15:52] <hallyn> (no biggie )
[15:52] <rsalveti> hm, nice
[15:54] <hallyn> rsalveti: is dropping --disable-darwin done on purpose?
[15:54] <hallyn> (i don't knwo what it is :)
[15:56] <rsalveti> I think it got removed from upstream
[15:57] <hallyn> rsalveti: ok - i see no problems with it.
[15:57] <hallyn> (commented)
[15:58] <infinity> hallyn: The fix is definitely in Q, yes.
[15:58] <infinity> hallyn: (and uploaded to P)
[15:58] <hallyn> rsalveti: infinity: yeah just saw it in changelog
[15:58] <hallyn> rsalveti: so you can drop that patch if you like.  but doesn't hurt anything
[15:58] <rsalveti> yeah, great
[15:59] <rsalveti> thanks for the review
[16:00] <hallyn> np
[16:09] <hallyn> rsalveti: and, confirmed i just pulled it out of qemu-kvm build on quantal and that worked fine too.  (\o/)
[16:11] <rsalveti> hallyn: awesome, thanks!
[16:15] <stgraber> hallyn: just checking, have you seen my PMs and messages to #ubuntu-server? (I remember you had issues with PMs in the past ;))
[16:22] <bigon> is there still any login in splitting geoclue package in geoclue and geoclue provider?
[16:25] <hallyn> stgraber: oh, i may not have.  i'm back to using irssi, but byobu has been crshing for me every few weeks at night, and did again last night
[16:25] <hallyn> i gots logs, lemme check
[16:25] <seb128> bigon, login in?
[16:26] <bigon> seb128: mmmh?
[16:26] <seb128> bigon, I don't understand the question
[16:27] <seb128> bigon, what "is there still any login in..." mean?
[16:27] <hallyn> stgraber: sorry, i guess i may need to add a lxc-start-ephemeral test to the testsuite
[16:27] <bigon> mehhh
[16:27] <bigon> seb128: s/login/logic
[16:27] <hallyn> stgraber: i'm quite sure i pushed the lxc-attach v2 changes.  i'll substitute v3 today or tomorrow.
[16:27] <bigon> time to go home I guess
[16:27] <seb128> bigon, ooooh
[16:27] <hallyn> stgraber: do you need anything more from me before ff?
[16:27] <seb128> bigon,
[16:27] <seb128>   * debian/control
[16:27] <seb128>     - Split the gypsy, gpsd, and gsmloc providers out into
[16:27] <seb128>       a separate source package, geoclue-providers, to simplify the
[16:27] <seb128>       MIR reducing the number of build depends.
[16:27] <seb128>     - Removed ofono-dev and libgypsy-dev build depends
[16:28] <seb128> bigon, does geoclue still use ofono-dev and libgypsy-dev?
[16:28] <seb128> bigon, if the reply is "yes" so the reason still stand
[16:29] <stgraber> hallyn: sorry, was blind, I didn't see you indeed pushed it, so nothing needed on your side
[16:29] <bigon> do we want these provider? in debian gypsy is not built (due to the huge security fail that it contained), gpsd is not even building iirc
[16:29] <bigon> the only remaning one is gsmloc
[16:29] <seb128> kenvandine, tedg: ^ do you know?
[16:29] <hallyn> stgraber: cool, thanks.
[16:30] <seb128> bigon, I don't know, I guess not
[16:31] <tedg> I don't really know, but I imagine it'll be something we have to fix at some point.
[16:31] <tedg> I mean, if it's disabled today, that's fine.
[16:32] <bigon> the thing is that I'm not sure about the mismatch of version between geoclue and geoclue-provider pkg
[16:32] <seb128> bigon, it just means nobody has been maintaining and updating geoclue-provider
[16:32] <seb128> we should probably just drop it
[16:41] <bigon> I also guess that the main geoclue pkg should be remerged with the debian one
[16:41] <seb128> ok
[16:47] <roaksoax> Hi gusy I have a packaging question. 'maas' currently Depends on 'maas-provision', however, the newer 'maas' I'll upload no longer does. So I was wondering what should be in debian/control in order for 'maas-provision' to be uninstalled on upgrade
[16:49] <cjwatson> roaksoax: Is maas-provision intended to be removed from the archive?
[16:49] <roaksoax> cjwatson: yes
[16:51] <cjwatson> roaksoax: Then Conflicts: maas-provision + Replaces: maas-provision
[16:51] <cjwatson> You might need Provides as well if other packages currently depend on maas-provision (but you often don't)
[16:52] <roaksoax> cjwatson: right, so that's what I was thinking, but manually testing I got something like "can't remove maas-provision because maas (older version) still depends on it"
[16:54] <slangasek> roaksoax: manually testing with dpkg, or with apt?
[16:54] <roaksoax> slangasek: dpkg
[16:54] <slangasek> roaksoax: wrong tool :)
[16:54] <slangasek> roaksoax: you either need to pass a slew of additional options to dpkg to accurately test this, or you should test using apt
[16:55] <roaksoax> slangasek: alright! I'll get it tested with apt! Thanks for the info :)
[16:56] <cjwatson> additional options> -B, I think
[16:57] <cjwatson> But yeah, use apt
[17:03] <shadeslayer> cjwatson: re : <cjwatson> My inbox was pretty unhappy this morning > haha :D
[17:06] <mlankhorst> can xf86-video-omap be moved into main?
[17:07] <shadeslayer> mlankhorst: file a MIR request?
[17:08] <ogra_> that shouldnt need a mir
[17:08] <BadDesign> What is the UTC release time for Ubuntu 12.04.1?
[17:08] <infinity> Sure it should.  It's new code.
[17:08] <infinity> Not that it'll be a hard MIR to process.
[17:09] <mlankhorst> it was a continuation from omapfb I think
[17:09] <ogra_> right
[17:09] <infinity> It's basically a rewrite, from what I understand.
[17:09] <infinity> But meh.
[17:10] <infinity> Either way, I think it's an obvious promotion.
[17:10] <infinity> How about we do an informal MIR.
[17:10] <infinity> jdstrand: Do you have security concerns about promoting the X driver for omap* ?
[17:11] <jdstrand> infinity: not especially other than to ask who the upstream is and how responsive are they?
[17:11] <cjwatson> BadDesign: We never hand out release times in advance.
[17:11] <infinity> jdstrand: Upstream is Rob Clark from TI, plus the general X usual suspects.
[17:12] <ogra_> its the same person maintaining the omap4 binary driver at TI
[17:12] <cjwatson> BadDesign: Largely because we generally simply don't set a time.
[17:12] <jdstrand> infinity: so we can expect support in the event of a security concern?
[17:12] <ogra_> ++
[17:12] <infinity> jdstrand: Absolutely.
[17:12] <jdstrand> ok, then no, I don't have conerns
[17:12] <mlankhorst> great :)
[17:12]  * ogra_ hugs jdstrand 
[17:12] <infinity> Yeah.  Alright.  And I already reviewed packaging and such when I synced it from Debian.
[17:12] <infinity> So.
[17:12] <infinity> There.  MIR done.
[17:12] <infinity> :P
[17:13] <jdstrand> heh
[17:13] <ogra_> :D
[17:13] <mlankhorst> awesome
[17:13]  * infinity goes to find some place to seed it.
[17:14] <infinity> Actually, it should get pulled in without seeding, if it's in drivers-all on arm*
[17:14] <ogra_> infinity, i think mlankhorst planned to have it in the -all package for xorg
[17:14] <infinity> And if it's not, that's a bug.
[17:14] <infinity> mlankhorst: Is it in drivers-all already?
[17:14] <mlankhorst> well I prepared it, I can't push directly
[17:14] <infinity> mlankhorst: I can, though.  Where do I find it?
[17:14] <ogra_> i think tjaalton is on it
[17:15] <infinity> Oh, snazzy.
[17:15] <infinity> Well, if I know it's going to land soon, I'll just do the promotion.
[17:16] <infinity> mlankhorst: Promoted.  Please make sure that whoever's sponsoring that change does it soon, so component-mismatches doesn't spend the next day yelling at me.
[17:17] <mlankhorst> infinity: oh if you want you can do it now
[17:17] <mlankhorst> http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xorg.git;a=shortlog;h=refs/heads/ubuntu
[17:20] <infinity> mlankhorst: Want to commit a dch -r to that, and give me a source package to sponsor?
[17:20] <infinity> mlankhorst: (I don't have commit to pkg-xorg)
[17:20] <mlankhorst> oh sure
[17:24] <mlankhorst> infinity: done
[17:29] <infinity> mlankhorst: Thanks, that'll do.
[17:30] <infinity> mlankhorst: Uploaded.
[18:24] <mlankhorst> yay
[18:24] <mlankhorst> time to update my panda to quantal I suppose :)
[18:37] <goddard> Contributing to the Ubuntu Wiki is a pain
[18:38] <goddard> Any plans to change it?
[18:40] <mlankhorst> howso? just create a account?
[18:43] <goddard> you would think it is that easy
[18:44] <goddard> but when i last contributed i had to actually download a bzr package, edit it, build html, and upload it
[18:45] <goddard> I did some contributions to the packaging guide
[18:47] <slangasek> wiki.ubuntu.com doesn't involve any of those things; what wiki are you talking about?
[18:49] <xnox> goddard: well yes, packaging guide and e.g. server guide etc. do require that, because they are not hosted on the wiki, but rather available in a few formats & translations
[18:49] <xnox> goddard: help.ubuntu.com/community and wiki.ubuntu.com can be edited directly in the web-browser.
[19:00] <goddard> ahh i see
[19:01] <goddard> is there a reason why the packaging guide isn't on the wiki as well?
[19:13] <mlankhorst> goddard: because they have to be shipped separately and not only to the wiki :)
[19:47] <xnox> goddard: because packaging guide can be translated, and the wiki does not support translations.
[19:48] <TJ-> A recent change to the nvidia DKMS drivers package has broken another package such that it won't conceivably ever work again. What's the procedure in such cases?
[19:48] <infinity> TJ-: That might need to be slightly less vague.
[19:49] <TJ-> infinity: bug #1039916 ... look at the last comment
[19:49] <infinity> TJ-: But if it's "some third-party tool relied on a feature that the upstream binary driver no longer provides", the solution would be to (A) remove the third-party tool from the archive, and (B) make the nvidia packages conflict with it.
[19:49] <infinity> Oh, in precise, we wouldn't do the removal bit.
[19:50] <infinity> But certainly, having the driver conflict with the tool, if there's really no way to fix the tool, would work.
[19:50] <TJ-> OK... it'll affect Q too of course
[19:52] <infinity> TJ-: You might also want to talk to Marc, since it was his patch that broke things (now that I've read the whole bug report).
[19:53] <infinity> TJ-: But if it's a tradeoff between dimmer control and priviledge escalation, with no way to compromise on fixing both, I suspect security wins.
[19:53] <TJ-> infinity: Yes, I was planning on emailing him. I think the patch is a good one - nvclock is using not-quite-approved hacks to do its thing, so I think nvclock has to give
[19:54] <TJ-> infinity: There is an alternative project developing for an nvida backlight DKMS kernel module that - when/if it works - does things properly with a /sys/class/backlight/ interface... so I think that should be the preferred route
[19:54] <infinity> TJ-: That does seem to be the saner way forward, yeah.
[19:55] <TJ-> infinity: besides which I think nvclock has been abandoned by its creator since 2009/10
[19:55] <TJ-> infinity: thanks; I'll figure out who to contact and what to do to let users of nvclock aware and remove it for Q
[19:58] <infinity> TJ-: I can remove it from the archive for Q right now, if you think that's the Right Thing To Do, but it'll still need the nvidia-* packaging updated to conflict and force removal on upgrades.
[19:58] <TJ-> infinity: Let me check first... if nvidia proprietary isn't used by nouveau or the old nv is, nvclock may still work
[19:59] <TJ-> infinity: And all I really wanted was the backlight dimming *sigh* :p
[20:06] <nabam> Not certain if this is the correct channel to ask this, but in using patch, is it a possibility to ignore a specific line?
[20:28] <Andy80> I'm working on packaging a project and I want to put my file on LP. Is it ok if I push using this url: bzr push lp:~andreagrandi/PACKAGENAME/packaging ?
[20:31] <alesage> Andy80, sounds fine--if not I've been doing it wrong :)
[20:32] <Andy80> alesage: I already tried with bzr push lp:~andreagrandi/PACKAGENAME but it wasn't enough.... maybe the last part is mandatory
[20:32] <Andy80> :)
[20:32] <Andy80> let's try...
[20:33] <Andy80> uhm..... LP says noooooo :\
[20:33] <Andy80> actually "PROJECTNAME" doesn't exist...
[20:33] <Andy80> maybe I should use +junk ?
[20:33] <Andy80> but it's so odd name...
[20:35] <roaksoax> slangasek: so the conflicts/replaces works. However, what about some of the dependencies of maas-provision (dnsmasq, tftp-hpa specifically). I'm currently listing them under conflicts/replaces too but don't know whether that's the correct approach since they only overlap functionality (and not files, etc)
[20:35] <Andy80> ok, pushed in junk
[20:40] <xnox> Andy80: bzr push lp:~/ubuntu/quantal/PACKAGENAME/packaging
[20:43] <Andy80> xnox: it's not a package already available in Ubuntu (I'm not a MOTU or something like that neither). I'm just getting started. It's a simple Python utility and I'd like to package it. I've put it in my /+junk/
[20:43] <slangasek> roaksoax: you certainly shouldn't conflict/replace with those, they're not obsolete packages and users can legitimately install them on the same host
[20:44] <slangasek> roaksoax: oh, or do they fight over the ports?
[20:44] <xnox> Andy80: that's ok then. you could try pushing, it should create a new package name.... I think... maybe not.
[20:44] <roaksoax> slangasek: they fight over ports
[20:44] <slangasek> roaksoax: ok; a bidirectional conflicts is allowed there - see tftpd-hpa, which already Conflicts: tftpd
[20:46] <xnox> I presume EXTLINUX is the new bootloader thing...
[20:46]  * xnox is confused why I am having it on non-efi system, but ok =)
[20:47] <roaksoax> slangasek: cool, thanks!!
[20:48] <slangasek> xnox: no, EXTLINUX is a very old bootloader thing
[20:48] <slangasek> efilinux is the EFI one
[20:51] <xnox> slangasek: i now ponder why did I install it back in january
[21:38] <seb128> ev, is errors.ubuntu.com known to have issues? it stays on "Loading" it seems
[21:38] <stgraber> seb128: try /?launchpad=false
[21:39] <seb128> in fact worked after a retry but it's very slow
[21:39] <seb128> stgraber, thanks
[23:29] <xnox> me wonders if I can "just do it" bug 1038577 is annoying
[23:29] <xnox> ... just needs rm maintainer script...
[23:32] <slangasek> xnox: of course you can
[23:32] <slangasek> I would have myself, but I wasn't sure whether it was better to rename the conffile back to the original name, or deal with the move
[23:32] <xnox> slangasek: i'm off to find the correct branch....
[23:33] <xnox> slangasek: hmm... did upstream rename it? did debian rename it? decisions... decisions... decisions...