[00:00] <maxb> Given 2.4 hasn't been removed from lucid yet, I was assuming 2.5 was not yet in jeopardy
[00:02] <ajmitch> I expect it'll be dropped to universe at least
[00:03] <ajmitch> installing python-all-dev doesn't grab python2.5-dev now, I believe
[00:03] <ajmitch> which bit me when trying to build something
[00:03] <maxb> Yup
[00:04] <ajmitch> the intent has been to only have 2.6 supported, which doesn't exclude having 2.5 in universe
[00:05] <maxb> Given Launchpad has had to maintain a PPA re-adding Python 2.4 support to jaunty/karmic packages, a PPA re-adding Python 2.5 support to lucid packages doesn't seem implausible as a stopgap measure
[00:06] <ajmitch> it does get a little annoying for 3rd parties like LP
[00:07] <maxb> I think it's good. Given how non-trivial 2.4->2.5 turned out to be, I dread to think what a pain a direct 2.4->2.6 upgrade would be like on a large codebase
[00:08]  * ajmitch is glad that the latest release of zope 2 supports python 2.6
[00:09] <maxb> Although I'm not a fan of Ubuntu's forced progress in all areas. Retrospectively, I think hal is being abandoned too soon
[00:09] <maxb> devkit-power just isn't there yet
[00:09] <ScottK> Most of the work for Python 2.6 in Debian is done.
[00:10] <maxb> Ah? What keeps them from switching default python right now?
[00:10] <ajmitch> ScottK: I've seen that, and it's good to see
[00:11] <ScottK> maxb: Maintainer won't upload it to unstable.
[00:11] <RoAkSoAx> ScottK, u here at UDS already?
[00:11] <maxb> Does the maintainer have a reasonable rationale for that?
[00:11] <ScottK> RoAkSoAx: Still in the air.
[00:12] <RoAkSoAx> ScottK, cool... I had not internet while flying :(
[00:54] <EzraR> there is no harm droping a depend on gnome volume manager right?
[00:56] <ScottK> EzraR: Why do you say that?
[01:01] <EzraR> ScottK: I am going to drop it from a package to fix a bug report
[01:01] <ScottK> EzraR: What bug?
[01:02] <EzraR> https://bugs.launchpad.net/ubuntu/+source/brdesktop-flavours/+bug/412643
[01:03] <EzraR> this package doesnt actually install anything, its just a list of recommends
[01:04] <EzraR> so really i would be droping it from the recommends not depends
[01:05] <ScottK> EzraR: Seems reasonable.
[04:38] <nigel_nb> hi, i'm looking for a little help about man pages
[04:38] <nigel_nb> can someone help me figure out how they are made?
[04:41] <micahg> nigel_nb: https://wiki.ubuntu.com/PackagingGuide/SupplementaryFiles#Man%20Pages
[09:26] <Laney> good morning
[09:26] <slytherin> Laney: good morning
[09:34] <directhex> it's a Laney! and a slytherin!
[09:34] <Laney> rawr
[10:00] <LucidFox> Evolution must be the most un-GNOME-like application shipped by default in Ubuntu.
[10:00] <slytherin> is auto import of sources from Debian stopped currently?
[10:00] <LucidFox> It feels like a KDE application that uses GTK for some reason.
[10:01] <Laney> slytherin: It's only semi-automatic - guess the required bodies are at UDS
[10:01] <Laney> my manual syncs from early last week still haven't been done either
[10:01] <slytherin> Laney: I know it is semi automatic but I was expecting that it should have been run at least once since lucid opened for development.
[10:01] <Laney> there were problems with the code crashing on v3 source packages
[10:08] <slytherin> hmm
[10:08] <directhex> i also have noticed a lack of syncitude
[10:08] <directhex> i blame bears
[10:09] <slytherin> LucidFox: Evolution is one of the most unstable software I have ever used. The only reason it is in default install is probably because of exchange support. Ironically even that is not stable.
[10:10] <LucidFox> Sad thing is, most email clients seem to focus on being yet another Outlook/Outlook Express clone instead of usability.
[10:10] <LucidFox> Thunderbird is the least cluttered one I've seen.
[10:10] <LucidFox> And even it is quite heavy.
[10:10] <slytherin> I hope anjal can replace evolution soon.
[10:11] <LucidFox> Hmm, never heard of it, let's give it a try
[10:12] <LucidFox> Ugh, ugly.
[10:13] <LucidFox> Still, this is a step in the right direction.
[10:13] <slytherin> LucidFox: Expected. It is quite new. Not even an year old.
[10:13] <LucidFox> Ideally I'd like something like Google Chrome, but for mail.
[10:14] <LucidFox> Instead of a cluttered Outlook-like UI that pops up a wizard on first start and wastes more space on combo boxes and buttons than on message content. :)
[10:14] <\sh> I would like to see a client which can deal with this *censored* exchange crap
[10:14] <siretart`> given that evolution's development is mostly closed, with programmers sitting in I think pakistan or india, I share your surprise that we don't have a better alternative...
[10:14] <achadwick> I quite like the idea of http://sup.rubyforge.org up to a point. Give it a saner, GUIish way of displaying email and a decent backend, and it might be a winner. Course then it wouldn't be sup, but hey...
[10:14] <\sh> siretart, claws-mail for standard mail stuff works...it's a mutt with GUI ;)
[10:15] <slytherin> siretart`: Any idea where in India? If it is not far from my place may be I will pay them a visit. :-P
[10:15] <siretart`> \sh: perhaps a good choice for xubuntu, but certainly not for a gnome desktop
[10:16] <\sh> siretart, oh well...I'm a pragmatic guy
[10:17] <siretart`> \sh: btw, may I take your latest mail to fai-devel that you are unsure if we really need to fall back to unionfs-fuse?
[10:17] <\sh> siretart, in the past we had problems with aufs right? and waldemar is also not sure if the latest aufs in karmic kernel helps us...
[10:18] <\sh> eventually I can check this out later this week..
[10:18] <siretart`> yes, last time I looked at fai the problem was to totally borked aufs in jaunty's kernel
[10:19] <siretart`> I really do hope that karmic's aufs works much better on nfs, but appaerently nobody hast tested that yet
[10:25] <siretart`> slytherin: look for a local Novel/Suse subsidiary
[10:25] <slytherin> hmm
[10:26] <LucidFox> \sh> claws-mail has a horrible icon theme, from the olden days of GNOME.
[10:26] <siretart`> if you are really interested, I can ask a new collegue here at work (he is affiliated with suse..)
[10:27] <LucidFox> And it's still cluttered and standing out in GNOME.
[10:27]  * siretart` uses and loves gnus. it will even be promoted to main for lucid :-)
[10:29] <\sh> LucidFox, really, I don't care about icons ;)
[10:29] <LucidFox> And text-based clients won't do either. It may not do me favor among kewl hackerz, but I'm a GUI person.
[10:30] <directhex> i agree
[10:30] <LucidFox> And I want a cohesive desktop based on the GNOME philosophy.
[10:30] <LucidFox> I'd like to see Chromium installed by default, for example.
[10:31] <directhex> gnome philosophy means epiphany ;)
[10:32] <LucidFox> Well, just because it's the official browser in GNOME doesn't make it the best.
[10:32] <LucidFox> Same with empathy - I still don't know what they were smoking to put it in the default installation.
[10:33] <\sh> siretart, do you have a good default config for gnus?
[10:34] <directhex> LucidFox, perhaps it relates to the unspoken problems with pidgin's upstream development?
[10:34] <LucidFox> That beong
[10:34] <LucidFox> * That being?
[10:35] <directhex> can't tell you. look up "unspoken" in the dictionary ;)
[10:37] <LucidFox> "The Ubuntu community has contributed 16666 ideas"
[10:37] <LucidFox> Spooky.
[10:46] <LucidFox>  11-Jun-2008
[10:46] <LucidFox> After some complaining and whining from a few people about how long it's taking, we've finally released a new Linux version: 2.8.6, enjoy.
[10:46] <LucidFox> ^ from xchat.org.
[11:05] <siretart`> \sh: default config? what's that? :-)
[11:05] <\sh> siretart, btw...the replacement for gnus/mail today is named eclipsemail (http://eclipsemail.org/wiki/index.php/Eclipsemail_User_Guide)
[11:05] <\sh> oh pop3 only...crap ;)
[11:06] <siretart`> err, in what ways can that be a replacement?
[11:06] <\sh> siretart, for people not knowing emacs ;) but eclipse
[11:07] <siretart`> if there was only a proper text editor in eclipse.. oh well.
[11:07] <siretart`> btw, how is eclipse doing these days in ubuntu? are we still shipping obsolete/outdated packages that don't work with current 3rd party extensions?
[11:08] <\sh> siretart, well, I do like the pydev stuff from eclipse, in combination with http://eclipse-tools.sourceforge.net/shortcuts.html rocks
[11:08] <\sh> siretart, eclipse in karmic works like a charm...
[11:08] <\sh> even with 3rd party stuff
[11:10] <siretart`> oh, indeed. seems we now ship 3.5.1. cool
[11:11] <siretart`> kudos to bdrung, then! :-)
[11:17] <noneNN> will kernel 2.6.32 be on karmic repos?
[11:20] <directhex> noneNN, no. karmic is a stable release, no invasive changes go in post-release
[11:21] <slytherin> noneNN: No.
[11:21] <directhex> i still don't "get" eclipse :(
[11:26] <slytherin> directhex: keep trying, it i not that hard. :-)
[11:27] <directhex> slytherin, i've occasionally poked it since i was an undergrad, and never thought more than "ick"
[11:28] <slytherin> directhex: probably because you never worked full time on a java based app.
[11:29] <directhex> true
[11:30] <LucidFox> slytherin> Ehehehe
[11:30] <LucidFox> I can relate tot hat.
[11:31] <LucidFox> I use Eclipse for Java extensively, but I couldn't get used to it for anything else.
[11:33] <\sh> eclipse + pydev + pybzr == my favorite UI for python development (+ web ext. for html / css /javascript stuff)
[11:34] <\sh> and apache directory studio plugin for ldap stuff...
[13:12] <lfaraone> Can I build a package with CDBS that uses multiple setup.py files? If so, how?
[13:42] <ngirard> Hi all. Using equivs-build I've built & installed a dummy package whose "provides" are beeing ignored by apt-get. Specifically, my texlive-dummy does provide, among others, tex-common ; and yet  apt-get install jadetex requires libosp5 openjade1.3 tex-common tipa to be installed... any thoughts ?
[14:04] <ripps> ngirard: you need to setup Conflicts and Replaces
[14:06] <ripps> http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-control
[14:12] <ngirard> Hi ripps. Thanks for your answer
[14:19] <ngirard> ripps: Here's the contents of texlive-dummy.txt : http://pastebin.com/d2f5cc73a . I've used it to build such texlive-dummy package: equivs-build texlive-dummy.txt ;  sudo dpkg -i texlive-dummy_1.5_all.deb
[14:19] <ngirard> It still doesn't work as expected.
[14:20] <ngirard> sudo apt-get install tipa
[14:20] <ngirard> suggests to *remove* my texlive-dummy in order to install tex-common texlive-base texlive-base-bin and so on...
[14:22] <ripps> I don't have any experience with a control that big and complicated, wait around until a MOTU can help
[14:23] <ngirard> ripps: sure. Thanks anyway !
[14:38] <alkisg> I have a project in a bzr branch in launchpad. I want to rearrange it a lot - rename a lot of files and dirs, add many new ones... I don't mind losing the history, so is it possible to clear the whole branch and start over?
[14:40] <tsimpson> you can probably just delete the branch and push to it again
[14:41] <alkisg> Thank you tsimpson :)
[15:22] <bddebian> Heya gang
[15:27] <\sh> hoi bddebian
[15:27] <bddebian> Hi \sh
[15:27] <\sh> bddebian, not in dallas @ uds?
[15:28] <geser> ngirard: tipa has a versioned dependency on tex-common and Provides don't work with versioned dependencies
[15:28] <geser> Hi bddebian, \sh
[15:28] <\sh> hey geser
[15:31] <bddebian> Heya geser
[15:31] <ngirard> Hi geser. Thanks for you answer. What would you advice me then ?
[16:00] <geser> ngirard: what are you trying to achieve?
[16:02] <ngirard> geser: sorry for beeing unclear. For all tex-related stuff I need, I've installed a fresh TeXlive 2009 manually. I want to prevent apt-get to install the official tex-related packages
[16:05] <geser> ah, you could try to build an empty package named "tex-common" with a large version (so it fullfills the dependencies but don't get replaced with a real tex-common package on next upgrade). But I don't know if there is a script which helps you doing it
[16:05] <geser> it's like a meta-pacakge but with empty Depends
[16:10] <ngirard> geser: what if I added large versions to the contents of my texlive-dummy control file ? Would it work ?
[16:11] <ngirard> to every package provided by texlive-dummy, meaning
[16:12] <geser> ngirard: Provides has only package names, no version. if you make your texlive-dummy version e.g. 2009, you still can only provide an unversioned texlive-common which doesn't fullfill the requirement of tex-common >= 1.18 (or similar)
[16:12] <geser> you would need to "rename" your texlive-dummy to tex-common
[16:13] <ngirard> geser: damn.
[16:14] <ngirard> geser: it'll take ages to generate empty, versioned packages corresponding to all texlive-related packages
[16:15] <geser> ngirard: you need only those which appear in versioned dependencies, the others can be only provided
[16:16] <ngirard> geser: insightful ! Yeah, right !
[16:16] <geser> ngirard: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual if you want to read how Provides work
[16:17] <serialorder> i don't know much yet so this might be a totally stupid idea, if it is i apologize and would like to know, but could you add it so that you could select your local version with update-alternatives?
[16:18] <ngirard> geser: okay, i'll go for your solution. Thanks very much for your assistance !
[16:19] <geser> you can use update-alternatives to select which implementation should be the default for a command, but that won't work on package versions (they are in dpkg's database)
[16:19] <geser> ngirard: I hope it works
[16:28] <ngirard> geser: it worked... at least for the very tipa package I told you about. Now, i'm afraid i'd like to ask you another question: sudo apt-get build-dep gnucash libaqbanking --> among the dependancies there also seems to be versioned dependancies of some tex-related packaged. My question is: How could I track these dependancies ?
[16:28] <ngirard> geser: here's the output: http://pastebin.com/d234ad565
[16:34] <geser> ngirard: I assume the tex packages are only recommended on some build-dependencies, I get no tex packages listed with disabled recommends (I've tested it on lucid but karmic and lucid shouldn't diverged much yet)
[16:40] <ngirard> geser: err... i'm not sure i understood, but anyway, I'm considering the following workaround: in bash or python, automate the creation & installation of dummy tex-related packages having a very high version. The only problem is, I may have problems when the official texlive 2009 packaged will be out and i want to switch to them
[16:40] <ngirard> the official texlive 2009 packaged -> packages ^
[16:43] <geser> ngirard: what you break, you'll have to fix yourself :) you could try using a high but unique version number (e.g. 9999) for which you could grep later the output of dpkg -l to find any of your dummy packages
[16:45] <ngirard> geser: good idea ! Let's go with it. Thanks again for your help !
[18:07] <maxb> Hmm. I'm trying to do my first UDD merge, and I got huge amounts of conflicts. So I read james_w's email and did it again with "bzr merge-package" which did lots of voodoo. But I still get unexpected conflicts within the debian/ dir
[18:08] <maxb> I am trying to merge lp:debian/sid/subversion into lp:ubuntu/lucid/subversion
[18:23] <randomaction> i think it's ok if you can resolve them
[18:29] <maxb> eww. The history of this branch is entirely screwed up
[18:29] <maxb> bzr merge-package is attempting to merge the changes from several already-merged debian versions
[18:35] <randomaction> oh, is it a problem with bzr-merge-package?
[18:36] <randomaction> I never used it, only MoM
[18:47] <maxb> randomaction: It turns out that this package's package branches are a bit screwed up
[18:47] <maxb> There's a debian revision bound to the history of the ubuntu package branch which isn't present in the debian package branch. This is confusing things rather significantly
[18:53] <randomaction> these branches seem to have no common revisions
[18:56] <m4rtin> once a patch has been submitted to the main-sponsors list, how long does it usually take for review?
[19:01] <randomaction> maxb: or is it because it was merged from experimental?
[19:01] <fcuk112> python-all-dev; does anyone know the diff between 9.04 and 9.10 when installing this package?
[19:02] <RainCT> fcuk112: not much, that package is empty
[19:02] <RainCT> it justs depends on all -dev packages for the different python versions
[19:03] <fcuk112> but do you know if the depencies have changed?
[19:04] <fcuk112> i am trying to upgrade libavg; and somehow it now fails through pbuilder.
[19:06] <maxb> randomaction: Oh! Yes! And yuck, that means the UDD tools are broken in this case
[19:07] <randomaction> because experimental and sid usually don't overlap
[20:07] <rizwanhudda> hi ubuntu geeks
[20:08] <rizwanhudda> i am new to ubuntu-motu , can some one suggest me where to start
[20:08] <geser> m4rtin: it depends how busy the core-devs are, now with uds happening, I'd be patient till middle/end of next week
[20:09] <rizwanhudda> hi gesser,m4rtin
[20:12] <m4rtin> geser: thanks - not moaning, just no point looking for a response before there's likely to be one (first patch over-excitement ;))
[20:17] <maxb> randomaction: huh? Surely the primary purpose of experimental is as a feeder for packages that eventually show up in sid?
[20:20] <randomaction> I mean, versions don't overlap. Last version of subversion in experimental was 1.6.1dfsg-1, followed by 1.6.3dfsg-1 in sid.
[20:20] <randomaction> There's no migration like unstable -> testing.
[20:25] <maxb> Right... there's no firm implied relationship *but* often there is a relationship since experimental is often-but-not-always a merge in the debian packager's vcs
[20:25] <maxb> s/a merge/a branch that is merged into what later goes to sid/
[20:27] <maxb> And the problem here appears to be that after a merge-from-experimental, the auto-importer didn't write appropriate ancestry for the subsequent merge from unstable
[20:28] <ajmitch> maxb: probably something you need to bug james_w about
[20:28] <maxb> yeah, once I've figured it out enough to file a bug
[20:28]  * maxb hugs bzr qlog
[20:28] <maxb> without which this would be an intractable problem :-)
[20:30] <maxb> Is there a word for a merge commit which has no changes and only exists to fix the ancestry?
[20:31] <maxb> .oO( bzr ci -m "Tie ancestry from debian/sid on upstream import branch." )
[20:34] <randomaction> I wonder if source format 3.0 (git) would make life easier
[20:39] <adama> http://www.geekologie.com/2009/11/15/cisco-bars.jpg
[20:41] <ari-tczew> hello devs, I have a question
[20:42] <ari-tczew> if Ubuntu's changes have been merged in Debian, should we sync package?
[20:42] <av`> yes
[20:42] <ari-tczew> but I see on merges.ubuntu.com comments "no need" or something
[20:43] <StevenK> Probably means "no need to merge"
[20:43] <ari-tczew> I think we should sync packages which are the same because it's easier for autosync in future
[20:43] <RoAkSoAx> ari-tczew, because those changes that *are* in Ubuntu, and have been *merged* to Debian, there's no need to sync a package that already have the Ubuntu Changes
[20:43] <StevenK> RoAkSoAx: Sure there is.
[20:44] <RoAkSoAx> ari-tczew, however, some of those commnets might not be up to date
[20:44] <ari-tczew> so, what's the conclusion? ignored these comments, or request a sync?
[20:44] <StevenK> RoAkSoAx: There is always a win to sync a package, because this means Ubuntu will stay up to date if Debian changes the package while the autosyncer runs
[20:44] <StevenK> ari-tczew: File a sync request
[20:45] <ari-tczew> StevenK: thanks!
[20:45] <geser> the comment could have been added late in the development cycle where it didn't make much sense to sync it at that time
[20:45] <RoAkSoAx> stefanlsd, yes indeed.
[20:46] <RoAkSoAx> yes and that's what I meant, that at the moment of the comment there was no need to sync it
[20:46] <RoAkSoAx> stefanlsd, wrong nick sorry :P
[20:47] <ari-tczew> +1 for: [21:44] <StevenK> RoAkSoAx: There is always a win to sync a package, because this means Ubuntu will stay up to date if Debian changes the package while the autosyncer runs
[20:49] <RoAkSoAx> ari-tczew, right, but for example, you made a change in Ubuntu, i.e. apply a patch in Ubuntu and forward it to Debian, then Debian applies that patch, and releases a new package, then there's no need to merge/sync it at that moment, as geser said
[20:56] <ari-tczew> yes, but if Debian will release a new package later, we need checking again
[20:57] <ari-tczew> but if we will sync package now, later autosync can do it (get  a new Debian's package)
[21:25] <geser> now is a good time to sync such packages, but not necessarily a few weeks before beta-freeze (as an example) where we don't get any benefit from it
[21:27] <sebner> huhu geser :)
[21:31] <ari-tczew> sebner: I have added a commen for cpufire-applet on merges.ubuntu.com "feel free to take it" as you wrote in mail
[21:31] <ari-tczew> s/commen/comment
[21:36] <serialorder> StevenK, is there a reason not to submit the viewport patch in rdesktop to debian?
[21:37] <StevenK> serialorder: I don't see why not. Keep in mind I've not touched rdesktop in quite some time
[21:37] <StevenK> I happen to be subscribed to an old bug
[21:38] <serialorder> yeah I noticed, I think we have worked out a fixes for both the -y and the -K bugs
[21:38] <StevenK> Do they keep everyone happy? :-)
[21:38] <serialorder> so far
[21:38] <geser> Hi sebner
[21:39] <StevenK> serialorder: Then I think the next step is to file a Debian bug about this, or to engage with upstream directly
[21:39] <serialorder> StevenK, I decided to work on that because rdesktop was in no condition to be deployed in a LTS release the way it was.
[21:40] <serialorder> well i would like to do a little more testing first just to make sure but that would be the plan
[21:44] <ari-tczew> StevenK: could you review this bug 389856, please?
[21:46] <StevenK> ari-tczew: Looks good to me
[21:47] <sebner>  ari-tczew sure :)
[21:48] <ari-tczew> right! but not looks good for nellery
[21:48] <sebner> ari-tczew: would you mind add that comment to all of my merges?
[21:49] <ari-tczew> so are you not interesting to merging packages changed by you?
[21:49] <sebner> ari-tczew: I don't have really time for it now so it's better some contributor has a little bit of training ;D
[21:50]  * ajmitch needs training & a few merges to do :)
[21:50] <ari-tczew> sebner: If I'll get a bit of time I can comment this
[21:51] <ari-tczew> Alert! Devs, please do not closing sync's request if changes was merged in Debian!
[21:52] <ari-tczew> We are not forwarding changes for Debian, after that were rejected
[21:53] <Rocha> hi
[21:53] <ari-tczew> this is passing with the idea
[21:53] <Rocha> i'm having some trouble with launchpad
[21:54] <Rocha> how can i branch two branches i have in a project registered in launchpad?
[21:54] <ari-tczew> Rocha: #launchpad
[21:54] <Rocha> ok
[21:56] <ari-tczew> StevenK: thanks for ACK!
[22:00] <sebner> ari-tczew: thx :)
[22:21] <ari-tczew> devs! please give a comment on merges.ubuntu.com/universe.html including bug#number of sync's request, it making work on merges more easier
[22:27] <ari-tczew> sebner: you didn't change any package on main, so on universe I have marked all packages changes by you as "feel free to take it"
[22:27] <sebner> ari-tczew: great. thanks!
[22:28] <ari-tczew> sebner: working for MOTU it's my pleasure
[22:28] <sebner> heh
[23:23] <master> lol