[08:31] <fabbione> interesting :)
[08:31] <fabbione> today's installer does install the kernel and for some reasons removes it immediatly after
[08:32] <fabbione> leaving yaboot in an interesting state ;)
[10:41] <Kamion> fabbione: today's installer is not worth looking at
[10:41] <Kamion> ignore it
[10:42] <Kamion> it is an ex-installer, it has ceased to be, it's pushing up the daisies, it's gone to join the choir invisible
[10:42] <fabbione> Kamion: yes i noticed :)
[10:42] <fabbione> specially when i saw: Removing linux-image...
[10:43] <Kamion> please try to find out what conflicts with old linux-image
[10:44] <fabbione> i did try
[10:44] <fabbione> but when i did chroot in target
[10:44] <fabbione> and done apt-get install linux-powerpc
[10:44] <fabbione> it just went in smoothly
[10:44] <fabbione> no info of any kind
[10:44] <fabbione> it didn't report any conflicts whatsoever
[10:44] <Kamion> you didn't need to try that, you could just have looked in /var/log/messages and/or /var/log/syslog to see what caused the removal
[10:45] <Kamion> i.e. what it was doing when it removed the package
[10:45] <fabbione> sure
[10:45] <fabbione> i can check that too
[10:57] <fabbione> ah
[10:57] <fabbione> it tries to install hotplug
[10:57] <Kamion> that'll be fixed soon
[10:58] <fabbione> and kicks out a bunch of stuff
[10:58] <fabbione> ok
[10:58] <fabbione> i had no doubts :)
[10:58] <Kamion> no as in I think it's already fixed in our archive, just needs an initrd rebuild
[10:59] <Kamion> yeah, it is
[10:59] <fabbione> ok
[10:59] <fabbione> it sounds strange tho
[10:59] <fabbione> because that's the output from what happens after debootstrap
[10:59] <fabbione> it install the kernels
[10:59] <fabbione> than it attemps to install another bunch of stuff
[10:59] <fabbione> and it's there that kills the kernel
[11:00] <fabbione> but well i am sure you know better than me
[11:00] <fabbione> :)
[11:00] <ogra> Kamion, there were several people having problems with pcmcia stuff on non-pcmcia machines last night, where the booting locked up on pcmciautils... known ?
[11:02] <Kamion> ogra: see my comment to Diablo-D3 on #ubuntu-devel
[11:02] <Kamion> 09:38 < Kamion> Diablo-D3: if you haven't already, could you please install the 2.6.15-6 kernel, reinstall pcmciautils, and confirm/deny that the lockup is gone?
[11:02] <Kamion> 09:39 < Kamion> Diablo-D3: if it isn't gone, please *report a bug* rather than using several hundred lines of my #ubuntu-devel scrollback on it, kthxbye :-)
[11:02] <Kamion> 09:40 < Kamion> Diablo-D3: because pcmciautils is going to stay in minimal - the packaging/upgrade issues are too difficult to deal with otherwise - so we need to make sure any lockups such as this are fixed
[11:02] <Kamion> Diablo-D3 said he was using 2.6.15-5, where soft lockups were a known problem
[11:02] <ogra> ah, ok
[11:03] <ogra> i didnt talk to him anymore, he cant behave ... but LaseJock seemed to have similar issues ... he used 2.6.15-5 too ...
[11:03] <ogra> *LaserJock
[11:04] <ogra> just wanted to make sure it didnt slip through
[11:04] <Kamion> right, nobody that I saw reported it with -6
[11:04] <Kamion> but that isn't conclusive evidence that it's gone
[11:04] <ogra> i havent seen such problems here ...
[11:04] <Kamion> so I want to make sure everyone retests, rather than just removing pcmciautils
[11:05] <Kamion> no, it will depend on your hardware. there were pcmcia crashes in the old world order as well, it's just that we didn't install pcmcia-cs on machines without pcmcia then
[11:05] <Kamion> (because of this)
[11:05] <ogra> yup, old debian behavior :)
[11:06] <Kamion> was sane
[11:06] <Kamion> you didn't want cardmgr running on desktops
[11:06] <ogra> yes, i just remembered the installer question ...
[11:07] <Kamion> damnit, d-i's going to fail to build
[11:09] <fabbione> whops
[11:09] <fabbione> :)
[11:10] <Kamion> OTOH once I promote the relevant thing, sparc might build this time round
[11:11] <fabbione> Kamion: no rush.. as usual
[11:11] <Mithrandir> woohoo, I think I've fixed kbd-chooser now.
[11:11] <fabbione> for sparc we are way to early in the release process to worry :)
[11:12] <Kamion> I care about sparc because its lack of building d-i is causing noise in anastacia output that we have to ignore
[11:12] <fabbione> Kamion: btw. i am going to look at that devmapper/lvm2 selinux thing on ppc
[11:12] <fabbione> ah ok
[12:05] <Mithrandir> and now it actually works.
[12:30] <fabbione> let see how my laptop will explode with the new kernel/udev and stuff
[12:33] <fabbione> WOO WOOOOO
[12:33] <fabbione> go X!
[12:33] <fabbione> at least it boots fine


[12:31] <juli_> Hi everybody, can someone answer my question, please.
[12:31] <juli_> I want to package a java lib which is built using Ant. Source distribution contains java sources and a number of tests. Is it ok to skip tests in the build target i.e.  don't build and run them but only build the library's jar itself (“ant jar” vs “ant release” in my case)? Or I have to run tests?  The problem is that tests introduce extra-dependencies.
[13:46] <maxb> juli_: AFAIK it's largely up to the people working on the package whether they consider running the testsuite as part of the build is worthwhile
[14:21] <persia> juli_, It's considered best practice to run the tests, but it's certainly not required.
[14:21] <persia> The reason for running the tests is to make sure that the library works.  In some cases it's more convenient to have a FTBFS than a broken library.
[14:40] <juli_> persia, thanks for the answer. I did run tests on my system, but they require a lot of jars (build-dep) so it is not easy to run them in package.  I think  I'll also ask the lib author's opinion.
[14:41] <persia> juli_, It's really just about your peace of mind as the maintainer.
[14:42] <persia> If you're willing to make sure that the shipped binary package always works, then you can do it that way.  Forcing the build failure just automates this.
[14:43] <persia> The trick is that if you don't run the tests during the build, you probably need to rewrite some of the tests to use the library installed by the package, rather than the library constructed by ant.
[14:43] <persia> Or you can just hope it works, which is what most folk do :)
[15:51] <juli_> persia, thank you. I think I'll run tests locally but skip them in the package.  Furthermore this lib is used by NetBeans so it will be a kind of test:)
[15:53] <persia> As long as you're feeling confident :)
[15:56] <juli_> I'll definitely be confident before I'll ask to upload a package.
[15:59] <persia> Well, it's also the testing post-upload.  Without running the tests at build time, you have to manually check the results, in case there was something funny about the buildd that day, etc.
[16:00] <persia> (not that this is usually an issue)
[16:03] <juli_> ok, I'll see what I can do about post-upload testing.


[05:52] <Stormer> I think Ubuntu should no longer include Firefox by default because Firefox has become spyware. Firefox maintains a connection to 'googleusercontent.com' the entire time its running and there is no way to stop it.
[06:49] <LocutusOfBorg> vorlon,
[06:49] <LocutusOfBorg> # vorlon, 2017-11-09: Ubuntu is upstream, package named differently (signon vs. signond), Debian version is behind
[06:49] <LocutusOfBorg> signond
[06:49] <LocutusOfBorg> we might want to remove it from sync-blocklist?
[06:50] <vorlon> I suppose so!
[06:50] <vorlon> LocutusOfBorg: done
[06:50] <LocutusOfBorg> :D
[06:51] <LocutusOfBorg> thanks
[06:51] <LocutusOfBorg> (I'm reviewing and checking the merge)
[07:22] <LocutusOfBorg> arraybolt3, I made a review for it ^^


[21:41] <ryanakca> mdke: Hi, were there reasons behind fixed width over fluid width (in ubuntunew )?
[21:42] <ryanakca> s/were there/what were the/g
[21:49] <newz2000> that was a topic of great debate
[22:03]  * ryanakca looks in the ML


[00:05] <JonyBlaze> anyone want to critique my first package ever (minus the walk-throughs)?
[00:05] <JonyBlaze> i would like to get it into ubuntu in the future
[00:06] <JonyBlaze> https://launchpad.net/~ezrareeves/+archive/pep8
[00:06] <tsimpson> how about uploading it to revu
[00:06] <JonyBlaze> i would have to build it for lucid for that wouldnt i?
[00:08] <tsimpson> JonyBlaze: well, if you want it in ubuntu
[00:09] <tsimpson> besides, it's just a source upload. so just update the changelog
[00:09] <JonyBlaze> right
[00:10] <tsimpson> revu lets motu post comments and you can re-upload without bumping the version
[00:13] <JonyBlaze> ok i will do that then
[00:15] <Laney> jdong: poor motu-sru!
[00:15] <jdong> Laney: it's mostly okay; I think karmic response time hasn't been too awful for SRUs
[00:15] <jdong> I'm making best effort at 24h turnaround
[00:15] <Laney> did you get put back into the process yet? ;)
[00:16] <jdong> Laney: nope!
[00:16] <jdong> and nobody said anything on the list either!
[00:16] <Laney> pitti made the change iirc - maybe you could ask him directly
[00:18] <Amaranth> MTecknology: gah, I changed the description for the flash bug too
[00:18] <MTecknology> Amaranth: same time?
[00:18] <Amaranth> Apparently
[00:18] <Amaranth> Or right before you
[00:18] <MTecknology> lol
[00:18] <Amaranth> Mine dropped workaround two and added a new workaround three from comment 163
[00:19] <Amaranth> Seemed like the easiest one of the nspluginwrapper hacks
[00:19] <Amaranth> and mentioned Chrome users were out of luck entirely
[00:19] <MTecknology> Amaranth: right after me; yours is the one that took
[00:19] <MTecknology> https://bugs.edge.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/410407/+activity
[00:19] <Amaranth> oh, goody
[00:27] <MTecknology> Amaranth: dangit... compiz is breaking my website -_-
[00:28]  * Amaranth uses the bat again
[00:29] <MTecknology> Amaranth: my site is kinda broken though..... I'm doing this thing where I try to knock out hundereds of lines of css to make things less bloated and easier to work with (and hopefully not fight nail and teeth to make show up decent in IE6)
[00:38] <fcuk112> in python there is a section that checks os.environ.has_key("XXX_PATH").  how does XXX_PATH get set here?
[00:38] <mzz> fcuk112: I don't understand the question
[00:39] <fcuk112> i mean, how do i find out where this environment variable got set?
[00:39] <mzz> fcuk112: os.environ is the environment, so on a unixy system you'd do something like "XXX_PATH=foo python ..."
[00:40] <mzz> fcuk112: or it may already be set in the environment you run python from (try running "echo $XXX_PATH"), or some other bit of python may be adding it to os.environ, or some extension module may be setting it from c
[00:40]  * dtchen prepares more pulseaudio crack for the lucid crackheads
[00:40] <mzz> there's not really a callback on setting an env var, you'd have to resort to basic grpping
[00:40] <mzz> oh wait, this isn't #python
[00:40] <fcuk112> yea i tried, couldn't see it.
[00:40] <fcuk112> hehe
[00:40] <mzz> sorry, bit of a mischan, but I guess what I said still applies
[00:41] <mzz> fcuk112: is this really literally "XXX_PATH", and what's the context to this?
[00:46] <jdong> dtchen: you can upload into main, right?
[01:03] <fcuk112> fixing a tomboy notes screenlets bug, it was pointing to the wrong path.  before that it was trying to source from the env.  but it's all good, i was testing the wrong version of the py script.
[01:15] <dtchen> jdong: no, I don't have upload privileges.
[01:16] <dtchen> I think there are a couple people who do lurking about
[01:19] <serialorder_> why would a debian directory have both a changelog and a changelog.in ?
[01:22] <serialorder_> if you have package_ver-0ubuntu2 and a recently updated package_ver-1 and no new changes need to be made because of debian's update what should be done?
[01:30] <dtchen> assuming the orig.tar.foo matches, request a sync from Debian $release
[01:30] <ajmitch> jdong: I have upload rights but no bandwidth here
[01:37] <jdong> dtchen: can I get your opinion/blessing on the debdiff proposed in https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/330766
[01:37] <serialorder_> dtchen, its not a sync because ubuntu makes some changes it just happens that ubuntu packaged the new version before debian so the ubuntu specific deltas need to be preserved its just that debian didnt introduce anything new
[01:37] <serialorder_> i dont know if that is clear enough
[01:39] <ajmitch> serialorder_: then make package_ver-1ubuntu with the debian revision as a base, with the ubuntu changes you need to keep
[01:40]  * ScottK hands ajmitch another '1'.
[01:40] <ajmitch> just say "Merge from Debian Squeeze, remaining changes:" or something similar
[01:40] <ajmitch> ScottK: yeah, typing via ssh from a conference :)
[01:41] <ScottK> I figured you knew, but just in case someone else thought that was correct.
[01:41] <ajmitch> yes sorry, i was typing too fast to check :)
[01:53] <serialorder_> ajmitch, when I list the remaining changes in the changelog should I retype them from before or just put a refernece  the original versions that introduced the changes?
[01:54] <ajmitch> list all changes that still affect the version you're working on
[01:54] <ajmitch> and list changes that you've dropped since the last version, too
[01:54] <ScottK> serialorder_: The next person that comes along to look at the package should be able to understand both the what and the why of the difference from Debian with just that changelog entry.
[01:55] <serialorder_> ok so then it is not sufficient to just list the entries lower in the changelog that specify why, that is good to know
[01:57] <ScottK> Since we do team maintenance here, it should be easy for anyone picking up the package to understand what's up with it.
[01:59] <serialorder_> should i list which versions the deltas are preserved from as well?
[02:02] <ScottK> No.
[02:02] <ScottK> Current state is what's important.
[02:03] <ScottK> When I do a merge, I have a habit of just dropping any undocumented changes I find unless it's obvious why they are needed (and then I document them).
[02:08] <ScottK> 3 out of 3 hunks FAILED -- saving rejects to file debian/rules.rej
[02:09] <ScottK> 5 out of 5 hunks FAILED -- saving rejects to file debian/control.rej
[02:09] <ScottK> \o/
[02:09] <ScottK> So much for the easy way.
[02:15] <JontheEchidna> Was there ever a source format 2.0?
[02:17] <ScottK> JontheEchidna: Google wig and pen.  Never deployed.  Heavily bike shedded over the years.
[02:21] <JontheEchidna> Interesting.
[02:31] <ScottK> So now which goes faster?  The laptop battery (11% and declining) or the tarball upload?
[02:32] <ajmitch> my laptop is working remarkably well in karmic now... except for important things like the cooling fans
[02:33] <ajmitch> even suspend/hibernate is working, so it's strange that the fan part of the ACPI info is just missing
[02:33] <ScottK> Easily worked around with a bag of ice.
[02:33] <ajmitch> except that I have it on my lap at pycon
[02:34] <ajmitch> I think I'll upgrade the BIOS before filing a bug about it
[02:56] <fcuk112> is launchpad.net running ok for you guys?  i am getting timeout errors.
[02:57] <ScottK> That's not rare.
[03:15] <p3rror> please can you explain the memory process when you do a SQL select on a table
[03:15] <lifeless> not really, thats more #mysql or #drizzle or #postgresql or ....
[04:06]  * ScottK gives up on trying to figure out if there is a way to get the laptop on the other side of the room to unsuspend so he can ssh into it and avoid getting up off the couch.
[04:56] <pmcenery> Does anybody have any recommendations on a pbuilder environment. What I mean by this is... for me, I dont really want my primary workstation to be bloated with packages. Instead, I'm thinking of either schroot for a couple of different pbuilder environments, or possibly lxc. Is there anyone who uses this sort of config for their build environment who has some valuable advice on the subject?
[05:13] <dtchen> pmcenery: well, I tend to have multiple pbuilders, sbuilds, schroots all hooked to an apt-cacher-ng instance on the host. That way it doesn't really matter about "bloating".
[05:16] <dtchen> jdong: looks sane, of course
[05:16] <dtchen> christoph's comment is nicely irrelevant, and the workaround is pretty kludgy
[05:17] <jdong> dtchen: *nods* thanks for the input
[05:17] <jdong> ScottK: ^^ based on that, and ebroder uploaded a new debdiff with correct versioning, could you do the honor of uploading to main?
[05:18] <ScottK> jdong: What bug again?  I'll probably put it off until tomorrow since I'm very tired and making silly mistakes at the moment.
[05:19] <jdong> ScottK: bug 330766
[05:19] <jdong> thanks, Scott :)
[05:21] <pmcenery> dtchen: thanks for the info.
[05:23] <dtchen> yw
[05:26] <ScottK> OK.  Got it.  Off to crash now.
[05:26] <jdong> good night!
[05:57] <astechgeek> Is the ubuntu-motu-mentors mailing list for Mentors or people looking for mentors?
[05:58] <jmarsden> astechgeek: The latter, I think, but some mentors are subscribed to it too.
[05:58] <astechgeek> okay just wanted to make sure I didn't want to subscribe being that Im looking to get involved and have no clue where to start
[05:58] <jmarsden> astechgeek: You can read the archives at https://lists.ubuntu.com/archives/ubuntu-motu-mentors/ before you subscribe...
[05:59] <astechgeek> I was reading through the articles on the ubuntu wiki about getting involved...
[05:59] <jmarsden> Good :)
[06:00] <astechgeek> as a noob where would be the best place to go to get started in contributing?
[06:01] <jmarsden> Well, it depends how fast you learn... if you want to contribute in MOTU-like work, you can use the six steps in https://wiki.ubuntu.com/MOTU/GettingStarted as a guide, and ask questions here in #ubuntu-motu
[06:01] <jmarsden> If after reading some of the material you decide packaging is too technical for you, consider joining the bugsquad and doing bug triage, etc to start with, maybe?
[06:01] <astechgeek> i have programming exp but don't feel confident enough to try the development side
[06:02] <jmarsden> MOTU stuff is more about basic scripting and use of tools than deep programming knowledge.
[06:02] <astechgeek> okay what about the bugsquad?
[06:03] <jmarsden> https://wiki.ubuntu.com/BugSquad
[06:03] <astechgeek> do they have a channel?
[06:03] <dtchen> #ubuntu-bugs
[06:04] <jmarsden> It's often more about asking bug reporters for more more info and duplicating bugs reports than deep debugging..., and yes, #ubuntu-bugs
[06:04] <astechgeek> simple enough :-D
[06:06] <astechgeek> thanks for the help, the descriptions will help ensure that I get involved with something that I'm comfortable with.
[06:11] <jmarsden> No problem, and welcome :)
[09:00] <MTecknology> Amaranth: compiz is breaking java too..... I don't use compiz but... ya know... it's not working :P
[09:00] <MTecknology> g'night all
[09:23] <ripps> I'm want to apply to become a MOTU, I want to know if anybody can look over my wiki and tell me what else I can do. https://wiki.ubuntu.com/ripps818
[09:25] <slytherin> ripps: have you done any contribution in terms of packaging in Ubuntu?
[09:27] <ripps> slytherin: I maintain 100+ packages in the gmpc-trunk team ppa's. I've also created several new packages that have gotten into Debian and then synced into Ubuntu
[09:28] <slytherin> ripps: PPAs are not official repository. And Debian is not Ubuntu. :-)
[09:28] <ripps> slytherin: well, I've tried time and time again to get packages through REVU, but it never pans out and I'm always ignored.
[09:28] <slytherin> ripps: thing is that if you want to apply for MOTU membership you need to demonstrate that you have helped packaging in Ubuntu directly and you blend in the community.
[09:29] <hyperair> slytherin: but packaging stuff for debian which get synced into ubuntu is recognized
[09:29] <slytherin> ripps: new packages is not the only way to help. You can fix existing packages.
[09:30] <ripps> I've made a few patched packages that I've offered up in my Testing PPA, like a focus glitch in compiz-plugins-main. It was fixed in Karmic, but I still have the Jaunty package in there.
[09:30] <slytherin> hyperair: not necessarily always. You can not get motu membership simply on the basis of youe debian work.
[09:32] <ripps> I'd gladly participate more with package fixing and new software in Ubuntu, but It always seems that nobody notices when I try to help. Maybe I'm just not vocal enough
[09:32] <slytherin> ripps: no. we are always short on manpower
[09:33] <hyperair> slytherin: true, but almost all my work in ubuntu is pushed in through debian. more people benefit that way.
[09:33] <slytherin> hyperair: I know.
[09:35] <ripps> Well, I have a few packages sitting in Debian Mentors, but I haven't been able to get anybody to sponsor it yet. If I upload it to REVU, can I get some help getting it accepted?
[09:35] <hyperair> ripps: you have to poke people here
[09:35] <ripps> I have, many times, but I'm usually ignored....
[09:35] <hyperair> ripps: try again >_>
[09:36] <hyperair> not everybody's free all the time
[09:36] <hyperair> if you just try a few times and give up, it's never going in
[09:36] <hyperair> i find it's easier to find a sponsor here than in debian mentors
[09:36] <hyperair> i've got a few packages sitting in mentors for months on end
[09:36] <fabrice_sp> in general, you will get more attention fixing existing packages than bringing new packages to Ubuntu
[09:37] <slytherin> ripps: That is the reason I said fixing up existing packages is better way to contribute. Once you are known in community it is easier to find sponsors for new packages.
[09:38] <ripps> Well, I have an updated liburiparser package, anybody interested in looking at it?
[09:38] <fabrice_sp> bug?
[09:38] <ripps> fabrice_sp: well, it's a requirement in order to get libxspf in, which is being called on increasingly in upstream for xspf playlist support
[09:39] <fabrice_sp> is there any bug number in launchpad?
[09:39] <fabrice_sp> for the new version upgrading
[09:40] <ripps> fabrice_sp: I don't see any launchpad bugs...
[09:41] <hyperair> ripps: imo the best way to handle getting packages into ubuntu is to get the update into debian, and then handle the sync/merge in ubuntu yourself instead of waiting for someone else to do it.
[09:41] <ripps> hyperair: I know, I did that with the libcue package I made
[09:44] <hyperair> well yeah, handle a few more and then apply for motuship or contributing-developer status
[09:45] <hyperair> contribution first, status/upload rights later
[09:50] <fabrice_sp> when beginning to contribute, I discover that you should be more proactive in opening bug reports to fix things, and open new ones to get your  stuff sponsored.
[09:52] <ari-tczew> hello
[09:52] <ari-tczew> devs, I have a question
[09:54] <fabrice_sp> !ask
[09:55] <fabrice_sp> :-D
[09:55] <ari-tczew> package in karmic have a patch, but unstable & testing have a new upstream version in repositories which these new versions have patch applied upstream. can is it a sync into lucid?
[09:55] <fabrice_sp> sounds like yes
[09:56] <fabrice_sp> if the patch has been integrated upstream, and the new package works (builds/installs/runs) fine, yes
[09:56] <ari-tczew> I guess that isn't can done by Ubuntu Archive Autosync, so do I need to open a sync request, right?
[09:57] <ari-tczew> of course including buildlog and information that patch has been applied upstream
[09:57] <fabrice_sp> yes
[09:57] <ari-tczew> ok, thanks ;-)
[09:57] <fabrice_sp> ;-)
[09:59] <ari-tczew> fabrice_sp: In this cycle's moment sync's requests needs MOTU ack?
[09:59] <ari-tczew> or only sponsor?
[10:00] <fabrice_sp> sponsors
[10:00] <ari-tczew> ok
[10:02] <fabrice_sp> motu-release subscription is when feature freeze is on
[10:03] <fabrice_sp> got to go. Bye
[10:05] <ari-tczew> ok bye
[10:12] <Nafallo> bdrung: no
[10:14] <bdrung> Nafallo: ?
[10:14] <Nafallo> 18:03:23 #ubuntu-motu: < bdrung> bigon: did you upload gajim to karmic-proposed?
[10:14] <Nafallo> doh
[10:14] <bdrung> k
[10:14]  * Nafallo should stop hilighting on gajim / wake up :-P
[11:15] <randomaction> Packages uploaded to REVU should target lucid, right? REVU complains: "Package is for "lucid" but only packages for "karmic" are currently accepted."
[11:19] <mok0> randomaction: that's abug
[11:20] <randomaction> I guess someone should update current development target
[11:20] <mok0> yeah
[11:20] <randomaction> is it worth filing a bug at LP?
[11:20] <mok0> You could
[11:21] <mok0> REVU has a project there
[11:21] <mok0> Then the devs wont forget :)
[11:22] <randomaction> ok, will do
[11:23] <mok0> Great, thx
[11:51] <geser> when merging an Ubuntu changelog into the Debian one, do we sort the Ubuntu changes by version or by date?
[11:53] <ari-tczew> I guess that by version
[11:57] <hyperair> by date would make things very confusing imo
[12:01] <ari-tczew> what is it a thing called an 'Ubuntu delta'?
[12:02] <geser> Ubuntu delta = differences between the Debian package and the Ubuntu one
[12:02] <ari-tczew> ok thnx
[12:44] <diwic> While trying to create a pbuilder environment for lucid, I ran into the following error: diff: PreDepends: diffutils but it is not installed
[12:44] <diwic> Any ideas?
[14:12] <ari-tczew> bugs looking for sponsors - merge to lucid:
[14:13] <ari-tczew> bug #477387
[14:13] <ari-tczew> bug #477389
[14:14] <c_korn> what is the correct why of a -dev package to depend on the library package ? I get lintian warnings with both binary:Version and source:Version
[14:38] <geser> what exactly did you put into debian/control?
[15:27] <ScottK> Possible new packaging opportunity coming our way; http://share.skype.com/sites/linux/2009/11/skype_open_source.html
[15:29] <hyperair> ScottK: i was thinking about that as well, but it seems that the protocol remains close sourced.
[15:31] <ScottK> hyperair: It will no doubt, have to go in Multiverse, but having it in the repos would be an improvement
[15:31] <hyperair> ScottK: do binary blobs go in multiverse?
[15:32] <ScottK> hyperair: If they are redistributable.
[15:32] <hyperair> chances are that the protocol library will remain a binary blob if it isn't opened as well
[15:32] <hyperair> ah
[15:32] <hyperair> so they can eh..
[15:32] <ScottK> Absolutely.
[15:33] <ScottK> Pretty much the only requirement for Multiverse is that it be legal for Canonical and it's mirrors to distribute.
[15:33] <hyperair> ah i see
[15:34] <ScottK> We have at least one package that even says something like "and if there's a conflict between what's in the license and what's needed for normal Ubuntu distribution, then the distribution's needs are OK".
[15:35] <Amaranth> Hey we can add skype support to telepathy
[15:38] <hyperair> that would be interesting
[15:38] <hyperair> but i'd really really prefer to see metacontact support on empathy first >_>
[15:39] <ripps> c_korn: foobar (= ${binary:Version})
[15:39] <hyperair> for some of my contacts, i've got 3-4 duplicates
[15:39] <geser> jdong: could you please ACK the SRU for bug #472824
[15:39] <hyperair> it's the main reason i'm sticking by pidgin for the time being
[15:40] <c_korn> ripps: this gives me an error that the dependency is too strict. (the -dev package is arch-indep)
[15:41] <geser> c_korn: no .a file in the -dev package?
[15:42] <c_korn> geser: no, no static libs. just headers and .so symlinks.
[15:45] <ripps> c_korn: pastebin the error that lintian is giving you
[15:45] <geser> c_korn: then try >= , like libpurple-dev does it too
[15:52] <c_korn> this is the error with = ${binary:Version}
[15:52] <ScottK> jdong: 330766 needs a TEST CASE:
[15:53] <c_korn> with >= ${source:Version} I get this error: http://pastebin.com/d5dd6ec96
[15:55] <c_korn> and a similar one with >=${binary:Version} http://pastebin.com/d52b323a1
[15:55] <c_korn> oh, I have forgotten the link in the = ${binary:Version} case. this is it: http://pastebin.com/d2a3e26aa
[15:57] <c_korn> and just for completeness the = ${source:Version} dependency: http://pastebin.com/d5a73530c
[16:05] <geser> c_korn: seems you get a warning either way, so pick one you "like" and overwrite it
[16:06] <geser> I guess lintian doesn't know yet about arch:all -dev packages
[16:07] <geser> if you want to get the package into Debian, I suggest using >= ${source:Version} as it's binNMU-safe
[16:07] <c_korn> geser: ok, thanks.
[16:22] <jdong> geser: acked
[16:43] <ScottK> chrisccoulson: runit needs to be fixed in Lucid before I accept the SRU (439049)
[16:51] <chrisccoulson> ScottK - no problem. I can do an upload to Lucid too
[17:01] <chrisccoulson> ScottK - it's fixed in Lucid now
[17:06] <ScottK> chrisccoulson: Accepted for karmic-proposed too.
[17:06] <chrisccoulson> ScottK - thank you
[17:06] <ScottK> No problem.  My part of the job is easy
[17:13] <ScottK> chrisccoulson: Would you please look at bug 400839.  I've been working with the uploader, but would like to see him get sponsored by more than just me.  I'd like to get it into Lucid quickly so we can do an SRU.
[17:13] <ScottK> jdong: It'd be nice to get a motu-sru ack for ^^^ too (patch will be the same modulo revision number).
[17:20] <JonyBlaze> anyone familiar with googlecodes URL syntax as far as making a watchfile
[17:55] <jdong> ScottK: ok, done :)
[18:02] <JonyBlaze> err nm
[18:02] <JonyBlaze> in uscan man page it says you can specify what the current version is on the 2nd line but doesnt show how, anyone know?
[18:03] <ScottK> JonyBlaze: I don't.  I'd suggest finding an existing package in the archive hosted there and copy.
[18:05] <Guest34157> I need som help
[18:05] <ScottK> jdong: Looking at it but getting distracted by filing bugs against our tools
[18:05] <JonyBlaze> ScottK: my issue is that upstream doesnt use very good versions in the filenames
[18:06] <JonyBlaze> ScottK: so I changed it for packaging, uscan would check theirs against mine and it wouldnt come up with the right answer
[18:06] <Guest34157> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:07] <Guest34157> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:09] <Guest34157> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:09] <joaopinto> Guest34157, first you should get  a proper nick :)
[18:17] <Laney> and stop repeating
[18:18] <hyperair> Laney: too late
[18:19] <Laney> what is
[18:21] <christian_> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:22] <hyperair> Laney: "and stop repeating"
[18:23] <christian_> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:26] <christian_> How should my rules file look like if the program is using a bash script to install and not a file named setup.py?
[18:26] <Laney> hahaha
[18:26] <Laney> hyperair: If you mean that he parted, I have that ignored
[18:26] <Laney> christian_: stop repeating please
[18:27] <hyperair> Laney: ah.
[18:28] <ScottK> christian_: My advice is read http://www.catb.org/~esr/faqs/smart-questions.html and then ask again after considering it.
[18:30]  * mok0 doesn't understand why that setup.py vs bash thing should be a problem
[18:31] <Laney> "All access to Launchpad must be authenticated as an application acting on behalf of a user. It's possible for the user to grant the application only readonly access, but it's not possible to access the APIs anonymously"
[18:32] <ScottK> Sounds like more user friendly design.
[18:33] <Laney> I'll just turn that into a warning
[18:34] <christian_> I followed this guide, https://wiki.ubuntu.com/PackagingGuide/Python, and it doesn´t explain how to proceed if the package doesn´t have a setup.py file. Please help me.
[18:36] <mok0> christian_: are you packaging a python program or module?
[18:37] <christian_> a python program, djl http://en.djl-linux.org/
[18:38] <ScottK> jdong and dtchen: Uploaded.
[18:39] <mok0> christian_: you don't need setup.py. From within rules, do whatever you need to in order to do the build
[18:40] <christian_> could you explain some more? This is my first package.
[18:40] <jdong> ScottK: Thanks!
[18:41] <mok0> christian_: can you write your own setup.py file?
[18:41] <mok0> christian_: if so, it will make things much easier
[18:42] <christian_> ok, should I just put the setup.py in the directory then?
[18:43] <mok0> christian_: yes, that will be ok for starters
[18:43] <christian_> mok0: Thanks!
[18:43] <mok0> christian_: then you can use the CDBS system and the rules file will be just a few lines
[18:45] <sebner> mok0: arghrshsarhgsharhgahgahs.. DH7!!!
[18:45] <mok0> sebner: bah
[18:45] <mok0> :)
[18:45] <mok0> I much prefer makefile macros
[18:45] <sebner> we have dh7 and quilt now. NO need for something else!
[18:46] <mok0> sebner, we have GNU make. No need for anything else
[18:46] <mok0> :)
[18:47] <sebner> mok0: I forgot to add "which is the best in the world so why using something worse .." ;)
[18:47] <mok0> sebner: But if you like, you can take over mentoring christian_ in dh7 *shudder*
[18:47] <ScottK> sebner: quilt is good for complex packages, but has a bit of learning curve.  It's the git of patching systems.
[18:48] <sebner> ScottK: I've found it always easier than e.g dpatch
[18:48] <sebner> mok0: I'd recommend DktrKranz who is *the* python with dh7 expert ;)
[18:48] <mok0> I use quilt
[18:48] <sebner> \o/
[18:49] <mok0> I use cdbs
[18:49] <ScottK> sebner: It doesn't get much easier than dpatch-edit-patch.
[18:49] <ScottK> Or cdbs-edit-patch
[18:50] <sebner> ScottK: right but my experience is that it's the easiest and most powerful among all patch systems
[18:50] <mok0> ScottK: cdbs-edit-patch is quite useful as an introduction anyways, since it's harder to screw up than quilt
[18:50] <ScottK> Well any system that requires people to set environment variables as the first step fails the easy test.
[18:51] <ScottK> mok0: Agreed.
[18:51] <ScottK> I've used quilt enough now that I'm comfortable with it, but it took some time.
[18:52] <mok0> I've forgotten a few time to "add" a file to quilt, and then it's a real pain to get the patch created
[18:54] <JonyBlaze> why cant debian/watch just use normal wildcards /sigh
[18:54]  * DktrKranz is a n00b, sebner probably confused him with someone else
[18:56] <mok0> JonyBlaze: The perl weirdness is upon us
[19:01] <JonyBlaze> :(
[19:17] <goshawk> hi, is there a way to retrieve a package with dget from the debian ftpmaster new section? http://ftp-master.debian.org/new.html ?
[19:20] <ScottK> goshawk: No.  They are not publically available
[19:21] <goshawk> oh
[19:36] <christian_> I get this when I am trying to build: dpkg-gencontrol: warning: can't parse dependency python-qt4  python-central (>= 0.6.11) dpkg-gencontrol: error: error occurred while parsing Depends field: python-qt4  python-central (>= 0.6.11) dh_gencontrol: dpkg-gencontrol returned exit code 255
[19:37] <jmarsden> christian_: python-qt4  python-central (>= 0.6.11)   needs a comma in there to separate the two clauses: make it Depends: python-qt4, python-central (>= 0.6.11)
[19:38] <jmarsden> In general "can't parse" means you made a syntax mistake of some sort.
[19:39] <christian_> Thanks! Let´s see how things work this time.
[19:41] <jmarsden> No problem.
[19:41] <christian_> Worked :-) Should I write something in the changelog about the setup.py file I added?
[19:47] <mok0> christian_: absolutely
[20:02] <ScottK> jdong: Unless you tell me otherwise pretty quickly, I'm going to assume your ack on gurlchecker means i can accept it.
[20:04] <jdong> ScottK: yes sir
[20:04] <ScottK> Excellent.
[20:04] <ScottK> Battery is at 5%, so it may not be until after I find power.
[20:06] <ajmitch> morning
[20:08] <ScottK> Just made it.
[20:26] <christian_> Package is here: http://revu.ubuntuwire.com/p/djl Please comment.
[21:25] <rlameiro> Good evening/morning/afternoon everyone
[21:25] <rlameiro> Well I want to start to make packages, what do I need to know before starting?
[21:26] <rlameiro> Do i need to understand makefiles etc?
[22:14] <bmm> I want to create a package for a very simple tool which does not have any Makefile and is just a single Python script. ( http://git.logfish.net/?p=shareftp.git;a=commit;h=9bff07bf7b18d19d8d16db0d67d2b31b575c379b ). Should I path a Makefile for the package or is there a nicer way?
[22:25] <lifeless> bmm: you're going to need a copyright statement at minimum
[22:25] <lifeless> we don't care about a makefile or not
[22:26] <bmm> lifeless: I just found out I can remove the /usr/share/cdbs/1/class/makefile.mk include (I'm using CDBS) and then add the files I need into shareftp.install and shareftp.manpages
[22:26] <bmm> I'm currently going to look up where to install the binary (/bin or /usr/bin) because I'm not sure what the policy is on that yet.
[22:26] <bmm> :)
[22:27] <bmm> lifeless: Thank you for you response!
[22:28] <bmm> OK, that's /usr/bin. Should be ok from here. Thank you for your response.
[22:39] <rlameiro> https://wiki.ubuntu.com/PackagingGuide/HandsOn
[22:39] <rlameiro> i am following this tutorial
[22:39] <rlameiro> but i am stuck in the dh_make
[22:39] <rlameiro> it gives an error
[22:40] <rlameiro> lameiro@studio:~/hello/hello-2.4$ dh_make -e<EMAIL_ADDRESS>[22:40] <rlameiro> Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch or cdbs?
[22:40] <rlameiro>  [s/i/m/l/k/n/b] s
[22:40] <rlameiro> Maintainer name : Ricardo da Rocha Lameiro
[22:40] <rlameiro> Email-Address<EMAIL_ADDRESS>[22:40] <rlameiro> Date            : Sat, 07 Nov 2009 22:38:26 +0000
[22:40] <rlameiro> Package Name    : hello
[22:40] <rlameiro> Version         : 2.4
[22:40] <rlameiro> License         : blank
[22:40] <rlameiro> Using dpatch    : no
[22:40] <rlameiro> Using quilt     : no
[22:40] <rlameiro> Type of Package : Single
[22:40] <rlameiro> Hit <enter> to confirm:
[22:40] <rlameiro> Could not find hello-2.4.orig.tar.gz
[22:40] <rlameiro> Either specify an alternate file to use with -f,
[22:40] <rlameiro> or add --createorig to create one.
[22:40] <rlameiro> lameiro@studio:~/hello/hello-2.4$
[22:40] <rlameiro> that tar doesnt exists
[22:40] <rlameiro> what exist is the underscore one
[22:40] <rlameiro> hello_2.4.orig.tar.gz
[22:41] <ScottK> !pastebin | rlameiro
[22:41] <mok0> !pastebin | rlameiro
[22:41] <rlameiro> sorry
[22:41] <mok0> Ha, ScottK you beat me to it
[22:42] <rlameiro> http://paste.ubuntu.com/312812/
[22:42] <rlameiro> better now?
[22:43] <mok0> rlameiro: You need to specify the tarball
[22:43] <rlameiro>  -r ?
[22:43] <rlameiro> at the tutorial they dont say that :/
[22:43] <mok0> rlameiro: you need at tarball called "hello-2.4.orig.tar.gz"
[22:44] <rlameiro> but shouldnt it be with _
[22:44] <rlameiro> ?
[22:44] <mok0> rlameiro: which must be in ../ relative to where you execute the commnad
[22:44] <mok0> yes
[22:45] <mok0> rlameiro: actually, it doesn't matter what it's called, as long as you specify it with the -f argument
[22:45] <rlameiro> ah
[22:45] <rlameiro> ok
[23:40] <bmm> Is it possible to have "quilt" generate a new file (not in the original source tree)?
[23:45] <dtchen> sure, via quilt new ... quilt add ... edit ... quilt refresh
[23:46] <Laney> or quilt shell!
[23:46] <dtchen> yep, several approaches
[23:48] <bmm> dtchen: that won't work for new files. If I create the file, then quilt new, quilt add file.txt, quilt refresh it will not see any changes as the file was added after it was created without any changes.
[23:49] <dtchen> err
[23:49] <jmarsden> bmm: Don't "create the file" first, create the file using quilt edit
[23:50] <dtchen> right
[23:50] <dtchen> I haven't ever created the file first :-)
[23:51] <bmm> jmarsden: but the files are created with a download script :( I'm trying to do a quick package of cgit and cgit requires me to download the full source of a git release in the source tree.
[23:52] <bmm> (I know, ugly, but still). So my plan now: make a list of all the files that I need, remove them, quilt add them before they exist, copy them back. Just making sure, that is the best way to do this with quilt?
[23:52] <Laney> use quilt shell
[23:53] <bmm> Laney: ah, that may help :D
[23:53] <bmm> Laney: of to try that...
[23:55] <bmm> Ah, works like a charm! Great, thanks!
[23:56] <Laney> good chap!
[23:57]  * bmm chuckles at the sight of a 9.8M patch


[08:00] <noodles775> Hi stub, is your branch (bug 461800) already through ec2 test etc., and ready to land? (or is there other manual testing that you had to do?)
[08:00] <mup> Bug #461800: new-slave.py no longer works <current-rollout-blocker> <Launchpad Foundations:In Progress by stub> <https://launchpad.net/bugs/461800>
[08:01] <stub> noodles775: That script is only tested on staging - everything in database/replication is outside of our test suite.
[08:02] <noodles775> stub: great, so land away then :)
[08:02] <stub> noodles775: ok. It was a branch of db-devel - is that going to be a problem with the current buildbot situation?
[08:02] <noodles775> stub: strange? the MP says that it's for merging into devel...
[08:03]  * stub double checks
[08:03] <stub> noodles775: Yes, you are right. It can land on launchpad/devel.
[08:03] <noodles775> stub: would it be quicker to get it qa'd if you land directly into db-devel?
[08:04] <noodles775> I'm about to try sending off a manual ec2 test run of db-devel...
[08:04] <stub> noodles775: Not really
[08:04] <noodles775> OK, then devel it is. Thanks!
[08:53] <al-maisan> hello gmb, when you start your day: I have a branch fixing an r-c bug for review: https://code.edge.launchpad.net/~al-maisan/launchpad/subsets/+merge/14343
[09:38] <gmb> al-maisan: Thanks. I'll get started on it shortly.
[09:39] <al-maisan> gmb: thanks
[10:14] <gmb> al-maisan: Looks good. r=me. Go ahead and request an rc review for it.
[10:14] <al-maisan> gmb: thank you very much.
[10:15] <al-maisan> noodles775: ^^
[10:15] <noodles775> Thanks al-maisan
[12:44] <al-maisan> gmb: here's another likely r-c candidate: https://code.edge.launchpad.net/~al-maisan/launchpad/getbyname-472608/+merge/14354
[12:44] <al-maisan> please take a look when you get back.
[13:06] <gmb> al-maisan: Okay, looking now.
[13:07] <al-maisan> gmb: thanks!
[13:08] <gmb> al-maisan: Looks good, r=me.
[13:08] <al-maisan> gmb: thank you very much!
[13:09] <gmb> al-maisan: You know it's a good review day when you get small Soyuz branches ;)
[13:09] <al-maisan> gmb: :)
[13:12] <bac> gmb: quiet day?  i'll be joining you here after i grab a quick bite to eat.
[13:12] <gmb> bac: Very quiet. I've reviewed entirely 2 RC requests, so everything must be working perfectly and we need fix nothing ever again.
[13:13] <bac> gmb: your assessment is spot on IMO.  perhaps i'll take a longer breakfast in light of our accomplishments.
[13:14] <gmb> A wise move.
[13:14] <noodles775> hey bac! There's 3 'In progress' registry crb bugs listed at https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.searchtext=&orderby=-importance&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.has_patch.used=&field.has_cve.used=&field.tag=current-rollout-blocker&field.tags_combinator=ANY&search=Search
[13:14] <noodles775> woops, sorry.
[13:15] <noodles775> But just wondering whether you know if they are really still in progress, or what their status is?
[13:16]  * bac looks
[13:17] <bac> noodles775: i know the two distroseries timeouts are being investigated.  i'm not sure about the other.
[13:18] <bac> noodles775: based on the last comment of bug 437184 i'd guess that edwin is working on it
[13:18] <mup> Bug #437184: New "See full publishing history" location is less useful <current-rollout-blocker> <post-3-ui-cleanup> <trivial> <Launchpad Registry:In Progress by edwin-grubbs> <https://launchpad.net/bugs/437184>
[13:19] <noodles775> bac: thanks - it's just getting quite late if they need QA on staging.
[13:21] <bac> noodles775: yes, i agree
[14:25] <leonardr> gmb, can you put https://code.edge.launchpad.net/~leonardr/launchpadlib/choose-your-client/+merge/14361 in the queue?
[14:27] <gmb> leonardr: Sure
[14:28] <gmb> leonardr: RC candidate?
[14:28] <leonardr> gmb: no
[14:39] <gmb> bac: Could you take a look at https://code.edge.launchpad.net/~gmb/launchpad/affects-me-spinner-bug-458766/+merge/14360 for me? It's not RC.
[14:41] <gmb> bac: I've just noticed that I've introduced some lint in the last hunk of the diff. Please ignore that; I'm fixing it now.
[14:41] <bac> ok
[14:42] <gmb> leonardr: Your branch looks good. r=me.
[14:42] <leonardr> gmb, that was quick, ok
[14:43] <gmb> leonardr: No, I'm just single-minded. I can review it again if you'd like ;)
[14:43] <leonardr> haha
[14:44] <gmb> I've also had two years of reviewing cprov's Soyuz patches. That makes you faster at reading code...
[14:44] <gmb> argh
[14:45] <al-maisan> :)
[15:02] <gmb> Ursinha: Do you have an m-p for your branch?
[15:03] <Ursinha> gmb, yes sir
[15:03] <Ursinha> gmb, https://code.edge.launchpad.net/~ursinha/launchpad/bug-391569-add-last-changed-column/+merge/14366
[15:03] <gmb> Ursinha: Thanks.
[15:03] <gmb> Ursinha: Is this RC?
[15:13] <bac> gmb: r=bac.  sorry it took so long, i got pulled into a long stand-up call
[15:13] <gmb> bac: No worries, it's not RC.
[15:13] <gmb> Thanks.
[15:14] <bac> gmb: it even works with webkit
[15:14] <gmb> bac: Glad you said so... I was wondering if it might just be for me that it worked. Webkit compatibility seems more'n a bit flaky in places.
[15:15] <bac> gmb: yeah, that's why i try testing stuff where possible
[15:25] <gmb> Ursinha: r=me with some stylistic changes (see my comments, they're pretty minimal).
[15:25] <gmb> Nice job.
[15:41] <gmb> bac: I'm going to go an try and get some hacking done. Give me a shout if the sky starts falling.
[15:42] <bac> gmb: ok.  have a call at the top of the hour that may last an hour or so.  can you keep on eye out here during that time?
[15:42] <gmb> Sure.
[15:42] <bac> gmb: thanks
[15:54] <adeuring> bac: could you please review this mp: https://code.edge.launchpad.net/~adeuring/launchpad/bug-435556/+merge/14368 ? (140 lines diff)
[15:56] <bac> adeuring: is this for an RC?
[15:56] <adeuring> bac: no
[15:57] <bac> adeuring: i have a call starting in 4 minutes.  i can review it or in an hour or you can ask gmb
[15:58] <adeuring> bac: sure, no problem. (i think gmb doesn't want to do more reviews today)
[16:01] <bac> adeuring: ok i'll get to it when i can
[16:02] <adeuring> bac: sure, no hurry. (the branch will sit anyway around until PQM opens again)
[16:09] <gmb> bac, abel: I'll take it - I was OTP.
[16:09] <gmb> adeuring: ^^
[16:09]  * gmb curses nickname changes across servers
[16:10] <adeuring> gmb: thanks!
[16:33] <Ursinha> gmb, thanks for your review and the tips
[16:33] <gmb> adeuring: Can you re-push your branch? There's no diff showing up and I can't branch from it; I get a "not a branch" error.
[16:35] <gmb> Ursinha: You're welcome.
[16:36] <adeuring> gmb: done. new branch, new MP
[16:36] <gmb> adeuring: Thanks.
[16:37]  * gmb goes to get a drink while the branch updates
[16:44] <gmb> adeuring: Weird; that branch still shows as "Not pushed to yet" Could you push it to another location on LP for me? I wonder if something in codehosting has gone *boing*
[16:44] <adeuring> gmb: what do you mean with "other location"?
[16:45] <gmb> adeuring: Try `bzr push lp:~adeuring/launchpad/foo` rather than just `bzr push`.
[16:45] <adeuring> gmb: ah, ok
[16:46] <adeuring> gmb:  lp:~adeuring/launchpad/review-435556
[16:47]  * gmb looks
[16:49] <gmb> adeuring: Yep, I think something on codehosting is broken; both branches are showing as not having been pushed to.
[16:49] <adeuring> gmb: right, but you can branch from them.
[16:49] <gmb> adeuring: Interesting; I can't.
[16:50] <adeuring> odd...
[16:50] <gmb> Ah, well, I can't *merge* from them. Hang on...
[16:51] <adeuring> gmb: here's the diff: http://paste.ubuntu.com/308634/
[16:52] <gmb> adeuring: Thanks.
[16:58] <gmb> adeuring: Your changes look good. r=me.
[16:58] <adeuring> gmb: thanks1
[16:58] <adeuring> erm, thanks!
[17:38] <adeuring> gmb: could you please formally give your review here: https://code.edge.launchpad.net/~adeuring/launchpad/bug-435556/+merge/14370 ?
[18:09] <gmb> adeuring: Done
[18:09] <adeuring> gmb: thanks!
[18:23] <EdwinGrubbs> bac: can you review https://code.edge.launchpad.net/~edwin-grubbs/launchpad/disable-summaries-for-distroseries/+merge/14374
[18:24] <sinzui> EdwinGrubbs: thanks for getting this done so quickly
[18:51] <EdwinGrubbs> sinzui: bac doesn't seem to be around, can you review ^^^
[18:51] <sinzui> I will
[18:53] <sinzui> Edwin: I am not excited by the "Not displayed on distroseries page for performance reasons."
[18:53] <sinzui> Also, this is both distroseries +index and +milestone
[18:54] <sinzui> The change also removes the milestone summary
[18:55] <sinzui> EdwinGrubbs: You could replace the technical message with
[18:55] <sinzui>     <tal:summary          content="structure milestone/summary/fmt:shorten/80" />
[18:55] <sinzui> so that users can see something about the milestone
[18:56] <EdwinGrubbs> sinzui: are you saying that you don't want this change to affect both the distroseries +index and +milestone?
[18:58] <EdwinGrubbs> sinzui: oh, I see, you are saying that the comment about the "distroseries page" is inaccurate.
[18:58] <sinzui> correct.
[18:58] <sinzui> Your fix should fix both page :)
[19:06] <EdwinGrubbs> sinzui: new diff posted: https://code.edge.launchpad.net/~edwin-grubbs/launchpad/disable-summaries-for-distroseries/+merge/14374
[19:08] <sinzui> EdwinGrubbs: Looks good to land.
[19:10] <EdwinGrubbs> sinzui: thanks
[19:10] <EdwinGrubbs> noodles775, flacoste: can I get an RC for https://code.edge.launchpad.net/~edwin-grubbs/launchpad/disable-summaries-for-distroseries/+merge/14374
[19:11] <al-maisan> hello bac, I have a branch that fixes an r-c bug: https://code.edge.launchpad.net/~al-maisan/launchpad/uploadurl-472929/+merge/14382
[19:11] <al-maisan> Could you please take a look?
[19:11] <bac> al-maisan: on it
[19:11] <al-maisan> bac: thanking you.
[19:12] <flacoste> EdwinGrubbs: done
[19:12] <EdwinGrubbs> thanks
[19:17] <bac> al-maisan: at line 16 of your diff, is self.context.distribution a dictionary?
[19:18] <al-maisan> bac: self.context is an IArchive instance
[19:18] <al-maisan> and distribution is one of its properties
[19:18] <bac> al-maisan: right but your indexing into it with ...distribution[series] so i wonder if that is a dict
[19:19] <bac> argh!  s/your/you're
[19:19] <al-maisan> bac, that's right, Archive implements a __get_item__() method
[19:20] <bac> al-maisan: so can you use .get(series) and avoid the try/NotFoundError ?
[19:20] <al-maisan> bac, wait, it's Distribution that has that method.
[19:20] <al-maisan> bac, let me look.
[19:20] <bac> al-maisan: yes, see if you can collapse lines 15-18 to
[19:21] <bac> series = self.context.distribution.get(series)
[19:21] <al-maisan> bac, ah, I see what you mean. Just treat it like a dict.
[19:22] <bac> yes
[19:23] <al-maisan> hmm ..
[19:23] <al-maisan>       File "/home/mhr/canonical/lp-branches/uploadurl-472929/lib/lp/soyuz/browser/archive.py", line 294, in _traverse_permission
[19:23] <al-maisan>         series = self.context.distribution.get(series)
[19:23] <al-maisan>     ForbiddenAttribute: ('get', <Distribution at 0xbbef1d0>)
[19:23] <al-maisan> bac ^^
[19:24] <al-maisan> I was trying http://pastebin.ubuntu.com/308740/
[19:24] <bac> al-maisan: ok then!
[19:24] <al-maisan> sorry
[19:26] <bac> al-maisan: i'm confused by the multiple checks at 13 and 19.  can 20-21 be moved under the check at 13?
[19:26]  * al-maisan looks
[19:27] <bac> perhaps not
[19:29] <al-maisan> bac: so, on lines 15-18 I am making sure that the series passed in by the user (via an URL param) is actually there.
[19:29] <al-maisan> if I can't find it, it is the same as if it was missing i.e. the result is a 404
[19:30] <al-maisan> otherwise I look up the package set, and, if I find that I attempt to find at least one archive permission
[19:32] <al-maisan> bac: please note also that I tested the branch on the Soyuz dogfood system.
[19:32] <bac> al-maisan: was there a reason for s/grouchy-thunderbird/thunderbird/ ?
[19:32] <al-maisan> bac: yes, I wanted 2 package sets with the same name
[19:33] <bac> ah, ok
[19:33] <al-maisan> in order to test that they are disambiguated on a distro series basis
[19:33] <bac> gotcha
[19:35] <bac> al-maisan: r=bac.  thanks!
[19:35] <al-maisan> bac: thanks a million
[19:35] <al-maisan> !!
[19:51] <bac> al-maisan: you going to try for an r-c from flacoste?
[19:51] <al-maisan> bac: I did ping him on lp-code
[19:52] <al-maisan> flacoste: the branch in question is: https://code.edge.launchpad.net/~al-maisan/launchpad/uploadurl-472929
[19:52] <al-maisan> could I please have an r-c for it?
[20:00] <al-maisan> flacoste: sorry for nagging but the midnight UTC deadline is drawing closer.
[20:12] <flacoste> al-maisan: has this been QA-ed on dogfood yet?
[20:12] <al-maisan> flacoste: yes indeed.
[20:12] <flacoste> al-maisan: ok, rc=me, did you update LPS with your UPDATE query yet?
[20:13] <al-maisan> flacoste: I am working on it as we speak.
[20:13] <al-maisan> flacoste: thanks for the rc.
[21:10] <mwhudson> abentley: want to review this branchmergeproposaljob join fix?
[21:10] <mwhudson> it's about 15 lines
[21:10] <abentley> mwhudson: Okay.
[21:18] <mwhudson> abentley: you should have an email by now
[21:20] <abentley> mwhudson: r=me
[21:21] <mwhudson> abentley: thanks


[08:20] <Nafallo> hi! I'm trying to push a branch of a new git repository, but keep getting "fatal: remote error: Project 'tpm2-pk11' does not exist."
[08:20] <Nafallo> which it doesn't, but I would assume it would get created :-)
[08:29] <cjwatson> Nafallo: No.  Repositories within a project are auto-created if you push to them, but auto-creating projects would be a bit much.
[08:30] <Nafallo> yeah, I'm not trying to make a project. I'm trying to push it to a team :-)
[08:30] <cjwatson> Then you want /~<team>/+git/tpm2-pk11
[08:30] <Nafallo> git remote add origin lp:~vcc-caeit/tpm2-pk11 ; git push origin vcclc/bionic
[08:30] <cjwatson> But that won't support merge proposals etc.
[08:30] <Nafallo> ah. I don't have the +git :-)
[08:31] <cjwatson> Are you sure you want to "push it to a team"?
[08:31] <cjwatson> That is not usual
[08:31] <cjwatson> It's the equivalent of +junk in bzr
[08:31] <Nafallo> https://code.launchpad.net/~vcc-caeit/+git <-- like the rest of them :-)
[08:31] <cjwatson> But those *are* in projects
[08:32] <Nafallo> oh. I think I see now...
[08:32] <cjwatson> Is your branch based on something else?
[08:32] <Nafallo> I'm piggybacking on the already existing projects for these packages, but it doesn't exist for the one I'm currently trying to push :-)
[08:32] <Nafallo> debian salsa :-P
[08:33] <Nafallo> that would explain it. cheers Colin :-)
[08:33] <Nafallo> now I need to figure out if I want to create that project or not :-P
[08:37] <cjwatson> Right.  Creating a project to reflect the existence elsewhere and then pushing to lp:~vcc-caeit/tpm2-pk11 would be usual in that case, not pushing to the personal namespace (lp:~vcc-caeit/+git/tpm2-pk11)
[08:37] <Nafallo> that makes sense now that I realised how it works.
[14:58] <Laney> Is https://oops.canonical.com/?oopsid=OOPS-a2f16d945d0eb9276cea6341b1ec8e7a reported or should I do it?
[14:59] <Laney> I did have a quick search but couldn't find a report
[15:06] <cjwatson> Laney: It's essentially the same underlying cause as https://bugs.launchpad.net/launchpad/+bug/1314569
[15:06] <cjwatson> (that's for copies rather than code review comments, and the exact state transitions are slightly different, but it's the same idea)
[15:06] <Laney> cjwatson: OK, thanks, that one I did turn up actually
[15:07] <Laney> heh @ critical