[08:48] <cpaelzer> doko: rbalint: FYI I've seen you have rebuilt cyrus-imap but it's test dependency issues hold back perl and many (22) other things. I've found that Debian has our delta https://launchpad.net/ubuntu/+source/cyrus-imapd/3.2.3-2ubuntu1 now accepted in https://tracker.debian.org/news/1181216/accepted-cyrus-imapd-324-3-source-into-unstable/
[08:48] <cpaelzer> doko: rbalint: thereby it can be a sync and tests retriggered once built
[08:49] <cpaelzer> I'll file a bug and trigger the sync unless you say that you are already on it
[11:25] <seb128> hey there, python questions pyferret tests fail because it does
[11:25] <seb128>  ; for py in $(py3versions -r 2>/dev/null) ... ; $py -c "import pyferret"
[11:25] <seb128> and Depends on python3-ferret which Depends on python3 (>= 3.8~)
[11:26] <seb128> which leads to bash: python3.9: command not found
[11:26] <seb128> is the right fix for thoses cases to have the tests control Depends on python3-all?
[11:57] <doko> seb128: yes. can you file a RC issue for Debian too?
[11:57] <seb128> doko, yes, will do, thanks for the reply
[11:58] <doko> User<EMAIL_ADDRESS>[11:58] <doko> Usertags: python3.9
[11:58] <seb128> k
[11:58] <doko> seb128: ^^^
[12:13] <cpaelzer> doko: rbalint: FYI the sync I mentioned earlier unblocked all things that waited on cyrus-imapd
[12:16] <cpaelzer> doko: rbalint: sil2100: given the high number of long-duration-often-manually-retried that https://autopkgtest.ubuntu.com/packages/libr/libreoffice/hirsute/arm64 and https://autopkgtest.ubuntu.com/packages/libr/libreoffice/hirsute/armhf are causing - what do you think of badtesting that on armhf/arm64
[12:16] <cpaelzer> it feels that must have been discussed before ...
[12:16] <cpaelzer> Was there any hope to not expect this to be a retry-monster forever?
[12:17] <Laney> The desktop team should be asked if they can work on making that less flaky
[12:17] <Laney> I don't think ignoring the tests there is a good answer
[12:18] <Laney> Reducing the coverage would be preferable if that gets it to be more stable, for example, assuming the flakiness can't be easily fixed
[12:18] <cpaelzer> sounds good, I'll ask in #ubuntu-desktop if they have (or want) a bug for it
[12:19] <Laney> - or in the meantime while fixing the flakes as a more long term task
[12:45] <cpaelzer> Hi proposed migration tries to confuse me, on recent qemu 5.1 it tells me "old binaries left on amd64: qemu-kvm (from 1:5.0-5ubuntu11)" (and the same for arm64/ppc64el/s390x)
[12:45] <cpaelzer> And that is true and expected, binary "qemu-kvm" existed but is gone intentionally
[12:45] <cpaelzer> As replacement there are breaks/replaces on the qemu-system-* packages, so the rev-deps should be covered.
[12:46] <cpaelzer> I'm puzzled what to do now, I'd have expected this to be not a migration blocker
[12:46] <cpaelzer> And once the new one migrated the old binaries to be removed via https://people.canonical.com/~ubuntu-archive/nbs.html
[12:46] <cpaelzer> Seems to be different now, could someone advice what/if I have to do now to ge this unstuck?
[12:52] <Laney> cpaelzer: it exists in proposed, was there a previous upload that didn't migrate? (yes)
[12:52] <Laney> an archive admin needs to remove that
[12:53]  * Laney does
[12:55] <Laney> nein, doko already did it!
[12:56] <cpaelzer> thanks Laney, just to make sure I get it right (for next time). Usually we'd have the old package in -release and not in -proposed. But since I had one upload in -proposed with qemu-kvm and then another one to -proposed without we now have had the package in -proposed but not as part of the current version that shall migrate. And NBS would instead be for things missing in -release
[12:57] <cpaelzer> sort of makes sense, it seems I just didn't hit this particular sub-case yet (or an AA was always too fast resolving it before it bothered me)
[13:32] <rbalint> @pilot in
[13:36] <rbalint> cpaelzer, yesterday following the recommendation of doko and vorlon i moved to the plusone discussion channel to #ubuntu-release on https://wiki.ubuntu.com/PlusOneMaintenanceTeam
[13:43] <cpaelzer> rbalint: intersting - we started there and were driven away being called too noisy
[13:45] <rbalint> ok, sorry, then this needs a wider discussion
[13:46] <rbalint> but this does not work, yesterday i missed the discussion by hanging out here
[13:47] <rbalint> who complained about the noise?
[13:50] <rbalint> cpaelzer, doko keeps talking on #ubuntu-release
[13:54] <doko> cpaelzer, rbalint: didn't vorlon change that to #u-r?
[13:57] <rbalint> doko, you suggested, vorlon agreed, i changed: https://pastebin.ubuntu.com/p/S5qRB9F8B7/
[14:06] <seb128> cjwatson, hey, I'm pondering adding a apt-proxy-url argument to launchpad-buildd/lpbuildd/livefs.py do you have any opinion on that before I actual start working on code changes?
[14:15] <cjwatson> seb128: Similar to the existing one in lpbuildd/debian.py?  Sounds reasonable to me if you have a good idea of how to jam it into livecd-rootfs and if it similarly defaults to the value in launchpad-buildd's config file
[14:22] <seb128> cjwatson, thanks, I hit the issue when trying local builds with ubuntu-old-fashioned, it uses the existing --http-proxy arg when there an apt config but that does
[14:22] <seb128>             if self.args.http_proxy:
[14:22] <seb128>                 proxy_dict = {
[14:22] <seb128>                     "http_proxy": self.args.http_proxy,
[14:22] <seb128>                     "LB_APT_HTTP_PROXY": self.args.http_proxy
[14:22] <seb128>                     }
[14:23] <seb128> cjwatson, the LB_ makes live-build do the right thing but the http_proxy blew up if you just use a squid-deb-proxy since it tries to use it as a real proxy and that fails
[14:23] <seb128> so I would just set "LB_APT_HTTP_PROXY" in the apt-proxy-url case
[14:27] <cjwatson> seb128: I expect I'll need to look at the diff, but sounds broadly reasonable I think
[14:27] <seb128> cjwatson, thanks
[18:25] <ItzSwirlz> so mouseemu has been removed it seems, is that correct?
[18:28] <tumbleweed> yep
[18:30] <ItzSwirlz> alr, time to see how cinnamon is doing in hirsute
[18:31] <ItzSwirlz> hm, i gotta tell preining to release 4.7.0 in debian
[18:31] <ItzSwirlz> Or i can reqsync 4.6.3.
[18:32] <ItzSwirlz> It's in experimental, I'll choose the latter (4.6.0-3)
[20:20] <rbasak> bdmurray: I replied in bug 1901491. Not sure if you were asking because you hadn't realised it was an SRU regression, or if you were asking why I was tagging post-accept.
[20:29] <bdmurray> rbasak: Thanks, I wasn't sure if some action was required.
[22:02] <rbalint> @pilot out


[10:03] <astraljava> http://paste.ubuntu.com/1404218/
[10:03] <astraljava> Don't like it.
[10:04] <astraljava> Especially the line 15: Depends: gnome-video-effects
[10:05] <ochosi> yeah, actually we've discussed cheese (et al) a few times already
[10:05] <astraljava> But, that's quantal, haven't upgraded to raring, yet.
[10:05] <ochosi> as long as we don't bump the iso-size, there's no need to bring this up again
[10:06] <ochosi> (and even then: it's not like we can/want conditionally install cheese if we detect it's a laptop)
[11:27] <ochosi> adnan: this was kinda in your direction and since you weren't here... http://dpaste.com/840086/
[11:28] <adnan> mhm acknowledged :-)
[19:12] <ScottL> knome: ping
[19:13] <knome> ScottL, hey
[19:14] <ScottL> hi knome. sorry to bother you. zequence and i where wondering about how difficult it would be to add the news to the ubuntu studio landing page, but it looks like he already is working on it
[19:15] <knome> ScottL, right. no problem. if you need help, just ping me again :)
[19:15] <ScottL> hehe, he broke it :P
[19:15] <knome> awwh
[19:15] <knome> should i look at it?
[19:15] <ScottL> he got it back :)
[19:15] <knome> heh, ok
[19:15] <knome> that's *very* live reporting
[19:16] <ScottL> hehe, he's fixing it now :P
[19:16] <ScottL> knome: i almost asked you how your thanksgiving was. i knew americans are ego-centric, but i thought i was slightly better
[19:17] <knome> ScottL, heh :)
[19:17] <knome> ScottL, is life any less busy now?
[19:17] <ScottL> it certainly is getting there, my friend :)
[19:17] <ScottL> i'm very happy to report that
[19:17] <knome> that sounds great
[19:18] <ScottL> i'm rather relieved, actually
[19:18] <knome> i'm sure
[19:18] <knome> being constantly overloaded isn't great for anybody
[19:18] <ScottL> with the integration of two companies (and specifically two engineering groups) there was obviously duplication of effort, but some was stupid because it actually caused more difficulty
[19:18] <knome> or even temporarily, if it goes on too long
[19:19] <knome> i remember you talking about that
[19:19] <knome> have you been able to delegate some of the work loaded for you off then?
[19:19] <ScottL> e.g. scheduling, because now not only did i have to schedule _my_ office, then i had to coordinate with our requirements of a different office
[19:19] <knome> ughh
[19:19] <knome> scheduling a one-man-office with clients is hard enough :D
[19:21] <ScottL> hehe
[19:22] <ScottL> i felt nervous about pushing the responsibility for most of the scheduling onto the other office, but it made certain tactical sense, plus it freed me up to work on those things that are in my review from last year :D
[19:22] <knome> yeah...
[19:23] <knome> even my strategy (with the one-man-company!) is to delegate as much as i can
[19:25] <ScottL> hah!
[19:25] <knome> in other words, make the clients do whatever they can
[19:25] <knome> ...or invoice more
[19:26] <ScottL> but my plan is to selectively delegate some responsibility and start doing the things that i _want_ to do (plus need to) BUT also start pushing my resume out after the first of the year
[19:27] <knome> hmmm
[19:27] <knome> i threw an onion slice on the touchpad and it changed the window
[19:27] <knome> (not intentionally!)
[19:29] <bluesabre> sounds like a bug in gsynaptics
[19:29] <bluesabre> ;)
[19:29]  * bluesabre hides
[19:30] <knome> lol
[21:11] <bluesabre> well, I expect to see the ML light up with excitement about synaptic now... http://www.webupd8.org/2012/12/how-to-install-synaptic-with-gtk3.html
[21:32] <adnan> knome, you should report bug to onion developers, slices shouldn't change the window
[21:32] <adnan> that's not the natural behaviour
[21:33] <knome> xP
[21:34]  * adnan hides


[08:22] <otubo> smoser: I'd appreciate a quick last review on my PR if you have some time :)
[13:47] <smoser> blackboxsw: or Odd_Bloke https://github.com/canonical/cloud-init/pull/721#pullrequestreview-581355914
[13:47] <smoser> otubo: yeah... i just responded.
[13:48] <smoser> always feel free to ping me, don't feel like you're annoying me.
[13:59] <otubo> smoser: will keep that in mind :) thanks!
[14:38] <Vultr-EBenner> Hello, I work with Vultr and we are currently working on adding a Datasource to Cloud-Init for our platform. One issue we have come across is that Cloud-Init by default only brings up the first interface, and any additional require a reboot. We use two different interfaces, one for public, and one for private. We really want both to be up here.
[14:38] <Vultr-EBenner> What we currently have implemented is that we are using the net class to determine the names and then brining them up with subp commands. However this is happening in the datasource and kind of on the fence about it. I wanted to reach out and see how the developers feel about this and how they would like to see us handle this.
[14:54] <Odd_Bloke> Vultr-EBenner: Hi!  cloud-init allows platforms to provide network configuration which will be applied to the instance; this sounds like a perfect use case for it: https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html
[14:56] <Odd_Bloke> Vultr-EBenner: Basically, your datasource should provide network config in either the v1 or v2 format (I linked to the latter, which is preferred) in the .network_config property, and cloud-init will take care of converting that to the configuration format of the running system and applying it.
[15:20] <Vultr-EBenner> That is indeed what we are doing. We are proving the network config, and it is indeed configured, however the second interface is not brought up as the first one is.
[15:23] <rharper> Vultr-EBenner: how is network config provided? is your metadata for the instance network based ?  if so, what cloud-init does is bring up one interface to then collect instance  metadata first, and if the provided metadata includes network config, (for one or more interfaces) this will be written to the OS net config and then the OS network layer will bring up all configured interfaces
[15:25] <Vultr-EBenner> We are depending on filesystem and network, then providing the config via networking with our metadata endpoing. We provide the network config via the vendor config and via the network function in the datasource. The first and second interface are configured, the first one comes up but the second does not unless we explicitly configure it and bring
[15:25] <Vultr-EBenner> it up ourselves it seems.
[15:28] <smoser> Vultr-EBenner: you need to run at local time frame in order to provide network config.
[15:28] <smoser> otherwise it is simply too late to apply it.
[15:30] <smoser> even if you "manually" apply it in "cloud-init init" time frame, other parts of the system have already expected networking to be up.
[15:30] <rharper> Vultr-EBenner: if your network config is included in the metadata end point, then you'll want to make use of the EphemeralDHCP class, see Azure or EC2 Datasources ... this allows your datasource to collect the correct instance network config before OS networking is configured;
[15:30] <smoser> look at digital oceans' datasource, which does something like what you need.
[15:31] <rharper> yeah, that's likely a simpler class to review
[15:32] <smoser> it doesn't have to be ephemeraldhcp... it just has to deterministically identify the platform is vultur, and then bring up networking manually to get the datasource, and then tear it all down.
[15:32] <Vultr-EBenner> I think I may be explaining this poorly. We arent having trouble creating the configs and getting them pushed. Thats all good. The issue is that the second interface isnt being brought up, just configured after everything is said and done. We can connect to the metadata server and configure everything just fine, thats not an issue.
[15:32] <Vultr-EBenner> No errors, in logs, the second interface is just never brought up no matter how we configure it it seems.
[15:33] <Vultr-EBenner> But it is configured. On reboot it comes up as expected.
[15:33] <rharper> smoser: but ephemeral dhcp might be less work if you just need an interfac4e up to talk to the metadata service;  either way is fine.
[15:34] <rharper> Vultr-EBenner: right; so, if you have logs, cloud-init collect-logs would be good;  it sounds like your network-config property might not get populated at local time; in which case, you get a dhcp on one interface config, and then later the config is updated but OS networking has already run
[15:34] <Vultr-EBenner> Again our issue isnt connecting to the metadata or anything in the config generation steps. Its after the config is applied by cloud-init the second interface is left down.
[15:34] <smoser> "how we configure it"
[15:34] <smoser> ?
[15:35] <smoser> you said that you are providing this at network time frame. "We are depending on filesystem and network"
[15:35] <smoser> that means it happens too late.
[15:35] <Vultr-EBenner> Ah, thank you, thats what I was wondering.
[15:35] <Vultr-EBenner> Assuming we will need to bring the link up on our own and do it before the networking step and stop depending on it then.
[15:36] <smoser> if you've correctly implemented check_instance_id, then a reboot will probably fix it. but yeah... you dont want that.
[15:36] <smoser> the fix is to run at local time frame.
[15:36] <Vultr-EBenner> Great thanks. We were thinking that was the issue. We have a solution ready to fix this then. Wasnt sure
[15:48] <Vultr-EBenner> Hmm, apparently I missed the message about running local prior, haha sorry for that. Yeah that does indeed seem to be the issue. Thanks again for the clarification.
[15:57] <rharper> np
[16:25] <kryl> hi there, I'm searching a service who can emulate EC2 like meta-data (for testing cloud-init with vagrant)
[16:40] <smoser> kryl: old. https://gist.github.com/smoser/1278651
[16:45] <kryl> smoser, thank you
[18:48] <jxtps> Hi! I'm trying to create an AWS AMI based on the AWS Deep Learning AMI (Ubuntu 16.04) v38.0. The provided AMI is quite slow to get training going due to a lot of "first run" type setup work that needs to be done (select framework (tensorflow), compile NVIDIA kernels (?), fetch transfer learning weights file, matplotlib needs to initialize some
[18:48] <jxtps> cache, ...).
[18:48] <jxtps> So I have created a warmup script that basically just runs a very limited training run and then I package up an AMI based on that. That works ok-ish - it's faster to get training going on a new instance than it would otherwise be. It's however still quite slow (~8 minutes), and I'm concerned that there are files stored to e.g. temporary directories
[18:48] <jxtps> that don't make it through the AMI-ification process.
[18:48] <jxtps> I'm aware of https://cloudinit.readthedocs.io/en/latest/topics/cli.html#cli-clean but the artifacts I'm concerned about are probably not part of the cloud-init state - is there any other cleaning that happens when packaging up an AMI on AWS?
[18:48] <jxtps> (I spawn an instance off of the based AMI, with a cloud-init script in the user-data that powers down the instance on completion, then an orchestration instance detects that shutdown and issues an ec2 create-image API call)
[18:48] <jxtps> Thanks!
[18:56] <Odd_Bloke> jxtps: My only experience is building the Ubuntu cloud images: those are constructed in a chroot without being booted, precisely to avoid having to clean up artifacts created by a boot.  You might be well-served by looking into image creation tools (e.g. Packer) which are likely to encapsulate best practice for you?
[18:57] <Odd_Bloke> (Other folks in here likely have more relevant experience, too. :)
[20:25] <andrewbogott> I maintain a custom debian base image with a bunch of things pre-installed for faster startup. It is… mostly not worth the trouble.  For real performance I'd probably make a snapshot post-cloud-init and use that.
[20:26] <andrewbogott> (not sure that's 100% applicable to your issue though)


[12:34] <wantom> :findJavaFromJavaHome
[12:34] <wantom> set JAVA_HOME=%JAVA_HOME:"=%
[12:34] <wantom> set JAVA_EXE=%JAVA_HOME%/bin/java.exe
[12:34] <wantom> if exist "%JAVA_EXE%" goto execute
[12:34] <wantom> echo.
[12:34] <wantom> echo ERROR: JAVA_HOME is set to an invalid directory: %JAVA_HOME%
[12:44] <wantom> so xubuntu is debians father???
[14:05] <KBar> hello. is there any reason that Xubuntu did not switching to yaru for 22.04? last time i checked it had all the necessary xfwm4 decorations with the themerc file. are we lacking in the selectors department (i.e. there are still some elements to be included)?
[14:05] <KBar> s/switching/switch
[14:16] <KBar> at first glance, most apps appear and look as expected
[14:34] <krytarik> I guess everybody is free to use whatever theme(s) they like, while I see no particular reason why Xubuntu should suddenly be made to look like Ubuntu proper.
[16:23] <BiggDap7856> Hello And Good Morning All Is This The Rite Place To Report A Bug?
[16:25] <BiggDap7856> I Am Traveling And Was Having Difficulty With Changing The Time Zone In The Panel Clock On The Desk Top
[16:25] <tomreyn> BiggDap7856: hi
[16:26] <BiggDap7856> Hi Tom
[16:26] <tomreyn> this is the right place to get community support with xubuntu
[16:26] <tomreyn> !bug | BiggDap7856
[16:27] <BiggDap7856> All Right Thank You My Man You Have Yourself A Good Day
[16:27] <tomreyn> thanks, you, too!
[20:09] <Eight_> Tried everything listed on this (https://askubuntu.com/questions/485261/change-boot-order-using-efibootmgr) page other than the supposed "ugly workaround" involving renaming in an attempt to change the boot order for my laptop, such that xubuntu or grub takes priority, but windows is still booting first. The only way to get xubuntu to boot is to
[20:09] <Eight_> manually hit the escape key during the early stages of a restart and to then select it. Would it be best to attempt to update the bios, or is there another possible fix that I can do?
[20:21] <tomreyn> Eight_: i'd do the bios update if there was one that's not marked as unstable. you also need to make sure fastboot is disabled on the uefi setup screens. if there's such an option.
[20:51] <Eight_> Not sure how to check whether fastboot is enabled or not assuming it is even an option.
[20:53] <Eight_> completely unrelated as well, but where in settings can you change the format for the time and date? Tried to go along with the 24 hour format, but I rather switch it
[21:00] <xu-irc27w> Hello out there! :)  I'm having problems installing Ubuntu/Xubuntu 22.04 on an older HP laptop. I can get Ubuntu 18.04 installed on it using the CLI minimal CD. But I'm unsure about how to proceed from that minimal command line version of Ubuntu 18.04 which I end up with. Can anyone advise me about how to upgrade this, so I can work with a GUI
[21:00] <xu-irc27w> desktop, instead of command line?
[21:05] <xu-irc27w> Also, ultimately I want to upgrade this installation of Ubuntu 18.04 to the latest 22.04, with the XFCE GUI desktop.


[00:18] <nickrud> !defaultapp
[00:18] <nickrud> there should be something about edit->prefs->media tab there as well, for default media and device apps
[01:54] <Flannel> prince_j1mmys: How can we help you?
[01:55] <prince_j1mmys> Flannel: came here a long time ago to report something, and never left
[01:55] <prince_jammys> should i leave?
[01:57] <Flannel> prince_jammys: We ask people don't idle here, yeah.  So we can keep track of who hasn't been helped, etc.
[01:57] <prince_jammys> ok. adios
[02:18] <Pici> restarting bot... hopefully
[05:06] <Tm_T> elky: ok, problem is, in some way, I am nazi, but perhaps not in a way you assume by the word
[06:06] <Myrtti> HUI KAUHEETA. oh horror.
[06:42] <elky> Tm_T, describe how exactly, since i'm pretty certain there's a far better word to use
[07:44] <Tm_T> elky: hmm, perhaps there is better word, have to try to find one as soon as R-girl is sleeping
[12:58] <bazhang> @login
[13:09] <jussi01> please peoples, do your @login and @btlogin in PM with the bot - no sense creating trafic in here when you dont need too!!
[13:10] <Pici> jussi01: @login doesnt reply if I do it in PM
[13:11] <elky> does for me
[13:11] <elky> just leave off the @
[13:11] <elky> actually, no, even with the @
[13:11] <elky> hrm...
[13:12]  * jussi01 wonders whats wrong as it works for me...
[13:12] <ikonia> just worked for me
[13:12] <ikonia> as a test
[13:12]  * Pici shrugs
[13:12] <elky> pici probably smells :P
[13:12] <ikonia> probably ?
[13:12] <jussi01> Pici: and elky you are not special enough :P
[13:13] <elky> jussi01, no, it works either way for me
[13:13] <elky> and i always do that stuff in PM to avoid giving users the idea to try
[13:13] <Pici> Other commands work, like bansearch
[13:20] <jussi01> Pici: ask stdin, maybe he has an idea
[13:25] <bazhang> works here occasionally; not today though
[15:24] <mneptok> @login
[15:24] <mneptok> does not wortk in /query
[15:24] <mneptok> -t
[15:25] <bazhang> didnt work here first time; closed PM window with the bot and worked 2nd time
[15:27] <mneptok> i have a unified /query window
[15:28] <mneptok> well, while i'm in the bantracker, might as well remove some cruft
[15:31] <Pici> Great. Now mneptok and I are 'special'
[15:33] <ikonia> Pici: you've always been special.....mneptok is new
[15:34] <mneptok> uhhh .... i'm pretty sure the card the police make me carry in my wallet says "thepthul"
[15:34] <mneptok> thpethul, even
[15:34]  * mneptok checks
[15:34] <mneptok> yeah, that's it.
[16:23] <nickrud> is that one with the biohazard warning?
[16:25] <mneptok> nickrud: leave my underpants out of this.
[16:34] <nickrud> mneptok don't try to change the subject; I'm sure your wife knows you well enough to not let you out of the house without checking. What about the card?
[16:42] <mneptok> nickrud: http://upload.wikimedia.org/wikipedia/commons/6/6a/Hazard_N.svg
[17:16] <jussi01> *GRUMBLE*
[17:16] <jussi01> stupid internet company did nt connect me today...
[17:16] <jussi01> no net for the weekend now...
[17:16] <Pici> :(
[17:17] <jussi01> just 3g
[17:17] <jussi01> *SIGH*
[19:38] <Seeker`> hi
[19:40] <nikrud> morning
[20:26] <jpds> evening.
[20:26] <mneptok> gronk.
[20:35] <Flannel> mneptok: What time of day is 'gronk' a greeting for?
[20:40] <Seeker`> mneptok o'clock
[20:41] <mneptok> Flannel: half-past funth
[20:42] <Flannel> Seeker`: I'm afraid of a clock with the Great Old Ones on it
[20:45]  * mneptok spews gods and heros from his reptilian cloaca
[20:49] <nalioth> any gronking time of the gronkin' day, of course
[22:34] <Odd-rationale> Hello! I was just checking on the factiod I submitted earlier on !xfce4-panels. Just wanted to make sure i did everything right... Thanks!
[22:43] <Amaranth> !panels-#xubuntu is <reply> Did you panels disappear? Press alt+f2 and run: xfce4-panels | See also: https://help.ubuntu.com/community/XubuntuPanels | Want to theme your panels? See http://xubuntu.wordpress.com/2007/10/12/howto-set-a-background-image-for-your-panel/
[22:43] <Amaranth> @login
[22:43] <Amaranth> !panels-#xubuntu is <reply> Did you panels disappear? Press alt+f2 and run: xfce4-panels | See also: https://help.ubuntu.com/community/XubuntuPanels | Want to theme your panels? See http://xubuntu.wordpress.com/2007/10/12/howto-set-a-background-image-for-your-panel/
[22:43] <Amaranth> Odd-rationale: there you go :)
[22:43] <Amaranth> Odd-rationale: that'll work as '!panels' in #xubuntu
[22:43] <Odd-rationale> Amaranth: Thanks!
[22:44] <Odd-rationale> Well, see ya guys later!
[22:54] <mneptok> oy tritium
[23:09] <tritium> Hi mneptok!
[23:10] <jpds> Hey tritium.
[23:10] <tritium> hi jpds
[23:13] <tritium> jpds: how are you?  What's new?
[23:14] <jpds> tritium: Mostly packaging a new app for a friend, great ta, yourself?
[23:14] <tritium> jpds: Doing well, thanks.
[23:15] <jpds> tritium: Good :)
[23:15] <tritium> :)
[23:54] <tritium> jpds: It's looking like it'll be a while before we hear anything about our request


[04:41] <m3ga> hi. bzr is not working on me. from ~/.bzr.log : http://paste.pocoo.org/show/543402/
[04:41] <m3ga> bzr version is from debian testing
[05:33] <AuroraBorealis> does bzr support "glob' syntax that git/hg do? (as in can i copy/paste their ignore files have)
[05:43] <Peng> AuroraBorealis: Yes, but not necessarily precisely the same syntax. bzr help ignore
[05:43] <AuroraBorealis> k
[05:45] <Peng> I dunno about git, but converting hg should basically be a copy+paste, but you will need tweaks, if only taking out "syntax: glob".
[05:46] <AuroraBorealis> http://stackoverflow.com/questions/4095696/mercurial-hgignore-for-visual-studio-2010-projects
[05:46] <AuroraBorealis> so the [Bb]uild[Ll]og.* stuff will work if you just put RE: infront of it?
[05:47] <Peng> I guess.
[05:48] <AuroraBorealis> there is 'bzr help patterns' which says yeah that works
[06:22] <m3ga> damn, that's just really silly. "bzr branch somerepo" used to just work and now it gives what i think is an obscure error message. bzr: ERROR: Target directory "" already exists.
[06:24] <Peng> I'm 15% sure that's a bug that was fixed.
[06:24] <m3ga> this is in debian testing
[06:28] <lifeless> m3ga: branching a branch, or a repo ?
[06:29] <m3ga> branch
[06:29] <lifeless> hmm, thats gotta be a regression
[06:29]  * lifeless handwaves and blames bzr-colo prep work (jelmer :P)
[06:29] <m3ga> 2.5.0dev6 in debian testing
[06:36] <Peng> *.log:6659032:2012-01-25 15:02:07: < jelmer> vila: no, that's not actually fixed yet but it's on my radar
[06:37] <m3ga> thanks Peng. pity it already made its way into debian
[07:29] <vila> hi all !
[07:33] <hariom> I want a binary file to untrack. How to do that?
[07:34] <hariom> I have added that file in .bzrignore but still in bzr status I see that file appearing in modified: list
[07:34] <poolie> bzr rm --keep THING
[07:35] <poolie> you may also want to uncommit, if you just committed it, then recommit without it
[07:37] <hariom> poolie: I hope it won't remove the THING. Does --keep ensure that?
[07:45] <vila> hariom: yes, that's what --keep does
[08:02] <poolie> hi vila
[08:02] <vila> hey poolie !
[08:05] <poolie> hi, how are you?
[08:05] <mgz> morning all
[08:07] <poolie> hi there
[08:09] <vila> poolie: fine, was able to deploy pristine-tar and pbzip2 late yesterday, I'm looking at the fallouts but we're down to ~400 failures (some new ones have appeared as usual ;-})
[08:10] <poolie> that's great
[08:10] <poolie> maybe i should follow up on the list
[08:12] <jelmer> hey
[08:25] <wgz> you guys carry on, I'll fiddle here
[08:44] <mardy> hi all, "bzr pull" from a local git repository suddenly started failing for all my projects: bzr: ERROR: Error reading from 'refs/heads/'.
[10:01] <vila> hghgnh lp downtime
[10:10] <vila> jelmer: ping, pm
[10:11] <mgz> you should just pick a public channel vila :)
[10:13] <vila> different subjects ;) Here, I'd like to mention I'll propose a merge to introduce 2.5b6 before we do 2.5.0 and that will mean retargeting the existing bugs
[10:15] <vila> that is, as soon as lp is back
[10:15] <vila> which seems to be the case already
[10:18] <mgz> yup, fdt is annoying because it's dt just when we're working, but it is at least f
[10:30] <elmo> halp, wat
[10:30] <elmo> Uncommit these revisions? ([y]es, [n]o): yes
[10:30] <elmo> bzr: ERROR: An inconsistent delta was supplied involving 'modules/geoip/templates/geoip.erb', 'geoip.erb-20110907035659-stu7uecbpgflsa0u-1'
[10:30] <elmo> reason: Unable to find block for this record. Was the parent added?
[10:30] <elmo> the uncommit appears to have taken - I'm now on $revno-1, but I'm scared by the ERROR message
[10:32] <mgz> like bug 910002 maybe?
[10:32] <ubot5`> Launchpad bug 910002 in Bazaar "uncommitting a dir rename causes InconsistentDelta error" [Undecided,New] https://launchpad.net/bugs/910002
[10:32] <vila> elmo: bzr version ? plugins ?
[10:33] <elmo> mgz: hmm, I do have a bunch of renames, but not of directories, but checking
[10:33] <mgz> that's a good bug report.
[10:33] <mgz> why's it still new...
[10:33] <elmo> vila: precise, so 2.5b5 - no funky plugins I know of
[10:36] <mgz> elmo: so, summary, don't be too scared because it's 'just' a dirstate error, which worst-case you can alwasy regenerate
[10:37] <mgz> but if you've got a slightly different from that existing bug, it would be good to add info there
[10:38] <vila> jelmer: filed bug #924220
[10:38] <ubot5`> Launchpad bug 924220 in Bazaar "ssl.ca_certs should be supported in authentication.conf" [Medium,Confirmed] https://launchpad.net/bugs/924220
[10:41] <mgz> somewhat telling stat about the last few weeks, 2.5 is on r6465 but dev is only on r6456
[10:42] <mgz> hm. that's a switch regression
[10:42] <elmo> mgz: should I be worried about 'inconsistent parents' in bzr check output?
[10:43] <mgz> `bzr switch -b existing_dir` now gives a LockDir error rather than just saying it already exists
[10:45] <mgz> elmo: well, to be safe you can do `bzr branch -r($revno-1) . ../new_tree` then copy over the changes
[10:45] <mgz> but no, probably.
[10:45] <elmo> mgz: ok
[11:07] <elmo> mgz: #910002 updated, thanks
[11:08] <mgz> elmo: thank you very much.
[11:09]  * mgz optimistically targets it
[11:09] <jelmer> mgz: that indeed is a very nice bug report
[11:09] <jelmer> so far the InconsistentDelta bug reports have all been very vague and hard to reproduce
[11:10] <mgz> I've put it on my queue to look at after the stuff needed for the freeze this week are done.
[11:49] <jml> Most of my local Bazaar projects are set up in treeless repos where I use a checkout
[11:50] <jml> I really want to try colo support, so I'm installing the nightly bzr
[11:50] <jml> how do I start hacking on one of my existing projects (e.g. testtools) with colo?
[11:53] <jelmer> hey jml
[11:53] <jelmer> jml: "bzr switch -b colocated-branch-name"
[11:54] <mgz> I'd create a new testtools repo locally with colo on, then branch any works in progress into it
[11:54] <jelmer> mgz: there's no need to enable colo anymore
[11:54] <mgz> as I think we discussed the other day, there's no easy migration tool from shared-treeless to colo currently
[11:54] <jelmer> you can just do it in an existing branch
[11:54] <mgz> ah, I missed the nightly part.
[11:58] <jml> interesting.
[11:58] <jml> jelmer: and I can blame you if everything goes pear-shaped?
[11:59] <jelmer> jml: well, there are still quite a few rough edges
[11:59] <jelmer> but you won't lose any data
[11:59] <jelmer> it's not a new repo format or anything like that
[12:00] <jml> jelmer: sweet.
[12:38] <jml> jelmer: so when I try "bzr switch -b new-branch-name" and then type "bzr branches", I only see '* (default)' listed
[12:43] <jelmer> jml: are you in a lightweight checkout perhaps?
[12:43] <jml> jelmer: I am.
[12:43] <Stavros> hello
[12:44] <jelmer> jml: That would explain it. "bzr switch" creates branches in your original directory, "bzr branches" lists branches in your current directory
[12:44] <jelmer> hi Stavros
[12:44] <Stavros> i'm trying to use bzr-git, i've installed dulwich and did "bzr branch lp:bzr-git .bazaar/config/plugins/git" but it's saying "unknown protocol" for git+ssh
[12:44] <jelmer> Stavros: it should be in .bazaar/plugins/git, not .bazaar/config/plugins/git
[12:44] <Stavros> jelmer: sorry, that's where it is
[12:44] <Stavros> jelmer: it fails properly when i rename it to bzr-git
[12:44] <jelmer> Stavros: does "bzr plugins" list it?
[12:45] <jml> jelmer: is that a bug? should I be using a full & proper branch with tree instead?
[12:45] <Stavros> ah,   ** Unable to load plugin 'git'. It requested API version (2, 5, 0) of module <module 'bzrlib'
[12:45] <jelmer> jml: if you're using colocated branches, you should beu using a full and proper branch instead; there is no point in mixing shared repositories with treeless branches and colocated branches
[12:45] <jelmer> Stavros: which version of bzr are you using?
[12:46] <jml> jelmer: good point.
[12:46] <Stavros> 2.4.2
[12:46] <jelmer> Stavros: that explains it, bzr-git trunk only works with bzr 2.5
[12:46] <Stavros> that's weird, i have the bzr ppa
[12:46] <jelmer> Stavros: you probably want to use a release
[12:46] <Stavros> oh
[12:46] <Stavros> hm
[12:46] <Stavros> do you have it tagged?
[12:46] <jml> jelmer: huh, and I guess all that's needed when fetching a project for the first time is 'bzr branch <URL>' and that will automatically work... that's actually a lot nicer than shared repos
[12:46] <jelmer> Stavros: or the daily build of both bzr and bzr-git
[12:46] <Stavros> i'll just use the release of bzr-git, thanks
[12:46] <jelmer> jml: yep, exactly
[12:47] <Stavros> how do we branch to tags again? it's been long since i used bzr, but it was the best
[12:47] <Stavros> bzr revert tag:bzr-git-0.6.7?
[12:47] <Stavros> hmm no
[12:47] <jelmer> Stavros: bzr up -rtag:bzr-git-0.6.7 I think
[12:47] <Stavros> that worked, thanks
[12:48] <jelmer> Stavros: you ctually want 0.6.6 I think
[12:48] <Stavros> jelmer: yep, that worked, thank you
[12:48] <jml> hmm.
[12:48] <Stavros> you might want to make the error messages a bit more descriptive :/
[12:48] <jml> also makes it a bit less cumbersome to write a command that shows branches with unmerged revisions.
[12:49] <jml> ugh, I wish fewer projects I worked on used virtualenv...
[12:49] <Stavros> jml: virtualenv is awesome, why don't you like it?
[12:50] <jelmer> Stavros: we keep going back and forth on this; the reason the error messages are less intrusive is because people kept complaining about them.
[12:50] <jml> Stavros: in a nutshell, because it requires too much network access.
[12:50] <Stavros> jelmer: even something like "unsupported protocol, see 'bzr plugins' for details" would be nice
[12:50] <Stavros> jml: ah
[12:50] <Stavros> jml: you can use pip with freezing
[12:51] <Stavros> bzr-git is amazing, oh how i love it
[12:51] <Stavros> has bzr gotten significantly faster in the past year? i switched to git from it for the speed, but git is a mess
[12:52] <jelmer> Stavros: yes, 2.5 will be a lot faster
[12:52] <Stavros> fantastic
[12:52] <Stavros> how stable is 2.5?
[12:53] <jml> jelmer: after branch lp:testtools, 'bzr branches' says '* (default)', then if I switch -b new-branch, only that new-branch appears in the 'branches' listing. How do I get back to trunk?
[12:53] <jelmer> Stavros: you should have gotten an error message about versioning when attempting to use git+ssh://. You didn't?
[12:53] <jelmer> jml: "bzr switch -b trunk"
[12:53] <jelmer> jml: The initial branch is unnamed, it's not named trunk
[12:54] <Stavros> jelmer: no, the exact message is: bzr: ERROR: Unsupported protocol for url<EMAIL_ADDRESS>[12:54] <jml> jelmer: but if I'd started hacking on that new branch then I wouldn't be able to do that without first figuring out the revision on which I diverged, right?
[12:55] <jelmer> Stavros: ah
[12:55] <jml> jelmer: is https://bugs.launchpad.net/bzr/+bug/588020 righly a colocated bug?
[12:55] <ubot5`> Launchpad bug 588020 in Bazaar "tab completion should honour switch lookup path" [Wishlist,Confirmed]
[12:55] <jelmer> Stavros: can you perhaps file a bug report about that? That's definitely a bug.
[12:55] <Stavros> sure
[12:55] <Stavros> with bzr or with bzr-git?
[12:55] <jelmer> Stavros: bzr
[12:56] <jelmer> jml: somewhat - it's an issue with sibling branches; that includes colocated branches but also "siblings" that happen to live in the same shared repository
[12:56] <jml> jelmer: so I guess that unless you are some kind of weirdo you almost always want to do 'bzr switch -b trunk' after fetching a branch for the first time
[12:57] <Stavros> do colocated branches shelve your uncommitted changes when switching yet?
[12:57] <jml> jelmer: I see. I was about to file a bug for tab completion for colo branches but I think that bug covers it.
[12:57] <jelmer> Stavros: no
[12:57] <Stavros> ah :/
[12:57] <jelmer> Stavros: personally I wouldn't really want that behaviour, but I guess it might make sense for switch to have an option to do that.
[12:58] <Stavros> jelmer: i would love it, instead of having to use different folders, if i could have a shelve per branch
[12:58] <Stavros> that way i could switch my uncommitted changes around
[12:58] <jelmer> I think shelves are per checkout at the moment though.
[12:58] <jelmer> so it's not just a matter of running shelve before the switch, you would actually have to change the way shelves work.
[12:59] <mgz> there are arguments both ways on that
[12:59] <jelmer> mgz: how do you mean?
[12:59] <Stavros> jelmer: ah :/
[12:59] <mgz> I find sometimes I'm glad my shelves are all on ./tree but sometimes they should be following ./feature-branch
[13:00] <jelmer> mgz: for what Stavros is asking about, you would definitely have to have them per-branch though
[13:00] <jelmer> jml: I think so too
[13:00] <Stavros> what i want is colocated  branches to contain my uncommitted changes, i don't really mind if this isn't implemented via shelves
[13:00] <Stavros> it would just be nice if this were possible
[13:01] <mgz> right, it's different ways of working
[13:01] <jelmer> Stavros: you don't want them all shelved onto the same shelve though
[13:01] <jelmer> Stavros: is what I'm saying
[13:01] <mgz> I quite often just start off on trunk then switch when I know what to name the thing I'm hacking on
[13:01] <jelmer> Stavros: you could always commit/uncommit before switching?
[13:01] <Stavros> jelmer: oh, yes, probably not
[13:01] <Stavros> jelmer: yeah, that's a solution
[13:01] <Stavros> it'd be nice if it were done automatically
[13:01] <Stavros> i might write a plugin to do it
[13:02] <Stavros> commit with some special commit message, uncommit if the last commit matches the message when switching
[13:03] <jelmer> I wouldn't want to do that automatically in the core, because it would really pollute the repository
[13:03] <jelmer> but yeah, you could very well do that as a plugin
[13:04] <Stavros> how hard is that to write, as someone very familiar with python but not at all with bzr plugins?
[13:05] <jml> Stavros: I found it pretty easy
[13:06] <Stavros> great, i'll give it a stab later today then
[13:06] <Stavros> it'll just commit and uncommit, how hard can it be
[13:06] <Stavros> although i guess it would break things if you push
[13:06] <Stavros> hmm
[13:06] <jml> Stavros: I found existing plugins and bzrlib/builtins.py to be the best places to start
[13:06] <Stavros> jml: ah, i'll try that, thanks
[13:06] <Stavros> i'll try to find a simple plugin and look at it
[13:07] <jml> bzr-grep is pretty simple, iirc.
[13:07] <Stavros> aha, i'll look at that then, thank you
[13:15] <Merwin> vila, are you there
[13:16] <vila> tricky question...
[13:16] <vila> I'm having a late lunch and reading the backlog ;)
[13:17] <Merwin> vila, one of my coworker just made a huge mistake :D
[13:18] <Merwin> He removed a lot of files, in different commits, merged with more recent commits, then commited the merge and pushed again...
[13:18] <Merwin> I need to undo all what he did, without touching other team members commits because they are good
[13:18] <Merwin> But looking at the qlog, I can see its merges with subcommits -the good ones-
[13:18] <Merwin> How can I just undo its modifications ?
[13:19] <Merwin> (For example, the last commit is a good one, but the 4 previous are bad, then 5th back is good, and the 6 back is wrong...
[13:20] <Merwin> So I would need to unco changes made in commit -2..-4, and -6 for example
[13:20] <mgz> jelmer: just to distract you further, have you got 30 seconds to check my thinking on <https://code.launchpad.net/~gz/qbzr/trivial__get_entry_nosuchid/+merge/90845>
[13:21] <mgz> jelmer: feel free to revenge bug me about anything during the week
[13:21] <vila> Merwin: same as yesterday, merge the reverse range of the revisions you want to undo, check the diff, commit, rinse and repeat for all ranges
[13:22] <Merwin> vila, I'll try, thanks
[13:22] <Merwin> vila, but the "good" commits are in merges, so I don't see them in bzr log
[13:22] <Merwin> I just see my bad-coworker commits
[13:22] <jelmer> mgz: +1, though you might want to always convert to a list in case iter_entries_by_dir returns a sequence rather than an iterator
[13:23] <mgz> but that loses the ability to only do the work for the first item
[13:24] <mgz> I guess for filter like this it's already done everything?
[13:24] <mgz> there's only one thing matching the given file-id
[13:24] <jelmer> mgz: there is only one item, so I don't think that's a big deal :)
[13:24] <vila> Merwin: use 'bzr log -n1 -l32' to view lower level commits (-n)
[13:24] <Merwin> vila, removing a "parent" commit (a merge commiut) won't remove all its children ?
[13:25] <mgz> I guess an alternative spelling would be: for i in iter(): return i; raise
[13:25] <mgz> which is actually a bit neater...
[13:25] <jelmer> yeah, that works too..
[13:25]  * mgz uses that
[13:26] <vila> Merwin: when you cherry-pick, you remove nothing
[13:26] <vila> Merwin: actually when you merge you remove nothing either, cherry-picking a reversed range doesn't remove the revisions either it only applies the opposite change
[13:28] <vila> mgz: being able to *move* a shelve would be really nice
[13:28] <Merwin> hum
[13:28] <vila> mgz: some revisions may need to be pulled too
[13:32] <mgz> vila: it would, but only if it was then available when switching back
[13:32] <vila> mgz: err, not sure we're on the same page, I was thinking about an explicit command to move a shelve from one tree to another
[13:34] <Merwin> vila, I can't male it work. The commit 350 is a "merge" commit. I want to keep all commits under it, but exclude modifications made by the guy. I try bzr merge -r 350..349 . but it seems that it cancels all subcommits
[13:35] <mgz> right, but needing to manually move it back again would be a little annoying too
[13:36] <vila> Merwin: well, yes, 350..349 includes all children, you probably want something I can;t describe without seeing your history though ;)
[13:43] <vila> Merwin: but you can address lower level commit by revno too, use their dotted representation that log -n1 will display
[14:02] <vila> mgz: rubber stamp for https://code.launchpad.net/~vila/bzr/beta6/+merge/90869 ?
[14:02] <vila> jelmer: see above and check your news entries :-p
[14:03] <vila> jelmer: kidding, don't lose time on that ;)
[14:03] <vila> jelmer: but I don't know if pqm will be as friendly ;)
[14:07] <Merwin> ok vila I think I got what I wanted! In fact if I want to cherrypick only the modifications done between a bzr merge and a bzr commit, I have to do bzr merge -r350..XXX.YYY.ZZZ, with XXX.YYY.ZZZ being the last commit before the merge
[14:07] <Merwin> Thanks for your help... again ;)
[14:07] <vila> yup exactly
[14:08]  * vila wishes this can some sort of drap-and-drop operation from qlog or something...
[14:08] <vila> s/can/can be/
[14:09] <Merwin> The GUI is too limite IMHO for these use cases :)
[14:09] <vila> yup... for now ;)
[14:10] <mgz> vila: done
[14:10] <vila> thanks
[14:13] <mgz> some of the pending bugs retargetted may want to be 2.5.0 again, but can see when the freeze happens which got done
[14:15] <vila> oh, just a sec, I'll make the 2.5.0 milestone active again
[14:16] <vila> done, feel free to retarget
[14:16] <vila> and sorry for bug spam
[14:17] <vila> jelmer, mgz : https://code.launchpad.net/~vila/bzr/920455-ssl-defaults/+merge/90693 should now be ready for final review
[14:18] <mgz> vila: looks like you still need a relative path for the installer versions
[14:19] <vila> I need a path yes, why relative ?
[14:19] <vila> and relative to what ? Oh, you mean relative to sys.executable for windows ?
[14:20] <vila> but yes, the intent is to do two one-liners fixes when windows and osx installers have a proposal
[14:20] <mgz> just `os.path.join(os.path.dirname(sys.executable), "ca_bundle.crt")` or something wouldn't hurt
[14:21] <vila> bzr_ca_bundle.txt ? Or is the executable already in a bzr-private directory ?
[14:22] <mgz> it's in "Program Files\Bazaar" or whatever on windows for the all in one installer, and Python26 etc otherwise
[14:23] <vila> ok, done then. People that don't use the all-in-one installer are supposed technical-savvy enough to set it up themselves in bazaar.conf
[14:24] <mgz> there's no reason to prefix the name at any rate, there's nothing bzr specific about certs.
[14:24] <vila> and pushed
[14:26] <mgz> and have you double checked that you do actually get the pretty error rather than random junk if a particular dir doesn't exist?
[14:30] <vila> yup, it's explained in one of my comments with instructions to reproduce ;)
[14:31] <vila> double-check welcome as I went to a lot of small changes trying to support 'optional' but I'm pretty sure I didn't break that in the end
[14:32] <vila> i.e. the logic is: if you defined ssl.ca_certs, it should be valid. When we need it, we query the config, if it doesn't exist, we abort (you ask for verification, we need some valid path)
[14:34] <mgz> but required is the default, so they didn't ask as such, the initial branch had various nitpicking about the connection-to-https case needing to have a pretty message about disabling checking when it fails
[14:34] <mgz> I'll try out your branch downstairs in a bit
[14:36] <trebor_dki> hi. being an plain cvs user, i am forced to import a subversion repo into a (new) bzr repo. is there a 5-minute howto in the man/info/web? thanks for hints
[14:36] <vila> mgz: yup, indeed the tension is between 'required' being the default and ssl.ca_certs *not* providing a valid default ;)
[14:38]  * trebor_dki found http://www.szakmeister.net/blog/2009/oct/12/bazaar-subversion-super-client/ - but that is (to me) about using bzr as a svn (super-)client.
[14:39] <jelmer> trebor_dki: the entire repository (all branches) or just a single branch?
[15:09] <trebor_dki> jelmer: (sorry for delay) - the entire repository
[15:10] <trebor_dki> it is a move from svn to bzr
[15:23] <smoser> anyone have thoughts on how i could get libvirt importer fixed: http://package-import.ubuntu.com/status/libvirt.html#2011-05-26%2020:07:23.558315
[15:27]  * trebor_dki found this: svnadmin dump -q path/to/my_svn_project > my_project_dump;; bzr svn-import my_project_dump new_path/to/my_project;;      is this the way to migration?
[15:29] <abentley> jelmer: bzr-pqm r83 breaks lp-land, because it calls BranchConfig.get, which doesn't exist.
[15:32] <jelmer> trebor_dki: you probably just want to call "bzr svnimport /path/to_my_svn_project project.bzr"
[15:32] <jelmer> ehm, "bzr svn-import ..." (with a dash)
[15:48] <wgz> vila: so, the current SSL config error handling is borked
[15:49] <wgz> I may be able to do something sane on the trace side when ssl.SSLError is raised, I then just need a suitable error for the config issue raised as well rather than the useless generic one
[15:49] <wgz> then the trace.note stuff in connect_to_origin can go, having been absorbed at a higher level
[15:49] <vila> borked how ? In which case ?
[15:50] <wgz> see mp.
[15:50] <wgz> 'Bad value' sucks.
[15:51] <wgz> given we're breaking something that used to work, the message needs to be totally clear about how to fix the issue
[15:52] <wgz> `bzr help ssl.ca_certs` could do with being a lot more detailed too.
[15:52] <vila> then move the trace you like into ca_cert_from_store *before* raising bad value
[15:53] <wgz> you can do that, just need to copy the block from `if ca_certs is None` below which I presume now never gets hit?
[15:54] <wgz> raising a custom error would still be nicest
[15:54] <vila> hmm
[15:55] <wgz> yeah, `ca_certs = config_stack.get('ssl.ca_certs')` is validating the file rather than just leaving None or a non-existant name
[15:55] <vila> at one point I wanted to add 'See bzr help %(option_name)s' ib ConfigValueError then the help can be used to provide more details
[15:56] <vila> well, I wanted.. I did and then removed it because the strings were frozen (which may have been a bad idea)
[15:57] <wgz> these messages aren't translated anyway atm.
[15:57] <wgz> (they should be)
[15:57] <wgz> you see what I'm talking about in HTTPSConnection.connect_to_origin right?
[16:00] <vila> the trace.note call right ?
[16:01] <wgz> there are two
[16:01] <wgz> they should kinda be combined really
[16:01] <wgz> but we need something for all kinds of validation errors, and the cert file missing is just a particular case of that
[16:02] <wgz> what's the easiest way of overriding a config default for a blackbox test?
[16:02] <wgz> having something try and connect to a https server with a default cert file that doesn't exist and asserting the error is useful would be good
[16:03] <wgz> +missing
[16:03] <vila> there is one trace.call and two trace.warning calls
[16:03] <vila> yeah, I tried a bit but resigned, there was no obvious way to test that ;_;
[16:05] <wgz> monkey patch opt_ssl_ca_certs to have a different default function?
[16:05] <vila> yeah, I did that at one point to unit test when trying to support 'optional'
[16:06] <vila> let's backtrack a bit
[16:07] <vila> we want: 1) the default value to be good for 99% of the cases, having the all-in-one windows installer and the osx installer carry the certs cover that
[16:07] <vila> 2) for the remaining windows/osx users, we want a clear error message
[16:08] <vila> mentioning bzr help %(option_name)s and enhancing the help *and* keeping the trace.note and trace.warnings where they are ?
[16:09] <wgz> plus a bit of editing, wouldn't be too bad
[16:09] <vila> mgz: by the way, we're not "breaking something that used to work", really, we fixed https for urllib that wasn't verifying ;)
[16:09] <wgz> though a little backwards compared to the error-then-advice approach trace.report_user_error has
[16:10] <wgz> the effect is breakage, it's good breakage, but I want to avoid hundreds of bug reports about an intended change
[16:11] <wgz> mentioning the default path is one thing config is doing right that the previous version didn't
[16:11] <vila> yeah, me too, that's why I want to fix this asap but the current implementation is already known to not be the final one, we really want support from authentication.conf
[16:12] <vila> err, why do you backwards ? We display the error mentioning the help, the advice in the help so it will displayed after the error too no ?
[16:13] <vila> or do you want the help itself to be part of the error ?
[16:13] <wgz> nope.
[16:13] <wgz> I like the advice after
[16:13] <wgz> moving the trace calls around would mean it gets printed first, which is till okay.
[16:14] <wgz> *still
[16:19] <vila> wgz: http://paste.ubuntu.com/824008/
[16:24] <wgz> vila: yeah, that kind of thing is nice. could also special case ConfigOptionValueError in trace, there are benefits both ways.
[16:24] <wgz> have we got a standard form of marking commands? I use backticks, but that may just be me.
[16:26] <wgz> I really want the advice about disabling right there in the error
[16:26] <wgz> and ideally not duplicated in several places.
[16:26] <vila> no standard, some errors use double-quotes most use nothing
[16:27] <vila> the problem is that we want a valid path, so config is the right place to check that,
[16:27] <vila> hmm
[16:28] <wgz> but config users can't rely on config to actually ensure a path is correct
[16:28] <vila> wgz: can you redo your test after changing 'error' to 'warning' for ssl.ca_certs ?
[16:28] <wgz> as they may be using the value later, and files can move etc.
[16:29] <wgz> ^sure
[16:29] <vila> right, but at one point the config is queried and at *that* point the file should be in the right place
[16:31] <wgz> vila: http://paste.ubuntu.com/824030/
[16:31] <wgz> that's more like what wget does, though still not *completely* perfect :)
[16:32] <vila> perfect enough ? :-D
[16:37] <vila> wgz: pushed
[16:37] <vila> with some more minor tweaks
[16:37] <wgz> http://paste.ubuntu.com/824042/
[16:37] <vila> argh, crossed on wire ;)
[16:37] <vila> None ??
[16:38] <wgz> apparently.
[16:38] <vila> err, and the meaning is ?
[16:39] <wgz> I'm built against a slightly newer openssl than default Python 2.7 config, but I doubt it's changed
[16:39] <vila> there are two 'raise's there, I just edited to use only one, but we'll raise if we see 'None'
[16:39] <vila> s/$/ anyway/
[16:39] <wgz> None is just what I observed the errno is if we don't supply a string for ca_certs
[16:40] <wgz> the trace functions kinda suck, we need to get away from using them
[16:40] <vila> but still use ssl.ca_reqs=required ?
[16:41] <vila> grr, that's the case I was getting rid of by using error instead of warning ;_;
[16:42] <wgz> config just doesn't have enough context to give good errors
[16:43] <vila> right, but we should not accept ca_reqs=required and ca_certs == None, no need to even try
[16:44] <vila> yeah config does not have enough context but if we go too far from config we can't point to config anymore
[16:44] <wgz> anyway, I've distracted you enough, what you have will do for now and I can tweak later
[16:45] <wgz> wrapping both ConfigValueError and SSLError in a BzrError with extra stuff would work as well.
[16:46] <wgz> would then avoid the duplication in those two locations
[16:47] <pmezard> hello, are Revision.message guaranteed to be unicode objects?
[16:47] <wgz> yes, with normal python caveats.
[16:48] <pmezard> what do you mean?
[16:49] <vila> wgz: as in: I push my latest changes and you'll pilot to safe harbor from there ?
[16:50] <wgz> python doesn't actually enforce types, so a misbehaving plugin could give you a Revision object where message is a byte string, or a tuple, or a Rabbit
[16:50] <vila> wgz: this code *will* be revisited in the future anyway
[16:50] <vila> or a Pony ?
[16:50] <wgz> a Pony would be too much to hope for.
[16:50] <pmezard> wgz: oh right, bugs are bugs, I was more interested about the intent
[16:50] <wgz> vila: yes, land away.
[16:50] <pmezard> thanks
[16:51] <fullermd> Ponies aren't bugs.  Unless they have 6 legs.  Which would be awesome.
[16:51] <wgz> :D
[16:51] <pmezard> eheh
[16:51] <LeoNerd> Some sort of centaur?
[16:52] <fullermd> That would be 5 legs.  Traumatic amputation.  He doesn't like talking about it.
[16:59] <vila> wgz: err, the None bit is unclear, I'd rather not test e.errno at all so we always display the note (this except clause is fatal anyway and the only workaround is to set ssl.ca_reqs=noe)
[16:59] <wgz> vila: land what you have, not my changes
[17:00] <vila> meh, AIUI, what I have will not do what we want on windows without a valid bundle O_o
[17:01] <vila> wgz: please just do a final test with reno 6464 and I'll land it
[17:15] <wgz> that now shows both messages though vila
[17:15] <wgz> the rev before was okay.
[17:16] <wgz> or delete the `if ca_certs is None:` block above
[17:18] <vila> wgz: will delete this block and land
[17:18] <wgz> cool.
[17:25]  * vila bangs head
[17:25] <vila> I've landed the 2.5b6 change on bzr.dev
[17:27]  * wgz pats vila
[17:27] <wgz> I should have seen that too
[17:30] <vila> lp-propose should default to the submit_branch location (which itself should default to parent_location if not set)
[17:35] <vila> each time I look at the pqm page when the test_non_ascii are passing, I have a wtf moment thinking we're back to the time were the test suite was run twice on pqm :)
[17:42] <cob_olp> hi
[17:44] <cob_olp> i would like have a bzr repository on a server
[17:44] <cob_olp> it is a windows machine
[17:45] <cob_olp> probably smart server will be a good choice?
[17:46] <cob_olp> but how can I introduce some security, I mean something like ssh
[17:46] <cob_olp> is it possible to setup ssh on windows, or maybe there is some other way?
[17:48] <nDuff> cob_olp: yes, cygwin's sshd supports Windows
[17:48] <nDuff> cob_olp: ...there are certainly other approaches as well, ie. running over https
[17:48] <cob_olp> hmm
[17:49] <cob_olp> so maybe instead of cygwin ssh, the better choice will be in fact a virtual machine with linux?
[17:51] <cob_olp> because for https I will have to introduce some authentication
[17:51] <cob_olp> should I in such case put some password on my repository folder?
[17:52] <cob_olp> will bzr support such access?
[17:58] <jelmer> cob_olp: yes, bzr supports kerberos and basic/digest auth
[18:00] <cob_olp> ok, thank you
[18:01] <cob_olp> and what setup would you suggest on windows 2003 machine?
[18:02] <jelmer> cob_olp: no idea, I haven't set up a https server on Windows
[18:16] <cob_olp> thank you for help
[18:17] <cob_olp> probably I will install VM with ubuntu server and use bzr+ssh:/ :)
[18:26] <JPeterson> i installed bzr-2.5b5-1-setup.exe, selected everything, and get this error bzr: ERROR: No module named xml_errors
[18:26] <JPeterson> when selecting All in the bazaar explorer toolbar
[18:28] <JPeterson> it seems like it was fixed here http://bazaar.launchpad.net/~gz/bzr-windows-installers/xmloutput_r160_update_921754/revision/202
[18:28] <JPeterson> can i use that release? how do I use it?
[18:30] <wgz> JPeterson: you can either remove xmloutput from the plugins dir or update it if you need it
[18:31] <JPeterson> wgz, how do i updated it?
[18:31] <JPeterson> why can't i update it from the plugin list
[18:35] <wgz> JPeterson: go to the plugins dir, remove the xmloutput dir, then do `bzr branch lp:bzr-xmloutput xmloutput` to recreate it with the latest version of the plugin
[18:35] <JPeterson> thx
[18:37] <JPeterson> wgz isn't the xmloutput dir supposed to come back after that?
[18:38] <wgz> yup, but you need to be in the plugins directory when you run the command
[18:48] <JPeterson> ok
[18:48] <JPeterson> wgz why do i get "Permission denied (publickey)"
[18:48] <JPeterson> i haven't even told it where my private key is
[18:49] <JPeterson> and i haven't told it my password
[18:50] <wgz> generally it means you've done `bzr launchpad-login` because it told you to, but not uploaded your public key to launchpad or run your ssh-agent
[18:53] <wgz> you can either remove 'launchpad_login' from your bazaar.conf (running `bzr version` will tell you what directory that's in), or go through the steps to enable ssh access
[18:54] <wgz> see <https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair> for that.
[19:08] <JPeterson> wgz, i dunno what running the ssh agent mean, but i ran it from cygwin isntead which worked
[19:12] <JPeterson> that didn't work because the Windows command line needs to see the private key too
[19:12] <JPeterson> how do i do that?
[19:15] <JPeterson> ok i need to use the annoying pageant.exe
[19:15] <JPeterson> it can't even add the key generated from ssh-keygen -t rsa lol
[19:19] <JPeterson> ok i have to run it through puttygen.exe first 0_o
[19:22] <JPeterson> wgz, now pageant.exe is running but bzr still fails with Permission denied (publickey).
[19:24] <JPeterson> can i ask tortoisebzr to run bzr through cygwin instead?
[19:29] <JPeterson> what's the point of tortoisebzr if it can't run bzr?
[19:30] <wgz> ...I'm missing context on that question thanks to my ISP
[19:33] <JPeterson> wgz, ok
[19:33] <JPeterson> https://launchpad.net/subdownloader "Programming Languages: Python / QT4 "
[19:33] <JPeterson> fantastic, what pythin version is it using
[19:33] <JPeterson> that's kind of relevant lol
[19:35] <wgz> that... doesn't seem related to bzr. it's just some project on launchpad,
[19:35] <JPeterson> ya
[19:36] <wgz> you could use 'Ask a question' to ask the developers to document which python version, or just try it locally and see if it breaks
[19:36] <mgedmin> Commit message was not edited, use anyway? [y/n]: n
[19:37] <mgedmin> this always makes me stop and think
[19:37] <mgedmin> don't make me think, please
[19:37] <mgedmin> if I abort the editor without quitting, clearly that's because I noticed something wrong in the diff and decided not to commit
[19:38] <wgz> or because you liked the auto generate commit message as it was?
[19:38] <wgz> (not that I'm sure it applies)
[19:38] <wgz> personally I always just use commit -m
[19:42] <wgz> mgedmin: deleting the contents of the file if you're unhappy with it avoids the prompt
[19:43] <mgedmin> there are auto-generated commit messages?
[19:43] <mgedmin> in what circumstances?
[19:44] <wgz> using the set_commit_message or commit_message_template hooks, as used by bzr-builddeb for instance
[19:56] <mgedmin> ooh
[19:57] <mgedmin> so when I answer "n" to the not edited question, I get
[19:57] <mgedmin> bzr: ERROR: empty commit message specified
[19:57] <mgedmin> which scarily-looks as if bzr tried to commit anyway and then aborted when it noticed the message was empty
[19:57] <mgedmin> there's no reason bzr can't check for empty-ness before it checks for not-edited-ness
[19:57] <mgedmin> and abort the commit (like git does) without asking unnecessary questions
[19:58] <wgz> patches welcome!
[19:59] <wgz> bzr branch lp:bzr then it's in bzrlib\msgeditor.py
[20:00] <wgz> just moving the block down would work but the logic could probably be tidied up more generally
[20:07] <wgz> JPeterson: now I've read the log from when I was disconnected, I see you were having issues getting an ssh key set up
[20:08] <wgz> JPeterson: did you remember to do 'Add key' on Pageant? pasting the section from you .bzr.log where it failed may have more info.
[20:08] <JPeterson> wgz ok
[20:09] <wgz> it seems to did all the hard bits.
[20:09] <wgz> and if it worked via cygwin then you must have the key on launchpad correctly.
[20:10] <JPeterson> wgz where's .bzr.log?
[20:10] <wgz> ah, unless you generated a new key rather than importing your existing one?
[20:10] <wgz> ^`bzr version` will tell you where .bzr.log is
[20:11] <JPeterson> 0.082  bazaar version: 2.5b5
[20:11] <JPeterson> ...
[20:11] <JPeterson> 0.322  ssh implementation is OpenSSH
[20:11] <JPeterson> [234260] 2012-01-31 21:11:08.059 WARNING: ConnectionReset reading response for 'BzrDir.open_2.1', retrying
[20:12] <wgz> you did Conversions -> Import key rather than Generate right?
[20:13] <JPeterson> correct
[20:13] <wgz> hm. and that looks like it's using openssh rather than paramiko or plink, which is why it doesn't find the key
[20:13] <wgz> if you do..
[20:13] <wgz> set BZR_SSH=paramiko
[20:14] <wgz> and then try to branch something again, do you get a different ssh implementation line in the log?
[20:15] <JPeterson> wgz thx, that's what was missing
[20:15] <wgz> ...it should be the default, I wonder what was going wrong
[20:16]  * wgz checks the code
[20:20] <wgz> hm. no, having something called ssh on your path takes precedence, that's not great on windows.
[20:22] <JPeterson> ok
[20:22] <JPeterson> restarted pageant and get this
[20:22] <JPeterson> 0.234  failed to load system host keys: [Errno 2] No such file or directory: 'C:\\Users\\User/.ssh/known_hosts'
[20:22] <JPeterson> thats' not where it is,
[20:22] <JPeterson> it's in C:\Files\Services\cygwin\home\User\.ssh
[20:22] <wgz> JPeterson: remember to set that variable in you user variables under system properties so it sticks
[20:23] <wgz> ^heh, that comes from a function where the docstring begins "Load system host keys (probably doesn't work on windows)..."
[20:24] <wgz> it's ignorable kipple though, provided you add the key again whenever you restart paramiko (yes, it's annoying, but most ssh-agents are like this) then things will work
[20:25] <wgz> so, right click little icon, add key, select key file, enter password
[20:25] <JPeterson> wgz, what? how do I tell it where the known_hosts is?
[20:26] <wgz> ah, maybe you can actually, and avoid pageant
[20:26] <wgz> try `bzr config ssh_host_keys=C:\Files\Services\cygwin\...etc`
[20:27] <wgz> no, wait, misread
[20:27] <wgz> what *is* this doing...
[20:28] <wgz> meh, just ignore it, is harmless
[20:31] <JPeterson> wgz: ok. now it worked again btw. ConnectionReset reading response for 'BzrDir.open_2.1', retrying came from a temporary router downtime
[20:31] <JPeterson> not bzr
[20:32] <wgz> it's unfortunate the failure modes look the same...
[21:28] <poolie> hi all