[00:13] <thumper> hallyn: hey there
[00:13] <thumper> hallyn: still around?
[00:14] <thumper> hallyn: I'm looing into the lxc template failing to stop issue on trusty with juju 1.22 with katco
[00:14] <thumper> hallyn: looking through the log files, it became obvious that the problem was intermittent with many other lxc containers and our template mechanism working on other machines
[00:14] <thumper> hallyn: so the race condition option seems most likely
[00:14] <thumper> hallyn: however I'm not entirely sure what we are racing with...
[02:22] <hallyn> thumper: well, whatever does the first lxc-create or lxc-start, can you have it do a 'ps -ef' and 'sudo aa-status' and 'dpkg -l'?  Question is whether package install is complete, and if not why not.
[04:51] <linocisco> hi all
[04:52] <linocisco> i have ddns registered at no-ip.com. I have no registered domain
[04:55] <linocisco> i want to setup webserver on virtualbox using dynamic dns. what do I do?
[06:19] <tash> when I run this from the CLI: curl http://myurl/cgi-bin/my-file.pl it returns a string "ok" which I expect. But, when I put that into a shell script like this: REQUEST=`curl http://myurl/cgi-bin/my-file.pl`  print $REQUEST   it spits this out: Error: no such file "ok"
[06:19] <tash> can anyone explain why it doesn't just show "ok" when I run it from a script, rather than display an Error
[06:22] <excalibr> tash, print?
[06:23] <excalibr> you want echo or printf if that is shell script
[06:26] <tash> yeah, lol
[06:27] <tash> i actually realized that after I put that here...I've been working on perl scripts and shell scripts today and got some syntax confused
[06:27] <tash> pffff, thx excalibr
[07:38] <brianw> using ubuntu 14.04 on (2) physical machines to host my glusterfs backup & lxc host for samba ad/dc containers & glusterfs/ctdb/samba DFS server containers. Each physical machine can run the network without the other. When the other comes back online, all is synced...
[07:38] <brianw> Lovely!
[07:39] <brianw> I just wish glusterfs supported btrfs backend with snapper support.
[08:11] <lordievader> Goodmorning.
[08:22] <excalibr> Upstart question, in script stanza, do your codes in it always get executed when you start/stop your upstart job?
[08:38] <excalibr> never mind
[09:06] <voidfire> anyone able to help me? tryin to setup vhosts like cpanel (per user)  in ubuntu
[09:06] <voidfire> tried manually. tried with webmin.. i dont know what im missing. I get forbidden eerors as well as I have fiddle with the permission of the  said user folder to try stuff out
[09:09] <lordievader> !webmin
[09:09] <lordievader> voidfire: ^ is likely why you get those errors.
[09:10] <voidfire> but I was trying first manually :/
[09:10] <voidfire> i tried throught webmins after I failed my self
[09:10] <voidfire> but thanks for your input..its better than nothin
[09:11] <voidfire> shall I go with ISPconfig3?
[09:13] <lordievader> Just pointing out what I know ;)
[09:13] <voidfire> tell me more of what you do know :)
[09:14] <voidfire> pweasee
[09:15] <lordievader> What are you trying to do exactly?
[09:15] <voidfire> im setting up 2 new ubuntu 14.04 servers (vps)
[09:16] <voidfire> i want inside one of them to make virtual hosts  on apache for every user
[09:16] <voidfire> so each user will be able to develop php/html and serve those files from /home/$USER/public_html
[09:16] <voidfire> similar to what a cpanel server does
[09:17] <voidfire> i know , ive googled for the matter but each article shows different proccess or misses steps and Im puzzled
[09:17]  * voidfire is confused
[09:17] <lordievader> http://httpd.apache.org/docs/2.4/mod/mod_userdir.html
[09:17] <voidfire> ive enabled that module
[09:18] <voidfire> lets read up
[09:18] <lordievader> voidfire: That should be all, then you should be able to acces http://localhost/~username/
[09:18] <voidfire> kay , thanx
[10:19] <frobware> anybody aware of dpkg SEGV issues on arm64 since Monday this week?
[10:54] <Odd_Bloke> frobware: On vivid?
[11:20] <frobware> Odd_Bloke, trusty
[11:20] <frobware> Odd_Bloke, I went back to http://cloud-images.ubuntu.com/trusty/20150313/trusty-server-cloudimg-arm64-disk1.img which is OK for my test case (installing devstack)
[12:44] <mgz> rbasak (or someone) licencing question:
[12:45] <mgz> we're currently removing some files from our tarball when building juju because they come from a w3c testsuite
[12:45] <mgz> looking at their docs again today, they now seem to offer 3-clause bsd as an option as well as their own non-free licence
[12:46] <mgz> so is bundling w3c test suites okay now?
[12:51] <strikov> mgz: very good point; i don't know the answer (need to think about it) but i just figured out that we *include* this testsuite as src/golang.org/x/net/html/charset/testdata/
[12:52] <strikov> mgz: we now have two copies of pretty the same code (maybe different versions) at golang.org/x/net and code.google.com/p/go.net/
[12:52] <mgz> strikov: so, the juju tarball we build explictly strips that
[12:53] <mgz> but the move is why I'm looking at it again :)
[12:53] <strikov> mgz: i found it in the tarball for 1.23-beta3
[12:53] <strikov> mgz: it removed from code.google.com/p/go.net/ but not from golang.org/x/net
[12:53] <mgz> >_<
[12:54] <strikov> mgz: do you know the reason why we have two versions of the same code?
[12:55] <mgz> code.google.com is shutting down, so everything is moving
[12:55] <mgz> I suspect not all things have moved the import over yet
[13:04] <strikov> mgz: origin link in the testdata/ folder doesn't work for me; what is the origin repo for these tests?
[13:06] <jelly> hi, is 15.04 server going with systemd as default init or is that delayed?
[13:07] <mgz> strikov: looks like it's that url s/repository\///
[13:07] <mgz> wait, other way around
[13:07] <mgz> add repository in, after tests/ in the path
[13:08] <strikov> jelly: systemd is default for vivid
[13:09] <strikov> mgz: ah, thanks; i was confused by the fact that they call them the-input-byte-stream-***
[13:12] <strikov> mgz: do you mean this by saying about bsd license: http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231
[13:13] <strikov> mgz: sorry, found right one
[13:13] <mgz> strikov: I was reading the "licenses for w3c test suites" page
[13:14] <rbasak> mgz, strikov: sounds OK, as long as the version you're shipping was released under the 3-clause bsd license as an option. I trust strikov will take care of checking that :)
[13:17] <strikov> mgz: rbasak: how about changing README in the tests folder to include 'all *.html files' are (c) by w3c and the following license applies <license from http://www.w3.org/Consortium/Legal/2008/03-bsd-license.html>
[13:17] <mgz> strikov: I'd like to do that, as an upstream patch at least
[13:18] <mgz> having a readme with a dead link and no mention of licencing at all is dumb
[13:33] <strikov> mgz: do you plan to file upstream bug to google or I need to do that?
[13:34] <mgz> strikov: I can
[13:34] <strikov> mgz: ok, thanks; ping me please when done so i can track it (i need to include a link to the bug to debian/copyright)
[13:42] <faylite> I get lots of lag while using ssh on a local network, 1-10 seconds of delay when typing etc. Any suggestions, it's a server on the same local network as me.
[13:42] <faylite> And it's connected to wifi......
[13:44] <lordievader> Bad wifi connection? Long latency?
[13:44] <faylite> Any commands to measure it? Probably bad connection but I'm not sure.
[13:46] <lordievader> faylite: /proc/net/wireless can tell you.
[13:50] <faylite> Not sure what's good or bad,  wlan0: link:58.  level:-52.  noise:-256
[13:53] <faylite> Ok nvm looks like the signal is pretty bad and unstable, guess I'll try plugging in the Alfa
[13:53] <lordievader> Link level isn't optimal.
[14:00] <strikov> mgz: i just updated the bug; imo, we need to remove this testsuite from 1.23 tarball; we will return it back but only when golang guys fix the issue upstream
[14:01] <strikov> mgz: i don't want to be in a position when we have 1.23 release but we can't package it because golang upstream doesn't fix it yet
[14:03] <mgz> strikov: sure
[14:05] <strikov> mgz: thanks
[14:07] <mgz> strikov: what's the tarball you are looking at? because it really should ahve the old location stripped already
[14:07] <strikov> mgz: yes, old location is stripped; i'm talking about new location
[14:07] <strikov> mgz: i.e. we need to remove both :)
[14:07] <mgz> okay, I have that change done, will propose now
[14:07] <strikov> mgz: awesome
[14:46] <caribou> utlemming: ping,
[14:47] <utlemming> caribou: pong
[14:47] <caribou> utlemming: just saw your MP for the cloud-init sosreport plugin, thanks !
[14:47] <utlemming> caribou: :)
[14:48] <caribou> utlemming: the only thing is that I will not merge it from bzr as I would prefer to have it upstream first
[14:48] <caribou> utlemming: do you have a github account ?
[14:48] <caribou> utlemming: this way, it will benefit to all distros
[14:49] <utlemming> caribou: ah, sure. What is the github project I need to fork?
[14:49] <utlemming> caribou: I'll be happy to submit it up that way
[14:49] <caribou> utlemming: https://github.com/sosreport/sos
[14:49] <caribou> utlemming: or I can do it for you if you're too busy
[14:50] <utlemming> caribou: meh, I'll do it...its simple and I should really be playing in the Github community more
[14:50] <caribou> utlemming: just make sure that your commit log starts with  [cloud-init] & add the signoff thingy
[14:50] <caribou> utlemming: just have a look here : https://github.com/sosreport/sos/wiki/Contribution-Guidelines
[14:51] <caribou> utlemming: so bryn doesn't send you back there. It mostly sums up to the two things I mentionned
[14:51] <caribou> utlemming: I worked on this a while back; sent a few emails then it fell in my todo blackhole
[15:06] <utlemming> caribou: done, https://github.com/sosreport/sos/pull/548
[15:07] <caribou> utlemming: yep, just got the email. Thanks a lot. I'll get it in ubuntu once it's in
[15:07] <utlemming> caribou: great :)
[16:56] <excalibr> Can someone help me with Upstart? Why does 'read' behave unusually in *-stop script stanza?
[16:56] <excalibr> I have these 2 lines in post-stop script block
[16:56] <excalibr>     read -r ppid < /var/log/dnscrypt-resolvers_1.log
[16:56] <excalibr>     touch /tmp/dnsc1_$ppid
[16:57] <excalibr> and when I stopped the job, the filename created in /tmp was dnsc1_[NOTICE]
[17:07] <lordievader> excalibr: what is in dnscrypt-resolvers_1.log?
[17:14] <excalibr> lordievader, /facepalm.  It meant to be a pidfile but it looks here something still caused it to fail
[17:14] <excalibr>     read -r ppid < ${PID_FILE_PRIMARY}
[17:14] <lordievader> ;)
[17:14] <excalibr>     touch /tmp/foobar_${ppid}
[17:15] <lordievader> Why throw it through read? 'touch /tmp/foobar_${PID_FILE_PRIMARY}'?
[17:15] <excalibr> stop: Job failed while stopping
[17:15] <excalibr> it gave me that when I stopped the service
[17:15] <excalibr> and dmesg output:
[17:16] <excalibr> [83429.323424] init: dnscrypt-proxy post-stop process (10894) terminated with status 1
[17:16] <excalibr> lordievader, Im interested with the file content
[17:16] <excalibr> not the file itself
[17:17] <lordievader> Could you pastebin the full script?
[17:18] <excalibr> lordievader, it works though if I wrote it this way: ppid=`cat $PID_FILE_PRIMARY`; touch /tmp/foobar_${ppid}
[17:19] <lordievader> I really have no idea what you are trying to accomplish.
[17:21] <excalibr> lordievader, http://pastebin.com/raw.php?i=KW4X9ZKF
[17:24] <lordievader> Could you explain what you are trying to accomplish?
[17:25] <excalibr> lordievader, I had this line earlier in the post-stop block: if { read -r ppid < ${PID_FILE_PRIMARY}; } 2>/dev/null  but oddly that didnt work so now this line was reduced to just that short read -r ... code. Basically I want to dig why the built-in read command failed
[17:26] <lordievader> So, run it manually?
[17:27] <excalibr> If I run that piece of code manually in interactive dash/bash shell it works just fine
[17:28] <lordievader> What does the upstart log say?
[17:28] <excalibr> where is the log file
[17:29] <lordievader>  /var/log/upstart/
[17:29] <excalibr> I dont see a log file for the upstart job in the dir
[17:30] <excalibr> I was wondering about this as well
[17:32] <lordievader> ttp://upstart.ubuntu.com/wiki/Debugging
[17:32] <lordievader> http://upstart.ubuntu.com/wiki/Debugging
[18:05] <jathan> Hello ubuntu-server chanel
[18:05] <lordievader> o/
[18:06] <jathan> Can someone tell me please which could be a good hardware characteristics for a Lidrectord implementation with Ubuntu Server 14.04 for an operation that will be attending between 200 and 1 milion requests per day?
[18:12] <Guest42674> hi
[18:12] <XIaah> does anyone have a few minutes for a few quick questions for a noob about linux servers?
[18:12] <lordievader> XIaah: Shoot
[18:14] <joren> Hey, has anyone else ran into missing ca certs on ubuntu server recently? The install I did is pretty minimal (from preseed) so I'm wondering if there's just a package or something I'm missing. Wget and python are both having trouble with some *fairly* common keys.
[18:16] <XIaah> thanks lordievader, im doing a project at the moment using a dns, http and msql server and going to use a client to "hack" the servers to gain information from them and try to patch the weaknesses in them. i've obviously got apache2 installed on the http with and mysql on the mysql server. however i'm slightly unsure on where the best place to install myphpadmin and wordpress (wordpress
[18:16] <XIaah> must be used for the sake of project) would be? would it be on the apache server as i read that it needs to have permission to access apache2. or would it be best to install it on the mysql server? i hope thats clear enough its been a very long day!
[18:16] <XIaah> everywhere i've looked so far just points towards LAMP and installing everything on the same server, which in my case isn't possible as i need to use 3 individual servers
[18:17] <lordievader> XIaah: Those things are usually placed in /var/www if that is what you mean.
[18:17] <XIaah> yeah
[18:17] <sarnold> joren: apt-get install ca-certificates, that ought to be a good start
[18:18] <joren> sarnold, that's on there. some ssl works, some doesn't. I was hoping there might be another package missing but maybe it's something else
[18:18] <XIaah> lordievader would you  recommend installing wordpress and myphpadmin along side apache2?
[18:19] <sarnold> XIaah: you could look into the juju charms for wordpress, apache, and mysql, they'll know how to configure those services to run on different computers
[18:19] <XIaah> sarnold juju charms? :o
[18:19] <sarnold> joren: can you share a specific site that's failing to verify?
[18:19] <sarnold> joren: maybe run it through the qualsys ssl checker..
[18:20] <joren> running now, https://api.xero.com/ for one
[18:20] <sarnold> XIaah: see e.g. https://jujucharms.com/mysql/trusty/24
[18:21] <XIaah> i'll look into it, thanks sarnold !
[18:22] <teward> anyone here use reprepro willing to give me a hand with something?
[18:22] <lordievader> XIaah: You need something to serve those pages ;)
[18:22] <teward> i need to get two versions of the same source package into a repository that is explicitly named what i want, say, 'nginx-mainline' or 'nginx-stable'
[18:23] <teward> and within that it needs to support ubuntu versions trusty, utopic, vivid, and debian repos as well.  any sane way to execute this
[18:23] <XIaah> lordievader what do you mean?
[18:23] <lordievader> XIaah: Apache is a web server, wordpress/phpmyadmin are web pages.
[18:25] <XIaah> lordievader: i'll have a dns running to support them also
[18:41] <jvwjgames> Hi i am trying to find my private key
[18:42] <jvwjgames> where is it stored
[18:42] <jvwjgames> i used openssl to generate a key
[18:42] <jvwjgames> but can't find the key
[18:42] <genii> cwd
[18:42] <teward> jvwjgames: /home/$USER/.ssh/
[18:42] <teward> jvwjgames: the default is id_something - id_rsa for an RSA key, etc.
[18:43] <jvwjgames>  openssl req -nodes -newkey rsa:2048 -keyout ...
[18:43] <teward> jvwjgames: those files contain the private keys; the id_something.pub file is the public key
[18:43] <jvwjgames> this is the command i used
[18:43] <teward> jvwjgames: oh wait, nevermind, i failed
[18:43] <teward> that command is only part of it, but -keyout should say what the filename is
[18:43] <teward> it'd then be in your current working directory
[18:43] <teward> (the directory you were in when you ran the command)
[18:44] <teward> FYI I can't read
[18:44] <teward> xD
[18:44]  * teward is tiredish
[18:46] <jvwjgames> i forgot to speok found it
[18:47] <jvwjgames> ok i found it
[18:52] <jvwjgames> where is the ssl config file for apache 2 i can't find it
[18:52] <jrwren> jvwjgames: you can find it yourself: grep -ri ssl /etc/apache2
[18:53] <jrwren> jvwjgames: looks like it is split across files in mods-enabled and sites-enabled
[19:09] <joren> It really does just seem like ubuntu is missing some important ca cert. it's working just fine on an arch machine and not working a few ubuntu servers
[19:13] <sarnold> joren: we really just repackage and ship the mozilla certs.. we don't want to be in the business of auditing CAs ourselves..
[19:15] <joren> I see
[19:16] <maxb> what exactly fails?
[19:16] <joren> wget https://api.xero.com
[19:16] <joren> for one
[19:16] <joren> openssl s_client -showcerts -connect api.xero.com:443
[19:16] <joren> show's "unable to get local issuer certificate
[19:17] <joren> er, with -CApath /etc/ssl/certs/
[19:18] <jrwren> joren: I hate to say WFM, but... :)
[19:18] <joren> :( maybe it's really a man in the middle :D
[19:19] <maxb> I do see it fail for me on vivid
[19:19] <maxb> though I can't quite work out why
[19:20] <jvwjgames> how do i convert a cert to X.509 PEM
[19:20] <jrwren> me too, works on trusty, fails on utopic  interesting
[19:21]  * joren on trusty here
[19:21] <joren> failing on at least 3 installs
[19:21] <joren> :/
[19:22] <jrwren> /etc/ssl/certs/Entrust.net_Secure_Server_CA.pem is on trusty and not utopic
[19:22] <jrwren> likely the cert was revoked for a reason?
[19:22] <jrwren> maybe because its a 1024 bit signing cert?
[19:23] <sarnold> jrwren: can you dpkg -S that on both systems? I thuoght the certs should be identical on all: https://launchpad.net/ubuntu/+source/ca-certificates
[19:24] <joren> I've got the Entrust.net_Premium_2048_Secure_Server_CA.pem but I'm missing that one that jrwren just mentioned. This gets me a bit closer :)
[19:25] <jrwren> sarnold: 20130906ubuntu2 on this not-updated trusty.
[19:26] <jrwren> here it is, phasing out 1024bit signing keys: https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/
[19:28] <jrwren> and https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.16.3_release_notes
[19:29] <sarnold> I don't thinkt hat's it though, qualys reports their cert and all certs above it in the chain are 2048. but they also report they are using sha1.. I wonder if that's related?
[19:30] <jrwren> sarnold: I can confirm that the missing file which I mentioned has the same fingerprint mentioned in those NSS release notes.
[19:34] <joren> jrwren, how did you find that that was the missing file? I've got one other site  failing that I'd like to investigate a bit too, it's failing on a verson of ca-certificates that works with api.xero.com
[19:35] <jrwren> joren: I saw the name entrust so I ls /etc/ssl/certs/*trust* on a trusty and a utopic. Lucky guess.
[19:35] <joren> cool cool
[19:35] <jrwren> joren: but, I am not sure that is the problem.
[19:35] <jrwren> I'd have excpect to see that cert as on in the chain in the output of that s_client command, and it is not
[19:37] <jrwren> i'm afraid i went down the wrong path on this. sorry.
[19:39] <joren> idk, seems logical to me. the ubuntu servers are missing a "USERTrust*" certs as well which would explain the other site.
[19:39] <joren> Maybe I should just get a different cert bundle from a trusted source
[19:40] <sarnold> you could download just their specific CA cert and use --ca-certificate=FILE
[19:40] <jrwren> joren: these certs were removed for good reason and without seeing them in that chain, there is no reason to believe adding the cert will fix the problem.
[19:41] <jrwren> joren: also, I do not think "unable to get local issuer certificate" is an error. I get that for google.com and yahoo.com
[19:42] <joren> I get "Verify return code: 0 (ok)" instead of the local issuer thing :/
[19:44] <joren> using that missing cert with --ca-certificate does indeed work. Which I had actually downloaded from Entrust yesterday.
[19:49] <joren> I guess I'll probably just do that, or add Entrust's full cert bundle, and maybe urge xero to get their key's resigned to that 2048 CA key if they can
[19:50] <joren> unless I'm missing something.
[20:19] <jvwjgames> where do i pu the chiper options in apache
[20:20] <jvwjgames> i can;t find the file
[20:20] <teward> jvwjgames: in your site configs, IIRC
[20:20] <teward> httpd.conf theoretically, but i don't know where that is on Ubuntu, as I use nginx instead :P
[20:21] <joren> jvwjgames, /etc/apache2/monds-enabled/ssl.conf is where I'd probably put it.
[20:21] <jrwren> jvwjgames: /etc/apache2/mods-available/ssl.conf
[20:22] <jrwren> jvwjgames: see SSLCipherSuite is there by default
[20:22] <joren> btw, thanks jrwren and sarnold for your help.
[20:22] <teward> what they said :0
[20:28] <jvwjgames> thanks guys
[20:29] <jvwjgames> >:(
[20:29] <jvwjgames> why
[20:29] <jvwjgames> https://www.ssllabs.com/ssltest/analyze.html?d=jvwjgames.net
[20:29] <jvwjgames> This server accepts the RC4 cipher, which is weak. Grade capped to B.
[20:32] <jrwren> jvwjgames: http://blog.rlove.org/2013/12/strong-ssl-crypto.html  I follow that.
[20:32] <jvwjgames> any ideas
[20:33] <teward> jvwjgames: you have the rc4 cipher somewhere
[20:33] <jvwjgames>  SSLCipherSuite AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5:!RC4
[20:33] <teward> but without your cipher strings we can't really tell
[20:33] <teward> did you reload the configuration when you hanged it
[20:33] <teward> changed*
[20:33] <jvwjgames> SSLHonorCipherOrder on
[20:34] <jvwjgames> yes
[20:34] <teward> yeah i was running the cipher test :p
[20:36] <teward> jvwjgames: i think it's missing this cipher in that config, but IDK why - ECDHE-RSA-RC4-SHA
[20:36] <teward> i just ran a cipherscan of your domain from here, and that's the only rc4 cipher still in use
[20:36] <teward> probably why it triggered
[20:36] <jvwjgames> so just add it
[20:37] <teward> see, https://cipherli.st/ is a little more 'accurate' to the cipher strings that you should probably use - it doesn't include the MEDIUM ciphers and won't trigger the RC4 error, but meh
[20:37] <teward> not that i endorse that list
[20:37] <jvwjgames> hmm intresting
[20:38] <jvwjgames> i had two lines for cipher settings
[20:38] <jvwjgames> and apache2 didn't complain
[20:38] <jvwjgames> maybe why it was still triggering
[20:38] <jvwjgames> retesting
[20:39] <teward> well it shouldn't, you *can* override ciphers for specific sites, IIRC.
[20:42] <teward> nope still triggering :P
[20:42] <teward> (make sure to refresh your configs every time)
[20:45] <jvwjgames> ok i just copied and pasted the config from that site you gave and i am now retesting
[20:45] <jvwjgames> and yes i did a reload and even a restart
[20:45] <jvwjgames> of the apache2 service
[20:46] <teward> you might have something overriding it elsewhere in other configs, but IDK where that'd be.
[20:46] <teward> (I'm not an Apache expert)
[20:47] <jvwjgames> ok
[20:47] <joren> grep -R SSLCipherSuite /etc/apache2/
[20:47] <joren> ?
[20:48] <joren> I just changed mine to "SSLCipherSuite AES256+EECDH:AES256+EDH" and it got rid of the RC4 thing for me. We've been using that on our public site for a while now
[20:50] <jvwjgames> ok retesting
[20:53] <teward> joren: yeah that's a strong ciphersuite, although iirc that limits to TLSv1.2 but don't quote me on that
[20:53] <teward> mmm it has older ones, too, nevermind.
[20:53] <teward> the only problem is if you need the 128 strength ones in which case time to expand
[20:55] <jvwjgames> hmm
[20:55] <jvwjgames> still don't work
[20:56] <joren> did the grep reveal any  other SSLCipherSuite lines? do you have the symlink at /etc/apache2/mods-enabled/ssl.conf?
[20:59] <joren> heh, that guy Robert Love has the same last name as me :)
[20:59] <joren> I'm waiting for the .love tld to come out :D
[21:01] <jvwjgames>  The apache2 configtest failed. Not doing anything.
[21:01] <jvwjgames> Output of config test was:
[21:01] <jvwjgames> apache2: Syntax error on line 219 of /etc/apache2/apache2.conf: Syntax error on line 163 of /etc/apache2/sites-enabled/default-ssl.conf: </IfModule> without matching <IfModule> section
[21:01] <jvwjgames> Action 'configtest' failed.
[21:01] <jvwjgames> The Apache error log may have more information.
[21:02] <jvwjgames> nevermind fixed it
[21:04] <jvwjgames> :D
[21:04] <jvwjgames> guys
[21:04] <jvwjgames> look
[21:04] <jvwjgames> https://www.ssllabs.com/ssltest/analyze.html?d=jvwjgames.net
[21:05] <jvwjgames> joren: look
[21:06] <jvwjgames> teward: look
[21:06] <joren> Congrats
[21:07] <jvwjgames> i had tones of cipher settings in diffrent places i commented them out and put the chiper settings in apache.conf and it worked
[21:08] <teward> jvwjgames: your OCSP is borked, but i think that's Comodo's fault
[21:08] <joren> you're getting allot less cipher suite mismatches than me
[21:10] <jvwjgames> i am
[21:10] <jvwjgames> hmmm
[21:10] <joren> I think it's a good thing ;)
[21:12] <jvwjgames> thanks for your help guys
[21:38] <joren> Anyone know if there SSLCertificateChainFile thing is supposed to take care of missing local ca certs? I started investigating the server I have access to that's failing wget but  ssl labs certainly isn't telling me there are any issues


[06:12] <al-maisan> Good morning
[10:17] <henninge> jtv: could you do a review for me?   Sure.
[10:18] <jtv> Where is it?
[10:18] <henninge> jtv: I may have typed faster than I was thinking. Let me check if I have already created the MP or not ...
[10:19] <henninge> jtv: no, so you are off the hook for another 15 min or so ... ;)
[10:19] <jtv> ok, I'll go concentrate on some problem-solving here
[10:44] <adeuring> henninge, intellectronica: could one of you please review this MP: https://code.edge.launchpad.net/~adeuring/launchpad/bug-460935-hwdb-better-consistency-check-udev-usb-devices/+merge/13942?
[10:44] <intellectronica> adeuring: sure
[10:45] <adeuring> intellectronica: thanks!
[10:45] <henninge> intellectronica: thanks, too.
[10:45] <intellectronica> henninge: and it won't be complete without thanking you as well. thank you!
[10:46] <henninge> ;-)
[10:50] <intellectronica> adeuring: r=me
[10:50] <adeuring> intellectronica: thanks!
[11:06] <jtv> henninge: this MP is taking rather longer than 15 minutes!
[11:06] <henninge> jtv: yes, sorry.
[11:07] <henninge> jtv: I had to get back into the matter and now try to explain it. Also, I had an interesting issue on #launchpad.
[11:09] <jtv> henninge: ah, the bzr import attribution issue.  We've seen that before, I think.
[11:28] <henninge> jtv: ok, here is the proposal. https://code.edge.launchpad.net/~henninge/launchpad/bug-128324/+merge/13946
[11:28] <henninge> jtv: If you still want to take it, you can claim it. But I could ask intellectronica now, too. ;-)
[11:29] <jtv> henninge: no worries, I'll take it.  Bit slow to load though.
[11:29] <henninge> jtv: it's HUGE ... ;)
[11:30] <jtv> henninge: let me see if I can reset that router...
[12:01] <adeuring> henninge, intellectronica: can I pester you with another MP? https://code.edge.launchpad.net/~adeuring/launchpad/bug-460976-noise-reduction-for-hwdb-processing-log/+merge/13950
[12:01] <intellectronica> adeuring: sure
[12:02] <adeuring> intellectronica: thanks!
[12:03] <wgrant> noodles775, al-maisan: Can one of you please do a simple review for me? https://code.edge.launchpad.net/~wgrant/launchpad/archive-debug-archive/+merge/13949
[12:03] <wgrant> I'm collecting far too many ddeb-related branches :(
[12:04] <al-maisan> wgrant: I can but probably won't get to it today .. is that OK?
[12:04] <henninge> al-maisan, wgrant: any reason I could not do it?
[12:04]  * al-maisan takes a look at the branch
[12:05] <wgrant> henninge: That'd be fine, but I'd like to get at least a glance from a Soyuz guy.
[12:06] <wgrant> (it's not urgent; I might not finish the dependent branches in 3.1.10. but I'd like to minimise the queue)
[12:08] <al-maisan> wgrant: this only affects the primary archive and not the partner archive?
[12:08] <wgrant> al-maisan: partner is small and not mirrored, so it's not a concern. Also note that I'm just moving the existing logic.
[12:15] <al-maisan> wgrant: right .. looks OK to me.
[12:18] <al-maisan> wgrant: please have it formally reviewed by either henninge or intellectronica.
[12:19] <intellectronica> wgrant: i can have a look as soon as i'm done with adeuring's branch
[12:19] <wgrant> intellectronica: Thanks.
[12:21]  * henninge is in the stand-up call now and will go to lunch after that.
[12:28] <wgrant> intellectronica: I need to sleep now. If you get to my branch, thanks!
[12:28] <intellectronica> wgrant: i can start now. which branch?
[12:28] <wgrant> intellectronica: https://code.edge.launchpad.net/~wgrant/launchpad/archive-debug-archive/+merge/13949
[12:28] <intellectronica> wgrant: cool. sweet dreams
[12:29] <wgrant> intellectronica: Thanks.
[12:44]  * henninge lunches
[12:57] <sinzui> henninge-lunch: intellectronica: can one of you review https://code.edge.launchpad.net/~sinzui/launchpad/prf-flavor-loop/+merge/13919
[12:57] <intellectronica> sinzui: sure
[13:09] <intellectronica> sinzui: r=me
[13:10] <sinzui> intellectronica: thank
[13:11] <intellectronica> henninge-lunch, abentley: if it's cool with you, i'm going to stop reviewing for now. i've done quite a lot of reviews so far, and have plenty of other work. if things get very bust later, though, give me a shout and i'll come back to help
[13:11] <abentley> intellectronica: Cool.
[13:22] <salgado> mine is https://code.launchpad.net/~salgado/launchpad/bug-452525/+merge/13873
[13:22] <salgado> any takers? :)
[13:29] <abentley> salgado: I'll have a look.
[13:34] <abentley> salgado: did you consider testing the view directly, rather than through th browser?
[13:36] <salgado> I don't remember
[13:36] <salgado> on a call now, will be out shortly
[13:37] <abentley> salgado: Okay.
[13:55] <matsubara> hi, could I get a review for https://code.edge.launchpad.net/~matsubara/lp-production-configs/update-oops-prefix/+merge/13954 ? It's a one-line config change to avoid generating conflicting oops reports.
[13:56] <matsubara> that change has been cowboyed btw
[14:24] <matsubara> henninge, can you take a look at https://code.edge.launchpad.net/~matsubara/lp-production-configs/update-oops-prefix/+merge/13954?
[14:24] <henninge> matsubara: sure
[14:24] <matsubara> thanks henninge
[14:24] <henninge> matsubara: what do "M" and "N" stand for?
[14:25] <matsubara> henninge, nothing. it's the oops prefix used by the lpnet configuration files. they are in alphabetical order
[14:28] <matsubara> henninge, so basically lpnet1 == A, lpnet2 == B, etc
[14:28] <salgado> abentley, so, I didn't consider writing a view test for that fix, but it probably is a good idea.  I'll give it a try
[14:29] <henninge> matsubara: ah, that makes sense. r=me
[14:29] <abentley> salgado: I meant rather than a browser test, because view tests are less fragile and test the code in question more directly.
[14:29] <matsubara> thanks henninge
[14:30] <salgado> abentley, yep, I know what you mean, and I think it will probably make for a simpler and more robust test
[14:31] <salgado> maybe even a bit faster
[14:32] <abentley> salgado: Is AccountStatus.DEACTIVATED already being tested?
[14:33] <abentley> salgado: Why is lib/devscripts/ec2test/instance.py changed by the branch?
[14:33] <salgado> abentley, I think there's a page test for the AccountStatus.DEACTIVATED case.  let me check
[14:34] <abentley> salgado: (because obviously it would be easy to expand the test to cover both)
[14:34] <salgado> abentley, nothing related to the branch.  just that I found a bug in it while using ec2
[14:35] <abentley> salgado: Okay.  Just wanted to make sure it wasn't accidental, since you didn't mention it in the description.
[14:35] <salgado> the test for DEACTIVATED accounts is in stories/foaf/xx-resetpassword.txt
[14:37] <abentley> salgado: Okay, so I think this is landable as-is, but would be even better if the test was a view test.
[14:37] <salgado> abentley, cool, I'll send you an incremental diff changing the test into a view test
[14:38] <abentley> salgado: Cool.
[14:38] <henninge> Hey jtv! I am done lunching, are you stuck in my branch? ;-)
[14:39] <jtv> henninge: didn't my vote come through?
[14:39] <jtv> I'm pretty sure it did.
[14:39] <henninge> jtv: oh, sorry. scroll error ... ;)
[14:40] <jtv> henninge: one of those things you probably should be able to manage when you work as a software engineer.  :-P
[14:40] <henninge> jtv: ssshhh
[14:41]  * jtv ssshhhes
[14:41] <henninge> jtv: and thanks for the review. I will do as you requested.
[14:41] <jtv> yeah, bitch!  you'd better!
[14:41] <jtv> sorry, couldn't resist
[14:41]  * jtv goes back go ssshhhing
[14:50] <bac> sinzui: will you re-review https://code.edge.launchpad.net/~bac/launchpad/bug-436259-add-member/+merge/13875
[14:51] <bac> sinzui: i don't have a diff as i merged in RF but i backed out the tests and made the link change you requested
[14:54] <sinzui> bac: r=me
[14:54] <bac> thanks
[15:01] <salgado> abentley, http://paste.ubuntu.com/302109/ is the incremental diff.  looks much better, IMO
[15:02] <abentley> salgado: Looks good.  Land it!
[15:02] <salgado> abentley, thanks
[15:21] <henninge> jtv: For the new "ec2 land" command to work, you need to set the review type to "code" as the script checks for that.
[15:22] <henninge> jtv: np, though, I already ec2 tested it, so I can just  submit.
[15:22] <jtv> henninge: is that it?  I thought the docs also said (thought it wasn't very clear to me) that it defaults to code if no review type is given.
[15:22] <henninge> jtv: ah
[15:22] <henninge> jtv: I think this is what happened on Friday:
[15:23] <jtv> henninge: (hang on, still in call)
[15:23] <jtv> henninge: (...and done)
[15:24] <henninge> jtv: There was a pending review from Launchpad Engineering of type "code" and my reviewer added a new review "Approved" without a type.
[15:24] <henninge> jtv: so the script saw the (unused) pending line.
[15:34] <jtv> henninge: it could well be that that is why I got the "get an approval vote" error for some reviews.
[15:34] <henninge> jtv: that's how I understand that error
[15:57] <henninge> jtv: should I review your branch scale-message-sharing-migration?
[16:25] <deryck> leonardr, you've pretty much already reviewed https://code.edge.launchpad.net/~deryck/launchpad/better-html-handling-description-editing/+merge/13963 for me as I did it.  Care to sign off on it?
[16:25] <leonardr> sure
[16:26] <deryck> leonardr, thanks.  And here's the related lazr-js branch:  https://code.edge.launchpad.net/~deryck/lazr-js/multine-editor-xhtml-handling/+merge/13967
[17:09] <bac> sinzui: i've submitted a MP for my palindromic bug 461164.  would you care to review it if/when it shows up on LP?
[17:09] <mup> Bug #461164: Project +download page has extra vertical space <Launchpad Registry:New> <https://launchpad.net/bugs/461164>
[17:11] <sinzui> bac: my pleasure
[17:17] <al-maisan> abentley: I have a mini-branch, could you please take a look: https://code.edge.launchpad.net/~al-maisan/launchpad/bq/+merge/13971
[17:18] <abentley> al-maisan: Sorry, on a call.
[17:18] <al-maisan> abentley: np, maybe when you finish the call?
[17:26] <sinzui> bac: font-size: 1.2em; is not supported by YUI-font. I think you should pick a percentage from the table in style-3.0.css. Do you know why the  <h2> font size an exception?
[17:28] <sinzui> bac: can we replace the first with the second
[17:28] <sinzui> tal:condition="python: release.release_notes or release.changelog"
[17:28] <sinzui> tal:condition="release/release_notes|release/changelog|nothing"
[17:33] <barry> abentley: have time for a quick review?
[17:34] <abentley> barry: sure.
[17:34] <barry> abentley: thanks. mp coming
[17:37] <abentley> al-maisan: r=me
[17:42] <al-maisan> abentley: thanks
[17:54] <bac> sinzui: i don't know why the h2 has a different size
[17:55] <sinzui> bac: I just updated the review: https://code.edge.launchpad.net/~bac/launchpad/bug-461164-downloadfix/+merge/13969
[17:57] <sinzui> bac: I do not think the <h2> font exception is needed. I see <h2> is set to 123.1%, which is about 1.2em
[17:57] <bac> sinzui: yes, i fixed the phantom border but failed to mention it in the cover letter
[17:57] <bac> sinzui: i'll gladly kill the font size
[17:57] <sinzui> bac: I am pleased nonetheless
[17:58] <sinzui> I think those font-sizes were added as beuno was planning the 3.0 style. +downloads was foreshadowing the current style rules
[17:59]  * sinzui is impressed he worked 'foreshadowing' into the conversation
[17:59]  * sinzui will try for 'prescient' next
[18:00]  * beuno blinks
[18:00] <beuno> have we dropped the pre-3.0 stylesheet yet?
[18:00] <beuno> or mochikit?  :)
[18:01] <bac> sinzui: the release notes are truncated to 800 char so i'll do the same with changelog
[18:03] <sinzui> +1
[18:03] <sinzui> beuno: I looked at that bug a week ago
[18:04] <sinzui> beuno: I think we need to test that the some of the folding/expansion still start on page load
[18:05] <bac> sinzui: note the h2 looks no different and the changelog is nicely truncated http://people.canonical.com/~bac/download-fix.png
[18:05] <sinzui> sweet
[18:06] <beuno> sinzui, to drop the stylesheet or mochikit?
[18:07] <sinzui> bac: so font is gone, changelog clamped, portlet-border fixed. What do you think about the python condition? If my suggestion does not work, keep it as it is so, I think this review is r=me
[18:07] <sinzui> beuno: mochikit
[18:07] <bac> sinzui: i killed the py condition too
[18:08] <bac> sinzui: i think i got all of your issues
[18:08] <bac> sinzui: diff http://pastebin.ubuntu.com/302205/
[18:08] <sinzui> bac: you rock. definite r=me
[18:10] <sinzui> beuno: looking at the default page scripts, I think mochikit is safe to remove
[18:10] <bac> ugh, got an error adding a comment to my MP: The following errors were encountered:
[18:10] <bac> (, 'createComment', 'launchpad.AnyPerson')
[18:10] <bac> OK
[18:10] <sinzui> bac: you are not just AnyPerson, you are a rocket scientist
[18:11] <beuno> sinzui, do you want to be a hero?
[18:12]  * sinzui checks the default script before answering
[18:12] <bac> adding MP comments works in FF.  :(
[18:17] <sinzui> beuno: we cannot remove mochikit. Many of the expand/collapse/fold functions are using its getElementsByTagAndClassName and swapElementClass functions
[18:17] <beuno> sinzui, really?  garrrrr...
[18:18] <sinzui> beuno: we need to YUI-iffy  500 lines in lp.js
[18:18] <beuno> sinzui, is there a bug for that?
[18:18] <sinzui> beuno: Just the remove mochikit bug
[18:19] <beuno> sinzui, could you comment on it with this new information?
[18:19] <beuno> I want to try and get gary_poster to sneak it in at some point
[18:19] <beuno> drop 30-50kb from each request
[18:20] <intellectronica> sinzui: getElementsByTagAndClassName is trivial to rewrite with the css selector capabilities of yui, innit?
[18:20] <sinzui> beuno: I suspect that if we provide yu substitute functions we can cust the mochikit was
[18:20] <sinzui> hmm
[18:20] <sinzui> wow my last sentence really fell apart. I have no idea where I was going with that
[18:21] <sinzui> intellectronica: I agree that we can provide some simple class/tag manipulation functions to remove mochikit
[18:21] <beuno> sinzui, Monday is a little early to kick off breakfeast with vodka
[18:22] <sinzui> It was mixed with orange juice
[18:22] <intellectronica> you really shouldn't eat on an empty liver
[18:24] <beuno> ...and that's how we make Launchpad kids!
[18:25] <sinzui> I think some alternate substances were involved in some of the code I have read, but maybe it was the result of a bad merge
[18:41] <sinzui> beuno: I updated bug 294656. I also added bugs and translations targets because they are the primary users of the legacy code. Bugs functions look like simple changes. Translations may be more substantial.
[18:41] <mup> Bug #294656: Every page requests two JavaScript libraries (remove MochiKit) <tech-debt> <Launchpad Foundations:Triaged> <Launchpad Bugs:New> <Launchpad Translations:New> <https://launchpad.net/bugs/294656>
[18:41] <beuno> sinzui, you rock man, thank you
[19:01] <bac> sinzui: my serieses-series branch is now fixed up and ready to land.
[19:01] <sinzui> bac: May the god of grammar remain  steadfast by your side
[19:01] <bac> was that an r=sinzui?
[19:02] <sinzui> it is an r=me
[19:45] <rockstar> abentley-lunch, I have a branch headed your way, but you seem to be eating late.  I'll just wait patiently.
[20:08] <EdwinGrubbs> sinzui, beuno: I posted a question on this mp concerning sinzui's suggestion. What do you think about it? https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-436507-distro-sourcepackage-link/+merge/13878
[20:09] <beuno> EdwinGrubbs, I'll take a peak in a minute
[20:36] <sinzui> EdwinGrubbs: I did not realise the link was a see-all. See-all was intended for portlets that show a limited count of a larger list. this case does not look like reason to use see-all
[20:37] <rockstar> abentley, do you think you'll be able to get to that review today?
[20:38] <abentley> rockstar: Signs point to no.
[20:38] <abentley> rockstar: But I can do it tomorrow morning.
[20:38] <rockstar> abentley, awesome.  Thank you.
[20:38] <EdwinGrubbs> sinzui: originally, I had put the link at the bottom of the first portlet, but Julian thought that the see-all would be better. Is the bottom of the first portlet good then?
[20:39] <EdwinGrubbs> sinzui, beuno: or should it go in the side portlet?
[20:40] <sinzui> We have lots of pages with links that precede the main content. We use <ul class="horizontal">
[20:40] <EdwinGrubbs> ok
[20:41] <sinzui> I do not think side portlet is correct it is not about the context, in fact it switches the context,
[22:43] <mwhudson> thumper: can you review a very small branch¿
[22:43] <mwhudson> ?
[22:44] <thumper> mwhudson: ok
[22:45] <thumper> mwhudson: how'd you get the upside down ?
[22:45] <mwhudson> thumper: compose - ?
[22:45] <mwhudson> or something like that
[22:45] <thumper> I don't have a compose key
[22:53] <thumper> mwhudson: done
[23:49] <mwhudson> thumper: http://pastebin.ubuntu.com/302425/ fixes https://bugs.edge.launchpad.net/launchpad-code/+bug/457999 in the way sinzui suggests, do you know if this link is tested anywhere?
[23:49] <mup> Bug #457999: verify download link is broken <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/457999>


[12:33] <pcjc2> nope... still crashes (eventually)
[12:40] <ubotu> New bug: #151771 in linux-restricted-modules-2.6.22 (restricted) "nvidia tv out black white, while setting pal-g, due to starting with dual-head on lcd+crt" [Undecided,New]  https://launchpad.net/bugs/151771
[01:06] <ubotu> New bug: #147309 in xorg (main) "ATI xorg driver missing resolution 1280x1024" [Undecided,New]  https://launchpad.net/bugs/147309
[01:51] <ubotu> New bug: #151790 in xorg-server (main) "gutsy beta -  gnome apps misinterpret xrandr" [Undecided,New]  https://launchpad.net/bugs/151790
[03:47] <ubotu> New bug: #133363 in linux-restricted-modules-2.6.22 (restricted) "suspend-to-ram problems with fglrx module loaded" [Medium,Confirmed]  https://launchpad.net/bugs/133363
[04:05] <ubotu> New bug: #151807 in xorg (main) "X freezes under kernel 2.6.22-14" [Undecided,New]  https://launchpad.net/bugs/151807
[10:14] <ubotu> New bug: #151741 in xorg (main) "No Usplash xorg" [Low,Incomplete]  https://launchpad.net/bugs/151741
[10:40] <ubotu> New bug: #151884 in linux-restricted-modules-2.6.22 (restricted) "X not starting after upgrade to 7.10 RC (ATI X1400)" [Undecided,New]  https://launchpad.net/bugs/151884
[01:31] <ubotu> New bug: #151930 in xorg-server (main) "[Gutsy]  - Xorg black/black screen on boot (monitor in standby)" [Undecided,New]  https://launchpad.net/bugs/151930
[01:41] <ubotu> New bug: #151936 in linux-restricted-modules-2.6.22 (restricted) "After update to linux-kernel-2.6.22-13 X-Server failed to load nvidia module." [Undecided,New]  https://launchpad.net/bugs/151936
[01:42] <ubotu> New bug: #141095 in xorg (main) "1400x1050 resolution set, but uses virtual enlarged screen instead of real resolution" [Undecided,New]  https://launchpad.net/bugs/141095
[01:50] <ubotu> New bug: #147068 in ubuntu "xorg 7.2 or 915 resolution crashing on logout (dup-of: 127101)" [Undecided,New]  https://launchpad.net/bugs/147068
[02:01] <ubotu> New bug: #151543 in ubuntu "xserver-xorg-video-intel and 1680x1050 (dup-of: 131646)" [Undecided,New]  https://launchpad.net/bugs/151543
[02:53] <ubotu> New bug: #151256 in xserver-xorg-video-intel (main) "[gutsy]  Xorg or Intel Driver Shows bar at bottom fter upgrade" [Undecided,Confirmed]  https://launchpad.net/bugs/151256
[03:26] <ubotu> New bug: #61181 in udev (restricted) "firmware dvb-usb-wt220u-zl0353-01.fw should be included" [Undecided,Invalid]  https://launchpad.net/bugs/61181
[03:56] <ubotu> New bug: #151974 in xserver-xorg-video-ati (main) "ATI Technologies Inc RV410 [Radeon X700]  [1002:5e4f]  - no compiz support" [Undecided,New]  https://launchpad.net/bugs/151974
[04:18] <pcjc2> I think I got fixes for #141063 and #127101 (based on Bryce's debug patch which disabled palette programming) - works for me now ;)
[04:19] <pcjc2> http://www2.eng.cam.ac.uk/~pcjc2/ubuntu/xserver-xorg-video-intel_2.1.1-0ubuntu9~pcjc2.debdiff
[04:28] <ubotu> New bug: #121653 in linux-restricted-modules-2.6.22 (restricted) "[gutsy]  Suspend to Ram does not work on Z61m" [Wishlist,Confirmed]  https://launchpad.net/bugs/121653
[04:30] <ubotu> New bug: #151987 in xresprobe (main) "Stall on upgrading xresprobe to 0.4.24ubuntu6" [Undecided,New]  https://launchpad.net/bugs/151987
[04:35] <ubotu> New bug: #151988 in xserver-xorg-video-trident (main) "Fuzzy Strip shows on screen with Toshiba Laptop" [Undecided,New]  https://launchpad.net/bugs/151988
[05:05] <ubotu> New bug: #151043 in ubuntu "gutsy - freeze after kde-logout with intel915gm (dup-of: 127101)" [Undecided,New]  https://launchpad.net/bugs/151043
[05:42] <ubotu> New bug: #151918 in xserver-xorg-video-ati (main) "ATI Radeon X200 7.10 RC install" [Undecided,New]  https://launchpad.net/bugs/151918
[05:50] <ubotu> New bug: #152016 in xserver-xorg-input-synaptics (main) "[GUTSY]  Acer 5920G Touchpad not configured correctly" [Undecided,New]  https://launchpad.net/bugs/152016
[06:11] <ubotu> New bug: #152021 in xorg (main) "Can not use external VGA display (T43 + ATI + VGA)" [Undecided,New]  https://launchpad.net/bugs/152021
[06:40] <ubotu> New bug: #152040 in ubuntu "sqldeveloper (java application) with compiz enabled no display on gusty (dup-of: 89189)" [Undecided,New]  https://launchpad.net/bugs/152040
[07:15] <ubotu> New bug: #152046 in xorg (main) "synaptics tapping is enabled and cannot be disabled without manually editing xorg.conf" [Undecided,New]  https://launchpad.net/bugs/152046
[07:20] <ubotu> New bug: #152050 in xorg (main) "machine crashes when screensaver activates" [Undecided,New]  https://launchpad.net/bugs/152050
[07:41] <ubotu> New bug: #152056 in xorg (main) "package x11-common 1:7.2-5ubuntu13 failed to install/upgrade: " [Undecided,New]  https://launchpad.net/bugs/152056
[10:00] <ubotu> New bug: #152085 in nautilus (main) "Nautilus freezes and eventually crashes when trying to preview .vss file" [Undecided,Invalid]  https://launchpad.net/bugs/152085
[10:45] <ubotu> New bug: #152104 in xserver-xorg-video-i810 (main) "xserver-xgl and dual screen external monitors does not work with i810." [Undecided,New]  https://launchpad.net/bugs/152104
[11:16] <ubotu> New bug: #152109 in xorg (main) "gsm/startx will ignore xorg.conf resolution settings and run with very low resolution" [Undecided,New]  https://launchpad.net/bugs/152109


[00:17] <EzraR> if an app is set up to run on diff OS's is it acceptable to break that functionality in the package to fix a bug? (Ubuntu is linux only)
[00:18] <EzraR> well actually its already broke
[00:18] <EzraR> i would just make it actually work for linux
[00:18] <EzraR> without fixing the larger bug
[00:21] <ScottK> EzraR: Yes.
[00:21] <ScottK> Bonus points for working in BSD land since Ubuntu has one downstream that uses that.
[00:23] <EzraR> it has diff configs for free,net, and open which would be best suited for that
[00:25] <EzraR> nm, im guessing free
[00:27] <wgrant> ScottK: We have a BSD downstream?
[00:28] <ScottK> wgrant: Nexunta or something like that?
[00:28] <wgrant> ScottK: That's OpenSolaris.
[00:28] <ScottK> Ah.
[00:28] <ScottK> EzraR: Nevermind
[00:28] <ScottK> That's what I get trying to remember stuff when I have flu.
[02:22] <FFEMTcJ> Could someone test my patch for Bug #481677 please
[02:24] <FFEMTcJ> I'm new at this, so would like some feedback if anyone has any.
[03:17] <lfaraone> How are sync requests scheduled? I see a NEW (to ubuntu) package in testing that I need synced to Lucid before I can do a sync request of a package with local changes.
[03:22] <ScottK> lfaraone: Just wait a bit.
[03:24] <lfaraone> ScottK: mk.
[04:06] <master> hello
[04:06] <master> umm
[04:06] <master> i would like to know
[04:06] <master> how to develop for ubuntu
[04:06] <master> i do C java and C++ and the likes
[04:10] <maco> master: hi :)
[04:12] <maco> i suppose you could have a look at the bugtracker.  the ones marked "triaged" are the ones that should have enough info for you to fix them, but you may want to start with triaged ones tagged "bitesize" to work your way up the tough ones if you're not too experienced yet
[04:12] <maco> note also that we're having the developer summit next week. you can listen in to streams of it and participate over irc...or at least just get a feel for how decisions happen around here and what new stuff is coming
[04:13] <maco> at some point, you'll probably want to learn to package up your patches. for that, i think daniel holbach's videos on youtube are fantastic
[04:14] <maco> master: is that the sort of info you were looking for?
[04:16] <maco> master: this is a good place to start https://wiki.ubuntu.com/UbuntuDevelopment
[04:17] <jmarsden> master: For MOTU-related stuff you can also start at https://wiki.ubuntu.com/MOTU/GettingStarted .  At some point reading the Packaging Guide https://wiki.ubuntu.com/PackagingGuide/Complete would also be good :)
[04:17]  * maco should get around to learning C++
[04:19] <maco> wow i dont think i ever actually read the wiki page i linked O_o
[04:23] <jmarsden> maco: Well, you became a MOTU without it, so you can't have missed *that* much :)
[04:23] <maco> jmarsden: i missed the bit about linking to "how to package without debhelper"
[04:24] <maco> also the sponsorship page? i apparently requested sponsorship rather wrong rather often. didnt know you were supposed to assign to nobody
[04:25] <master> k
[04:25] <master> but
[04:25] <master> im not sure how to go about making the patch
[04:25] <maco> ah ok
[04:25] <maco> have you ever used the diff command?
[04:27] <maco> hmm wait lets back up
[04:28] <maco> ok first, you find out what package contains whatever bug you want to fix. if its one on launchpad, youre good. if one you found "dpkg -S <program>" replacing <program> with the command that runs the program you found the bug in
[04:28] <maco> then you get that package in source form: apt-get source <package>
[04:28] <maco> then itll unpack a directory of source code for you
[04:29] <maco> i would then run: cp -lr original_source/ modified_source/ (replace original_source with the directory name)
[04:29] <maco> cd into modified_source/ and make whatever edits are necessary to fix the bug
[04:30] <maco> then run: diff -rU original_source/ modified_source/ > fixstuff.patch
[04:30] <maco> there's your patch!
[04:34] <maco> you can also make a debdiff, but there are directions elsewhere for that. a patch is good enough to attach to a bug report and have someone do something with it. if you want to know how to make a debdiff see daniel holbach & james westby's ubuntu open week session logs from a couple weeks ago
[04:34] <maco> master: does that help?
[04:38] <master> thanks so much maco
[04:38] <maco> no problem :)
[04:40] <master> what is the usual language the sources are in?
[04:40] <maco> most of GNOME is C, most of KDE is C++, both have a lot of Python programs as well
[04:40] <maco> ive yet to use my Java in FOSS
[04:40] <maco> underlying system stuff is usually C as well
[04:41] <master> k
[04:41] <master> cos i dont do python
[04:41] <maco> neither do i
[04:41] <maco> i just do C or Java
[04:41] <JanC> you can learn basic Python in less than 1 day  ;)
[04:42] <master> mm
[04:42] <master> ok
[04:42] <maco> yeah...ive done a couple of patches in python without knowing python
[04:42] <maco> it looks like pseudocode, but it happens to run
[04:42] <JanC> contrary to C++, you need about 10 years to learn basic C++  ;)
[04:43] <maco> haha...i need to get around to that
[04:43] <maco> only knowing how to code for the DE i dont use anymore is a little ick
[04:43] <JanC> even the inventor of C++ admits he doesn't understand C++, so...
[04:43] <maco> bjarne?
[04:43] <JanC> yeah  ☺
[04:44] <maco> ...he didnt say anything bad about c++ when he got up to speak about it
[04:44] <JanC> well, he wrote it in the book I have; actually he said he doesn't understand all the corner cases of C++
[04:45] <JanC> and AFAIK nobody does (there are no 2 C++ compilers that interpret it alike)
[04:46] <maco> hpux's c++ compiler will quote page & line numbers at you when you screw up
[04:46] <maco> of the C++ specification
[04:46] <JanC> which is why most projects agree to use only a subset of C++  ;)
[04:46] <maco> moz devs learned quickly that if it fails to compile on hpux, the hpux compiler is right
[04:47] <JanC> there are valid C++ constructs that can have 2 meanings according to the spec, no way a compiler can decide what's right  ;)
[04:47] <jdong> too bad the C++ specifications are non-free ;-)
[04:47] <jdong> in a quite literal financial sense of the term.
[04:47] <maco> jdong: thats rather sucky
[04:47] <jdong> indeed
[04:47] <JanC> jdong: well, the drafts that get approved are free most of the time
[04:48] <jdong> I needed it the other day to help a friend make a pedantic point on homework.
[04:48] <jdong> i.e. declaring an int main without explicitly returning.
[04:58] <master> open office is programmed in java rite?
[04:58] <jdong> no
[04:58] <jdong> it's primarily programmed in C++
[04:58] <JanC> no, most of OO.o is C++, with some parts in Java
[04:58] <master> o
[04:58] <master> ok
[04:58] <jdong> multimedia portions are in Java
[04:58] <master> 00.o???
[04:58] <jdong> but are "optional" ish.
[04:58] <JanC> e.g. the database is in Java IIRC
[04:59] <jdong> master: upstream insists that it's called OpenOffice.org
[04:59] <jdong> and never shortened in any other manner.
[04:59] <master> o
[04:59] <master> kk
[04:59] <JanC> jdong: OpenOffice is a company in the Netherlands that is way older than OO.o  ;)
[04:59] <jdong> :)
[05:00] <JanC> they actually distribute StarOffice and now OpenOffice.org
[05:00] <JanC> and help promote it
[05:01] <JanC> they do the whole "open office" stuff, including operating systems on server & desktop, applications, etc.
[05:01]  * jdong nods
[05:02] <JanC> they even promote Ubuntu  ☺
[05:11] <master> anyone here knows how to do OS programming
[05:14]  * maco looks at jdong
[05:14] <maco> im not done with OS class yet
[05:15] <maco> but jdong knows everything about everything
[05:15] <jdong> jdong has currently enteredCriticalSection....
[05:15] <jdong> err that didn't sound right.
[05:15] <maco> hahahaha
[05:15] <jdong> I meant to express jdong is busy right now with WORK and not interruptible.
[05:15] <maco> critical section works...
[05:17] <Flannel> master: "OS Programming" could be a lot of things.  What are you trying to do?
[05:18] <master> lol
[05:20] <RAOF> OS programming: working out why grub2 sticks an invalid vg entry in its list of lvs, causing it to segfault.
[05:23] <DBO> RAOF, halp, Docky needs you
[05:23] <RAOF> DBO: Trade you a working grub for help on Docky? :)
[05:23] <DBO> mmmm, I suggest LILO, its the bestest
[05:23] <RAOF> Won't boot from lvm
[05:24] <RAOF> IIRC
[05:24] <jdong> it's called a /boot partition.
[05:24] <jdong> *ducks*
[05:24]  * DBO was being sarcastic
[05:49] <dtchen_> lilo does boot from lvms.
[05:50] <dtchen_> granted, I don't recall if it was a *SUSE setup
[05:51] <dtchen_> maco: eh, I'm quite certain I've bopped you over the noggin with "don't assign unless explicitly granted permission"
[05:51] <maco> dtchen_: yeah i know *that*
[05:51] <dtchen_> OTOH, you do have an amazing ability to tune out everything I say
[05:52] <maco> i mean i didnt know you were supposed to unassign after you attach your debdiff and before you subscribe sponsors
[05:53] <dtchen_> in all honesty, sure, you're supposed to, but if your sponsor can't be arsed to do that herself/himself, then...
[05:58] <fabrice_sp> dtchen_, grub2 also boot from lvms
[05:59] <dtchen_> fabrice_sp: yes. I'd be rather up a creek if it didn't.
[05:59] <fabrice_sp> :-)
[08:09] <LucidFox> I should say, Karmic is the first time I found the default desktop theme actually enjoyable.
[10:12] <m4rtin> hi, I've written a couple of patches for bugs in bash-completion and attached them to the relevant bugs; could someone give me information on what I do next? This is my first delve and I'm not sure what the "sponsor queue" is etc.
[10:22] <randomaction> m4rtin: have you created debdiffs?
[10:24] <m4rtin> randomaction: yes, I have uploaded the debdiff as an attachment on the bug and tested the fix using dpkg. Just read the Sponsoring process and gathered I am now supposed to subscribe the sponsors, so just did that. Was that correct?
[10:24] <randomaction> yes
[10:24] <randomaction> and set status to Confirmed
[10:25] <m4rtin> yep, status Confirmed, assigned-to: Unassigned
[10:25] <randomaction> if it's a regular bug (i.e. not security or SRU)
[10:30] <m4rtin> yeah, just regular - thank you :)
[10:31] <m4rtin> presumably it will then show up in the sponsor queue listed above (delayed?)
[10:31] <randomaction> yes it will
[10:34] <randomaction> m4rtin: is it bug 435055?
[10:35] <m4rtin> yes
[10:35] <m4rtin> (don't laugh! I appreciate it's a tiny bug, but I thought a small fix for a first attempt at submitting would be preferable)
[10:36] <randomaction> I'm not a MOTU but I think I can give you some hints
[10:36] <randomaction> so that your debdiff looks better
[10:37] <randomaction> the syntax for closing a bug in changelog is LP: 435055
[10:37] <randomaction> sorry, LP: #435055
[10:38] <randomaction> and the target in changelog should be lucid, not karmic
[10:39] <m4rtin> ah ok, let me fix that. Presumably I should change control and changelog and then re-"debuild"
[10:40] <randomaction> yes, or for such small changes you can hand-edit your debdiff
[10:42] <randomaction> and this package uses a patch system (quilt)
[10:42] <m4rtin> ah ok, thanks - my other question was, do you have any tips for this kind of situation: say I fix a bug and then want to work on another in the same package, the debdiff must be against the current source I assume, so installing will re-introduce the existing bugs I have fixed... any recommendations?
[10:43] <m4rtin> oh, does that (quilt) mean that I have missed something?
[10:44] <randomaction> you should format your change as a patch contained in debian/patches
[10:44] <randomaction> https://wiki.ubuntu.com/PackagingGuide/PatchSystems
[10:45] <m4rtin> damn. ok - let me go have a read
[10:49] <m4rtin> so, if I understand correctly, I should 1.) make my changes 2.) push a new patch 3.) create a quilt README 4.) quilt refresh 5.) pop the patch
[10:51] <m4rtin> no, I assume 1 and 2 were the wrong way around
[10:51] <randomaction> you run: 1) quilt push -a (applies all patches) 2) quilt new <patchname> 3) quilt add <filename> 4) <make a change> 5) quilt refresh
 would be bash_completion in your case
[10:53] <m4rtin> ok - I'll redo the patch and attach it. Thanks for the help and apologies for my ignorance
[10:53] <randomaction> and 0) export QUILT_PATCHES=debian/patches
[10:54] <randomaction> and dch (before or after, as you wish)
[10:54] <m4rtin> dch should be at step 4? or is this irrelevant?
[10:54] <m4rtin> (and do I need to submit a debdiff as well as the quilt diff?)
[10:55] <randomaction> additions to debian/changelog don't go into quilt patch
[10:55] <m4rtin> ah ok, so it doesn't matter when that is done
[10:55] <randomaction> generally, patch systems are used to track changes outside of debian/
[10:55] <randomaction> yes
[10:55] <m4rtin> and, therefore, I assume a debdiff is also used
[10:56] <randomaction> and quilt patch will make it into debdiff
[10:56] <m4rtin> oh ok great :)
[10:57] <m4rtin> actually, presumably the quilt patch system also deals with my problem of multiple changes, because I just push another change (provided there are no changes to the same file)
[10:58] <randomaction> if can fix several bugs in one upload (one debdiff)
[10:59] <randomaction> *you can
[10:59] <m4rtin> I think, as this is my first attempt, I'll stick to just fixing one very simple bug and learn to get it right
[11:07] <m4rtin> randomaction: do I need to do a quilt add README? PackakingGuide suggests so, but your instructions didn't
[11:08] <randomaction> it's required by Debian policy, so Debian maintainer of the package should do it at some point
[11:08] <m4rtin> but I should not?
[11:08] <randomaction> this qualifies as a general cleanup, so shouldn't be done in a bugfix
[11:09] <m4rtin> ok, thank you
[11:09] <randomaction> the difference between Debian and Ubuntu should be kept minimal for ease of maintenance
[11:09] <m4rtin> right, I've done my quilt refresh
[11:10] <m4rtin> do I then need to pop the patch?
[11:10] <randomaction> debuild will do it
[11:10] <m4rtin> oh ok, so now I just go through the same debuild process as usual?
[11:12] <randomaction> do you have a new patch created in debian/patches?
[11:12] <randomaction> and its name in debian/patches/series?
[11:13] <m4rtin> yep
[11:13] <randomaction> you should be ok to debuild then
[11:13] <m4rtin> great - I'll give it a shot
[11:22] <m4rtin> and it's up there
[12:17] <diwic> What is the reasoning behind disabling apport for a final release?
[13:36] <ari-tczew> sponsors, can someone take a look on bug #413657 ?
[14:51] <dtchen_> ari-tczew: you have e-mail WRT coccinelle.
[14:52] <dtchen_> diwic: no real need to flood LP
[14:56] <DktrKranz> whois Laney Laney
[14:56] <dtchen_> idle time, eh?
[14:57] <DktrKranz> damn... well, Laney, I will point you to a mail I've just sent to debian-legal wrt pidgin-facebookchat
[14:57] <DktrKranz> yup :)
[15:00] <diwic> dtchen_: but is it really necessary? LP has duplicate detection, and it would be useful to catch bugs in the stable distribution.
[15:00] <dtchen_> diwic: I'm not one to debate this particular policy :-)
[15:06] <iulian> DktrKranz: jpds is the maintainer of pidgin-facebookchat in Debian.
[15:08] <dtchen_> bddebian: hiya, any ETA for libsdl1.2_1.2.14 in Debian? Any way I can assist?
[15:08] <DktrKranz> iulian: err... indeed :)
[15:08] <DktrKranz> anyway, jpds and iulian: http://lists.debian.org/debian-legal/2009/11/msg00029.html
[15:08] <iulian> DktrKranz: Yea, I've read the mail.
[15:09] <iulian> Thanks.
[15:09] <bddebian> dtchen_: I know they asked upstream to add pkg-config files but other than that no, I don't know yet :(
[15:09] <DktrKranz> I'm not sure if it's your case, but if it is, thee could be legal troubles
[15:10] <iulian> DktrKranz: Indeed.
[15:10] <dtchen_> bddebian: ok. 1.2.14 is blocking a buttload of audio bugs for me, but that's not such a big issue; I'd just rather not spend cycles backporting to 1.2.13. Thanks!
[15:10] <chrisccoulson> diwic - apport is disabled in the stable distribution mainly because the bugs that users will report are all duplicates of the bugs we already know about from testing
[15:10] <chrisccoulson> in that case, all it does is annoy users and spam people subscribed to those bug reports
[15:11] <chrisccoulson> s/all/mostly
[15:11] <diwic> chrisccoulson: I thought LP automatically duplicated those with the existing ones
[15:12] <dtchen_> that would be part of the spam :-)
[15:13] <chrisccoulson> indeed, dtchen is right
[15:13] <chrisccoulson> apport is just not very useful in a stable distribution, when users are just going to report bugs that we already know exist
[15:14] <bddebian> dtchen_: Understood.  Let me see if I can push the issue.
[15:14] <dtchen_> bddebian: no sweat, seriously. I have so many other bugs. :-)
[15:15] <bddebian> Don't we all? :)
[15:16] <dtchen_> nah, I could use a few more. :-)
[15:16] <bddebian> I have a couple I could give you :)
[15:16] <dtchen_> I'm not saying bitrot is a good thing :-)
[15:17] <maco> wow this channel looks happy today
[15:17] <dtchen_> I think there's a coccinelle upload in your future, maco.
[15:18] <maco> ok
[15:18] <dtchen_> (http://kernel.ubuntu.com/~dtchen/upload_queue/)
[15:18] <maco> my keys are on laptop. think its ok to get it out?
[15:18] <diwic> chrisccoulson: I don't really agree, but at least I get the reasoning.
[15:18] <dtchen_> maco: (eh, you're ircing from class; I think you know the answer to that question)
[15:20] <maco> dtchen_ ...no?
[15:21] <Hobbsee> maco: look into debsign -r if you haven't already
[15:22] <StevenK> That assumes that her laptop or other machine with keys are network accessible
[15:23] <Hobbsee> true
[15:23] <maco> Hobbseeok
[15:23] <Hobbsee> but if they weren't accessible, then why would she be asking if it was ok to get them out?  ;)
[15:23] <maco> StevenK yeah i can get on the school vpn :)
[15:24] <maco> booo @ freenode java applet. it doesnt put a space after tab-completing names
[15:27]  * StevenK didn't know Freenode had one of those
[15:28] <maco> http://java.freenode.net/
[15:28] <maco> they added it when they banned mibbit
[15:28] <StevenK> Ahhh
[15:38] <jdong> they....
[15:38] <jdong> replaced an AJAX applet with a Java applet?
[15:43] <ari-tczew> qa.ubuntuwire.com isn't work :-(
[15:47] <maco> jdong they figured they could control the java applet better than they could abuses of mibbit
[15:47] <jdong> lol
[15:48] <jdong> if they switch it to Macromedia Shockwave they'd have no abuses!
[15:48]  * maco headdesk
[15:49] <StevenK> jdong: Or users
[15:50] <jdong> that's the whole point :)
[15:50] <jdong> or switch it to silverlight and only directhex will be on IRC.
[15:50] <jdong> *DUCKS* ;-)
[15:57] <bbigras> bug 476360 and bug 428017 has a fix uploaded to karmic-proposed. It's waiting for a MOTU SRU ACK. If someone has time. the first bug fix make the plugin work again
[15:58] <ScottK> jdong: ^^^
[15:58] <chrisccoulson> diwic - why don't you agree? what do you think would be the benefit for enabling it by default?
[15:58] <dtchen_> just missed him, apparently :/
[15:58] <bbigras> ScottK: thanks :)
[15:59] <chrisccoulson> heh, just noticed that. thanks
[16:00] <ari-tczew> any sponsor bored here? :P bug #482663
[16:01] <dtchen_> maco: *cough* s/karmic/lucid/ !
[16:01] <maco> dtchen_: yeah yeah just did that
[16:01] <maco> i noticed quick and poked Hobbsee
[16:02] <dtchen_> maco: danke
[16:02] <Hobbsee> yay for soyuz auto-rejecting it
[16:02] <maco> :( i screwed up already
[16:02] <dtchen_> that's hardly a screw-up
[16:03] <dtchen_> just don't break the toolchain like I did :-)
[16:03] <jdong> bbigras: both diffs look good to me
[16:03] <jdong> ScottK: am I blind, or is there no kopete-facebook in the queue/
[16:03] <jdong> (I hope those were uploaded against karmic-proposed, versioned properly)
[16:03] <maco> dtchen_: O_o
[16:03] <ScottK> jdong: It's not uploaded yet, but I think there's a debdiff in the bug
[16:04] <ScottK> Riddell said he was waiting on a ack to upload
[16:04] <jdong> hmmph two separate bugs
[16:04] <jdong> should we make one new SRU bug to encampass both diffs?
[16:11] <jdong> bbigras: ok I gave you an ACK on bug 476360 to proceed with karmic-proposed SRU'ing of both patches
[16:12] <jdong> I see Riddell already uploaded them to Lucid as one, so the same will work for karmic-proposed...
[16:12] <bbigras> jdong: ok thanks, is there documentation about how and where to upload it?
[16:13] <jdong> ScottK: can you help bbigras through the rest of the process? I gotta head out for a meeting right now
[16:14] <ScottK> jdong and bbigras: Not right now, as I'm heading out too, but we'll get it taken care of.
[16:15] <bbigras> ScottK: ok thanks. I'll ping Riddell to see if he has time
[16:53] <ari-tczew> ScottK: when ubuntu-archive will sync packages?
[17:01] <geser> ari-tczew: usually the archive admin of the day processes them, but with uds next week I don't expect to see them processed before the week after uds
[17:04] <ari-tczew> OK
[17:11] <goshawk> how do i modify a patch which have been created with quilt?
[17:13] <DrKranz> quilt push patchname; edit files; quilt refresh; quilt pop -a
[17:13] <geser> apply the patch with quilt, edit the files you need to modify (don't forget to add them, if they aren't already touched by that patch), "quilt refresh"
[17:21] <goshawk> sorry, very bad connection
[17:22] <goshawk> DrKranz: where should i run quilt push? in the root of the package or in debian dir?
[17:22] <DrKranz_> in package root, you probably have to export QUILT_PATCHES=debian/patches beforehand
[17:23] <goshawk> yes
[17:23] <goshawk> it works now
[17:23] <goshawk> ;)
[17:45] <serialorder> anyone know a way I can convert diff in RCS format to unified format?
[18:09] <DrKranz_> jdong: time to put your motu-sru hat on for bug #433924 ?
[18:18] <ari-tczew> how often https://merges.ubuntu.com/universe.html is updating?
[18:31] <jpds> ari-tczew: /topic #ubuntu-devel: MoM up to date as of Monday 4am, but now stalled
[19:58] <ScottK> jdong: Looking for an ack for Bug 384929
[19:59] <maco> jdong: while youre at it bug 317366 needs an sru ack
[20:11] <jdong> ok ok jdong just returned from 2 hours to himself
[20:11] <jdong> let him catch up and caffeinate first!
[20:11] <maco> jdong talks about jdong in the 3rd person?
[20:11] <jdong> for now he does
[20:14] <jdong> ScottK: 384929 acked.
[20:14] <ScottK> jdong: Thanks.
[20:16] <ScottK> Meh.  Too late (you added your comment)
[20:17] <jdong> and debdiff on 317366 is acked.
[20:18] <jdong> nov 5th... wonder why that never made it to my LP bugmail
[20:18] <jdong> oh. 15 minutes ago
[20:18] <jdong> must've been recently subscribed
[20:18] <maco> jdong: thanks
[20:19] <jdong> welcome :)
[20:20] <maco> jdong: that bug has tasks open for karmic and jaunty. is ack for both?
[20:21] <jdong> maco: I only saw a debdiff for Karmic, but a similar debdiff at jaunty would be covered under the ACK too :)
[20:21] <maco> jdong: okiedoo
[20:23] <serialorder> how would you list multiple lp bugs in a  changelog would (LP: #nnnn, nnnn2, nnnn3) work?
[20:23] <maco> i think you need to include LP: each time
[20:23] <jdong> that's correct.
[20:24] <serialorder> so it would be (LP: #nnnn, LP: #nnnn2, LP: #nnnn3)
[20:24] <jdong> correct
[20:24] <serialorder> ok thanks
[20:24] <maco> jdong: ergh...jaunty and karmic are both 9.06-1 so karmic's gettin -1ubuntu0.1, but what would jaunty get? O_o
[20:24] <jdong> ugh I hate this game.
[20:25] <maco> lucid got -2ubuntu1
[20:25] <jdong> well we've got a couple options here....
[20:25] <jdong> we could play the game the security team plays with Firefox releases
[20:25] <geser> 9.06-1ubuntu<IP_ADDRESS> and 9.06-1ubuntu<IP_ADDRESS> or something like that
[20:25] <jdong> i.e. 1ubuntu<IP_ADDRESS>
[20:25] <jdong> i.e. 1ubuntu<IP_ADDRESS>
[20:26] <jdong> or we can play geser's game :)
[20:26] <kees> https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
[20:27] <kees> when you have colliding versions, the best way to handle it is the ubuntu0.MM.mm.1 style
[20:27] <jdong> cool.
[20:27] <jdong> kees wins because he has a wiki citation!
[20:27] <kees> heh.  not sure if that counts, since I wrote it.  ;)
[20:28] <jdong> hahaha :)
[20:28] <jdong> well if I could make stuff up on the SRU wiki page I would too ;-)
[20:28] <kees> hehe
[20:28] <maco> 9.06-1ubuntu<IP_ADDRESS>) karmic-proposed; and
[20:28] <geser> jdong: quick write two wiki pages to trump kees' one wiki page :)
[20:28] <maco> (9.06-1ubuntu<IP_ADDRESS>) jaunty-proposed; ?
[20:29] <jdong> hahaha
[20:29] <jdong> maco: reasonable to me.
[20:29]  * jdong would eventually like to see backports use numeric suffixes too
[20:29] <jdong> since not very far from now we are gonna run out of ascending letters
[20:29] <maco> ok now what about the part where i realized jaunty was the same version *after* uploading karmic's?
[20:29] <ScottK> maco: You want 1ubuntu<IP_ADDRESS>
[20:29] <ScottK> (the missing leading 0 is important)
[20:30] <jdong> maco: that part, you've got ScottK with the big red button.
[20:30] <maco> ScottK: oh god. 2010 is coming.
[20:30] <ScottK> Yep.  2012 too
[20:30] <maco> haha
[20:30] <maco> UGLY version strings
[20:31] <dtchen_> no, ugly would be Qt.
[20:32] <dtchen_> I think I've done a few myself.
[20:32] <maco> ScottK: can you hit that button?
[20:32] <EzraR> people should only change packages with patches and link the patch to the changelog entry
[20:33] <EzraR> that would make life easy
[20:33] <kklimonda> maco: it's not that ugly - have you seen qt version from karmic? ;)
[20:33] <dtchen_> kklimonda: jinx
[20:33] <maco> does it have a "-really"?
[20:33] <kklimonda> yeah
[20:33] <dtchen_> no, no hyphen
[20:34] <jdong> did it hurt too much to bump the epoch?
[20:34] <kklimonda> right, no hyphen but really is there... and I can remember an even better version string from the past..
[20:35] <kklimonda> jdong: then we would have to convince debian maintainer to add epoch too
[20:35] <ScottK> maco: If you're going to use the release number approach you need to do it for both Karmic and Jaunty.
[20:35] <kklimonda> (I remember similar discussion from 6 months ago when we had a similar problem with python-storm)
[20:36] <serialorder> is there a way to convert a patch from rcs format to unified?
[20:36] <maco> ScottK: hence red button
[20:36] <maco> ScottK: im redoing with it for both of them
[20:36] <ScottK> OK.  Rejected
[20:36] <maco> thank ye
[20:36] <ScottK> No problem.
[20:36] <dtchen_> oh man, old-releases.ubuntu.com/ubuntu/pool/universe . *shudder*
[20:37] <maco> kklimonda: i remember apache or mysql or something like that having a "really" string
[20:37] <kklimonda> maco: I think it was mysql
[20:38] <maco> yeah i think so too
[20:38] <ScottK> Yep
[20:38] <kklimonda> and I think ScottK could find an even better example of weird version string from some -updates (I remember him pasting it in the past ;) )
[20:38] <ScottK> I think instead of really, we should use the IRC nick of the person that messed it up.
[20:38] <maco> haha
[20:40] <ScottK> I had to use an awful one in backports to revert a bad Flash backport once
[20:40] <dtchen_> man, you gals/guys are really triggering *all* my bad Ubuntu memories
[20:40] <dtchen_> vlc, flashplugin-nonfree, ...
[20:41] <ScottK> And from you, that's saying something.
[20:42] <maco> why?
[20:42] <ScottK> Given that you live inside a major nightmare
[20:42] <maco> because the packages he works on are most other people's bad ubuntu memories?
[20:42]  * maco ducks
[20:42] <mok0> heh
[20:45] <maco> kees: "SECURITY UPDATE: [how the bad guys could get you]" *snicker*
[20:45]  * jdong loved his markov generated security advisories
[20:48] <jdong> haha I still have a copy of it
[20:48] <jdong> http://jdong.mit.edu/~jdong/usnramble.txt
[20:49] <maco> jdong: LINEBREAKS
[20:50] <jdong> "ntpd does not check this privilege when executing
[20:50] <jdong> non-Postfix commands"
[20:50] <jdong> hahaha
[20:50] <jdong> they almost sound real.
[20:50] <maco> huh?
[20:51] <maco> oh...i see...
[20:51] <jdong> I fed all of the USN's up to some date through a markov generator :)
[20:51] <jdong> just to see what vulnerabilities it'd invent
[20:52] <mok0> jdong, on a different note, you need help with backports?
[20:52] <jdong> mok0: that would be appreciated, yes
[20:52] <mok0> jdong: I've been on the applicants list for quite some time
[20:53] <jdong> *looks
[20:53] <jdong> yes you are
[20:53]  * ScottK +1's mok0 for ubuntu-backporters.
[20:53] <jdong> well, welcome aboard, mok0 :)
[20:54] <mok0> Thanks :-)
[20:54] <jdong> are you familiar with what to do, or do you need a quick tour?
[20:54] <mok0> jdong, a quick tour might be good
[20:55] <serialorder> ill try one more time, is there a way to convert a patch from rcs format to unified?
[20:55] <mok0> jdong: but the packages that interest me the most are "leaf packages"
[20:55] <serialorder> sorry i mean a diff
[20:55] <ScottK> serialorder: I doubt anyone here knows.
[20:55] <jdong> mok0: leaf packages are definitely the ones that are best for backporting
[20:56] <jdong> general rules of thumb is that we'd prefer that they build cleanly with no source changes...
[20:56] <mok0> serialorder: rcsdiff ?
[20:56] <ScottK>  ^^^ The only one old enough to know.
[20:56] <jdong> for those, we just ask for 2 or so reports that the built package works
[20:56] <maco> serialorder: you could probably write a perl script...
[20:57] <mok0> mok0: errh, perhaps it's rdff
[20:57] <mok0> rdiff
[20:57] <jdong> and then all you have to do is verbally ACK and subscribe ubuntu-archive.
[20:57] <jdong> source change backports should be acked by a backporter and uploaded into the -backports pocket; and an archive admin will poke it through
[20:57] <jdong> umm... I believe nowadays we're using the "Confirmed" state to mark a backport that's approved and "in progress" to mark uploaded source-change backports
[20:58] <mok0> jdong: ... and should not introduce new dependencies I guess
[20:58] <jdong> idn if the UbuntuBackports wiki page has been updated to reflect that yet
[20:58] <ScottK> In progress for ones that are acked to the archive too
[20:58] <jdong> mok0: I personally don't have a big objection to needing to pull in new dependencies
[20:58] <jdong> it will make update-manager upset enough to request a partial upgrade
[20:58] <jdong> more importantly is don't break any reverse dependencies
[20:58] <ScottK> The biggest thing to worry about is things with rdpends.
[20:58] <ScottK> Yeah
[20:59] <jdong> and for server packages and other security-sensitive ones, keep in mind the maintenance commitment.
[20:59] <mok0> jdong: maintenance-commitment?
[20:59] <jdong> if we're backporting from one stable release to another, we can easily also backport over subsequent -security updates... but if we plucked mysqld from lucid right now...
[20:59] <serialorder> mok0, thanks looking at it
[21:00] <jdong> it's a bit troublesome if someone finds a security bug in it
[21:00] <mok0> jdong: so, you mean a maintenance commitment from the backporter to keep an eye on problems with the package?
[21:00] <jdong> mok0: right
[21:01] <ScottK> There's no formal commitment, we just don't want to get stuck in a position were it's hard to fix.
[21:01] <jdong> although technically we don't have a support/maintenance guarantee in Backports, we'd rather not take that to an extreme.
[21:01] <jdong> for example, in the past I've dug myself into a hole with Firefox backports before.
[21:01] <ScottK> jdong: Speaking of which, the qt4-x11 in hardy backports needs updating, but I can't find anyone to test it.  It should be a no-change from intrepid-security.
[21:01] <jdong> ended up that we had something like gutsy-backports firefox collecting dust and nobody cared enough to go freshen it up.
[21:02] <jdong> ScottK: hmm if it was a -security change, then my gut feeling would be to just backport it
[21:02] <kklimonda> btw, are there any plans to enable users to easily install selected packages from -backports ?
[21:02] <ScottK> jdong: Well it's also a big stack of other stuff too.
[21:02] <jdong> lovely.....
[21:02] <ScottK> kklimonda: There's a spec for it for Lucid
[21:03] <kklimonda> I almost remember reading something about iit
[21:03] <mok0> Well, I imagine there are many users who don't want to upgrade every 6 months... but still want newer versions and the bug-fixes that come with them. There's a balance between doing that and upgrading
[21:03] <jdong> mok0: absolutely
[21:03] <jdong> mok0: the challenge will be that the testing userbase rapidly declines as a release ages :)
[21:04] <mok0> Using backports should give you a certain amount of updates, but not everyrhing
[21:04] <kklimonda> and what is the general rule about backporting to LTS? for example could I backport package from LTS+2 to LTS? wouldn't it be a problem if someone tried to upgrade system to LTS+1?
[21:04] <ScottK> jdong: qt4-x11 | 4.4.0-1ubuntu5~hardy1 | hardy-backports | source and qt4-x11 | 4.4.3-0ubuntu1.4 | intrepid-security | source
[21:04] <jdong> kklimonda: should be backported to every release in between too
[21:05] <jdong> ScottK: oh groan. Any ABI/API changes there?
[21:05] <jdong> kklimonda: I guess the exception is for LTS's where LTS+1 is already out-of-support.
[21:05] <ScottK> jdong: Shouldn't be.  qt4-x11 promised compatibility
[21:05] <jdong> cool!
[21:05] <jdong> that means we've got an external party to blame right? ;-)
[21:05] <ScottK> Sure.
[21:06] <kklimonda> right, that's how our users will see it ;)
[21:06] <kklimonda> I just had to explain to the irritated user that we don't ship neither gtk+1.2 nor libartsc0 (or similar)...
[21:07] <jdong> haha and I had to explain the same about libstdc++5.
[21:07] <jdong> and it wasn't long ago that someone asked about gcc-2.95
[21:07] <kklimonda> the libstdc++ was always the mess..
[21:07] <maco> 2?
[21:07] <mok0> kklimonda: ... but if you want basic upgrades in GTK or QT versions, you might as well upgrade to a newer release
[21:07] <maco> someone asked in -kernel about 2.6.18 headers
[21:08] <jdong> lol
[21:08] <maco> did any release even ship 2.6.18? edgy was 17...
[21:09] <jdong> yeah we definitely had a 2.6.18.
[21:09] <kklimonda> btw, is it just me or had rmadison got faster for ubuntu lately? I don't have time to prepare a tea anymore ;)
[21:09] <ScottK> But I don't think we ever released with it
[21:10] <jdong> kklimonda: my umadison always gets rmadison answers the fastest.
[21:10] <jdong> (haha yes, uber madison)
[21:10] <dtchen_> no, we never released 2.6.18.
[21:11] <dtchen_> http://old-releases.ubuntu.com/ubuntu/pool/main/l/linux-source-2.6.*
[21:11] <jdong> it must be Debian I'm thinking of then
[21:12] <maco> jdong: yeah i think etch had it
[21:12] <maco> centos 5 definitely did
[21:12] <ScottK> Has.  It's still supported
[21:12] <maco> yeah that
[21:12] <dtchen_> linux-source-2.6.18 | 2.6.18.dfsg.1-24 |     oldstable | all
[21:12] <dtchen_> linux-source-2.6.18 | 2.6.18.dfsg.1-26 | oldstable-proposed-updates | all
[21:14] <kklimonda> dfsg? what non-free things linux source have?
[21:15] <maco> ScottK: green button?
[21:15] <jdong> kklimonda: the firmware tree.
[21:15]  * ScottK looks
[21:15] <mok0> kklimonda: the kernel has certain binary blobs that are non-free
[21:16] <ScottK> maco: The task for Jaunty needs to be accepted.
[21:17] <mok0> kklimonda: ... rather, certain kernel modules
[21:17] <maco> ScottK: can i accept it since jdong said ack in here?
[21:17] <ScottK> maco: Yes.  As a MOTU you can in general.
[21:17] <maco> ScottK: i meant in terms of policy
[21:17] <jdong> yes, you can accept the task :)
[21:17] <ScottK> Accepting that task is more like "Yeah, seems like something we might want to fix" whereas motu-sru ack is "this exact fix is approved to go in"
[21:18] <maco> ah ok
[21:18] <maco> ok button pressed
[21:18] <maco> your turn :P
[21:18]  * maco throws hot potato
[21:21] <ScottK> Done
[21:21] <maco> thank you
[21:22] <ScottK> Thank you for taking care of it.  My part's easy.
[21:23] <maco> hey its kklimonda's patch :P
[21:23]  * ScottK notes maco has the buildd's monopolized for all but armel and hppa at the moment.
[21:23] <ScottK> Yeah, but you get to thank him.
[21:23] <maco> hahahaha
[21:24] <maco> already did
[21:24] <maco> (hahahaha @ buildds)
[21:43] <ScottK> ari-tczew (or whoever was asking about qa.ubuntuwire.com): It's fixed.
[21:47] <fabrice_sp> ari-tczew, I'll put on hold the merge of incron: the Debian maintainer seems to be willing to include the patch
[21:52] <ari-tczew> fabrice_sp: I don't know what Debian maintainer is doing
[21:52] <ari-tczew> MoM comment was free, no bug request...
[21:52] <fabrice_sp> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548786
[21:52] <kklimonda> what are going to be requirenments for being Ubuntu developer after archive reorganization?
[21:53] <maco> kklimonda: the definition of ubuntu developer will change a bit
[21:53] <maco> kklimonda: youll apply to the team that covers the packages you concentrate on
[21:53] <fabrice_sp> ari-tczew, I usually reports all patches to Debian to see if Debian adopt the change, so that we can sync after, and reduce the Ubuntu worload
[21:53] <kklimonda> maco: so there will be a desktop team, server team, python team etc. ?
[21:54]  * TheMuso waves from a somewhat similar timezone as some of you.
[21:54] <fabrice_sp> ari-tczew, anyway, you should have asked me before working on the merge: I an the last uplaoder of the pacakge
[21:54]  * ScottK waves back to TheMuso
[21:54] <ScottK> kklimonda: Something like that.  What happens for packages covered by no team is subject of a session at UDS.
[21:55] <maco> kklimonda: theres going to generalist-dev too
[21:55] <ScottK> ari-tczew: fabrice_sp is correct.  The first thing is says on https://merges.ubuntu.com/universe.html is "If you are not the previous uploader, ask the previous uploader before doing the merge. "
[21:56] <kklimonda> ScottK: maybe it's time to admit we don't have manpower needed to maintain all of them? :/
[21:56] <ScottK> maco: How exactly that's going to work is not clear yet (at least to me)
[21:56] <ScottK> kklimonda: Universe has never been as well maintained as Main, but it has improved significantly in the last two years I've been around.
[21:56] <dtchen_> kklimonda: no one has ever claimed that "we" have enough manpower
[21:57] <TheMuso> i/c
[21:57] <kklimonda> dtchen_: true
[21:57] <dtchen_> and yes, it has gotten much better since 5.04
[21:57] <kklimonda> heh, I should get my stuff together and upload all patches for piuparts already..
[21:57] <fabrice_sp> that's why it's better to try to have changes adopted by Debian, instead of merging :-)
[21:58] <ScottK> fabrice_sp: +1
[22:00] <ari-tczew> OK devs
[22:01] <TheMuso> c
[22:01]  * TheMuso must be tired.
[22:01] <TheMuso> ]:)
[22:01] <ari-tczew> fabrice_sp: could you review this bug #434433
[22:01] <kklimonda> is python 2.5 going to be supported in lucid?
[22:02] <maco> TheMuso: why do you say that? because you just flew to yesterday?
[22:02] <ScottK> kklimonda: No.
[22:02] <maco> or from tomorrow to today. or something.
[22:02] <wgrant> One Python version? Excellent.
[22:02] <ScottK> So far
[22:02] <fabrice_sp> ari-tczew, I was having a quick look at bug 482657
[22:02] <TheMuso> maco: Something like that.
[22:02]  * ScottK doesn't know the 2.7 schedule
[22:02] <wgrant> ScottK: Mid-2010.
[22:03] <ScottK> Ah, good.
[22:03] <fabrice_sp> ari-tczew, there seems to be an empty change in debian/rules (dh_installchangelog)
[22:03] <ScottK> Of course we now have exactly no python version in common with Debian.
[22:03]  * ScottK wishes the Ubuntu and Debian python maintainers would coordinate better.
[22:03] <ari-tczew> fabrice_sp: and what next?
[22:04] <fabrice_sp> could you just check if this change has been reported to Debian, and if it seems to be willing to adopt it?
[22:04] <fabrice_sp> s/it seems/Debian seems/
[22:05] <kklimonda> ScottK: python-support ships symlinks for python-support.pth for both 2.6 and 2.5 versions - python-support.pth for 2.5 is a dangling symlink. Can I assume that the same will happen when we ship 2.7? i.e. there will be another dangling symlink for 2.7 installed?
[22:06] <ScottK> If we get 2.7, it won't be dangling.
[22:06] <ari-tczew> fabrice_sp: do you mean about dh_installchangelog ? if yes, it is only a mistake made by me, during edit debian/rules
[22:06] <serialorder> fabrice_sp, perhaps the MOTU merging guides should be updated with directive to check with debian to see if they will accept the merges
[22:07] <kklimonda> ScottK: but in the default instalation when we ship only one version
[22:07] <ScottK> kklimonda: That isn't always true
[22:07] <fabrice_sp> ari-tczew, yes.
[22:08] <fabrice_sp> serialorder, makes sense, yes. You just volunteered to do that, right? :-)
[22:08] <kklimonda> ScottK: so the best idea is to ignore it (this broken symlink is one of things that stops piuparts from working out of the box in ubuntu)
[22:09] <serialorder> fabrice_sp, i guess I did, I just sya that because I work on merges a lot and noboy has ever suggested asking debian to incorporate first
[22:09] <serialorder> if relevant i always submit upstream after themerge though
[22:10] <fabrice_sp> serialorder, I would say both, as Debian may want to integrate the patch before, but that's fine also
[22:10] <fabrice_sp> the goal is to reduce the difference between Debian and Ubuntu
[22:11] <fabrice_sp> so if it goes through upstream, it's fine also (but may take longer) :-)
[22:11] <serialorder> fabrice_sp, sorry i meant deabian not upstream
[22:12] <ari-tczew> https://wiki.ubuntu.com/Debian/ForUbuntuDevelopers
[22:13] <fabrice_sp> for forwarding to debian, submittodebian is your firend :-)
[22:13] <ScottK> kklimonda: I'm not 100% sure.
[22:13] <fabrice_sp> s/firend/friend/
[22:14] <fabrice_sp> it's also a matter of where we are in the dev cycle. Now, we are at the very beginning, so we have 'time' to try to get the patches adopted :-)
[22:15] <ari-tczew> fabrice_sp: you have acked my request, after sync by ubuntu-archive packages will mark as uploaded by me or by you?
[22:15] <fabrice_sp> ari-tczew, by you, I think
[22:16] <fabrice_sp> never paid attention to that
[22:16] <ScottK> ari-tczew: Should be by you, but sometimes it doesn't work out.
[22:16] <ari-tczew> yhym OK
[22:16] <fabrice_sp> ari-tczew, did you saw the comment of mterry in bug 434433
[22:17] <fabrice_sp> he is saying that he should be a sync, and not a merge
[22:17] <fabrice_sp> s/he/it/
[22:17] <ari-tczew> fabrice_sp: yes, but I have more trust for you, so I want to ask you :P
[22:18] <ari-tczew> so do I need to change bug's name and description to sync instead merge?
[22:19] <ScottK> ari-tczew: Yes
[22:20] <ari-tczew> fabrice_sp: you can give a review just now for sync
[22:21] <fabrice_sp> ari-tczew, you can trust him: he is also a MOTU :-)
[22:21] <fabrice_sp> it should be a sync, yes
[22:24] <ari-tczew> fabrice_sp: done, bug 434433
[22:25] <POX> ScottK: Ubuntu and Debian Python maintainers are^Wis the same person
[22:26] <fabrice_sp> ari-tczew, ok. I'm test building it right now
[22:27] <ScottK> POX: I know.
[22:31] <fabrice_sp> ari-tczew, ack'd. Bed time now. Bye
[22:32] <ari-tczew> thanks, bye