| slangasek | cjwatson: you haven't been bzr push --overwrite'ing lp:~ubuntu-archive/ubuntu-archive-tools/trunk/, have you? bzr pull tells me I have extra revisions locally which I swear I've pushed twice before | 00:43 |
|---|---|---|
| stgraber | slangasek: I usually keep that one mostly up to date on my laptop and I'm not seeing an error when updating it here, what commits are you looking for? | 00:44 |
| slangasek | stgraber: commits from 16 Jun | 00:45 |
| stgraber | slangasek: are you sure you pushed them? I'm not seeing them and I last commited to it in late June and never needed --overwrite since (that I can remember at least) | 00:46 |
| slangasek | no, I'm not sure, but I remember doing so :) | 00:46 |
| * xnox 's last update from Mar 12th, and bzr pull doesn't complain here =) | 00:47 | |
| slangasek | ok, the problem was that 'bzr push' pushed to the wrong place, huzzah | 00:48 |
| xnox | --remember for the win! =) | 00:48 |
| slangasek | cjwatson: nevermind, pilot error on my side :) | 00:49 |
| stgraber | ah yeah, I often get that when I want a change to be reviewed (so pushing to another branch), then forget to reset the push target | 00:49 |
| slangasek | yep | 00:49 |
| stgraber | though I use bzr push :parent more and more so I'm sure of where I'm pushing ;) (or confirm with bzr info) | 00:49 |
| slangasek | if bzr lp-propose-merge behavior was more sensible, I would probably be less likely to trip over this | 00:50 |
| stgraber | +1 | 00:50 |
| xnox | i never got submit / lp-propose-merge to work properly, seems to always propose against the wrong thing or tell me there "no changes to submit" | 00:51 |
| xnox | i guess i never understood the concept of submit branch.... | 00:51 |
| slangasek | xnox: oh, if you bzr push --remember mybranch and bzr pull --remember :parent, it works, and then you forget you've done this and push everything else to the wrong branch ;P | 00:52 |
| xnox | don't do that! =)))) *simples* | 00:52 |
| slangasek | then I have to open my *browser* to submit an MP! terrible! | 00:53 |
| slangasek | all this software is conspiring against me | 00:53 |
| xnox | i usually edit inline, if it gets big: cd ../; mv trunk my-feature-branch; bzr branch lp:project trunk | 00:53 |
| StevenK | slangasek: There's a launchpad plugin for bzr that allows you to submit MPs via the command line | 01:02 |
| xnox | =))))) | 01:07 |
| slangasek | StevenK: yes, and its semantics are terrible, see the preceeding discussion ;) | 02:17 |
| rbasak | Daviey: I thought our conclusion was that you were going to accept facter 1.6.5-1ubuntu1.2 into precise-proposed and I'd then verify 1.6.5-1ubuntu1.1 and 1.6.5-1ubuntu1.2 and the other releases all at once? | 07:23 |
| Daviey | rbasak: right, that is what i thought. | 07:27 |
| Daviey | rbasak: is there a hiccup with that? | 07:27 |
| rbasak | Daviey: it's still in the unapproved queue | 07:28 |
| Daviey | rbasak: Gah | 07:51 |
| rbasak | Thank you! | 08:02 |
| === doko_ is now known as doko | ||
| cjwatson | *thunk* | 09:29 |
| cjwatson | ^- sound of the Apache 2.4 transition landing in saucy | 09:29 |
| Laney | \o/ | 09:29 |
| cjwatson | That's 115 fewer packages backed up in -proposed | 09:29 |
| Laney | many removals? | 09:30 |
| cjwatson | auth-mysql, auth-pgsql, musicindex | 09:30 |
| infinity | Both mod_auth_sqls? Really? Special. | 09:31 |
| cjwatson | auth-pgsql has a fix which I managed to wake upstream up to review, so hopefully will return soon | 09:31 |
| cjwatson | auth-mysql I need to work on | 09:31 |
| infinity | cjwatson: Did you come up with some demotion magic, or just doing manual copies and deletes for now? | 09:31 |
| infinity | (Not like copy and delete is hard) | 09:32 |
| cjwatson | I committed demote-to-proposed now, but be warned, it's fairly rough due to LP bugs | 09:33 |
| cjwatson | One of them (auth-pgsql I think) I was unable to demote properly and had to temporarily remove | 09:33 |
| cjwatson | Need to sit down and fix LP ... | 09:33 |
| infinity | Hrm? Quel bugs? | 09:35 |
| infinity | I would have assumed it was just a vaguely atomic copy-with-binaries-and-delete (ie: the exact inverse of what britney does) | 09:35 |
| cjwatson | Sometimes it refuses to copy the binaries due to imaginary conflicts. | 09:36 |
| infinity | Oh. Cute. | 09:36 |
| cjwatson | This is especially amusing when the binaries have been removed, in which case neither include_binaries=False nor =True works. | 09:36 |
| cjwatson | But whichever one it was failed with some other conflict. | 09:36 |
| cjwatson | Didn't really feel like debugging it at the time, I'm afraid :) | 09:37 |
| infinity | I could see it failing because of old pubs in -proposed, but I thought copying an identical pub over itself was meant to not trip that. | 09:37 |
| infinity | The binary removal and include bug is fun, though. | 09:37 |
| cjwatson | <PlainPackageCopyJob to copy package libapache2-mod-auth-pgsql from ubuntu/primary, RELEASE pocket, in ubuntu saucy to ubuntu/primary, PROPOSED pocket, in ubuntu saucy, including binaries> | 09:38 |
| cjwatson | raised CannotCopy: | 09:39 |
| cjwatson | libapache2-mod-auth-pgsql 2.0.3-5build3 in saucy (binaries conflicting with the existing ones) | 09:39 |
| cjwatson | for the record | 09:39 |
| cjwatson | It does work in some cases, but evidently the conflict checker is mad (which I sort of knew) | 09:39 |
| infinity | Fun. I'd probably just cheat by uploading build4 and removing build3, but that's hardly an intuitive workflow. | 09:39 |
| cjwatson | I just removed build3 and I'll sync it back in when it's fixed in Debian. | 09:40 |
| rbasak | \o/ | 09:50 |
| rbasak | Thanks cjwatson! | 09:50 |
| Daviey | cjwatson: Super on the apache transition! Thanks. | 10:22 |
| infinity | ScottK: You have a debootstrap in precise-backports whose version trumps the more correct one in -updates. Do you plan to keep backporting newer versions to cope with that, or should we just remove it and let people who installed it hang? | 10:59 |
| xnox | cjohnston: rbasak: apache2.4 upgrade doesn't go smooth at all. So apache2.4 postinst tries to checkconfig / restart apache, but the sites and modules are not disabled. Since apache is upgraded first, before modules, the resart fails as it can't load up old mpm_prefork / wsgi / php5 / python. Thus one is stuck with broken unconfigured packages and whoopsie/apport popups going crazy =) | 12:01 |
| xnox | cjwatson: ^ | 12:01 |
| xnox | i had to manually disable all my sites, revert default config, comment out all LoadModules from their *.load files. Then configure apache2, finish off upgrade, re-enabled sites/modules. | 12:01 |
| * xnox would have thought such dance would be done automagically by apache upgrade. | 12:02 | |
| cjwatson | I can't look at it today. Hopefully somebody else can | 12:04 |
| cjwatson | It's the server team's problem anyway, surely :) | 12:04 |
| * cjwatson was just helping with the package-level migration | 12:04 | |
| * xnox will probably write to apache2 maintainers | 12:41 | |
| rbasak | xnox: my test upgrade worked ok when it was still in -proposed. I'll see if I can reproduce what you're seeing. | 13:05 |
| xnox | rbasak: just upgrading with default site enabled works fine. it's just i actually had php5, wsgi, python modules installed, enabled and used by my site. (just tiny webapps / single file scripts, nothing fancy) | 13:07 |
| rbasak | xnox: what do we need to do to fix that? All the modules packages to Conflicts: apache2 (<< 2.4)? | 13:09 |
| rbasak | Hmm, that wouldn't help actually. New apache with old modules would still be permitted then. | 13:09 |
| xnox | rbasak: i think that apache2.4 shouldn't restart apache, nor run check-config on upgrade from apache2.2, if modules have not been upgraded yet. but then i'm not sure what will restart apache2 after all modules are upgraded.... we don't quite have post-apt-get-run. maybe a trigger or something like that?! | 13:13 |
| === balloons_ is now known as balloons | ||
| slangasek | cjwatson: apache2 \o/ | 14:33 |
| mdeslaur | apache2 \o/ | 15:00 |
| ScottK | infinity: Sigh. I don't plan newer backports. I guess I should fix it. Thanks for pointing it out. | 15:25 |
| === rtg is now known as rtg-afk | ||
| jamespage | Daviey, re python-neutronclient - that will replace python-quantumclient going forwards and has the appropriate transitional package | 16:32 |
| jamespage | can you do the NEW acceptance and the main inclusion wiggle? | 16:32 |
| Daviey | jamespage: I'd like it to have an ack from mterry or another MIR'er before processing it | 16:32 |
| jamespage | Daviey, ok | 16:32 |
| Daviey | I have happy to NEW it, but not promote it until it's had a nominal agreement from them | 16:33 |
| jamespage | Daviey, can you reject that NEW package please | 16:42 |
| jamespage | just spotted an autopkg test issue I may as well solve now rather than later | 16:42 |
| Daviey | jamespage: You said that, seconds after i accepted it | 16:43 |
| jamespage | arggghhhhhh | 16:43 |
| Daviey | ^^ | 16:43 |
| jamespage | nm | 16:43 |
| jamespage | guess its later then! | 16:43 |
| Daviey | jamespage: I am leaving neutronclient binaries in NEW. By accepting, i'll introduce the transitional package to main. | 17:21 |
| cjwatson | Can't you override it to universe if that's what you want? | 17:23 |
| Daviey | cjwatson: python-quantumclient is a current package. This upload has a transitional package which replaces that | 17:24 |
| Daviey | So it will make the current python-quantumclient non-installable | 17:24 |
| Daviey | As this is essentially a project rename, a quick OK from ~ubuntu-mir was what i was looking for before accepting the binaries | 17:26 |
| Daviey | cjwatson: Have another idea? | 17:26 |
| cjwatson | renames don't normally require MIR approval | 17:32 |
| === rtg-afk is now known as rtg | ||
| infinity | Daviey: It doesn't requre an MIR, but whoever accepted it should have accepted it to main, not universe. :/ | 18:37 |
| jbicha | could an AA look into promoting init-system-helpers? bug 1199422 | 18:41 |
| ubot2` | Launchpad bug 1199422 in init-system-helpers (Ubuntu) "[MIR] init-system-helpers" [Undecided,Fix committed] https://launchpad.net/bugs/1199422 | 18:41 |
| infinity | jbicha: As to your wondering about why it's not on component mismatches, you want the much scarier-looking http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt | 18:42 |
| jbicha | ooh, much nicer | 18:43 |
| infinity | jbicha: And promoted. | 18:44 |
| stgraber | can someone process that one? (grub signed binary in Unapproved)^ | 20:08 |
| stgraber | slangasek: ^ | 20:10 |
| infinity | I can. | 20:12 |
| infinity | stgraber: Don't foget a matched grub-signed upload. | 20:13 |
| infinity | stgraber: With my recent change, that should actually block migration until you do. I hope. | 20:13 |
| stgraber | infinity: we'll see soon enough ;) | 20:14 |
| stgraber | thanks | 20:14 |
| ScottK | Is it safe to have more than one copy of sru-release running at the same time? | 20:19 |
| infinity | ScottK: Define "safe". | 20:19 |
| ScottK | sru-release for KDE SC 4.10.5 packages is up to 15 minutes, and it was only a partial set. | 20:19 |
| infinity | ScottK: If multiple SRUs reference the same bug, you'll hit closure races (bug filed for that, but not fixed), and half your copies might fail. | 20:20 |
| ScottK | I'd like to make sure the set always gets released in the same publisher run and with the increased number of packages in 4.11, I wonder if it will get done if it's done one at a time. | 20:20 |
| infinity | ScottK: And given our speedups in the publisher, she odds of landing that many things in one cycle are slim. | 20:21 |
| infinity | ScottK: You might have to live with the idea that they won't. | 20:21 |
| ScottK | How often is it running now? | 20:21 |
| * infinity is also reminded that he needs to send out a "look, it's faster" email. | 20:21 | |
| infinity | ScottK: Every 5m, at the fastest, realistically, between 10 and 20. | 20:21 |
| ScottK | OK. That was 17, so I guess it won't. | 20:21 |
| infinity | ScottK: Basically, it *tries* to run every 5, but average runs are 10-20, depending on what's publishing. | 20:22 |
| ScottK | Yes, that would be good to know. | 20:22 |
| ScottK | Right. | 20:22 |
| Daviey | infinity: I agree it doesn't require a full MIR, but i simply asked for a quick ack. It seemed reasonable. | 20:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!