[02:36] <anastasiamac> menn0: just as a test, can u now see 'CAAS' on the board?
[02:36] <menn0> anastasiamac: I can. thanks!
[02:37] <anastasiamac> menn0: ack. i'll see if i can add joel
[02:37] <anastasiamac> menn0: does he need the ability to move cards or just to view them?
[02:37] <menn0> anastasiamac: thumper just explained to me how to do it :)
[02:37] <anastasiamac> menn0: thumper: awesome!
[02:38] <menn0> anastasiamac: it would be great if joel could move/add/update cards
[02:39] <anastasiamac> menn0: k. does it mean u want me to add him or r u in control now?
[02:50] <menn0> anastasiamac: sorry, otp. thumper is adding him now (he doesn't have an acccount)
[03:04] <thumper> I've just added joel to leankit
[03:04] <thumper> and emailed him
[03:19]  * thumper afk to collect kids
[04:24] <babbageclunk> wallyworld: can you take a look at this please? https://github.com/juju/juju/pull/7340
[04:25] <babbageclunk> wallyworld: oh, also - I just noticed this while I was scrolling through it: https://github.com/juju/juju/pull/7340/files#diff-bad794df7c6f66424c0b9cc0961da6ccR896
[04:27] <babbageclunk> wallyworld: That seems wrong to me - it's saying you don't need write permission to the model to add a relation if the other end is a remote application.
[05:11] <wallyworld> babbageclunk: looking now
[05:12] <babbageclunk> wallyworld: cool thanks - no rush, I'm looking at the maas thing atm
[05:32] <menn0> jam: sorry :)
[05:33] <jam> https://hangouts.google.com/hangouts/_/canonical.com/john-menno?authuser=1 ?
[05:33] <jam> I wasn't sure if you intended to stay in the same channel or switch
[09:39] <thumper> night all
[10:13] <wpk> call at 7am: https://www.youtube.com/watch?v=vidNWtQeREw
[23:12] <mup> Bug #1688177 changed: juju show-action-status needs more details <canonical-bootstack> <juju:Triaged> <https://launchpad.net/bugs/1688177>
[23:15] <mup> Bug #1688177 opened: juju show-action-status needs more details <canonical-bootstack> <juju:Triaged> <https://launchpad.net/bugs/1688177>
[23:18] <mup> Bug #1688177 changed: juju show-action-status needs more details <canonical-bootstack> <juju:Triaged> <https://launchpad.net/bugs/1688177>
[23:42] <mup> Bug #1662857 changed: cannot go get the source code  <juju:Triaged by menno.smits> <https://launchpad.net/bugs/1662857>


[00:00] <bodhi_zazen> Are we ready to start ?
[00:00]  * Snova is here
[00:00] <bodhi_zazen> weee hooo
[00:00]  * tim_sharitt is ready
[00:00] <bodhi_zazen> first, sorry about the confusion re time and date
[00:01] <bodhi_zazen> again, I will do these Q&A sessions every 2 weeks or so
[00:01] <bodhi_zazen> I was asked to cover permissions today and to make it interesting will add in sticky bits and acl :)
[00:01]  * RachedTN is ready too :)
[00:02] <bodhi_zazen> This is a good time to mention the shared ssh session
[00:02] <bodhi_zazen> http://paste.ubuntu.com/147955/
[00:02] <bodhi_zazen> we can use that for a hands on demo
[00:02] <bodhi_zazen> but if you are interested , please ssh in when you get a chance
[00:02] <bodhi_zazen> so you are ready to go when we start
[00:02]  * Geek`N`Proud thought he'd stick around
[00:02] <Pretto> 404
[00:02] <bodhi_zazen> if you need help, ask and someone will answer in a PM
[00:02] <Daisuke-Ido> The requested URL /beginners/ufbt-guest was not found on this server.
[00:03] <bodhi_zazen> http://paste.ubuntu.com/147955/
[00:03] <WastePotato> Am I late?
[00:03] <Snova> No.
[00:03] <WastePotato> Ok.
[00:03] <bodhi_zazen> Ah, my mistake, lol
[00:03] <bodhi_zazen> http://bodhizazen.net/ufbt/ufbt-guest
[00:03]  * bodhi_zazen bad
[00:04] <WastePotato> Yay. SSHing into bodhi_zazen's computer. \o/
[00:04] <bodhi_zazen> sweet :)
[00:04] <Snova> Or as close to it as you'll ever get...
[00:04] <bodhi_zazen> OK, lets start with the basics
[00:04] <bodhi_zazen> permissions often frustrate new users
[00:05] <bodhi_zazen> and it is a BIG change if you come from Windows
[00:05] <Daisuke-Ido> i'm going to pop back over to gnome
[00:05] <bodhi_zazen> Every file and directory has an owner (the one who made it), a group, and "other"
[00:05] <bodhi_zazen> permission are rwx - read, write, and execute
[00:05] <bodhi_zazen> and so are listed with ls -l
[00:05] <bodhi_zazen> as 3 sets :
[00:06] <bodhi_zazen> rwxrwxrwx
[00:06] <bodhi_zazen> for owner:group:other
[00:06] <bodhi_zazen> a - means you do not have the permission
[00:06] <bodhi_zazen> so r--r--r-- is read only
[00:07] <bodhi_zazen> You can also see permissions graphically by right clicking a file
[00:07] <bodhi_zazen> and selecting the permissions tab
[00:07] <bodhi_zazen> To change permissions from the command line you can use "octals"
[00:07] <bodhi_zazen> which are listed here : http://www.zzee.com/solutions/linux-permissions.shtml
[00:08] <bodhi_zazen> or if you can not use the octals, use +rwx
[00:08] <bodhi_zazen> so, with the chmod command
[00:08] <bodhi_zazen> chmod o+rwx foo
[00:08] <bodhi_zazen> chmod g+r foo
[00:08] <bodhi_zazen> chomd 755 foo
[00:09] <bodhi_zazen> you change the group with chown or chgrp
[00:09] <bodhi_zazen> chown owner:group foo
[00:09] <bodhi_zazen> chown owner.group foo
[00:09] <bodhi_zazen> period works as well as a : , although it id depreciated >:)
[00:09] <bodhi_zazen> With the gui tools use the pull down menu
[00:10] <bodhi_zazen> The thing that is odd, directories
[00:10] <bodhi_zazen> you need to set the x to list the contents of a directory
[00:10] <bodhi_zazen> chmod a+x bar
[00:10] <bodhi_zazen> allows people to ls bar
[00:10] <bodhi_zazen> again see http://www.zzee.com/solutions/linux-permissions.shtml
[00:11] <bodhi_zazen> Questions about basic permissions ?
[00:11] <bodhi_zazen> otherwise I am going to move on to sticky bits >:)
[00:12] <bodhi_zazen> Sticky bits are not hard to understand, but they are odd
[00:12] <bodhi_zazen> They are also called SUID and SGID
[00:12] <bodhi_zazen> if you have an executable file or binary
[00:13] <bodhi_zazen> and you suid it, it runs with the permissions of the OWNER of the file, not the user who runs the script / binary
[00:13] <bodhi_zazen> so ...
[00:13] <bodhi_zazen> if the file is owned by root
[00:13] <bodhi_zazen> and you then chmod 755
[00:13] <bodhi_zazen> anyone can run the file
[00:14] <bodhi_zazen> if you run the script as a use, the process has permissions of the user who called it
[00:14] <bodhi_zazen> If, however, you chmod u+s foo
[00:14] <bodhi_zazen> now anyone can run the script and , as it is owned by root, it runs as if root called the script
[00:15] <bodhi_zazen> no password is required
[00:15] <bodhi_zazen> do no do this
[00:15] <bodhi_zazen> any script to be run by root should be owned by root and, IMO, called with sudo
[00:15] <bodhi_zazen> same thing applies to SGID
[00:15] <bodhi_zazen> if the SGID bit is set, the script runs with permissions of the group that owns the file
[00:16] <bodhi_zazen> with me so far ?
[00:16] <bodhi_zazen> One last bit, +t
[00:16] <bodhi_zazen> +t is the "sticky bit"
[00:16] <Spreadsheet> Can I talk?
[00:16] <bodhi_zazen> in the past it meant keep the script in memory
[00:16] <bodhi_zazen> Spreadsheet: yes
[00:16] <bodhi_zazen> anyone can break in at any time
[00:17] <Spreadsheet> Ok, I have a question
[00:17] <bodhi_zazen> this is an open session
[00:17] <bodhi_zazen> please :)
[00:17] <Spreadsheet> This is sorta related to the topic
[00:17] <Spreadsheet> Sometimes i use chown, and it doesn't work
[00:17] <Spreadsheet> Then i use it a couple more times and it does work...
[00:17] <Spreadsheet> Is this a bug?
[00:17] <pleia2> :)
[00:17] <bodhi_zazen> You can not chown a file or directory you do not own
[00:17] <bodhi_zazen> hey pleia2 :)
[00:18] <Spreadsheet> bodhi_zazen: All of the files on this comp belong to me...
[00:18] <bodhi_zazen> this makes sense in that a user can not chown a file owned by root
[00:18] <Spreadsheet> Oh wait
[00:18] <Pretto> never happened to me :D
[00:18] <bodhi_zazen> LMAO Spreadsheet
[00:18] <Spreadsheet> Ok, the file is owned by root
[00:18] <Spreadsheet> So then I use sudo
[00:18] <bodhi_zazen> to change a file woned by root you need sudo
[00:19] <bodhi_zazen> but you should not change ownership or permisssions of system files
[00:19] <Spreadsheet> It's not a system file
[00:19] <bodhi_zazen> sudo -e /etc/fstab for example
[00:19] <Spreadsheet>  /var/www/
[00:19] <bodhi_zazen> yea, that *should* be owned by www-data
[00:19] <Spreadsheet> ehh... go on
[00:19] <bodhi_zazen> so, add your user to www-data
[00:19] <bodhi_zazen> :)
[00:20] <bodhi_zazen> OK, we were talking sticky bits
[00:20] <bodhi_zazen> the most common use of a sticky bit is on a directory
[00:20] <bodhi_zazen> if a sticky pit is set on a shared directory (one with say permissions of 777)
[00:21] <bodhi_zazen> users can not delete file they do not own
[00:21] <bodhi_zazen> even though group or other permissions may allow rw access to a file
[00:21] <bodhi_zazen> There is a very nice review of sticy bits here : http://lokams.blogspot.com/2008/03/about-suid-sgid-and-sticky-bit.html
[00:22] <bodhi_zazen> and here : http://www.linuxdevcenter.com/pub/a/linux/lpt/22_06.html
[00:22] <bodhi_zazen> questions ?
[00:22] <bodhi_zazen> Otherwise I am going to talk about acl , or access control lists
[00:23] <bodhi_zazen> Please, all questions are welcome and it gets boring seeing a wall of bodhi.zazen speaking >:)
[00:23] <Snova> Might want to go into setuid/setgid (though that'd be another wall :P)
[00:23] <Snova> Oh wait
[00:23]  * Snova wasn't here
[00:23] <Snova> Well, in that case, what does the sticky bit do on a file?
[00:23] <bodhi_zazen> lol Snova :)
[00:24] <bodhi_zazen> you mean the -t on a file ?
[00:24] <bodhi_zazen> or the SUID
[00:24] <Snova> Sticky bit... no idea what "-t" means. :P
[00:24] <bodhi_zazen> lol
[00:25] <bodhi_zazen> Snova: take a look at this linky : http://lokams.blogspot.com/2008/03/about-suid-sgid-and-sticky-bit.html
[00:25] <Spreadsheet> g2g
[00:25] <bodhi_zazen> I covered the topic just previous and do not want to repeat it ;)
[00:26] <bodhi_zazen> OK , acl stands for access control list
[00:26] <bodhi_zazen> the idea of an acl list comes into play when you have many, perhaps hundreds of users on a system
[00:26] <bodhi_zazen> and so then the "other" permissions get messy
[00:27] <bodhi_zazen> you do not want to create hundreds of groups for all the various user shares
[00:27] <bodhi_zazen> enter acl
[00:27] <bodhi_zazen> acl allows a user to set permissions on a file or directory for each user on the system
[00:28] <bodhi_zazen> acl is the backbone of SELinux, and if you understand acl you understand a lot about SELinux
[00:28] <bodhi_zazen> acl is installed by default on Ubuntu, but you need to "activate" it
[00:28] <bodhi_zazen> it is an option when you mount a file system
[00:28] <bodhi_zazen> so you
[00:29] <bodhi_zazen> mount /dev/sdxy /media/foo -o acl
[00:29] <bodhi_zazen> Or add acl to /etc/fstab in the options column
[00:29] <Pretto> so, acl is just for "others" right?
[00:29] <bodhi_zazen> yes and no Pretto
[00:29] <bodhi_zazen> I will demo it in a sec ...
[00:30] <bodhi_zazen> acl is a command line tool
[00:30] <bodhi_zazen> although there is a very nice gui tool, Eiciel
[00:30] <bodhi_zazen> http://www.linux.com/feature/138169
[00:31] <bodhi_zazen> Eiciel is in the Ubuntu repos , but I could not integrate it with Nautilus as in that link
[00:31] <bodhi_zazen> after you install it it is in the menu under System
[00:31] <bodhi_zazen> want to see acl in action ?
[00:31]  * jgoguen nods
[00:32] <Pretto> yeap
[00:32] <bodhi_zazen> OK, everyone ssh into the shared session ?
[00:32] <bodhi_zazen> let me show a few things ...
[00:33] <bodhi_zazen> OK, permissions of new files are govened by umask
[00:33] <bodhi_zazen> so as you can see , the group is govened by the primary or effective group
[00:33] <bodhi_zazen> Now lest change groups for a sec
[00:34] <bodhi_zazen> the command was newgrp and it spawns a new shell
[00:34] <Pretto> :D
[00:34] <bodhi_zazen> do you see how that changed the group of the new file ?
[00:35] <bodhi_zazen> OK, so if I want a shared directory , I would now need to chmod all those files
[00:35] <bodhi_zazen> chomd -R 770 MAD
[00:35] <bodhi_zazen> or worse, chmod -R 777 MAD
[00:36] <bodhi_zazen> or chgrp and then chown, you get the idea
[00:36] <bodhi_zazen> now let us use ACL
[00:36] <bodhi_zazen> See the +s in the permissions ?
[00:36] <bodhi_zazen> the sgid is set
[00:38] <bodhi_zazen> Do you see how the sgid bit made the file "file.admin" owned by the group guru ?
[00:38] <bodhi_zazen> >:)
[00:38] <bodhi_zazen> OK, now acl ...
[00:38] <bodhi_zazen> You list the access list with getfacl file
[00:39] <bodhi_zazen> we set the acl with setfacl
[00:42] <bodhi_zazen> This changed the behavior of the directory, we set the defaults with -d and the options with -m and long handed rwx permissions
[00:42] <jgoguen> bodhi_zazen: so the default ACL entries will override the existing user/group/other permissions?
[00:42] <bodhi_zazen> yes jgoguen
[00:43] <bodhi_zazen> with that last command , I over rode the sgid we set
[00:43] <bodhi_zazen> the directory is not owned by admin
[00:43] <bodhi_zazen> default:group:admin:rwx
[00:43] <bodhi_zazen> watch
[00:44] <bodhi_zazen> hmm ,not what I expcected, lol
[00:44] <Pretto> hhehhehhe. .weird
[00:45] <Pretto> so the + means that MAD has an acl?
[00:46] <bodhi_zazen> yes Pretto
[00:46] <bodhi_zazen> see how acl changed the group of "file" made by root ?
[00:46] <bodhi_zazen> from root.root to root.guru ?
[00:46] <bodhi_zazen> OK, now lest add a user
[00:47] <bodhi_zazen> see, now I added in the user, bodhi, who has rwx to the file MAD/file.guru
[00:48] <bodhi_zazen> user:bodhi:rwx
[00:48] <bodhi_zazen> and on
[00:48] <bodhi_zazen> Obviously acl is a bit complex
[00:48] <bodhi_zazen> and I will not claim to be an expert
[00:48] <bodhi_zazen> :)
[00:49] <bodhi_zazen> oops, apparmor is preventing me from showing you more with acl at the moment
[00:49] <bodhi_zazen> lol
[00:50] <bodhi_zazen> see : http://www.suse.de/~agruen/acl/linux-acls/online/
[00:50] <bodhi_zazen> for more info on acl
[00:50] <bodhi_zazen> and man acl
[00:50] <bodhi_zazen> and Eiciel
[00:51] <bodhi_zazen> Eiciel gives you a gui tool to manage acl
[00:51] <bodhi_zazen> Sorry if I rambled on too long about permissions
[00:51] <bodhi_zazen> :)
[00:51] <bodhi_zazen> we have 10 min left
[00:51] <bodhi_zazen> questions ?
[00:52] <bodhi_zazen> you like the shared ssh session ?
[00:53] <bodhi_zazen> I can demo apparmor if you want :)
[00:54] <bodhi_zazen> See how the /tmp directory has +t set ?
[00:54] <bodhi_zazen> you should now know what that means :)
[00:55] <bodhi_zazen> you should now understand why root kits search for files with the suid bit set
[00:58] <jgoguen> bodhi_zazen: back to setuid/setgid...should setgid necessarily be avoided the same as setuid?
[00:59] <bodhi_zazen> probably jgoguen
[00:59] <bodhi_zazen> although it is not working as I expected
[01:00] <bodhi_zazen> if you need to run a script as root, use sudo
[01:00] <bodhi_zazen> If you need to give a user limited root access, use sudo and configure with visudo >:)
[01:00] <bodhi_zazen> Ah, apparmor is restricting me from further demos :)
[01:01] <bodhi_zazen> you will have to check out suid on your own , lol
[01:01] <jgoguen> I was thinking more along the lines of having a script write to a log file...but I suppose ACL would also handle that quite nicely :)
[01:01] <bodhi_zazen> acl FTW :)
[01:02] <bodhi_zazen> Once you learn acl , and you have a multiuser system, you will make good use of it
[01:02] <bodhi_zazen> acl does not make sense, however, on a single user system
[01:03] <Pretto> thank you for your explanations bodhi_zazen
[01:03] <bodhi_zazen> np Pretto :)
[01:03] <bodhi_zazen> thank you for coming
[01:03] <bodhi_zazen> anyone have a suggestion for next time ?
[01:04] <bodhi_zazen> In the long run, we will bring up a moodle site and content will be available for review pre and post sessions
[01:04] <bodhi_zazen> the BT is working on it
[01:04] <bodhi_zazen> If you have suggestions, add it here
[01:05] <bodhi_zazen> https://wiki.ubuntu.com/BeginnersTeam/FocusGroups/Education/Proposals
[01:05] <bodhi_zazen> thank you everyone for coming
[01:05] <bodhi_zazen> please spread the word
[01:06] <bodhi_zazen> you should all have been disconnected from the shared session as I closed it :)
[01:06] <bodhi_zazen> see you again in 2 weeks
[01:06] <jgoguen> \o/ ty bodhi_zazen
[01:06] <bodhi_zazen> you are most welcome jgoguen
[01:06] <bodhi_zazen> I hope I learned you something
[01:08] <WastePotato> I always miss it. ):
[01:08] <DasEi> ermm, you're just done now ?
[01:08] <WastePotato> ?
[01:09] <WastePotato> I had a shower.
[01:09] <DasEi> root@jaunty64:~# date -u
[01:09] <DasEi> Fr 10. Apr 00:05:07 UTC 2009
[01:09] <DasEi> root@jaunty64:~#
[01:09] <WastePotato> Wut/
[01:09] <DasEi> gnarf...
[01:10] <WastePotato> Hey bodhi_zazen, what was that thing on your shell with the quote and and the calendar? I want it. o:
[01:13] <WastePotato> DasEi: Oh I get it.
[01:13] <DasEi> I recently got a email saying friday, 00.00 utc.. two thirds of every meeting slip through the time-gap
[01:13] <WastePotato> Daylight savings time, maybe?
[01:14] <DasEi> WastePotato: on a linux-trml? , lol; WastePotato
[01:14] <WastePotato> Hmm.
[01:15] <DasEi> sad enough, and I even was on and checked time before-- lets all go home and cry then ;-)
[01:16] <WastePotato> Wait a sec.
[01:16] <DasEi> sure
[01:17] <DasEi> any of the others, did someone log that seession ?
[01:18] <WastePotato> http://pastebin.com/f153ef8b5 ('pastebin - collaborative debugging tool')
[01:18] <WastePotato> It's the best I can do. ):
[01:18] <WastePotato> Damn. I really need to sort out my log folder.
[01:19] <DasEi> WastePotato: very nice thank you, no I can rest in peace in again
[01:20] <WastePotato> DasEi And all of the stuff that happened in his ssh session is here: http://pastebin.com/m1aa9b669 ('pastebin - collaborative debugging tool')
[01:23] <DasEi> so permissions, nothing completly new to me, though always nice to rexerise; funny, the date I got was european - one day
[01:24] <DasEi> WastePotato: did you want me to wait for the log or still something else ?
[01:30] <WastePotato> Eh?
[01:32] <WastePotato> The channel log and the ssh log are all that I have/
[01:34] <WastePotato> Does anyone want me to paste the log on the site?
[01:34] <WastePotato> !log
[01:34] <ubot2> Channel logs can be found at Channel logs can be found at http://irclogs.ubuntu.com/ - See also !OpenWeek - See also !OpenWeek
[01:34] <WastePotato> ):
[01:34] <DasEi> WastePotato: that was very nice, I just refelcted your upper Wait a sec, gripping acl rightnow:)
[01:34] <DasEi> reflected*
[01:35] <WastePotato> Oh. :)
[01:40] <DasEi> is there anyone around practising some ssh with me tomorrow/saturday..  whenever ?
[01:44] <DasEi> enough to read and try myself for now, see you around and thanks again
[04:38] <schwinn434> looking for #ubuntuforums-beginners something like this, any help would be appreciated
[04:38] <schwinn434> can't get the exact chat room name correctly
[04:42] <nhandler> schwinn434: It is #ubuntuforums-beginners, I don't know why it isn't working for you


[02:08] <phma> I'm trying to package a program I wrote. I typed:
[02:08] <phma> bzr dh-make mirasol 0.1.0 ~/build/mirasol/cdbg/mirasol-0.1.0-Source.tar.bz2
[02:09] <phma> It replied:
[02:09] <phma> bzr: ERROR: Either run the command from an existing branch of upstream, or move mirasol aside and a new branch will be created there.
[02:09] <phma> man bzr doesn't say anything about dh-make, so I'm lost.
[02:10] <phma> I ran the command in a newly created ~/package directory.
[02:16] <ItzSwirlz> Hm
[02:16] <ItzSwirlz> did you run dh_make --createorig?
[02:18] <phma> no, I didn't see any instruction to do that.
[02:18] <phma> https://packaging.ubuntu.com/html/packaging-new-software.html
[02:21] <phma> The prompt is just "$", which doesn't tell me which directory I should be in when running the commands.
[02:23] <ItzSwirlz> hm
[02:23] <ItzSwirlz> I don't use bzr much so I cant help
[02:28] <phma> What directory should I run dh_make in?
[02:30] <phma> ls in ~/package looks like this: mirasol  mirasol_0.1.0.orig.tar.bz2
[02:31] <phma> mirasol is a directory containing the source code.
[03:08] <ItzSwirlz> dh_make should be ran in the root dir of the project
[03:13] <phma> You mean in the source directory? Nothing goes in the source directory except source files, backup files, and the .git directory.
[03:30] <nano11bravo> git commit "cats play in the dark"


[01:11] <igc1> morning all
[01:13] <poolie> hello igc1
[01:14] <poolie> igc1, maybe we could do a blog post together about news in explorer some time?
[01:15] <igc> hi poolie
[01:16] <igc> poolie: that would be good. I'm pretty close to calling it 1.0beta fwiw
[01:18] <poolie> igc: re the 'evaluation' thread, how about if i make init warn you when it's making a standalone repository?
[01:18] <poolie> or maybe even fail, would that be too harsh?
[01:18] <poolie> i guess init and branch would need to do this
[01:19] <lifeless> I believe init-repo reports the format of what it made today.
[01:19] <lifeless> making init do the same wouldn't be horrible; and you could fold that in reasonably tastefully I suspect
[01:20] <igc> poolie: I'm yet to see that email sorry. Ask me again later today :-)
[01:42] <poolie> np
[02:04] <lifeless> poolie: another example of the project-priority != dev priority mismatch: for doc folk, sorting some doc bugs to high and low may be very useful, even if for the project all doc bugs are low.
[02:04] <lifeless> poolie: I'm starting to think personal[inc teams]-annotation of bugs would be a really useful feature.
[02:04] <poolie> mm
[02:04] <poolie> yes
[02:05] <lifeless> e.g. the launchpad-bazaar folk could annotate the bugs they care about as critical etc; bzr devs could choose to see that, or ignore it.
[02:05] <poolie> yes i see
[02:06] <lifeless> it would give you the 'I care about this bug' thing you like to do too. mmm could perhaps trial by having the doc team tag with doc-high, doc-low etc
[02:57]  * igc lunch
[03:14] <lifeless> time to pickup my passport
[03:15] <Kamping_Kaiser> :)
[03:50] <distatica> Is the diff utility that is called by qdiff specific to bzr? It's an excellent tool, and I'd love to use it elsewhere besides bzr repos.
[03:52] <spiv> distatica: to be precise, it's part of the qbzr plugin for bzr.
[03:52] <distatica> Yeah, that's what I'm thinking.. is there any way to run it on it's own?
[03:53] <spiv> distatica: I haven't looked closely at the source, but it's probably not too hard to take that part and make a standalone program of it.
[03:53] <distatica> What language is that stuff written in? do you know?
[03:53] <spiv> distatica: although for non-bzr diffing I'd probably use an existing graphical diff tool like meld.
[03:53] <distatica> The part i would probably be working with.
[03:53] <spiv> distatica: Python
[03:53] <distatica> oh, then I have a hope in hell. :)
[03:54] <distatica> never tried meld, will check it out. So far the best tool I have used is the qbzr one.
[03:54] <spiv> distatica: basically all of bzr and its plugins are Python.  (There are some optional C and Pyrex extensions for speed, but you wouldn't need to touch those for this.)
[03:55] <distatica> I had heard that it was python, but wasn't sure. I'm glad for that, Python is a good language.
[03:55] <distatica> meld looks pretty good too, thanks
[03:58] <spm> spiv: Ooo. Ta! meld is *nice*. been using kompare myself, meld looks that little bit better. ta x 2.
[03:59] <spiv> spm: heh :)
[04:00] <spm> the big win was the in each line highlight of the differences. some of our changes in configs can have (not pointing fingers at PQM, much) horrible regexs. and picking up the diff can be... hard. :-)
[04:00] <distatica> Pretty decent, I don't know if it's quite up to the qbzr version, but it's good anyways.
[04:29] <shakaran> Hi, how I can count the added/removed lines between 2 commits?
[04:30] <RAOF> “bzr diff -r$OLD..$NEW | diffstat” would work.
[04:33] <shakaran> RAOF: thanks, works perfect!
[05:16] <poolie> spiv, igc, lifeless, hi
[05:16] <poolie> (and anyone else) can you please test installation of bzr from karmic-proposed
[05:16] <poolie> if it works ok, please comment on https://bugs.edge.launchpad.net/ubuntu/+source/bzr/+bug/437626
[05:28] <spiv> poolie: done
[05:36] <poolie> thanks
[05:58] <poolie> spiv, excuse my bad memory, but did you do something generic about hiding exceptions during cleanup
[05:58] <poolie> and if so what?
[05:58] <poolie> i'd like to use it in bug 423015
[05:58] <spiv> poolie: see the bzrlib.cleanup module
[05:59] <poolie> thanks
[05:59] <spiv> poolie: also either one of my unreviewed merge proposals ;)
[05:59] <poolie> :)
[05:59]  * spiv -> afk for 10 minutes
[06:46] <ChrisMorgan> I created my branches in a shared repository, but now I'm into another problem; I have branches for [company].[module] and [company].clients.[whatever], but I really need a basic one for just [company] so I can put my __init__.py file in there - can I do that without causing trouble determining which branch things belong to?
[06:51] <lifeless> ChrisMorgan: sure
[06:52] <ChrisMorgan> How about if I create a new file in one of the subdirectories which has its own branch - will it show up as 'unknown' in the parent branch?
[06:53] <ChrisMorgan> It's saying 'unknown' for the sub-branches... ignore?
[07:03] <lifeless> igc: I really wish you could explain how heavyweight checkouts != bound branches - it confuses the hell out of me when you say that
[07:03] <lifeless> ChrisMorgan: up to you
[07:03] <ChrisMorgan> Or can I do something with join/split stuff?
[07:04] <ChrisMorgan> I'm confused :-)
[07:04] <lifeless> ChrisMorgan: what are you trying to do
[07:05] <ChrisMorgan> I have a parent directory squiggle.  There is a repository in it.  There are lots of branches in subdirectories, squiggle/foo, squiggle/bar, etc.  There would be no need to have a branch in squiggle, except for the fact that Python requires a file __init__.py... so I need another branch in squiggle.
[07:05] <ChrisMorgan> However, bzr status squiggle then goes not knowning about foo and bar
[07:06] <ChrisMorgan> Upps, got to go now, I'll stay in the room though if you can help me? :-)
[07:06] <lifeless> if foo and bar are branches bzr st shouldn't mention them.
[07:06] <lifeless> are you sure they are branches?
[07:06] <lifeless> you might try pastebinnning the command + output.
[07:08] <igc> lifeless: well I did try to explain the differences in https://lists.ubuntu.com/archives/bazaar/2010q1/065891.html
[07:12] <poolie> spiv: big one approved
[07:12] <spiv> poolie: thanks!
[07:13] <igc> poolie, lifeless, vila: wrt my disable plugin patch, should I remove support for an explicit path and just support 'disable' (or '') for disabling them?
[07:13] <lifeless> igc: I would be happiest if you just did disable for now
[07:14] <lifeless> vila and I can try to get what poolie is concerned about in strasbourg
[07:14] <poolie> (phone)
[07:15] <igc> lifeless: so the feature you and vila are working on will miss 2.1?
[07:15] <lifeless> igc: I'm a) sick, and b) working on dx-team stuff, and then lca and then strassbourg
[07:16] <igc> lifeless: I really don't need the path stuff but my patch might be a stop gap until your stuff lands?
[07:16] <igc> lifeless: but I personally only care about disabled vs otherwise
[07:16] <lifeless> igc: I know that your path stuff won't help any of the use cases I've seen for automated stuff in this area
[07:16] <lifeless> igc: so I'm not sure who it would be stop-gapping for
[07:17] <igc> lifeless: only someone with a plugin both system installed and locally installed - picking the former over the latter
[07:20]  * vila needs to bring his car to the garage and will be afk for ~1 hour
[07:22] <vila> igc: but regarding plugin stuff, as said in my mail, 1) using config vars is not a good idea, 2) using PZR_PLUGIN_PATH to disable is not trivial and I'm not working on it right now
[07:26] <poolie> igc, i don't have any strong objection to being able to set the path there
[07:26] <poolie> i'll look at the patch again
[07:27] <poolie> spiv, how about just always logging cleanup failures?
[07:27] <poolie> oh
[07:27] <poolie> nm, i misread it
[07:28] <lifeless> poolie: vila and I have concerns though. Can we land igcs disable-only version of the patch ?
[07:30] <poolie> does that exist now?
[07:30] <poolie> i think vila's final comments in https://code.edge.launchpad.net/~ian-clatworthy/bzr/411413-plugin-disable/+merge/16719 are reasonable
[07:30] <poolie> however incremental improvements are also good
[07:30] <lifeless> igc has implied that it did in the past or is at least trivial to get to.
[07:32] <igc> poolie, lifeless: I don't have a version yet that does disable only. It's a one line code change I suspect.
[07:33] <igc> poolie, lifeless: tweaks the doc changes in my patch is the larger part if that's the direction to go
[07:33] <igc> tweaking
[07:34] <lifeless> poolie: quick call?
[07:34] <igc> poolie, lifeless: the broader Q was a conceptual one: should I 'remove' functionality from the patch given there's no alternative likely soon?
[07:35] <igc> wrt specifying an explicit plugin when multiple are installed
[07:35] <ChrisMorgan> lifeless: yep, they're branches alright, but with no commits yet - should I commit to them?
[07:37] <poolie> lifeless: sure
[07:38] <ChrisMorgan> lifeless: bzr init-repo foo, bzr init foo/bar, bzr init foo, bzr st foo: unknown: bar/
[07:39] <ChrisMorgan> Commit an unchanged revision to foo/bar and st foo still shows unknown bar
[07:44] <ChrisMorgan> I also tried the split / join --reference stuff as at http://wiki.bazaar.canonical.com/NestedTreesDesign#creating-a-nested-tree and I'm still getting the unknown status on bar
[07:45] <lifeless> ChrisMorgan: don't touch split/join
[07:45] <lifeless> ChrisMorgan: its not production ready
[07:45] <ChrisMorgan> OK, I was just testing it as that was what was detailed in the page.
[07:45] <ChrisMorgan> I figured it wasn't ready seeing as it didn't work :P
[07:47] <lifeless> ChrisMorgan: you probably want to do bzr ignore ./bar
[07:48] <ChrisMorgan> OK then.  Or I could resort my structure... thinking about it more I don't need the clients stuff in the main branch... I'm not going to want to be able to `import myproj.clients.whatever`...
[07:48] <ChrisMorgan> So I think I'll actually separate it one level more in the repository.
[07:48] <ChrisMorgan> Thanks.
[07:49] <ChrisMorgan> Uh... can I "uninit"?
[07:49] <igc> poolie, vila, lifeless: I've replied to vila's comment on my patch now
[07:50] <ChrisMorgan> I've run init-repo and init in the same directory, can I go back to just the repo rather than the branch as well, or should I just scrap all my .bzr directories and start clean again?
[08:09] <lifeless> ChrisMorgan: if you delete .bzr/branch and .bzr/checkout then you'll have what bzr init-repo created
[08:19]  * vila back
[08:26]  * igc dinner
[08:28] <bialix> hello all
[08:28] <bialix> igc is here?
[08:32] <lifeless> 19:26  * igc dinner
[08:32] <lifeless> 19:28 -!- bialix<EMAIL_ADDRESS>has joined #bzr
[08:32] <bialix> thanks lifeless, and hi
[08:34] <lifeless> hi :)
[09:40] <mathrick> hiya, I have a repo (my thesis) where I started some work (library bindings) which I now want to split out into a standalone branch. But I don't want the intial commits to the thesis files to show up in the bindings' history
[09:40] <mathrick> the commits look like that: 1..3 thesis, 4.. bindings
[09:41] <mathrick> so in essence I want to remove commits 1..3 from the history
[09:41] <mathrick> what's the best way to do that?
[09:41] <mathrick> the changes are textually independent, and all bindings work happened in a subdir I bzr split out
[09:55] <bialix> fast-import-filter
[10:08] <mathrick> bialix: thanks, lemme try that
[10:15] <ChrisMorgan> lifeless: thanks, I got my repository and branches all set up properly again... I think I'm happy with it this time and think it'll do all that I want :-) (Though if I could version the contents of a SQLite, MySQL or PostgreSQL database with Bazaar I'd be even happier...)
[10:15] <mathrick> bialix: that worked fine, cheers
[10:31] <lifeless> ChrisMorgan: bzr can do it; doesn't make it a good idea :)
[10:31] <ChrisMorgan> How can it do it?
[10:31] <lifeless> bzr add foo.db; bzr commit.
[10:31] <ChrisMorgan> The /contents/ of the database... not the database!
[10:32] <lifeless> sqlite foo.db dump > foo.dump; bzr add foo.dump; bzr commit
[10:33] <ChrisMorgan> Still not automatic :-)
[10:33] <ChrisMorgan> I suppose SQLite can have hooks... I wonder what that would really do to performance.
[10:33] <ChrisMorgan> Ghastly idea, isn't it :D
[10:37] <mathrick> ChrisMorgan: that's why people invented backups
[10:37] <mathrick> do a periodic snapshot and version that
[10:37] <ChrisMorgan> I know... it really would simplify my task though if I could use Bazaar to version the contents of a database...
[10:37] <ChrisMorgan> Ah well, I'll sort it out somehow :-)
[10:48] <mathrick> ChrisMorgan: you could make a hook that took a snapshot before commits, but it'd presumably make commits slow
[10:50] <ChrisMorgan> Problem is it's the other way round I want it - someone does something on the website (something that matters, i.e. in the admin section) and it goes and exports that and commits to bzr, and a way then to do the converse with pulling, take a diff and apply it somehow to the database.
[10:50] <ChrisMorgan> I think I'm dreaming a rather far-fetched dream.  I think I'll have to be satisfied with django-reversion at the moment.
[10:50] <mathrick> ChrisMorgan: in this case, what you really want is a full-fledged plugin
[10:50] <ChrisMorgan> Something like that.
[10:51] <ChrisMorgan> A way to version the contents of a database.
[10:51] <ChrisMorgan> Clearly every table being versioned would need to have a primary key.
[10:53] <ChrisMorgan> How hard do you think it'd be?
[10:54] <ChrisMorgan> Do you think it'd be reasonable and possible?
[10:54] <ChrisMorgan> I imagine I'd need to learn a lot about Bazaar first.  For the moment I think I'll get on with other facets of my product.
[11:02] <ChrisMorgan> I'm sure it would be fascinating to do.  I'll see if I ever get to it :-)
[11:02] <ChrisMorgan> Goodnight now.
[13:16] <rubbs> ok, I know this is easy, but I can't seem to find it. I branched from a machine on my LAN, but now I want it to pull from lp:bzr. How do I change the parent branch?
[13:17] <maxb> pull --remember
[13:18] <rubbs> cool, thanks. I knew it was something rediculously easy
[15:11] <squeeky> Hi kids. Using the 2.01 Mac package from the website, fresh install, I try to bzr branch or init and score "bzr: ERROR: '/Volumes/Data' is not a working copy
[15:11] <squeeky> So what went wrong?
[15:11] <Peng> Ick, the most recent revision of bzr.dev caused conflicts with 2.0.
[15:12] <squeeky> It was labelled as "stable".
[15:12] <vila> fullermd: ping
[15:14] <vila> squeeky: Pend refers to the dev version, not related to your problem, can you pastebin your $HOME/.bzr.log ?
[15:14] <squeeky> any pastebin of choice?
[15:14] <vila> !paste
[15:16] <squeeky> http://ubuntu.pastebin.com/m5a8c668e
[15:18] <Peng> What the hell, pastebin.com? Why not paste.ubuntu.com?
[15:18] <squeeky> I should empasise that /Volumes/Data is the working parent directory to the one I was trying to bzr init/branch
[15:19] <Peng> squeeky: I suspect you have an .svn directory sitting somewhere.
[15:19] <Peng> squeeky: ls /Volumes/Data/.svn and /Volumes/data/whatever/.svn
[15:19] <squeeky> What does this have to do with the price of tea in china?
[15:20] <Peng> squeeky: bzr-svn
[15:20] <squeeky> ummm, okay, wasn't using that. Can't bzr just not pay attention to .svn folders in a parent?
[15:20] <LeoNerd> How else would it know you were in a svn checkout, though?
[15:20] <Peng> squeeky: You are using bzr-svn.
[15:21] <LeoNerd> bzr implements a prettymuch-complete frontend to working on svn checkouts/WCs/etc...
[15:21] <squeeky> what
[15:21] <squeeky> so... it's a piggyback scm?
[15:21] <LeoNerd> No...
[15:21] <LeoNerd> bzr has its own native formats of course.
[15:21] <LeoNerd> It -can- use svn -as well-
[15:21] <LeoNerd> You can use the bzr command as a frontend to a number of different repository/wc formats, including svn, git,...
[15:22] <LeoNerd> Since you have the bzr-svn plugin loaded, it's looking for .svn directories, in case you're trying to use it on a svn checkout
[15:22] <squeeky> ugh.
[15:22] <LeoNerd> I find it very useful... Being able to  bzr log10  in a svn checkout, or  bzr shelve  it
[15:22] <LeoNerd> It actually makes svn almost useable
[15:23] <squeeky> I generally don't mix scm's. But whatever, it's fixed now, thanks Peng.
[15:23] <LeoNerd> If you're not wanting to use the bzr-svn stuff.. then.. uh.. just don't load the bzr-svn plugin :)
[15:23] <LeoNerd> Heh.. we have a bizarre mix of cvs/svn/bzr at work.. I like not needing to remember which command is which. I just type "bzr whatever".. and it all works out
[15:24] <squeeky> meh, it's fossil for internals, git for stuff that tentatively gets public OS release, svn/cvs/bzr for patching other people's stuff.
[15:45] <maxb> I find it pretty annoying when bzr-svn kicks in when I'm not actually in a svn wc
[15:46] <maxb> It would be better if it didn't search up for .svn, since .svn doesn't require that
[17:38] <fullermd> vila: Hmmwhat?  I didn't do it, I swear.
[17:49] <jam> abentley: are you around?
[17:49] <jam> I'm trying to sort out bug #494269
[17:49] <jam> And trying to understand what TT should be doing
[17:50] <jam> I *think* it should be allowing the tree root to be added, but at apply time it should verify that there is only one
[17:51] <jam> (the delta I'm looking at shows the new root added at the beginning, then all paths are renamed into that new location, then the old one is removed.)
[18:36] <kiko> hey there
[18:36] <kiko> say I have a tree that contains as a subdirectory a copy of bzr
[18:36] <kiko> is there a way of updating that subdirectory to a more recent version of bzr and retaining some commit history information?
[18:37] <kiko> a copy of the bzr source IYSWIM
[18:37] <luks> that question doesn't make sense to me
[18:37] <jam> kiko: so you have a tree, such that in one subdir you also have a version of the bzr source
[18:37] <luks> how it updating bzr in conflict with retaining history?
[18:37] <maxb> Could you elucidate "retaining some commit history information" ?
[18:37] <jam> is that correct?
[18:37] <kiko> luks, let me trivialize it
[18:38] <jam> if you used stuff like "bzr merge-into"
[18:38] <jam> to create it
[18:38] <kiko> launchpad contains a subdirectory called lp-buildd
[18:38] <jam> then in the future you should be able to "bzr merge $BZR"
[18:38] <jam> and it should mostly JustWork
[18:38] <kiko> lp-buildd is actually managed as a separate branch
[18:38] <kiko> by lamont
[18:38] <jam> (lp:bzr-merge-into, btw)
[18:39] <kiko> can I merge the changes in lp-buildd into the launchpad tree
[18:39] <kiko> with bzr-merge-into?
[18:39] <jam> kiko: I assume you want to bring the lp-buildd code into the launchpad codebase in a subdir
[18:39] <fullermd> I think you're asking the other way around from what merge-info is for.
[18:39] <jam> bzr-merge-into should do a decent job of that, IIRC
[18:39] <maxb> IIUC, yes if they already share ancestry. Otherwise, an initial delete and re-merge would be required.
[18:39] <jam> If you are trying to split it out
[18:40] <kiko> jam: they don't share any history
[18:40] <jam> then you can split it out and play tricks with 'bzr add --file-ids-from"
[18:40] <jam> kiko: unfortunately, *today*, without the same file ids, we can't link up the changes
[18:40] <kiko> gotcha
[18:42] <abentley> jam: I believe that was one of the things my proposed changes to nested trees fixed.
[18:43] <abentley> jam: I agree that TreeTransform should delay tree shape sanity checking until the transform has been completely specified.
[18:44] <C-S> I get the following bug: bzr: ERROR: exceptions.AttributeError: 'tuple' object has no attribute 'encode'
[18:44] <C-S> any idea?
[18:44] <abentley> jam: I would do that in find_conflicts
[18:44] <jam> C-S: any backtrace?
[18:44] <jam> C-S: Something is getting a tuple that is expecting a string
[18:44] <C-S> yes there is quite some backtrace, can I post it somewhere?
[18:44] <jam> !paste
[18:46] <C-S> jam: http://ubuntu.pastebin.com/d7752a537
[18:46] <C-S> ubottu: thank you
[18:47] <abentley> jam: see fixup_new_roots in transform.py in http://bazaar.launchpad.net/~abentley/bzr/nested-trees
[18:48] <jam> abentley: thanks for the pointer
[18:56] <C-S> jam: any ideas?
[18:58] <jam> C-S: can you paste "bzr status" before the commit?
[18:59] <jam> I'm wondering if it might have something to do with a symlink, et
[18:59] <jam> etc
[19:00] <C-S> jam: http://ubuntu.pastebin.com/d125d8417
[19:00] <C-S> jam: or with Umlauts in file names?
[19:12] <C-S> jam: I now deleted all .bzr directories and restarted.
[19:12] <C-S> jam: Even after adding one .tex file it crashes
[19:27] <jam> C-S: what does "bzr plugins" list?
[19:29] <C-S> jam: http://ubuntu.pastebin.com/d5abcf59f
[19:32] <jam> C-S: you could try "bzr commit --no-plugins" but that doesn't seem to be it
[19:32] <jam> certainly this doesn't seem to happen to me, since I've been committing without probs for a long time
[19:34] <C-S> jam: that gives a different error:
[19:35] <C-S> jam: bzr: ERROR: No repository present: "file:///..."
[19:35] <jam> C-S: so are you in a subdirectory of a git repo?
[19:36] <C-S> jam: hmm let me check
[19:36] <jam> (I don't know that bzr-git implements proper commit
[19:36] <jam> commit-to-git support)
[19:38] <C-S> jam: this was it! It works again after deleting the .git folder in the main directory.
[19:38] <C-S> jam: it would be could to give a nice bug report
[19:39] <jam> C-S: so I think this is a bug in bzr-git, you can mention something about 'commit in git working dir fails', and include the traceback
[19:40] <jam> I'm guessing that the GitCommitBuilder.record_iter_changes is working differently than we think it should
[19:40] <jam> either that or GitTree.iter_changes() is working differently
[19:41] <jam> what is weird is that it seems to be a mix of WorkingTree4 (which is a bzr regular tree)
[19:41] <jam> so I don't really understand why it was confused
[19:41] <jam> C-S: steps to reproduce would also be appreciated
[19:47] <C-S> jam: I'll file the bug. Thanks again.
[19:57] <maxb> Is there any way to hook bzr to discover all branch modifications? Such as might be needed to implement an automatic backup system?
[19:58] <maxb> In particular, I want to know about operations that don't change the tip of a branch - e.g. tags
[20:13] <mathrick> abentley: are pipelines meant to provide a similar functionality to git rebase's patch reshaping, or is that different?
[20:14] <abentley> mathrick: No, they're meant to be an alternative to rebasing.  For similar functionality, see bzr-rewrite.
[20:14] <kiko> jam, btw, you could provide the licensing information for bzr-merge-into.. ;-)
[20:15] <mathrick> abentley: oh, I didn't see rewrite on the plugins page
[20:16] <jam> kiko: __init__.py clearly states GPLv2, but I can add a COPYING.txt if it makes you feel better
[20:16] <mathrick> abentley: but pipes can still result in retroactive history changes, right?
[20:16] <kiko> jam, no, I meant on launchpad :)
[20:16] <jam> ah
[20:16] <mathrick> how does that play together with published branches?
[20:16] <abentley> mathrick: bzr-rewrite was formerly called rebase, and that name is still used on the plugin page.
[20:17] <abentley> mathrick: pipes cannot result in retroactive history changes.
[20:17] <jam> kiko: done
[20:17] <jam> not entirely sure why it matters
[20:18] <mathrick> abentley: so what's the result of adding a patch to an earlier pipe and pumping it?
[20:18] <abentley> mathrick: It's as though you did a merge and commit in the later pipe.
[20:18] <mathrick> oh
[20:19] <mathrick> so it'll be visible to someone reading patches?
[20:20] <jam> abentley: the tests I can find in transform are about moving a root directory, I'm trying to test adding a new one and removing the old one completely
[20:21] <jam> abentley: does this look valid: http://paste.ubuntu.com/355157/
[20:21] <jam> (It currently fails trying to rename the cwd, but I want to know that I'm on the right track first)
[20:22] <abentley> jam: That looks like a reasonable change.  You're probably right that we haven't tried to handle that directly in the TT before.  I'm pair programming at the moment.
[20:23] <jam> abentley: sure, I don't mean to bother you too much, but I don't really know how the TT code is supposed to hang together everywhere
[20:24] <mathrick> abentley: I'm very interested in a tool that'd let me reshape changes logically for reviewers, but I sort of can't see how pipelines help with that if they're basically merges
[20:25] <mathrick> (also, take your time if you're busy right now, it's not urgent)
[20:31] <jam> mathrick: you may want to look at http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-keep.html
[20:31] <jam> which doesn't explicitly use pipelines
[20:32] <jam> though you could do something like that for the individual branches
[20:33] <mathrick> jam: yeah, I don't want to lose the history if possible, but I'd like to be able to submit a logical view of the end result. Lemme just read through that
[20:33] <jam> mathrick: it is how I did it, at least
[20:33] <jam> basically, you could use threads/pipelines for each of the new branches created
[20:34] <jam> however in *my* case, I wanted a DAG of branches, not a simple stack
[20:34] <mathrick> loom was unusable for that scenario
[20:34] <jam> though probably not critical
[20:34] <mathrick> since the threads stack in the wrong direction
[20:34] <jam> both pipelines and loom think in terms of a stack
[20:34] <jam> though you can "up-thread; bzr revert"
[20:34] <jam> or use "bzr switch" to change threads without merging
[20:35] <jam> mathrick: wrong direction?
[20:35] <mathrick> hmm, I might be mixing up two different scenarios
[20:36] <mathrick> jam: I know I hit that at least once, when I wanted to keep a change that wouldn't get pushed upstream when merging, but which'd sit on top of other changes (ie. editing config files to match your local dev setup without touching the deployed config)
[20:37] <mathrick> that doesn't work, because of how changes flow through the loom
[20:37] <mathrick> IIRC, there were also similar issues when you tried to use looms for reshaping, but I'd have to rethink that from first princinples again, I'll read your post first
[20:48] <otto_sange> help question: when I run the command $ bzr branch lp:valo-cd
[20:49] <otto_sange> I get the error:Server does not understand Bazaar network protocol 3, reconnecting.  (Upgrade the server to avoid this.)
[20:49] <otto_sange> Server does not understand Bazaar network protocol 2, reconnecting.  (Upgrade the server to avoid this.)
[20:49] <otto_sange> bzr: ERROR: Generic bzr smart protocol error: Server is not a Bazaar server: Received bad protocol version marker: "error\x01Generic bzr smart protocol error: bad request u'bzr request 2'\n"
[20:49] <jelmer> otto_sange, hi
[20:49] <otto_sange> one guy at #launchpad suggested I'd ask here. Maybe it is a locale problem.
[20:50] <maxb> What is your local bzr version?
[20:50] <otto_sange> My system: plain Ubuntu 9.10, fresh bzr installation from main, clean conf, python 2.6
[20:50] <otto_sange> Bzr version 2.0.0
[20:50] <otto_sange> system locale Finnish
[20:51] <jelmer> otto_sange: I can't reproduce the problem here - what is your locale set to?
[20:51] <otto_sange> LANG=fi_FI.UTF-8 to be specific
[20:52] <jelmer> otto_sange: It seems to work fine with that locale as well
[20:52] <otto_sange> although the locale thing is just a guess. I'd expect there would be more about this on Google if all Finnish users suffered from it..
[20:53] <otto_sange> Any other ideas?
[20:53] <otto_sange> running -v does not give any extra info
[20:53] <jelmer> otto_sange: I'm out of ideas at the moment, but spiv might have more ideas - I think he should be around soon.
[20:53] <jelmer> spiv: ^
[20:55] <maxb> jelmer: About those bzr-svn "inconsistent details in skipped record" warnings - I had a look at what the code was actually comparing and it seems to be complaining about one side of the comparison being a tuple, the other a list. Does that mean anything to you?
[20:57] <jelmer> maxb: We've had problems with that in the past as well
[20:57] <jelmer> maxb: I guess bzr is a bit more strict now in various places
[20:57] <jelmer> maxb: I'm happy to see bzr-svn adjusted to use whatever bzr uses
[20:58] <maxb> I should stick a "raise" in there and see where it explodes, I guess
[20:59] <maxb> On another matter, I don't suppose you have any magical debugging tips for figuring out why bzr-svn would go into an infinite loop trying to detect svn tags on a particular repo?
[20:59] <maxb> private, unfortunately
[21:01] <otto_sange> jelmer: I need to get some sleep now. If anybody comes up with ideas, drop me a line at otto (a) sange.fi so that I could start contributing to a Launchpad project some day... Thanks!
[21:02] <poolie> jam, hi, shall we chat?
[21:02] <jam> sure poolie
[21:02] <jelmer> otto_sange: Will do
[21:02] <jelmer> maxb: -Dtransport is usually quite helpful
[21:03] <maxb> I'll give it a go
[21:03] <jelmer> maxb: Also, SIGQUIT is your friend.
[21:03] <maxb> ah
[21:03] <jam> jelmer: I think the check needs to be less strict. We can hit that internally as well
[21:03] <jam> some apis return [] for parent_ids, some return ()
[21:03] <jam> both should be allowed
[21:03] <jam> I don't know how I've triggered it before, but I most certainly have, without bzr-svn
[21:04] <jelmer> jam: Most things seem to rely on tuples, e.g. knits will bail out if you try to add the same text twice with the parents as a list
[21:04] <maxb> ooi, what are the strings containing four numbers? -->     ('21277 252 0 333', ((),)) ('76755 252 0 333', ([],))
[21:05] <maxb> Indeed, it looks like the tuples are the "existing" and the lists the "new" in my case
[21:14] <spiv> Drat, missed otto_sange.
[21:15] <thumper> spiv: do you know?
[21:15] <thumper> spiv: I was talking to him on #launchpad
[21:15] <thumper> spiv: he did leave an email address :)
[21:18] <spiv> thumper: yeah, just sending mail now
[21:18] <spiv> thumper: but no, it's a mystery to me.
[21:18] <thumper> :(
[21:21] <maxb> Is there a document with a typical/recommended layout for working with a shared repository, multiple branches, and a lightweight checkout?
[21:22] <rubbs> maxb: I don't think there is a document for that, but I'd say you could do this:
[21:22] <rubbs> ./shared_repo/
[21:23] <rubbs>             /branches/
[21:23] <rubbs>                        /branch_a/
[21:23] <rubbs>                       /branch_b/
[21:23] <rubbs>             /lw_co/
[21:23] <rubbs> just an idea
[21:27] <maxb> I'll practice a bit :-)
[21:49] <spiv> rubbs, maxb: probably more common is ./repo/branch_{a,b,...} for the branches, and ./work (outside the repo) for the checkout.
[21:49] <lifeless> I do
[21:49] <spiv> rubbs, maxb: that said, it'll just as well either way.
[21:49] <rubbs> ah, that's a good point
[21:49] <lifeless> ./project/branches
[21:49] <spiv> s/it'll/it'll work/
[21:49] <lifeless> ./project/working
[21:49] <maxb> ah... a good point, it had not occurred to me that it could be outside.
[21:50] <lifeless> e.g. bzr/trunk, bzr/foo bzr/bar bzr/working
[21:50] <lifeless> and working is a lw checkout of e.g. trunk
[22:03] <mathrick> okay, so empirically, it seems that pipelines work sorta backwards if you want to use them to reshape changes: earlier pipes in the pipeline will have the logical view, whereas the last one will have the original changes
[22:15] <jam> abentley: the way the code is written, if you add a new root but do *not* delete the old root, things still work (fixup_new_roots always removes the old root if there are any new ones.)
[22:15] <jam> should I add a check that self._new_root in self._removed_content ?
[22:18]  * mkanat is working on the final touches of the CVS->bzr migration for upstream Bugzilla, for the next few days.
[22:19] <mathrick> jam: hmm, interesting post that, but what does submit: really mean in those branches?
[22:19] <mathrick> more generally, how can I find out what branch is submit: for the given tree?
[22:19] <jam> mathrick: Are you talking about the blog post?
[22:19] <mathrick> yep
[22:20] <jam> At *this* point, I would make submit: be the dev branch, and use launchpad's "this change depends on this other branch"
[22:20] <jam> at the time I did that code
[22:20] <jam> that feature was not present
[22:20] <mkanat> mwhudson: Going to start on the loggerhead stuff today! :-)
[22:20] <mathrick> jam: æh, I don't understand what you're talking about :)
[22:20] <jam> mathrick: the submit branch is always 'trunk'
[22:20] <jam> IMO
[22:20] <mwhudson> mkanat: woo
[22:21] <jam> it just happens that one branch depends on another landing to get a nice diff of the changes
[22:21] <mathrick> jam: and if I don't set it up specially, what becomes submit? And how can I check what is submit at any given point?
[22:21] <jam> mathrick: bzr info submit: ?
[22:21] <mathrick> ahh
[22:22] <mathrick> right
[22:22] <jam> I set up a default submit in locations.conf
[22:26] <lifeless> moin
[22:27] <jam> morning lifeless, I hope you're feeling better
[22:28] <lifeless> over the worst I think; coughed up lots of plugins w/some blood and can now breath properly ;)
[22:28] <lifeless> no fever today
[22:29] <lifeless> s/in//
[22:29] <lifeless> jam: you might like testrepository
[22:29] <lifeless> jam: it should be windows friendly
[22:29] <jam> lifeless: I saw your post, looked interesting
[22:30] <ChrisMorgan> bzr co http://code.djangoproject.com/svn/django/trunk/ django-trunk is failing (yes, I've installed bzr-svn, and got it working on another repository) :-(
[22:31] <ChrisMorgan> It asks for username and password, which I leave blank, and then says 'bzr: ERROR: Not a branch: "http://code.djangoproject.com/svn/django/trunk/".'
[22:31] <ChrisMorgan> replacing bzr with svn makes it work fine
[22:44] <mkanat> Is there a way to enforce, on the repo/branch side, that nobody can check in without setting whoami?
[22:50] <lifeless> use bzr+ssh:, and write a plugin that hooks branch pre_tip_change that checks for e.g. localhost in the host part of the author of new tips
[22:52] <mkanat> lifeless: Awesome, thanks.
[22:52] <mkanat> http://bzr.mozilla.org/
[22:52] <mkanat> Nothing really in there yet, though.
[22:53] <mkanat> lifeless: For something better than that, is there a way to make sure that committer is actually the person committing?
[22:53] <mkanat> lifeless: The SSH accounts are email addresses, if that helps....
[22:54] <lifeless> mkanat: sure, ssh sets an env variable or whatever
[22:54] <lifeless> cross check that
[22:54] <mkanat> lifeless: Right, great idea. Thanks. :-)
[22:55] <lifeless> you can raise TipChangeRejected (or anything if you want) to signal the error - TCR gets tunnelled nicely though.
[22:55] <mkanat> Cool.
[22:55]  * mkanat has never written a plugin, so this will be new territory.
[23:01] <abentley> jam: That sounds reasonable.
[23:53] <poolie> hi abentley
[23:53] <poolie> hi spiv?
[23:53] <abentley> poolie: hi
[23:53] <poolie> ChrisMorgan: please open a bug and paste the number here
[23:54] <ChrisMorgan> In bzr-svn?


[15:54] <ioria> hi....  having issues booting 4.4.0-83-generic  with nouveau ...  any pointing ? (booting in text modes stops witha kernel panic)
[17:24] <alinefm> Hi all, Does anyone know when kernel will be updated to 4.11 on Ubuntu 17.10 ?
[17:53] <apw> alinefm, likely early next week now
[17:57] <alinefm> apw, thanks


[04:06] <drab> anybody got any suggestion why testing with fio reads would come back slower than writes?
[04:06] <drab> using O_DIRECT, no BBU caches, "simple" nvme device
[04:15] <patdk-lap> hmm, flash tends to buffer writes
[04:26] <average_guy> where are the commands you enter stored? so when you hit up they reappear
[04:27] <drab> patdk-lap: mmmh, that could be, however I had a spare one of these nvme and put it into a machine that's slower/worse than the server I was testing on and the gap doesn't show
[04:28] <drab> so it's something on this paricular machine that's causing the reads to be 2/3 slower
[04:28] <drab> I'm testing with fio using a test script so that's consistent on the machines with the same nvme device and same pcie adapter in a x16 slot
[04:28] <drab> even more interesting, I found out that's really concurrency killing it
[04:29] <drab> if I run fio with 1 job, the newer server obliterates the others and reads are 2x writes almost
[04:30] <drab> but if I just up jobs from 1 to 4 booom, reads crawl from 2.7GMps down to 200MBps
[04:31] <drab> writes also slow down, but of only a "few" hundred MBs, staying about 700 or so, which is btw what the manufacturer spec'ed this for, so that's cool
[04:37] <drab> if I didn't have the other system to compare to I'd agree, since flash is indeed caching and this paricularly one has a nice SLC cache before writing to TLC Nands
[04:38] <drab> so maybe the real issue here is that concurrency simply kills performances on this box period but doesn't on another fo reasons I dont get (same ubuntu xenial with same kernel)
[07:40] <vamadir> I buy vps server with ubuntu. And now i have 2 process GETTY, i think its server provider connet(some reboot etc...) from web panel. But i want delete this, its will be ok?
[07:40] <vamadir> i need only ssh
[08:01] <lordievader> Good morning
[09:48] <jamespage> rbasak, around? I have a query re the current inflight ceph sru's
[10:37] <m1dnight_> Anyone here have experience with msmtp?
[10:41] <m1dnight_> msmtp keeps setting my from address to "default", while I have clearly configured the from to be<EMAIL_ADDRESS> Sender address rejected: need fully-qualified address
[11:18] <jamespage> rbasak, nm I figured it out - the tag was not quite 'verification-done' - doh!
[14:01] <frickler> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1587886 is still affecting me on Xenial it seems (when running neutron-vpnaas), is there a chance to backport the fix? or get the version from zesty into UCA?
[14:10] <cpaelzer> hi frickler, let me take a look
[14:10]  * cpaelzer has no ECC-memory in his brain :-/
[14:12] <cpaelzer> frickler: are you the Dr. that did the last update a few minutes ago on  the bug?
[15:25] <frickler> cpaelzer: yes. and neutron does use the plain xenial package indeed
[15:28] <cpaelzer> frickler: ok, since I have no good local repro I have provided a ppa with the fix backported to Xenial
[15:28] <cpaelzer> frickler: it is currently in some more testing, but if you could verify it solves it for you that would be great
[15:29] <cpaelzer> frickler: if it does comment on the bug please (I did so announcing the ppa)
[15:30] <cpaelzer> frickler: also if you could provide a short "Test Case" section for https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template that would be great as well
[15:30] <cpaelzer> frickler: I'm good adding the rest
[15:31] <frickler> cpaelzer: sure, thx
[15:54] <frickler> cpaelzer: so the fix works, minor issue: updating only strongswan itself doesn't pull in the updated other packages automatically, needed to update strongswan-charon and -starter explicitly
[15:55] <frickler> cpaelzer: I'll try to find a simpler test case than install OpenStack with certain settings and configure a VPN link now
[15:57] <cpaelzer> thanks
[17:26] <genii> drab: Did you make any headway on the preseed file?
[17:42] <matsaman> just installed 12.04.5 as a virtualbox guest, and it seems like trying to apt-get install anything throws 'no installation candidate'
[17:45] <nacc> matsaman: did you run `apt-get update` first?
[17:46] <matsaman> I've run that, yes
[17:47] <nacc> matsaman: can you pastebin that output, and then an example `apt-get install ...` output?
[17:50] <matsaman> looks like https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1430648
[17:51] <matsaman> I'm doing an update, upgrade, & dist-upgrade now
[17:51] <matsaman> I'm assuming this is because I opted out of automatic updates at install time
[17:52] <matsaman> which is a habit I've developed because that has, IME, _increased_ the likelihood of the installer failing
[17:52] <matsaman> the irony, there is no escape
[17:52] <nacc> matsaman: :)
[17:53] <matsaman> as if I'd be installing 12 if I wanted updates anyway! heh
[17:53] <zul> cpaelzer/coreycb: im not able to reproduce http://paste.ubuntu.com/23949041/
[17:58]  * matsaman sighs
[17:58] <matsaman> no improvement
[18:02] <zul> coreycb: rc1 incoming
[18:02] <matsaman> oh thank heaven
[18:02] <matsaman> fixed with http://askubuntu.com/questions/297757/why-after-fresh-ubuntu-12-04-installation-update-arent-being-installed#answer-300930
[18:27] <drab> genii: no, I got stcuk with another nasty issue, trying to debug some nvme device that's giving out seemingly random performances...
[18:28] <drab> also trying to reconcile dd with fio... I thought if I ran fio with 1 job same filesize same block value I would get the similar readings, but nope
[18:28] <drab> fio's value are way way lower for whatever reason I don't get (in a reading O_DIRECT should play no role and a sync and flush buffers before running dd)
[19:32] <sarnold> drab: what exact dd commandline are you using?
[19:45] <blueking> I have samba share  on mine ubuntu server.. but workgroup/ubuntu server aren't visible on my lan, tho I could connect to mine samba share as it was configured before... changes I've made  added two more nic, made those two nic into one  interface name bond0  interface that samba share was on before are disabled..  I've changed smb.conf    I need to change somewhere else too ?
[19:50] <sarnold> blueking: check samba logs, maybe it's telling you the error..
[19:50] <blueking> ok
[19:57] <blueking> how long time should it take to have devices visible at explorer  networked devices visible 'WORKGROUP' as an example..
[19:59] <sarnold> try using smbclient directly without trying to browse
[20:00] <sarnold> browsing is handled by a different protocol, and it may not be indicative of the success or failure of the sharing protocol
[20:04] <blueking> but samba share works from old setup.. I could access it from mine windows pc
[20:06] <sarnold> when troubleshooting it's worth trying to break big problems into small problems and then solve them one at a time, from the most basic upwards
[20:06] <sarnold> you know how it goes, starting with "is it plugged in and turned on?", "is the network cable plugged in?", "are there link lights on both the NIC and the switch?" and onwards and upwards :)
[20:07] <sarnold> bonding makes things a bit more complicated since I don't know how to e.g. check if the machine's responding to arps correctly; but you could test ping and ssh inbound and outbound and make sure that the machine still has networking at all
[20:07] <sarnold> and if it appears to have networking still, then you can focus on the two protocols in windows sharing -- the sharing bit (smb) and the browsing bit (nmb)
[20:09] <sarnold> bonding makes things a bit more complicated since I don't know how to e.g. check if the machine's responding to arps correctly; but you could test ping and ssh inbound and outbound and make sure that the machine still has networking at all
[20:09] <sarnold> and if it appears to have networking still, then you can focus on the two protocols in windows sharing -- the sharing bit (smb) and the browsing bit (nmb)
[21:08] <ikonia> win 10
[21:08] <ikonia> oops
[21:09] <compdoc> wot?!   ban!
[21:39] <powersj> nacc: can you import dlm for jgrimm and I?
[21:40] <nacc> powersj: running now
[21:41] <powersj> nacc: great thx!
[21:44] <nacc> powersj: of course, should be done soon
[21:44] <nacc> powersj: done
[22:25] <powersj> nacc: thanks again
[22:35] <nacc> powersj: np!
[23:13] <drab> sarnold: to write I'm testing with dd of=/dev/nvme0n1 if=/dev/zero count=10000 bs=128K conv=fdatasync,notrunc oflag=direct
[23:13] <drab> sarnold: for reading sudo dd if=/dev/nvme0n1 of=/dev/null count=10000 bs=128K
[23:13] <genii> drab: What kind of drive is it?
[23:14] <genii> ( the EVO apparently have some issue)
[23:14] <sarnold> drab: good good
[23:15] <drab> genii: http://mydigitalssd.com/pcie-m2-ngff-ssd.php
[23:15] <sarnold> drab: the downside of course is that now I'm out of suggestions why the two would have different values :)
[23:15] <drab> sarnold: :)
[23:15] <sarnold> drab: if fio were -faster- that'd make loads of sense, I could say "oh it's probably doing multiple requests"
[23:16] <sarnold> but fio is slower and I'm 99% sure dd isn't going to be submitting multiple IO requests :/
[23:16] <drab> yeah, that's also what I don't get...
[23:16] <sarnold> drab: maybe capture .1s of strace output? I'm curious what the write patterns are for both
[23:17] <drab> the other thing is that results are inconsistent... sometimes I get lots of context switches and low tput, sometimes high tput and pretty high ctx, other times high tput and low ctx
[23:17] <drab> these are test servers doing nothing other than being hammered with fio, so I don't get why the huge flactuation in ctx
[23:17] <drab> but it's the only thing I can see diff besides the speeds
[23:17] <drab> (in fio output)
[23:19] <drab> it might be the hw, but blaming it on the hw isn't a great solution... we're a non profit and money is tight, trying to get some older drives to behave by putting a decent cache in front of them
[23:19] <drab> and this seemed like a very good option, low price, good perfs, really good reviews on tomshardware & a few other places
[23:19] <drab> it's not top of the line, but plenty for us
[23:20] <drab> except that I just can't get consistent numbers no matter what
[23:20] <sarnold> drab: ohhhhhhh
[23:21] <drab> what, you solved it? :)
[23:21] <sarnold> drab: my new theory -- the drive's firmware is compressing the hell out of a string of zeros. it's writing almost nothing most of the time.
[23:21] <sarnold> drab: probably fio knows about this and is sending uncompressable blocks to the disk to write.
[23:22] <genii> According to the webpage for the drive, it does have some fancy firmware
[23:22] <drab> sarnold: that's an interesting thought, I might try to find a way to test around it
[23:23] <drab> thank you
[23:23] <drab> I'm still left with the problem of inconsistent tests tho
[23:23] <sarnold> yeah :/
[23:23] <drab> I've had maybe 3 or 4 times in a row fio giving me back 1.5GBs reads
[23:24] <drab> and then seen those plummet to 700MBps
[23:24] <drab> and no way to get them back up, not even with a reboot, nothing
[23:24] <sarnold> I started by looking at the page to see if they mentioned how much overprovisioned space they had, in the hopes that that might help dictate just how much garbage compaction it might do, and -that- is what kicked off the neuron that remembered that most flash firmwares try hard to reduce writes..
[23:24] <sarnold> OUCH
[23:24] <sarnold> that's one heck of a penalty once you hit it
[23:25] <drab> then at some point I tried to write a 10GB file as a test, and got 1.5GPBs again...
[23:26] <drab> and that is stable on one test machine, meaning I keep getting 1.5GBPs, but I can never get that speed on a 1GB file sample, needs to be at least 3GB to get close to 1GBps
[23:26] <drab> on the other machine however going back and forth with 10GB makes no diff, it's "stuck" at 700MBps
[23:26] <sarnold> where is your 1gig file coming -from-?
[23:26] <drab> I have no idea how fio gens that
[23:27] <sarnold> unless it was already stuffed in RAM you might be testing the read speed of the drive holding it, or the throughput of the pcie bus that's got the devices..
[23:27] <drab> I guess I might look into that since I'm out of options
[23:27] <sarnold> probably fio does the right thing and generates a megabyte or two of uncompressable data at startup and just re-uses it
[23:28] <sarnold> though that might encourage folks to do de-dup. so maybe they'd have light-weight modifications in place too..
[23:38] <powersj> nacc: finished dlm merge
[23:38] <powersj> set you as the reviewer so you can judge how well jgrimm taught me ;)
[23:39] <jgrimm> ha! nice
[23:40] <nacc> powersj: thanks, will probably get to it tmrw
[23:41] <sarnold> drab: what kind of drives will you be putting behind this nvme? even 700MBps is way faster than spinning metal drives, maybe the odd performance bumps might not matter in the end
[23:41] <sarnold> drab: I'm curious what the cause is, but at some point it might not really matter
[23:46] <JoseLuis_> Good afternoon
[23:49] <jgrimm> nacc, i am curious why dlm wasn't auto-updated by the importer?
[23:49] <jgrimm> powersj, ^^
[23:49] <nacc> jgrimm: how do you mean?
[23:50] <jgrimm> since it had been imported before.. i thought it would be kept fresh when newer debian available
[23:50] <JoseLuis_> Does anyone know those files ( /usr/bin/xjrcsubbir and /etc/init.d/xjrcsubbir) ? is running in my server ubuntu Ubuntu 16.04.1 LTS
[23:50] <nacc> jgrimm: it will be updated when a new publish is seen in launchpad
[23:50] <nacc> jgrimm: relative to when the importer itself last ran
[23:52] <sarnold> JoseLuis_: I've never seen it. my archive mirror doesn't have anything like it.
[23:53] <sarnold> and just as troubling, google reports "Your search - xjrcsubbir - did not match any documents"
[23:53] <JoseLuis_> thanks sarnold, my server is running in in linode.com
[23:53] <jgrimm> nacc, how is that useful?
[23:54] <nacc> jgrimm: sorry?
[23:54] <nacc> jgrimm: maybe we can discuss this in our 1x1
[23:54] <sarnold> JoseLuis_: -maybe- it's something they built but even so I'd expect to find some reference to it somewhere on the internet.
[23:54] <sarnold> JoseLuis_: try asking in #linode on irc.oftc.net
[23:54] <jgrimm> nacc, yep! all good. not urgent in the slightest. :)
[23:54] <JoseLuis_> thanks sarnold
[23:55] <JoseLuis_> Does anyone know those files ( /usr/bin/xjrcsubbir and /etc/init.d/xjrcsubbir) ? is running in my server Ubuntu 16.04.1 LTS on linode.com
[23:56] <JoseLuis_> mistake!!


[07:38] <smb> Morning +*
[07:39] <diwic> morning pqr s/p/s s/q/m /s/r/b
[07:39] <diwic> hmm, that will actually replace the r in morning as well
[07:40] <diwic> smb, anyway, I'm tracing down a 3.0 regression for a few HDAs and I believe I found the upstream commit that resolves the problem, but that patch is quite large.
[07:41] <diwic> smb, would you prefer a large upstream patch or something smaller that I crafted myself?
[07:42] <smb> diwic, From the point of view of a stable maintainer probably rather something crafted with the note why that was done.
[07:43] <smb> It is just better to decide what something does that way. It is a bit of a gap between rather preferring upstream vs. I can understand it...
[07:44] <diwic> smb, in this case I tend to agree
[07:44] <diwic> smb, you can search for commit 3af9ee6b83 for reference
[07:45] <diwic> should be in 3.1
[07:47] <smb> diwic, Hm, yeah. Most of it looks not too bad actually. But the whole block in alc662_auto_fill_dac_nids looks a bit scary at least on the first glance
[07:48] <diwic> smb, yeah, it's mainly the stuff in alc_auto_look_for_dac I need here
[07:51] <diwic> smb, hmm, and actually that stuff is yet again rewritten in a later commit
[07:51] <diwic> smb, better craft something then probably
[07:54] <smb> diwic, It is always some tough decision. There have been bigger changes accepted in the past. Just then be prepared to get asked how well this was tested. It may make sense if you can say, there was just no other way to get this done and I did test it at least on the variety of hw I got that is affected.
[07:55] <smb> Unfortunately when larger changes were done, they usually _had_ some hidden pitfalls in certain cases in them as well. Which tends to lower the acceptance of big chances again.
[07:58] <diwic> smb, yeah, and tbh I'm a little afraid that would happen if we applied 3af9ee as is
[08:00] <smb> diwic, If even you are afraid, that is a bad sign. :)
[08:22] <jjohansen> gah! so I bisected my video problem, found the patch that broke it but, reverting it in newer kernels doesn't restore my display :(
[08:22] <jjohansen> just my luck
[08:23] <smb> Sounds like one of those days
[08:26] <jjohansen> yeah
[09:05] <smb> jjohansen, Still around?
[09:05] <jjohansen> yep
[09:06] <jjohansen> smb: ?
[09:06] <smb> jjohansen, I wonder whether you could have a peek at that sru Tim sent around (about igb). I have that is-the-stove-really-out nagging feeling about spinlock without any diabling
[09:07] <smb> If someone else would review and say it looks okish I just would ack it as well
[09:07] <jjohansen> smb: sure
[09:14] <jjohansen> urg, this is when I wish for my big monitor so I can run two instances of meld side by side
[09:18] <jjohansen> smb: your right about the is-the-stove-really-out nagging feeling, I have it too.  I have the original up and this and am doing a full on proper comparison
[09:19] <jjohansen> and eval
[09:20] <smb> jjohansen, Ah ok. Yeah, somehow it feels to me that at least a spinlock_bh variant may be required
[09:20] <jjohansen> hrmmm, that is a frightening thought :)
[09:21] <smb> But its just that uneasy feeling I usually have about not turning off anything. Somehow I converted to use spinlock alone only if I had nesting... But that is maybe just overcautious
[09:21]  * jjohansen wishes the original patch hadn't crammed 4 or 5 different things into it
[09:22] <jjohansen> of course but being overcautious is safe
[09:24] <smb> Exactly. Rather be safe than sorry and in the bug report I think was a version with irqsave and restore which has been dropped because the original patch did not use it. Though the original patch completely changed things...
[09:24] <jjohansen> well I am not so worried about what is done in the original patch as patches around it
[09:25] <jjohansen> the original didn't change things enough in the locking sense for that worry
[09:29] <smb> In that case I did not look that much on what was done upstream (taking the statement about it being complicated and not all needed to get the gist of what is needed). Mostly what is done looks ok (make the update happen all the time and lock on the callers). And also most callers seem to be things that are triggered from userspace only. Just the watchdog function I am not sure. And whether it may interrupt a caller from user-space in an unfor
[09:29] <smb> tunate way
[09:31] <smb> Still I did not want to get that patch forgotten just because I am a code worrier... :-P
[09:39] <jjohansen> smb: heh no worries, we will get it taken care of
[10:17] <jjohansen> smb: so this I am less than thrilled with the patch
[10:18] <smb> jjohansen, Oh, ok. So what are your worries there?
[10:19] <smb> (actually if you could just reply in the thread, then you'd have to type it only once..)
[10:19] <jjohansen> smb: in the context of locking _bh, or irq I think it is okay, but I am not entirely convinced the locking is doing much good
[10:20] <jjohansen> smb: basically, it does prevent similtaneous writers, but it does nothing for readers
[10:20] <smb> jjohansen, Ah, ok... Hm, missed that aspect then
[10:22] <jjohansen> smb: look at igb_get_stats in igb_main.c
[10:22] <smb> jjohansen, Probably did not look into all accesses. At least the hunks seemed to change read (in those cases) into a write (update)
[10:22] <jjohansen> in the original patch a copy is made after the update and the copy is what is returned to the readers
[10:22] <jjohansen> so they have a private copy
[10:22] <jjohansen> a snapshot
[10:23] <jjohansen> here we are returning the live structure
[10:23] <jjohansen> now the question is do we care?
[10:24] <jjohansen> the locking seems to have been mostly added for 64bit accesses on 32bit machines
[10:24] <smb> Hm, doing the snapshot ensures that the stats are coherent. I guess updates just happening more often would not be completely what is desired...
[10:24] <jjohansen> so right now I am trying to figure out if we care
[10:25] <jjohansen> if its only for consistency across 64 bit stats then we may not care
[10:25] <jjohansen> if its for snapshot consistency we do
[10:25] <smb> Well otoh locking sounds reasonable just because now there may be two readers causing parallel updates, won't they?
[10:26] <jjohansen> possibly, the writers certainly need locking of some form
[10:26] <jjohansen> but I am not familiar enough with the code to say if multiple writers can occur at that point
[10:26] <jjohansen> but the locking won't hurt
[10:27] <smb> iirc it was changing the code so reading the stats for example with ethtool woul update them at that time
[10:27] <smb> And I guess at least in theory that could happen in parallel
[10:27] <jjohansen> it really comes down to the readers
[10:28] <jjohansen> right
[10:28] <jjohansen> I think the writers can be parallel, I am just not positive
[10:28] <jjohansen> so, I good with the locking on the writer side
[10:29] <jjohansen> its the readers I am trying to figure
[10:29]  * jjohansen really wishes the original patch had been split up
[10:29] <smb> Ok, let me have a look at this again in meld...
[10:32] <smb> wtf
[10:32] <smb> I am not sure why I care... There was a code warrior putting that into master-next already it seems...
[10:33] <jjohansen> o_O
[10:36] <smb> jjohansen, Just questioning my sanity: do you see it too?
[10:37] <jjohansen> hrmm, let me pull and see
[10:39] <jjohansen> ah gah my linux-next tree hasn't been updated to git hub
[10:41] <smb> oops
[10:50]  * smb -> lunch
[11:02] <jjohansen> smb: so I don't believe we care.  We aren't updating 64 bit values, and I don't see a reason for rx and tx stats to be a snapshot, that is if rx gets incremented while read tx it doesn't really matter
[11:04] <smb> jjohansen, Ah ok, so basically the net stats are not really verifyable the first place. If its only rx / tx then surely they are ok as long as the value itself is consistent
[11:04] <smb> Would be different when there was something like irqs as well which would or would not be consistent with rx or tx
[11:05] <jjohansen> well its a little more than rx or tx look in include/linux/netdevice.h for net_device_stats
[11:06] <jjohansen> eg you could get rx_bytes and rx_packets to be from different snapshots
[11:07] <jjohansen> but the lack of consistency there is a very minor problem
[11:07] <smb> Yeah, and probably was there before...
[11:07] <jjohansen> yep
[12:22] <mterry> ogasawara, hello!  I'm just pinging you to make bug 849564 more visible.  :)  Very reproducable and pretty annoying regression.  I'd be glad to help test kernels
[12:22] <ubot2> Launchpad bug 849564 in linux "System76 Lemur: Does not suspend on second attempt" [Undecided,Confirmed] https://launchpad.net/bugs/849564
[12:24] <apw> jjohansen, tyler hicks is the ecryptsfs man right ?
[12:25] <jjohansen> yep
[12:25] <jjohansen> I keep meaning to sit down with him but haven't yet
[12:27] <apw> jjohansen, heard any reports about encrypted swap corrupting stuff ?
[12:27]  * smb <- back
[12:27] <apw> https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/745836
[12:27] <ubot2> Ubuntu bug 745836 in ecryptfs-utils "ecryptfs encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed]
[12:27] <apw> smb, ^^ you may be interested in the bottom of this
[12:27] <apw> i assume swap actually is actually dmcrypt
[12:27] <kirkland> wow
[12:27] <jjohansen> apw: no
[12:28] <kirkland> apw: so swap is not encrypted using ecryptfs
[12:28] <kirkland> apw: it's just dmcrypt
[12:28] <smb> apw, Thought you were the bottom man... :-P
[12:28]  * smb looking
[12:28] <apw> right ... i assume the users are confused
[12:28] <kirkland> apw: ecryptfs-setup-swap sets it up
[12:29] <kirkland> apw: you assume correctly, I think :-)
[12:30] <apw> smb, would you have time to poke this nest of worms ?
[12:31] <smb> apw, Not sure I really want to...
[12:31] <apw> jjohansen, if you do talk to tyler, tell him that people are reporting that the 'crap at the end of ecryptsfs files' bug is being reported not fixed even where the fixes are applied
[12:31] <apw> smb, heh now that i can understand :/
[12:31] <apw> smb, i could swap you for working out why we have power problems if you like
[12:32] <jjohansen> apw: yeah, that is weird
[12:32] <smb> apw, I probably take the other land-mine then I guess
[12:33] <smb> apw, At least things exploding is more realistic
[12:37] <apw> smb, it sounds like they have a reproduce by in a vm if you scroll back a few comments
[12:38] <smb> Yeah. Will try the receipe and see what I get
[13:04] <Sweetshark> apw, smb: Hi there.
[13:05] <smb> Sweetshark, Hi, just reading through that bug
[13:05]  * Sweetshark is Bjoern Michaelsen. And yes, it seemed to be quite reproducable in the end.
[13:06]  * smb Realized
[13:06] <smb> Sweetshark, How small was the smal RAM?
[13:07] <smb> 512M?
[13:07]  * apw is suprised LO would start at all in that
[13:08] <Sweetshark> smb: 512MB was enough here.
[13:08] <apw> Sweetshark, was it reproducible on oneiric ?
[13:09] <Sweetshark> and then open Firefox, imagesearch for large images and open 20 in tabs to make him swap. (Unless you kernelguys have something less pragmatic).
[13:09] <Sweetshark> apw: Havent tried yet. I just got it reproducable today.
[13:09]  * jjohansen -> waves good night
[13:09] <smb> jjohansen, night
[13:09] <apw> Sweetshark, heh i think i'd probabally just boot the VM with less ram :)
[13:10] <apw> jjohansen, no bed bugs ....
[13:10] <smb> Also got some program done by someone to eat memory... Would try that too
[13:34] <Sweetshark> as for this affecting oneiric: it is highly likely as there are stacktraces for it: bug 854197 for example
[13:34] <ubot2> Launchpad bug 854197 in libreoffice "soffice.bin crashed with SIGSEGV in QPaintEngine::drawImage() (dup-of: 745836)" [Undecided,Incomplete] https://launchpad.net/bugs/854197
[13:34] <ubot2> Launchpad bug 745836 in ecryptfs-utils "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed] https://launchpad.net/bugs/745836
[13:35] <Sweetshark> or bug 801592 (which is closer to the original "cppu::throwException" stacktrace.)
[13:36] <Sweetshark> arggh, pasted the wrong bugs.
[13:38]  * Sweetshark better tries himself.
[13:41] <smb> Sweetshark, I think at least the initial report of that was 32bit. Since you already spent quite a time with those, were there 64bit cases as well?
[13:43] <Sweetshark> smb: yes.
[13:43] <Sweetshark> smb: Actually I personally reproduced on natty 64-Bit.
[13:44] <smb> Ah good. So that does not matter
[14:16]  * ogasawara back in 20
[14:19] <tyhicks> apw, kirkland, Sweetshark: I looked into bug 745836 last night and have a gut feeling that it is an inode race condition that I fixed recently. I haven't had a chance to update the bug with my findings yet.
[14:19] <ubot2> Launchpad bug 745836 in ecryptfs-utils "encrypted swap corrupts application stack/heap [was: soffice.bin SIGSEGV cppu::throwException()]" [Critical,Confirmed] https://launchpad.net/bugs/745836
[14:20] <tyhicks> I started to backport the patches last night but ran out of steam
[14:20] <tyhicks> I think I've just got one left to do
[14:21] <smb> tyhicks, Just wondering, if it is encrypted home/swap it is dm-crypt no ecryptfs...
[14:21] <apw> tyhicks, though they claim near the bottom that removing ecryptfs from the equasion and the problem is still there
[14:22]  * tyhicks missed that
[14:22] <apw> tyhicks, Sweetshark it was you who claimed to have tested with just dmcrypt swap and normal home right ?
[14:23] <tyhicks> I can reproduce this easily in my vm... let me give it a shot on an unencrypted home
[14:23] <apw> tyhicks, thanks
[14:24] <smb> tyhicks, or just replace the swap by an unencrypted one
[14:35] <tyhicks> apw smb: I couldn't reproduce it with encrypted swap and unencrypted home
[14:35] <tyhicks> smb: you wanted me to test unencrypted home with unencrypted swap?
[14:37] <smb> tyhicks, Interesting, in the bug report it is claimed with encrypted home and without encrypted swap it cannot be reproduced either...
[14:37] <smb> tyhicks, I am still installing a vm, so if you want to go for a try, sure
[14:37] <tyhicks> smb: I'm thinking that this is the eCryptfs inode race condition that I fixed upstream recently
[14:38] <tyhicks> smb: encrypted swap could add just enough latency into everything that the race condition exposes itself more often
[14:38] <smb> Ah, that may well be
[14:39] <smb> tyhicks, So since you were already quite close to have the patches ready (and probably a test kernel too), I think the best approch would be to give those a try first
[14:44] <tyhicks> smb: Ah, I just noticed that the fixes I had started backporting are already in oneiric
[14:46] <tyhicks> smb: Sweetshark says that it is highly likely that oneiric is affected, too, but I'm not seeing any reports against oneiric
[14:46] <smb> tyhicks, Sweetshark thought there were bug reports for oneiric too. But then said something about wrong ones and I am not sure with what kernel version those would have been opened anyway
[14:47] <Sweetshark> smb: I just got a vanilla oneiric beta2 vm ready. Trying to reproduce.
[14:48] <tyhicks> Sweetshark: great - that would give me a good idea about whether or not this patchset I'm backporting is going to fix it
[14:48] <smb> Sweetshark, tyhicks Can I let the two of you check into this. It feels like tyhicks has the best lead for the fix anyways
[14:48] <tyhicks> smb: works for me
[14:49] <tyhicks> smb: if I determine that eCryptfs is not at fault, I'll let you nkow
[14:49] <smb> Thanks a bunch. Yes, sounds good
[14:49]  * apw idly notes that 'thanks a bunch' is normally negative
[14:50] <smb> oops
[14:50]  * smb meant it the positive way
[14:50] <apw> thanks a lot! is normally possiblem t
[14:50] <apw> possible, thanks a lot.  is often not :)
[14:50] <apw> isn't english great
[14:51]  * smb probably has to live with every second word he says is an insult, about drinking or sex without knowing
[14:55] <Sweetshark> tyhicks: NOT reporoducable in oneiric beta2 with encrypted home and swap (or at least not easily reproducable).
[14:56] <tyhicks> Sweetshark: woohoo... I think I might be on the right rack
[14:56] <tyhicks> s/rack/track/
[14:56] <tyhicks> Sweetshark: thank you!
[14:58] <Sweetshark> of course tests cant prove the absense of bugs ;)
[15:04] <tyhicks> Oh, I should probably get some quick confirmation on the natty kernel source that I'm using (I've never worked directly on an ubuntu kernel before now)
[15:05] <tyhicks> Is the master branch of git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git what I should be backporting against?
[15:07] <tgardner> tyhicks, either master or master-next
[15:08] <tgardner> master-next is the branch we'll actually apply the SRU patch agains
[15:12] <Sweetshark> tyhicks: what are the chances that Libreoffice itself is at fault here? I assumed pretty slim and closed as invalid. Since you have a idea what the root cause it do you agree that this is valid to assume?
[15:17] <tyhicks> Sweetshark: Tough to say just yet
[15:17] <Sweetshark> tyhicks: k
[15:18] <Sweetshark> well, if you find anything fishy from LO on this please reopen on libreoffice.
[15:18] <tyhicks> Sweetshark: at first glance, my reaction was "Oh, eCryptfs is doing something non-POSIX-like and libreoffice should maybe handle that better" but then as I looked into it more, I got the feeling that eCryptfs is at fault
[15:19] <Sweetshark> tyhicks: k thx
[15:20] <apw> ogasawara, the binary package is: linux-image-extra-3.0.0-9-virtual
[15:20] <apw> as an example from my test builds
[15:20] <ogasawara> apw: cool, was just about to check
[15:20] <ogasawara> apw: so we're fine there
[15:20] <apw> the theory behind the packaging changes is that you could pick any subset as a separate package
[15:21] <apw> so you could pull out staging for example
[15:21] <apw> though we don't do it
[15:21] <apw> bug #818177
[15:21] <ubot2> Launchpad bug 818177 in udev "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
[15:32]  * smb drops off
[15:49] <sforshee> mjg59, do you know of any way to get a trace of the AML method calls being made by a driver under Windows?
[15:49] <mjg59> sforshee: Nope
[15:49] <sforshee> rats
[16:44] <cking> sforshee, ask alexhung
[16:46] <cking> mjg59, nice response to microsoft's fluff
[16:47] <mjg59> cking: Thanks!
[16:47] <sforshee> cking, already have, but I'm exploring a couple of alternate avenues
[16:47] <cking> I'm glad it's getting a whole load of attention
[16:48] <cking> sforshee, pity you can't slap in systemtap eh?
[16:48] <sforshee> cking, I found some kind of sample for tracing ioctls (which is how AML methods appear to be invoked on windows)
[16:48] <sforshee> heh
[16:49] <sforshee> cking, windows also seems to have support for something called filter drivers, which I think can be placed transparently between a driver and the hardware
[16:49] <cking> sforshee, that's interesting to know, so is the windbg approach a dead end?
[16:50] <sforshee> cking, it looked like it required some special hardware, so I'm looking at software-only solutions first
[16:51] <cking> sforshee, you could hack out the DSTD, put in some extra AML to do port 0x80 writes and then boot the machine with BITS to pre-load the tables into memory - and then chain boot Windows.
[16:51] <cking> you need a port 0x80 debug card ;-) and patience
[16:52] <cking> oh, SIGCHILD, gotta to attend my kids..
[16:52] <sforshee> cking, that's an interesting idea, but these are netbooks so installing a port 0x80 debug card is going to be problematic :)
[16:52] <cking> sforshee, yep, I've always found they don't work well
[16:53] <cking> the mini PCI-e one's have never worked for me
[16:53] <mjg59> sforshee: Alternative is to figure out where ACPI debug statements go on Windows and fill the AML with a pile of them
[16:54] <sforshee> mjg59, thanks, I'll look into that as well
[17:29]  * sforshee -> dr appt
[17:51]  * tgardner -> lunch
[17:54]  * apw calls it beer time, laters
[18:12] <cjwatson> Hmm.  Is there a reason why xenbus_probe_frontend is modular in several of our configs?
[18:12] <cjwatson> It means that other Xen drivers (e.g. xen-netfront) don't get autoloaded
[18:19] <cking> sforshee, be sure to write up your findings once you've figured out a workable methodology ;-)
[18:20] <tgardner> cjwatson, I think the backends are built-in for DomU clients. Aren't the front-end drivers for Dom0 ? or do I have it backwards.
[18:28]  * ogasawara lunch
[18:41] <cjwatson> tgardner: I think you have it backwards
[18:42] <cjwatson> tgardner: I'm on a domU client at the moment - loading xenbus_probe_frontend is enough for it to find its network interface
[18:43] <cjwatson> and without that, the installer fails due to having no network interfaces; I could work around this in the installer, but it seems more correct to build this in unless there's a reason not to
[19:05] <cjwatson> tgardner: I've filed bug 857662 with a more complete rationale
[19:05] <ubot2> Launchpad bug 857662 in linux "Should xenbus_probe_frontend be built-in?" [Undecided,New] https://launchpad.net/bugs/857662
[19:05] <tgardner> cjwatson, ack
[19:06] <tgardner> cjwatson, are you using the server or virtual ?
[19:06] <cjwatson> explained in the bug
[19:09] <cjwatson> ... and corrected the description to match reality
[19:11] <tgardner> cjwatson, so you think CONFIG_XEN_XENBUS_FRONTEND=y will solve all your problems ? -virtual works as desired ?
[19:12] <cjwatson> I have no remotely straightforward way of trying -virtual - I don't control the host
[19:12] <cjwatson> I have tested that 'modprobe xenbus_probe_frontend' makes everything work
[19:13] <tgardner> cjwatson, ok
[19:13] <cjwatson> and I guess I sort of feel that -generic should be a superset of -virtual, normally?  at least for "does it work"-ness
[19:14] <cjwatson> ISTR -virtual originally being just a make-it-smaller flavour
[19:14] <tgardner> cjwatson, actually, -server and -virtual are much more closely related (in amd64)
[19:15] <cjwatson> oh, is the -virtual config generated somehow?
[19:16] <cjwatson> I noticed
[19:16] <cjwatson> debian.master/config/amd64/config.flavour.generic:21:CONFIG_XEN_XENBUS_FRONTEND=m
[19:16] <cjwatson> debian.master/config/amd64/config.flavour.virtual:21:CONFIG_XEN_XENBUS_FRONTEND=y
[19:16] <cjwatson> and inferred that it wasn't a simple subset any more
[19:16] <tgardner> cjwatson, it was originally based on -server
[19:16]  * jjohansen -> lunch
[19:16] <cjwatson> oh, I see, well, -server has CONFIG_XEN_XENBUS_FRONTEND=m too
[19:16] <cjwatson> I wouldn't object to switching the xen images over to -virtual in P if it's the kernel team's opinion that that would work better
[19:17] <cjwatson> and if you think CONFIG_XEN_XENBUS_FRONTEND=y across the board is too risky for Oneiric then I can add workarounds
[19:17] <tgardner> cjwatson, we tailored -virtual for use in xen environments
[19:17] <cjwatson> but I thought it made sense to ask first
[19:17] <tgardner> I'm still evaluating  CONFIG_XEN_XENBUS_FRONTEND=y across the board
[19:17] <tgardner> its likely OK
[19:22] <tgardner> cjwatson, it _looks_ ok, but I think I've gotta test it on some bare metal first.
[19:25] <ogasawara> tgardner: lemme know how the tests go.  I'll hold off on the upload for a bit so we can add the config change.
[19:26] <tgardner> ogasawara, it'll take 30 mins or so
[19:26] <ogasawara> tgardner: ack
[19:34] <tgardner> cjwatson, ogasawara: the only way to build in XEN_XENBUS_FRONTEND is by enabling one of the front end device drivers, e.g., CONFIG_XEN_BLKDEV_FRONTEND=y or CONFIG_XEN_NETDEV_FRONTEND=y. This is the reason we only enabled those drivers for -virtual.
[19:35] <tgardner> I'll add my rationale to the bug
[19:51] <cjwatson> tgardner: oh, drat
[19:52] <cjwatson> that seems like a bug in the upstream config system
[19:52] <cjwatson> since you can never get autoloading that way
[19:52] <tgardner> cjwatson, Im not saying it _won't_ work, I'm just a little reluctant at this late stage.
[19:53] <cjwatson> yeah, understood
[19:53] <cjwatson> switching to -virtual will be fine for P, and I'll work around it in the installer for Natty/Oneiric
[19:54] <tgardner> cjwatson, cool, much appreciated.
[19:55] <cjwatson> solutions that don't involve kernel changes are fine, I just have a little Keybuk voice in the back of my head going "we should just change the kernel" sometimes ;-)
[19:55] <tgardner> I guess I'm the anti-keybuk
[19:55] <tgardner> ogasawara, fire away
[19:56] <ogasawara> tgardner: I'm firing up test boots and will then pull the trigger
[20:36]  * tgardner -> EOW
[21:18] <bryceh> ogasawara, heya
[21:18] <ogasawara> bryceh: hi what's up
[21:18] <bryceh> ogasawara, I want to build a kernel for a bug reporter to test, with an upstream patch applied
[21:19] <ogasawara> bryceh: want me to build it for ya?
[21:19] <bryceh> ogasawara, oh that'd be great
[21:19] <ogasawara> bryceh: sure, just point me to the patch.
[21:19] <bryceh> it's comment #7 on https://bugs.freedesktop.org/show_bug.cgi?id=41059
[21:19] <ogasawara> bryceh: I assume oneiric kernel?  and do they need amd64 or i386?
[21:19] <ubot2> Freedesktop bug 41059 in Driver/intel "XRANDR operations very slow unless (phantom) HDMI1 disabled" [Major,New]
[21:20] <bryceh> ogasawara, amd64
[21:21] <ogasawara> bryceh: once I've got it, you want me to just post the url to the test kernel in that bug?
[21:21] <bryceh> ogasawara, yep that'd be perfect
[21:21] <ogasawara> bryceh: ack, will do
[21:23] <bryceh> thanks ogasawara!
[21:25] <htorque> bryceh: hi! what do you say - are 120 ms per DP port probe ok? HDMI2 and HDMI3 in comparison are much faster.
[21:30] <bryceh> htorque, keith packard's been reworking the DP probing code lately
[21:31] <bryceh> we've seen some horrible times, particularly eDP, of 500-1000ms in some cases
[21:31] <bryceh> so compared with that 120 ms doesn't seem too bad
[21:31] <bryceh> however my expectation would be that it should be much lower than that
[21:32] <htorque> bryceh: okay, thanks for your answer! :)
[21:32] <bryceh> Given the recent trend of hardware with lots of different ports, what concerns me is the sum of doing these probes in serial.  I wonder why they're not done in parallel; is that even possible?
[21:33] <bryceh> htorque, keithp has a code branch with reworked DP probing that we had a couple people test and they found it significantly imprved boot speed
[21:34] <bryceh> I've communicated this to Intel, which they were glad to  hear and hopefully they'll have that new code finished, QA'd, and available in time for LTS
[21:34] <bryceh> I am not confident it's something we'd want to risk SRUing for oneiric but guess we can decide at some point when the code is ready
[21:35] <htorque> bryceh: the 1.6 sec. from HDMI1 are definitely worse - especially if you don't have HDMI ports :P
[21:35] <htorque> do you have a link to that branch?
[21:37] <bryceh> no but I can dig it up, one sec
[21:37] <htorque> bryceh: found this: http://kernel.ubuntu.com/~sarvatt/macbook-air/
[21:38] <bryceh> aha yeah that's it
[21:44] <htorque> bryceh: from 120 ms per port to 50 ms per port. nice! :)
[21:47] <bryceh> htorque, most excellent :-)


[14:05] <littlegirl> Hey there, I assigned myself the task of fixing https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/1242277 but can't figure out how to edit https://help.ubuntu.com/ - anybody got any advice on how it's done?
[14:05] <ubot2> Launchpad bug 1242277 in ubuntu-docs (Ubuntu) "Salamander is spelt incorrectly on help.ubuntu.com main page" [Undecided,Confirmed]
[14:06] <belkinsa> I think you need to be an wiki admin?
[14:07] <littlegirl> Oh, hehe, I'd better unassign myself, then. (:
[15:48] <dsmythies> https://help.ubuntu.com/ is maintained via the launchpad branch https://code.launchpad.net/~ubuntu-core-doc/ubuntu-docs/help.ubuntu.com . It is not a wiki. The bug report mentioned earlier has been fixed.
[15:49] <dsmythies> I use https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/BuildingDocumentation as my how-to reference for help.ubuntu.com
[15:50] <belkinsa> So, help.ubuntu is really the system docs?
[15:53] <dsmythies> Yes, help.ubuntu.com is a combination of the DeskTop help and severguide master files, with about 4 or 5, maybe more, glue files that hold it all together. help.ubuntu.com is in all supported languages. The serverguide was just added in other languages for 13.10. However the serverguide .pdf still has issues in other languages, so only English for it.
[19:28] <pleia2> belkinsa: the wiki is everything under help.ubuntu.com/community/
[19:29] <pleia2> belkinsa: if it doesn't have /community/ that means it's system docs
[19:29] <belkinsa> Yeah, I figured.
[19:29] <belkinsa> But thank you.
[19:29] <pleia2> sure
[19:32] <belkinsa> Do we have any numbers of how many people use the community wiki?