[03:35] <kgoetz> if i blow away 70-persistent-net.rules will it be recreatd next boot?
[03:38] <pteague> anybody have any hardware suggestions for an ubuntu desktop?
[03:38] <kgoetz> what sort of suggestions
[03:40] <ScottK> pteague: Intel video for FOSS video support unless you're a gamer.
[03:40] <kgoetz> ScottK: if your after *F*oss you'll need intel anyway :)
[03:40] <pteague> intel video?  i was thinking nvidia for xvmc
[03:42] <pteague> i'm starting a new job on monday & they're wondering what i want as a workstation... i'm pretty much handling all their web stuff - db, webserver, site, etc
[03:42] <kgoetz> so you *dont* want broadcom network devices :)
[03:43] <kgoetz> you can either go with nvidia and known support, or gamble on AMD getting ATI open sooner rather then later for video
[03:43] <pteague> was thinking amd cpu & nvidia video
[03:44] <kgoetz> amd is ok. not been exactly cutting edge recently (on desktops), but solid  still
[03:44] <kgoetz> and less buggy then intels *grin*
[03:45] <pteague> libc6 works on amd... certain features are borken on intel
[03:49] <kgoetz> thats something worth remember for me i think
[03:52] <pteague> i use chbg on occasion & discovered it wouldn't work on my laptop (intel)...  went back & reinstalled the first 6 disc i had & it worked so i locked the libc6 library... i updated my desktop (amd) & chbg worked... so i thought great! it's fixed.. unlocked on laptop, downloaded updates, & it's broken! hehe
[03:54] <kgoetz> i dont have tha ttool, what is it?
[03:55] <pteague> screensaver, desktop changer...  can use it as a slideshow as well
[03:55] <kgoetz> aaah.
[03:57] <pteague> i realize there's a couple different xscreensaver things that do something similar, but it has a lot of options & the really nice thing about it is i can get it to just display all the images dead center
[05:43] <orochi2> i had a question about apache now that i have my ubuntu server setup (i didnt use the livecd, but the server cd) i was wondering if someone was available for a few questions
[05:46] <kgoetz> !tell orochi2 about ask
[05:48] <orochi2> lol ok good, someone's alive out there. I used to run a gentoo box as a LAMP, I like Ubuntu so far, but i want to do it right. What would be the best way of setting up my website. I find it a pain to deal with the files in /var/www as they are all root:root, what would be the best way to manage those files? Create a virtual host for my .com for the user i use, leave it as root and live with it what would be the best way to go abou
[05:50] <kgoetz> depends. for personal space simply create public_html and put your files in thre
[05:50] <kgoetz> otherwise, look into vhosts (asking about this stuff in #apache would be a good idea too)
[05:51] <orochi2> ok
[05:52] <orochi2> should I leave my vhost as root:root or what would be the owner:group i should have the files be in?
[05:53] <kgoetz> ideally yes, tehy would stay as root, but if you will edit the fils a lot, it might make sense to go with youruser:www-data
[05:53] <orochi2> ok ill look into that
[08:06] <asisak> What should I prefer nowadays if I want to run multiple (web) environments on a (Ubuntu) Linux box?
[08:06] <asisak> E.g., some plone portal(s), some wiki(s) and some other services (like DNS or e-mail)
[08:06] <asisak> Xen might be an overkill, but I am not sure if VServer or something similar is a good idea...
[08:07] <macd> Seperating those services with a VM is a very good idea
[08:08] <macd> Xen is pretty painless to setup on Gutsy now, plus you can just bootstrap a base ubuntu system, then install those services you need only
[08:08] <asisak> You mean install the separate services in separate VMs?
[08:14] <macd> Sure, why not
[08:14] <macd> its a very good way to minimize risk from a securty standpoint also
[08:17] <asisak> Sure, but you have to upgrade each machine, and you run many kernels
[12:57] <_oet> Hallo
[12:58] <pvandewyngaerde> _oet: english here
[12:58] <_oet> Woops, english channel offcourse :P
[12:58] <_oet> my bad ;)
[13:21] <kraut> moin
[13:23] <sommer> kraut: hey
[13:23] <kraut> hi sommer
[13:23] <kraut> interesting surname :)
[13:23] <sommer> kraut: thx
[13:24] <sommer> had it all my life... heh
[13:35] <_oet> I was wondering, whether the support for the current 7.10 server version is completely stopped in 2009 or that security updates will continue to be provided..
[13:40] <firecrotch> _oet: I'm pretty sure that means that there won't be any security updates after that
[13:40] <_oet> ok, thanks for the info :)
[13:41] <firecrotch> _oet:  8.04 will be an LTS release though, if I'm not mistaken
[13:42] <_oet> ok
[13:42] <_oet> i'll keep that in mind
[13:43] <MenZa> It will, firecrotch
[13:43] <firecrotch> thanks, MenZa
[13:44] <firecrotch> _oet: are you planning on using Ubuntu for a webserver or something of that nature?
[14:04] <CyberMad> i want to install gnome.. then i did apt-get install gnome..
[14:05] <CyberMad> now, how to start my gnome?
[14:05] <firecrotch> CyberMad:  startx
[14:05] <pvandewyngaerde> dont you need  ubuntu-desktop ?
[14:06] <sommer> CyberMad: you might check out this forum thread: http://ubuntuforums.org/archive/index.php/t-186298.html
[14:06] <pvandewyngaerde> or  /etc/init.d/gdm start
[14:06] <sommer> it lists all the packages you'll need
[14:06] <CyberMad> ok thanks a lot
[14:07] <CyberMad> so, what is the different between ubuntu-server dan ubuntu-desktop? only on the package?
[14:07] <CyberMad> like ubuntu-desktop doesn't have samba package on cd, etc
[14:07] <CyberMad> is that correct?
[14:10] <pvandewyngaerde> its the packages  for a GUI desktop , a server doesnt need one by default
[14:10] <sommer> CyberMad: yep different packages on the CD, different kernel, different installer
[14:10] <CyberMad> is this what you mean:
[14:10] <CyberMad> sudo apt-get install ubuntu-desktop
[14:10] <CyberMad> sudo apt-get install gdm
[14:10] <CyberMad> sudo /etc/init.d/gdm start
[14:10] <CyberMad> sudo dpkg-reconfigure xserver-xorg
[14:11] <CyberMad> well, i just want to run vmware-server on ubuntu-server
[14:11] <CyberMad> actually i don't have any idea about that
[14:12] <CyberMad> i want running windows xp on vmware-server
[14:12] <CyberMad> so everyone can remote that XP
[14:12] <CyberMad> because we don't XP on every computers
[14:12] <CyberMad> but sometime we still need XP
[14:14] <sommer> CyberMad: you should be able to do that on Ubuntu Server
[14:22] <CyberMad> sommer without the GUI ?
[14:22] <CyberMad> sommer have you try the vmware-server ?
[14:23] <sommer> CyberMad: nope I haven't tried vmware myself in quite a while... I think it can though?
[14:23] <sommer> others in this channel I know have
[14:24] <CyberMad> :)
[14:24] <CyberMad> well ok, i will test it this week
[14:24] <CyberMad> thnks
[14:24] <sommer> CyberMad: here's a wiki page on vmware: https://help.ubuntu.com/community/VMware/Server
[14:24] <sommer> you could try that out and update the page if there's anything missing :)
[14:24] <CyberMad> that's very cool... will help me much.. thanks
[14:24] <sommer> np
[14:34] <_ruben> just curious .. are there any plans whatsoever to support PF_RING on ubuntu (server)? just found catapulta.org, which does incorporate PF_RING, but is still at beta state
[14:37] <firecrotch> _ruben: you ought to be able to enable it in Ubuntu
[14:37] <firecrotch> _ruben: I found a tutorial that works on Debian which would be a good starting point, at least
[14:37] <firecrotch> http://bjou.homeunix.net/blog/2006/12/advanced-packet-capturing-howto-pf_ring-napi-and-extended-libpcap-on-debian-sarge/
[14:39] <_ruben> firecrotch: i know that url .. its a bit outdated since it mentions a cvs repo intead of svn .. and i expect PF_RING to integrate into ubuntu/debian kernels 'nicer' than our current SuSE kernels (old kernels with tons of security backports)
[14:40] <_ruben> bit curious though if there were any plans on actually offering support on it and providing the appropriate kernels/libpcap libs for it
[14:41] <firecrotch> Ah, well, I'm definitely not the person to find out about that from
[15:56] <nealmcb> server team meeting in 4 minutes in #ubuntu-meeting:
[15:56] <nealmcb> https://wiki.ubuntu.com/ServerTeam/Meeting
[15:59] <sommer> nealmcb: I think they will... can always update it later :)
[16:00] <sommer> the cert statement that is
[16:05] <nxvl_work> isn't today the meeting?
[16:06] <sommer> nxvl_work: yep #ubuntu-meeting
[16:25] <soren> !mda
[16:25] <ubotu> Sorry, I don't know anything about mda - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[16:41] <Gargoyle> Can anyone help me reconnect my split-brained drbd?
[16:42] <Gargoyle> I have them both set to secondary/unknown, but can't get them to connect. Not bothered which is primary, only testing at the mo.
[17:00] <ScottK> nealmcb: It's probably worth mentionind that although Postfix is primarily an MTA, it can serve as an MSA and and MDA too.
[17:00] <nealmcb> ahh - got it
[17:02] <soren> MSA?
[17:02] <ScottK> Mail Submission Agent.
[17:02] <soren> Which does what?
[17:02]  * lamont tries to decide if he cares what the 'S' and 'D' stand for
[17:02] <ScottK> MUA -> MSA -> MTA -> MTA -> MDA -> MUA.
[17:03] <nealmcb> so postfix with a smarthost is an msa?
[17:03] <nealmcb> any other msas?
[17:03] <ScottK> I'd say yes, but there are probably protocol police that would disagree.
[17:03] <nealmcb> (anything with a smarthost....)
[17:03] <lamont> MSA means that it listens on the 'submission' port, for MUAs to talk to.
[17:04] <nealmcb> ahh
[17:04] <lamont> MTA means it listens on the 'smtp' port
[17:04]  * ScottK likes lamont's definitions
[17:04] <lamont> MDA means that it delivers to local/virtual/whatever mailboxes, from whence MUAs grab it
[17:04] <lamont> MUA means a user interacts with it directly
[17:05] <lamont> MUI == mail using idiot
[17:05] <lamont> aka, user
[17:05] <soren> So Postfix is an MSA because an MUA can poke stuff into its queue by way of /usr/sbin/sendmail ?
[17:05] <lamont> MUI -> MUA -> MSA -> MTA -> MTA -> MDA -> MUA -> MUI. :-)
[17:05] <keescook> so are pop/imap servers actually MDAs then?
[17:05] <soren> No.
[17:05] <soren> Did my mail not reach the mailing list yet?
[17:05] <lamont> keescook: they don't deliver to mailboxes. they provide access to them
[17:06] <lamont> soren: MSA is, IMO, kinda stupid.
[17:06] <lamont> the concept, that is.
[17:06] <soren> lamont: Agreed.
[17:06] <keescook> soren: no it did, and I thought the same you did -- I was just trying to figure out what to call the pop/imap piece
[17:06] <lamont> an MSA is an MTA that listens on the 'submission' port.
[17:06] <soren> lamont: It's something that only marginally makes sense on a design diagram of postfix and *nowhere* else. :)
[17:06] <keescook> MSA makes sense for ISPs that want to block MTA traffic.  :P
[17:06] <nealmcb> I think the goal of the submission port is to help fight spam by separating submission from transfer at the port leel
[17:06] <lamont> which it, therefore, assumes is an MUA talking to it, not some random MTA, or spamware.
[17:06] <keescook> nealmcb: yup
[17:07] <keescook> so pop/imap is an Mailbox Access Agent?  (between the MDA and the MUA?)
[17:07]  * keescook loves making stuff up
[17:07] <lamont> nealmcb: which does next to nothing for you when the spamware connects to the MSA
[17:07]  * lamont ^5s keeskook.
[17:08] <lamont> what are we gonna make the rest of the letters??
[17:08] <nealmcb> msa?  mui? :-)
[17:08] <soren> ffs...
[17:08] <soren> :p
[17:08] <lamont> nealmcb: I assume that MSA was someone elses.  MUI is all mine.
[17:08] <lamont> soren: ffs is a very nice kernel routine, returning the first set bit in a word
[17:08] <keescook> msa is real (as ScottK says: Mail Submissions Agent)
[17:09] <lamont> MAA... mail authentication agent?
[17:09] <keescook> (without the trailing s)
[17:09]  * nealmcb nods
[17:09] <lamont> MBA: masters of business administration.
[17:09] <soren> lamont: ffs == first f???? set?
[17:09] <nealmcb> mba mail bs agent?  aka spammer?
[17:09] <lamont> find first set
[17:09] <soren> lamont: of course.
[17:09] <ScottK> IIRC there's an Internet Draft somewhere that defines all these.
[17:09]  * lamont was thinking mail breaking agent
[17:09] <nealmcb> same thing
[17:09] <ScottK> Ah, that would be Exchange.
[17:10] <keescook> ah-ha, Mail Retrieval Agent
[17:10] <dthacker> sorry, missed the meeting. when will transcripts be up?
[17:10] <keescook> http://wiki.mutt.org/?MailConcept
[17:10] <lamont> ScottK: stop introducing facts into the discussion (internet draft)
[17:10] <nealmcb> time we all moved to jabber and rss and left this mail morass to die a slow death :-)
[17:10] <lamont> MYA: mame your a**
[17:11] <lamont> hrm... IP-over-bullhorn.
[17:11] <ScottK> Speaking of such, rfc2821bis is in IETF last call now.
[17:13] <nealmcb> keescook: nice one
[17:14] <lamont> ScottK: prior to being voted on, yes?
[17:14] <ScottK> lamont: Yes.
[17:14] <ScottK> So this would be the time to look at it and kvetch.
[17:14] <ScottK> http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis-06.txt
[17:14] <nealmcb> ScottK: thanks
[17:15] <ScottK> nealmcb: No trouble.
[17:16] <lamont> keescook: I think they're onto us.
[17:17] <keescook> lamont: dangit
[17:43] <nijaba> Table create at https://wiki.ubuntu.com/ServerPackageReview
[17:44] <nijaba> Volunteers should now run to put their names along the best packages ;)
[18:13] <ivoks> hi
[18:13] <ivoks> ScottK: you'll work on amavis?
[18:23] <ivoks> lamont, ScottK ping?
[18:24] <ScottK> ivoks: Yes.
[18:25] <ScottK> ivoks: I think the package itself is in good shape.  I'd be curious if you have comments.
[18:26] <ivoks> defaults are ok
[18:26] <ivoks> from my experience, i had problems only with systems with misconfigured /etc/hosts
[18:26] <ivoks> and that's quite often :/
[18:27] <ivoks> other than that, package is in great shape
[18:27] <ivoks> maybe we could work on some rules for ubuntu
[18:27] <ivoks> i have a dream when amavis will become part of default mail server installation :)
[18:28] <ScottK> Right, well that'd be a big part of the point for moving it to main.
[18:28] <ScottK> I did make a change to make it easier to fix the config if you've got a /etc/hosts problem and don't know Perl syntax.
[18:29] <ivoks> great
[18:30] <ivoks> i'll work on drbd
[18:30] <ivoks> nad maybe we could push postgrey to main too?
[18:31] <ivoks> it had only one CVE entry, IIRC, in couple of years...
[18:31] <ScottK> ivoks: I'm not convinced on postgrey.  I think Greylisting is useful now, but the benifit is only transient.  More and more spammers are retrying now, so it's value is dimishing. I don't see supporting it for 5 years.
[18:31] <ivoks> they are retrying, with same ip
[18:32] <ivoks> that's when other antispam tools kick in
[18:32] <ivoks> i use it and it does more than all other anti spam tools at the moment
[18:32] <ivoks> there are installations where i use it for 2 years
[18:32] <ivoks> 0 problems
[18:33] <ivoks> but i understand your point
[18:33] <ivoks> anti-spam protection is very dynamic area...
[18:35] <sommer> ivoks: speaking of anti-spam I've added a section on Mail Filtering to the server guide... I was wondering if I could send it to you for review?
[18:35] <ScottK> I think adding amavisd-new is a sensible, stable core to allow people to hang whatever they want off of it.
[18:35] <ScottK> ivoks: Do you read postfix-users?
[18:36] <sommer> ScottK: not that I don't value your input, but the more reviews the merrier
[18:36] <ScottK> sommer: Of course.
[18:36] <ivoks> sommer: sure
[18:36] <ivoks> ScottK: no... :)
[18:37] <sommer> ivoks: cool, there's also an update to the Postfix SASL section using Dovecot.
[18:37] <ScottK> ivoks: OK.  There was a funny bit today about an Ubuntu user writing in with a Postfix problem that turned out to be webmin adding 'sudo' to their smtpd_recipient_restrictions.
[18:37] <ivoks> :)
[18:38] <ivoks> i'll check archives :)
[18:38] <ivoks> webmin is evil.
[18:38] <sommer> ivoks: I'll get that to you this evening, thanks again.
[18:38] <ivoks> sommer: great
[18:40] <ivoks> i have to get rid of desktop related packages i maintain :)
[18:40] <ivoks> they hunt me while i'm a sleep :)
[18:40] <ScottK> ivoks: Don't sleep then.    I've done things like that.
[18:44] <ivoks> fun... hm, i don't think there's a good word for that :)
[18:46] <ivoks> see you later
[18:51] <nealmcb> sommer: can you send me the mail filtering section also?
[19:02] <sommer> nealmcb: absoluteley
[19:30] <nealmcb> sommer - a section in the server guide on how server differs from desktop (kernel, no x11, etc) would be handy I bet.  those articles from http://www.enterprisenetworkingplanet.com/netos/article.php/3710641 have more detail than we want, but touching on a few of them would make savvy users feel more comfortable
[19:33] <sommer> nealmcb: good idea... I'll add that to the list, and try to get it in before hardy.
[19:36] <nealmcb> dthacker: you can find raw recent meeting logs at http://kryten.incognitus.net/mootbot/meetings/
[19:36] <nealmcb> e.g. http://kryten.incognitus.net/mootbot/meetings/ubuntu-meeting.20071127_1603.html for today
[19:36] <nealmcb> but those get moved I think later on
[19:37] <nealmcb> sommer: you rock :-)
[19:37] <sommer> heh party!
[20:33] <macd> mathiaz, around?
[20:34] <mathiaz> macd: yes.
[20:35] <macd> I saw the meeting minutes, do you have a link on the wiki to using tasksel?
[20:35] <macd> ohh, and I added a few tihngs to it the other day detailing the exact configuration changes
[20:47] <mralphabet> nijaba: are you around?
[20:48] <mralphabet> nijaba: I am looking at https://help.ubuntu.com/community/JeOS and made some minor corrections (spelling).
[20:50] <mralphabet> nijaba: there is one spot that I can't seem to fix.  Under 'Installing VMware Tools', 'Next should ask VMware to mount the VMwareTools CD', VMwareTools shows as a link, but only 'MwareTools' is actually linked.  When I edit the page to correct it, there is no link in the wiki code.
[20:50] <mralphabet> nijaba: so not sure where it is getting the link from, but I thought I would mention it.
[21:42] <nijaba> mralphabet: Thanks for your corrections.  Regarding the Link, I came to the conclusion of a bug in InterWiki...
[21:44] <mathiaz> macd: the documentation I've found about tasksel is its README file
[21:44] <mathiaz> macd: in /usr/share/doc/tasksel/
[22:00] <soren> mralphabet: It's a link because it has at least two capital letters in it separated by lower case letters. It doesn't matter if a page exists with that name.
[22:00] <nijaba> mralphabet: regarding your edit of sudo apt-get install lamp-server^, the ^ is not a mistake, it is actually required :)
[22:01] <mralphabet> nijaba: oh, heh, sorry about that ;(
[22:01] <nijaba> mralphabet: np.  soren just fixed the link btw: VMware{{{}}}Tools
[22:02] <mralphabet> nijaba: I'll put the ^ back in
[22:03] <nijaba> mralphabet: thanks
[22:22] <macd> mathiaz, thanks.


[01:01] <jonnydee> hi, I'm just investigating the bzr-svn plugin features and associated worklflows...
[01:02] <jonnydee> now I wonder how the workflow for dealing with svn branches is like...?
[01:03] <jonnydee> I've seen blog posts telling to branch the 'trunk', then branch from the local 'trunk' branch, commit to the latter, and finally merge to the former
[01:05] <jonnydee> But how can I deal with branches tracked within svn? Will it be possible to work on a svn branch using bzr-svn, and finally merging that svn branch to trunk? will it look like I did a merge from a branch to trunk using svn?
[01:06] <jelmer> jonnydee: hi
[01:07] <jonnydee> hi jelmer :)
[01:07] <jelmer> jonnydee: they're much like "normal" bazaar branches, and you can pull from them merge into them and push into them as you would expect to with a regular bzr branch
[01:09] <jonnydee> so it should be possible to emulate a branch-merge workflow of users using svn only?
[01:10] <jonnydee> I'm asking because we have svn, but I would like to use Bazaar and this should completely be transparent to the other svn users
[01:11] <jelmer> jonnydee: yes, although bzr-svn does add revision properties with bzr metadata that can't be represented in svn natively
[01:13] <jonnydee> jelmer: I think that shouldn't be an issue... So I would co "trunk" using bzr, do my commits to a local branch of it, then I push to svn using an svn-url pointing to ../branches/my-branch
[01:14] <jonnydee> then I merge my local my-branch into my local "trunk" checkout and push to svn "trunk"?
[01:15] <jelmer> jonnydee: there's no need for the local mirrors
[01:15] <jonnydee> svn users will then see my branch commits for ../branches/my-branch, and they will realize that I merged that branch into "trunk"?
[01:16] <jonnydee> no need for local mirrors?
[01:16] <jelmer> jonnydee: You'll have to push that branch into /branches/my-branch in svn manually
[01:16] <jelmer> jonnydee: otherwise it won't show up there in svn
[01:17] <jelmer> there is an option in bzr-svn to do that for you, but it's experimental
[01:17] <jonnydee> ok, that's what I assumed, but will they somehow realize that I finally did a merge from /branches/my-branch to /trunk ?
[01:18] <jelmer> not anymore than they currently will
[01:18] <jonnydee> AFAIK svn >1.5 does merge-tracking and I wonder if this information will be propagated when I push my merge to the svn /trunk
[01:20] <jelmer> bzr-svn does set svn:merge-info, but it won't use it for the bzr revision graph
[01:21] <jonnydee> ok, so that's good news. It means that svn users will be able to see, that I merged /branches/my-branch to /trunk, right?
[01:22] <maxb> yes, the metadata will be there if they care to look for it
[01:22] <jonnydee> jelmer,maxb: thank your very much for your fast and helpful feedback :)
[01:26] <maxb> I am toying with trying to get bzr-svn to build a bzr revision graph based on svn:mergeinfo
[01:26] <maxb> I don't think it'll ever be roundtrippable, but it would be a boon for people doing a one-time convert out of svn
[01:27] <jonnydee> maxb: I think that would be really helpful in such cases
[01:27] <jonnydee> I wish you good progress
[01:28] <jonnydee> it's been a pleasure to talk to you! bye, and thanks once more for your attention :)
[01:54] <maxb> Why does bzrlib.tag._merge_tags_if_possible exist?
[01:54] <maxb> I'm trying to see what functionality it provides over tags1.merge_to(tags2), and there doesn't seem to be any
[01:58] <spiv> maxb: it does wha tthe comment says
[02:00] <spiv> maxb: if you want to pass the ignore_master=True arg, but aren't sure the tags implementation supports that API (new in 2.3), then it will try pass the flag, but if it can't it emits a warning and just give the pre-2.3 behaviour (by not passing the flag).
[02:00] <spiv> maxb: it's backwards-compat paranoia, basically
[02:01] <maxb> spiv: ok..... but I know it existed before ignore_master did .... so why? Prescience? :-)
[02:01] <spiv> maxb: when I added the ignore_master param as part of a bug fix I added that function so that cmd_merge (and possibly other bits of bzrlib?) can use it to avoid breaking with e.g. bzr-svn branches if the user is running with an un-updated plugin.
[02:01] <spiv> Are you sure?
[02:02] <maxb> Yes, because I remember looking at its pre-ignore_master implementation, which was more obviously mystifyingly pointless
[02:02] <spiv> I'm pretty sure I remember adding it :)
[02:02] <maxb> hm :-)
[02:02] <spiv> Or, perhaps, updating it to be its current useful form ;)
[02:03] <maxb> right
[02:03] <spiv> But I think I added it.
[02:04]  * spiv looks
[02:05] <maxb> no, it's existed since poolie first implemented tags in branches in 2007 :-)
[02:05] <spiv> Ah, well, probably a hangover from an early implementation of tags.
[02:05] <spiv> I'm guessing it predates the merge_to method.
[02:06] <spiv> Anyway, it serves a useful purpose in 2.3 :)
[02:08] <maxb> Now that's planning ahead :-)
[02:51] <chx> to roll bzr patches i am using  diff --diff-options -up so that i get @@ -136,6 +136,10 @@ function user_pass_reset($form, &$form_s now this is good but now I need patches suitable for patch -p1 and this created patch -p0 patches
[02:56] <chx> bzr diff -p1 gives me a patch -p1 but that does not do what diff -p does (--show-c-function)
[02:59] <chx> there is a largely undocumented option to bzr diff: --format
[03:00] <fullermd> I think that's used by plugins.
[03:04] <chx> fullermd: hi. any solution? I am happy to hack a plugin if necessary :) just dont know where
[03:04] <fullermd> Well, my solution has been to point and laugh at people screaming for -p1 patches.  Not sure that helps you   ;)
[03:05] <fullermd> Does bzr's -p take effect before --using?  That sounds like it would be possible...
[03:05] <fullermd> If possible, it probably should, and would be a bug if it didn't.  And surely it's possible; where else is an external diff getting filenames but from trusting what bzr says?
[03:07] <chx> i am reading diff.py and external_diff has http://paste.pocoo.org/show/343131/  in it
[03:07] <chx> this makes me suspect that the prefix is not taken into account
[03:09] <fullermd> As if showing python code to me is gonna do anything   :p
[03:09] <fullermd> I woulda approached it by just trying it to see...
[03:09] <spiv> You could try passing the diff throught filterdiff
[03:09] <spiv> It's got a --addprefix option
[03:10] <chx> spiv: <3 you.
[03:11] <chx> spiv: now, how can i tell bzr that bzr diff is alias for bzr diff --options -up | filterdiff --addprefix a/
[03:11] <chx> (or more elegantly --addoldprefix a/ --addnewprefix b/ )
[03:11] <spiv> chx: for that I think you need a shell alias :)
[03:12] <chx> spiv: sniff i need to figure out bash code that on bzr foo runs bzr foo but on bzr diff runs the aforementioned ugliness.
[03:13] <fullermd> Nah, just make a 'bzrdiff' alias.
[03:13] <chx> Aliases don't allow for control-flow, command line arguments, or additional trickery that makes the command line so useful.
[03:13] <spiv> Personally I'd go with fullermd's suggestion
[03:13] <chx> fullermd: i guess.
[03:14]  * fullermd still says that -p should affect external diff...
[03:14] <mwhudson> bzr () { if [ "$1" = "diff" ]; then shift; command bzr diff "$@" | diffstat; else command bzr "$@"; fi; }
[03:14] <spiv> Because as you say making bash treat 'bzr diff' differently to 'bzr foo' is going to be fiddly, and I'm fairly lazy.
[03:15]  * mwhudson has been doing too much shell lately
[03:15] <spiv> Or, just hang out for 3 minutes, either way.
[03:15] <spiv> :)
[03:15]  * fullermd huddles mwhudson up in the corner with a blanket and a bowl of hot soup.
[03:15] <chx> thanks
[03:15] <mwhudson> fullermd: thanks
[03:16] <chx> mwhudson: good god
[03:16] <chx> mwhudson: thanks
[03:16] <chx> off to the gym
[09:08] <montywi> vila: bzr check still running (laptop with 2 cores + flash disk)....
[09:09] <vila> montywi: single core used, lots of CPU needed, did it output some progress (even flaky) ?
[09:09] <vila> montywi: or something in .bzr.log (more likely)
[09:09] <montywi> yes, its progressing
[09:10] <vila> ha good, damn, I just realized I didn't recommend -'v' :-( /me bangs head
[09:10] <vila> stupid stupid stupid
[09:10] <montywi> it's now in 'checking graphs 42000/85000
[09:11] <montywi> this is increasing with 1 per 3 seconds
[09:11] <vila> hmm, I don't remember the order in which the checks are performed :-/
[09:11] <vila> 1 out of the 85 000 ? O_o
[09:12] <vila> 85.000 more or less correspond to the number of revisions ?
[09:12] <vila> (not the mainline revs, all the revisions I mean)
[09:17] <montywi> i think so
[09:17] <montywi> so if it continues like now, it will take 43000*3 seconds more to do the check
[09:17] <montywi> or 1.5 days
[09:17] <montywi> (for this stage)
[09:18] <vila> yeah, for this stage :-/
[09:19] <vila> on the other hand, you haven't encounter issues while using this branch/repo since you started the check on a copy right ?
[09:20] <vila> montywi: the format used is 2a right ?
[09:23] <montywi> yes
[09:23] <vila> on both counts ?
[09:23] <montywi> both counts ?
[09:23] <vila> on the other hand, you haven't encounter issues while using this branch/repo since you started the check on a copy right ?
[09:24] <montywi> no problem found with repro during the last 2 days
[09:24] <vila> k
[09:24] <montywi> but i will continue to do rsync backups to be able to repeat any problems that is found
[09:24] <vila> of course 2 days (or even 3) is ridiculously too long for a check...
[09:24] <vila> thanks
[09:26] <vila> montywi: before I forget and in case you need to re-run a check (cough, hopefully not) use BZR_LOG=<different-one> bzr check -v
[09:26] <montywi> ok and thanks for tip
[09:26] <vila> montywi: so we get a clean log with all collected data (-v shouldn't make it really slower ;-/)
[09:27] <montywi> i would like to use the laptop after 2 weeks...
[09:28] <vila> oh good, Apple will be announcing some new models tomorrow, you'll be able to buy a new one, no problem :-}
[09:28] <vila> <desperate sarcasm/>
[09:35] <montywi> Apple? Why on earth would I want to buy an Apple?  I am using *real* machines ;)
[09:36] <montywi> (Machines which software I can use, modify and extend without having to talk with lawyers)
[09:36] <vila> oh, but you can install Ubuntu on them :D
[10:45] <Tak> actually, ubuntu is really nice on my macbook pro
[11:54] <vila> jelmer: make sure you always mentions bug numbers in news entries (how a veteran packager can miss that is beyond my understanding ;-D)
[11:54]  * vila lunch
[11:55] <jelmer> vila: *nod*
[11:55] <jelmer> vila: did I miss one somewhere?
[11:56] <vila> jelmer: hmm, yes, but... I can't remember where right now :-( if you don't find it, don't worry, I'll fix it at release time anyway
[11:56] <vila> I noticed it yesterday if that helps, may be already landed, not sure
[11:57]  * vila really out :)
[11:59] <jelmer> bon appetit :)
[12:16] <shakaran> Hi, Where I can delete the config for bazaar explorer with Windows XP?
[12:19] <shakaran> bzr: ERROR: bzrlib.util.configobj.configobj.ParseError: Invalid line at line "1" with bzr 2.3.0 and I need delete de .conf file or whatever file that store the corrupt file
[12:21] <shakaran> somebody?
[12:22] <jelmer> shakaran: hi
[12:22] <jelmer> shakaran: it's either the .bzr/branch/branch.conf file or the locations.conf or bazaar.conf in your bzr home directory
[12:25] <shakaran> I have a C:\Archivos de programa\Bazaar for bzr home directory
[12:25] <shakaran> I search *.conf files but it dont found any file with conf
[12:26] <shakaran> Archivos de programas = Program files (sorry for the spanish)
[12:27] <shakaran> I have all my local branch's with Eclipse on C:\workspace If I search .conf file there I get:
[12:27] <shakaran> a branch.conf with:
[12:28] <shakaran> parent_location = ../../Earth%20Wars/
[12:28] <shakaran> push_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/spy/
[12:28] <shakaran> submit_branch = file:///C:/workspace/Earth%20Wars/
[12:28] <shakaran> [commit_data]
[12:29] <jelmer> hmm, that all looks reasonable
[12:29] <shakaran> I have other 3 files with branch.conf
[12:29] <shakaran> parent_location = ../../Earth%20Wars/
[12:29] <shakaran> push_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/trunk/
[12:29] <shakaran> [commit_data]
[12:30] <shakaran> third file:
[12:30] <shakaran> bound_location = bzr+ssh://bazaar.launchpad.net/%2Bbranch/ea/
[12:30] <shakaran> bound = True
[12:30] <shakaran> parent_location = bzr+ssh://bazaar.launchpad.net/%2Bbranch/ea/
[12:30] <shakaran> submit_branch = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/spy/
[12:30] <shakaran> [commit_data]
[12:30] <shakaran> last file:
[12:30] <shakaran> bound_location = bzr+ssh://bazaar.launchpad.net/~davidgb-10/ea/trunk/
[12:30] <shakaran> bound = True
[12:30] <shakaran> (sorry about the flooding)
[12:31] <jelmer> shakaran: only the file in the branch you were working in should be relevant
[12:32] <shakaran> I dont see the problems on line 1 for the files. The problem is that bzr-explorer fails on start with a bug
[12:33] <shakaran> http://pastebin.com/azDjMfjm
[12:33] <shakaran> it dont show the invalid file, so I dont know what file is it bad parsed
[12:41] <jelmer> shakaran: one sec, I'll look at the source
[12:42] <jelmer> shakaran: do you have a qbzr.conf file anywhere?
[12:44] <shakaran> on whick folder should be? on bzr home?
[12:44] <shakaran> I report the bug too https://bugs.launchpad.net/bzr/+bug/723691
[12:45] <shakaran> not found a qbzr.conf (on all system)
[12:48] <jelmer> shakaran: It seems like a qbzr issue, hopefully one of the qbzr folks can help out
[13:08] <shakaran> jelmer: I report the bug, I wait then, thanks for your great help
[13:47] <vila> jelmer: that one: https://code.launchpad.net/~jelmer/bzr/multiprocessing-cpu_count/+merge/50812
[13:48] <jelmer> vila: Will fix - thanks for the reminder :)
[13:52] <vila> np ;)
[13:59] <jml> how can you tell what commands a plugin provides?
[14:01] <jelmer> jml: bzr help commands | grep plugin-name
[14:02] <jelmer> jml: I don't think we have anything fancier than that to discover it
[14:02] <jml> jelmer: thanks.
[14:03] <jml> jelmer: I have just discovered how awesome bzr-stats is.
[14:06] <jelmer> jml: :)
[14:06] <jelmer> it could be a lot more awesome though
[14:06] <jml> Yeah, agreed.
[14:07] <jml> I was just thinking, wouldn't it be nice if I could run a command and have it tell me how actively developed this project is
[14:07] <jelmer> jml: Ohloh-style, e.g.:
[14:08] <jelmer> "Decreasing year-over-year activity." / "Large development team" / ... ?
[14:09] <jml> yeah, maybe
[14:09] <jml> well, actually that would be pretty cool
[14:09] <jml> but also something like "6 commits to trunk in the last month"
[14:10] <jml> or maybe a little ascii art graph of num commits per chunk of time
[14:10] <jelmer> ah, hmm
[14:10] <jelmer> I quite like the (new?) blurb on the code.launchpad.net/PROJECT pages with that data
[14:12] <jml> yeah
[14:12] <jml> it's not that new, I think.
[14:13] <jelmer> jml: didn't launchpad also have tiny graphs with the branch activity for a while?
[14:13] <jml> jelmer: it did.
[14:13] <jelmer> jml: Do you know why that was removed?
[14:14] <jml> jelmer: we removed them because showing them on a branch listing for a project is generally uninteresting
[14:14] <jml> and that's where they were shown
[14:14] <jml> e.g. all of the branches for bzr will have almost exactly the same graph
[14:14] <jml> because they are all short-lived branches of trunk.
[14:14] <jml> jelmer: and so rather than rehabilitate the feature, we killed it.
[14:15] <jelmer> ah, ok
[14:17] <vila> jml: any feedback about bzrlib.transform.orphan_policy=move ?
[14:17] <jml> jelmer: do you know how to tell bzr-stats that two people are the same?
[14:17] <jml> vila: no. I'm a loser.
[14:18] <jml> vila: do I just add that line to my bazaar.conf?
[14:18] <vila> jml: yup
[14:18] <vila> bzr.transform.orphan_policy=move
[14:18] <vila> grr don't paste !
[14:18] <jelmer> jml: it looks for similar email addresses/fullnames
[14:18] <vila> :)
[14:19] <jml> vila: thanks. added, will let you know how it goes. (I have a couple of branches up that delete directories)
[14:19] <jelmer> jml: it doesn't support a rename map of any sort (yet)
[14:19] <jml> jelmer: ahh ok.
[14:19] <vila> jml: cool, will fix any related bug
[14:20] <vila> jml: especially the ones with reproducing recipes ;)
[14:20] <jml> vila: heh. will do. :)
[14:22] <jml> jelmer: I have now filed many bugs on bzr-stats. I might actually try to fix them, but, you know how it is.
[14:30] <jelmer> jml: :)
[14:30] <jml> jelmer: I also just filed a bug asking for reviewer stats. I think that's kind of a tough one that might require some kind of hook thing.
[14:30] <jelmer> jml: with regard to reviewers, I think it would be really nice if we can start sticking them in a revision property
[14:30] <jml> +1
[14:37] <jelmer> jml: https://bugs.launchpad.net/bzr/+bug/723740
[14:38] <chx> jelmer: hi. Am I having the honor to talk to the author of bzr-git :) ? If yes, then https://bugs.launchpad.net/bzr-git/+bug/719238 what does this... mean? there is support for push now but it's experimental and shouldnt be...?
[14:43] <jelmer> chx: hi :)
[14:47] <jelmer> chx: looking..
[14:48] <jelmer> chx: so, there has been some initial work on proper push (as opposed to dpush) but it's not ready for prime time use yet
[14:48] <jelmer> chx: it should by default be disabled but doesn't appear to be
[14:49] <chx> ah i see
[14:50] <chx> next question, when i use bzr git-import http://git-testing.drupal.org/project/drupal.git it creates an empty directory with .bzr in it
[14:50] <chx> oh it created a repo?
[14:53] <jhunt> Hi - can someone help me out with bug 723735? It's blocking me from submitting code prior to todays feature freeze.
[14:54] <chx> jelmer: http://web.dodds.net/~vorlon/wiki/blog/bzr-git_case_study.html from reading this i am under the impression that bzr git-import http://git-testing.drupal.org/project/drupal.git should actually download something but it dosnt.
[14:55] <jelmer> jhunt: I can't see that bug because it's private.
[14:55] <jelmer> chx: It should, but that URL is a bit strange (it gives me a 404)
[14:55] <chx> jelmer: weird. git clone works with it unless i am blind.
[14:56] <chx> jelmer: yeah it does
[14:56] <chx> AH ha!
[14:56] <chx> jelmer: that's a git:// url
[14:57] <chx> jelmer: it's just that git ... works with http
[14:57] <chx>  bzr git-import git://git-testing.drupal.org/project/drupal.git is downloading.
[14:57] <jelmer> chx: can you file a bug against bzr-git?
[14:58] <chx> jelmer: https://bugs.launchpad.net/bzr-git/+bug/723751
[15:02] <jelmer> ah, I think I see what's happening
[15:02] <jhunt> jelmer: yes - the bug was created as private by default, but I am unclear as to why.
[15:08] <jelmer> jhunt: can you make it public or pastebin the information you can make public?
[15:09] <vila> jhunt: I often see bug created private when apport is involved...
[15:18] <jhunt> jelmer: bug 723735 is now public
[15:26] <jelmer> jhunt: so, it seems like the "-v" is the bit that breaks
[15:26] <jelmer> jhunt: does it still break if you run without -v ?
[15:35] <jhunt> jelmer: well, I just pushed the same branch using "bzr push -v lp:~jamesodhunt/+junk/foo" and that was fine ?
[15:36] <vila> jhunt: no stacking involved in +junk
[15:36] <jelmer> jhunt: I guess it's stacking related.
[15:36] <jelmer> hmm, gmta :)
[15:37] <jelmer> jhunt: can you perhaps try with the latest bzr (2.3.0) ?
[15:56] <vila> jelmer: You haven't (yet) used the lazy registration of branch formats in the foreign plugins right ?
[15:57] <vila> jelmer: argh, gmta again, loom trunk: branches have diverged :D
[16:01] <vila> jelmer: additional tweak pushed
[16:01] <jelmer> vila: I have, bzr-{hg,svn,git} use it
[16:02] <jelmer> vila: it's not in any releases yet though, so changing things should be possible
[16:02] <vila> jelmer: while you're warmed up, care to use it for looms too ?
[16:03] <vila> jelmer: do you remember if jam is already moving today ?
[16:08] <jelmer> vila: sure, I'd be happy to
[16:08] <jelmer> vila: I'm not sure
[16:08] <bialix> heya all
[16:09] <vila> heya bialix
[16:09] <jelmer> hey bialix, how's your day?
[16:09] <bialix> jelmer: I wish something better
[16:09] <vila> jelmer: could you give your input on https://code.launchpad.net/~vila/bzr/config-expand-options/+merge/50355 ?
[16:09] <bialix> vila: if you have a minute to talk about configs and qbxt
[16:09] <bialix> qbzr
[16:10] <vila> don't ask to ask :)
[16:11] <vila> Pushed up to revision 404.
[16:11] <vila> Huh ? What do you mean file not found ?
[16:11] <vila> errr
[16:11] <vila> :)
[16:11] <bialix> vila: currently qbzr/lib/util.py has its own Config object which is kinda caching object
[16:11] <bialix> it does not try to re-read the real config every time
[16:12] <bialix> *Config class
[16:12] <bialix> it's used to work with qbzr.conf
[16:12] <bialix> this class is using to work with qbzr.conf
[16:12] <jelmer> vila: sure
[16:13] <bialix> vila: what I need to switch to using bzrlib.config instead
[16:13] <vila> bialix: looking at it, it seems to have anticipated bzrlib.config.LockableConfig... except save is explicit
[16:14] <vila> hmm, and {set|get}_option here is {set|get}_user_option there :-/
[16:14] <vila> wow, and BOOKMARKS
[16:15] <vila> bialix: forget it, too early to migrate
[16:24] <bialix> vila: forget what?
[16:24] <bialix> sorry, I had a call
[16:25] <vila> bialix: qbzr needs to save only once, this is not yet available (unless you don't want atomicity anymore)
[16:25] <vila> so you can't migrate yet... unless
[16:25] <bialix> vila: I don't think it's the main goal
[16:25] <vila> ha, ok
[16:25] <bialix> it saves data here and there all the time
[16:25] <bialix> no atomicity, as I can see
[16:26] <vila> another point to consider:
[16:26] <bialix> I need to dig through the history of that code to understand why it written in the way it's written
[16:26] <vila> instead of using a separate config file, you may want to prefix your options with 'qbzr.'
[16:27] <bialix> :-/
[16:27] <vila> and use bazaar.conf or branch.conf
[16:27] <bialix> that'd be bad
[16:27] <bialix> maxb recently said against this
[16:27] <jelmer> vila: I'll have a look at the expand options branch and your udd MPs when I get back
[16:27] <vila> that would mean that in the future, some options may be defined in branch.conf, locations.conf, bazaar.conf
[16:27] <bialix> actually I don't like how it's designed today
[16:27] <vila> bialix: not for all variables
[16:27] <vila> jelmer: great
[16:28] <bialix> we have a lot of runtime variables which is not user editable
[16:28] <vila> jelmer: err, back from what ? :D
[16:28] <jelmer> vila: need to run some errands
[16:28] <vila> jelmer: np was kidding :)
[16:28] <maxb> The thing I objected to was 'bzr viz' storing window sizes in pixels in bazaar.conf, thus making it impractical to version-control my bazaar.conf
[16:28] <vila> maxb: yup, I understood that
[16:28] <bialix> maxb: exactly
[16:28] <bialix> vila: ^ see
[16:29] <vila> bialix: see ^ :D
[16:29] <bialix> vila: I don't like how we store our data in qbzr.conf
[16:29] <vila> that doesn't mean it applies to *all* qbzr config options ;)
[16:29] <bialix> yes, of course
[16:29] <bialix> there are about 5-10 options which are not pixels
[16:29] <maxb> I think it's fine for plugins to rewrite bazaar.conf so long as they only do it in response to the user actually reconfiguring sometime
[16:29] <maxb> *something
[16:30] <vila> yeah, I'll go as far as saying that 'bzr config' should be almost the only one to modify config options
[16:30] <bialix> if we start talking about bzr-explorer then it has a ton of options grouped into subdir
[16:31] <vila> the execptions being --remember, window sizes, bookmarks, aliases, but even bookmarks and aliases should be defined with 'bzr config' and just use special names
[16:31] <vila> bialix: I discovered that a couple of days ago, but most of them are in xml files
[16:32] <vila> there is one horror there still, file extensions are associated with executables by using the list of extensions as the key and the application as the value...
[16:32] <bialix> vila: I'm very dislike code like that in the qbzr:
[16:32] <vila> I wonder why it's not the reverse...
[16:33] <bialix>         config.set_option(name + "_window_size", "%dx%d" % size)
[16:33] <bialix>         config.set_option(name + "_window_maximized", is_maximized)
[16:33] <bialix>         size = config.get_option(name + "_window_size")
[16:33] <bialix> those concatenations make me feel bad
[16:34] <vila> bialix: use helpers
[16:34] <vila> and dots instead of _
[16:34] <bialix> no, I'm trying to say: why we haven't put them into subsections
[16:35] <vila> if you start thinking about option names as python identifiers
[16:35] <bialix> or even into database
[16:35] <bialix> registry
[16:35] <vila> eeerk
[16:35] <bialix> and so on
[16:35] <vila> no subsections please
[16:35] <bialix> that's bad
[16:35] <vila> I don't think we need more than python identifiers here
[16:35] <bialix> I can't agree
[16:36] <vila> that's far more user friendly than subsections with [[[[[very embbeded section]]]]]]
[16:36] <bialix> bzrlib.config has hidden ConfigObj too deeply
[16:36] <vila> not enough obviously
[16:36] <bialix> I need only one layer down
[16:36] <bialix> every q-window should have dedicated section
[16:37] <bialix> for their pixel settings
[16:37] <vila> qbzr.<window_name>.size
[16:37] <bialix> great! can I have one of this?
[16:37] <vila> just do it !
[16:37] <vila> it works today !
[16:37] <bialix> really?
[16:37] <bialix> in 2.3?
[16:37] <vila> in 2.0 even
[16:37] <bialix> ???
[16:38] <vila> '.' has always been valid in an option name
[16:38] <bialix> I never seen it
[16:38] <bialix> ha
[16:38] <bialix> you again put me bacj
[16:38] <bialix> back
[16:38] <vila> ?
[16:38] <bialix> one sec, I'm pastebining
[16:39] <bialix> vila: http://pastebin.com/XQ9PiW7P
[16:40] <bialix> do you like it?
[16:40] <bialix> I'm NOT
[16:40] <bialix> that's a mess
[16:40] <bialix> sorry for my french
[16:40] <vila> :)
[16:41] <vila> Yeah and the user has no idea who is spamming his config file...
[16:41] <vila> subsections won't make it less spammy
[16:41] <bialix> the syntax you have shown "qbzr.<window_name>.size" recalls me about git configs
[16:41] <vila> just because it's like git doesn't mean it's bad
[16:41] <bialix> dot syntax is using to navigate through sections, IIRC
[16:42] <vila> no, sections are used for something else !
[16:42] <vila> that's the whole point
[16:42] <bialix> I thought you said we can navigate through our sections as well
[16:42] <vila> if you use sections to define the name space you can't reuse it to define values for more specific cases
[16:42] <bialix> let's draw a line: I want those automatic pixel settings to be stored separately of user options
[16:42] <vila> 'specific' can be a path, a user name, an url, whatever
[16:43] <bialix> vila: so I need [GEOMETRY] section and q-window names as subsections
[16:43] <vila> bialix: right, put them in a qbzr.windows.conf file then
[16:43] <vila> haaa
[16:43] <vila> scratch above
[16:43] <bialix> qbzr.internals.pixels.settings.dont.edit.it.please.and.even.dont.look.inside.conf
[16:43] <maxb> What do we use sections for at the moment, other than locations.conf ?
[16:43] <vila> a qbzr.windows.conf with window names as sections then
[16:44] <vila> maxb: nothing, exactly my point ;)
[16:44] <maxb> oh, and branch.conf [commit_data]
[16:44] <bialix> yep, famous commit_data
[16:44] <vila> maxb: kill that one, I don't even want to know it has ever existed :)
[16:44] <bialix> (palm face)
[16:45] <vila> bialix: windows size are user specific right ? It's a bit sad it can't be project or even branch specific no ?
[16:45]  * bialix wonders where is the Gary. maybe in the long and sunny vacation on Taiti
[16:45] <bialix> vila: yep
[16:46] <vila> nahhh, in a basement with someone whipping him
[16:46] <bialix> nm
[16:46] <vila> hmm
[16:47] <vila> then no sections for window names :)
[16:47] <vila> you can do as locations.conf and use path as section names instead
[16:48] <vila> one planned feature for configs is that the sections (from path) would be allowed in bazaar.conf to act as default values (as opposed to overriding values in locations.conf)
[16:48] <bialix> vila: so far nobody compains about pixels settings to be non-project adjustable
[16:49]  * vila nods
[16:50] <bialix> vila: I want to extract pixel settings out of qbzr.conf, that's my long standing desire
[16:51] <bialix> I'm not sure I need conf file for them even
[16:51] <vila> config files are for text values that a user may want to edit, ... yeah
[16:52] <bialix> yep
[16:52] <vila> but you need some sort of persistence
[16:52] <bialix> of course
[16:53] <vila> so putting them in a different file with a comment: '# Sorry guys, not for you to edit' could work
[16:53] <bialix> so COnfigObj with subsections provides me a good hierarchy store
[16:53] <bialix> I'm not very good in sqlite
[16:53] <vila> why would you care about how it's represented in the file if you don't intend to edit it ?
[16:54] <bialix> sometimes I need to edit it
[16:54] <bialix> maybe to test something or to workaround something
[16:54] <vila> the dotted notation works quite well for python modules why not for you ?
[16:54] <bialix> the paste I've shown
[16:54] <bialix> the options are not grouped toghethre
[16:55] <bialix> so it's harder to read and analyze
[16:55] <bialix> for me as qzbr dev
[16:55] <vila> sorry ? you mean you want them sorted by what criteria ?
[16:55] <bialix> by window name of course
[16:56] <bialix> they're essentially grouped
[16:56] <bialix> but not in the file
[16:56] <vila> err, the file you pasted is grouped by window name...
[16:56] <bialix> 'cause config preserves the order
[16:57] <bialix> no, it's not
[16:57] <bialix> look for explorer_
[16:57] <bialix> they're spread
[16:58] <bialix> they're spread across the lines
[16:58] <bialix> ditto re log
[16:58] <bialix> and I think diff as well
[16:58] <bialix> sometimes I edit it to test something
[16:58] <bialix> sometimes it's for different reason
[16:59] <bialix> but my point: there are 75 lines of different settings
[16:59] <vila> well, that's your file :)
[16:59] <bialix> yeah, why not
[17:00] <vila> I meant, you're free to organize it as you see fit, we already agree it's not really user oriented
[17:01] <bialix> qbzr.conf is twofold today
[17:01] <bialix> there are user settings as well. I simply omit them when pasting
[17:01] <bialix> while pasting
[17:02] <bialix> vila: I raise this question because of new patch submission: https://code.launchpad.net/~nick-sonneveld/qbzr/fix-258926/+merge/50862
[17:02] <bialix> it touches the same grey area
[17:03] <bialix> some qbzr options are about appearance, some about behavior
[17:03] <vila> well, the in (True, 1) is a subset of get_user_option_as_bool
[17:03] <bialix> yep
[17:03] <bialix> reinventing the wheel for fun and profit
[17:04] <bialix> ok,
[17:04] <bialix> I need to go home now, I'd like to continue this rant later
[17:04] <vila> but yeah, the behavior is a good candidate for branch.conf and this route is via qbzr.<window name?>.versioned_files.show
[17:04] <bialix> I need to think more
[17:05]  * bialix disappears
[17:05] <vila> except you'll need to find a way for the user to decide in which conf file the changes are recorded
[17:05] <vila> too lat :)
[17:05] <vila> e
[18:38] <CoffeeIV> Is there a general way I can undo a "bzr up" if I need to ?  The situation is a live web site maintained under bzr version control.  I think "bzr revert" would un-do edits I made, but if I note a revision number, is there a quick way to back out of a "bzr up" if I need to ?
[18:42] <chx> CoffeeIV: you can bzr up -r somepreviousrev
[18:42] <chx> CoffeeIV: i recommend setting a tag before upping and hten it's easy to back down
[18:42] <CoffeeIV> chx: ok, I will figure out how to do the tag.  Thanks !
[18:43] <chx> CoffeeIV: bzr tag whatever :) and then bzr up -r tag:whatever
[18:43] <chx> CoffeeIV: this is bzr, everything is trivial (until you do something as silly as i did two days ago and even that it was two commands to fix it, lol)
[18:44] <Tak> that's what I love about bzr
[18:45] <Tak> none of this 10 commands, each with 3 optional arguments and nondeterministic side effects, to accomplish a straightforward task
[18:46] <chx> yessss
[19:40] <beuno> http://git-annex.branchable.com/
[19:40] <beuno> that looks interesting
[19:42] <Tak> looks similar to mercurial's bfiles extension
[20:09] <jaypipes> anybody know how to find out who removed or renamed a file that was at one time under bzr source control?
[20:21] <vila> beuno: damn it
[20:23] <vila> beuno: that's on my TODO list for months, far low unfortunately
[20:23] <beuno> vila, WORK FASTER
[20:23] <beuno> :)
[20:25] <vila> :-}
[23:29] <thumper> $ bzr revno :push
[23:29] <thumper> bzr: ERROR: Unsupported protocol for url "lp:~thumper/launchpad/lp-client-cache-move"
[23:29] <thumper> expected?
[23:29] <thumper> wasn't to me
[23:30] <thumper> $ bzr revno lp:~thumper/launchpad/lp-client-cache-move
[23:30] <thumper> 12445
[23:30] <bob2> is it a "lp: urls when you're not logged in are http://" issue?
[23:30] <thumper> nope
[23:30] <thumper> it seems that if you try to use a branch alias, it isn't expanding the branch


[01:21] <tedg> Saviq: Thanks!
[10:38] <Mirv> Saviq: mzanetti: tsdgeos: it is now possible to run Qt 5.6 on vivid too, hopefully it would aid in getting 5.6 bugs fixed. https://wiki.ubuntu.com/Touch/QtTesting updated
[10:39] <Mirv> so silo 048 is for vivid overlay (testing only), silo 011 will be targetting landing for Xenial overlay use (Touch only), and an undecided silo will be targetting landing actually to Ubuntu y-series archives
[10:40] <mzanetti> Mirv, does that mean we're going to update v+o to 5.6?
[10:41] <Mirv> mzanetti: no, we target updating x+o to 5.6 and switch from v+o to x+o
[10:41] <mzanetti> ok
[10:41] <mzanetti> Mirv, ETA?
[10:41] <Mirv> mzanetti: but surely, nothing is 100% set to stone and that's partially the reason I decided to start 5.6 for v+o (in case we'd want to stay on vivid but require 5.6)
[10:42] <Mirv> mzanetti: as soon as everyone starts getting bugs fixed. which should be "now" pretty much. but I think when it seems to be on par with 5.5 at least, it can land to x+o.
[10:42] <Mirv> it is easier to land to overlay than to archives since I don't need to care about KDE, LxQt etc, so it should be possible to land to x+o before y
[10:44] <Mirv> mzanetti: I'm mostly aware of the Unity 8 scope drawing problem as a blocker compared to xenial w/ Qt 5.5. there are also a couple of powerpc and s390x problems which might not block for overlay but need to get sorted out anyway.
[10:45] <Mirv> of course, almost no-one has tested any of xenial lately so it's a bit hard to say. but if Qt 5.6 is a requirement, then there's less reasons to stay too long at 5.5 in x+o.
[10:47] <mzanetti> agreed
[13:17] <Mirv> fixing video playback in Qt 5.6 was easy enough
[13:17] <Mirv> just updating qtvideo-node a bit in similar fashion as I did for 5.5
[13:23] <tsdgeos> :)
[14:29] <Saviq> tsdgeos, yikes, seen bug #1572590 ?
[14:29] <ubot5`> bug 1572590 in unity8 (Ubuntu) "Scopes scrolling scope jumps to mid way" [Undecided,New] https://launchpad.net/bugs/1572590
[14:29] <tsdgeos> Saviq: yeah :/
[14:30] <tsdgeos> wonder if it's similar to the fix i just made
[14:30] <tsdgeos> though doesn't seem likely
[19:33] <mterry> josharenson, heyo!  I'm trying to reproduce the failure you see on geonames translation branch with hebrew
[19:34] <mterry> josharenson, but no luck so far (my test string is for boston: בוסטון)
[20:45] <josharenson> mterry: so you enter that and boston appears?
[20:45] <mterry> josharenson, yeah in Hebrew
[20:46] <mterry> josharenson, I start with ב
[20:49] <josharenson> mterry: 1 min, trying to reproduce my failure, but copy pasting backwards is hard
[20:50] <mterry> josharenson, yeah mixing RTL and LTR is awful
[20:52] <josharenson> mterry: I search for "חיפה" on the phone and get no results (I haven't tried it backwards yet though now that I think about it). This is what happens when I grep for it though http://pastebin.ubuntu.com/15956250/
[20:53] <josharenson> Boston is RTL->LTR, but this is RTL->RTL....
[20:53] <mterry> josharenson, well what do you mean backwards?  Are you saying when typing Boston in Hebrew, you don't start with ב?
[20:54] <josharenson> mterry: No you would, I'm just wondering if when searching for חיפה starting with a ה instead of a
[20:54] <josharenson> mterry: ח
[20:54] <josharenson> mterry: wtf this is hard
[20:54] <mterry> josharenson, so maybe I'm misunderstanding what you're seeing -- if you type ב do you get results?
[20:55] <josharenson> mterry: let me see if the silo is still on my phone, and I'll update the review to be more specific
[20:56] <mterry> josharenson, cool.  Sorry to be dense  :)  Hard to grok RTL for me
[20:56] <josharenson> mterry: I agree
[21:04] <josharenson> mterry: so I set the phone language to hebrew, add He to the OSK, and I see nothing at all when I type any letter (So not Boston, or any city)
[21:04] <josharenson> mterry: I'm updating everything right now in case there were any changes
[21:04] <mterry> josharenson, humph.  I will try with a full fresh reset then...   How do you add a ppa to the phone? When I do it the normal way, I run into this https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1276373
[21:47] <ubot5`> Launchpad bug 1276373 in lxc-android-config (Ubuntu) "invalid cross-device link" [Undecided,Won't fix]
[21:47] <josharenson> (normal way being add-apt-repository)
[21:47] <mterry> josharenson, oh you get that error if you end up upgrading lxc-android-config
[21:47] <mterry> josharenson, you can do add-apt-repository sure
[21:48] <josharenson> mterry: ah I guess I should flash the latest image, and then add the ppa
[21:48] <mterry> josharenson, just when doing apt upgrade, either install a new enough image that it won't pull in lxc-...  or do apt install PKG manually
[21:48] <mterry> josharenson, yeah that helps
[21:48] <mterry> josharenson, I think you can also pin the package...
[21:48] <mterry> josharenson, I don't remember the exact command, but citrain does it


[06:40] <nuvolari> o/ oh hi
[06:41] <nuvolari> from a *cold* bloemfontein
[06:41] <nuvolari> althought I'm told it's been colder
[06:44] <Kilos> lo nuvolari  cold here too
[06:44] <Kilos> yip going to start warming now
[08:57] <charl> good morning
[08:57] <charl> Maaz: coffee on
[08:57]  * Maaz washes some mugs
[09:01] <Maaz> Coffee's ready for charl!
[09:14] <charl> Maaz: thanks
[09:14] <Maaz> charl: Sure
[13:17] <Kilos> haha graeme you now a Guest32143   here
[13:17] <Kilos> hi charl
[13:17] <Kilos> nuvolari  wanneer vat jy die lang pad
[15:53] <charl> hi Kilos :)
[16:14] <magespawn> good evening all
[16:28] <Kilos> hi there magespawn
[16:28] <Kilos> you need to set Quassel to show when you are afk
[16:29] <magespawn> yup i used to do that, keep forgetting, will do it from now
[16:29] <Kilos> lol
[16:29] <Kilos> the pro also doesnt set his. i dunno why
[16:30] <Kilos> he likes to sneak in without anyone seeing i think
[16:31] <Kilos> professional lurker
[16:31] <magespawn> forgetful
[16:31] <Kilos> you still get messages even though it shows away hey?
[16:33] <magespawn> yup it is just so that people do not try to talk to you
[16:33] <Kilos> ah
[16:34] <magespawn> like so
[16:34] <magespawn> see i can still talk even
[16:34] <magespawn> it is just /away and /back
[16:34] <Kilos> i see you online
[16:34] <Kilos> ah
[16:35] <Kilos> ya the pro is too old to remember that
[16:35] <magespawn> you can also run those commands so that if you are online but busy else where people will not bother you
[16:36] <magespawn> i am not sure but i think he and i are close in age, lol
[16:38] <Kilos> lol
[16:38] <Kilos> no hes way older man
[16:44] <magespawn> really?
[16:44] <Kilos> ya
[17:05] <magespawn> i find no proof of this online, but that is not surprising, inetpro would not put that up anyway
[17:30] <Kilos> hi StonedAlchemist
[17:30] <StonedAlchemist> Kilos, hi!
[17:35] <Kilos> hi ThatGraemeGuy
[17:36] <StonedAlchemist> How are you Kilos ?
[17:37] <Kilos> good tks StonedAlchemist  and you?
[17:37] <StonedAlchemist> A bit hungover but I'm fine.
[17:37] <Kilos> ow
[17:40] <StonedAlchemist> Lol
[17:40] <Kilos> self inflickted pain sjoe
[17:40] <Kilos> inflicted
[17:40] <Kilos> that thing
[17:42] <StonedAlchemist> Yip but it still feels good..
[17:42] <Kilos> hehe
[17:49] <magespawn> i am not so sure about the hangover feeling good
[17:49] <Kilos> yeah
[17:53] <StonedAlchemist> yeah no the hangover sucks but the events leading up to the hangover is what is good.
[17:54] <Kilos> hahaha
[17:55] <magespawn> well that was interesting
[17:55] <Kilos> wb magespawn
[17:55] <magespawn> wonder what it pinged? me or the core
[18:05] <magespawn> ty
[18:12] <magespawn> ah well at least it rejoined automagically
[18:13] <Kilos> yeah
[18:13] <magespawn> busy updating the machine that the quassel is running on
[18:14] <Kilos> aha
[18:35] <ThatGraemeGuy> 'lo
[18:36] <captine> hi all
[18:43] <magespawn> hi captine ThatGraemeGuy
[19:06] <magespawn> Kilos i have a free vps from these guys http://haphost.com/ they also do free web hosting
[19:07] <magespawn> it did take about a week or so for it to be set up
[19:11] <charl> hi magespawn
[19:11] <charl> hi captine, ThatGraemeGuy
[19:12] <charl> magespawn: how is that possible... what is the catch
[19:15] <charl> i would love to sign up but i'm suspicious
[19:17] <ThatGraemeGuy> hey charl
[19:18] <ThatGraemeGuy> lol
[19:18] <ThatGraemeGuy> 128MB RAM
[19:18] <ThatGraemeGuy> there's the catch
[19:19] <charl> haha
[19:20] <charl> is that even possible.... i guess it is
[19:20] <charl> nah then i'll rather pay a few euro and get a real vps
[19:23] <magespawn> charl no help and i think there is a cap on the data transferable
[19:23] <magespawn> charl just something for me to try my hand at
[19:43] <superfly> ohi
[19:46] <charl> hi superfly
[21:27] <Kilos> night all. sleep tight


[01:06] <asac> stgraber: cjwatson: i dont think i asked for two layers of feeding to stable. lets chat tomorrow about it; if you still have quotes from back then, it might help me rememeber what i thought/meant that got interpreted like this :)
[01:12] <stgraber> asac: the two layers is what you asked to setup for the current implementation (utopic-proposed gets manually copied to utopic which then gets manually copied to stable) as you wanted more control as to what gets into stable than just have stable be a straight alias for utopic or whatever our stable series is
[01:19] <asac> stgraber: ok, i sense there might be confusion again as i am thinking about devel and stable only... and not really utopicetc.
[01:20] <asac> stgraber: with rtm feeding into stable-proposed soon, i guess that part of straight alias is void anyway ?
[01:20] <asac> e.g. utopic feeds to devel-proposed/devel and ubuntu-rtm/utopic feeds into stable-proposed/stable?
[01:21]  * asac thinks it would be easier to refer to uptopic as our current devel archive series (which kind of already exists as an alias for upload and apt, no?)
[01:22] <asac> and ubnutu-rtm/utopic referring to our "stable" archive series for touch in that senes
[01:22] <asac> assuming we have branched ubuntu-rtm i would think that ubuntu/utopic -> devel-proposed ... and ubuntu-rtm/utopic -> stable-proposed
[01:24] <asac> anyway, lets sync tomorrow when colin is awake too
[01:25]  * asac waves; be back in a few hours
[04:43] <constantine> Hey guys. I was just curious: do Canonical use -flto option to compile packages? It looks like good optimization, but looks like nobody uses it for unknown reasons.
[04:51] <constantine> Probably nobody uses it cuz -flto option(stands for "link time optimization") relatively fresh. If this is the reason, then I hope I give good hint, how to make Ubuntu a bit faster ;)
[07:19] <dholbach> good morning
[07:38] <dholbach> Noskcaj, any luck with 1346056?
[07:40] <LocutusOfBorg1> ScottK, you there?
[07:41] <LocutusOfBorg1> sorry but I didn't like too much your upload https://launchpad.net/ubuntu/+source/wxpython3.0/<IP_ADDRESS>+dfsg-2ubuntu1
[07:41] <LocutusOfBorg1> you fixed a bug in the _wrong_ place
[07:41] <LocutusOfBorg1> the build failure is a fault in wxwidgets, and it has been spotted because ubuntu has a _bad_ cairo version
[07:41] <LocutusOfBorg1> so the right fix is:
[07:41] <LocutusOfBorg1> fix 1353362
[07:43] <LocutusOfBorg1> wait for wxwidgets3.0 to be uploaded in debian (hint: the fix is there http://anonscm.debian.org/cgit/freewx/wx.git/commit/?h=wx3.0-debian&id=7bbc39c4018cee0fa2e021e58ea79bd5de241785 )
[07:43] <LocutusOfBorg1> and then rebuild wxpython.
[07:43] <tvoss> seb128, good morning. Not sure you are the right person to ask, but I was looking at the dbus spec and stumbled across GetConnectionCredentials, which would be super useful to have. However, it's only supported from ver 1.7 onwards. Do you know if we have plans to update to that version?
[07:43] <LocutusOfBorg1> this is a bug in _every_ package using wxwidgets, not just wxpython, so please next time fix it properly ;) many thanks
[07:44] <seb128> tvoss, see https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1320422
[07:45] <seb128> tvoss, tyhicks is/was working on it
[07:46] <tvoss> seb128, ack and thx, will follow up with him then
[07:46] <seb128> thanks
[08:59] <Noskcaj> dholbach, Just got back into town then. I made a crappy patch to remove turbogears2, but i'm waiting for a responce from the debian zope team about transaction before i do anything
[09:00] <dholbach> Noskcaj, ok cool - maybe you can follow up on the bug report to just mention where things stand
[09:00] <Noskcaj> ok
[09:04] <cjwatson> asac: the series in the ubuntu-rtm distribution is called 14.09 rather than utopic - since RTM isn't tied to the Ubuntu release cycle I didn't think it made sense to tie it to Ubuntu release codenames
[09:06] <cjwatson> asac: stgraber set it up for me on Friday as ubuntu-touch/ubuntu-rtm/14.09-proposed and ubuntu-touch/ubuntu-rtm/14.09, on the system-image side; I think that makes sense provided that we also have a stable alias (and maybe a stable-proposed alias, I don't care much).  The utility of that is that in a few months' time we can potentially keep working on updates to 14.09 while also preparing for a switch to 14.12 or whatever
[09:10] <doko_> Noskcaj, the best thing is to package it yourself, and then point the team to it
[09:11] <Noskcaj> doko, I wanted to check if there was a reason for no updates other than "maintainer MIA"
[09:12] <doko> Noskcaj, you didn't write that in your email
[09:12] <Noskcaj> no, i should have
[09:12]  * Noskcaj leaves to get food
[09:16] <doko> mlankhorst, mesa ping
[10:32] <asac> cjwatson: ok thanks! devel{-proposed} points to ubuntu-touch/ubuntu/utopic{-proposed} accordingly i guess?
[10:34] <cjwatson> asac: Just ubuntu-touch/utopic-proposed but yes
[10:34] <cjwatson> I think
[10:34] <asac> ack
[10:35] <cjwatson> Not totally sure how that works, as it's not in the config file
[10:36] <cjwatson> Oh, well, it's in http://system-image.ubuntu.com/channels.json
[10:36]  * asac reads
[10:36] <cjwatson> Some of those have "alias" entries
[10:38] <asac> yeah see it
[10:40] <asac> think makes sense as it is now
[10:53] <jamespage> cjwatson, morning
[10:54] <jamespage> cjwatson, do you have any ideas as to why a block device might have a first partition which is identifying as a character device?
[10:54] <jamespage> (context - https://bugs.launchpad.net/charms/+source/ceph-osd/+bug/1343199)
[10:57] <cjwatson> jamespage: err doubleyou tee eff
[10:57] <cjwatson> jamespage: get a udev trace maybe?
[10:57] <jamespage> cjwatson,  that was my reaction as well
[10:57] <jamespage> cjwatson, will try to
[10:57] <cjwatson> jamespage: that really should be impossible regardless of the structure of the partition table, so while looking into the partition table might illuminate the problem somehow, the fix shouldn't be there
[10:58] <jamespage> cjwatson, ack
[10:59] <cjwatson> I don't even know how you'd do that in a udev rule if you wanted to.  Doesn't that come from the kernel?
[11:00] <cjwatson> udev_device_new_from_devnum is probably the starting point for tracking it down within udev
[11:15] <jamespage> cjwatson, I've asked that one of the reporters debug when it happens again
[11:33] <doko> xnox, did you finish your work on creduce?
[14:46] <ScottK> LocutusOfBorg1: Changing package depends won't provide a missing build-depend, so your change is orthogonal to mine.  In any case, once there's a version in Debian that will build on Ubuntu too, mine should definitely by sync'ed over.  Additionally, I find your approach very aggressive and unwelcome.  Calm down.
[14:51] <Mirv> a packaging ack for unity8 desktop file moves + removal of an upstart job would be appreciated: https://ci-train.ubuntu.com/job/landing-006-2-publish/50/artifact/packaging_changes_unity8-desktop-session_1.0.12+14.10.20140811-0ubuntu1.diff
[15:02] <jamespage> doko, apologies its taken me so long to get to the libcommons-logging-java/tomcat8 unpicking
[15:03] <jamespage> but I've hopefully fixed that now so comp mismatches might be a little more usable shortly
[15:07] <doko> jamespage, \o/
[16:41] <arrrghhh> infinity, bdmurray was there some specific bug that needed squashing before updating the meta-release-lts page?
[16:41] <bdmurray> arrrghhh: coincidentally, I just did that
[16:42] <arrrghhh> ohai look at that
[16:42] <arrrghhh> thank you :)
[16:43] <infinity> arrrghhh: There were bugs we fixed last week.  The only bug over the weekend was that it was a weekend.
[16:44] <arrrghhh> works for me.  thanks so much!
[16:45] <rbasak> bdmurray: nack on bug 1252843. AIUI, the exact same problem will occur on V->W upgrade when V is installed on an HWE stack.
[16:46] <infinity> slangasek: I uploaded a new shim-signed to unblock your shim in proposed (and now my d-i and the kernel), but what I didn't check is if you need/want to mirror your fallback stuff in -signed as well somehow.
[16:46] <infinity> slangasek: (My upload was just a straight rebuild to fix deps)
[16:46] <slangasek> infinity: um!
[16:46] <bdmurray> rbasak: okay
[16:46] <rbasak> bdmurray: correction. U->V when on a V HWE stack.
[16:46] <slangasek> infinity: can you remove this from the queue or is it too late?
[16:46] <slangasek> infinity: shim is SUPPOSED to block in -proposed until the binary signing is done
[16:46] <infinity> slangasek: My upload WOULD have been a straight rebuilt to fix deps, if it hadn't FTBFS. :P
[16:47] <slangasek> infinity: yeah, please don't touch this
[16:47] <infinity> slangasek: Err, oh.  Well, it's blocking everything else. :/
[16:47] <slangasek> why are things blocking on it?
[16:47] <rbasak> bdmurray: I think this bug affected a large number of people. I saw many complaints about a blank screen on boot, and this was both reproducible and sounded like a reasonably common use case.
[16:47] <infinity> slangasek: Oh, shim-signed CONTAINS the blob.  Right.  I was thinking it was like grub/linux.  Derp.
[16:47] <rbasak> bdmurray: agree that there's no point fixing HWE stack upgrades on P for this bug, but we should do something about it for T HWE.
[16:48] <infinity> slangasek: It's blocking because shim-signed has a versioned dep on shim, which causes d-i to FTBFS, which blocks the kernel.
[16:48] <slangasek> blahhh
[16:48] <infinity> slangasek: Perhaps this should be staged in a PPA, if the turnaround time it on the order of weeks instead of hours.
[16:48] <slangasek> infinity: so in the future, I guess that means we should upload shim to a distro ppa instead of directly to -proposed, yeah
[16:48] <slangasek> any way that we can route around this for d-i in the present instance?
[16:49] <infinity> slangasek: Can I delete shim/shim-signed from -proposed so d-i is happy, and then we can sort out what to do?
[16:49] <slangasek> infinity: only if you can recover it
[16:49] <infinity> slangasek: I can delete and copy it back in, sure.
[16:49] <slangasek> this binary has been submitted to Microsoft, it needs to not get lost :)
[16:49] <infinity> slangasek: Deletion isn't particularly fatal.
[16:50] <slangasek> where do you stash it to make sure it doesn't disappear?
[16:50] <infinity> slangasek: The librarian.
[16:50] <infinity> slangasek: We can just copy it back in over itself, like nothing happened.
[16:51] <slangasek> ok
[16:51] <slangasek> then yes, as long as we're sure it'll find its way back safely when it needs to, go ahead
[16:52] <infinity> slangasek: So, a landing that takes this long is a poor fit for a CI silo, perhaps we should just give you a devirt of your own (or a foundations one, so it's not a bus issue), and use that for shim exclusively.
[16:52] <cjwatson> foundations devirt sounds good for this
[16:52] <slangasek> agreed
[16:55] <infinity> slangasek: Want to create a "Shim Staging" PPA under ~canonical-foundations and I'll do the magic to make sure it's distro-sane, and copy these binaries there, so we don't lose them?
[16:56] <infinity> s/lose/forget about/
[16:57] <slangasek> infinity: de-virt me? https://launchpad.net/~canonical-foundations/+archive/ubuntu/shim
[16:57] <infinity> slangasek: Fixing it up now.
[16:59] <slangasek> and copy done, I think: https://launchpad.net/~canonical-foundations/+archive/ubuntu/shim/+packages
[17:00] <infinity> Oh, I was just doing that.
[17:00] <infinity> Looks good.
[17:00]  * infinity cancels his.
[17:14] <LocutusOfBorg1> ScottK, sorry if I seemed aggressive, wasn't in my mind to be ;)
[17:15] <LocutusOfBorg1> this is why I ended my question with the ";)"
[17:15] <LocutusOfBorg1> sorry again
[17:16] <LocutusOfBorg1> and anyway, sorry but I didn't understand your answer :D
[17:16] <LocutusOfBorg1> wxpython3.0 depends on wxwidgets3.0 and the build failure was in wx code
[17:17] <LocutusOfBorg1> so the fix should be done in wxwidgets3.0, rather than in wxpython
[17:21] <LocutusOfBorg1> because a program that uses libwxgtk3.0-dev should automatically drag in the mesa-common-dev package, rather than adding it manually
[17:21] <LocutusOfBorg1> (please correct me if I'm saying something wrong, and sorry again for being unpolite, it wasn't in my intentions)
[17:23] <psivaa> cjwatson: infinity: i'm investigating an issue with the i386 desktop VM installations
[17:23] <psivaa> the installation with the preseed http://paste.ubuntu.com/8018805/ succeeds but the host machine is not able to ssh to the client VM
[17:24] <cjwatson> can you tell whether the client VM's network is up?
[17:24] <psivaa> purging openssh-server and reinstalling in the VM fixes the issue. i.e. being able to ssh from the host machine
[17:25] <psivaa> cjwatson: i think the network is up since i am able to apt-get update from it (after logging in to the Virt machine manager UI)
[17:25] <cjwatson> psivaa: was openssh-server definitely installed beforehand?  I don't think pkgsel/include is honoured by ubiquity (in general it doesn't have much in the way of package selection)
[17:25] <cjwatson> psivaa: or are you handling that in a late_command hook instead?
[17:26] <psivaa> cjwatson: yes, i think utah deals with it
[17:26] <psivaa> cjwatson: and i confirmed that openssh-server was installed and sshd was running
[17:26] <cjwatson> psivaa: ok, could you take a backup copy of /etc/ssh/ before purging openssh-server and compare it with what's there afterwards?
[17:26] <psivaa> but sshd_config was empty
[17:26] <cjwatson> empty?  blink
[17:26] <cjwatson> psivaa: can you point me at the utah code here?
[17:27] <cjwatson> psivaa: also any installer logs you have
[17:28] <psivaa> http://d-jenkins.ubuntu-ci:8080/job/psivaa-utopic-desktop-i386-smoke-default/6/artifact/log/utah-72-boot.log has the openssh-server installation details and let me point to the utah code for it
[17:28] <cjwatson> jibel: Any guesses as to why I might be getting this kind of result from adt-run with adt-virt-qemu?  http://paste.ubuntu.com/8018927/
[17:28] <cjwatson> I just added the ls -lR / whoami there to rule out obvious permission issues
[17:30] <cjwatson> psivaa: The only reason I can see in openssh-server.postinst why this could happen is if something had touched /etc/ssh/sshd_config before openssh-server was installed
[17:30] <ScottK> LocutusOfBorg1: OK.  I don't claim it was the best solution, just that it worked.
[17:31] <psivaa> cjwatson: http://bazaar.launchpad.net/~utah/utah/dev/view/head:/utah/provisioning/provisioning.py#L741 and http://bazaar.launchpad.net/~utah/utah/dev/view/head:/utah/provisioning/provisioning.py#L798 would be relevant
[17:31] <cjwatson> psivaa: If that file exists, the postinst just modifies it rather than writing a fresh one.  I guess I could change it to test for empty-or-zero-size, but this seems like it must be a bug somewhere else
[17:32] <cjwatson> No mention of sshd_config in utah though
[17:32] <psivaa> cjwatson: i dont think we are touching the file before installing and on amd64 installs this is not an issue. the sshd_config comes with the entries needed
[17:32] <cjwatson> Definitely no idea why it might be arch-specific
[17:32] <cjwatson> psivaa: So, literally empty /etc/ssh/sshd_config, i.e. zero-bytes?
[17:33] <psivaa> cjwatson: it was empty.. dint check if it was with zero-bytes
[17:33] <psivaa> I'll run another test to check
[17:43] <LocutusOfBorg1> thanks ScottK , I hope I can ask you to sync as soon as we fix it in debian :) have a good day
[17:44] <ScottK> LocutusOfBorg1: Yes, I'd much prefer it sync'ed from Debian, just let me know.
[17:46] <LocutusOfBorg1> +1 I love fixing debian bugs and syncing ubuntu ;)
[17:47] <LocutusOfBorg1> hint: cairo needs merging, it will fix the "bug" at the actual debian style
[17:47] <LocutusOfBorg1> (cairo is the reason why nobody noticed the bug in debian)
[17:47] <LocutusOfBorg1> bug 1353362
[17:47] <LocutusOfBorg1> (leaving sorry)
[17:52] <ScottK> zul: Your upload of ironic has been sitting in proposed for a month.  Fancy fixing it?
[18:04] <psivaa> cjwatson: http://pastebin.ubuntu.com/8019255/ is the /etc/ssh/ listing
[18:06] <psivaa> cjwatson: and /var/log/apt/history.log does not contain any reference to openssh-server
[18:07] <psivaa> neither does dpkg.log
[18:39] <jdstrand> @pilot in
[18:40] <cjwatson> psivaa: That's incredibly confusing.  My guess is filesystem corruption - try forcing the installation to sync harder (er, in some way) before shutting down?
[19:22] <jibel> cjwatson, from the paste, I've no idea. Are you on trusty (the version string suggests so)? Is the package available somewhere? I'll have a look.
[19:45] <Lysian> Hi, in Precise Release Notes https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes, is a dead link to changes of 12.04.5 https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/ChangeSummary/12.04.5
[20:55] <jtaylor> doko: do you have a hint where to look to add -Wl,--no-as-needed before the sanaitizer links in the gcc commandline, some spec file maybe?
[20:57] <jtaylor> it is done for -lc -lgcc but I can't figure out where
[21:05] <jtaylor> mh I guess I found it in gcc.c
[21:33] <ScottK> Would someone please requeue the libkdegames test for i386.
[21:52] <xnox> doko: creduce.... no, doesn't ring a bell.
[21:59] <sarnold> hey xnox :)
[21:59] <xnox> sarnold: hola =)
[22:00] <doko> xnox, fixed it
[22:01]  * xnox this is a public service announcement: "nobody likes thinkpad's nipple. it's just that touchpad has horrible tap/drag/scroll sensitivity, awful touchpad button and feels like sandpaper rather than a good quality touchpad"
[22:02] <kklimonda> hmm, i really like x240 touchpad
[22:03] <kklimonda> and yeah, im not using the trackpoint at all now
[22:03] <xnox> i have x230 and it doesn't compare to e.g. macbook from 2006
[22:03] <ogra_> xnox, that totally contradicts what i always hear from thinkpadders who are buying them because they are nipple fans
[22:03] <kklimonda> mhm, they have revamped it in x240 again
[22:04] <xnox> ogra_: a thinkpad nipple is forced upon me =) taking my microsoft sculpt keyboard and mouse combo with me tomorrow
[22:05] <kklimonda> ogra_: i'm starting to think that people are just in an abusive relationship with their trackpoints ;)
[22:06] <ogra_> i find thinkpad nipples pretty awful ... though not as bad as the toshiba copy that i had to use once with a company laptop
[22:07] <kklimonda> i find thw nipple in x240 pretty bad, and now im left wondering if it has always been that way, or did they break it at some point
[22:07] <ogra_> i think they call them "accupoint" or some such
[23:32] <jdstrand> @pilot out
[23:42] <bdmurray> rbasak: Did you try the debian patch for bug 1257186? it looks a bit different than the debdiff you posted.


[18:46] <OvenWerks> in 15 min or 45? or another time?  :)
[18:47] <krytarik> I don't knooow! :D
[18:49] <OvenWerks> Anybody else around?
[18:50] <OvenWerks> (controls hasn't moved much)
[19:57] <eylul> Sorry OvenWerks technical problems
[20:48] <OvenWerks> So much for that one  :)
[20:49] <eylul> which one?
[20:49] <OvenWerks> this one (meeting)
[20:49] <eylul> oh right
[20:49] <eylul> I am very sorry
[20:49] <OvenWerks> No worries
[20:50] <OvenWerks> I have not much to report
[20:51] <eylul> to be honest neither do I.  I am installing ubuntustudio to a new laptop so a few bug reports. but that's the extent of last few days I am afraid
[20:52] <OvenWerks> I haven't done any testing. My P4 box doesn't like USB sticks and I don't have lots of DVDs to use up...
[20:54] <eylul> *nods*