[03:34] <Resistance> i placed myself on the list to be considered an op in #ubuntu.  i'd like my "proposed op" status revoked on the LP group (i think i need more practice at catalyzing first)
[03:35] <pangolin> ircc ^^
[03:36] <pangolin> Resistance: :)
[09:35] <AlanBell> odd request from Resistance there
[09:37] <AlanBell> done though
[22:39] <Unit193> Flood bots in #kubuntu are having a fun time again :P


[10:53] <flocculant> Unit193: thanks - I forgot to mention that to oleks :)
[10:54] <Unit193> Sure thing.
[10:54] <flocculant> well I didn't totally forget - just forgot to tell them :D


[21:48] <bob98> To my way of thinking, it is something that is a part of an application and should  just do its thing in the background if access to the application is sufficient by that user
[21:48] <gigirock> ColdKeyboard, have you a uefi boot ?
[21:50] <ColdKeyboard> gigirock: To be hones, I don't think I have but haven't checked yet
[21:50] <ColdKeyboard> I didn't make changes to BIOS config thou
[21:50] <gigirock> ColdKeyboard, did you install / reinstall the grub in the ssd ?
[21:51] <tito_> hi guys
[21:51] <bob98> oerheks: ran the command you suggested, it does not list scripts of individual web pages visited
[21:53] <ColdKeyboard> gigirock: Yes I did. I think GRUB boots the hdd fine. I can see it and it boots to emergency console where I can pretty much do everything except GUI and some services don't start...
[21:53] <gigirock> !info nvidia-panel
[21:53] <oerheks> huh/ you started that *your* script is not running, now you switch to scripts of web pages visited, what did i miss?
[21:54] <ColdKeyboard> I'm not sure if there is a way to see why it's failing to start GUI
[21:55] <xenial64-user2> hello?
[21:55] <Chicken_Wrap> hi
[21:56] <bob98> oerheks: I guess I was not clear, sorry if I confused you; I guess you thought I wrote a script for Firefox? No. I am talking about how the NoScript plugin allows /blocks scripts on various web pages
[21:56] <oerheks> bob98, then noscript would prevent this, i just read back
[21:57] <oerheks> without js the video would not start, for example
[21:58] <bob98> oerheks: so going back to my original question: why is everything working fine under 16.04 but not under 18.04 (even if all scripts are allowed)?
[22:02] <Chicken_Wrap> bob98: Tried to read back but got lost. You’re saying you’ve allowed scripts globally in NoScript from Firefox, but websites are behaving strangely?
[22:02] <GlenK> hi there.  I have ubuntu 14 running via virtmanager, or qemu/kvm I guess.  when I go full screen though I'm not able to select my laptops native resolution.  any ideas?
[22:04] <hp> Does ubuntu have support for i915/GM965 gpu ?
[22:05] <gigirock> hp, mmmmmh i think not
[22:05] <bob98> Chicken_Wrap: here's a repeat of my original post: Problem with script permissions in Firefox: under 18.04 on some sites (ex: http://www.pro-tv.net/2002-5-kanal.html or http://rus24.tv/perviy_kanal.html). Same sites with same ver of Firefox work fine under 16.04. What is likely responsible: NoScript plugin, Firefox for 18.04 or something in 18.04 itself?
[22:05] <hp> :(
[22:05] <hp> gigirock: too bad can I install 4.13/4.14 kernel where it works over the original one(IK it's not really supported but)?
[22:06] <hp> on 18.04 lts
[22:06] <hp> ?
[22:06] <bob98> Chicken_Wrap: so under 18.04, even after allowing all scripts on the pages I listed above, the video does not start. Yet everything works fine under 16.04
[22:07] <hp> like 4.14.51/4.13.16 gigirock ?
[22:07] <hp> from kernel-ppa on a 18.04
[22:08] <gigirock> hp 1604 is here to stay for some year again why do you need to upgrade ?
[22:08] <hp> because I know for sure that even the intel wifi driver isn't supported/doesn't work
[22:08] <hp> I'm not on ubuntu
[22:08] <hp> rn
[22:09] <gigirock> hp and what is your wifi chip ?
[22:09] <hp> output on 4.13: Card-2: Intel PRO/Wireless 3945ABG [Golan] Network Connection           driver: iwl3945
[22:10] <hp> on 4.15 it doesn't load the driver or it's not there I haven't memorised the driver name so I haven't tried to modprobe it
[22:10] <hp> under 4.15
[22:10] <bob98> Chicken_Wrap: I do not permit scripts globally, but even after changing all scripts on a page to "Temporarily Trusted" the problem persists under  18.04
[22:13] <hp> also from the output of the apt on that distro it said something about missing i915 firmware gigirock ,but I would had to check how it works on ubuntu install/ubuntu live dvd
[22:13] <hp> which is what I gonna do rn with xubuntu 18.04 in sec
[22:14] <hp> see you in a jiffy
[22:14] <hp> I log out
[22:17] <bob98> oerheks: Chicken_Wrap: do you understand my question now?
[22:18] <bob98> and if so, could this be in any way related to ubuntu itself or am I better off taking it further on #firefox or specifically on NoScript's forum?
[22:19] <cheikh> Hello Word
[22:22] <Chicken_Wrap> bob98: Have you tried to outright disable NoScript and refresh to see if it’s the problem? Because I doubt it has anything to do with Ubuntu.
[22:24] <hp> Yo got a question
[22:25] <hp> If I put cmdline option before booting iso in live/install mode
[22:25] <hp> will it install with altered /etc/default/grub ?
[22:25] <hp> and put that cmdline option everytime
[22:25] <hp> or I will have to do it post install ?
[22:25] <bob98> Chicken_Wrap: good advice :) its the simplest things we often overlook...
[22:25] <hp> file=/cdrom/preseed/xubuntu.seed boot=casper initrd=/casper/initrd.lz quiet splash video=SVIDEO-1:d video=TV1:d ---
[22:25] <hp> Need the video= cmdline
[22:26] <hp> desperatelly to boot into xorg at all
[22:26] <hp> on 18.04
[22:26] <hp> on 14.04-17.10 it was mainlly to avoid usb devices not waking up as fast
[22:26] <hp> now I need it to boot tbh
[22:27] <hp> yeah I will verify after install I guess
[22:27] <antifa> het guys ! having some trouble runing calibre on ubuntu 18.06 I et thiss error when runin
[22:27] <antifa> ImportError: No module named _firefox3cookiejar
[22:27] <tomreyn> !enter | hp
[22:27] <hp> allright
[22:28] <FatSpitfire> ubuntu broken at booting line 19.6
[22:28] <tomreyn> hp: linux parameters you provide in a live grub are not retained, they are valid just for this very boot.
[22:29] <antifa> het guys ! having some trouble runing calibre on ubuntu 18.06 I et thiss error when runing it ImportError: No module named _firefox3cookiejar
[22:29] <FatSpitfire> how to fix booting problem from telnet ?
[22:29] <hp> tomreyn, ah I see well I will add it in after install
[22:30] <hp> fingers crossed for the screen to work in other modes than 1024x768 ,it works on livecd ,but something broke with intel driver on 4.15 on that other distro
[22:32] <Chicken_Wrap> bob98: Any progress?
[22:32] <hp> yeah running modesetting driver rn
[22:33] <bob98> Chicken_Wrap: thank you for your interest; the 18.04 system is not at my location and my client isn't able to try it right now... unfortunately...
[22:33] <tomreyn> antifa: which ubuntu version (lsb_release -ds), calibre + firefox versions (dpkg -l calibre firefox)
[22:33] <Chicken_Wrap> oof. okay.
[22:34] <bob98> Chicken_Wrap: I hope it is a NoScript issue. Other alternatives are likely to take longer to fix...
[22:35] <tomreyn> bob98: you should also have them use developer console, if just to take a screenshot, so you can compare it to yours
[22:36] <tomreyn> since there, it may well tell what got blocked and why.
[22:37] <bob98> tomreyn: where can I learn about developer console?
[22:38] <tomreyn> bob98: probably on some mozilla websites, they have a developer wiki. also around noscript documentation, i would guess. or just try it, should be available on the 'tools' menu
[22:47] <bob98> tomreyn: I assume you meant: tools>web developer>browser console ?
[22:48] <af99> is there a terminal command to boot kali alongside mint thanks for any help
[22:48] <tomreyn> bob98: yes, although sodcrtipt may have one of its own. other filtering addons do it this way.
[22:49] <tomreyn> af99: how is this an ubuntu question?
[22:50] <af99> sorry im new to irc i can retry in mint chat
[22:50] <bob98> tomreyn: many thanks :)
[22:50] <tomreyn> bob98: welcome
[23:01] <acebrianjuan> hello everyone
[23:01] <Chicken_Wrap> hi
[23:01] <acebrianjuan> I just installed ubuntu 18.04 on an msi laptop
[23:02] <acebrianjuan> but I have no sound at all
[23:03] <acebrianjuan> what should I do to get sound back?
[23:03] <user> I know that feeling
[23:04] <user> I have no idea. I've been without sound on this computer for months.
[23:05] <acebrianjuan> user: nah
[23:05] <acebrianjuan> hard to believe
[23:06] <user> Well, I only use it when traveling, so I get it out about twice a year
[23:07] <user> Back in kernel 3, the sound worked fine, but now in kernel 4 the headphone jack isn't showing up in pulseaudio output devices at all. All that's there is the HDMI.
[23:07] <user> So I suppose I could hook it up to a tv or something and get sound.
[23:08] <user> I tried an old pair of usb headphones, but I only got sound on one side, and I'm not sure if that's the headphones or the laptop.
[23:08] <acebrianjuan> user: oh so neither the jack is working?
[23:09] <user> The jack just isn't there, according to pulseaudio
[23:09] <acebrianjuan> well that's 50% audio
[23:09] <acebrianjuan> ;)
[23:09] <acebrianjuan> I'm gonna have to try the jack too
[23:09] <acebrianjuan> 1 sec...
[23:10] <user> Well, I've got my phone with me, so at least I can listen to youtube, but that's about all I can do with this phone.
[23:10] <adrian_1908> acebrianjuan: no devices listed in pavucontrol under configuration?
[23:10] <ColdKeyboard> Is there a how-to guide on how to clone old spin drive onto ssd with clonezilla?
[23:13] <acebrianjuan> the jack works woot! woot!
[23:15] <ColdKeyboard> Or how can I see why my Ubuntu cloned disk is failing to start gui and services/
[23:16] <acebrianjuan> adrian_1908: I haven't got pavucontrol installed
[23:17] <adrian_1908> acebrianjuan: oh ok. looks like sounds works for you already :)
[23:18] <acebrianjuan> If I open the sound options, under output devices I can see 2 devices: Digital Output (S/PDIF) - Built-in Audio and Speakers - Built-in audio
[23:18] <user> but yeah, the only think listed for my under pavucontrol configuration is various HDMI outputs
[23:18] <user> *thing, me
[23:19] <acebrianjuan> but if I unplug my headphones I cannot hear a thing comming from the speakers
[23:20] <acebrianjuan> do you guys know what might be the problem?
[23:20] <acebrianjuan> I've got the volume at max
[23:22] <user> Check the speaker volume sliders in ALSAmixer?
[23:22] <adrian_1908> acebrianjuan: so under "Built-in Audio" you selected the Profile that feeds your speakers (whatever connector/device that is)?
[23:24] <acebrianjuan> the only profile that I can choose is "Analog Stereo Output"
[23:24] <acebrianjuan> I've tried the "Test Speakers" function too
[23:24] <adrian_1908> hmm ok, that might not be right for internal speakers (of your notebook), which I presume you want. No idea then, sorry.
[23:26] <acebrianjuan> adrian_1908: what profile should appear?
[23:26] <acebrianjuan> so that I can search on the net
[23:27] <adrian_1908> acebrianjuan: no idea, i rarely use my notebook, but Analog Stereo Output would refer to the 3.5mm audio jack, which works as you found out.
[23:28] <acebrianjuan> I've read posts about re-installing alsa and they claim it works
[23:28] <acebrianjuan> I should give it a try
[23:28] <adrian_1908> did you have sound before on earlier Ubuntu versions (or different distro), or is this your first attempt with Linux on that machine?
[23:29] <acebrianjuan> the machine is brand new
[23:29] <adrian_1908> ok
[23:30] <adrian_1908> Well, MSI is pretty mainstream so I would guess they don't use sound components not supported by Ubuntu out of the box. Hopefully it's a simple fix as you say.
[23:31] <acebrianjuan> I hope so
[23:31] <acebrianjuan> I'm gonna get a system76 nex time
[23:31] <acebrianjuan> *next
[23:32] <acebrianjuan> I've spent a few days learning how to dual-boot
[23:33] <acebrianjuan> now I'll have to spend some more time with audio
[23:33] <acebrianjuan> *sigh*
[23:36] <ColdKeyboard> Okay, I didn't connect my other 4TB drive that's listed in fstab, so that's why it didn't boot up after cloning. I've connected it and now it works great!
[23:37] <acebrianjuan> thanks for the help guys
[23:37] <acebrianjuan> see you!
[23:38] <april2018> when I login with ssh my prompt looks like (1:361)# .  I then have to run  ~/.bashrc and then its back to ubuntu-dev:~#
[23:38] <april2018> how can I fix it so its fixed as ubuntu-dev:~#
[23:38] <niceguy99> hello can somone please tell me how to delete lvm information from my hard drive using ubuntu live cd so i can then installl ubuntu it is complaining it can't delete it
[23:39] <april2018> I like knowing the directory I am in sometimes I forget :-P
[23:39] <april2018> eg ubuntu-dev:/home#
[23:40] <adrian_1908> niceguy99: I don't know much about LVM, but I would recommend you launch gparted from the LiveCD and see if that gets the job done. Pretty intuitive interface.
[23:41] <niceguy99> i know there is some lv something command or somehting
[23:41] <xit> april2018: when you login via ssh, what shell are you using?  i.e. $SHELL
[23:42] <GlenK> so I just installed lubuntu.  but apparently the program I'm trying to run won't run.  so I need something or other that comes with the regular old ubuntu install.
[23:42] <GlenK> so my question, can I install the unity stuff and all that easily somehow?
[23:43] <Bashing-om> !unity | GlenK
[23:43] <adrian_1908> GlenK: which program won't run?
[23:44] <GlenK> adrian_1908: cisco's packet tracer program
[23:44] <april2018> xit: sorry I am very new to Linux i there a easy way to tell ?
[23:44] <xit> april2018: sure just type: echo $SHELL
[23:45] <adrian_1908> GlenK: is this supplied by Cisco or via the package manager? In the former case, I'd be surprised if it depended on a specific DE, so long the graphics libraries are installed.
[23:45] <GlenK> adrian_1908: supplied by cisco
[23:46] <april2018> xit: ubuntu-dev:/home# echo $SHELL /bin/bash
[23:46] <GlenK> is there no ubuntu equivalent of something like fedora's "dnf group install gnome desktop"?
[23:47] <xit> april2018: Can you try that command before your prompt is set?
[23:48] <adrian_1908> GlenK: you can install another DE through a meta-package, certainly. If you wish to use Gnome though, I would just install vanilla Ubuntu instead. Not sure how the Unity package is called, do a websearch.
[23:49] <Chicken_Wrap> GlenK: https://help.ubuntu.com/community/MetaPackages#Desktop_Metapackages
[23:51] <xit> april2018: If it still says /bin/bash, then type: gedit ~/.bash_profile        and add the text from: https://paste.ubuntu.com/p/fTBtNmd5YW/
[23:53] <april2018> thanks for the hint xit: let me try that
[23:54] <GlenK> Chicken_Wrap: so it sounds like I want to do something like "apt-get install ubuntu-desktop".  but when I try that it complains about unmet dependencies
[23:55] <Chicken_Wrap> Paste?
[23:55] <GlenK> argh.  hard to do from my vm
[23:56] <Chicken_Wrap> Use pastebinit or something.
[23:56] <Chicken_Wrap> sudo apt install ubuntu-desktop | pastebinit    works, I think. Provided you have pastebinit installed, of course. I don’t remember if Ubuntu comes with its own paste service built-in.
[23:58] <april2018> Thanks xit that did it I just had to use nano as I did not have gedit installed it seems
[23:58] <GlenK> ha, nevermind.  I just kept adding whatever dependencies it complained about to my install command and now it seems to be working
[23:59] <GlenK> haha, watch.  gonna go through all this and then packettracer still won't work
[23:59] <xit> april2018 great!  :)
[23:59] <GlenK> and I'd be fine with vanilla ubuntu, but for some reason compiz goes nuts in my vm


[00:17] <mup> Bug #1480298 changed: unknown object type "Charms" <blocker> <ci> <compatibility> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1480298>
[02:34] <perrito666> menn0: it appears memoserv is not as useful as it used to
[02:35] <menn0> perrito666: why not? I've never used it before and was just looking at its help.
[02:35] <menn0> perrito666: review is all done btw
[02:35] <perrito666> menn0: well I found you before memoserv :)
[02:35] <perrito666> it only works when people identify
[02:36] <menn0> perrito666: I did see the message when I logged in but I didn't know what is what about
[02:36] <menn0> perrito666: I only just checked now
[02:38] <perrito666> oh I see, it used to be waaay more crude
[02:38] <perrito666> iirc it was a message thrown at you upon identification
[02:41] <perrito666> menn0: are you sure about makeEnvironment in 1.24?
[02:42] <menn0> perrito666: no, I was looking at master so there's a chance it's not there in 1.24.
[02:42] <perrito666> it isnt, just checked
[02:42] <menn0> cool
[02:42] <menn0> perrito666: you could copy it back if you wanted
[02:43] <perrito666> well, Ill address all other points and if by then its still today Ill do it
[02:45] <menn0> perrito666: no problems
[02:45]  * perrito666 is running dangerously low on today reserves
[04:15] <perrito666> menn0: It is too late for me, I pushed as much as I could please take a look, re master my patch will deppend on will's one so you might need to add a seccond look at his patch pending (the one with 70 files)
[04:15] <perrito666> cheers
[04:16] <menn0> ok will look at both before I EOD
[04:16] <menn0> go to bed man!
[04:29] <mup> Bug #1461888 changed: Units stuck in agent-state: down state <juju-core:Expired> <https://launchpad.net/bugs/1461888>
[05:05] <menn0> perrito666: I see you've responded to most of the issues I raised but I don't see the pushed changes
[07:33] <voidspace> dimitern: ping
[07:34] <dimitern> voidspace, pong
[07:34] <voidspace> dimitern: do you have a minute to talk about spaces and subnets?
[07:35] <dimitern> voidspace, sure, hangout?
[07:35] <voidspace> ok
[07:35] <voidspace> stdup hangout?
[07:35] <dimitern> ok, omw
[07:54] <wallyworld> jam: i see you're looking at the doc :-) still WIP,  i need to break for dinner but will come back to it after
[07:54] <jam> wallyworld: sgtm
[09:05] <dooferlad> dimitern: hangout?
[09:05] <dooferlad> jam: ^^
[09:05] <jam> dooferlad: oops, omw
[09:49] <voidspace> dimitern: I can see you editing my work :-)
[10:15] <dimitern> voidspace, I hope you don't mind :)
[11:41] <perrito666> hey  I have http://reviews.vapour.ws/r/2297/ and its master version http://reviews.vapour.ws/r/2299/ both fixing  https://bugs.launchpad.net/juju-core/+bug/1479289 in case anyone feels like reviewing
[11:41] <mup> Bug #1479289: statushistory uses sequence, fails in multi-env state servers <blocker> <jes> <status> <juju-core:In Progress by hduran-8> <https://launchpad.net/bugs/1479289>
[11:45] <perrito666> dimitern: those are the patches you are looking for, if you think they are mergeable feel free to now I really need some sleep
[12:11] <dimitern> perrito666, ack, thanks
[13:03] <voidspace> dimitern: ping
[13:05] <dimitern> voidspace, pong
[13:05] <voidspace> dimitern: apiserver/testing/stub_network.go
[13:06] <voidspace> dimitern: if initialised with spaces sets up a few spaces, including a duplicate
[13:06] <voidspace> dimitern: the duplicate has the comment  "duplicates are ignored when caching spaces."
[13:06] <voidspace> dimitern: however, of course, AllSpaces is returning this duplicate
[13:06] <voidspace> dimitern: do you know why the duplicate is there and what the comment means?
[13:07] <voidspace> also FakeSpace only stores subnet IDs and is unable to return real subnet information - so I guess I have to expand it
[13:08] <voidspace> dimitern: if you don't know I can ask dooferlad
[13:09] <dimitern> voidspace, that whole complicated logic around caching spaces is overengineered I'm afraid
[13:10] <voidspace> dimitern: where is that done?
[13:10] <dimitern> voidspace, needs to be simplified and get rid of the cache, but that's not affecting you I guess?
[13:10] <voidspace> I can see a reference to it in apiserver/subnets/subnets.go
[13:10] <voidspace> well, the cache isn't directly affecting me I don't think
[13:10] <dimitern> voidspace, the duplicates are there to verify they are ignored
[13:11] <voidspace> dimitern: but I think I'll need some logic now in the fake AllSpaces method to ignore them there too
[13:11] <dimitern> voidspace, that sounds good to me
[13:11] <voidspace> ok
[13:11] <dimitern> voidspace, I can have a look at some point if you want
[13:12] <voidspace> and the FakeSpace will need to be more sophisticated to construct real Subnets to return from AllSpaces
[13:12] <voidspace> the FakeSpace doesn't have references to the actual subnets, just their ids
[13:12] <voidspace> but I can work my way through that
[13:14] <TheMue> aaaaaaaaaaaaaargh!
[13:14]  * TheMue slams his head on his desk
[13:16] <TheMue> whole time hunting a so far non existent failure in a test case, but introduced it himself by changing some of the test data
[13:16] <TheMue> gnah!
[13:20] <dimitern> TheMue, bad luck :/
[13:24] <TheMue> dimitern: yeah, so dumb
[13:28] <mup> Bug # changed: 1452422, 1459785, 1464335, 1466969, 1468581, 1474606, 1475271, 1477358
[13:31] <mup> Bug # opened: 1452422, 1459785, 1464335, 1466969, 1468581, 1474606, 1475271, 1477358
[13:33] <voidspace> dimitern: where does the caching stuff exist?
[13:33] <voidspace> dimitern: FakeSpace.SubnetIds seems to be unused
[13:34] <voidspace> dimitern: I'd like to replace SubnetIds with Subnets
[13:34] <voidspace> if I get rid of the SubnetIds from the test stub SetUp nothing seems to fail
[13:34] <voidspace> (nothing in apiserver anyway)
[13:34] <voidspace> so it looks like it's safe to modify
[13:37] <mup> Bug # changed: 1452422, 1459785, 1464335, 1466969, 1468581, 1474606, 1475271, 1477358
[13:37] <voidspace> no references to cache in apiserver/spaces
[13:38] <voidspace> apiserver/subnets/subnets.go has a reference to a spaces cache
[13:38] <dimitern> voidspace, yes, I only needed the ids then, so feel free to extend it as you need
[13:39] <voidspace> dimitern: but getting rid of the ids doesn't seem to cause any tests to fail
[13:39] <voidspace> I can't see where they're used...
[13:39] <voidspace> dimitern: ok, I'll proceed carefully :-)
[13:41] <dimitern> voidspace, the caching stuff is in apiserver/subnets on create
[13:41] <voidspace> dimitern: ok, thanks
[13:53] <dimitern> voidspace, TheMue, dooferlad, guys, the induction sprint will be 1-4 Sept in London; now it's being requested and we should sort the travel details as soon as we have the req num
[13:53] <voidspace> dimitern: ok
[13:53] <dooferlad> dimitern: sounds good
[13:54] <TheMue> dimitern: fine, already marked a flight at my favourite site for flight information retrieval
[13:55] <dimitern> cheers!
[13:57] <dimitern> voidspace, was August, 31 the UK bank holiday?
[13:58] <dimitern> dooferlad, ^^
[13:59] <dooferlad> dimitern: yes
[13:59] <dimitern> dooferlad, ta! added to the calendar
[14:01] <wwitzel3> ericsnow: ping
[14:10] <perrito666> well the day I decide to go cut my hair, the barber shop is closed, such is my luck
[14:15] <dimitern> jam, TheMue, (as you'll be the only ones beside me booking flights) the sprint request is approved, please sort your flights
[14:19] <TheMue> dimitern: yep, having the req num and I can book. already looked for a flight
[14:39] <jam> dimitern: TheMue: alexisb: the Sprint Request includes Monday, but I'm pretty sure we decided just Tues-Fri
[14:39] <alexisb> jam, that is my fault
[14:39] <jam> alexisb: k. just making sure I didn't miss a conversation
[14:39] <jam> I replied to your Sprint email
[14:39] <alexisb> thanks
[14:40] <dimitern> jam, I assumed the same
[14:40] <alexisb> that is what happens when you are trying to do 5 things at once
[14:40] <jam> alexisb: no harm. just getting confirmation and thanks a ton for pushing so fast on it.
[14:42] <dimitern> alexisb, yes, thanks a lot for organizing it so quickly!
[14:44] <TheMue> +1
[14:58] <voidspace> alexisb: yep, thanks
[15:05] <TheMue> alexisb: ping, hangout
[15:05] <alexisb> TheMue, heya, sorry my current meeting is running over
[15:06] <TheMue> alexisb: ok, leaving and wait until you ping me then ;)
[15:12] <dooferlad> voidspace: we don't do anything about the hotel booking, right?
[15:18] <alexisb> ok TheMue , I am jumping on
[15:18] <TheMue> alexisb: /me too ;)
[15:29] <voidspace> dooferlad: that's the usual situation
[15:29] <voidspace> bbiab
[16:33] <xwwt> mgz:  Can you join the windows call?
[16:34] <mgz> omw
[18:08] <perrito666> bbl, construction site checking :D
[18:41] <ericsnow> wwitzel3: could you give me a couple quick reviews?  http://reviews.vapour.ws/r/2301/ and http://reviews.vapour.ws/r/2300/
[19:37] <wwitzel3> ericsnow: sure, once I cut myself out of these weeds
[19:38] <ericsnow> wwitzel3: :)
[21:11] <wwitzel3> ericsnow: I have one test giving me a hard time
[21:12] <ericsnow> wwitzel3: np
[21:12] <ericsnow> wwitzel3: can I help?
[21:12] <wwitzel3> ericsnow: mind taking a look? been stuck on it a while
[21:12] <wwitzel3> ericsnow: in moonstone
[21:31] <menn0> perrito666: ping
[21:31] <perrito666> menn0: pong
[21:31] <perrito666> menn0: no, I actually found no one willing to review those
[21:32] <menn0> perrito666: for some reason your latest changes to the statushistory PR aren't showing on RB
[21:32]  * perrito666 headbutts the kb
[21:32] <menn0> perrito666: but i've looked on Github and things look good there
[21:32] <menn0> perrito666: the only problem I can see is that the tests in state/upgrades_test.go aren't checking the error return from the upgrade funcs
[21:32] <menn0> perrito666: other than that ship it!
[21:33] <perrito666> menn0: oops, I missed that?
[21:34] <menn0> perrito666: yep
[21:35] <menn0> perrito666: i'll update the review anyway and then you can start merging
[21:35] <menn0> perrito666: note that I also updated the ticket so that both master and 1.24 series are shown
[21:35] <perrito666> menn0: I seem to have missed that in only one
[21:36] <perrito666> menn0: I did see the email pass
[21:37] <perrito666> well for a bug fix that was a big patch
[21:39] <menn0> perrito666: review updated
[21:40] <menn0> perrito666: that happens :)
[21:45] <perrito666> menn0: $$merged$$ now lets wait
[21:45] <perrito666> sometimes I reall miss subversion where I could do tests/commits while working in something else
[21:46] <perrito666> menn0: how do you feel about repeating the hit with http://reviews.vapour.ws/r/2299/
[21:46] <perrito666> you will have to look at ghub too
[21:48] <perrito666> while you where not here fwereade's large patch was merged
[21:54] <menn0> perrito666: rather than having to review the whole thing again, can you point me at the parts where you had to make significant changes?
[21:55] <perrito666> menn0: finally I did not do any change, the only sifnificant differences is megawatcher became allwatcher (but the file contents did not change) and makeEnvironment was already there
[21:56] <menn0> perrito666: well in that case, just merge away
[21:57] <perrito666> seems the bot is a bit lazy today
[23:00] <axw> alexisb: will be a couple of mins
[23:00] <alexisb> axw, no worries
[23:01] <alexisb> wait I should so no wuckers
[23:02] <alexisb> thumper, menn0, cherylj can you all please make sure that bug https://bugs.launchpad.net/juju-core/+bug/1481368 gets updated with the latest status and your eod
[23:02] <alexisb> it is being closely tracked
[23:05] <thumper> ack
[23:36] <perrito666> Both patches for https://bugs.launchpad.net/juju-core/+bug/1479289  have landed (and include in them the uncommente test that caused the bug report in first place, working)
[23:36] <mup> Bug #1479289: statushistory uses sequence, fails in multi-env state servers <blocker> <jes> <status> <juju-core:Fix Committed by hduran-8> <juju-core 1.24:Fix Committed by hduran-8> <https://launchpad.net/bugs/1479289>
[23:43] <perrito666> bbl dinner
[23:52] <thumper> hmm...
[23:52] <thumper> is archive.ubuntu.com down for anyone else?
[23:53] <thumper> hmm...
[23:53] <thumper> apt-get update inside my container is having issues
[23:57] <anastasiamac> thumper: i can reach archive.ubuntu.com


[00:15] <poolie> hi jam
[00:29] <jam> hi poolie, I tried calling earlier
[00:31] <poolie> hi there
[00:31] <poolie> want to talk now?
[00:36] <jam> sure
[00:36] <jam> espec if we can make it quick
[00:38] <poolie> give me a call?
[01:16]  * maxb uploads the fourth try at 2.3b2 to beta ppa :-)
[01:20] <lifeless> 2.3b2.4?
[01:20] <lifeless> could be a confusing version number
[01:44] <lool> slangasek: pong
[01:44] <slangasek> lool: hi - sorted now, no worries :)
[01:45] <lool> slangasek: Ok; sftp to what branch?
[01:45] <lool> slangasek: Ok  :)
[01:50] <maxb> ugh, failed test again
[01:59] <maxb> Here goes 2.3.0~beta2-1~bazaar1~maverick5, may it have better luck than the last 4
[02:39] <poolie> hi spiv?
[02:39] <spiv> poolie: hi poolie
[02:39] <spiv> I'm nearly done with split-NEWS
[02:39] <poolie> cool
[02:39] <spiv> Just writing up docs on how to start a new release with it, which of course reveals improvements I should make to that process :)
[02:40] <spiv> Or rather, how to start a new series.
[02:43] <maxb> yay successful build
[02:45]  * spiv -> lunch
[02:51] <maxb> So, fixes to make the testsuite work on the buildds.... should I target those at 2.2? 2.1?
[02:51] <poolie> i'd say 2.2, or maybe even only trunk
[02:51] <poolie> how likely is it to have adverse consequences?
[02:56] <maxb> Very little, given I only touch setup.py and test code
[02:56] <maxb> And actually, having touched the test code, I don't technically need to touch setup.py
[02:57] <poolie> 2.2 sounds good then
[02:57] <poolie> could you nag or whatever the sru team?
[02:58] <maxb> Do we actually have test results in the bug yet?
[02:58] <maxb> Also, perhaps I should target my test fixing into 2.1, in case we want to SRU lucid again
[04:39] <peitschie> spiv: are you around?
[04:49] <spiv> peitschie: I am, yes
[04:49] <peitschie> spiv: was just wanting to quickly check if you'd heard anything regarding the data we were playing with yesterday?
[04:50] <spiv> I think jelmer & jam have basically identified the cause
[04:50] <spiv> What remains is to figure out what to do about it :)
[04:50] <peitschie> oh!  that was quick!
[04:51] <peitschie> is it likely to be a difficult thing to fix?  I ask as i'm being pushed to decide if we do branching in svn... or whether we can continue with bazaar
[04:51] <peitschie> tho i'd love to stay with bzr for the project... this bug in particular is causing mega hassles trying to get changes committed back to svn, or merge changes in from svn :S
[04:54] <spiv> I'm not sure, I don't think I've seen the full discussion between jam and jelmer.  It's related to what happens after a ghost is filled in.
[04:55] <peitschie> ah k :)... sounds like it might be safest to let the project do the branching in svn... then i'm not under time pressures (or emotional pressures!) for this to get fixed immediately
[04:55] <spiv> It sounds like there needs to be some clarification/decision about precisely what bzr's expectations are there (so that bzr-svn can meet them), but also how to do that in a way that is as useful as possible.
[04:55] <peitschie> yes... thats understandable.  bzr-svn does seem to be the cutting edge of ghost handling in bzr world
[04:56] <spiv> Yes, it seems so!
[04:57] <spiv> It seems likely that there is a corebzr issue here, but bzr itself doesn't tend to make it easy to create ghosts.
[04:57] <spiv> They in practice tend to come from imports/conversions from foreign systems.
[04:57] <peitschie> yes... i had noticed that a lot of core bzr seemed to struggle with ghosting in various ways... though the most recent version definitely has been a huge improvement
[05:00] <peitschie> either way... i'm very gratified to hear the probable cause was found!
[05:03] <spiv> Me too:)
[05:40] <poolie> hi spiv,
[05:40] <poolie> when you're done with news could you look at james's bug 653307?
[05:42] <spiv> Sure.  Another one :/
[05:58] <chx>  never know whether  diff -r 17210..17200  include 17200 and 17210 or not
[05:58] <chx> does it or not...?
[05:58] <poolie> chx: it names two trees
[05:58] <poolie> the one committed by 17210 and the one committed by 17200
[05:58] <poolie> and it gives the diff between them
[05:58] <chx> that does not help me :)
[05:58] <chx> does it include the differences introduced in 17200?
[05:58] <poolie> so it excludes the first and includes the right
[05:59] <poolie> stewart: want to be  a bzr-stats maintainer?
[05:59] <stewart> poolie, sure.
[05:59] <poolie> :)
[06:00] <poolie> congrats
[06:00] <stewart> poolie, next thing i was going to add was some extra mapping of email addresses to the same people... the mysql tree is rather chaotic with what people committed as.
[06:00] <poolie> by all means still ask for reviews
[06:00] <poolie> but now you can merge them yourself
[06:02] <chx> poolie: so it exclude 17200 and includes 17210?
[06:03] <chx> poolie: that sort of "includes the first" sitll does not help me :(
[06:05] <chx> poolie: yes. it does. i see. i do not understand at all.
[06:05] <chx> poolie: but i see.
[06:05] <stewart> poolie, great.
[06:07] <chx> poolie: thanks
[06:09] <poolie> chx it's easier if you remember that the numbers are assigned when you commit, after you finish changing the tree
[06:09] <chx> poolie: i still do not understand a word. what tree?
[06:09] <chx> anyways, back in ten.
[07:25] <vila> hi all !
[07:33] <peitschie> hi villa
[07:33] <peitschie> *vila
[07:34] <vila> _o/
[07:40] <peitschie> thats the cutest wave eva lol
[07:41] <vila> \o_ \o/ _o/ _o_ hop hope morning exercise
[07:41] <vila> s/hope/hop/ typo
[07:42] <poolie> hi there vila
[07:42] <poolie> i'm trying to work out if we actually agreed on not having rcs
[07:43] <vila> Seen  my last comment on the review ? I misremember ?
[07:43] <vila> It seem I fail to reach agreement for even the tiniest details these days :(
[07:44] <poolie> ah, it's ok
[07:44] <poolie> isn't my graph nice? :)
[07:44] <vila> I believe the agreed plan is that we will do an API freeze in the last
[07:44] <vila> beta, then make a 2.3 branch, then release 2.3.0 directly off that
[07:44] <vila> branch, then possibly a 2.3.1 etc into Natty.  rcs are unnecessary
[07:44] <vila> overhead since the final source is normally good.
[07:45] <vila> straight from your mail
[07:45] <vila> Message-ID<EMAIL_ADDRESS>[07:45] <vila> and indeed part of the [RFC] Releases planning thread
[07:46] <vila> graph.. which graph ? :)
[07:46] <poolie> "less open bugs"
[07:50] <vila> wow fix vs confirmed... amazing
[07:51] <poolie> and it's really pulled ahead the last few months
[07:51] <vila> Wow in progress decreasing, excellent. I still need to purge my queue...
[07:52] <vila> the 1700 figure is also interesting to compare with the one reported by fixed-in (~1142 or something)
[07:52] <vila> I'm not sure I de-dupe in fixed-in  for that matter
[07:58] <spiv> A loosely related graph I find interesting: http://webnumbr.com/active-bzr-branches-on-lp
[07:59] <spiv> Which is climbing, but perhaps indicates more that LP's classification of "active" is incorrect than anything else.
[08:00] <vila> https://code.edge.launchpad.net/ubuntu is still surprising to me
[08:01] <vila> but indicates a strong activity nevertheless
[08:03] <ddaa> are those all native lp hosted bzr branches?
[08:03] <ddaa> or some kind of automated churn?
[08:09] <spiv> vila: ta, created http://webnumbr.com/bzr-branches-for-ubuntu ;)
[08:09] <spiv> (although sadly the point-and-click thingy failed and I had to go read some xpath docs)
[08:10] <vila> spiv: great thanks !
[08:12] <vila> ddaa: who knows...
[08:13] <CcxCZ> so when is next stable release planned? (whether I should bother publishing ebuild w/ py2.7 fix)
[08:15] <vila> CcxCZ: are you subscribed to the bazaar ML ?
[08:16] <CcxCZ> nope
[08:16] <CcxCZ> is it on gmane?
[08:17] <vila> I think so
[08:17] <spiv> http://news.gmane.org/gmane.comp.version-control.bazaar-ng.general I think
[08:17] <vila> The topic is under discussion, and two points are relevant for you if you're involved in gentoo packaging
[08:18] <CcxCZ> I'm not an official packager, I just try to fix bugs when I bum pinto them
[08:18] <vila> CcxCZ: One is that it would be very nice to know which bzr/plugins versions are carried (any gentoo command to get that updated will be awesome)
[08:19] <vila> the other is that https://edge.launchpad.net/bzr/+series is supposed to be the most up-to-date source for release dates
[08:20] <vila> as far as 2.3 is concerned, we expect to release it next February
[08:20] <vila> for 2.2 we say 2.2.2 should be released 2010-11-18 but I think that would be later (we will release it *iff* we encounter critical bugs)
[08:21] <vila> CcxCZ: what fix are you referring to ?
[08:22] <CcxCZ> launchpad/xmplrpc
[08:23] <vila> do you have the bug number ?
[08:23] <CcxCZ> wait, I'll get it
[08:25] <CcxCZ> https://code.launchpad.net/~toshio/bzr/python27-lp-fix/+merge/35487
[08:25]  * vila cries lp in maintenance mode
[08:26]  * ddaa hands vila a tissue
[08:26] <ddaa> careful with the faux-amis :-)
[08:27] <vila> CcxCZ: let's try again later, but what I'm trying to understand is whether the fix has landed in the 2.2 branch or not and whether you are backporting it to 2.2.1 in gentoo only or use the lp:bzr/2.2 branch
[08:27] <vila> ddaa: cries is not about crying ?
[08:27] <vila> with tears of blood ?
[08:27] <vila> :)
[08:28] <ddaa> ah okay, I assumed you merely meant "shouts" :-)
[08:28] <vila> ddaa: nah, I use ALLCAPS when shouting but I alsmot never shout for work related problems, I keep that for private stuff and even there...
[08:28] <CcxCZ> no, I had to apply the patch to 2.2.something
[08:29] <vila> CcxCZ: err, so you mean you backported it to gentoo only right ?
[08:29] <CcxCZ> backported it to my personal gentoo overlay, yes
[08:31] <CcxCZ> 2.2.1 it was I think
[08:33] <vila> CcxCZ: ok, so excuse my poor gentoo knowledge here, but will this patch find its way to the 'official' gentoo distro ?
[08:34] <vila> CcxCZ: I'm trying to understand how we could reduce the overall work here and whether we should apply your patch to the lp:bzr/2.2 branch or not
[08:35] <vila> ha, lp is back, so the fix has landed in 2.3b2 already
[08:36] <CcxCZ> nope, unless I convince the dev he should add it, so I came here to check whether I should bother to do so, or should I just wait for next release
[08:38] <vila> CcxCZ: ok, hmm, right, I see the patch now, definitely not critical so unlikely to get backported to 2.2,
[08:39] <vila> CcxCZ: I think that answers your question: it will be available in 2.3 only
[08:39] <vila> CcxCZ: now, do you know a way in gentoo to get which bzr/plugins versions are installed ?
[08:40] <CcxCZ> gtg now, back in few minutes, kay?
[08:40] <vila> CcxCZ: Sure !
[08:40] <spiv> vila: I don't think 'critical' is precisely the criteria for a backport to a stable branch
[08:40] <spiv> It's more 'is the benefit worth the risk (and effort)?'
[08:41] <spiv> So a medium importance bug that has an utterly safe fix would be a good candidate for a backport, for instance.
[08:41] <vila> spiv: that doesn't really fly with the SRU policy, but it seems I can't summarize this sort of thing so feel free to amend our doc on the subject
[08:42] <spiv> vila: I believe it does fit the SRU policy
[08:43] <spiv> "# Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)."
[08:43] <spiv> Especially as part (1) is bolstered by our large automated test suite.
[08:43] <spiv> It also fits with what I recall poolie saying in the past.
[08:44] <vila> spiv: I'm not the one that needs to be convinced... my understanding of the current situation is that 2.2.1 is still not in maverick-updates
[08:45] <spiv> That's more to do with a smooth, effort-free path for getting our stable micro releases into -updates than anything else though, isn't it?
[08:45] <vila> spiv: and for this particular case, unconditionally overriding the python implementation is a risk to miss more 2.7 fixes
[08:46] <spiv> (And making our test suite pass in the package build environment helps create that smooth path)
[08:46] <spiv> vila: haha 2.7 fixes
[08:46] <spiv> vila:
[08:47] <spiv> 2.7 is already being handled more conservatively by upstream than previous 2.x releases for updates, because they don't plan any more 2.x at all.
[08:48] <vila> right, more conservatively in this case still means they broke 2.6 compatibility...
[08:49] <spiv> Right, but this fix is fine on 2.6 too
[08:49] <vila> ... which I won't remember in 6 months
[08:50] <spiv> Well, to be less abstract: I think the risk that this specific workaround for 2.7 might cause problems later is pretty low.
[08:51] <spiv> And if a future 2.7 does break it, and passes the SRU process for maverick-updates, then I'm sure a corresponding fix for bzr would be accepted for maverick-updates too :)
[08:52] <spiv> We should get the python package build to pass bzr's test suite too, not just the bzr package ;)
[09:01] <CcxCZ> vila: I'm back but I'm not sure I understand the question. Plugins (except for launchpad) are packaged as normal gentoo packages: dev-vcs/bzrtools, dev-vcs/bzr-svn, ...
[09:03] <vila> CcxCZ: I only have a basic knowledge of gentoo, so this may be obvious to you, I'd like to know what command or series of commands I should use to get the plugin list and their associated versions
[09:05] <CcxCZ> bzr version / bzr plugins seems best to me :-) but I just used `equery list -f 'bzr'` to get all packages with 'bzr' in name
[09:06] <CcxCZ> note that equery is in gentoolkit package and not installed by default
[09:06] <CcxCZ> vila: what do you need it for?
[09:09] <vila> CcxCZ: doh, good point on  bzr version / bzr plugins :-D
[09:10] <vila> CcxCZ: I need it to get a distro point of view about what is packaged
[09:10] <vila> CcxCZ: but bzr version/plugins may do it, I need to make sure my setups don't interfer here
[09:11] <vila> which BZR_PLUGIN_PATH=+site:+core should do
[09:12] <vila> CcxCZ: sounds like a very good plan, portable, easy to explain, usable by anybody, excellent
[09:13] <CcxCZ> equery belongs -f '/usr/lib(64)?/python.*/site-packages/bzrlib/.*'
[09:13] <CcxCZ> should search for packages that installed files matching regex
[09:14] <CcxCZ> since gentoo ebuilds are usually written in version-agnostic way, the version numbers should match
[09:21] <vila> CcxCZ: ok, so both commands (and bzr version/plugins too for that matter) tells me about *installed* packages (and my VM only has bzr itself installed)
[09:21] <vila> CcxCZ: is there a variant that can tell me about plugins that *can* be installed ?
[09:24] <CcxCZ> not really, because ebuilds don't have any identificator marking it as 'bzr plugin', but equery list -pf 'bzr' should give you an idea (or -pof if you want to search overlays)
[09:25] <CcxCZ> or you can use online tool http://gpo.zugaina.org/Search?search=bzr
[09:26] <vila> CcxCZ: some result: only bzr-2.2.0
[09:26] <vila> ha, let me try that
[09:28] <vila> CcxCZ: hmm, from http://gpo.zugaina.org/dev-vcs/bzr-git, 'gentoo' is the official and 'funtoo' an overlay ? What is bzr-git-9999 ?
[09:29] <CcxCZ> 9999 means current head is pulled from developers' vcs
[09:29]  * spiv wonders what happens if the branch has more than 9999 revisions...
[09:30] <vila> ha, and the Overlay: bazaar (layman) just has no icon right ?
[09:30] <CcxCZ> use gentoo-portage.com to see only normal portage
[09:30] <CcxCZ> spiv: it's bumped with some nines :-)
[09:30] <CcxCZ> there are packages like that
[09:31] <CcxCZ> (they use date as version number iirc)
[09:31] <spiv> CcxCZ: heh :)
[09:33] <vila> CcxCZ: excellent, I think gentoo-portage.com is a good starting point for me now
[09:33] <vila> for me for now ?
[09:34] <vila> CcxCZ: so http://gentoo-portage.com/dev-vcs/bzr says that 2.0.1, 2.0.4, 2.2.0 and 2.2.1 are available right ? (As in the user can decide which one is installed)
[09:36] <CcxCZ> note the keywords: 'arch' means stable, '~arch' means testing (for now)
[09:37] <vila> CcxCZ: I was about to ask :)
[09:38] <vila> CcxCZ: weird, http://gentoo-portage.com/Search?search=dev-vcs%2Fbzr doesn't mention qbzr even if http://gentoo-portage.com/Search?search=qbzr says it's part of dev-vcs...
[09:39] <vila> CcxCZ: anyway, food for thought, thanks for the juicy pointers ;)
[09:39] <CcxCZ> also you may want to read this: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3
[09:40] <CcxCZ> maybe http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2 before that
[09:41] <vila> CcxCZ: thanks
[09:41] <CcxCZ> vila: the uri you posted searches for dev-vcs/bzr* but qbzr is dev-vcs/qbzr
[09:42] <vila> ha, implicit globs...
[09:43] <vila> we should lobby the qbzr devs to switch to bzrq :) I'm sure they will love the idea :D
[09:45] <CcxCZ> substring search raher than glob, but whatever :-)
[09:48] <vila> CcxCZ: indeed: http://gentoo-portage.com/Search?search=bzr is the best fit
[09:48] <vila> net-libs/libzrtpcpp  is irrelevant but fun anyway :)
[09:52] <vila> http://packages.gentoo.org/category/dev-vcs?full_cat is a good summary too, even if I don't understand everything there :)
[09:53] <jelmer> yeah, libzrtpcpp always comes up in searches for bzr in debian/ubuntu as well :-)
[10:13] <CcxCZ> vila: just msg me if you need anything gentoo-specific
[10:14] <vila> CcxCZ: ok, thanks !
[14:19] <sender> jelmer: hi, are you available? :)
[14:22] <jelmer> sender, hey
[14:22] <jelmer> sender, I'm at work at the moment, I can help later tonight though
[15:45] <mgz> launchpad seems slow today. making lots of nutty packages?
[15:46] <mgz> *natty
[15:47] <vila> naughty ?
[15:48] <mgz> very.
[15:51] <mgz> wonder if I can find a big enough chunk of time today to look at hooks...
[15:52] <vila> don't tell me :-/
[15:55] <rubbs> I created a repo and one of my devs can not add a .bzrignore file. He's in the group that owns .bzr dir and it's mod'd to 775 at this point. am I missing something? bzr: ERROR: Cannot lock /home/httpd/smackemyackem.com/dev/.bzr/checkout/dirstate: [Errno 13] Permission denied: u'/home/httpd/smackemyackem.com/dev/.bzr/checkout/dirstate'
[15:56] <Glenjamin> sounds like something inside .bzr isn't owned by him
[15:57] <vila> rubbs: mod'd -R ?
[15:58] <jam> morning vila
[15:58] <vila> jam: morning !
[15:58] <rubbs> yeah. I'm bombing the whole thing and running again. It's possible I missed something, and this is more for instructional purposes.
[15:59] <rubbs> It's possible I have an odd sticky bit set up or something
[15:59] <vila> /home/httpd implies this is also served via http ? As such it's owned by the web user ?
[16:00] <vila> nah, www user or whatever is used for your install
[16:00] <rubbs> also I had one other quick question. My devs like to connect to the dev server with this: http://www.expandrive.com/windows It's basically sshfs for windows. Would this cause problems if their working tree is on the sshdrive, but they are working in windows? with a windows version of bzr?
[16:00] <vila> ouch
[16:00] <rubbs> vila: /home/httpd in this case is misleading. it's not a web directory at this point.
[16:01] <rubbs> mostly being used as an "example" to teach bzr
[16:01] <vila> there have been problems with sshfs in the past about renames and locks (not sure about locks)
[16:02] <rubbs> ah, and originally we had a lock problem. I think I manually fixed that.
[16:02] <vila> I *used* to work with sshfs, I still use nfs a bit, but as a rule... mounted file systems are more trouble than benefits IME
[16:02] <rubbs> k
[16:02] <rubbs> so maybe I should have them pull things locally and bind to the dev machine.
[16:02] <vila> that being said, we support it AFAIK
[16:02] <vila> rubbs: yup
[16:02] <rubbs> k
[16:03] <rubbs> thanks for all your help/advice. I'll have to check into a few things
[16:03] <vila> maxb: yeehaa for the beta-ppa !
[16:05] <vila> maxb: does this mean the tests are running there ? For bzr only or did you try for some plugins too ?
[16:05] <vila> maxb: did you remove the install-related failing one ?
[16:08] <vila> mgz: was your lanchpad remark about 'updating diff' ? Because I see that right now for two mps of mine
[16:08] <vila> mgz: and it's more than slower than normal...
[16:08] <mgz> yeah, and slowness of sending out email too.
[16:10] <mgz> ha, funny indentation error, wonder who the blame is on
[16:12] <mgz> wow, that's ancient. vila from rev 2900?
[16:12] <vila> me ? Can't be. blame emacs :)
[16:12] <vila> where is that ?
[16:13] <mgz> well it's you or jam from rev 1185
[16:13] <mgz> bzrlib\config.py line 965
[16:13] <mgz> causes this:
[16:13] <mgz> http://babune.ladeuil.net:24842/job/selftest-windows/lastFailedBuild/testReport/bzrlib.tests.test_config/TestIniBaseConfigOnDisk/test_reload_see_new_value/
[16:15] <vila> wow indenting the first mkdir address that ?
[16:15] <vila> and it never failed before on windows ???
[16:16] <jam> vila: I would imagine that the first time we have to mkdir 2.0 we have to mkdir the parent dir
[16:16] <jam> and we never have a case where one-but-not-both needs to be created
[16:17] <vila> which reminds me that I never really grok that code, what if we need to create more than 2 parents ?
[16:18] <vila> mgz: revno 2900... was only fixing a module.symbol :)
[16:18] <mgz> it was 2900.something, does qblame have a mainline revs only option somewhere?
[16:19] <vila> mgz: dunno, but in the file graph window you have a contextual menu including show file differences
[16:19] <mgz> anyway, it's an easy fix to get us down to 4 failures on windows babune +- random sftp failures
[16:20] <vila> shoot !
[16:20] <mgz> and I think I've got bugs on the remaining ones too.
[16:20] <vila> random as in ?
[16:21] <mgz> oh, maybe not the test_unicode_bzr_home one, the error on that changed recentlyish
[16:21] <mgz> as in, sometimes they fail, sometimes they don't
[16:21] <vila> haha
[16:21] <vila> but *how* do they fail :)
[16:22] <jam> vila: well, the changes that AppData don't exist are pretty much NIL...
[16:22] <vila> I see so many different spurious failures that I kind of lost track sometimes
[16:22] <jam> but yes, it could be turned into an os.makedirs()
[16:22] <jam> it is pretty old code
[16:22] <mgz> with PermissionError but if we're lucky fixing your transport cleanup with fix those too
[16:23] <vila> jam: not throwing stones (or I should throw them at myself) as I was never able to run these specific tests when I was looking at the code
[16:23] <mgz> http://babune.ladeuil.net:24842/job/selftest-windows/196/ <- see two new sftp failures hiding the fact I just fixed two tests
[16:23] <mgz> ^I think that config code is fine bar the missing indent
[16:24] <mgz> ...is it worth adding a test just for this... hmmm... nah.
[16:24] <vila> mgz: no ! We already have a failing test !
[16:24] <mgz> righty.
[16:26] <vila> http://babune.ladeuil.net:24842/job/selftest-windows/189/testReport/bzrlib.tests.test_bundle/TestReadMergeableFromUrl/test_smart_server_connection_reset/ is surprising, we don't translate the exception correctly ?
[16:27] <mgz> that's bug...
[16:27] <vila> err, sry for the url in an old build, I just check it has been failing consistently for a while
[16:27] <mgz> bug 581311
[16:27] <mgz> see comment #1 for my thinking.
[16:28] <mgz> I'm not completely certain just wrapping the error is right.
[16:28] <vila> just reading
[16:29] <vila> I don't remember if we reconnect automatically on CONNRESET, but if we do, then I see no reason to not do it too for CONNABORTED
[16:30] <vila> does CONNABORTED exist on *nix ?
[16:31] <mgz> yup.
[16:32] <mgz> errno.ECONNABORTED on nix.
[16:34] <mgz> now gmail has decided to be pants as well as launchpad. will someone please unbreak the internet?
[16:34] <vila> sudo repair internet
[16:35] <Kinnison> This incident has been reported to your systems administrator.
[16:41] <vila> :)
[16:42] <Glenjamin> Does anyone else run bzr smart over HTTP+WSGI?
[16:43] <Glenjamin> i've been getting some weird errors lately, which have mostly been fixed by disabling the pyrex-built C extensions. I reported one, but haven't really had time to sit down and make reproducible test cases
[16:43] <Glenjamin> (as i need to make my server work :))
[16:43] <vila> mgz: the only explanations I can find about ECONNABORTED only mentions the *server* side and it occurs if the client close the socket between the listen() and the accept()...
[16:43] <mgz> Glenjamin: I have done, but found it's pretty much always worse than just http
[16:43] <mgz> unless you really need push, and then I don't really trust it to be correct
[16:44] <Glenjamin> mgz: writeable with access controller by ldap (through apache)
[16:44] <mgz> ^right, I don't think we expect to be hitting it under unix semantics, but winsock is slightly different
[16:45] <vila> mgz: all in all, I think we shouldn't care and just process it as a CONNRESET
[16:46] <vila> mgz: the specific error code is raised only on windows anyway
[16:46] <mgz> okay, but then do we only catch the windows varient?
[16:46] <mgz> can bzr use ldap directly?
[16:47] <vila> mgz: your call, if you can write the associated tests with sufficient precision :-P i.e. just *add* the windows specific one on windows, who knows if/when someone will ever unify them...
[16:53] <Glenjamin> mgz: it could actually, but there's not really a clean place to slot in smart-server authentication
[16:53] <Glenjamin> and/or access control
[16:54] <Glenjamin> Aside from "just use ssh", which in most cases is a good solution
[17:08] <Glenjamin> with a short nickname on a remote master branch, and then doing "bzr nick" on a local bound branch, I'm getting part of the progress bar left over
[17:13] <Glenjamin> and can't reproduce on loggerhead :<
[17:13] <Glenjamin> *launchpad even
[17:14] <vila> Glenjamin: with which bzr version ?
[17:15] <vila> Glenjamin: whatever, file a bug, poolie has fixed quite a few in this area and is definitely the one to talk to about it
[17:15] <Glenjamin> 2.1.1 on ubuntu
[17:15] <Glenjamin> i'll try an upgrade first
[17:16] <vila> wow, yes, try an upgrade
[17:16] <vila> Glenjamin: still on lucid ? Try maverick :-D
[17:16] <Glenjamin> LTS :)
[17:16] <vila> Glenjamin: use the stable ppa !
[17:16] <vila> :D
[17:16] <Glenjamin> don't upgrade servers that aren't broken!
[17:17] <Glenjamin> we do, but we don't update packages very often
[17:17] <vila> Glenjamin: you just said it was broken ! (Ok, I stop :)
[17:17] <Glenjamin> dunno why I didn't try that first, it's fixed
[19:40] <dev001> @ a 'bzr  multi-pull' in my system_wide_plugins dir, i'm, today, getting a bunch of " ... minimum exported version ..." errors: http://pastebin.com/6YN3sGxw.  Some, not all, of my pulls are failing.  What to do here?
[19:44] <jelmer> dev001, is that repeatable? I mean, after you've done that multi-pull don't most errors go away?
[19:46] <dev001> jelmer: hm.  took three iterations, but, yes ... the errors are all gone now.  anything to worry about ?
[19:47] <jelmer> dev001: no
[19:47] <dev001> jelmer: that's what i like to hear :-) thx.
[22:21] <metaperl> hello... it seems that bzr has the concept of revision (http://wiki.bazaar.canonical.com/MatthewFuller/SpotDocs/PiecesInBrief)  by default which means it's fairly easy to track back in history ... that seems to be missing from git unless you manually do some sort of tagging of each commit?
[22:28] <maxb> metaperl: revision == commit, more or less. I don't understand what difference you are seeing
[22:30] <metaperl> maxb:  it may just be my inability to use github, but I have problems moving back in time to find a file that is no longer in my repository. that being said, I just browsed around on launchpad and tried to move through various revisions of the bzr source and did not find that straightforward either. I might be better off with the old school svn
[22:31] <maxb> hah!
[22:31] <maxb> I don't think it's any easier there
[22:39] <poolie> hi maxb, jam
[22:41] <mgz> what's the easiest way of creating a working tree with bzr over sftp?
[22:42] <poolie> bzr-upload?
[22:42] <poolie> fix wts to work over transports? :)
[22:42] <poolie> i've been meaning to do that for years :/
[22:42] <mgz> heh. I read the note in the push docs, and thought someone might have already done it.
[22:43] <peitschie> morning everybody
[22:45] <mgz> is that bug 606249 or is there also an earlier one poolie?
[22:47] <poolie> i don't see why it would actually be all that hard
[22:47] <poolie> it is that one, but i wouldn't be surprised if there's an equivalent old bug
[22:48] <mgz> bug 44663 also talks about the restriction but isn't about lifting it
[22:51] <poolie> mgz i think basically we just need to audit for the places it uses local directory access
[22:51] <thumper> abentley: bzrtools is bitching about versions
[22:51] <thumper> abentley: just a FYI
[22:51] <poolie> check all those capabilities are supported by transports, or update them if not
[22:51] <poolie> make sure that it doesn't get substantially slower using a localtransport
[22:52] <poolie> (which is basically an aspect of the previous point)
[22:55] <mgz> all sounds doable.
[22:55] <jbowtie> Just pinging for feedback on my new sphinx theme ( http://lists.ubuntu.com/archives/bazaar/2010q4/070526.html )
[22:55] <mgz> I like it bar the orange.
[22:56] <mgz> I'm not convinced by the ubuntu font for paragraph content, but it's nice for headlines.
[23:00] <jbowtie> I'm kind of punting on the color selection until I see the proposed overhaul of the main site - I know someone has been working on it.
[23:00] <jbowtie> But I think we really need to bring the main site, wiki, and documentation together visually.
[23:02] <jbowtie> mgz: I could dial back on the ubuntu font for para content, but it actually looks great in print. I'll take a fresh look in a couple of weeks when I'm less besotted with it.
[23:03] <mgz> yeah, that's worth doing. twas, emmajane? that did a rehaul of the main site last yearish, I'm not really sure more big changes there are a good plan, but tightening everything up would really help.
[23:03] <jelmer> 'morning poolie, mgz, jbowtie
[23:04] <mgz> hey jelmer.
[23:04] <mgz> ...just about to ask you about a bug, but launchpad is going down so I'll leave it for next time I remember.
[23:07] <poolie> hi there jelmer
[23:07] <peitschie> mornin jelmer
[23:08] <jbowtie> Hi jelmer - it seems to me bzr-svn never has to deal with branch divergence; do you have some magic code that prevents that?
[23:09] <jbowtie> Every time I commit from bzr-tfs subsequent pulls complain about branch divergence for some reason, trying to track that down.
[23:10] <jelmer> mgz: Ah, yep - I guess it's time for our new release. :-)
[23:10] <jelmer> hi peitschie
[23:11] <jelmer> jbowtie: bzr-svn sets the branch tip manually when pulling, it has its own code to notice branch divergence
[23:11] <jelmer> jbowtie: Which methods are you overriding exactly?
[23:16] <jbowtie> jelmer: For branches, just pull and is_compatible
[23:17] <jbowtie> Most of the stuff I'm doing is in the repository classes.
[23:17] <jelmer> jbowtie: Branch.pull() or InterBranch.pull() ?
[23:18] <jbowtie> jelmer: GenericInterBranch.pull() - don't really have a TFS-native representation due to silliness in TFS workings.
[23:19] <poolie> hi jbowtie
[23:20] <jbowtie> hi poolie, thanks for the feedback on the binary diff/merge stuff.
[23:20] <poolie> you're welcome, thanks for tackling it
[23:21] <poolie> i can see the point about just handling big files well but it's not really either/or
[23:23] <jbowtie> I agree, but fixing big file support is likely a harder problem - need to rethink repository format for that one.
[23:25] <jbowtie> I've also got plans for .xcf files as well - my real driver - but I think tackling archives first will cover a much wider array of use cases.
[23:30] <jbowtie> jelmer: Do you know where the branch tip is being set in bzr-svn?  I'm not seeing anything obvious in branch.py
[23:31] <jelmer> jbowtie: It should be in InterBranch.update_revisions(), look for a call to self.target.generate_revision_history()
[23:36] <jbowtie> jelmer: Found it, thanks. Looks like it is exactly the chunk of logic I need to implement to fix my bug.
[23:37] <jelmer> jbowtie: Great. :-)
[23:38] <jelmer> jbowtie: Btw, I was wondering whether it was possible to use bzr-tfs against codeplex.com, apparently it runs a Team Foundation Server. Have you tried that?
[23:40] <jbowtie> jelmer: I have not tried that yet, I suspect they're running TFS 2010 which bzr-tfs doesn't support yet (though someone submitted a patch I need to review)
[23:40] <jelmer> jbowtie: They have a broken (what I assume is a) tfs-to-svn bridge, which is causing strange errors when bzr-svn is used against it.
[23:40] <jelmer> jbowtie: Ah, ok.
[23:42] <jbowtie> jelmer: I'll have a look at supporting that once I've fixed the disappearing revision bug (revisions make it to the repository but not the branch)
[23:42] <GungaDin> when cherry picking, will there ever be a way to track history of these revisions in the future? or is it now just like a regular merge of the deltas?
[23:42] <GungaDin> or the text?
[23:42] <jbowtie> Which is, you know, kind of an issue...
[23:45] <jbowtie> GungaDin: Tracking cherry picks is something on the roadmap for the future. See http://wiki.bazaar.canonical.com/CherryPick
[23:46] <GungaDin> but when it's done in the future, will it possible for cherry picked revision in the past?
[23:46] <dash> bzr, the global causality violating VCS
[23:47] <peitschie> lol
[23:47] <fullermd> Causality?  Bah.  What did it ever do for me?
[23:49] <jbowtie> GungaDin: I assume not, but that depends on how it is ultimately implemented. With a cherry-pick we currently preserve the revid but not the ancestry.
[23:49] <jbowtie> In theory you could reconstruct the ancestry via repository forensics.
[23:49] <jbowtie> I think I just coined a new job description.
[23:50] <dash> jbowtie: please, we prefer to be called "programmer-archaeologists"
[23:52] <jbowtie> dash: Depends on whether you consider it a reconstruction of ancient history or solving a case of patricide.
[23:52] <fullermd> I think it's more matricide, 'cuz when you find out it happened the first word out of your mouth will be "mother-".
[23:55] <jbowtie> fullermd: Actually depends on whether it's the left -hand or right-hand parent that's lost.
[23:56] <jbowtie> Besides if it's repository forensics, I can put "Private Eye" on my business cards.  P
[23:56] <fullermd> Ah, a whole new field of ancestral chirality is opening up.
[23:57] <jbowtie> GungaDin: Did that answer your question?


[06:27] <oda> Tim Allen naked eating a corn dog underwater mummified
[07:01] <_bbb> true story
[07:10] <oda> Best story.
[07:11] <oda> Insomnia is the enemy.
[10:46] <BiosElement> Anyone else up at 7am? >.>
[11:28] <canthus13> Me.
[11:37] <BiosElement> Heh I feel sorry for you canthus13 :P
[11:42] <canthus13> I have kids to get to school. :/
[11:43] <BiosElement> How very exciting
[12:47]  * oda up at 5am
[12:52] <oda> Going to try out doing street photography today and I find that I'm more comfortable when dead tired ^_^
[12:52] <oda> Sleep is the cousin of death
[13:52] <thafreak> Morning Ohio


[02:43] <machina> Hi, I have a question. To fix this upgrade bug ( Bug #206862 ), should I follow the steps outlined here? https://wiki.ubuntu.com/MOTU/Contributing#Preparing New Packages
[02:44] <persia> machina: That package is maintained in Debian.  You might want to work with Nick Rusnov to follow up on Debian bug #446530
[02:46] <persia> But yeah, if you're preparing a new upstream, and it's for Ubuntu only, that's roughly the right procedure.
[02:46] <machina> persia: I read the Debian bug report and noticed that Siegfried's call for a follow up on the bug was left unanswered. So I thought I might just package it for Ubuntu, then worry about the debian upstream later...
[02:47] <persia> The packaging is about the same for either Debian or Ubuntu.  If you prep some work, and contact the maintainer to get it uploaded, you might do well.
[02:48] <persia> If not, sure, just update in Ubuntu (but be warned that this may make merging hard if the orig.tar.gz differs in Debian later)
[02:50] <machina> I'm pretty new to packaging, what kind of prep work would you mean?
[02:52] <persia> OK.  I tend to do the following when updating a package.
[02:52] <persia> 1) Download the new source
[02:52] <persia> 2) Try to apply the previous diff.gz
[02:52] <persia> 3) review any patches to the source to make sure they still apply and solve the relevant issue.
[02:53] <persia> 4) loot for any bugs in Ubuntu and try to fix them
[02:53] <persia> 5) look for any bugs in Debian and try to fix them
[02:53] <persia> 6) Look at some other distributions to see if they have any patches that look interesting (and try to apply them)
[02:54] <persia> But that's sorta general.  Do you know how to manipulate package sources, or are you still learning this?
[02:55] <machina> i don't remember much, so yea i'm still learning
[02:55] <machina> I know how to apply patches & such though
[02:56] <persia> And how to use the various patch systems for debian-format source packages?
[02:57] <machina> i'd have to refer to a wiki for that
[02:57] <persia> That's OK.  I'm just trying to gauge the level of description you need :)
[02:58] <persia> I'd guess you're in a good state to try to follow the steps above.  Just ask here when you run into something you're unsure about.
[03:00] <machina> alrighty thanks
[05:21] <nxvl_> persia: isn't easier use uscan; uupdate?
[05:49] <persia> nxvl: uscan only downloads upstream if the watch file works (not often in my experience for packages that don't get much maintenance), and uupdate might work: I just don't tend to use it.
[05:50] <persia> Plus neither of them do the rest of the hunting about to get something in good shape vs. just pushing a new upstream.  Again, this is more important when there isn't active coordination between distro and upstream maintainers.
[05:55] <nxvl> persia: oh! that might be it, i always work really close with upstream
[05:55] <nxvl> persia: and try to get 0 patches
[05:56] <nxvl> in the packages i maintain, i mean, which are the ones that i usually update
[05:56] <persia> That's the best option, if you're the maintainer.  When dealing with packages that someone else maintains that haven't been updated in a while (or even more fun, with packages with no maintainer), other bits become useful.
[05:57] <persia> But that's a matter of whether one actually cares about packages, or is just trying to keep the distro relatively current and bug-free (in the latter case, one is much more likely to need to use my full list of steps)
[06:00] <nxvl> yeah, well i maintain my packages in debian
[06:00] <nxvl> :D
[06:00]  * persia tries to avoid owning packages, but is becoming increasingly unsuccessful.
[06:01] <nxvl> heh
[06:01] <nxvl> yeah, i gived up long ago
[06:01] <nxvl> :D
[07:37] <dholbach> good morning
[08:06] <thekorn> hey MOTUs!
[08:06] <thekorn> if anyone feels like doing some packaging reviews
[08:06] <thekorn> http://revu.ubuntuwire.com/p/python-fusepy or http://revu.ubuntuwire.com/p/zeitgeist-filesystem
[08:06] <thekorn> might be a good start of this pre-christmas week ;)
[08:25] <persia> thekorn: Just a couple notes on python-fusepy: 1) some of the upstream files don't appear to have a license, 2) why choose GPL for the packaging when the code is ISC?
[08:31] <thekorn> persia, thanks for looking at this package, 1.) my understanding of the packaging process is that I just package what the upstream author gives me, so if he decides to not add a license to the header of his examples, it is his decision
[08:32] <thekorn> and I also thought that adding the license to debian/copyright covers the issue of missing license headers
[08:32] <persia> thekorn: You are entirely correct about packaging only what upstream gives you in terms of licenses.  Where this gets tricky is that you need to be able to demonstrate not only that you have a license to distribute it to Ubuntu, but that you have a license to permit Ubuntu to distribute it to users.
[08:33] <persia> And no.  Only getting upstream to release something different, or deleting stuff from the tarball addresses licensing issues.  That said, there are some fuzzy areas: it all depends on how well it's argued.
[08:33] <persia> For instance, if you had some reference that demonstrated that these unlicensed example files were intended for open release, you could include that documentation, which might cover it.
[08:34] <persia> But the default state of code is that it cannot be distributed without explicit permission from the author.
[08:35] <thekorn> ok, so ther are tow solutions: get in contact with the author and ask him to add a license or give me explicit permission, or remove the examples from the package?
[08:35] <persia> That's my opinion.
[08:36] <wgrant> And it is also the generally held opinion around here, I believe.
[08:36] <persia> For fairness, I'll mention that others believe that one can argue that some files can be distributed without license headers if there is a COPYING or similar file in the root directory of the package.  Since there isn't in this case, I'm not sure that argument applies.
[08:36] <thekorn> ok, thanks, I think will will contact him, having a package without examples is bad
[08:37] <persia> thekorn: OK.  I recommend mentioning that you're packaging it for a distribution, and need the explicit grant of redistribution rights.
[08:38] <persia> Because the author is perfectly correct to distribute without explicit licensing if those files are only intended for educational purposes, and only intended for original recipients of the tarball from upstream.
[08:39] <persia> Unless, of course, if the author is distributing from Honduras or Nicaragua, in which case the files do not automatically carry implicit reservation of rights, but I wouldn't want to count on that.
[08:39] <persia> thekorn: What about the second question?
[08:41] <thekorn> persia, honestly, I did not think about this, I used what dh_make created for me, is this an issue if the packaging license is different to the code license?
[08:41] <persia> That's again a matter for debate.  I like to keep them the same as the contents of the diff.gz are typically considered the packaging, and it means that any patches added to diff.gz automatically are license-compatible with upstream.
[08:42] <persia> Of course, there are others who believe that use of the GPL is more important than supporting upstream: for them, your choice is correct.
[08:42] <persia> (because ISC code can be imported into GPL code, but GPL code cannot be exported to ISC)
[08:44] <persia> This is complicated because some people argue that small patches are not sufficiently significant works on their own to carry a license, and so adoption regardless of license compatibility may be considered fair use in some jurisdictions.  It's also complicated because if you borrowed packaging hacks from GPL packaging, you need to preserve that, if you believe the hacks are significant enough to warrant licensing.
[08:44]  * directhex kicks persia out of GNU-related groups, for suggesting that using GPL *isn't* the most important goal
[08:44] <thekorn> hmm, this license stuff makes me crazy, I'm not a lawyer!
[08:44] <persia> thekorn: I suspect the majority of us aren't.  That's why I tend to use the following rules
[08:45] <persia> 1) Everything must be licensed to be DFSG-free (or at least Ubuntu-free).
[08:45] <persia> 2) Packaging should be the same license as upstream
[08:46] <persia> Following these rules means you end up having a lot of back-and-forth with upstream about licensing, and there are some restrictions about pulling patches from other's packaging for certain packages, but should protect you from any legal implications.
[08:47] <persia> (of course, if you want real advice, speak to someone who is authorised to dispense advise)
[08:47] <thekorn> you should this rules to a section of the packaging guide ;)
[08:50] <persia> thekorn: Seems it already exists: https://wiki.ubuntu.com/PackagingGuide/Complete#Copyright%20Information
[08:50] <persia> At least some of that comes directly from one of my -classroom sessions, but it's been fleshed considerably since then.
[08:51] <persia> Bascially, rule #1 is the first bullet in the first list, and rule #2 is interesting thing 3 about debian/copyright
[08:51] <thekorn> persia, ah ok, thanks. I had a hard time reading this huge wiki page, I must have missed this section
[08:52] <thekorn> another solution for my special case would be to just include the one file (fuse.py, which has a license header etc.) I need into my product (zeitgeist-filesystem) into the package
[08:52] <thekorn> which should be ok license wise,
[08:53] <persia> Well, it's only the examples (and memory3.py) that don't have licenses.  You'd have to modify the original tarball.
[08:53] <persia> It's worth an email to upstream.  If that doesn't result in a fix soon, then removing the extra files (which aren't used for most stuff), and including something in README.Debian explaining where to download examples would work.
[08:54] <thekorn> persia, ok thank you very much. I'm contacting upstream now
[08:55] <persia> thekorn: Good luck.
[08:56] <thekorn> thanks
[09:05]  * persia is enjoying REVU.  Anyone else have a request (or shall I just pick one?)
[09:22] <thekorn> persia, thanks for looking at zeitgeist-filesystem on REVU too
[09:34] <persia> thekorn: Same set of issues, really :)
[09:35] <thekorn> persia, with one difference: I'm upstream for zeitgeist-filesystem, so communicatin should be a bit smoother ;)
[09:35] <persia> thekorn: We can hope :)
[10:23] <Rhonda> I wonder, is it possible to list more than just 10 strings in the the translations part of launchpad? Given that it takes a bit to load even that it would be much more convenient to have more than just 10 on a page.  :/
[10:27] <persia> There's some way to interact with .pot files.  Ask in #launchpad@freenode
[10:29] <Rhonda> Yes, I saw that - somehow that would though be just a workaround. :)
[10:30] <persia> There may also be a way to translate more strings at once (I'm not sure: I've not used Rosetta in years).
[10:31] <Rhonda> Well, one can translate 10 strings at once through the web interface.
[10:32] <dpm> Rhonda, you can hack the URL to specify a bigger batch size (i.e. more translations to be presented on a page). Let me give you an example...
[10:35] <dpm> Rhonda, for example https://translations.launchpad.net/ubuntu/karmic/+source/evolution/+pots/evolution/ca/+translate?start=10&batch=30 -> you can specify the batch parameter to get more translations shown on the web UI - IIRC the limit is 30 or 50, though
[10:36] <Rhonda> dpm: Oh, didn't know about the batch argument, cool! Usually I _do_ hack URLs where it's obvious, but I didn't know that there's such an argument. :)
[10:40] <dpm> Rhonda, yes, I think they stopped showing it so that people do not overuse it. There didn't use to be a limit on the batch size either, but it was then limited for performance reasons AFAIK
[10:53] <AnAnt> Hello, I am developing a software that has some files covered under GPL3+ & others under CC-BY-SA, how should I put the copyright files ?
[10:53] <AnAnt> concat both licenses in the COPYING files ?
[10:53] <AnAnt> btw, the question is regarding upstream software
[10:56] <persia> First, check the CC and GPL sites to get some opinions on compatibility.  MY memory is that not all versions of the GPL are compatible with all versions of CC-BY-SA.
[10:56] <persia> Second, you'll want to specify which files fall under which licenses in debian/copyright
[10:57] <AnAnt> persia: do I have to specify which files in upstream's COPYING too ?
[10:57] <persia> http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html shows an example with GPL and LGPL that might give you a starting point.
[10:57] <persia> No, Upstream is different.
[10:58] <persia> So, Upstream should either include two license files (neither needs be named COPYING, so long as they are clearly named), or put both in COPYING with some description.
[10:58] <persia> Then, in each upstream file, specify which license applies.
[10:59] <AnAnt> persia: thanks
[11:11] <directhex> only cc-by-sa 3.0+ is dfsg
[11:12] <directhex> CC isn't GPL-compatible
[11:17] <persia> directhex: I thought there was some version of CC that was compatible with some version of the GPL.  Are you sure that never got resolved?
[11:18] <directhex> persia, i'm going by gnu.org, not that i trust those rabble-rousers
[11:44] <persia> directhex: Hrm.  I thought I saw something, but the only mention of CC-BY-SA-3.0 on gnu.org I can find is a declaration of it's compatibility with GFDL1.3.  I see lots of negative stuff about CC-BY-SA 2.0.  I see nothing about CC-BY-SA 2.5.
[11:44] <directhex> not the most comprehensive resource
[11:45] <persia> No, but it provides handy guidelines.  I suppose each upstream is basically on their own when it comes to selecting from what sources they may draw.
[11:54] <Quintasan|Szel> persia: hi, the rest of the vote will be on MOTU Council mailing list?
[11:55] <persia> Quintasan|Szel: Yes.  So far, it's looking good.  If the others don't vote in a few days, I'll just record them as abstaining, and complete processing your application (probably near the end of the week)
[11:56] <Quintasan|Szel> persia: Okay, thanks for letting me know :)
[12:02] <slytherin> A bit off topic. Does anyone have a link to a howto about adding help to a GTK application?
[13:07] <jbicha> slytherin: try the guides at the bottom of http://library.gnome.org/devel/guides
[13:07] <slytherin> jbicha: thanks
[13:32] <quadrispro> ehy guys, should I wait for an ubuntu-sru ACK before uploading to -proposed or not?
[13:32] <matti> I would wait. No harm done in waiting ;p
[13:32] <matti> Sit back and relax.
[13:32] <matti> Have some tea ;p
[13:34] <slytherin> quadrispro: You must wait.
[13:35] <quadrispro> Yep, so I know the process well :)
[13:35] <quadrispro> thank you
[13:35] <matti> ;p
[13:35] <matti> Please, don't call it "The Process" ;p
[13:35] <matti> It should like my work place ;p
[13:35] <matti> s/should/sounds/
[14:46] <ScottK> It looks like oprofile is in serious need of a merge and doko is unlikely to get to it soon, so if someone is looking for profitable work to do ....
[14:46] <hyperair> profitable?
[14:47] <ScottK> hyperair: As in useful.
[14:47] <hyperair> ah
[14:47] <hyperair> =)
[14:49] <slytherin> hyperair: Have you ever successfully setup remuco-vlc in karmic?
[14:49] <hyperair> never tried, really
[14:49] <hyperair> ..speaking of remuco, i'm supposed to get it updated in debian!
[14:49]  * hyperair facepalms
[14:50]  * hyperair prepares to fire off an RFS
[14:50] <slytherin> hyperair: I was able to use remuco-totem. But -vlc doesn't work.
[14:50] <hyperair> i'll give it a go later
[14:50] <slytherin> And I think there is some serious problems with Sony Ericsson phones. They always give me trouble with bluetooth.
[14:51] <hyperair> mine's a sony ericsson s500i
[14:51] <hyperair> it works wonderfully
[14:51] <hyperair> both with remuco and without
[14:51] <hyperair> as in, the builtin bluetooth control thing works pretty well too
[14:52] <slytherin> then it is problem with my phone.
[14:52] <hyperair> probably
[14:52] <hyperair> i'd try with a windows machine to see whose fault it is
[14:53] <slytherin> hyperair: I don't have a windows machine.
[14:53] <hyperair> oh well =\
[14:54] <hyperair> if your bluetooth transmitter uses usb, you could try getting virtualbox to hijack it, if you have a virtual machine with windows on it
[14:55] <slytherin> hyperair: that is not an option either. My laptop has sufficient memory to run VB but it is powerpc. My PC is i386 but not sufficient memory. :-P
[14:56] <hyperair> heh i see
[14:56] <hyperair> ouch =p
[14:56] <hyperair> does the PC have issues with bluetooth?
[14:57] <hyperair> also, what kind of troubles did you have with your phone?
[14:57] <slytherin> All sorts of. Pairing doesn't work reliably (pin dialog doesn't come up on PC). File transfer doesn't work etc.
[15:05] <slytherin> hyperair: you are still using thirdparty sources for compiling client right?
[15:06] <hyperair> slytherin: no. not at all.
[15:07] <hyperair> the client was only included once oben (upstream) got rid of the need for including third party sources.
[15:07] <hyperair> something about stubs
[15:07] <slytherin> ok.
[15:10] <slytherin> hyperair: Are you anyway familiar with the client code?
[15:12] <hyperair> slytherin: not at all. but i'm educated somewhat in java. (it's the only language my formal education has covered, and one of the languages i really loath)
[15:13] <slytherin> hmm. I guess I will have to take my own help. :-)
[15:14] <hyperair> slytherin: you could poke the author.
[15:18] <slytherin> hyperair: I want to debug why the client does not detect bluetooth capability on my wife's phone. Will check code first.
[15:30] <bddebian> Heya gang
[16:06] <dholbach> who can I interest in running a session at the next Ubuntu Developer Week? https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep still has a couple of empty slots :)
[16:44] <EzraR> how long does it take a package to get into testing from unstable
[16:45] <maco> 10 days i think
[16:45] <EzraR> if a package was added to testing a couple days ago will it be in testing in time to get added to lucid?
[16:45] <EzraR> oh nice
[16:45] <EzraR> thats not long
[16:47] <EzraR> if said package fixes a bug can it get upgraded in karmic (not backports)
[16:47] <EzraR> a bug that makes the package not work by default
[16:48] <EzraR> would that be a SRU?
[17:04] <cjwatson> EzraR: http://wiki.ubuntu.com/StableReleaseUpdates; if the package is just plain non-functional, then yes the fix may be eligible for a stable update
[17:04] <cjwatson> EzraR: 10 days> but this depends on other things, 10 days is just the normal minimum
[17:15] <EzraR> ok so once it hits lucid put a SRU request
[17:15] <EzraR> thnx
[17:30] <joaopinto> will python2.5 be removed on Lucid ?
[17:49] <ScottK> I would imagine so, but it's up to doko.
[21:15] <randomaction> Any idea what's happening here? Package was apparently synced twice (bug 402089, bug 484679), but is still at older version.
[21:20] <geser> randomaction: interesting, usually the AA sync script complains when the switch to overwrite the ubuntu delta got forgotten
[21:28] <randomaction> I think I'll reset one of these bugs to Confirmed and ask AAs to look once again.
[21:31] <ScottK> randomaction: Is it a v3 source package in Debian?
[21:33] <randomaction> it's not afaict (no debian/source/format)
[21:33] <geser> randomaction: you could try if slangasek or james_w have time to look at it as this seems to be special
[21:33] <geser> ScottK: the first sync which failed is from July
[21:34] <ScottK> Oh.
[21:34] <ScottK> md5sum mismatch?
[21:34] <joaopinto> hi
[21:34] <ajmitch> different upstream version
[21:34] <joaopinto> is there any utility that lists conflicting packages from a repository ? I mean doing a recursive analisys
[21:34] <randomaction> yep, second sync is for newer upstream
[21:46] <persia> kees: I was trying to make mk-sbuild-lv work on ports architectures, and I wondered if there was a difference between -updates and -security on security.ubuntu.com (there is a vast difference on ports.ubuntu.com)
[21:47] <joaopinto> hum, any idea how apt install recommends deals with conflicts ? If a package is recommended but conflicts with an installed package is it simply not installed ?
[21:47] <StevenK> persia: It has just worked for me before?
[21:48] <geser> joaopinto: try it out in a pbulder?
[21:48] <persia> StevenK: Then you were 1) defining an lpia chroot, and 2) using security.ubuntu.com ${RELEASE}-updates for security (if you enabled security)
[21:48] <joaopinto> geser, I would need to find a conflict case :P
[21:49] <persia> StevenK: Or at least it failed completely to work for me with powerpc and armel (until I changed some stuff).
[21:49] <StevenK> persia: I was undoubtedly doing both of those
[21:50] <persia> There was a bunch of special-case code to make lpia chroots work on i386 or amd64 machines.  I'm not sure they would have worked for a native lpia schroot.
[22:04] <slangasek> randomaction, geser: the fox1.6 sync failure isn't due to the missing 'force' switch, it's because the source package in Debian is broken and has no sourceful Section field
[22:04] <slangasek> (this only gets detected when trying to flush the syncs to the archive, so is easily overlooked)
[22:06] <slangasek> randomaction, geser: documented now in bug #484679
[22:07] <geser> slangasek: thanks for looking at it
[22:07] <randomaction> slangasek: thanks for looking


[23:54] <maco> rosco_y: gnome is included. just choose it at the login screen
[23:54] <edbian> Philosoraptor, I'm not sure
[23:54] <edbian> Afteraffekt, A block?
[23:55] <rosco_y> maco: :) Thanks!
[23:55] <edbian> Afteraffekt, I have no idea what you're talking about anymore
[23:55] <CyborgSmurf> Matic`Makovec: ls = NWNDE.iso (I changed the name)
[23:55] <nerdshell> edbian: yes, but what's the utility of . ?
[23:55] <ubun> Ubuntu1010 doesnt see my MP3 as an mp3 what can i do?
[23:55] <Chii> There we go
[23:55] <edbian> nerdshell, to do things like ./folder
[23:55] <Chii> Wireless at last!
[23:55] <edbian> Chii, :D   That was easy
[23:55] <cusith> If anyone is available to help a first time Linux user with some Ubuntu install issues, please send me a message.  Ubuntu freezes during install.
[23:55] <Matic`Makovec> CyborgSmurf, basically your pwd is /home/cyborgsmurf in which you have NWNDE.iso?
[23:55] <edbian> Chii, what was so hard about it?
[23:55] <Chii> Indeed haha
[23:56] <Chii> I have no idea >.>
[23:56] <eliam> m1dn1ght, hmmm, just scan read that guide, I think you're correct about that bit maybe not applying...
[23:56] <edbian> Chii, :D
[23:56] <Chii> I think maybe I clicked the wrong button
[23:56] <Chii> as it was installed and I didn't noticed the networks
[23:56] <eliam> m1dn1ght, tried an nfs client on the server?
[23:56] <edbian> Chii, hahaha.  Well now it works
[23:56] <Chii> Indeed
[23:56] <emap> cusith: freezes with no error or anything that may let you guess something's wrong?
[23:56] <ubun> Ubuntu1010 doesnt see my MP3 as an mp3 what can i do?
[23:56] <edbian> Chii, It was the modprobe that made them show up and my other commands LO
[23:56] <edbian> :)
[23:56] <Chii> Ah
[23:56] <MarkSS> Where can I find a JPEG decoder or some image forensics program for Ubuntu?
[23:56] <CyborgSmurf> Matic`Makovec: what?
[23:56] <zvacet> ubun: do you have codecs installed
[23:56] <Afteraffekt> edbian, thanks anyways ill find it
[23:57] <Chii> so I do have to use modprobe to start it up?  As for doing the sudo-apt get install bit... it turns out it was already installed hehe
[23:57] <Matic`Makovec> CyborgSmurf, what part of my question is "what"?
[23:57] <ubun> zvacet: codecs?
[23:57] <cusith> No error message. A window comes up asking to connect to the internet to download update, and nothing happens, the loading symbol just keeps on turning.
[23:57] <Chii> I also disabled the default drivers that came with the laptop for the wireless
[23:57] <edbian> Chii, You will not have to do modprobe again
[23:57] <Chii> Hope that doesnt bite me in the arse later
[23:57] <ubun> zvacet: the restricted stuff?
[23:57] <m1dn1ght> eliam: As in have I tried to reverse the roles and connect to the a share on the client machine from the server?
[23:57] <Chii> Thank goodness
[23:57] <edbian> Chii, restart now and see what happens
[23:57] <zvacet> !medibuntu | ubun
[23:57] <CyborgSmurf> Matic`Makovec: pwd = password (why would I need to type in a password?)
[23:57] <Chii> Im almost afraid :3
[23:57] <emap> cusith: please report here all your install process (if you did anything besides going on next next yes ok whatever) and your system specs
[23:57] <Chii> lol
[23:57] <Chii> Ill do it later xD
[23:57] <edbian> Chii, I can help if it doesn't work
[23:57] <eliam> m1dn1ght, no, just connect from the server to the server....just to check the config is working on the server.
[23:58] <Chii> True haha
[23:58] <Matic`Makovec> CyborgSmurf, type pwd in shell and you'll find out what it is. Type exactly those three letters: "pwd"
[23:58] <Chii> Also when  I reboot Ill be coming on my registered nick Elda
[23:58] <m1dn1ght> eliam: Ah - I see what you're saying.  Let me try
[23:58] <edbian> Chii, k
[23:58] <ubun> zvacet: i dont think i do, let me do my homework on that so i know what it all does..
[23:58] <eliam> m1dn1ght, rules out some complications...
[23:58] <rww> CyborgSmurf: Print Working Directory
[23:59] <zvacet> ubun: it will install w32 codecs so that should work
[23:59] <CyborgSmurf> Matic`Makovec: /home/cyborgsmurf/Desktop/NWNDE
[23:59] <Matic`Makovec> CyborgSmurf, see now?


[09:48] <mup> Bug #1929928 changed: MAAS fails on determining default route <MAAS 2.9:Triaged> <https://launchpad.net/bugs/1929928>
[09:57] <mup> Bug #1929928 opened: MAAS fails on determining default route <MAAS 2.9:Triaged> <https://launchpad.net/bugs/1929928>
[10:00] <mup> Bug #1929928 changed: MAAS fails on determining default route <MAAS 2.9:Triaged> <https://launchpad.net/bugs/1929928>
[10:03] <mup> Bug #1929928 opened: MAAS fails on determining default route <MAAS 2.9:Triaged> <https://launchpad.net/bugs/1929928>
[10:15] <mup> Bug #1929928 changed: MAAS fails on determining default route <MAAS 2.9:Triaged> <https://launchpad.net/bugs/1929928>
[10:51] <mup> Bug #2017767 opened: Gigabyte Z62-63-00 randomly fails enlisting and commisioning in UEFI mode <MAAS:New> <https://launchpad.net/bugs/2017767>
[11:03] <mup> Bug #2017767 changed: Gigabyte Z62-63-00 randomly fails enlisting and commisioning in UEFI mode <MAAS:New> <https://launchpad.net/bugs/2017767>
[11:15] <mup> Bug #2017767 opened: Gigabyte Z62-63-00 randomly fails enlisting and commisioning in UEFI mode <MAAS:New> <https://launchpad.net/bugs/2017767>
[15:36] <mup> Bug #1876365 opened: host passthrough not working with KVMs <bug-council> <MAAS:Triaged> <https://launchpad.net/bugs/1876365>