[01:01] <JanC> caliculk: do you really need an old Postgres version?  if so, maybe use Ubuntu 12.04 for now?
[01:01] <JanC> and find some way to upgrade in the next couple of years
[01:02] <caliculk> JanC just to get the data, but I already did so for now. I don't need it anymore.
[01:02] <JanC> okay  :)
[01:26] <dsfsdgdsg> Hi there, How do I allow "user" who is apart of "snort" group access to /var/log/snort/, these are the permission I have so far. (http://paste.ubuntu.com/12147143/)
[01:38] <dsfsdgdsg> in order for a user to have rw do you have set +x ? makes no sense
[01:39] <TJ-> that directory doesn't give the user any permissions
[01:42] <dsfsdgdsg> interesting what should I google to work this out?
[01:42] <TJ-> dsfsdgdsg: look at the pastebin... in particular, look at the owning *user* and *group* - what is the *group* ?
[01:43] <edtoast_46> please try joining #edtoast .I would greatly appreciate it
[01:44] <dsfsdgdsg> the owning groups are *snort* and *adm* ?
[01:44] <TJ-> dsfsdgdsg: no. The owning user is "snort". The owning *group* is "adm". Is your user a member of "adm"?
[01:48] <dsfsdgdsg> no I'm not in group adm only snort, sudo and user
[01:48] <TJ-> dsfsdgdsg: that is why the user doesn't get access to /var/log/snort/
[01:54] <dsfsdgdsg> TJ-: excellent thanks so much I've added myself now have access, If I have 0660 set I cannot see the permissions on file only file names as *user*
[03:09] <caliculk> Alright, a little frustrated, but after trying to modify samba config files, and restart the service, I can no longer properly start or access the samba server.
[03:09] <caliculk> It doesn't show up if I ty to manually access it, if I rollback the config file either.
[03:18] <caliculk> This is what syslog states: http://pastebin.com/C7adWBcd
[09:24] <samthewildone> I recently did a "dpkg reconfigure console..." and my tty1 font is still very small
[09:25] <samthewildone> is there a way I can take this from 7.5pt to like 12 ?!
[09:35] <mybalzitch> https://askubuntu.com/questions/173220/how-do-i-change-the-font-or-the-font-size-in-the-tty-console
[09:36] <mybalzitch> samthewildone: ^
[11:17] <tiblock> Hi. I have binary file "myprogram" and i want to launch it just like "myprogram" what is correct way to do it? I know i can "ln -s" it to /usr/bin or add to PATH, but what is correct way?
[11:17] <bekks> tiblock: Add it to your path.
[11:17] <bekks> Or start it with "./myprogram" after changing to the directory where it is located.
[11:19] <tiblock> bekks, isnt there tools in ubuntu for that? I saw programs do like "update-alternatives" or something and after that programs are working.
[11:20] <bekks> tiblock: update-alternatives will not help you in this case.
[11:20] <tiblock> bekks, okay, thank you
[11:20] <bekks> tiblock: Whats the actual issue, behind your question?
[11:20] <tiblock> bekks, just want to know maybe i doing something wrong
[11:20] <tiblock> but looks like everything is fine
[11:32] <jelly> tiblock: if it's not packaged, you should probably use /usr/local/bin PATH component instead of /usr/bin
[11:42] <tiblock> jelly, thank you
[12:49] <yoko> Hi, my simple question
[12:50] <yoko> install lamp in root account, i have use normal account localhost, example adress localhost = /var/www I have localhost = /home/myaccount/www how added in apache2.conf ?
[12:52] <yoko> ok
[12:53] <teward> yoko: um...
[12:53] <teward> yoko: edit the apache configurations with sudo?
[12:54] <yoko> yes i used sudo
[12:54] <teward> and you edited the apache configurations and pointed the docroot to /home/myaccount/www ?
[12:55] <yoko> my apache2.conf file http://wklej.org/id/1781392/
[12:55] <yoko> yes
[12:56] <yoko> i have use localhost forum in normal account home
[12:56] <teward> ...
[12:56] <teward> you didn't edit this config
[12:57] <teward> or rather
[12:57] <teward> you provdied the WRONG configuration
[12:57] <teward> yoko: the config for the sites is in sites-available.
[12:57] <yoko> i know
[12:57] <teward> first
[12:57] <teward> `sudo a2dissite default`
[12:57] <teward> then edit the default configuration file in the /etc/apache2/sites-available/ folder
[12:57] <teward> then `sudo a2ensite default`
[12:57] <teward> `sudo service apache2 restart`
[12:57] <yoko> ERROR: Site default does not exist!
[12:57] <teward> ...
[12:57] <teward> i hate apache
[12:58] <yoko> lighttp install ?
[12:58] <yoko> It only local localhost on theme created
[12:58] <teward> not what i meant
[12:59] <yoko> http://www.lighttpd.net
[13:01] <teward> yoko: include the /etc/apache2/sites-available/000-default.conf in a pastebin
[13:02] <yoko> http://wklej.org/id/1781396/
[13:03] <teward> yoko: edit line 12 to be the correct docroot.
[13:03] <teward> ie. /home/myaccount/ww
[13:03] <teward> restart the apache2 process - sudo service apache2 restart
[13:04] <teward> see if that fixes it
[13:04] <teward> (and read up on Apache configuration documentation because you should probably try and understand it a little if you're going to be running apache)
[13:06] <yoko> i do
[13:07] <yoko> loclhost in adress - Forbidden  You don't have permission to access / on this server. Apache/2.4.10 (Ubuntu) Server at localhost Port 80
[13:12] <yoko> thank for help hello
[13:30] <linocisco> hi all
[13:31] <linocisco> I am now trying to install ubuntu server 14.04.2 and at the stage of preparing hdd. After ubuntu server and I will install CEntOS later. How should I prepare HDD partition and recommended partition size and type as minimum requirement
[13:31] <linocisco> ?
[13:38] <linocisco> I am now trying to install ubuntu server 14.04.2 and at the stage of preparing hdd. After ubuntu server and I will install CEntOS later. How should I prepare HDD partition and recommended partition size and type as minimum requirement. I am thinking for dualboot
[13:39] <linocisco> I am now trying to install ubuntu server 14.04.2 and at the stage of preparing hdd. After ubuntu server and I will install CEntOS later. How should I prepare HDD partition and recommended partition size and type as minimum requirement. I am thinking for dualboot
[13:41] <RoyK> !ask
[13:42] <RoyK> !patience
[13:42] <RoyK> linocisco: just split it in two if you want dual boot. I'd use a VM for one of them, though. Why are you testing both?
[13:43] <RoyK> linocisco: Both should work well on their own - it's just linux - the choice between them mostly depends on what you're most used to or what you like
[13:44] <linocisco> RoyK, thanks for reply. One OS should be ubuntu server with most common server roles, file/directory .etc and second will be Elastix with is natively bundled with CentOS
[13:46] <RoyK> linocisco: I beleive you can run elastix on ubuntu too
[13:46] <linocisco> RoyK, I dont want to mess up both
[13:47] <RoyK> oh - you mean elastix as in a distro?
[13:47] <RoyK> that one? http://www.elastix.com/en/downloads/
[13:48] <RoyK> just run a VM with it
[13:48] <RoyK> install kvm+libvirt and start virt-manager and install it
[13:48] <linocisco> RoyK, sure. Elastix recommends upgrade only from its release. no modification. I am not happy with performance of VM of my hardware resource.
[13:48] <RoyK> what sort of hardware?
[13:49] <RoyK> a VM usually gets 10% lower CPU than native, so it shouldn't be too much of a problem
[13:49] <linocisco> RoyK, HP Elite 8200 CMT and internet is very expensive here
[13:49] <RoyK> we run 90% of our servers virtualised ;)
[13:50] <linocisco> RoyK, it might be hardware virtualization like VMWare ESX-i. software virtualization is not so good in performance
[13:50] <RoyK> kvm uses hardware virtualisation
[13:51] <RoyK> just like ESXi
[13:53] <RoyK> Amazon is mostly using KVM these days
[13:54] <mybalzitch> I'm glad the most recent kvm update fixed virtualization on my server
[13:54] <mybalzitch> it had been broken for more than a year
[13:55] <RoyK> broken how?
[13:58] <mybalzitch> libvirt would complain about an unknown error when you launched a VM
[13:58] <linocisco> RoyK, Is KVM better than Oracle's Virtualbox?
[13:58] <mybalzitch> linocisco: kvm is not an oracle product, so that's nice
[13:58] <quantic> linocisco: Highly.
[13:58] <linocisco> mybalzitch, i know. it is linux's one
[13:59] <bekks> Virtualbox is an Oracle product, so its not that slow as KVM ;)
[13:59] <RoyK> linocisco: probably about the same - VirtualBox may be better on graphics, though, but usually you won't need that on a server
[13:59] <bekks> You can run VBox headlessly.
[14:01] <RoyK> bekks: yes, you can, but I was thinking about desktop virtualisation - last I tried that with kvm, it wasn't very good, but again, this is about a server, right?
[14:02] <RoyK> oh - seems KVM supports vGPU now too
[14:02] <RoyK> neat
[14:02] <RoyK> ESXi 6 supports that too - not 5.5, though
[14:10] <RoyK> linocisco: how much memory do you have in this box?
[14:14] <linocisco> hi all
[14:14] <linocisco> with reference to http://ubuntuserverguide.com/2013/02/manual-disk-partition-guide-for-ubuntu-server-edition.html, i m not quite sure about partition
[14:16] <RoyK> linocisco: just create a 1GB partition for /boot, with ext2, and then a partition with the rest of the disk for LVM, on LVM, create a LV for swap (same as memory size) and one for root (10GB should do for a start) on ext4. Add more later or increase sizes later if you need to
[14:16] <RoyK> always use LVM - it's way more flexible than partitions
[14:18] <linocisco> RoyK, I am thinking about dualboot as I said. so should I choose 50% first?
[14:19] <RoyK> linocisco: why dualboot? have you even triede KVM?
[14:19] <RoyK> tried, even
[14:19] <RoyK> or tested
[14:19] <RoyK> or whatever
[14:19] <RoyK> try virtualisation first
[14:20] <linocisco> RoyK, i should install KVM , right  ? that will need internet to download, here more dowloading more money here with mobile internet I have here
[14:20] <linocisco> I have never successfully managed dualboot
[14:20] <RoyK> linocisco: the packages aren't very big
[14:20] <RoyK> the virtualisation level is in kernel - all you need are the support packages
[14:21] <linocisco> RoyK, honestly, I have internet with 3G SIM card with Nokia E5 handset. I dont know how to provide internet from that dump nokia to cli only server. that is why I am stuck
[14:22] <RoyK> linocisco: damn - where are you located?
[14:23] <RoyK> I don't think kvm/libvirt/virt-manager is much, though, perhaps a few megs
[14:23] <linocisco> RoyK, preferred not to say. but it is not expensive internet
[14:24] <linocisco> RoyK, preferred not to say. but it is so expensive internet
[16:52] <ren0v0> hi, when partitioning a disk, is it possible to control partition numbers? im trying to create a new partition and its calling it #5 ?
[16:54] <quantic> ren0v0: You're creating a logical partition on an MBR formatted disk.
[16:54] <quantic> ren0v0: That's normal. Primary partitions are 1-4. Extended/logical/whatever are 5+.
[16:55] <ren0v0> ok thanks :D
[16:55] <lordievader> You could choose to go with gpt instead.
[16:55] <quantic> ^
[16:55] <ren0v0> learn something everyday, always wondered why
[17:03] <linocisco> how to edit grub file ? on boot, splash menu is so fast and I can't go into advanced options
[17:06] <lordievader> linocisco: vim /etc/default/grub|/etc/grub.d/*?
[17:07] <lordievader> Then run 'sudo update-grub2'.
[17:38] <linocisco> hi
[17:39] <linocisco> hi
[17:45] <linocisco> hi
[17:45] <lordievader> linocisco: Err, hello?
[17:46] <linocisco> i have problem with grub
[17:47] <linocisco> to change bigger fonts in CLI
[17:47] <lordievader> Grub has little to do with how fonts are rendered in tty's.
[17:49] <linocisco> lordievader, https://www.centos.org/forums/viewtopic.php?f=13&t=2932&sid=bc3bdda5c4cbb8bc4d4c7144e290f5dc
[17:49] <linocisco> lordievader, that trick fixed my fonts on ubuntu server version before
[17:49] <linocisco> lordievader, now I can't find that file. grub.cfg has no such line
[17:51] <lordievader> You don't want to edit /boot/grub/grub.cfg directly.
[17:51] <lordievader> What trick are you referring to?
[17:52] <linocisco> lordievader, in the grub file, I need to find such line "kernel /vmlinuz-2.6-whatever ro root=/lots-of-numbers, KEYTABLE=us rhgb quet"
[17:53] <linocisco> and add nomodeset at the end . that fixed my problem with smaller fonts on CLI
[17:54] <lordievader> linocisco: That is /etc/default/grub.
[17:55] <bekks> lordievader: Which he states does not exist for him.
[17:56] <linocisco> bekks lordievader i swear I had used that trick
[17:56] <linocisco> so what is your trick to make smaller fonts in CLI to make it biggger?
[17:57] <lordievader> If that file ain't there grub is not installed.
[17:57] <linocisco> not only in CLI, also should be bigger in grub boot loader menu lines and font at boot time
[17:57] <lordievader> linocisco: What is the output of 'dpkg -l|grep grub'?
[17:57] <bekks> linocisco: So that file existed. What did you do to it so it doesnt exist anymore?
[17:57] <lordievader> Sounds like a driver not handeling modesetting properly.
[17:58] <linocisco> grub-common, grub-gfxpayload-lists grub-pc grub-pc-bin grub2-common
[17:58] <linocisco> mine is 64bit
[17:59] <linocisco> i formatted HDD and reinstall with 14.04.2 x64
[17:59] <linocisco> before was 32bit
[18:00] <bekks> linocisco: Whats the output of "ls -lha /etc/default/grub"?
[18:00]  * lordievader thought grub-pc or grub-common delivered /etc/default/grub
[18:02] <linocisco> bekks, -rw-r--r-- 1 root root 1.2K Aug22 23:57 /etc/defult/grub
[18:02] <lordievader> So it does exist...
[18:02] <bekks> So that file exists - whats the problem now?
[18:03] <linocisco> let say what I have done to fix small fonts problem is wrong. ok? how do you fix if I were you?
[18:03] <bekks> Lets say you fix your first issue first.
[18:03] <bekks> nomodeset.
[18:03] <linocisco> bekks,  I am looking for the correct file and correct line and correct place to add that "nomodeset"
[18:04] <bekks> !nomodeset | linocisco
[18:08] <linocisco> bekks, thanks. finally Got it. that is what I am asking so long
[18:08] <bekks> You have een clued multiple times on how to do it, bt you ignored all clues.
[18:09] <linocisco> bekks, what I need is only that link "http://ubuntuforums.org/showthread.php?t=1613132"
[18:09] <linocisco> correct ubuntu way
[18:10] <bekks> You were told how to do it the ubuntu way multiple times.
[18:10] <bekks> Whatever - did you fix it now?
[18:11] <linocisco> bekks, done. I didn't understand before I got that link because I am looking for that desired file
[18:12] <lordievader> Yes, and you were given that file several times.
[18:12] <linocisco> lordievader, I didn't see. i m sorry
[18:12] <bekks> And that link, too.
[18:13] <bekks> linocisco: You must have been ignoring clues the whole day then...
[18:14] <linocisco> bekks , I was being told /etc/default/grub. many times, but I dont know exactly where in which line to edit
[18:14] <linocisco> sorry for your time and my time. have a nice day
[18:14] <bekks> You have benn told multiple times.
[18:14] <bekks> *been
[18:16] <linocisco> thanks anyway . done
[18:29] <linocisco> hi all, what is the recommended updated ubuntu server book?
[18:29] <linocisco> with most common troubleshooting real world examples
[18:29] <bekks> linocisco: The online documentation. Printed documentation is out of date before you read it.
[18:45] <lordievader> The best way to learn is to use it.
[18:46] <linocisco> lordievader, somewhat correct. but level of knowledge is not the same for everyone.
[18:47] <bekks> linocisco: you dont need the same level for learning by doing :)
[18:47] <lordievader> Hence the learning ;)
[19:05] <samthewildone> I need help to make my fonts bigger, I tried the dpkg reconfigure console command but, the fonts are still pretty tiny.
[19:07] <samthewildone> oh wait... nevermind I found it !
[19:22] <caliculk> Is logrotate no longer enabled on Ubuntu 15.04 server edition?
[19:31] <caliculk> I seem to be having an issue with logrotate not rotating logs, even when running logrotate -d /etc/logrotate.conf shows the appropriate values to rotate the logs
[21:39] <diego12> hola
[21:53] <samthewildone> currently did a shred from a remote to the server but, still logged in terminal
[21:53] <samthewildone> is there a way I can break away from the terminal and have the shred still run in th background ?
[21:54] <bekks> You would have needed to start it using tmux, screen or nohup
[21:57] <dweller_> Trying to get swap partition to work on a fresh install of 14.04.3. I get this error at startup: "The disk drive for /dev/mapper/cryptswap1 is not ready yet or not present". I have tried following the steps outline here: http://punygeek.blogspot.ca/2012/10/ubuntu-1204-how-to-solve-disk-drive-for.html which does show the swap partition is present after "free -m" but upon reboot, the problem persists.
[22:03] <oste> seeing a crazy situation - i have a deploy script that creates a symlink for nginx to read. It seems like this symlink is not updating - the site is served old symlinks
[22:03] <samthewildone> bekks: yeah kinda figured that out at the last minutew
[22:03] <samthewildone> bekks: thx


[00:17] <anon^_^> Hi, question for devs. Recently a few patches were submitted to LKML to try and address a long standing issue with desktop responsiveness under heavy i/o disk activity
[00:18] <anon^_^> any possibility that these patches will be backported for the next Ubuntu release?
[00:18] <anon^_^> references
[00:18] <anon^_^> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/131094
[00:18] <ubot2> Ubuntu bug 131094 in linux-source-2.6.22 (Ubuntu) (and 2 other projects) "Heavy Disk I/O harms desktop responsiveness (affects: 99) (dups: 6) (heat: 787)" [High,Won't fix]
[00:18] <anon^_^> http://www.phoronix.com/scan.php?page=news_item&px=ODQ3OQ
[00:18] <anon^_^> http://www.phoronix.com/scan.php?page=news_item&px=ODQ3Mw
[00:38] <penguin42> hmm that could explain particularly grim behaviour I've got on systems running off live writable USB disks
[18:57] <kx> I have compiled a kernel obtaining the source with git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git MyDirectory. Now I want to update the files to the latest 2.6.32-24.39 additions. Is there a git command to do that?
[19:04] <kx> I think the git user's manual has my answer
[21:39] <Guest39869> I used my old .config for the 2.6.32-21 kernel to compile the 2.6.32-17 kernel and it installed a lot of new modules. I don't think they were necessary, so is there any way to change this so it won't happen in the future?
[22:06] <squarebracket> has there been any progress on an lbm-wacom package?


[13:03] <CcxCZ> LeoNerd: I guess that's more a question for #launchpad
[13:04] <LeoNerd> m?
[13:04] <LeoNerd> Oh... my question from Friday. Mmmmm lag.
[13:04] <CcxCZ> weekends :-)


[14:56] <mhall119> bilal: happy birthday!
[14:56] <bilal> mhall119: Thank you!
[14:57] <bilal> mhall119: enjoy your weekend!
[15:11] <mhall119> sure will :)
[15:11] <mhall119> got dinner on the smoker already


[00:49] <t1mp> fginther: yes, I saw the approved message on https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/tabs_chevron_asset_update/+merge/190639
[00:49] <t1mp> fginther: but normally all the test reports are linked, here there is nothing
[02:27] <fginther> t1mp, successful test results are only posted for ci (non-approved) jobs. A long time ago, successful autolanding results were also posted, but people complained about too much email spam.
[02:27] <fginther> t1mp, if you're curious, the results are here: https://jenkins.qa.ubuntu.com/job/ubuntu-ui-toolkit-autolanding/373/
[07:38] <cjwatson> asac: I can't meet my promises for opening the next series in a timely manner because Mark hasn't given us a name.
[07:39] <cjwatson> asac: We would have been able to do all the initialisation yesterday and probably open around now if not for that obstacle.
[07:49] <asac> cjwatson: high
[07:49] <asac> hi
[07:49] <asac> >)
[07:52] <asac> cjwatson: so instaed of today we move everything by one day and open on monday?
[07:53] <cjwatson> I have no idea.  We were promised (yesterday) a name by close of play New York time.  That promise was broken
[07:53] <cjwatson> So at this point I can't promise anything until we have a name
[07:55] <ogra_> sigh ...
[07:55]  * ogra_ thought last cycle it was bad
[07:59] <fginther> asac, morning
[07:59] <asac> fginther: hi!
[08:00] <asac> fginther: early bird? or a fire burning somehwere?
[08:00] <fginther> asac, are we ok to re-enable auto merging for unity8
[08:00] <asac> fginther: i think so
[08:00] <fginther> asac, just up for a bit
[08:01] <asac> fginther: does it pass now?
[08:01] <asac> i think they are reasonably close so they can do the final fixes in upstream merger
[08:01] <asac> fginther: ok... so baby time? :)
[08:01] <didrocks> (they should pass now, with the getenv fix)
[08:01] <asac> fginther: anyway. yeah, i guess we can go for it given that didrocks reported that unityu7 passed
[08:01] <fginther> no, :-( both mir and ro images failed all tests for image 100
[08:02] <didrocks> fginther: hum, you didn't get the memo
[08:02]  * didrocks fetches and forwards
[08:02] <fginther> baby in the left arm, laptop on the right
[08:03] <didrocks> fginther: fwed you 2 emails
[08:03]  * fginther reads
[08:03] <didrocks> fginther: and the last random crash was a getenv issue which is fixed (so all should pass now)
[08:16] <t1mp> fginther: ok, thanks :)
[08:30] <asac> didrocks: cjwatson: can we maybe chat a bit about how we do the saucy-updates images? will we just have daily images rolling with cron for that? would they go into "saucy-proposed" and stay there until we roll an update to users?
[08:30] <asac> saucy-proposed == system image channel
[08:31] <didrocks> asac: hum, I think we should still kick them on demand, as it's more to test the infra for stephan basically than having any useful fix for us
[08:31] <didrocks> (apart from the incoming download-manager one)
[08:33] <didrocks> asac: I'm more afraid (and I think we should discuss) about how the dashboard and other tools will support the image numbering
[08:33] <didrocks> if we release images for saucy and T, they might end up with the same version number
[08:33] <didrocks> or different, but saucy > T for instance
[08:33] <ogra_> didrocks, ++ (ondemand)
[08:34] <didrocks> not sure how our tooling supports that
[08:34] <asac> didrocks: so we have touch_ro currently. so from resoruce perspective we could keep it running and could notice if things regress right away (feels also like a good exercise imo)
[08:34] <asac> didrocks: and yes, tooling needs to be discussed and version numbers etc.
[08:35] <didrocks> asac: not sure how this is linked to touch_ro? (probably missing a piece ;))
[08:35] <cjwatson> I don't think anything much needs to be changed on the image-building side
[08:35] <cjwatson> Except possibly version numbering, not really familiar enough with system-image's numbering to help there
[08:35] <asac> cjwatson: does the image builder use a central counter for image numbers?
[08:36] <asac> e.g. is it unique?
[08:36] <ogra_> cjwatson, the test infra works based on image numbering atm
[08:36] <asac> didrocks: we have two dashboards ... touch_mir and touch_ro
[08:36] <ogra_> if we have two same numbers that might fall over
[08:36] <cjwatson> asac: My stuff is all DATE[.COUNTER] where COUNTER is set if there's been more than one build that day.  It is unique per flavour/image-type/series/architecture
[08:36] <asac> i got asked if we want to kill touch_ro and rename touch_mir to touch; maybe we can say touch and touch_saucy
[08:36] <didrocks> asac: right, not sure why we keep testing touch_ro btw :)
[08:37] <didrocks> asac: yeah, that's what I discussed yesterday with vila
[08:37] <cjwatson> asac: I don't know the uniqueness constraints on the system-image stuff, which is all stgraber's
[08:37] <didrocks> and I would +1 from that :)
[08:37] <cjwatson> asac: I would hope that it's only required to be unique per channel or similar
[08:37] <cjwatson> But I don't actually know
[08:38] <didrocks> or we can name that after the channel maybe
[08:38] <asac> right. so i think the version tarball has info about the channel etc. so it doesnt need to be unique across channels
[08:38]  * didrocks looks at the wiki page
[08:38] <vila> didrocks: yes, that 's why asac is pinged on the topic ;)
[08:38] <didrocks> ah ok ;)
[08:41] <didrocks> asac: the thing I'm really afraid of (not related to the infra) is that we publish, let's say, 10 images on the stable channel (saucy)
[08:41] <didrocks> so image 110
[08:41] <didrocks> and 5 in the proposed one (T)
[08:41] <didrocks> once we point stable to T…
[08:41] <didrocks> 105 < 110, not sure if the system-image-dbus daemon will pick it up
[08:42] <cjwatson> shouldn't we be talking about image saucy/110 instead?
[08:42] <didrocks> (and even if it does, it's not clear to the user)
[08:42] <cjwatson> I agree we need to make sure any software consumers work
[08:42] <didrocks> right, saucy/110 makes more sense
[08:43] <cjwatson> I mean, at some point we're going to have to maintain longer-lived stable branches
[08:43] <cjwatson> assuming this stuff gains any commercial popularity/deployment
[08:43] <didrocks> right, they will maybe have their custom name…
[08:43] <asac> didrocks: my understanding is that the device knows well on which channel it is
[08:43] <asac> didrocks: and hence doesnt care about version numbers being unique across all channels
[08:43] <asac> but we should check with stgraber...
[08:43] <didrocks> asac: yeah, but even in the ui, there is just the image build communicated, so if people goes from 110 to 105, it won't be clear to them :)
[08:44] <asac> similarly utah can extract that info etc.
[08:44] <didrocks> right, let's sync with StevenK :)
[08:44] <didrocks> stgraber*
[08:44] <didrocks> (sorry StevenK ;))
[08:44] <asac> didrocks: well, people going from 110 on devel to 105 on saucy (or the other way around) are switching channels
[08:44] <didrocks> asac: not when we'll switch the stable channel to T
[08:44] <asac> we currently don't support that as a UI nor cli feature on the phone
[08:44] <didrocks> they won't know it :)
[08:44] <asac> didrocks: right. thats a visualization thing on the phone then
[08:44] <didrocks> indeed
[08:45] <asac> we should display the build ID like<EMAIL_ADDRESS>- build 98"
[08:45] <didrocks> (at least, the version is a string, phew! ;))
[08:45] <ogra_> ugh
[08:46] <ogra_> we try to roll on top of the distro, lets not put version names in
[08:46] <asac> not sure. it's a build id ... not really a version
[08:46] <didrocks> why not use "1.0 - #98" ?
[08:46] <ogra_> yeah
[08:46] <didrocks> then, switching to T will be "1.1 - #whatever"
[08:46] <asac> didrocks: that doesnt explain which channel you are on
[08:46] <didrocks> or 1.0.1
[08:46] <asac> the UI should clearly display which channel
[08:47] <ogra_> asac, didrocks then lets put in "stable, devel, devel-proposed"
[08:47] <didrocks> as it's rolling, and we change pointers on the channel…
[08:47] <ogra_> but lets not tie to close to distro names
[08:47] <cjwatson> mm, there is the question of what happens when the stable channel flips
[08:47] <cjwatson> I guess we just need to make sure that the version is greater, artificially if necessary
[08:48] <didrocks> right, for potential manufacturers… they will probably stay on older version (whatever version will mean)
[08:48] <ogra_> in fact i think our major version should always match framework/sdk numbers
[08:48] <asac> ogra_: so not sure... lets talk with stgraber. i am sure he has some thoughts given what channels were already there:
[08:48] <asac> http://system-image.ubuntu.com/
[08:49] <ogra_> (or APi or however you want to call it)
[08:49] <asac> so seems we have names of the release... and aliases (stable etc.)
[08:49] <asac> you can track stable
[08:49] <asac> or you can track saucy
[08:49] <asac> its not the same thing
[08:49] <ogra_> asac, we talked already, the plan is to have a stable channel and branch saucy away into that
[08:49] <asac> stable will move on to tripidititity
[08:49] <asac> :)
[08:49] <asac> ogra_: i know
[08:49] <asac> wait
[08:49] <didrocks> and manufacturers can take "saucy"
[08:49] <asac> well. lets have a talk when stgraber is up
[08:49] <asac> :)
[08:50] <didrocks> and will stay spicy/saucy :)
[08:50] <ogra_> we should simply not promote to use the release names, as that will get you stuck somewhere
[08:50] <ogra_> its a one way street ... once we switch devel over you are stuck
[08:50] <didrocks> ogra_: TBH, that's why I pref (version - #id) (and we can map version to saucy, t…)
[08:50] <asac> switch devel over?
[08:50] <asac> whats that?
[08:50] <asac> you mean to T?
[08:51] <ogra_> didrocks, exactly
[08:51] <ogra_> asac, devel always points to the stable image of the devel release
[08:51] <ogra_> bo matter is thats S, T or R or whatever
[08:51] <ogra_> *no matter if that is
[08:51] <asac> right. so we need to first ensure that stable doesnt get updated once we move to T
[08:51] <asac> agreed
[08:51] <asac> lets talk to stgraber
[08:52] <ogra_> stable will get the released sauct SUR image
[08:52] <ogra_> *saucy
[08:52] <ogra_> *SRU
[08:52] <asac> exactly
[08:52] <ogra_> damn, cant type at all today
[08:52] <asac> but then once we start updating tsable from T
[08:52] <asac> it is not saucy anymore
[08:52] <didrocks> ogra_: get some sleep ;)
[08:52] <asac> hence every channel is special
[08:52] <ogra_> asac, what i'm saying is that we need to discourage the usage of the names
[08:52] <didrocks> ogra_: +1
[08:52] <ogra_> people should use stable, devel or -proposed
[08:53] <didrocks> we can even use "13.10 - #buildid"
[08:53] <ogra_> and we should not promote the names at all
[08:53] <didrocks> "14.04 - #otherbuildid"
[08:53] <asac> ogra_: i think thats a long term discussionm to have and yes 13.10 might be a better name to use than saucy
[08:53] <ogra_> asac, no
[08:53] <ogra_> decouple from ubuntu releases ... focus on our channels only
[08:53] <didrocks> well, there are 2 things I guess:
[08:54] <asac> anyway, lets wait for stgraber. i am sure he has thoughts that we should take as a starting point
[08:54] <ogra_> nobody should need to cate if stable is saucy or T
[08:54] <ogra_> of if devel is T or  U
[08:54] <didrocks> - some people/manufacturers will always want the latest and best, so they will be on "stable - #100"
[08:54] <ogra_> right
[08:54] <didrocks> - some manufacturers want their customers staying on 13.10, so we can show "13.10 - #100"
[08:54] <didrocks> maybe it's the same image
[08:54] <didrocks> maybe stable points to 14.04
[08:54] <didrocks> so not the same image
[08:54] <ogra_> oh, and on a sidenote ...
[08:55] <ogra_> HAPPY BIRTHDAY lool !!!!!!!!!!!
[08:55] <didrocks> ogra_: quite laggy, he has already showed up (and left) :)
[08:55] <asac> lool: !!! /me singing !!!
[08:55] <ogra_> he has a backlog :)
[08:55] <didrocks> yeah, crazy people with bip…
[08:55] <ogra_> :)
[08:56] <asac> didrocks: bip is a good thing
[08:56] <ogra_> yep
[08:56] <asac> with bip you can deprioritize emails a bit, which helps sanity a lot :)
[08:56] <didrocks> asac: it's not, I'm sure I lost life hope time due to it :)
[08:56] <didrocks> so if it's important, people can email
[08:57] <didrocks> harder than just pinging
[08:57] <asac> right
[08:57] <didrocks> or getting 100 "didrocks: ping" when you are back
[08:57] <didrocks> without any context
[08:57] <asac> i take a slightly different perspective that i am happy to discuss over a beer :)
[08:57] <asac> lol
[08:57] <didrocks> heh ;)
[08:57]  * didrocks feels now so good without bip :p
[08:57] <didrocks> (I guess it's still configured on my server, just not running)
[08:58] <ogra_> well, it takes me 20min in the morning to read my backlog ... and udually i catch the important bits there so i can just quickly skim through mail
[08:58] <didrocks> ogra_: yeah, but mentally you are "connected"
[08:58] <ogra_> no
[08:58] <didrocks> even if you are at a restaurant, dining
[08:58] <didrocks> dinning*
[08:58] <ogra_> my bip does that for me ;)
[08:58] <didrocks> ok, I feel that way, can't be disconnected mentally
[08:58] <asac> right. i am super relaxed if i am not working
[08:58] <didrocks> knowing people are pinging me
[08:59] <ogra_> i dont have to be mentally connected cince it collects the stuff to present it to me when i feel ready
[08:59] <asac> because of bip
[08:59] <asac> didrocks: so you have ping nightmares ... or rather daydreams, just because you know there is a bip running.
[08:59] <asac> wow :)
[09:00] <didrocks> asac: exactly!
[09:00] <didrocks> waow, my insanity is discovered :p
[09:00] <asac> i guess you really shouldnt have bip running then
[09:00] <asac> :)
[09:00] <didrocks> I know, that's why I don't anymore :)
[09:00] <ogra_> i personally feel it speeds me up ... i only have to read ~100 of the 400 mails i usually get over night
[09:00] <ogra_> in pre-bip times that was easily double
[09:01] <asac> didrocks: maybe the curation lies in exactly doing the opposite: enabling bip and learning not to care :)
[09:01] <didrocks> asac: I was using screen + irssi for some years, and then bip for an additional one. It really didn't help
[09:01]  * didrocks digs up http://blog.didrocks.fr/post/Moving-away-from-(screen-irssi)-to-(bip-weechat)
[09:45] <didrocks> asac: hum, seb was asking about indicator fixes for touch only (robru had the request yesterday)
[09:46]  * didrocks thinks we're blurring the message…
[09:46] <didrocks> I don't want us to spend time testing and landing the SRU
[09:46] <asac> didrocks: well, i explicitely kept the answer generic. yes, the decision whether you do a SRU upload is still the same from before
[09:47] <asac> didrocks: i even say that if he has concrete cases we have to talk
[09:47] <didrocks> asac: well, if you're telling that, robru will be pushed to land this fix
[09:47] <asac> didrocks: i hope not
[09:47] <didrocks> it was the case yesterday
[09:47] <didrocks> and it seems you're contradicting my email which tried to make a clear line :/
[09:47] <asac> didrocks: to be honest imo there was not enough info to assume that i am answering or approving a concrete case
[09:47] <didrocks> we'll see
[09:47] <asac> didrocks: i am not contradicting
[09:48] <didrocks> the fix is http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.14.04/revision/393
[09:48] <didrocks> FYI
[09:48] <asac> i am saying that SRUs are done like before... (just that they shouldnt bother for touch)
[09:48] <asac> didrocks: is robru on ue-leads?
[09:48] <didrocks> you didn't tell that they shouldn't both for touch
[09:48] <didrocks> asac: no, he's not
[09:48] <didrocks> that's why I gave him the same details this morning
[09:49] <didrocks> about the SRU policy for touch and what to do for others
[09:50] <didrocks> bother*
[10:23] <asac> didrocks: so for now all we are and should be doing is handing out an internal guideline and inform people about the relative priorities. this should be more than enough to convince people to not put too much effort into SRUing for touch on saucy - which is the goal here.
[10:24] <didrocks> asac: I agree, that's what I tried to do with that email :)
[10:24] <asac> and luckily in CI landing team we have a chance to talk to them 1-on-1
[10:24]  * didrocks -> lunch
[10:24] <asac> with them and convince them that it might be unwise
[10:24] <asac> hehe
[10:24] <asac> didrocks: enjoy
[10:24] <didrocks> thanks!
[10:25] <ogra_> asac, well, depends, while i'm completely in the "forbid all SRUs, concentrate on making the first T image rock" camp ... without T opening in time thats a moot thing :(
[10:26] <apw> use a ppa ?
[10:27] <ogra_> apw, against what release ?
[10:28] <ogra_> apw, the point is we want to roll on top if the archive with our stuff
[10:28] <apw> against S, doesn't matter, you make it in there, and when T finally appears you copy the lot out to there
[10:28] <ogra_> apw, if the archive doesnt open ofr a week we fall behind .. no PPA will help uploading to T if T doesnt exist
[10:28] <apw> you make a new PPA called "what we want in T" and you upload to that as if it was T, but in the S pocket
[10:29] <apw> and use it as the archive
[10:29] <ogra_> apw, we have -updates and the possibility to do SRUs. but thats exactly the opposite of what we need to do
[10:29] <apw> not suggesting sru's, i am suggesting a PPA which you treat as T, just use S as the upload name
[10:29] <apw> that is functionally equivalent to a T pocket no ?
[10:30] <ogra_> right, we dont want PPAs in official images anymore and -updayes provides tecnically what we need
[10:30] <ogra_> it might be functionally equivalent but wont give us the bugs the  new archive will
[10:30] <ogra_> we would still have to fix them once our underlying stuff changes
[10:31] <apw> except it is protected by the sru team and a PPA isn't
[10:31] <infinity> That's no excuse to stop development.
[10:31] <infinity> Not having it in an image doesn't mean you can't do all the programming, building, and testing up to that point.
[10:32] <infinity> Anyhow, if you want to complain about the lack of T, I recommend phoning Mark.
[10:32] <infinity> Repeatedly.
[10:32] <ogra_> heh
[10:32] <ogra_> i assume someone does that already
[10:32] <cjwatson> yes
[10:32] <ogra_> (s/assume/hope/
[10:32] <ogra_> )
[10:33] <cjwatson> first thing I did this morning was escalate to silbs
[10:39] <asac> ogra_: upstream merger continues working, so there is at least no complete blockage
[10:39] <asac> landings are stalled, which is unfortunate, but i dont anticipate this to delay much longer (for nwo :))
[10:39] <asac> otherwise we can revisit other mitigation options on monday
[11:05] <didrocks> right, there is still option of daily-build-next -> next
[11:05] <didrocks> which is exactly how we handled daily releases for raring -> saucy transition, and what apw suggested in fact (but already exist and already supported ;))
[11:05] <didrocks> then switching from the ppa to T is a 2 line diff
[11:17] <nik90> @ci, can anyone push the latest trunk build https://code.launchpad.net/~phablet-team/qtubuntu-sensors/trunk to the phone? It will provide haptic feedback for buttons :)
[11:18] <nik90> rev 38
[11:24] <didrocks> nik90: hey, last time we tried it, it wasn't working
[11:24] <didrocks> nik90: see line 185 on the landing ask
[11:24] <didrocks> so we are waiting on kalikiana's feedback
[11:25] <didrocks> nik90: and now, we're waiting for T to open to push those kind of fixes (people will be transitionned to it)
[11:25] <didrocks> but I think first, we need the confirmation it really works :)
[11:28] <nik90> didrocks: ah okay
[11:28] <nik90> didrocks: where I can the landing ask?
[11:29] <didrocks> nik90: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 should be what you need
[11:30] <nik90> thnx
[11:30] <didrocks> yw, keep us posted! ;)
[11:31] <t1mp> nik90: haptic feedback for buttons? that's sounds very awesome
[11:32] <nik90> t1mp: I know :)...hopefully kalikiana can chime in to this discussion when available
[12:01] <kalikiana> nik90: t1mp hmm what's being asked from me exactly?
[12:04] <didrocks> kalikiana: look at the landing ask you filed, there are some comments on landing qtubuntu-sensors (mirv tested it, and it didn't work)
[12:07] <kalikiana> okay, I'll give it another test run; we were testing it in a devel image in parallel and I was running into several unrelated problems - I didn't know it didn't work for mirv at all
[12:09] <didrocks> kalikiana: he'll be back on Monday. If it's working for you, maybe you can check with him?
[12:10] <kalikiana> I "used to" work, the problem is that a ton of "noise" makes it hard to make a statement on the latest image
[12:10] <kalikiana> *It
[12:10] <kalikiana> so I'm trying on the proposed image now
[13:00] <kalikiana> hm "can't open /cache/recovery/ubuntu_command" after 2 attempts
[13:00] <lool> asac, ogra_: Thanks!
[13:00] <ogra_> :)
[13:00] <kalikiana> is it worth rebooting and trying again or should I file a bug?
[13:01] <ogra_> kalikiana, both !
[13:01] <ogra_> :)
[13:01] <kalikiana> :-D
[13:01] <ogra_> the proposed and the devel image are indentical btw
[13:07] <kalikiana> ogra_: https://bugs.launchpad.net/phablet-tools/+bug/1241568
[13:08] <ogra_> kalikiana, thanks
[13:26] <fginther> sil2100, you around?
[13:30] <sil2100> fginther: yes!
[13:30] <sil2100> Just finished lunch
[13:31] <fginther> sil2100, I left you a pm
[13:31] <sil2100> fginther: yes, I see it - commenting! Thanks
[14:03] <ogra_> asac, we have a name !!!
[14:06] <cjwatson> Already working on it, though I need to leave in <3 hours
[14:08] <asac> we have?
[14:08] <asac> :)
[14:09] <ogra_> the trusty tahr
[14:13] <asac> nice
[14:16] <nik90> I have come to know of these animals only after the announcement of the code names :)
[14:20] <ogra_> thats the plan behind these names ;)
[14:20] <ogra_> finding an animal plus an adjective thats unique on google as a combo
[14:20] <ogra_> that way you will always find ubuntu using these two
[14:34] <asac> cjwatson: how will we coordinate doing the first image after the toolchain? i assume thats something to look at monday?
[14:35] <ogra_> asac, the default in cdimage will change at the toplevel
[14:35] <asac> (i suggest we dont really stress this... we have a name, and the day delay we got is fine imo)
[14:35] <ogra_> the rest is bugfixing uninstallable packages
[14:35] <ogra_> (if we even need that)
[14:35] <asac> ogra_: and we get stgraber do magic to the system-image job
[14:35] <asac> so it does the right thing
[14:36] <asac> still, we need to coordinate when the toolchain is done
[14:36] <ogra_> right, not sure whats needed on stgrabers side
[14:36] <asac> so we can do one image etc.
[14:36] <asac> doanac: there?
[14:36] <asac> doanac: what do we need to do if we want touch_mir to point to trusty?
[14:36] <ogra_> i think though that we could try building the first image by next friday
[14:36] <asac> doanac: and keep another one rolling that tests saucy-proposed channel?
[14:36] <asac> (replacing touch_ro)
[14:37] <cjwatson> asac: I don't have time to coordinate it today, but I'd hoped to get the auto-sync running over the weekend so that it can be mostly built by the time people care
[14:37] <cjwatson> I don't know if I'll have time for that
[14:37] <asac> cjwatson: hmm. so no clean first image?
[14:38] <ogra_> ??
[14:38] <ogra_> asac, did you expect an image today ?
[14:38] <asac> ogra_: plan was to land toolchain, then kick an image and then start with the normal archive stuff like autosync etc.
[14:38] <asac> yes
[14:38] <asac> right after landing the toolchain
[14:38] <ogra_> ah
[14:38] <asac> before auto-imports and what not
[14:39] <ogra_> well, moday or tuesday will do i guess
[14:39] <doanac> asac: its basically a config change for us
[14:39] <doanac> should be fairly simple
[14:39] <asac> ogra_: right, but i feel cjwatson wants to turn the auto syncs etc. on before the weekend
[14:39] <asac> err
[14:39] <asac> during weekend
[14:39] <asac> so there wont be such an image with those properties
[14:39] <asac> doanac: can you already do that?
[14:39] <ogra_> asac, why is that impirtant ? it would be identical to #100
[14:40] <doanac> asac: yes. i'll get with josepht and plars to get it ready
[14:40] <asac> ogra_: new toolchain, good first image to start the release cycle
[14:40] <ogra_> just with a different name stamped in
[14:40] <asac> various reasons, also social reasons
[14:40] <asac> ogra_: right. it ensurees we can rerun images from our new release on our new infrastructure
[14:40] <asac> before the rough weather arrives
[14:40] <ogra_> i would wait until the first import chunk landed
[14:40] <asac> pipecleaning after the switch over basically
[14:40] <ogra_> there wont be rough weather
[14:40] <asac> well, was discussed before
[14:41] <ogra_> there wasnt in saucy, there wont be in T
[14:41] <asac> just asked cjwatson if he plans changing plans now that the name is late
[14:41] <asac> ogra_: not everyone believes your guts :)
[14:41]  * ogra_ trusts our infrastructure
[14:41] <asac> haha
[14:41] <ogra_> in that area it has matured 9 years
[14:42] <ogra_> saucy was completely flawless in that regard and i expect the same for trusty
[14:42] <asac> its simple. you start a new cycle, you produce a first new image that is the same, has the new tooclhain and gives you confidence that everything is good aka green :)
[14:42] <asac> not sure why we should miss something that cheap to do
[14:42] <ogra_> we never did that
[14:42] <asac> it doesnt require more than pushing the build image button once the toolchain is in
[14:42] <asac> doesnt mean we shouldnt do it :)
[14:42] <ogra_> after all a new toolchain wont give you anything
[14:43] <asac> after all we want to move all UE over to T from day 1
[14:43] <ogra_> your binaries havent been rebuilt
[14:43] <asac> we didnt do that either in last cycles
[14:43] <ogra_> and we dont ship the toolchain
[14:43] <asac> its not about that
[14:43] <asac> its about the rest :)
[14:43] <ogra_> (well, we ship gdb)
[14:43] <asac> anyway. lets wait for cjwatson
[14:43] <ogra_> what rest ?
[14:43] <ogra_> all binaries will be identical to image 100
[14:43] <ogra_> so you can as well take 100 as the reference
[14:43] <cjwatson> asac: If we have time for a clean first image I'd like to do that
[14:44] <asac> cjwatson: from touch, UE perspective we have the time
[14:44] <asac> we can totally live with a delay of 1 day
[14:44] <cjwatson> asac: But it will probably involve you promising not to complain about auto-syncs running during the week
[14:44] <cjwatson> (the initial bulk, that is)
[14:44] <asac> cjwatson: did i say that i would complain? :)
[14:44] <cjwatson> I'm just being cautious :)
[14:44] <asac> i thought we just keep a very close eye on it and do things if stuff regresses
[14:44] <ogra_> matter of experience ? :)
[14:44] <asac> etc.
[14:44] <cjwatson> The builders will be slower than usual, there'll probably be some build failures as things settle down
[14:44] <cjwatson> I need people not to be panicking about that
[14:45] <asac> cjwatson: i anticipated that we experiment how things go... probably starting with "auto syncs" for a bit and then see
[14:45] <cjwatson> It should be fine once the initial batch lands
[14:45] <cjwatson> ogra_: You ship libgcc
[14:45] <asac> cjwatson: right. but from what i understand things that fail to build will be stuck in proposed and all things that depend on it with it.
[14:45] <cjwatson> That's about it though
[14:45] <ogra_> cjwatson, yeah
[14:45] <cjwatson> asac: Yeah, but builds run against proposed, necessarily
[14:45] <asac> cjwatson: so those we will have a chance to take a look at etc.
[14:45] <cjwatson> asac: So some builds will normally fail
[14:45] <asac> ah ... sure
[14:46] <asac> we will see... we should just keep a bit of a forecast so we know whats coming
[14:46] <asac> etc.
[14:47] <cjwatson> we're doing gcc 4.8, boost 1.54, db 5.3, perl 5.18 in the toolchain bootstrap
[14:47] <cjwatson> https://launchpad.net/~ubuntu-toolchain-r/+archive/test/+packages?field.name_filter=&field.status_filter=published&field.series_filter=saucy
[14:47] <plars> asac: doanac and I were just discussing... do we need to keep saucy jobs? or just transition completely to trusty for touch?
[14:48] <ogra_> plars, we'll need both as long as we do saucy images
[14:48] <ogra_> to see if they regressed
[14:48] <kalikiana> I'm seeing this in an otherwise passing mr:
[14:48] <asac> plars: we want to keep saucy jobs i believe
[14:49] <asac> plars: whether we daily prodyuce new saucy-proposed images or just on demand is not yet clear, but in general i feel we should make touch_ro --channel saucy-proposed tests
[14:49] <kalikiana>  /usr/lib/pbuilder/pbuilder-modules: line 424: 17749 Segmentation fault tar -x --use-compress-program "$COMPRESSPROG" -p -f "$BASETGZ" E: failed to extract /var/cache/pbuilder/saucy-armhf.tgz to /var/cache/pbuilder/build//17710 ERROR:pbuilderjenkins:Error during build execution
[14:49] <asac> and make touch_mir == touch with devel-propopsed
[14:49] <plars> asac, ogra_, doanac: ok, that was my next question, how frequent would they be :)
[14:49]  * ogra_ would only do on demand
[14:50] <plars> asac, doanac: in that case, would we be safe to disable what was formerly called "touch_ro" jobs and just focus on the default mir installs?
[14:51] <asac> plars: doanac: i was suggesting: rename touch_ro to touch_saucy (--channel saucy-proposed)
[14:52] <asac> and rename touch_mir to touch (--channel devel-proposed)
[14:52] <doanac> i think touch_saucy is redundant. we already include the series name
[14:52] <doanac> but otherwise i agree
[14:52] <plars> asac: well, I think we are saying the same thing - it's not so much a rename, because we want the saucy jobs to be running mir (and the trusty ones) right?
[14:52] <plars> asac: right now, the touch_ro jobs are really the sf jobs, as they always were until mir came in
[14:53] <rsalveti> is someone going to work on supporting mir for nexus 7 or 10?
[14:53] <rsalveti> otherwise it'd still be good to let the tests running against SF
[14:53] <josepht> we'll need to coordinate variant name changes for the dashboard (i.e. touch_mir -> touch)
[14:53] <rsalveti> even if we don't officially support it
[14:54] <rsalveti> in theory we need to care about tablets this cycle as well
[14:54] <asac> rsalveti: first we have to fix galaxy nexus performance
[14:54] <rsalveti> at least more than we did for saucy
[14:54] <asac> rsalveti: then i would vouch for tackling n10 or so
[14:54] <asac> or both
[14:54] <asac> if we still want to do tablets :)
[14:54] <asac> (which i am sure we do)
[14:54] <asac> rsalveti: but first we need emulator
[14:54] <rsalveti> right, so don't disable the smoke tests on SF then
[14:54] <asac> nothing will move on new devices before we have that
[14:55] <plars> rsalveti: we're not running anything on the tablets right now
[14:55] <rsalveti> and I'm sure when people decide to bootstrap touch to new hardwares, they will try SF first
[14:55] <plars> rsalveti: but they are available for as soon as people are going to care for those
[14:55] <rsalveti> plars: right, but we at least know our stack is supposed to work with SF
[14:56] <asac> rsalveti: SF is kind of dead... if community shows up and want to port features that we only have in MIR to it, it might come back as a community thing - but i doubt it actually
[14:56] <rsalveti> all I'm saying is that it'd be good to have the results for that, so we know how broken it is
[14:56] <rsalveti> asac: I'm not just concerned with that, I mean when our oem decide to bootstrap to a new hardware
[14:56] <rsalveti> they will always test with SF first
[14:56] <rsalveti> as mir might be completely broken until someone ports to it
[14:56] <ogra_> asac, we need to make sure SF still works as long as we tell the community to do ports
[14:57] <rsalveti> not only that, but that's a big +1 to keep it around for a bit more yeah
[14:57] <rsalveti> we'll stop supporting it completely soon, but let's not do this now
[14:57] <rsalveti> while we have mir only working nicely at one device
[14:58] <ogra_> yes, we should keep SF for at least one more release cycle
[14:58] <asac> rsalveti: is MIR really so hard to prot?
[14:58] <asac> rsalveti: given that we support android drivers it shouldn't be so hard for OEMs to get that going, no?
[14:58] <rsalveti> asac: it's not trivial, no
[14:58] <asac> really?
[14:58] <ogra_> asac, for the kind of porters we have it is a hard task ... not everyone is a graphics driver specialist
[14:59] <asac> i know that its not easy for porters
[14:59] <asac> just asking about real oems
[14:59] <rsalveti> yeah, even we can't fix and port to the stuff we support
[14:59] <asac> or rather SoC folks
[14:59] <asac> or MALI folks from arm... they can surely do that easily if they want, no?
[14:59]  * ogra_ doesnt care about SoC folks
[14:59] <rsalveti> probably, but yeah, we only care about oem and community ports at this point
[14:59]  * ogra_ does care about such projects like the fairphone
[14:59] <asac> rsalveti: lol... well, our part is a bit harder because its the FIRST and SECOND platform we are dealing with
[14:59] <ogra_> who will give us a big boost with their ports
[15:00] <asac> once we have those done well, we are surely far more efficient and the code is far better suitable for enablement
[15:00] <ogra_> ebnthusiats buy these
[15:00] <rsalveti> asac: right, that's exactly why we shouldn't disable SF now :-)
[15:00] <ogra_> ++
[15:00] <ogra_> it is the saem as with the cdimage zips ...
[15:00] <rsalveti> and I don't mean fully supporting SF, I just want smoke tests running against it so we know how broken it is
[15:01] <rsalveti> and know what to expect
[15:01] <ogra_> we dont really support them but keep them available until ports can do the full thing
[15:01] <rsalveti> yeah, and it's also always useful when bootstraping to a new hardware
[15:01] <ogra_> right
[15:01] <rsalveti> doing the entire system image as a first try is just too much
[15:01] <ogra_> yep
[15:01] <rsalveti> now put system image + mir just to bootstrap it
[15:01] <ogra_> and to limited for actually fixing the initial issues you will hit
[15:02] <rsalveti> yeah
[15:02] <asac> rsalveti: you mean disable the dashboatrd runs?
[15:02] <asac> i am fine with keeping dashboard running with minimal amount of jobs
[15:02] <asac> but not everything
[15:02] <asac> more like what we hav for _custom
[15:02] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_custom/
[15:02] <rsalveti> asac: just for the core stuff
[15:03] <asac> right. we can do that i think fora bit if you find it useful
[15:03] <asac> have to check if we run out of resources though :)
[15:03] <rsalveti> yes, please
[15:03] <asac> doanac: plars: so minor change in plan :)
[15:04] <asac> doanac: we want to rename touch_ro to touch_sf4p and run the same jobs against the SF variant of devel-proposed there
[15:04] <asac> doanac: and create a new touch_saucy instead (with the content from above
[15:04] <asac> plars: ^^
[15:04] <asac> rsalveti: ok, so but you own it now perswonally
[15:04] <doanac> asac: touch_saucy doesn't make sense.
[15:04] <asac> rsalveti: e.g. its your obligationm to ensure taht if there are jobs failing that they are getting brought to our attention
[15:04] <josepht> doanac: +1
[15:05] <asac> doanac: it does
[15:05] <doanac> why not just "touch" and "touch_sf4p"
[15:05] <ogra_> doanac, because we still want saucy tests too
[15:05] <rsalveti> asac: sure
[15:05] <doanac> asac: we already include the release name as its own column
[15:05] <doanac> you'll be able to differentiate
[15:05] <asac> doanac: we have touch (devel-propsed), touch_saucy (saucy-propsed), touch_custom (devel-custom), touch_sf4p (mimimal job for devel-proposed with SF)
[15:05] <asac> doanac: well, then tell me how you want to name it :)
[15:06] <asac> doanac: its not good to name two with the same name
[15:06] <kgunn> didrocks: ping
[15:06] <doanac> asac: let me talk with josepht and plars
[15:06] <plars> doanac, asac: well, if it's sf then touch_sf would probably be ok
[15:06] <asac> rsalveti: at best find someone through G+ or so that wants to own that build and work with CI etc. to escalate, look at test regressions
[15:06] <plars> not sure what sf4p even means
[15:07] <asac> plars: doanac: see the lisst above
[15:07] <asac> plars: please use sf4p (its SF)
[15:07] <asac> its a political name :)
[15:07] <asac> (for my personal safety)
[15:07] <ogra_> 4p ?
[15:07] <asac> for porters
[15:07] <ogra_> ah
[15:07] <rsalveti> asac: we're fine to own that for a while
[15:08] <asac> rsalveti: priority must stand back behind many things. better really find someone outside mid term
[15:08] <asac> for now its probably okaish
[15:08] <asac> as long as someone owns it that isnt official :)
[15:09] <rsalveti> asac: it's a low priority, don't worry
[15:10] <didrocks> kgunn: pong
[15:14] <kgunn> didrocks: hey so duflu did some changes to our branches
[15:14] <kgunn> didrocks: hopefully under your guidance
[15:14] <didrocks> kgunn: yeah, he did ping me this morning
[15:15] <kgunn> didrocks: he seemed to move our lp:mir to point to saucy
[15:15] <didrocks> kgunn: I told him it's useless as we discussed, but if he wants to have a "saucy" series…
[15:15] <kgunn> didrocks: yeah...but we can't find "trunk"
[15:15] <didrocks> kgunn: just that we won't SRU the saucy branch
[15:15] <didrocks> lp:mir is what we are going to release for T
[15:15] <didrocks> it's my only requirement
[15:16] <kgunn> didrocks: hmmm....well...that's not what he did
[15:16] <didrocks> then, if duflu wants to support something ubuntu doesn't… not my word apparently :)
[15:16] <didrocks> kgunn: hum? he told me that the saucy serie was for saucy, that it wasn't lp:mir
[15:16] <didrocks> kgunn: lp:mir is https://code.launchpad.net/~mir-team/mir/development-branch?
[15:16] <didrocks> that changed
[15:17] <didrocks> kgunn: will https://code.launchpad.net/~mir-team/mir/development-branch always have ABI compatilibity or bumped assured?
[15:17] <kgunn> didrocks: ok...so you don't carer if its pointing to "trunk"
[15:17] <didrocks> kgunn: I just care about lp:mir
[15:17] <kgunn> didrocks: yes...he seemed to unilaterally decide to do all this w/o talking to anyone :-\
[15:17] <didrocks> lp:mir should ensure ABI compatilibity (or bump the ABI properly in the packaging)
[15:17] <didrocks> should always pass tests
[15:17] <didrocks> and be always shippable
[15:17] <didrocks> that's the rule for all projects
[15:17] <kgunn> didrocks: ack...so right now he's put us at risk
[15:17] <didrocks> I expect you are following that too :)
[15:18] <didrocks> kgunn: exactly, it's probably already built in the ppa as well
[15:18] <kgunn> didrocks: of course...
[15:18] <didrocks> kgunn: can you undo that then?
[15:18] <kgunn> didrocks: damn it...i'll work with the guys to correct....is there anything you can do on your side to stem the flow from development branch
[15:19] <didrocks> kgunn: well, the ppa won't be of use before Monday, so it's fine, if you fix it today, the new rebuild should be good
[15:20] <kgunn> didrocks: ack...
[15:20]  * kgunn screams inside
[15:22] <didrocks> kgunn: everything will be fine, no harm done yet ;)
[15:37] <didrocks> ok, time for exercise and week-end then!
[15:37]  * didrocks waves good evening :)
[15:38] <seb128> didrocks, have a good w.e
[15:39] <didrocks> thanks, you too seb128, have fun in Canada!
[15:39] <seb128> didrocks, thanks
[15:39] <ogra_> blame it !
[15:39] <ogra_> :)
[15:43] <kalikiana> jdstrand: ping, do I ask you about permissions of /sys/class/timed_output/vibrator/enable on the device?
[15:44] <kalikiana> seems like it changed from allowed to root-only at some point which basically breaks my code
[16:30] <cjwatson> I broke trusty with a typo when copying the toolchain in.  wgrant, infinity, and I are working on cleaning up; unfortunately I have to go
[16:31] <cjwatson> So I can't promise when you get to build post-toolchain images
[16:31] <cjwatson> Hopefully today if you have time and if livefs chroots have been created
[17:07] <jdstrand> kalikiana: we've never allowed that permissions, but certainly can. can you file a bug against apparmor-easyprof-ubuntu and mention if this should be allowed for all apps or if not, what types of apps?
[17:09] <kalikiana> okay, will do.
[17:29] <kalikiana> jdstrand: https://bugs.launchpad.net/ubuntu/+source/apparmor-easyprof-ubuntu/+bug/1241735
[17:37] <jdstrand> kalikiana: thanks
[20:20] <ogra_> asac, FYI i just did an image testbuild for tasty, it wont build unless we rebuild android (since the android package uses the release name inside the img filenames) so plain toolchain build wont be possibile


[02:10] <imgbot> [03:10] <imgbot> [03:25] <imgbot> [03:25] <imgbot> [04:15] <imgbot> [04:15] <imgbot> [19:16] <bzoltan> trainguards: may i ask for a reconf of the vivid silo1? I just added the -gles branch to the request.
[19:18] <robru> bzoltan: there's gotta be a better way to handle this gles stuff...
[19:20] <robru> bzoltan: ok reconfigured. gotta run though, bbl!
[20:12] <bzoltan> robru:  super thanks