[00:29] <lfaraone> nhandler: yes, that's correct, that should be reflected in that I merged in the changes from Debian, commited, and then made the changes for Ubuntu in http://bazaar.launchpad.net/~lfaraone/ubuntu/lucid/autokey/merge0.61.5-1ubuntu1/revision/10
[00:29] <lfaraone> nhandler: rev 10 is the only ubuntu-specific change in the package.
[00:34] <lfaraone> nhandler: yes, that is the upstream changelog. Upstream keeps their changelog in debian/changelog in their svn tree. The real debian changelog is at http://packages.debian.org/changelogs/pool/main/a/autokey/autokey_0.61.5-1/changelog , the upstream changelog I attached (from SVN trunk) is at http://code.google.com/p/autokey/source/browse/branches/autokey-combined/debian/changelog
[02:38] <psusi> holy moly... lp says it's goign to take 2 days to build my patched parted in my ppa
[02:39] <micahg> psusi: some PPA builders have probably been temporarily reappropriated
[05:31] <fabrice_sp> Hi. Could someone try building scala (http://ftp.debian.org/debian/pool/main/s/scala/scala_2.7.7.dfsg-4.dsc) for bug 545975: it FTBFS here, but with a strange error
[05:33] <AnAnt> Hello, could someone sponsor this patch LP 544296
[05:42] <fabrice_sp> AnAnt, let me check
[05:44] <fabrice_sp> it seems you forget to run update-maintaner
[05:44] <AnAnt> oh yes
[05:45] <AnAnt> fabrice_sp: ok, can you also check LP 543679
[05:45] <AnAnt>  ?
[05:46] <fabrice_sp> I can check, but not upload right now: my build desktop is quite broken
[05:47] <fabrice_sp> (caused by a self destruction of my motherboard)
[05:48] <AnAnt> ok
[05:49] <fabrice_sp> it's a new package: you should get an ack from the Release team, no? Or explain why you don't need it
[05:50] <AnAnt> fabrice_sp: I didn't know wether I should subsribe -sponsors or -release
[05:52] <fabrice_sp> I would say first -release, because of Feature Freeze, and document the FFe
[05:52] <fabrice_sp> and as soon as you get the ack from  -release, subscribe -sponsors
[05:54] <AnAnt> ok
[05:55] <AnAnt> I updated the patch for zekr
[05:56] <fabrice_sp> ok. Sponsors are subscribed, so it should be ok. As soon as I xcan build and upload a package, I'll upload it (if nobody did it before)
[05:57] <fabrice_sp> I'll also unsubscribe -sponsors from 543679
[06:02] <AnAnt> ok
[07:18] <dholbach> good morning
[08:32] <AnAnt> dholbach: hello
[08:32] <dholbach> hey AnAnt
[08:32] <AnAnt> how are you ?
[08:33] <dholbach> good good - how are you?
[08:33] <AnAnt> fine
[08:33] <AnAnt> not sure wether to close that long time bug or what
[08:34] <dholbach> do it if you think it's been fixed. you can still ask people to test it and reopen the bug if necessary
[08:34] <AnAnt> ok
[08:34] <AnAnt> dholbach: can you sponsor this patch: LP 544296
[08:36] <dholbach> having a look
[08:36] <IntuitiveNipple> Could someone sponsor bug #546108 debdiff please?
[08:36] <ara> is wiki.ubuntu down?
[08:37] <dholbach> ara: it works for me
[08:39] <ara> dholbach, weird, it times out for me
[08:40] <dholbach> ara: does the traceroute look funny for you?
[08:41] <ara> dholbach, it just times out... it might be my internet connection
[08:41] <dholbach> ara: maybe if you run    mtr wiki.ubuntu.com    it shows you a where it's broken
[08:42] <ara> dholbach, it is indeed my internet connection
[08:42] <dholbach> ok
[08:42] <ara> *sigh*
[08:42] <dholbach> AnAnt: uploaded, I ran 'update-maintainer' for you
[08:43] <AnAnt> dholbach: I ran it already in the 2nd patch
[08:43] <AnAnt> thanks anyways
[08:43] <dholbach> not in http://launchpadlibrarian.net/41931707/zekr_0.7.5~beta3%2Brepack-1ubuntu1.debdiff :)
[08:43] <dholbach> but anyway :)
[08:43] <dholbach> it's all good
[08:45] <johe|work> hi there, is there any way coova-chilli (coova.org) could be part of the ubuntu repository, maybe someone could add it, or maybe somone could teach me how to add it :-)
[08:45] <AnAnt> slangasek: thanks !
[08:45] <dholbach> AnAnt: شكرا
[08:46] <AnAnt> dholbach: ah ! you still remember
[08:46] <dholbach> AnAnt: one of the very few I didn't forget :)
[08:47] <AnAnt> AnAnt: erm, it was probably the only one
[08:48] <dholbach> might be ;)
[09:31] <joaopinto> good morning
[10:04] <suji11> hi
[10:07] <suji11> how to write rules file?
[10:22] <brijith> Hi all , how can I change the permission of a folder in side rules file while packaging?
[10:26] <suji11> how to write rules file?
[10:39] <brijith> suji11:http://videos1.showmedo.com/ShowMeDos/extras/linuxJensMakingDeb/from_py_to_deb.pdf
[12:21] <ejat> can someone help me with this : http://paste.ubuntu.com/401749/
[13:06] <bobbo> zul, ping
[13:06] <zul> bobbo: pong
[13:06] <bobbo> zul, I noticed you've filed an MIR for python-formencode but it currently FTBFS
[13:07] <zul> bobbo: yeah im working on it
[13:07] <AnAnt> Hello, I'm not sure wether to ask this question here or in #ubuntu+1, I have a closed-source software here that crashes when I use lucid (yet it works funny with debian unstable), yet when I strace that software, it doesn't crash, what would be the possible reason for this ?
[13:07] <AnAnt> s/funny/fine
[13:07] <bobbo> zul, okay, I have a patch for it but I'll hold off on uploading it if you're working on it :)
[13:07] <zul> bobbo: thanks
[13:17]  * POX doesn't understand most of Ubuntu changes in python-formencode
[13:32] <ScottK> POX: Since the last two revisions didn't build, I suspect they can be ignored.
[13:33] <POX> ScottK: not really: http://packages.ubuntu.com/lucid/all/python-formencode/filelist (WTF?)
[13:34] <ScottK> POX: rmadison says ubuntu1 is the last one that built.
[13:36] <POX> ScottK: well, right now I'm not really motivated to contribute in Ubuntu, so I'll just say that formencode and gaupol should be checked
[13:37] <ScottK> POX: Are you  satisfied with python-formencode with Python 2.6 in Debian as it is?
[13:38] <POX> yes
[13:38] <ScottK> Good enough for me.
[13:38] <ttx> There is a MIR in progress for python-formencode, FWIW
[13:39] <POX> someone enabled tests in ubuntu and they probably failed as locales are not installed at build time so they installed .po files for... every single Python version
[13:39] <ttx> zul ^
[13:39] <ScottK> ttx: It ought to at least build and dropping python-dns from depends with no rationale is just wrong.
[13:40] <ScottK> POX: Thanks.
[13:40] <POX> python-dns is probably removed as it's not in main
[13:40] <zul> i just uploaded the FTBFS fix
[13:40] <ttx> I'm trying to avoid duplicating work :)
[13:40] <zul> and removed python-dns as well
[13:40] <ScottK> POX: Yes, but we aren't supposed to just drop depends willy nilly.
[13:40] <ScottK> zul: Why?
[13:41] <zul> because its not in main
[13:41] <ScottK> zul: That's not a proper rationale.
[13:41] <zul> and the testsuite ran fine without it
[13:41] <ScottK> And so that means there's no impact?
[13:41] <zul> didnt appear to any to me
[13:43]  * POX will move python-dns to Recommends
[13:43] <POX> zul: see validators.py
[13:44] <ttx> POX: the question is more how useful python-dns is to python-formencode
[13:44] <POX> see validators.py
[13:44] <ttx> if its optional, should be a suggests, if its required for 90% of the cases, then recommends (anbd pushing it to main) is the way to go
[13:45] <ttx> (mind you, I've no clue what python-formencode does)
[13:45] <ScottK> I just left a comment in the MIR bug that I don't think "the test suite works" is sufficient investiation before dropping a depends.
[13:45] <POX> ttx: take a look at line 1362
[13:46] <POX> asserts are disabled only with -O (and python packages do not use that)
[13:46] <POX> so if self.resolve_domain is set to true, it will fail
[13:48] <ttx> but it's only set if you explicitely set resolve_domain=True
[13:48] <ttx> as explained on line 1257
[13:48] <ttx> it's clearly optional
[13:49] <ttx> If you pass ``resolve_domain=True``, then it will try to resolve the domain name to make sure it's valid.  This takes longer, of course. You must have the `pyDNS <http://pydns.sf.net>`__ modules installed to look up DNS (MX and A) records.
[13:49] <ttx> default is False
[13:49] <ScottK> So the question would  be do the redepends set it to True?
[13:49] <ttx> so I would downgrade it to Suggests
[13:50] <ttx> ScottK: yes
[13:50] <ttx> if they do, Recommend/MIR is in order :)
[13:51] <ttx> hm. do the buildds install recommends ?
[13:51]  * POX will not downgrade it to Suggests as all applications that use resolve_domain will fail without pydns
[13:51] <ttx> POX: well, they could depend on python-dns if they require it
[13:52] <ttx> it all depends on how prevalent usage of resolve_domain=True is
[13:52] <ttx> if every consumer of pyhton_formencode sets it, I tend to agree with you. But the default value seems to tell a different story.
[13:53] <ScottK> I think that Recommends is more appropriate, but we are in the realm where if the in archive rdepends doesn't set it True, downgrading to Suggests in Ubuntu to save disk space is not wildly inappropriate.
[13:53] <sistpoty|work> ttx: buildds don't install recommends
[13:54] <sebner> huhu sistpoty|work :)
[13:54] <sistpoty|work> hi sebner
[13:54] <ttx> sistpoty|work: Ii seemed to remeber that :)
[13:54] <ttx> ScottK: I agree with you, we need to have a look at those rdepends.
[14:01] <ttx> commented.
[14:39] <lfaraone|really> nhandler: I added a debdiff between the attached branch in bug 546139 and the current Debian revision.
[14:41] <nhandler> lfaraone|really: And what was the reason (with you being the DM) for not having the transitional package install the gtk version in debian?
[14:43] <lfaraone|really> nhandler: because in Debian we're transitioning from autokey to autokey-qt, since that's what we've been shipping in testing for a while now.
[14:44] <lfaraone|really> nhandler: it's been in section: KDE since Aug 2009, but we shipped it in section GTK in karmic.
[14:46] <lfaraone|really> lfaraone|really: I discussed this with my sponsor as well as upstream, and we all agreed this would be the best plan.
[14:47] <lfaraone|really> nhandler: I discussed this with my sponsor as well as upstream, and we all agreed this would be the best plan. *
[14:47] <nhandler> lfaraone|really: I ACKed the FFe ;)
[14:48] <lfaraone|really> nhandler: thanks :)
[14:53] <jcfp> nhandler: could you unsubscribe ubuntu-release from #545610 for now?
[14:53] <nhandler> Bug 545610
[14:54] <nhandler> jcfp: Done
[14:54] <jcfp> thanks :)
[15:00] <lfaraone|really> nhandler: okay, I subscribed ~ubuntu-sponsors
[15:36] <duanedesign> working on a FFe, building the new upstream source I am getting two(2) warnings.  http://paste.ubuntu.com/401850/
[15:43] <jcastro> directhex: he what tasque is in debian?
[15:43] <jcastro> .8 or .9?
[15:44] <ScottK> jcastro: rmadison -u debian tasque
[15:44] <jcastro> ScottK: omg. I could have used that trick like 5 years ago
[15:44] <jcastro> thanks for that
[15:44] <ScottK> You're welcome.
[15:46] <directhex> "-u qa" is quicker to type
[16:26] <nigelb> trying to build the cheese package, and I get this error "make: *** No rule to make target `/usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk'.  Stop."
[16:26] <nigelb> all I did was add an apport hook
[16:27] <ScottK> Is gnome-pkg-tools a build-dep?
[16:28] <nigelb> yes
[16:29] <ScottK> Does it still provide that file?
[16:30] <nigelb> oh, if I install that package, this might work?
[16:32] <ScottK> Yep
[16:33] <ScottK> You need to install all the build-depends.
[17:33] <mpt> Ubuntu Software Center v2 has a "Developer Tools" > "Mono" section, but Monodevelop isn't in it. The fix is a really simple packaging change: http://launchpad.net/bugs/546936
[17:36] <mpt> There are similar one-line-fix bugs that would be ideal for someone getting started in packaging: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=metadata
[17:39] <micahg> I just saw bug 545563 was fixed
[17:40] <micahg> but it pulls in 268MB of docs as a depends?  should it be doing this?
[17:43] <micahg> mpt: I see you're famiiliar with the categories for the software center, can I ask you a qeustion?
[18:11] <ari-tczew> how can I build package by pbuilder when I have lucid and I want to build on intrepid?
[18:14] <prefrontal_> pbuilder-satisfydepends-dummy depends on * ; however: package * is not installed
[18:14] <prefrontal_> isn't the point of pbuilder to simulate building my package on a system that doesn't even have the right dependencies yet?
[18:15] <ari-tczew> prefrontal_ did you update pbuilder?
[18:15] <sistpoty|work> ari-tczew: pbuilder --create --distribution=intrepid [--basetgz /var/cache/pbuilder/intrepid.tar.gz]
[18:15] <sistpoty|work> maybe --distribution intrepid one of the two should work
[18:16] <prefrontal_> ari-tczew, i just created a new pbuilder env
[18:16] <ari-tczew> sistpoty|work: Unknown option [--distribution=intrepid] was specified
[18:16] <sistpoty|work> ari-tczew: then try without =
[18:17] <sistpoty|work> prefrontal_: if you put "foobar" in build-depends, and there is no package foobar, pbuilder cannot install it
[18:18] <sistpoty|work> prefrontal_: or if you build-depend on a package in universe but have only a line for main in the pbuilder's sources.list
[18:18] <prefrontal_> really? it can't find the debhelper package then
[18:18] <ari-tczew> sistpoty|work: okay, your command succeful, so then what;s the command I need to build package on intrepid?
[18:18] <sistpoty|work> ari-tczew: simply tell pbuilder to use that tar.gz with --basetgz <locationoftargz>
[18:19] <sistpoty|work> pbuilder --build --basetgz some.tar.gz foobar.dsc
[18:19] <ari-tczew> thanks!
[18:19] <ripps> I prefert to use the cowbuilder mod of pbuilder, seems alot faster.
[18:20] <sistpoty|work> oh, I've been told that there is better magic called pbuilder-dist or so, not too sure where that lives (maybe in ubuntu-dev-tools)
[18:26] <ari-tczew> sistpoty|work: E: File intrepid.tar.gz does not exist
[18:28] <ScottK> You need to create the new pbuilder chroot first
[18:29] <ari-tczew> ...
[18:29] <ari-tczew> does someone can expand pbuilder to easy build on other releases?
[18:30] <ari-tczew> to use pbuilder by using command-option like --dist=jaunty
[18:30] <sistpoty|work> ari-tczew: you'll need to specify exactly the base tarball that you created with --create
[18:30] <sistpoty|work> ari-tczew: if you omited --basetgz at --create, then it should be in /var/cache/pbuilder/base.tar.gz
[18:30] <sistpoty|work> (or base.tgz, don't recall that atm)
[18:31] <ScottK> ari-tczew: pbuilder-dist intrepid create
[18:31] <ScottK> Then pbuild-dist intrepid build ....
[18:32] <ari-tczew> sistpoty|work: so actually 'pbuilder build *.dsc' will build on intrepid instead jaunty? :-/
[18:32] <sistpoty|work> ari-tczew: pbuilder build will use the standard tarball. It will build with whatever is inside that tarball
[18:33] <sistpoty|work> ari-tczew: the distribution is only specified by what packages are in the tarball and what apt sources line is in the tarball. pbuilder --build knows nothing about the distribution
[18:33] <MTecknology> How can I see packages that are waiting to be uploaded into lucid?
[18:35] <ari-tczew> sistpoty|work: do you mean tarball as .diff.gz ?
[18:35] <sistpoty|work> MTecknology: define "waiting to be uploaded" (as in stuck in binary/source new, or waiting to get sponsored, or anything else?)
[18:35] <MTecknology> sistpoty|work: stuck in binary/source new
[18:35] <sistpoty|work> ari-tczew: no the base tarball from pbuilder (which is actually just a tarball of a chroot)
[18:36] <ari-tczew> ehh, I'll use ScottK propose, because I think that this is it, what I'm looking for
[18:36] <sistpoty|work> MTecknology: https://launchpad.net/ubuntu/lucid/+queue
[18:36] <ScottK> There are other ways to do it, but that works.
[18:36] <MTecknology> sistpoty|work: thanks :)
[18:36] <sistpoty|work> yw
[18:38] <prefrontal_> how do I handle using pbuilder to build a package that depends on another package that i created and isn't in the repos
[18:43] <sistpoty|work> prefrontal_: quick and dirty: pbuilder --login --safe-after-login
[18:43] <sistpoty|work> prefrontal_: that should print you a path were the chroot is extracted
[18:44] <sistpoty|work> prefrontal_: copy the deb over there
[18:44] <sistpoty|work> prefrontal_: and install it inside pbuilder
[18:44] <prefrontal_> then what?
[18:44] <sistpoty|work> prefrontal_: that's it. package is then installed in the chroot and hence available once you unpack it again
[18:45] <sistpoty|work> prefrontal_: however that also means that it's there when you don't expect it and want a clean env
[18:45] <prefrontal_> oh, i thought that the chroot was inside the base.tar.gz which is decompressed and then recompressed every time i run pbuilder
[18:46] <sistpoty|work> prefrontal_: yes, but with pbuilder --login --safe-after-login you can decompress it and do things inside it
[18:46] <prefrontal_> ok, then how do i recompress it afterwards
[18:46] <sistpoty|work> prefrontal_: --safe-after-login takes care of it
[18:46] <prefrontal_> ok, thanks
[18:47] <sistpoty|work> prefrontal_: cleaner approach would be to use a local repository and add that to the apt-sources line inide the chroot (but I can't provide details for that)
[18:56] <MTecknology> So, when something should be uploaded into ludid, it winds up at launchpad.net/ubuntu/lucid. How does it get there and what happens from there?
[18:56] <MTecknology> I'm guessing only motu can upload there, so is revu where a motu can accept a users package and push it into lp.net/ubuntu/lucid ?
[18:58] <sistpoty|work> MTecknology: it gets there only if in freeze, or if the source package is new (source new) or if the source package produces a new binary package
[18:58] <MTecknology> sistpoty|work: so that's a queue for exceptions?
[18:59] <sistpoty|work> MTecknology: in regards to freeze? no, we just turn the archive down to manual when in freezes (e.g. betafreeze) since an uncoordinated upload could mean that iso have to be rebuilt (and hence mean lots of lost time)
[19:00]  * sistpoty|work heads home now... cya
[19:00] <MTecknology> ttyl
[19:02] <MTecknology> I'm just trying to understand the process packages take to get into ubuntu; so far I understand how a package gets into debian and then from there's it's just a sync into ubuntu; i get how the version numbers work to keep syncs in line. It's the others paths that confuse me. Not from my side but rather yours
[19:04] <geser> what confuses you?
[19:05] <MTecknology> geser: if I upload someting to motu and motu decide it's a good package, what happens to it?
[19:05] <geser> what you mean with "upload to motu"?
[19:06] <MTecknology> upload to revu*
[19:06] <ari-tczew> upload to universe?
[19:06] <MTecknology> revu.ubuntuwire.com
[19:08] <geser> MTecknology: when you upload your package to revu, it gets reviewed -> comments with mistakes -> fix & reupload -> review -> ... -> it the package is good, it gets advocated (by a developer) -> when it has two advocates, it gets uploaded to the archive (usually done by the developer who did the 2nd advocate)
[19:08] <geser> that's the workflow in theory
[19:09] <MTecknology> geser: and that upload goes to launchpad.net/ubuntu/version_name ?
[19:10] <geser> yes, LP doesn't distinguish syncs (from Debian) and uploads (merges, bug fixes, new packages)
[19:11] <MTecknology> how does the sync happen?
[19:11] <MTecknology> a script runs, checkes versions, if debian_ver > ubuntu_ver :then upload to lp?
[19:12] <geser> yes
[19:12] <MTecknology> is that script built into launchpad or something somebody has running on a server?
[19:14] <MTecknology> I suppose that part doesn't matter so much
[19:14] <geser> both, some part is done by scripts run by an archive admin (see lp:ubuntu-archive bzr branch) and some parts build into LP
[19:14] <MTecknology> oh
[19:15] <MTecknology> so.. what does dput look like for the upload queue?
[19:17] <geser> dput only uploads some files (.changes, .dsc, .diff.gz, ...) to an ftp-server and a part of LP scans this directory periodically and processes the files/uploads it finds there
[19:17] <MTecknology> oh
[19:18] <geser> nothing magic :)
[19:18] <MTecknology> so almost just like launchpad or revu, just different server?
[19:19] <geser> both have an FTP server for the uploads
[19:19]  * geser is losing context. what "different server"?
[19:19] <MTecknology> So, there's a status of New,Accepted,Rejected,Done,Unapproved - the names are pretty self explanatory, but how are those handled?
[19:20] <MTecknology> geser: I meant other than launchpad for upload - your answer answered it
[19:21] <MTecknology> and is a sync'ed package from debian ever rejected? - and how would that be handled
[19:23] <geser> for uploads: the upload processor checks the signature if the person can upload or not (Accepted or Rejected email), then it gets into the queue (https://edge.launchpad.net/ubuntu/lucid/+queue) where I've to pass as I don't know the details how those different status get assigned and work
[19:24] <MTecknology> If I'm asking too many questions feel free to slap me, I'm waiting for an upload marked "Done" to get into the archives and sync so I can install it. It may have the patch to an irritating bug
[19:25] <geser> for syncs: as they are done on the canonical servers, I'm not sure how exactly it gets done (but you can dig through the LP code if you are interested)
[19:26] <MTecknology> I was just about to peak
[19:26] <geser> I know only of rejects for syncs which has to pass through the (source) NEW queue (i.e. the first sync of the package into Ubuntu when it gets reviewed by the archive admins)
[19:27] <MTecknology> New is for new packages, not updates?
[19:27] <geser> yes
[19:28] <prefrontal_> pbuilder is too slow. it keeps downloading all the same packages from scratch every time
[19:28] <prefrontal_> takes me like 20 minutes to make a minor change and find out if it works
[19:28] <geser> packages that got accepted once get auto-accepted on the following uploads/syncs (modulo freezes when the archive is on manual)
[19:28] <ScottK> Which can include new binary packages in existing source packages
[19:28] <MTecknology> then when uploaded it winds up in either accepted or rejected and if accepted it waits until uploaded and then it windws up in done?
[19:29] <ScottK> It moves from accepted to done when it's published.
[19:29] <james_w> prefrontal_: you can set and apt cache dir to prevent that. I thought it was set by default.
[19:29] <ScottK> The publisher runs once an hour at :03 after.
[19:29] <MTecknology> and when it's in done that means it's in the archives and just needs to sync?
[19:30] <ScottK> It generally takes about 40 minutes to finish, so at :45 after the results are on archive.ubuntu.com and then can be mirrored
[19:30] <ScottK> Yes.
[19:30] <geser> after a (successful) upload the source gets published (once an hour), then the source package gets distrbuted to the buildds, the build debs gets put into the queue (same procedure as for sources), and published on the next publisher run
[19:30] <prefrontal_> james_w its the whole download + install process that is redundant..
[19:31] <geser> prefrontal_: usually pbuilder caches the .debs it downloads for re-use
[19:31] <prefrontal_> ok but how can i get it to stop starting over from scratch every time
[19:31] <james_w> don't use pbuilder then!
[19:31] <ScottK> prefrontal_: The install process is to make sure you start with a clean chroot.
[19:31] <prefrontal_> ok but that is making it very difficult to debug..
[19:31] <james_w> it's designed to ensure a clean environment
[19:31] <prefrontal_> a clean chroot is not essential.
[19:31] <ScottK> prefrontal_: temporarily you can use pbuilder login and work within the chroot.
[19:32] <prefrontal_> that's a particular debugging technique that i dont need right now..
[19:32] <ScottK> Then exit when you're done.
[19:32] <MTecknology> and when it's rejected because it's new, somebody needs to upload the source somewhere, then the rest can be uploaded?
[19:32] <prefrontal_> ok but i don't know what pbuilder build *dsc does..
[19:33] <prefrontal_> do you see what i mean? i would like for pbuilder build to try and build my package, but i don't need it to start from the beginning every time
[19:34] <ScottK> pbbuilder login
[19:34] <ScottK> apt-get build-dep packagename
[19:34] <ScottK> apt-get install fakeroot devscripts
[19:34] <ScottK> apt-get source packagename
[19:34] <ScottK> cd into the package dir
[19:34] <ScottK> debuild -us -uc
[19:34] <ScottK> It'll build
[19:35] <ScottK> prefrontal_: ^^
[19:35] <prefrontal_> thank you ScottK
[19:36] <geser> MTecknology: new (source or binary) packages get put on hold (in the NEW queue) until an archive admin looks at them and give a go (accepted) or a no-go (rejected)
[19:36] <MTecknology> oh
[19:36] <prefrontal_> ScottK, how will apt know where my package is? i usually pass pbuilder a .dsc file
[19:37] <geser> pbuilder has some scripts which look at the .dsc file and extract from there the build-dependencies to install and only tell apt (inside the pbuilder) to install them
[19:38] <MTecknology> geser: so what's the actual purpose of a motu? just making sure syncs happen correctly, watching the quality of debian/, dealing with new/updated packages, and helpin anyone that wants to contribute to ubuntu?
[19:38] <prefrontal_> ok but how can a command like 'apt-get build-dep packagename' work when packagename is not in a repository.
[19:39] <prefrontal_> its in /tmp of my workstation
[19:39] <prefrontal_> my package doesn't build in pbuilder yet..i'm trying to debug that
[19:41] <geser> MTecknology: almost, merge/syncing packages from Debian, fixing bugs (e.g. by applying patches from LP), fixing FTBFS, keeping the packages installable (unmet dependencies, caused e.g. by transitions), helping here, sponsoring, and probably some more tasks
[19:42] <MTecknology> !ftbfs
[19:42] <MTecknology> geser: what is ftbfs?
[19:43] <geser> Failed To Build From Source
[19:44] <MTecknology> oh
[19:45] <MTecknology> so if a person creates 500 high quality packages for ubuntu and developed half of them, they're still not a candidate for being motu but they'll now have a whole lot of experience to get themselves there?
[19:48] <geser> yes, a MOTU has to "show" packaging skills, knowledge of the Ubuntu processes (merges, syncs, freezes) and to be able to work in a team (with the other MOTUs)
[19:54] <MTecknology> geser: so assuming I completely understood everything you told me (i think i do), how much of the process would I now understand?
[19:57] <ScottK> prefrontal_: In that case you need to manually copy the package into the chroot (it lives in /var/cache/pbuilder/build) and apt-get install the list of build-deps by hand
[19:58] <geser> the detail knowledge of the working of the archive is not something which is expected to be known from a MOTU, more how (and when) syncs should be done, how a merge is done, when and how a freeze exception should be requested
[19:59] <prefrontal_> ScottK, i got this now, thanks.
[19:59] <prefrontal_> much easier doing all this by hand
[20:00] <MTecknology> geser: so when I think I'm far enough along I should ask for a mentor.. I'm not sure when I'll consider myself far enoguh along
[20:04] <lfaraone|really> Four of my uploads recently ( https://launchpad.net/ubuntu/+source/dvi2ps/4.1j-3 , https://launchpad.net/ubuntu/+source/choosewm/0.1.6-1 , https://launchpad.net/ubuntu/+source/debian-edu-artwork/0.0.30-4 , and https://launchpad.net/ubuntu/+source/mgp/1.13a+upstream20090219-2) have FTBFS on armel, but build fine elsewhere. Is something up with the buildslaves?
[20:04] <lfaraone|really> (build fine on other archs)
[20:05] <MTecknology> geser: thanks for all the info :)
[20:05] <ScottK> lfaraone|really: You'd have to look at the build logs and see why they failed.  I'm not aware of anything.
[20:06] <geser> MTecknology: just start working (e.g. with bug fixes) and when stuck ask here, at some point in the future you will have enough knowledge to become a MOTU
[20:08] <arand> debfx: Assuming you're the one to turn to for vbox in ubuntu... would you mind/have time to look at patches in Bug #510571 for a possible SRU?
[20:08] <MTecknology> geser: I made one bug fix that's in ubuntu now and i've been trying to make the perfect debian/ dir for a package i want to get into debian. I've been learning a lot
[20:10] <prefrontal_> can someone clarify for me - every time i do pbuilder create ... it deletes my current default pbuilder env and starts from scratch?
[20:11] <geser> pbuilder create is only to setup a pbuilder from fresh
[20:11] <prefrontal_> ok but what i'm not clear on is whether it makes an additional pbuilder or nukes my old one first
[20:12] <geser> you do "pbuilder create" only once, and later only "pbuilder update" (to update it), "pbuilder build" to build a package, etc.
[20:12] <prefrontal_> but what if i login and then install a bunch of packages and then exit?
[20:12] <prefrontal_> then i have tainted it right
[20:12] <geser> no
[20:12] <prefrontal_> oh
[20:13] <prefrontal_> all clear, thanks
[20:14] <geser> pbuilder creates a "base.tgz" (in /var/cache/pbuilder), "pbuilder login" unpacks this base.tgz below /var/cache/pbuilder/build and removes this "copy" when you're done (log out from pbuilder)
[20:14] <ScottK> prefrontal_: If you want a persistent change in the pbuilder chroot you do login --saver-after-login.  It's hard to do by accident.
[20:22] <debfx> arand: you need to target DIST-proposed (e.g. karmic-proposed) for SRUs
[20:23] <arand> debfx: Ah for the debdiffs? More things I should look over?
[20:25] <MTecknology> so a new version of a package was uploaded and is marked as Done; how long does it usually take before that's reflected in packages.ubuntu.com?
[20:26] <debfx> arand: yes, looks fine otherwise
[20:27] <MTecknology> oh.. on http://archive.ubuntu.com/ubuntu/ - what are the different directories for?
[20:27] <MTecknology> jackass.canonical.com ??
[20:28] <debfx> arand: then you need to subscribe ubuntu-sru
[20:29] <arand> debfx: Oops, facepalm, though I'd already done that...
[20:29] <sistpoty> MTecknology: dists contains package files for each distribution. pool is the package pool (there's only one for all distributions, meaning that there can be only one package with the same version per distribution)
[20:30] <sistpoty> s/per distribution/for all distributions/
[20:30] <MTecknology> so pool/ is the latest and greatest of all?
[20:30] <sistpoty> MTecknology: every binary and source package is in there, yes :)
[20:31] <prefrontal_> what happens to my .deb after pbuilder build makes it?
[20:31] <prefrontal_> it seems to not have copied it to the directory i started pbuilder in
[20:31] <geser> prefrontal_: look in /var/cache/pbuilder/results
[20:32] <sistpoty> prefrontal_: default is /var/cache/pbuilder/result (overridable with --buildresult)
[20:32] <sistpoty> hi geser
[20:32] <geser> Hi sistpoty
[20:33] <prefrontal_> thanks.
[20:34] <MTecknology> sistpoty: oh... so everything just exists in pool/ and Packages.bz2 is the list of what you can install from that repository?
[20:34] <geser> yes
[20:35] <sistpoty> prefrontal_: btw.: took me some time to find out I could put this in ~/.pbuilderrc: BUILDRESULT=$(pwd)/result/
[20:35] <MTecknology> so is debian run about the same way, just that ubuntu tries to make things much easier for others to contribute and find their place to contribute?
[20:36] <sistpoty> MTecknology: I wouldn't exactly state that it's that much easier to contribute in Ubuntu
[20:37] <sistpoty> MTecknology: what's different is that debian is organized democratically (at least formally), while ubuntu is based on a dictatorship (officially referred to as meritocracy)
[20:38] <MTecknology> sistpoty: I'm not much of a politicts person so that just went over my head :P
[20:38] <sistpoty> heh
[20:39] <MTecknology> I know who my president is for once, that's about the extent of it
[20:40] <xhaker_> hi sistpoty. can you please sync postgis 1.5.1-1 from unstable?
[20:40] <sistpoty> xhaker_: sorry, not an archive admin, so I can't sync. Does it need an FFe? If so, bug number?
[20:41] <MTecknology> sistpoty: btw - i didn't mean anything bad about debian, just seems like ubuntu focuses on making things pretty and easy
[20:42] <sistpoty> MTecknology: didn't understand it in a way that is bad in regards to Debian ;)
[20:42] <MTecknology> ok :)
[20:43] <xhaker_> sistpoty: it's in universe. though motu-release members could sync
[20:43] <xhaker_> s/though/thought/
[20:44] <sistpoty> xhaker_: there's no motu-release any longer, only ubuntu-release (teams have joined). However being a member of -release doesn't mean that I can do a sync, only ack a FFe requesting a sync ;)
[20:44] <MTecknology> how long does it normally take archive.ubuntu.com to sync to us.archive.ubuntu.com ?
[20:45] <sistpoty> MTecknology: no idea, you could eventually ask elmo on -devel, he'd certainly know. My personal experience between a.u.c and de.a.u.c is between 8 hours and one day backlog
[20:46] <MTecknology> sistpoty: oh- thanks
[20:48] <MTecknology> hrm....
[20:49] <MTecknology> I just switched my mirror to archive.ubuntu.com and I still can't get the new package
[20:50] <mpt> micahg, you had a question?
[20:51] <mpt> (Sorry, Lucid crashed for me, didn't see it until just now when I checked irclogs.ubuntu.com:-)
[21:19] <prefrontal_> when I sign my package using debuild -S it asks me for my gpg password twice and then says success. but when i use pbuilder build on that it says it fails to verify my signature
[21:22] <sistpoty> prefrontal_: can you pastebin the message from pbuilder?
[21:23] <geser> I assume it's because gpg inside the pbuilder doesn't know the key
[21:27] <micahg> mpt: yeah, I wanted to make sure I did the right thing to get Thunderbird to shwo up in the software center
[21:28] <mpt> micahg, USC (almost exactly) follows the table and algorithm given here: https://wiki.ubuntu.com/SoftwareCenter#Genre
[21:28] <mpt> micahg, so the way to get Thunderbird into "Mail" is to set the .desktop category to "Email"
[21:29] <micahg> mpt: k, that's what I did, so when does that refresh
[21:30] <mpt> micahg, I *think* USC updates its catalogue whenever you do apt-get update or equivalent
[21:30] <mpt> But I'm not an expert on that, mvo would know more.
[21:30] <mpt> oh, wait
[21:30] <mpt> change to .desktop file
[21:30] <mpt> That requires a change in app-install-data
[21:30] <mpt> -ubuntu
[21:31] <micahg> mpt: k, so I just wait for the update after I push the .desktop change
[21:32] <mpt> micahg, once you've uploaded a fixed version, I think someone needs to set off a process that updates app-install-data-ubuntu. But again, that's is a bit outside my area of expertise. :-)
[21:33] <mpt> mvo or, probably, anyone on the Desktop team would know.
[21:33] <micahg> mpt: k, thanks
[21:33] <mpt> thanks for fixing it
[21:33] <micahg> mpt: I'll bug chris coulson about it
[21:33] <mpt> k
[21:34] <prefrontal_> my workstation is running karmic, but my pbuilder is lucid. when i run debuild -S to create my source package i get an E (error) from lintian that says bad-distribution-in-changes-file lucid
[21:34] <prefrontal_> i have to be on lucid to make a source package for lucid?
[21:35] <geser> ignore that (lintian from karmic doesn't know of lucid)
[21:35] <sistpoty> prefrontal_: you can ignore that error, lintian on karmic just won't know about lucid. Nonetheless at this point for the release, I'd highly recommend to test the package on a real lucid system
[22:08] <nixternal> hrmm, custom package here, kubuntu-docs, and I have desktop files that need translating, so I am using the .desktop.in stuff....if I add the langpack.mk to the rules and do a dh_install, will it understand what to do?
[22:08] <nixternal> I am a bit confused with the translation stuff, running in circles looking at different packages for ideas
[22:35] <RainCT> nixternal: Hey
[22:35] <nixternal> howdy
[22:36] <RainCT> nixternal: About the mail you've just send to ubuntu-devel@ about the .desktop files, what build system are you using there?
[22:36] <nixternal> cdbs
[22:36] <nixternal> but I could always change that if debhelper is easier
[22:36] <RainCT> nixternal: I mean upstream (or are those .desktop files in debian/)?
[22:36] <nixternal> we use cdbs for all kubuntu packages, so that is why it is being used
[22:37] <nixternal> oh, building with a custom makefile
[22:37] <nixternal> so the makefile builds the docs to kubuntu-docs/build/kubuntu and the rules file installs from tehre
[22:39] <RainCT> nixternal: OK. You can use "intltool-merge -d po/ <name>.desktop.in <name>.desktop" to generate the .desktop file from the .desktop.in, incorporating any translations
[22:39] <nixternal> use that in my makefile?
[22:39] <nixternal> or use it in rules?
[22:40] <RainCT> nixternal: well you can use it in either of them, but I guess doing it in the Makefile would make the most sense
[22:41] <RainCT> brb
[22:41] <nixternal> right, ok...i will go with that then...thanks a ton
[22:42] <sebner> huhu RainCT :D
[23:13] <RainCT> nixternal: sure, no problem :)
[23:13] <RainCT> hi sebner
[23:13] <RainCT> well I'm off to bed, Ubuntu Global Jam tomorrow.. cya
[23:16] <arand> debfx: Are pulling the pathed packages into -proposed yours or the sru-teams area? (Bug #510571 again)
[23:16] <arand> s/pathed/patched/
[23:21] <debfx> arand: ubuntu-sru needs to ACK the SRU request and then you need a sponsor who uploads the package
[23:22] <debfx> arand: I can't do any of that as I'm not a motu
[23:22] <arand> debfx: Right-o, waiting time then.
[23:38] <micahg> in a changelog, the entries go by release order or time order on a merge?
[23:38] <micahg> nm, I found my answer in the merge script :)
[23:44] <mr_pouit> micahg: if you have some time some day, could you give a look at gnome-chemistry-utils in lucid? It ftbfs (imo) because of xulrunner 1.9.2 (built fine a month ago with 1.9.1), and I can't finish a transition (goffice) because of that.
[23:44] <micahg> mr_pouit: yes, I'll try to get to it next week
[23:46] <mr_pouit> micahg: nice, thanks! Just ping me if you need more info at that time.
[23:47] <micahg> mr_pouit: ok


[01:28] <Ubulette> we need NSPR_HEAD_20080120 now
[09:19] <asac_the_2nd> still no asac :(
[10:47] <armin76> nat/canonical?
[10:47] <armin76> asac_the_2nd: you work at canonical? :P
[10:47] <asac_the_2nd> yes, i am at the london office now
[10:47] <asac_the_2nd> and cannot access my home system anymore :(
[10:50] <armin76> mozilla bug 413143
[10:50] <asac_the_2nd> ubotu: wake up!
[10:50] <ubotu> Sorry, I don't know anything about wake up! - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[10:50] <armin76> yuck
[10:50] <armin76> it says time out
[10:50] <asac_the_2nd> mozilla bug 413143
[10:50] <asac_the_2nd> is bugzilla down or what?
[10:50] <armin76> wfm
[10:51] <armin76> https://bugzilla.mozilla.org/show_bug.cgi?id=413143 <- fix
[10:52] <armin76> i have no clue how to fix that :(
[10:52] <asac_the_2nd> hmm
[10:52] <asac_the_2nd> do you use system gif?
[10:52] <armin76> nope
[10:52] <armin76> err, gif?
[10:52] <asac_the_2nd> try to do that
[10:52] <armin76> so what? it's an unaligned access, it should be fixed anyway :P
[10:53] <armin76> since when system gif is available? :P
[10:54] <asac_the_2nd> apparently it isn't
[10:58] <asac_the_2nd> damn ... i hit ctrl+alt+backspace :)
[10:59] <asac_the_2nd> can you paste the bug again?
[10:59] <asac_the_2nd> armin76: ?
[11:00] <armin76> https://bugzilla.mozilla.org/show_bug.cgi?id=413143
[11:03] <asac_the_2nd> ok ... everything is messed up here on my laptop ... have to checkout trunk first
[11:08] <asac_the_2nd> am i still here?
[11:14] <[reed]> no
[11:14] <asac_the_2nd> hehe
[11:18] <armin76> lol
[11:20] <armin76> asac_the_2nd: fix it!
[11:32] <asac_the_2nd> armin76: you are the alignment guy here :)
[11:32] <armin76> haha
[11:33] <armin76> i have no clue :P
[15:27] <jepp> general.useragent.override disappears after restarting firefox
[15:27] <jepp> why is that
[15:27] <jepp> i am also using useragent switcher but i have to switch every time after restart
[15:27] <jepp> does anybody know how i can change user agent of FF permanantly?
[15:29] <jepp> ?
[19:24] <Ubulette> hi
[19:25] <Ubulette> damn, my patched libpng is still broken for apng in ff3 :( I'm not sure it's the lib or ff3
[19:31] <Ubulette> [reed], do you know if it's even supposed to work ? (ie --with-system-png)
[19:33] <armin76> wfm :P
[19:37] <Ubulette> which patch did you use ?
[19:43] <armin76> the one i pasted to you
[19:52] <armin76> hrm...
[19:52] <armin76> i think nss-3.12_beta1 breaks tb-2
[20:00] <Ubulette> ok, i've compared the diffs, i have 2 casts you don't have, that's it. everything else is identical
[20:25] <armin76> so yep, beta1 breaks tb2
[20:25] <armin76> i think alpha didn't...
[20:26] <Ubulette> how does it break ?
[20:27] <armin76> fails to compile
[20:27] <armin76> i'll paste you the log later
[20:32] <Ubulette> could be something i've already fixed a while ago...
[21:38] <armin76> Ubulette: http://rafb.net/p/7sMWqS80.html
[21:38] <Ubulette> yep, fixed
[21:39] <armin76> nss's fault?
[21:40] <armin76> gimme link!
[21:40] <Ubulette> http://patches.ubuntu.com/by-release/extracted/ubuntu/s/seamonkey/1.1.7+nobinonly-0ubuntu2/11_bz399589_fix_missing_symbol_with_new_nss.patch
[21:41] <armin76> thanks :D
[21:41] <Ubulette> you'll need that for all moz 1.8 tools
[21:43] <armin76> yuck, thanks
[21:51] <Ubulette> even with your patch, apng is still broken...
[21:52] <armin76> you broke it!
[21:53] <Ubulette> probably but i don't know how
[21:53] <Ubulette> i'm rebuilding xul once again to be sure
[21:54] <Ubulette> except --with-system-png, did you use anything else ?
[21:54] <Ubulette> (related)
[22:47] <Ubulette> armin76, which version of libpng do you have ?
[23:28] <armin76> Ubulette: no idea, i don't use external png
[23:33] <Ubulette> could you try ?
[23:34] <armin76> tomorrow :)
[23:34] <armin76> if you don't mind :P
[23:34] <armin76> any page i should check?
[23:35] <Ubulette> http://people.mozilla.com/~dolske/apng/demo.html
[23:35] <armin76> okay
[23:37] <Ubulette> armin76, here is what i see with the patch you pointed at yesterday: http://www.sofaraway.org/ubuntu/tmp/ff3-system-apng.png
[23:38] <Ubulette> 1st frame is okay (so regular png are fine) but subsequent frames are corrupted


[07:56] <didrocks> hey mmrazik, do you have some logs about the issues we are currently having in corrupted checkouts?
[07:56] <didrocks> (knowing that we just started fresh from trunk)
[07:57] <mmrazik> pretty much just the output of "bzr branch lp:~mrazik/libdbusmenu/xvfb-run-a"
[07:57] <mmrazik> let me pastebing that
[07:57] <mmrazik> err.. sorry.. output of " bzr checkout lp:~mrazik/libdbusmenu/xvfb-run-a
[07:57] <mmrazik> "
[07:57] <mmrazik> bzr branch works fine
[07:58] <mmrazik> http://pastebin.ubuntu.com/1512096/
[07:58] <didrocks> vila: jelmer: hey! would you have any idea of what can be the cause of this? ^
[07:58] <mmrazik> the steps to reproduce are: 1. bzr branch lp:libdbusmenu
[07:58] <mmrazik> 2. make your changes + commit
[07:59] <mmrazik> 3. bzr push
[07:59] <mmrazik> 4. bzr checkout (from the same location where you just pushed)
[08:00] <didrocks> mmrazik: easier, bzr checkout lp:libdbusmenu has the same issue
[08:00] <didrocks> so something not correct in the launchpad repo?
[08:03] <vila> didrocks, mmrazik : weird, when tried locally I got an additional hint in the error message: "Run 'bzr reconcile --canonicalize-chks' on the affected repository."
[08:04] <vila> which doesn't appear in your paste...
[08:04] <mmrazik> vila: I tried that on my xvfb-run-a repo (locally) and then pushed to xvfb-run-a2 but it didn't help
[08:04] <didrocks> vila: I don't see this hint as well
[08:05] <vila> mmrazik: well, if the lp repo has the issue, fixing your local one won't help (and you may be additionally tricked if the offended repo is stacked on on lp)
[08:06] <didrocks> vila: so bzr reconcile --canonicalize-chks :parent?
[08:07] <vila> hmm, "bzr info -v lp:libdbusmenu" erroring is suspicious, is the lp branch properly configured ?
[08:07] <didrocks> ah interesting, indeed
[08:07] <vila> bzr config -d lp:libdbusmenu
[08:07] <vila> branch:
[08:07] <vila>   stacked_on_location = /+branch-id/590782
[08:07] <vila>   parent_location = ../../../+branch/dbusmenu/
[08:08] <didrocks> the project was renamed
[08:08] <vila> that parent_location is really weird...
[08:08] <didrocks> from dbusmenu to libdbusmenu
[08:08] <didrocks> and I guess when renaming a project, trunk branch naming follows but not the configuration
[08:08] <vila> but shouldn't really matter in fact
[08:08] <didrocks> vila: there should be no parent location for lp:libdbusmenu, it's the real trunk
[08:09] <mmrazik> I start to recall an issue with the rename. Trying to recall what additional bzr command we were running
[08:09] <vila> yeah, I don't think it's ever used
[08:09] <vila> anyway, can you run reconcile on that lp branch ?
[08:10] <vila> if :parent doesn't work, use the lp url instead
[08:10] <mmrazik> will do
[08:12] <mmrazik> vila: bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/%2Bbranch/libdbusmenu/.bzr/) cannot canonicalize CHKs.
[08:13] <mmrazik> btw. what we have done in CPH had something to do with unstacking but I can't figure out the exact command
[08:14] <vila> CPH ?
[08:14] <mmrazik> vila: copenhagen
[08:14] <mmrazik> I believe we did the renaming there
[08:15] <mmrazik> but then checkout of the trunk didn't work due to some stacking errors
[08:15] <mmrazik> and somebody (I believe from the launchpad team) helped us with that
[08:15] <vila> right, I was about to say that lp guys may have better access...
[08:16] <mgrandi> that error seems really vague..
[08:16] <didrocks> bzr reconfigure --unstacked
[08:16] <didrocks> ?
[08:16] <mgrandi> is there no more descriptive error?
[08:16] <mmrazik> didrocks: yep... thats the one we were using
[08:16] <didrocks> mmrazik: maybe try this on lp:libdbusmenu ?
[08:16] <mmrazik> didrocks: thats what we did
[08:17] <didrocks> mgrandi: I guess that's what bzr is giving :/
[08:17] <mgrandi> is there a stack trace?
[08:17] <mgrandi> either in the output or in bzrlog
[08:17] <mmrazik> mgrandi: http://pastebin.ubuntu.com/1512096/
[08:18] <mgrandi> i meant for one that says "cannot canonicalize chks"
[08:18] <vila> so lp:libdbusmenu is stacked on lp:libdbusmenu/12.10 indeed so the error may be there for all we know
[08:19] <vila> bah and that one is stacked on lp:dbusmenu/0.6 ...
[08:19] <vila> and finally stacked on 0.5
[08:20] <mgrandi> russian dolls, bzr style
[08:20] <mgrandi> well having a stack trace
[08:20] <mgrandi> for that 'cannot canonicalize' would help...
[08:20] <mmrazik> btw. I just did the reconfigure and I can checkout lp:libdbusmenu now
[08:20] <mmrazik> but bzr info -v still gives errors
[08:20] <vila> mgrandi: grep shows only one call site
[08:21] <vila> bzr checkout lp:libdbusmenu/12.10 succeeds
[08:21] <didrocks> mmrazik: confirms about checkouting working now
[08:22] <vila> having trunk stacked on another branch... is kind of wrong, you generally want trunk's repo to contain most of the history
[08:22] <didrocks> vila: I think that the indicator team is normally doing at the end of a release, something like:
[08:23] <didrocks> bzr branch lp:libdbusmenu
[08:23] <didrocks> bzr push lp:~…/libdbusmenu/13.10
[08:23] <didrocks> and then, set lp:libdbusmenu to …/libdbusmenu/13.10
[08:23] <didrocks> so that's why we have branches stacked an previous releases I guess
[08:24] <vila> I probably miss why you need such a workflow...
[08:24] <didrocks> vila: I don't know why they are doing that, but it seems to be there one :)
[08:25] <vila> but that's not the best way to use stacked branches
[08:25] <didrocks> I think they don't know (and arguagly, they shouldn't have to know) about stacking
[08:25] <didrocks> arguably*
[08:25] <vila> anyway, you're unblocked right ?
[08:25] <mmrazik> vila, didrocks: yes
[08:26] <didrocks> vila: I think, yeah :)
[08:26] <vila> ok, cool
[08:26] <didrocks> thanks vila, mgrandi!
[08:26] <didrocks> I'll try to have them changing their workflow :)
[08:26] <didrocks> mmrazik: btw, it's part of the things we should write on a wiki, like process to create a new release
[08:26] <vila> didrocks: sounds like a good idea
[08:26] <didrocks> mmrazik: because the unity team is doing one way, the indicator team is doing another…
[08:27] <mgrandi> haha, not sure i did anything but ok
[08:27] <vila> but that "canoot canonicalize" error is worth a bug report, it sounds like something really weird is going on there
[08:28] <didrocks> vila: ok, we'll open one with those info, hoping that we can recreate it :)
[08:28] <vila> mgrandi: well, you pointed out that the error message was weird and that's often the way to detect bugs ;)
[08:28] <mgrandi> yeah
[08:28] <mgrandi> why i try to always give as much info in error messages, vague stuff hurts to look at =(
[08:29] <mgrandi> almost worse then microsoft saying "error code 21124124XABB"
[08:31] <vila> here, the message is triggered by an attribute check on the repo object, so probably something jelmer did for foreign repos except we are dealing with a bzr repo here... so I'm a bit lost
[08:31] <mgrandi> i noticed that it was saying osmething about sha1:blahblah
[08:31] <mgrandi> those are for git right?
[08:32] <jelmer> vila: it's not necessarily something to do with foreign repos
[08:32] <jelmer> vila: just that we happened to have a known bug in bzr-svn that was related to this
[08:33] <vila> jelmer: that was just a feeling ;) A bzr repo object missing a bzr method...
[08:33] <vila> some borked inheritance path ?
[08:38] <jelmer> vila: possibly
[16:51] <xnox> Can somebody push https://code.launchpad.net/~xnox/bzr-dbus/pygi/+merge/137173 ?
[17:47] <mgz> xnox: done
[17:48] <xnox> mgz: thanks


[07:02] <ducasse> good morning
[10:59] <lotuspsychje> good noon to all
[11:24] <lotuspsychje> !19.04
[11:25] <jeremy31> is almost dead
[11:25] <lotuspsychje> yeah oerheks just mentioned :p
[11:25] <oerheks> nein, nein, kein Unterstützung
[11:26] <oerheks> :-D
[11:26] <jeremy31> lets bow our heads for a moment of silence
[11:26] <oerheks> *chop*
[11:29] <lotuspsychje> lol
[11:29] <lotuspsychje> 1min silence for a dead non-lts release
[11:30] <jeremy31> now we can return to the 20.04 pre release party
[11:31] <lotuspsychje> im already partying on daily, having fun with daily xorg crashes
[13:45] <daftykins> lol
[13:45] <daftykins> lotuspsychje: i can't help but wonder if you did a fresh install again and avoided what you might normally change or install, whether they'd go away :)
[14:08] <lotuspsychje> daftykins: good idea to test a recent daily, but still im getting alot of updates, hoping one that fixes at one point :p
[14:09] <daftykins> but the break might be in your config, i'd be willing to bet those prerelease versions mess up so strongly that a good regular wipe is the only true way to test
[14:10] <lotuspsychje> daftykins: some of the bug i encounter are happening on 19.10 too and tested on a live too
[14:11] <daftykins> still
[14:11] <lotuspsychje> the dock flicker fight with xscreensaver for example
[14:11] <daftykins> well it sounded like you said it's just an ignored package
[14:12] <tomreyn> yes, xscreensaver :-)
[14:12] <daftykins> and screensavers are the 90s
[14:12] <lotuspsychje> im puzzled at that bug, guiverc also tested it and also has it
[14:13] <lotuspsychje> works like a charm on bionic
[14:13] <lotuspsychje> and as long as the repos serve it, lotus gonna digest :p
[14:16] <daftykins> what do you use it for, blanking the screens after a timeout or actually showing a ghetto screensaver? :)
[14:16] <lotuspsychje> yeah matrix code after 1min
[14:17] <daftykins> xD
[14:17] <lotuspsychje> with the matrix 4 coming and all lol
[14:28] <lotuspsychje> woe-usb snap only shows publisher, not contact
[14:31] <daftykins> all snaps are woe ;)
[14:32] <lotuspsychje> lol
[14:33] <pragmaticenigma> it wouldn't matter... if they can't read the documentation... they probably shouldn't be using it


[02:29] <ScottK> JontheEchidna: You're an op in #kubuntu due to being on KC.
[02:29] <JontheEchidna> aah, ok
[07:01] <ybit> I made this earlier: http://www.youtube.com/watch?v=cRo4XZrXtc0
[07:01] <ybit> thought some of you might find it interesting
[07:02] <ybit> guess i could send something to the mailing list
[07:02] <ybit> curious if this is the direction others have in mind
[07:02] <ybit> i know there are some who aren't
[07:02] <ybit> some being kubuntu devs
[11:25] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/smokegen] Philip Muškovac * 20 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:26] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/smokeqt] Philip Muškovac * 15 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:28] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kate] Philip Muškovac * 53 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:30] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/okular] Philip Muškovac * 20 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:31] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/printer-applet] Philip Muškovac * 4 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:33] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/marble] Philip Muškovac * 23 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:34] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/libkexiv2] Philip Muškovac * 27 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:35] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/libkdcraw] Philip Muškovac * 25 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:35] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kactivities] Philip Muškovac * 4 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:36] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kross-interpreters] Philip Muškovac * 10 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:38] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kde-runtime] Philip Muškovac * 255 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:42] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kdegames] Philip Muškovac * 142 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:43] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kdemultimedia] Philip Muškovac * 139 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:44] <yofel_> printer-applet_4.7.95-0ubuntu1_source.changes rejected, guess we'll need to update the package set again
[11:46] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kdepimlibs] Philip Muškovac * 156 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:47] <micahg> yofel_: I can sponsor something for you later today if you need
[11:49] <yofel_> I'll come back to that later if the others aren't up
[11:54] <yofel> micahg: actually, can you sponsor kactivities please? http://people.ubuntu.com/~yofel/foo/
[11:54] <micahg> yofel: too tired right now, but can do later today when I get up
[11:54] <yofel> kk
[11:56] <Quintasan> apachelogger: ping
[11:57] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kde-baseapps] Philip Muškovac * 201 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:57] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/libkipi] Philip Muškovac * 26 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[11:59] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/libkdeedu] Philip Muškovac * 22 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[12:00] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/libksane] Philip Muškovac * 19 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[12:05] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/kde-wallpapers] Philip Muškovac * 21 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[12:22] <CIA-48> [lp:~kubuntu-packagers/kubuntu-packaging/oxygen-icons] Philip Muškovac * 91 * debian/changelog releasing version 4:4.7.95-0ubuntu1
[12:25] <yofel> bbl
[16:15] <_Groo_> hi/2 all
[16:15] <_Groo_> yofel: ping
[16:18] <ScottK> yofel: I was going to look at kactivities, I get "You don't have permission to access /~yofel/foo/kactivities_4.7.95-0ubuntu1.dsc on this server."
[17:24] <_Groo_> yofel: ping
[17:51] <yofel> ScottK: can you upload from bzr? (seems sftp keeps permissions...) or I can reupload
[17:51] <yofel> _Groo_: pong
[17:51] <_Groo_> yofel: hey hey :D
[17:52] <yofel> I'll need someone that can upload all of the new packages in main anyway
[17:52] <_Groo_> yofel: did you by any chance compiled 4.7.95 with secrets enabled? just curious
[17:52] <yofel> _Groo_: ksecrets is a seperate package, and no, kdelibs wasn't rebuilt with secrets support
[17:52] <yofel> I'm not even sure how exactly you're supposed to use it
[17:53] <_Groo_> yofel: yes i know ksecrets is a separate package but since its not there, i figured it wasnt added :)
[17:53] <yofel> there's a package in ninjas for precise, feel free to play around with it
[17:53] <_Groo_> yofel: k tks :)
[18:56] <ScottK> yofel: Possibly tonight.  I think you can change permissions in the sftp session, but I'm not sure.
[19:00] <yofel> I reuploaded with fixed permissions
[19:38] <Riddell> hi all
[19:38] <Riddell> yofel: what needs doing?
[19:38] <yofel> Riddell: anything on http://yofel.dyndns.org/kubuntu/bzrstat/ that has 4.7.95 an UNRELEASED
[19:39] <yofel> *and
[19:46] <Riddell> "yuriy-kozlov extended their membership" yay you still love us!
[19:47] <yofel> Riddell: do you have access to the package list for kubuntu-dev btw.?
[19:47] <Riddell> no but it's published somewhere public isn't it?
[19:48] <yofel> well, we need to change it - for the kdeutils and kdeaccessiblity split
[19:48] <yofel> and I'm trying to remember who we asked last time...
[19:48] <Riddell> e-mail cjwatson
[19:48] <yofel> ah, right
[19:48] <yofel> will do
[19:49] <apachelogger> yofel: https://wiki.ubuntu.com/Kubuntu/KubuntuDevelopers#List_of_Packages
[19:49] <apachelogger> also wiki.kubuntu.org is defunct
[19:49] <apachelogger> :(
[19:49] <yofel> yeah, use wiki.ubuntu.com :/
[19:51] <_Groo_> apachelogger: that phonon is a broken code in progress is not actually news ;)
[19:51] <_Groo_> apachelogger: btw kudos... vlc and gstreamer are very stable now :)
[19:52] <_Groo_> apachelogger: i know i like to bash phonon but im a big fan in disquise
[19:52]  * apachelogger used to be a fan :S
[19:54] <_Groo_> apachelogger: you ARE a fan :D
[19:54] <Riddell> maybe apachelogger is using qtmultimediakit
[19:54] <_Groo_> btw, off topic, anyone knows what happened to the vlc daily builds in LP? is the maintainer dead or somthing?
[19:54] <apachelogger> talking about broken code, eh? :O
[19:55] <_Groo_> Riddell: what are the plans for kde 5.0, qt 5.0? phonon or qtmultimedia? any news on if anything was decided?
[19:55] <apachelogger> _Groo_: daily builds are too expensive to maintain on lp :P
[19:55] <apachelogger> OBS supremacy
[19:55] <apachelogger> _Groo_: there is no qt5 :P
[19:55] <apachelogger> there is loads of qthings 5
[19:55] <apachelogger> among them pornon and qtmultimediakit
[19:56] <_Groo_> apachelogger: but was anything decided in last summit? maybe a merge, or a winning backend?
[19:56] <apachelogger> what summit?
[19:56] <_Groo_> or we gonna keep the long standing tradition of supporting everything half baked?
[19:57] <_Groo_> ANY summit :D summits are too many nowadays to keep count
[19:57] <apachelogger> there was no summit where any sort of anything was discussed
[19:57] <apachelogger> sheytan: ping
[19:58] <_Groo_> apachelogger: open governance my *ss
[19:59] <_Groo_> apachelogger: so LP disabled daily builds for all projects is that it?
[19:59] <apachelogger> no
[19:59] <apachelogger> caring about it building is too expensive
[19:59] <apachelogger> so prolly remis just got sick of it :P
[19:59] <apachelogger> asuming remis made the ppa
[20:00] <_Groo_> apachelogger: do you know of a ppa with fairly recent builds i could add?
[20:01] <apachelogger> no
[20:01] <apachelogger> real men build their own vlc
[20:02] <_Groo_> apachelogger: i used to be a real man :( nowadays i dont have time to build evertyhing i would like... i already build amarok, rekonq, (used to build phonon and bastard sons)... a ppa would do
[20:02]  * apachelogger only builds pornon
[20:02] <apachelogger> and even that only ever so often
[20:04] <_Groo_> apachelogger: how do you test phonon-vlc agasint the 1.2 branch then?
[20:04] <apachelogger> I built it once
[20:04] <apachelogger> plus I do not test it
[20:04] <apachelogger> as 1.2 is not supported
[20:05] <_Groo_> apachelogger: well im using pornon-vlc with 1.2 for months now.. works like a charm...
[20:05] <apachelogger> I did not say it does not work
[20:05] <apachelogger> I said it is not supported
[20:05] <apachelogger> very different things
[20:05] <_Groo_> apachelogger: arent you the one always bitching for the second coming of vlc? aka 1.2?
[20:07] <_Groo_> apachelogger: ill just compile today git ¬¬
[20:08] <_Groo_> apachelogger: btw i cant compile phonon master in oneiric anymore... code is too messy
[20:08] <apachelogger> fails to compute
[20:09]  * _Groo_ is confused by apachelogger answer as usual
[20:09] <apachelogger> WFM
[20:10] <_Groo_> apachelogger: ahah :D
[20:10] <_Groo_> apachelogger: one of these days im gonna bump into you in person in some forsaken summit
[20:10] <_Groo_> apachelogger: and you wont know who i am till its too late!
[20:11] <apachelogger> terribly unlikely, I have broken the primary multimedia system for prn
[20:11] <apachelogger> I won't live to see another summit
[20:12] <_Groo_> apachelogger: what? pr0n is broken?????? PITCHFORKS!!!!
[20:12] <apachelogger> see
[20:14] <_Groo_> apachelogger: what am i gonna do now???? i might even do.. do... god forbids... WORK!!!
[20:14] <Riddell> package KDE?
[20:16] <_Groo_> Riddell: yofel is on it :D hes out of pr0n since monday
[20:17] <yofel> _Groo_: feel free to package oxygen-gtk3
[20:18] <_Groo_> yofel: for oneiric or for precise? i can do it for oneiric friday (ill be at home).
[20:19] <yofel> well, shouldn't be much different for precise
[20:19] <_Groo_> yofel: i just need help with the xml generation for the default gtk theme
[20:19] <yofel> ah, that'll be a patch somewhere else anyway I think
[20:19] <_Groo_> yofel: what i mean is, i can test it on oneiric, then i can make it compile in precise, but i cant test it
[20:20] <_Groo_> yofel: we need guinea pigs
[20:20] <yofel> sure, I'm on precise
[20:20] <_Groo_> im using it in oneiric btw, with 4.7.95... works like a charm.. worked fine with 4.7.4 and 4.7.90 too
[20:23] <_Groo_> why dont we use this capable guy work? https://launchpad.net/~gnumdk/+archive/ppa/+packages
[20:27] <Riddell> feel free to investigate
[20:27] <micahg> yofel: you still need sponsoring?
[20:28] <yofel> actually yes
[20:30] <_Groo_> Riddell: anyway, i should have something cooked by friday
[20:31] <_Groo_> i doubt apachelogger fixed pr0n by then ehehehehe
[20:34] <micahg> yofel: same place?
[20:35] <Riddell> micahg: what are you uploading?
[20:35] <micahg> Riddell: yofel mentioned that he can't upload a few things due to the packageset like kactivities
[20:36] <micahg> Riddell: if you've got him covered, I'll move along :)
[20:36] <Riddell> I've got the rest of 4.7.95 preparing now
[20:37] <Riddell> takes a while to run debuild -S on all these packages
[20:40] <micahg> Riddell: ok, I'll leave it to you then
[20:40] <micahg> Riddell: BTW, would it be possible to make a team that owns kubuntu-devel with the DMB and whoever you think is appropriate as members
[20:54] <Riddell> micahg: yeah I should do that but it takes more brainpower than I have just now
[20:54] <Riddell> keep poking me
[20:54] <micahg> Riddell: ok
[20:57] <jussi> Riddell: how you feeling?
[21:01] <Riddell> jussi: I just bought 2 litres of irn bru, that should see me through the next 24 hours
[21:01] <jussi> Riddell: hehe, but seriously - I read the blog post, how are things going? you will make a full recovery I trust?
[21:02] <Riddell> jussi: well I went canoeing today so I can't be that bad
[21:03] <Riddell> or maybe I'm just a very good canoeist that I can do it with one eye shut
[21:03] <jussi> Riddell: fair enough.
[21:03] <jussi> haha
[21:03] <Riddell> I'll probably make a recovery, nobody known for sure, just wait and see
[21:03] <jussi> Riddell: I guess they were not hard  rapids / no rapids at all then? .p
[21:04] <Riddell> not until the end when I was hoping other people would take over the leadership/coaching
[21:04] <Riddell> but not, these polo players just care about themselves and their ball, tsk
[21:16] <JontheEchidna> anybody else seeing uninstallable libkworkspace4 on precise?
[21:18] <micahg> wfm
[21:31] <ulysses> haha, Muon 1.2.65 is „Daring Dalek” :)
[21:35] <JontheEchidna> :P
[21:35] <JontheEchidna> It's actually been Doctor Who aliterations since the first release :>
[22:00] <ScottK> micahg: Why do we need a separate team to own kubuntu-dev?
[22:00] <micahg> ScottK: just an option is Riddell wants to stay as owner
[22:00] <micahg> s/is/if
[22:01] <micahg> we did this for edubuntu so the edubuntu council and the DMB can own/administer, but not receive rights
[22:22] <Riddell> yofel: 4.7.95 building
[22:22] <Riddell> yofel: it's in ppa for oneiric?
[22:22] <Riddell> shall we do a kubuntu.org story?
[22:23] <yofel> you could probably just upload - it build fine in ninjas, and I don't remember adding build-deps
[22:23] <yofel> oh right, the announcement is missing, oneiric is in beta ppa
[22:23] <Riddell> we can be the first! http://kde.org/info/4.7.95.php#binary
[22:24] <Riddell> yofel: do you want to do kubuntu.org or shall I?
[22:24] <yofel> it would be nice if you could do it, I'm busy with something else currently
[22:24] <Riddell> can do
[22:30] <Riddell> http://www.kubuntu.org/news/kde-sc-4.7.95
[23:03] <micahg> is it ok for me to give back the kdelibs5-dev armel failures? it seems to be built and published now
[23:06] <micahg> retrying
[23:18] <Riddell> thanks micahg
[23:19] <micahg> I had a list from last week already and a shell command to just retry them all :)
[23:28] <Riddell> nifty
[23:28] <Riddell> yofel: hmm, pykde4 failure?
[23:29] <Riddell> not what happened in the oneiric ppa
[23:30] <yofel> wth...
[23:30] <yofel> neither in precise ninjas
[23:33]  * yofel looks for build-dep changes
[23:40] <yofel> Riddell: It's the new sip that ScottK uploaded 3 days ago, I uploaded to ninjas a day before that, and downgrading sip makes pykde build again
[23:41] <yofel> ah, came from debian
[23:41] <JontheEchidna> the best I can tell is that sip is magic
[23:42] <yofel> agreed
[23:43] <Riddell> hmm, email simon?
[23:43] <micahg> yofel: sorry, a lot of those armel retries will come back as failed again since kde-workspace isn't built, I'll retry them again later once that's built
[23:44] <yofel> np, mail mailbox is flooded anyway
[23:44] <yofel> *my mailbox
[23:44] <micahg> I just retried kde-workspace on all archs and it's building or queued now