[06:51] <ppisati> moin moin
[07:24] <apw> moin
[08:30] <ppisati> i love the smell of kernel compilation in the morning...
[08:30] <zequence> Smells like...
[08:31] <smb> burning copper
[08:40] <apw> heh ...that's a good description
[09:12] <apw> smb, so what are you reproducing this on, is this your amd box ?
[09:13] <apw> smb, i wonder if i should be trying to repro it on my kit, to see if there is a type of kit link
[09:13] <smb> apw, One... its the dell 1521
[09:13] <smb> But in bug 1268906 jodh has seen it on an i7
[09:13] <ubot2`> Launchpad bug 1268906 in qemu-kvm (Ubuntu) "cpu soft lockup running kvm" [Medium,Confirmed] https://launchpad.net/bugs/1268906
[09:14] <apw> ok so that is intel and amd showing it?
[09:15] <apw> you should let peter know the extent of the h/w you have seen it on
[09:15] <smb> apw, IF only you would read mail
[09:15] <hvn2> question: if I cross-compile a patched vanilla kernel using make-kpkg, ending up with a linux-image and linux-header, and I install it using dpkg, will Ubuntu treat it as an Ubuntu kernel or does it take more to be treated as such ?
[09:17] <hvn2> my problem is that I've tried for 6 times now, and each time I get the message that it won't be written into flash
[09:19] <apw> hvn2, what is the message you get
[09:19] <apw> smb, i have read email, once is enough, ever
[09:20] <smb> apw, Sometimes people do reply... :) So, yeah I did already let him know that
[09:21] <apw> smb, and _that_ one i am not even copied on!
[09:21] <jarkko_> what should i do i get multiple of these on dmesg
[09:21] <jarkko_> 7659.777995] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 0 in queue 2
[09:21] <jarkko_> its known issue
[09:21] <smb> apw, Hm, I thought I did a reply all to his...
[09:21] <hvn2> apw: the exact message is that "kernel <..> does not match your subarchitecture omap, therefore not writing it into flash." Of course I configured the kernel for omap.
[09:22] <smb> apw, So no, you are not on that, but the initial email you were not either
[09:23] <apw> smb, indeed and the search page on lkml does not auto update!
[09:23] <apw> so ner
[09:23] <smb> apw, stupid them then :)
[09:23] <apw> smb, i note you are starting this with very little memory, i presume that is what is triggering the need to ipi a lot
[09:24] <smb> apw, Would it not do the opposite since the host is under less pressure?
[09:25] <smb> apw, Note that it is the qemu task on the host that runs into this
[09:27] <smb> hvn2, what does "file <kernel file>" say about that
[09:27] <apw> smb, but it is the internel need for one cputhread in the guest to wake the other that triggers the need to add the TIF_ flag in the first place, so i would guess anything which makes CPU to CPU comms in the guest more comon would tickle this issue more
[09:29] <smb> apw, I don't think so. In some cases the softlockup happened even when still running isolinux or the bios which inside the guest is not SMP
[09:29] <hvn2> smb, that says "Debian binary package (format 2.0)"
[09:30] <smb> hvn2, That would be a deb package and not the kernel which I assume the flashing is right to refuse
[09:31] <hvn2> no, on the target I did "file" on the kernel I cross-compiled
[09:34] <ppisati> hvn2: so you have a .deb package, right?
[09:34] <ppisati> hvn2: my guess is that, the vmlinuz file and initrd were installed successfully, you can check it looking inside /boot for those two fiels
[09:35] <ppisati> *files
[09:35] <ppisati> hvn2: what is failing is flash-kernel, you are hitting the same bug as this one: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/721147
[09:35] <ubot2`> Launchpad bug 721147 in flash-kernel (Ubuntu Natty) "flash-kernel subarch check fails with Linaro OMAP kernels" [Undecided,Fix committed]
[09:36] <ppisati> hvn2: after vmlinux and initrd are installed, there's a trigger to turn them into uImage and uInitrd files that uboot can understand
[09:36] <ppisati> hvn2: problem is, every board/arch is different, is tretaed differently and thus therte's a specific piece of code that deals with it
[09:37] <ppisati> hvn2: in your case when flash-kernel is invoked it doesn't understand for which arch/board your kernel was compiled for, and thus doesn't know how to handle it
[09:37] <ppisati> hvn2: anyhow
[09:37] <ppisati> hvn2: you just said that's a patched kernel, did you manually try to boot it?
[09:37] <ppisati> hvn2: does it work?
[09:41] <hvn2> ppisati: on x86 it installed and works perfectly, on this board it's given this message each time. Also, last time I tried to boot from the first attempt, it booted into the standard kernel. Since then I didn't boot since I got this message.
[09:43] <ppisati> hvn2: read the lp bug that i mentioned above, you are hitting the same problem
[09:43] <ppisati> hvn2: installing a kernel on an arm board it's (usually) a two step process
[09:43] <ppisati> hvn2: 1) tou install it (and create initrd) in /boot
[09:44] <ppisati> hvn2: 2) those files are converted in uImage/uInitrd files and copied somewhere
[09:44] <ppisati> hvn2: your package installation is failing point 2
[09:44] <ppisati> hvn2: because flash-kernel doesn't know how to handle your package
[09:47] <hvn2> ppisati: ah ok..right now, I'm reinstalling my latest kernel version and will check on the uImage and uInitrd. Then will try to boot into it
[09:55] <hvn2> ppisati: I just check /boot, and the only files that have been created from this latest install are initramfs and initrd.img. From yesterdays attempt are System.map and vmlinuz. The fat32 partition does not contain new uImage or uInitrd.
[09:56] <hvn2> ppisati: So I guess I have to manually do step 2
[09:58] <hvn2> ppisati: yes, that my problem is clearly according to that bug
[10:29] <hvn2> ppisati: I just found this for Karmic: mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d ./vmlinuz-* ./uImage . Does this handle uInitrd as well ?
[10:29] <ppisati> hvn2: as the command says, it creates only uImage
[10:30] <ppisati> hvn2: if i would you, i would put some echo in flash-kernel and the reinstall an ubuntu kernel on that board
[10:30] <ppisati> hvn2: this way you can see what's going on
[10:36] <cking> apw, did you get my email wrt thermad
[10:36] <cking> ?
[10:39] <hvn2> ppisati: ok ty. I will check.
[10:58] <apw> cking, yep saw it
[10:59] <apw> cking, i thin you are on the money, lets get it synced over
[11:00] <apw> cking, i assume we want -7 yes ?
[11:05] <cking> apw, yep
[11:11] <caribou> Is our signed kernel that boots in secure mode a totally separate kernel or some thing that sits on top of the regular one ?
[11:12] <apw> caribou, it is exactly the same kernel, bit for bit, with a teensy signature attached
[11:12]  * caribou is just trying to confirm that our signed kernel has kexec disabled
[11:13] <apw> caribou, though it exercises different code during early boot if booted signed from efi
[11:13] <caribou> apw: ah, ok, hence the ./usr/lib/linux/vmlinuz-3.11.0-15-generic.efi.signature in the package
[11:13] <apw> caribou, kexec is enabled
[11:13] <caribou> apw: ah ok, thought it was not
[11:15] <apw> caribou, it is arguable if you have module signing enforced it should be, but it is not
[11:15] <apw> caribou, we did however just add the commit below
[11:15] <apw> commit 70a96bd309fc4ff7d07792057cda1ad89e647388
[11:15] <apw> Author: Kees Cook<EMAIL_ADDRESS>[11:15] <apw> Date:   Thu Jan 23 15:55:59 2014 -0800
[11:15] <apw>     kexec: add sysctl to disable kexec_load
[11:15] <apw>
[11:15] <apw> which allows you to permenantly diable it on boot, this lets you load a crash kernle and then stop it being changed
[11:22] <caribou> apw: yeah, I remember asking about this one recently
[11:22] <caribou> apw: thanks for the info
[11:38] <apw> henrix, about to blow the autotriager into bits again
[11:38] <henrix> apw: ack
[11:48] <cking> apw, i may have to do one more thermald upload as I've just been given a some patches to make it work with systemd
[11:54] <apw> cking, thats fine, we can sync again, if -7 is worth having now
[11:55] <cking> well -8 won't add much for us, , so -7 is fine for the mo, but I will get -8 up sometime today once I've sanity checked it
[12:03] <apw> cking, ok that is sync'd, built, and pending publication
[12:06] <cking> ta
[12:07] <cking> apw, the next step I guess is to make it install on our kernel for x86 systems
[12:08] <apw> yeah i guess we make it an install dependancy of the kernel on x86, does it make sense anywhere else ?
[12:08] <cking> apw, nope, just for x86
[12:19] <apw> ok, so we will trigger a component missmatch, so we need an MIR filing for that to get considered for inclusion
[12:25] <zequence> apw: So, I was able to narrow down one clue to linux-lowlatency not booting - as it seems to freeze because of at least one type of wifi driver. I was thinking of doing more testing, and thinking since the diff is so small, it should be easy to narrow it down even more.
[12:25] <zequence> apw: So, I thought to try rebuild the kernel without the threadirqs parameter
[12:26] <zequence> But, maybe you guys already have an idea about what it could be?
[12:26] <apw> zequence, so joe has built kernels with preempt off, and you can test the thread thing by turning it off on the command line
[12:27] <zequence> apw: Right
[12:27] <zequence> Ok. Will do some testing this evening
[12:28] <apw> liase with jsaulisbury as he has all the kernels et
[12:28] <apw> etc
[12:29] <zequence> apw: Alright
[14:07] <rtg> cking, have you written a main inclusion request for thermald ?
[14:07] <cking> rtg, nope, how does one go about that?
[14:08] <rtg> cking, um, I have to figure it out every time 'cause I don't do it that often.
[14:08] <cking> https://wiki.ubuntu.com/MainInclusionProcess i guess
[14:08] <rtg> cking, that looks right
[14:24] <caribou> what value of /proc/meminfo would be good candidate to evaluate the memory available when booted in the kexec crash dump environment ?
[14:24] <caribou> I was thinking of MemTotal & MemFree
[14:37] <apw> caribou, yep, those are the ones i would start with
[14:38] <caribou> apw: ok, thanks. I'm hoping to define a set of scripts that can be easily replayed. If I get good results, I'll write a blog post about it
[14:58] <jsalisbury> bjf, want me to apply the <IP_ADDRESS> updates to Saucy master-next ?
[14:59] <bjf> jsalisbury, yup, go for it
[14:59] <jsalisbury> bjf, cool.  I'll push them to my git repo on zinc again and send a pointer
[15:02] <jsalisbury> bjf, also, there was an update from the bug report on bug 1254091 but he didn't update the tags
[15:02] <ubot2`> Launchpad bug 1254091 in linux (Ubuntu Saucy) "intel_pstate no_turbo patch from upstream" [Medium,In progress] https://launchpad.net/bugs/1254091
[15:44] <hvn2> question: after installation of a custom built kernel and rebooting, the tracking data shows the kernel image has bad data crc. How can I check beforehand if this is the case ?
[16:08] <jsalisbury> henrix, I was cross checking the v<IP_ADDRESS> patches I'll be applying to Saucy with your emails for <IP_ADDRESS> -stable review.
[16:08] <jsalisbury> henrix, It seems this one is not in v<IP_ADDRESS>:
[16:08] <jsalisbury> [PATCH 3.11 233/233] ftrace: Have function graph only trace based on global_ops filters
[16:08] <jsalisbury> henrix, was that dropped?
[16:13] <lag> cking: Hey Colin
[16:13] <cking> lag, yup
[16:13] <jsalisbury> henrix, ahh, I think this explains it: http://www.spinics.net/lists/stable/msg34983.html
[16:15] <lag> cking: Just to let you know, there's been a slight change of plan
[16:15] <lag> cking: As your patch turned into a code clarity patch, rather than a BUG, I'm going to push it though -next instead of -fixes
[16:15] <cking> lag, ok, sure, that makes sense
[16:15] <lag> cking: As your patch turned into a code clarity patch, rather than a BUG, I'm going to push it though -next instead of -fixes
[16:16] <lag> Whoops, wrong window to do (up + return)
[16:19] <henrix> jsalisbury: yep, it has been dropped (as you've already found out :) )
[16:20] <jsalisbury> henrix, great, thanks.  Just wanted to confirm :-)
[16:31] <sforshee> smb: do you know if it's possible to run xen in a kvm guest?
[16:32] <smb> sforshee, not done that but with nested enabled on host ... theoretically
[16:33] <sforshee> smb: just looking for a way to run xen without sacrificing a physical machine
[16:33] <plars> bjf: psivaa and I are still seeing this test_010_proc_maps failures, at least on non-precise runs. Was there anything specific about the fix for that to precise?
[16:34] <smb> sforshee, Its not so much sacrificing... you still can boot normally after..
[16:35] <smb> I  just would fear an unknown amount of "nobody  tried that before" when trying to run inside a kvm VM
[16:36] <bjf> plars, can you look in the ubuntu_qrt_kernel_security.tar.bz2 tar file and see what the latest revno reported in the bzr.log file in that tar file is?
[16:43] <bjf> plars, it should be this: http://paste.ubuntu.com/6920824/
[16:43] <plars> bjf: ah, that's not the results file
[16:44] <plars> bjf: I was looking in the wrong thing, I don't know if I have that after the run, but I could wait for one running right now to finish and see what it has
[16:44] <bjf> plars, you should be able to look in your git repo
[16:50] <plars> bjf: ok, at least in our tree that seems correct
[16:54] <bjf> plars, i'll add code to the tests so that shows up in the output results
[17:03] <bjf> sbeattie, it sounds like CI is still seeing issues with the security test. it looks like they are now running the latest version. i'll add code to the tests so they report what version they are running
[17:18] <hallyn> apw: hi, did i scare you away with the user.overlay.* idea for overlayfs? :)
[17:39] <apw> hallyn, i thought you decided you could make a big mess with that, removingwhiteouts
[17:40] <hallyn> apw: I don't undestand, but I think the answer is no (i didn't decide that ,that is :)
[17:40] <hallyn> apw: to remove a whiteout, the user would have to find the file on the writeable layer
[18:06] <jsalisbury> henrix, I noticed there may be a change missing in <IP_ADDRESS>, which came in with patch:
[18:06] <jsalisbury> [PATCH 3.11 148/233] mmc: sdhci-pci: Fix BYT sd card getting stuck in runtime suspend
[18:06] <jsalisbury> henrix: The sdhci_intel_mrst_hc1_hc2 struct is missing the addition of  .own_cd_for_runtime_pm = true,
[18:07] <henrix> jsalisbury: checking...
[18:07] <henrix> jsalisbury: ah, i see what you mean
[18:08] <henrix> jsalisbury: so, that structure is actually on a different place in 3.11
[18:08] <henrix> jsalisbury: it is defined in drivers/mmc/host/sdhci-pci.c instead of rivers/mmc/host/sdhci-pci.h
[18:09] <henrix> jsalisbury: so, the change is still there, but in a different place
[18:09] <henrix> jsalisbury: does this makes sense to you?
[18:09] <jsalisbury> henrix, hmm, I don't see the change in that file.
[18:10] <jsalisbury> henrix, I see that you backported that struct into drivers/mmc/host/sdhci-pci.c, which I'll have to move back to drivers/mmc/host/sdhci-pci.h for Saucy, heh
[18:11] <henrix> jsalisbury: you're talking about commit d097d786191a4cd882d622479a742a90605004c6 (in the stable tree), right?
[18:11] <jsalisbury> henrix, I see the struct defined in drivers/mmc/host/sdhci-pci.c, but it seems to me missing the addition of own_cd_for_runtime_pm = true
[18:11] <jsalisbury> static const struct sdhci_pci_fixes sdhci_intel_mrst_hc1_hc2 = {
[18:11] <jsalisbury>         .quirks         = SDHCI_QUIRK_BROKEN_ADMA | SDHCI_QUIRK_NO_HISPD_BIT,
[18:11] <jsalisbury>         .probe          = mrst_hc_probe,
[18:11] <jsalisbury> };
[18:12] <henrix> hmmm....
[18:13] <jsalisbury> henrix, hmm, maybe a later commit dropped it?
[18:14] <henrix> jsalisbury: ok, so 2 sdhci_pci_fixes struct instances are modified: sdhci_intel_mfd_sd and sdhci_intel_byt_sdio. correct?
[18:14] <hallyn> oh no.  is lvm in trusty supposed to be working?
[18:14] <henrix> actually, sdhci_intel_mfd_sd and sdhci_intel_mfd_sdio
[18:15] <henrix> gah! i'm confused :)
[18:15] <jsalisbury> henrix, for that commit, should be three:
[18:15] <jsalisbury> sdhci_pci_fixes, sdhci_intel_mrst_hc1_hc2 and sdhci_intel_byt_sdio
[18:16] <jsalisbury> wait
[18:17] <henrix> jsalisbury: sdhci_intel_mrst_hc1_hc2?
[18:17] <hallyn> lvcreate/lvremove on trusty kernel on precise host is taking a long time;  acting like it is trying to dd all 50G (creating a snapshot) and not killable
[18:17] <henrix> jsalisbury: i'm looking at the original commit (77a0122e0838663795651aa0beb2325156f98c09) and it this is not modified
[18:18] <hallyn> looks like udev rules are causing a hang
[18:18] <henrix> jsalisbury: ah, maybe you're looking at the '@@ -225,6 +225,7 @@ static const struct sdhci_pci_fixes sdhci_intel_mrst_hc1_hc2 = {' line?
[18:18] <jsalisbury> henrix, sorry, let me check again.
[18:18] <hallyn> this rings a bell.
[18:18] <jsalisbury> henrix, yes, I think that is what I'm doing
[18:20] <jsalisbury> henrix, yeah, sorry to have caused the confusion.  I was looking at the wrong struct in the diff
[18:20] <henrix> jsalisbury: uff!  :)
[18:21] <hallyn> i bet slangasek remembers this...
[18:21] <henrix> jsalisbury: anyway, thanks for reviewing.  these sort of mistakes have happen in the past, so...
[18:21] <hallyn> maybe udev changelog will jog my memory
[18:23] <jsalisbury> henrix, that commit failed when applying to saucy.  It was due to the move of structs to the header file like you say.  mainline moved some structs to the header file, your <IP_ADDRESS> moves them back, then Saucy moves them back out.
[18:24] <jsalisbury> henrix, thanks for reviewing and helping un-cross my eyes, heh
[18:24] <henrix> jsalisbury: heh.. anyway, its odd saucy has the struct in a different place. i guess a SAUCE patch (probably cherry-picked from 3.12+) has done that
[18:25] <jsalisbury> henrix, yes, a SAUCE patch, cherry-picked from 3.14-rc1:
[18:25] <jsalisbury> https://lists.ubuntu.com/archives/kernel-team/2014-January/038073.html
[18:27] <henrix> ah, ok.  that would explain it :)
[18:28] <hallyn> hm, was transient.  will wait till it happens again to open a new bug i guess
[19:23] <slangasek> hallyn: lvcreate/remove being slow doesn't ring a bell to me; there've been issues with udev rules in the past, but I think those were all resolved for precise
[19:24] <hallyn> slangasek: hm, thanks.  I remember the udev rule thing having to do with watershed;  but don't recall the details or what we fixed.
[19:25] <hallyn> I guess somehow I ended up having 'lvcreate' race with a udev rule for the lvm lock.  <shrug>  This is a trusty kernel on precise host, btw.
[19:25] <hallyn> i'll file a bug if/when it happens again
[20:14] <jsalisbury> bjf, sconklin, I finished applying the <IP_ADDRESS> updates to Saucy.  However, I'm getting an abi check error, when performing a test build:
[20:14] <jsalisbury> https://pastebin.canonical.com/104737/
[20:15] <sconklin> looking
[20:15] <bjf> jsalisbury, is there a "start new release" after the previous release and before your changes?
[20:15] <jsalisbury> bjf, checking
[20:15] <sconklin> yeah, what he said
[20:16] <hvn2> question: how can I verify beforehand if a new uImage has a wrong crc ?
[20:20] <jsalisbury> bjf, sconklin It does'nt look like there was a "Start new release".  The last one was before Ubuntu-3.11.0-17.31.  Here is the tip of the saucy tree I used:
[20:20] <jsalisbury> https://pastebin.canonical.com/104739/
[20:20] <sconklin> jsalisbury: right.
[20:20] <bjf> jsalisbury, ok, run maint-start-new-release in that tree then rebase that down to just after the commit for the last release
[20:21] <jsalisbury> sconklin, bjf, ok, got it.  Thanks!
[20:21] <sconklin> That's something you didn't know to look for. There should always be a start-new-release right after a release on master-next, but you have to wait to do it until the packages are built.
[20:22] <sconklin> sometimes some patches get applied to master-next in that window, and you have to go back and reorder things in master-next to 'insert' a start new release commit
[20:22] <jsalisbury> sconklin, I knew to look for it when turning the crank, but not while applying stable updates
[20:22] <sconklin> ack, ok
[20:22] <jsalisbury> sconklin, now I know :-D
[20:23] <bjf> jsalisbury, it's all about bumping the abi
[20:24] <jsalisbury> bjf, abi == "aggravating binary interface"
[20:24] <jsalisbury> :-)
[20:42] <jsalisbury> bjf, sconklin, Hmm, do I need to do the 'start new release' before applying the stable updates?  It does'nt seem like it.
[20:42] <bjf> jsalisbury, no
[20:43] <jsalisbury> bjf, I'm getting an error doing the rebase.  I'll see if I can figure it out
[20:58] <sconklin> hey joe, would you like for me to put the startnewrelease on and rebase that so you have a clean tree with the right ABI files to apply the upstream?
[20:59] <sconklin> jsalisbury: ^^
[21:03] <jsalisbury> sconklin, I don't think so.  I'll see if I can get it to work.  It will help me learn :-)  I'll ask you to do it if I can't get it to work.
[21:04] <sconklin> cool, that's probably the right answer
[21:04] <jsalisbury> sconklin, I'm going to grab some lunch, then start it from scratch to help memorize the steps.  I'll let you know if I get hung up.
[21:05] <sconklin> ok, np
[21:05] <jsalisbury> sconklin, thanks for the help!
[21:48] <bjf> sbeattie, did you see the earlier comment about the security test failing still?
[21:48] <sbeattie> bjf: I did not, sorry.
[21:48] <bjf> sbeattie, np
[21:49] <bjf> sbeattie, looks like we are now running the latest tests
[21:49] <bjf> sbeattie, plars has a test run he just recently did on saucy and it failed
[21:50] <sbeattie> bjf: got a pointer to the failure? I can never navigate the forest of jenkins servers you guys have
[21:50] <bjf> plars, ^
[21:51] <plars> sbeattie: https://jenkins.qa.ubuntu.com/job/sru_kernel-saucy-virtual_amd64-kvm-virtual/93/
[21:57] <plars> sbeattie: on the plus side, it does seem to be working ok on precise
[22:00] <sbeattie> plars: this looks like the same issue: either the QRT script is out of date, or else /usr/share/doc/linux-image-3.11.0-17-generic/changelog.Debian.gz doesn't contain a reference to CVE-2013-2929
[22:02] <plars> sbeattie: bjf just made some changes to have it show which rev of the qrt tests its running, I need to update our copy and rerun, but given that it's pulling from the same source that our precise tests are pulling from (which now work) I think we have an updated qrt now
[22:04] <sbeattie> well, it's the same failure, where a test is succeeding where it wasn't expected to, and the reason it's not expecting it to is because the kernel version is between a specific range and the test can't find that CVE number in the kernel's changelog.
[22:31] <sbeattie> plars: ohhhhh. the changelog gets reset each go around. Okay, I'm just going to assume that CVE-2013-2929's been fixed everywhere.
[22:34] <plars> sbeattie: I'm not sure I follow
[22:34] <plars> sbeattie: this is something you are scanning for in that changelog with qrt?
[22:36] <sbeattie> yes, I was changing the expectation of the test based on whether the kernel was claiming it had been fixed.
[22:37] <sbeattie> I'm ripping that out now, and will expect the test to pass.
[22:40] <sbeattie> plars, bjf: rev 2119 of QRT should cause things not to fail anymore.
[22:40] <sbeattie> plars: the saucy kernel should not be blocked on that test-kernel-security failure, if you don't want to re-run tests.
[22:41] <plars> sbeattie: ok, that's all that's failing on it so I'll mark it good then
[22:42] <plars> bjf: any further thoughts on the btrfs test at https://bugs.launchpad.net/kernel-sru-workflow/regression-testing/+bug/1267469? Given that the proc maps thing is resolved and the config_debug_rodata is a known issue, I think we can mark that one good as long as you are comfortable that the btrfs test failure was just a timing thing?
[22:42] <ubot2`> Launchpad bug 1267469 in Kernel SRU Workflow regression-testing "linux-ti-omap4: 3.2.0-1443.62 -proposed tracker" [Medium,In progress]
[23:44] <miseria> "la verdadera felicidad de un ser humano, se logra cuando deja de ser esclavo, de la avaricia y la codicia" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*


[09:14] <dpm> hi danilos, good morning. If you're around, would you mind looking at this merge proposal I sent for intltool yesterday? https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112
[09:32] <danilos> dpm, hi, overall it looks good: can you ping me towards the end of the day please (so I can focus a bit more on the regexes)?
[10:02] <dpm> danilos, sure, thanks
[16:03] <dpm> danilos, here's the "ping me towards the end of the day" ping, if you've got a minute to review the regexes on the intltool MP: https://code.launchpad.net/~dpm/intltool/add-qtdesigner-support/+merge/145112 :-)


[05:08] <mborzecki> morning
[05:11] <mborzecki> brb, new kernel
[05:52] <zyga> good morninf
[05:58] <mborzecki> zyga: hey
[05:58] <zyga> hey hey
[05:58] <zyga> I'm trying to fix what I prepared yesterday and add the CUDA test as well
[06:11]  * zyga fights tab creep
[06:14] <mborzecki> zyga: next step https://forum.snapcraft.io/t/do-snaps-apps-support-vulkan/10534/2
[06:15] <zyga> mborzecki: yeah, I will find some hello-vulcan code
[06:15] <zyga> mborzecki: the interesting experience started when I removed various random bits of MESA from my test snap
[06:15] <zyga> it shrank significantly and no longer ran without the "driver" snap connected
[06:15] <zyga> but first things first
[06:16] <zyga> fight tab creep, restore opengl part to working order, get cuda to work in confinement
[06:20] <mborzecki> mvo: morning
[06:20] <zyga> hey mvo :)
[06:21]  * zyga managed to reduce tab creep to ~ 10 tabs
[06:23] <mvo> hey mborzecki and zyga good morning
[06:24] <mborzecki> zyga: can you take a quick look https://github.com/snapcore/snapd/pull/6792 ? just renames and moving the code around
[06:24] <zyga> mborzecki: looking
[06:24] <zyga> I had a look last night but it was a bit more complex
[06:25] <zyga> mborzecki: question: why PositionedVolume contains a *Volume rather than Volume?
[06:25] <mborzecki> zyga: avoiding another copy, no other reason
[06:26] <zyga> are we mostly working with Positioned or the plain version?
[06:26] <mborzecki> zyga: depends where, validation works with Volume mostly, update works with Positioned*
[06:26] <zyga> a copy has its cost but also has the property of not being related to something anymore, so you can clobber the volume but the positioned volume stays intact
[06:26] <zyga> mmm
[06:27] <zyga> +1 but consider if it is easier to reason about this without the pointer
[06:27] <mvo> hm 6782 has no +1 but surely mborzecki has an opinion on this one :)
[06:27] <mborzecki> mvo: looking
[06:28] <zyga> commented
[06:28] <mborzecki> zyga: thanks
[06:28] <zyga> mborzecki: and then perhaps https://github.com/snapcore/snapd/pull/6788 :)
[06:29] <zyga> simple and just a 2nd +1
[06:29] <mborzecki> mvo: lgtm, though i can only +1 the parts i didn't touch :)
[06:30] <zyga> woot, thank you!
[06:30] <mvo> mborzecki: that seems to be fine, I will +1 the parts you did touch
[06:38] <zyga> mborzecki, mvo: one simple argument removal https://github.com/snapcore/snapd/pull/6794
[06:40] <mborzecki> zyga: more lines removed than added, +1 :)
[06:42] <mvo> zyga: 6782 had a +0.9 from you - is the final 0.1 there now? with that we can merge jamies 6759
[06:42] <zyga> Thanks guys!
[06:42] <zyga> mvo: looking
[06:44] <zyga> mvo: https://github.com/snapcore/snapd/pull/6782/files#diff-bdab0f3d09049605d4bd7bc4892a6a4bR91 !!!
[06:44] <zyga> was this always broken>?
[06:49] <mvo> probably :/
[06:51] <zyga> but the test did not catch this before
[06:51] <zyga> interesting
[06:56] <mvo> zyga: yeah, definitely worth looking why
[06:58] <zyga> mvo: and it was failing for you without this extra dash, right?
[06:58] <zyga> mvo: but not initially,
[06:58] <mborzecki> mup still silent?
[06:58] <mvo> zyga: I think mborzecki fixed this particular one
[06:58] <mvo> mborzecki: I think so
[06:59] <zyga> mvo: so something that changed in the patch caused it to fail
[06:59] <mborzecki> --build-id?
[06:59] <zyga> aha
[06:59] <zyga> yes
[06:59] <mvo> mborzecki: we probably need to poke gustavo about it
[06:59] <zyga> mup_: hello
[07:00] <pstolowski> morning
[07:01] <mborzecki> zyga: mvo: fwiw both -build-id and --build-id, the manpage though says --build-id
[07:03] <mvo> hey pstolowski
[07:03] <mvo> mborzecki: aha, nice
[07:07] <pstolowski> mvo: i saw your idea from yesterday, ty, i'm looking at it
[07:09] <pstolowski> (timing for state loading)
[07:16] <mvo> pstolowski: cool, thanks
[07:23] <zyga> did anyone restart https://github.com/snapcore/snapd/pull/6794 ?
[07:26]  * mvo didn't
[07:27] <mvo> zyga: if you could add a test to 6751 this one is fine to go in, sorry that the review for this took so long, its nice and small and ready
[07:27] <zyga> checking
[07:27] <zyga> yes, I plan to
[07:27] <zyga> that's an early branch,
[07:27] <zyga> just didn't go anywhere last week
[07:27] <pstolowski> mvo: to clarify - the idea with timings is to measure state.ReadState() on startup correct?
[07:38] <mvo> pstolowski: yes
[08:01] <zyga> mvo, mborzecki: another simple chunk https://github.com/snapcore/snapd/pull/6796
[08:14] <Chipaca> moin moin
[08:16] <niemeyer> mvo, mborzecki_: May I help somehow?
[08:16] <mborzecki_> niemeyer: hi, mup is awfully silent
[08:16] <niemeyer> Sorry, I still haven't fixed its ability to self-identify
[08:17] <niemeyer> I'll poke it
[08:17] <mborzecki> niemeyer: thanks!
[08:17] <zyga> hello Chipaca, hey niemeyer :)
[08:17] <niemeyer> mup_: Should work now
[08:17] <mup_> niemeyer: In-com-pre-hen-si-ble-ness.
[08:18] <niemeyer> Hmm.. and somebody took over its nick
[08:18] <niemeyer> zyga: Heya
[08:46] <mvo> zyga: hey, do you have time for a quick about the static attibutes PR?
[08:46] <zyga> mvo: hey, sure
[08:47] <mvo> zyga: cool, lets hop to the standup channel, I will be there in 30s
[08:47] <zyga> mvo: sure
[09:04] <zyga> pstolowski: hey
[09:04] <mvo> pstolowski: hey, want to join the standup channel?
[09:04] <zyga> pstolowski: we have the call about stale connection attributes
[09:04] <zyga> pstolowski: could you join us please
[09:04] <zyga> pstolowski: sorry for not pinging you earlier, but we just started a moment ago
[09:05] <pstolowski> zyga: sure, coming
[09:18] <zyga> thank you Pawel!
[09:19]  * Chipaca hates 409s
[09:24] <mup> PR snapd#6797 opened: overlord/ifacestate: revert the initial fix for lp #1825883 <Created by stolowski> <https://github.com/snapcore/snapd/pull/6797>
[09:37] <pstolowski> zyga, mvo: ^
[09:40] <zyga> done
[09:40] <zyga> pstolowski: and update the bug report with additional information that this is unfixed
[09:40] <mvo> pstolowski: ta!
[09:41] <pedronis> mvo: we still need to decide what to do with https://github.com/snapcore/snapd/pull/6638/files, no ?
[09:41] <mup> PR #6638: interfaces: add support for the snapd snap in the dbus backend  <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6638>
[09:41] <mvo> pedronis: yes
[09:42] <mvo> pedronis: its a re-exec thing but yeah, without it there is a (small) regression
[09:43] <mvo> pedronis: thinking about it, it might be racy but worst case is that the same file is written twice - unless I miss something
[09:48] <pedronis> Chipaca: mvo: hi, is the cohort stuff in 2.39? what is still missing?
[09:49] <Chipaca> pedronis: it is not in 2.39, no
[09:49] <Chipaca> pedronis: create-cohort landed just last night finally
[09:49] <Chipaca> pedronis: i'm working on install, tests are looking good and hoping to get it covered and up today
[09:50] <Chipaca> switch and refresh should be a small thing after that, and then commands to expose this to the user
[09:50] <Chipaca> still thinking about leave-cohort a bit, but expect it to emerge naturally as i get there
[10:09] <mup> PR snapd#6798 opened: gadget: introduce checkers for sanitizing structure updates <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6798>
[10:10] <mborzecki> another bulky one ^^, fortunately tests are 75+% of the whole thing
[10:21] <mvo> pedronis: should I de-conflict 6747 for you?
[10:27] <mborzecki> mvo: can we just bump go to 1.10 in travis? iirc it's the oldest one we build with anyway
[10:33] <mvo> mborzecki: iirc EPL and RHEL were holidng us back, but if that got updated to 1.10 +1
[10:34] <mborzecki> mvo: it would also fix the madness with go fmt indent chnges in 1.10
[10:34] <mvo> mborzecki: what is the version in centos right now? (and rhel?)
[10:34] <mborzecki> mvo:  checking right now
[10:34] <mvo> mborzecki: ta
[10:35] <mvo> pedronis: fwiw, I have a PR almost ready to add deviceCtx to checkSnap* and update the tests (just the mechanics at this point, no functional changes)
[10:35] <mborzecki> mvo: golang-1.11.5-1.el7
[10:37] <mup> PR snapd#6799 opened: travis: bump Go version to 1.10.x <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6799>
[10:41] <mvo> mborzecki: \o/
[10:44] <Chipaca> mborzecki: I don't think the .x is literal
[10:44]  * Chipaca looks
[10:44] <Chipaca> well it worked ¯\_(ツ)_/¯
[10:44] <mborzecki> Chipaca: that should be last tagged patch release in given major.minor
[10:45] <Chipaca> mborzecki: isn't "1.10" the same?
[10:45] <mborzecki> Chipaca: i was bit surprised suprised that 1.10 is 1.10 exactly
[10:45] <Chipaca> that is surprising indeed
[10:46] <Chipaca> the documentation i saw didn't point this out either
[10:46] <Chipaca> hm
[10:46] <Chipaca> anyway, eh, if it works it works
[10:52] <pedronis> mvo: if you want/can, I'm trying to take care of errands and then do the 2.39 reviews
[10:52] <mvo> pedronis: thanks!
[10:58] <mvo> pedronis: pushed the update for devicectx
[10:58] <mvo> 6747 needs a second review btw :)
[10:58] <mvo> (its this devicectx PR)
[11:25] <Chipaca> luuuuuuuunch
[11:25]  * Chipaca is zombie
[11:35] <pedronis> mvo: gave some feedback on #6778
[11:35] <mup> PR #6778: [RFC] snapstate: auto-install snapd when needed <Created by mvo5> <https://github.com/snapcore/snapd/pull/6778>
[11:53] <pedronis> mvo: commented also in #6638
[11:53] <mup> PR #6638: interfaces: add support for the snapd snap in the dbus backend  <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6638>
[11:53] <pedronis> marked it for 2.29 as well
[11:54] <pedronis> heh, 2.39
[12:01] <mborzecki> off to pick up the kids
[12:04] <dot-tobias> kyrofa / sergiusens: Is it possible (and feasible) to use classic snaps as stage-snaps? The ruby snap seems to work fine so far, but suddenly the bundled libraries are not found by apps in the snap. I guess it has something to do with this snapcraft notification: “part X needs the following libraries that are not included in the snap or base: lib64/ld-linux-x86-64.so.2”
[12:14] <pedronis> pstolowski: question in #6755
[12:14] <mup> PR #6755: overlord/snapstate: tweak autorefresh logic if network is not available <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6755>
[12:16] <cmatsuoka> Chipaca: can the snapd snap be built with base: core? it could solve the snap dir clutter problem
[12:16] <mup> PR snapd#6799 closed: travis: bump Go version to 1.10.x <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6799>
[12:17] <pstolowski> pedronis: replied
[12:17] <mup> PR snapd#6797 closed: overlord/ifacestate: revert the initial fix for lp #1825883 <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6797>
[12:20] <pedronis> pstolowski: couple of comments, thank you
[12:22] <pedronis> mvo: thanks for #6771 , I was thinking about something like that
[12:23] <mup> PR #6771: cmd: add `snap debug validate-seed <path>` cmd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6771>
[12:24] <pedronis> mvo: zyga: this is bad tough:  #6763
[12:24] <mup> PR #6763: overlord/snapstate: remove PlugsOnly <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6763>
[12:24] <zyga> pedronis: oh?
[12:24] <zyga> pedronis: can you clarify?
[12:24] <pedronis> zyga: it's needed for this at some point: https://forum.snapcraft.io/t/cross-snap-operations-bases-and-concurrency/5685
[12:25] <zyga> pedronis: I wasn't aware of this, is having just plugs somehow special though? (or having just slots?)
[12:25] <Chipaca> cmatsuoka: if that now works, yes
[12:25] <pedronis> zyga: yes, it's special, two snaps having only plugs can't interfere with each other
[12:26] <Chipaca> cmatsuoka: assuming base: core doesn't actually reach the snap.yaml
[12:26] <zyga> pedronis: how about two snaps with just slots?
[12:26] <pedronis> (unless they are a special snap like bases or kernel etc)
[12:26] <cmatsuoka> Chipaca: worked in a quick PoC, let me try with the real thing
[12:26] <pedronis> zyga: that's not as useful, they interfere each with snaps with plugs
[12:28] <pedronis> anyway that change needs reverting
[12:28] <pedronis> atm
[12:51] <sergiusens> dot-tobias: you will need to organize or set the library paths appropriately... I don't think the "fine" part has been nailed if libraries are not found
[12:51] <sergiusens> dot-tobias: also, if the publisher decides to change the base then when you stage that snap you will potentially have a broken snap, more than potentially, most likely as the path to the linker loader is fixed to the base
[12:52] <sergiusens> kyrofa: we do have a bug for that about the deb and bases... it just requires time... I am not missing the SRU process at all
[12:55]  * sergiusens scratches head as he does not see his replies from yesterday on this irc session
[12:56] <dot-tobias> sergiusens: Thanks for the info, I'll test if a fork of the snap works better (I haven't found an issue yet, but I guess somewhere down the road the ruby snap's classic confinement will break something?). Anyway, the snapcraft notice about ld-linux doesn't occur if I switch back to stage-packages and the ruby plugin, but still one service suddenly cannot find a library pulled in via stage-packages (not stage-snaps) … puzzles me
[13:21] <tomwardill> hi! Is there a snapd environment variable (or other method) that will get me the response payload from the store?
[13:21] <zyga> Chipaca: ^
[13:22] <Chipaca> tomwardill: hi! yes 1 sec
[13:22] <tomwardill> ta
[13:23] <Chipaca> tomwardill: SNAPD_DEBUG_HTTP, more in https://github.com/snapcore/snapd/blob/master/HACKING.md#testing-snapd
[13:24] <jdstrand> ogra: hey, I just noticed on my arm64 device, 'sudo classic' results in no /etc/alternatives, which causes anything you install with apt that uses alternatives to fail. have you seen this?
[13:24] <tomwardill> Chipaca: that doesn't appear to dump the response body
[13:24] <tomwardill> (Or I'm doing it wrong)
[13:24] <Chipaca> tomwardill: it does :-) how are you doing it?
[13:24] <tomwardill> oh, I might have the wrong number in the wrong place
[13:25] <tomwardill> one sec :)
[13:25] <tomwardill> Chipaca: sorry, I was holding it wrong.
[13:25] <Chipaca> tomwardill: https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537
[13:26] <tomwardill> I had '9' rather than '7', because obviously a higher number is better...
[13:26] <Chipaca> :-D
[13:26] <cachio> mvo, https://paste.ubuntu.com/p/ztGGVFZsF6/
[13:26] <cachio> mvo, this is the output, last line is stuck
[13:26] <mvo> cachio: /o\
[13:30] <mborzecki> cachio: is this what the stuck code is doing? http://paste.ubuntu.com/p/KpGxWdFfVJ/
[13:30] <cachio> mborzecki, yes
[13:31] <cachio> mborzecki, for i in $(seq 130); do echo $i && snap run --strace="-tt" test-snapd-tools.echo "hello-world"; done
[13:31] <cachio> mborzecki, that was the line
[13:32] <mborzecki> cachio: hmm, bad news, seems to run fine locally, with that script i had ~2k iterations before i killed it
[13:33] <mborzecki> cachio: let me try that under spread
[13:33] <cachio> mborzecki, I can generate a debug session on gce
[13:40] <jdstrand> cjwatson: hey, so I've got this in my snapcraft.yaml (https://paste.ubuntu.com/p/kmCRMGGCkk/; note, I tried https://paste.ubuntu.com/p/WPSBFbbPhs/, but that didn't seem to work (didn't pull in gcc-multilib on either amd64 or arm64), but I digress)
[13:41] <cjwatson> jdstrand: this is all up to snapcraft I'm afraid; LP has no say in that
[13:41] <jdstrand> cjwatson: this successfully pulls in gcc-multilib on amd64 (good), but on arm64, it does not. it seems that gcc-multilib is gcc-multilib:armhf in the archive and the chroot in LP doesn't include armhf on arm64
[13:42] <cjwatson> jdstrand: LP chroots have indeed never had cross-architecture config, and are unlikely to
[13:42] <cjwatson> if snapcraft needs that then it has to set it up itself
[13:42] <jdstrand> cjwatson: on amd64 gcc-multilib is in gcc-multilib:amd64, not gcc-multilib:i386
[13:42] <jdstrand> in the archive
[13:43] <jdstrand> so I'm a bit puzzled by either snapcraft, the chroot or the archive
[13:43] <cjwatson> this is really just something we dispatch and let other tools deal with it.  I can only reiterate that nobody should be expecting the base image (chroot) to contain foreign-architecture config
[13:44] <jdstrand> interesting
[13:44] <jdstrand> so I'm just lucky that I could install gcc-multilib on amd64
[13:44] <mup> PR snapd#6800 opened: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <https://github.com/snapcore/snapd/pull/6800>
[13:44] <cjwatson> I guess ... I've only used that in very limited cases
[13:44] <jdstrand> cjwatson: ok, thanks
[13:45] <cjwatson> I think in general gcc's multilib config is supported in Ubuntu only where there's been a positive need for it
[13:46] <cjwatson> I guess you'd need to talk to Matthias about that though
[13:46] <jdstrand> cjwatson: in my 'sudo classic' chroot on arm64 device, installing gcc-multilib works great, but it has armhf configured. interesting, in trying to reproduce this I see:
[13:46] <jdstrand> $ sudo dpkg --remove-architecture armhf
[13:46] <jdstrand> dpkg: warning: cannot remove non-foreign architecture 'armhf'
[13:47] <cjwatson> perhaps that's actually its native architecture; try dpkg --print-architecture
[13:47] <jdstrand> $ dpkg --print-architecture
[13:47] <jdstrand> arm64
[13:48] <jdstrand> which is why I came to you. things aren't quite lined up in all the different places
[13:48] <cjwatson> Uh.  Pass :)
[13:48] <jdstrand> I can accept that classic chroot is wrong
[13:48] <mborzecki> cachio: can reproduce that, somehow appears more often with --strace='-tt'
[13:49] <cjwatson> You do also get that message if the architecture hasn't actually been added to dpkg as a foreign architecture (try "dpkg --print-foreign-architectures")
[13:49] <jdstrand> but it seemed odd that gcc-multilib was in the amd64 part of he archive and not in arm64, but instead in armhf
[13:49] <cjwatson> I suppose it could be that the classic environment just crowbarred that package in
[13:49] <cjwatson> Well, that's entirely up to the gcc maintainers
[13:50] <jdstrand> dpkg --print-foreign-architectures prints nothing. anyway, like I said, I'm fine to accept the classic chroot is setup wrong
[13:50] <cachio> mborzecki, nice
[13:50] <cjwatson> And classically multilib has required non-trivial per-architecture effort to maintain
[13:50] <jdstrand> interesting
[13:51] <jdstrand> ok, well, now I'll ask kyrofa and sergiusens how I can setup snapcraft.yaml so it adds armhf lines if I use gcc-multilib:armhf
[13:51] <jdstrand> kyrofa, sergiusens: ^
[13:51] <jdstrand> cjwatson: thanks
[13:52] <cjwatson> np, I think that's likely to be the best path
[13:54] <jdstrand> kyrofa, sergiusens: recall that on arm64 I have a makefile that will detect the SNAPCRAFT_ARCH_TRIPLET and decide if it should build some binaries with -m32. I can't use -m32 without gcc-multilib, but I can't install gcc-multilib on arm64 in LP because the chroot doesn't have cross build env by design (see above) and sources.list doesn't include armhf lines
[13:55] <jdstrand> kyrofa, sergiusens: (this isn't an issue on amd64 since by chance, I only need amd64 configured to install gcc-multilib, but on arm64 I need gcc-multilib:armhf)
[13:56] <jdstrand> kyrofa, sergiusens: if there is a path forward today, I'd like to use it, but since I've got amd64 working with -m32, I can skip this on arm64 if I need to
[13:58] <jdstrand> kyrofa, sergiusens: as an aside, I thought this would (try to) install gcc-multilib on amd64 and arm64, but gcc was always installed: https://paste.ubuntu.com/p/WPSBFbbPhs/. I worked around it with this: https://paste.ubuntu.com/p/kmCRMGGCkk/
[13:59] <mup> PR snapd#6791 closed:  overlord: update static attrs when reloading connections (2.39) <⛔ Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6791>
[14:02] <mborzecki> ps -ef | grep /sbin/strace shows that we're leaving some strace processes behind
[14:06] <sergiusens> jdstrand: I don't think we support commas there, have you tried multiple "on" statements?
[14:07] <sergiusens> I also don't think we ever tested the construct of having "on, else" statements with just plain packages listed, if that works, great I guess
[14:07] <mup> PR snapd#6741 closed: osutil,cmdutil: move CommandFromCore and make it use the snapd snap (if available) <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6741>
[14:09] <mup> PR snapd#6801 opened: snapstate,devicestate: add snapstate.DeviceCtx to checkSnap* <Created by mvo5> <https://github.com/snapcore/snapd/pull/6801>
[14:12] <jdstrand> sergiusens: multiple on works fine. I read the docs on advanced grammar and they suggested that would work. that isn't the part I care most about though. its installing gcc-multilib:armhf on arm64 in LP:
[14:12] <jdstrand> Could not find a required package in 'build-packages': gcc-multilib:armhf
[14:12] <jdstrand> Build failed
[14:12] <jdstrand> sergiusens: this is because the arm64 chroot in LP intentionally leaves out armhf. is there something I can do today to make this work in LP?
[14:14] <jdstrand> sergiusens: (again, it's ok if there isn't, I'll just move on, but if there is, I'd like to do it)
[14:19] <sergiusens> jdstrand: the "add ppa hack" from the forum could work by overriding the pull step and apt updating
[14:20] <sergiusens> jdstrand: I think that now that we assume all environments where run are disposable, we can certainly "try" and enable the arch from our repo handler
[14:20] <sergiusens> if you don't mind logging a bug, that would be great
[14:23] <mvo> mborzecki: 6759 keeps on giving - now it fails in google:centos-7-64 .../tests/main/base-snaps#
[14:23] <mvo> mborzecki: it seems to be a real issue
[14:24] <mvo> mborzecki: I see that it fails to exec snap-exec - https://paste.ubuntu.com/p/BZ5VQY2cjK/
[14:24] <jdstrand> sergiusens: do you use launchpad bugs or github issues?
[14:24] <mborzecki> mvo: hmm
[14:24] <mvo> mborzecki: which is strange as we did not change anything here
[14:24] <mvo> mborzecki: I have a meeting now so can't dig deeper
[14:24] <sergiusens> jdstrand: lp bugs, our issue tracker on github is closed
[14:25] <jdstrand> ok
[14:25] <sergiusens> that said, I have been looking into using github projects, need to convince mvo of something we can consolidate on
[14:27] <mborzecki> mvo: fails only on centos and amzn2, /etc/os-release is not a symlink on either distro, wonder if that could cause something (and wouldn't explain why it happens only now)
[14:28] <mvo> sergiusens: I would not mind using gh projects, I just did not investigate this much yet
[14:28] <mvo> mborzecki: interessting
[14:29] <mvo> mborzecki: I guess its related to us no longer using cgo in some interessting and yet mysterious way
[14:32] <sergiusens> mvo let's discuss in Lyon... I really like the cross project functionality of LP bugs, but it misses all the nice features of things built around 2010, like a nice dashboard to manage milestones and such... and since our code is on github, auto closing issues becomes much easier
[14:33] <jdstrand> sergiusens: ok, filed https://bugs.launchpad.net/snapcraft/+bug/1827067. let me know if you need anything else
[14:33] <mvo> sergiusens: sounds good, lets sit together in lyon
[14:33] <mup> Bug #1827067: need a way to add foreign architecture to sources.list for build-packages/stage-packages <Snapcraft:New> <https://launchpad.net/bugs/1827067>
[14:40] <mborzecki> mvo: snap-exec is not a static binary
[14:46] <cachio> jamesh, hi, could you please take a look to this change 6541
[14:46] <kyrofa> jdstrand, (cc sergiusens) regarding your last point first, we do support commas but the grammar enforces an AND relationship, not an OR
[14:46] <cachio> #6541
[14:46] <mup> PR #6541: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
[14:46] <kyrofa> e.g. `on amd64,ubuntu` or `on armhf,fedora`
[14:46] <cachio> jamesh, any suggestions about how to improve that, still failing sporadically
[14:47] <sergiusens> kyrofa: compressed nesting; I wish we had better syntax for that... I completely forgot about that scenario and assumed the opposite on first read
[14:48] <mvo> mborzecki: its not? hm, how did that work in the past then - I mean, this test?
[14:48] <kyrofa> sergiusens, maybe it SHOULD be... but yeah
[14:48] <mborzecki> mvo: idk, everything seems to be in order
[14:48] <mborzecki> mvo: /usr/lib/golang/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=tDnwG8u1pBmUWQO10qzA/_x6vj92SB3p958rhGThv/9RCsi
[14:48] <mborzecki> VE8AphCR9FsbPHc/tDnwG8u1pBmUWQO10qzA -B 0x2b904b806d8f25f00e904ab996b99be6dc650588 -extldflags "-Wl,-z,relro  -static" -extld=gcc $WORK/b001/_pkg_.a
[14:49]  * mvo weeps a bit in the corner
[14:49] <mborzecki> mvo: -static seems to be passed to gcc/ld
[14:49] <mvo> mborzecki: oh, so by not having gcc anymore we loose this? that makes sense
[14:50] <mvo> mborzecki: now the question is how to pass -static to go without cgo
[14:52] <mborzecki> mvo: CGO_ENABLED=0 basically :) but, ther's something fishy about that still
[14:52] <Chipaca> pedronis: silly question about context (the go one), as i've seen opinions on both sides: would it be the right place to use to store the client's user-agent to then send it to the store? that was my plan way back before i read people saying context was evil or sth
[14:52] <ogra> jdstrand, hmm, i think mvo added some code to fix alternatives in core itself in the past. perhaps the classic snap needs some adapting to that
[14:54] <pedronis> Chipaca: in a meeting
[15:08] <pedronis> Chipaca: I think the best use case is a layer talking to itself across others, but once context is around there be some other legitimate use cases
[15:08]  * zyga lunch
[15:08] <pedronis> or not too bad abuses
[15:09] <pedronis> 2nd reviews of https://github.com/snapcore/snapd/pull/6731 would be appreciated
[15:10] <mup> PR #6731: overlord: make the store context composably backed by separate backends for device asserts/info etc <Created by pedronis> <https://github.com/snapcore/snapd/pull/6731>
[15:11] <mborzecki> mvo: CGO_ENABLED=0 or -buildmode=pie seems to trigger the right behavior, but the PIE build fails as centos glibc-statc was not built with -fPIC
[15:11] <mborzecki> mvo: oh, and the same macro on fedora adds -buildmode pie
[15:15] <mup> PR snapd#6802 opened: overlord/ifacestate: update static attributes of "content" interface <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6802>
[15:49] <cachio> jamesh, hi
[15:49] <cachio> jamesh, could you please take a look to #6541
[15:49] <mup> PR #6541: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
[15:58] <mup> PR snapd#6803 opened: daemon, o/snapstate, store: support for installing from cohorts <Created by chipaca> <https://github.com/snapcore/snapd/pull/6803>
[16:00] <Chipaca> pedronis: i'll review composable thing this evening if nobody else has gotten to it
[16:00] <Chipaca> now i'm going for a run, i think
[16:07] <jdstrand> kyrofa: that would explain while that wouldn't work there. it could never be true. thanks!
[16:12]  * zyga makes more progress :)
[16:12] <zyga> ltrace was the missing link towards visibilty of what was going on
[16:13] <zyga> quick coffee break is deserved :)
[16:52] <mvo> pedronis: 6778 is green and I addressed your points, let me know if I can do more
[16:54] <pedronis> let me look
[16:56] <pedronis> mvo: it looks fine, I don't know how likely those files are to change soon?
[16:57] <mvo> pedronis: you mean the dbus ones? that is not likely but I was refering to the auto-install snapd when needed PR :)
[16:58] <mup> PR snapd#6800 closed: snapstate: revert "overlord/snapstate: remove PlugsOnly" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6800>
[17:01] <pedronis> mvo: there is the the question about the signature of coreSnapInstalled and snapdSnapInstalled
[17:02] <mvo> pedronis: if its considered important I can change it, the call side will become a bit more unwieldy - but happy to do that
[17:03] <pedronis> mvo: I think it would be better to differentiate the errors
[17:04] <mvo> pedronis: ok, I will update the code (after dinner)
[17:08] <zyga> re
[17:52] <zyga> Bike break
[18:28] <pedronis> mvo: I fixed an annoying spread failure in my other PR, let me know if you want me to re-review something else today
[18:29] <mvo> pedronis: 6778 should be ready in ~5min
[18:29] <mvo> pedronis: but given that things will not be ready tonight anyway its fine to do all of this tomoorow
[19:03]  * cachio afk
[19:58] <mup> PR snapd#6804 opened: [RFC] store,daemon,client: allow user-agent setting for Search() <Created by mvo5> <https://github.com/snapcore/snapd/pull/6804>
[20:10] <mup> PR snapd#6805 opened: interfaces/docker-support: support overlayfs on ubuntu core <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6805>
[21:10] <mup> PR snapd#6806 opened: snapcraft.yaml: include libc6 in snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6806>
[23:05] <mup> PR snapcraft#2545 opened: catkin plugin: use build-packages for compilers <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2545>
[23:23] <mup> PR snapcraft#2546 opened: [legacy] catkin plugin: ensure cxxflags are consistent <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2546>


[00:57] <micahg> DktrKranz: hi, pkg-multimedia would like a new version of scons, but I'm wondering what impact that has on existing packages, do all the rdepends need a rebuild?
[04:24] <arand> The authour section in the manpage, does that refere to the manpage or the application?
[04:27] <lifeless> manpage I believe
[04:28] <lifeless> probably best to be explicit though
[04:29] <arand> ok, cheers
[06:01] <Mase_wk> hi guys, i am trying to package an application and I would like it to add it's directory to the PATH on installation. What is the preferred way to do this ?
[06:01] <micahg> Mase_wk: to not do this at all...why can't you install in the appropriate existing paths
[06:04] <Mase_wk> good question. I guess there is no real reason at all other than the install guides telling me to set it up this way
[06:06] <Mase_wk> micahg: this is a small python utility which dynamically looks at the path of the executable to see where it should load the rest of it's components from
[06:06] <Mase_wk> i think i would have to change that behavior to jam it in /usr/bin
[06:06] <Mase_wk> is there a recommended way of doing that or should i just hard code it ?
[06:07] <Mase_wk> it has a bunch of xslt, xml files as well as other python libs
[06:08] <micahg> Mase_wk: I'm not so familiar with python utilities
[06:08] <RAOF> The xslt, xml stuff sounds like it wants to go in /usr/share/$PACKAGENAME, and the other python bits treated differently.
[06:09] <ScottK> The actual executable should still go in /usr/bin even though it's written in Python.
[06:09] <Mase_wk> RAOF: right, so i'm not really sure what the best way to modify this application to make that happen is. Do i go through and hardcode it , or should i try an make it a config option and upstream it ?
[06:10] <Mase_wk> at the moment it's reasonably dynamic, you just run the binary and it figures out where stuff is.
[06:10] <RAOF> Yeah, but it's wrong :)
[06:10] <RAOF> Or, at least, that's not *NIX-y.
[06:10] <Mase_wk> yeh i understand that, i am just trying to work out how best to modify it
[06:11] <RAOF> If you can see a clean way to do it upstream, that's better.
[06:11] <RAOF> If you can't, it's ok to distro-patch.
[06:11] <Mase_wk> hmm ok thanks
[07:48] <arand> How can I run a lintian check on a plain manpage without having to go through the build procedure?
[08:04] <dholbach> good morning
[11:36] <X3lectric> hi guys, im trying to uplaod to my ppa, but lately idk why the orig.tar.gz gets stuck at 93622k out of 93623k
[11:36] <X3lectric> irrespective of file size
[11:43] <geser> X3lectric: I've heard about this "last 1k" problem, but don't remember what the issue is or if it's fixed or can be worked-around, try asking in #launchpad
[11:43] <geser> I see you're already there
[11:45] <Laney> it's a dput bug
[11:45] <Laney> or a bug which is exposed by dput
[11:45] <Laney> bug 193848
[11:46] <Laney> I think you can work around it by using sftp
[11:46] <Laney> X3lectric: ^^^^
[11:50] <Bachstelze> that's weird
[11:50] <Bachstelze> it's old, but I never had this issue
[11:50] <X3lectric> Laney: thx
[11:51] <Laney> it depends on how your router handles passive FTP I think
[12:03] <X3lectric> Laney: my router has no problems with passive ftp, its not a home network error
[12:04]  * X3lectric knows networking backwards
[12:59] <Laney> good for you
[13:12] <X3lectric> Laney: this is a actual bug that ppa upload ned to bypass ftp and use sftp but the config for sftp on dput is proving a chanllenge
[13:13]  * X3lectric is not ppa/launchpad jedi
[13:14]  * X3lectric is not even bzr experienced
[13:15] <Laney> X3lectric: https://help.launchpad.net/Packaging/PPA/Uploading#SFTP%20and%20older%20versions%20of%20Ubuntu
[13:16] <X3lectric> ya read that
[13:16] <X3lectric> Permission denied (publickey)
[13:16] <X3lectric> Unable to connect to SSH host ppa.launchpad.net; EOF during negotiation
[13:17] <Laney> you need to add your ssh key into launchpad
[13:17] <X3lectric> google is not helping either
[13:30] <X3lectric> Laney: it is added man
[13:31] <X3lectric> https://launchpad.net/~x3lectric
[13:35] <c2tarun> I was trying to install the build dependencies for a package and I got this error http://paste.kde.org/6685/, what is meaning of this error?
[13:37] <X3lectric> c2tarun: try running a-t-get install -f
[13:37] <X3lectric> er
[13:37] <X3lectric> apt-get install -f
[13:38] <c2tarun> X3lectric: here is what I got 0 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
[13:39] <X3lectric> try installing the deps again
[13:39] <X3lectric> you my wanna check wahts not getting upgraded
[13:40] <X3lectric> idk kde
[13:41] <X3lectric> apt-get install -f is supposed to fix any broken packages
[13:42] <c2tarun> X3lectric: here are the build dependencies reported by dpkg-checkbuilddeps r-base-dev r-cran-xtable r-cran-spc r-cran-maptools r-cran-vcd r-cran-msm r-cran-vr r-cran-colorspace r-cran-matrix   while installing them I am getting the same error.
[13:42] <X3lectric> dpkg --configure -a
[13:43] <X3lectric> you may want to remove the respective packages from /var/cache/apt/archives/
[13:43] <c2tarun> X3lectric: nothing happened, no output. What is the problem exactly?
[13:43] <X3lectric> broken packages
[13:44] <X3lectric> http://www.google.co.uk/search?q=Broken+packages&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a
[14:01] <c2tarun> does dpkg-checkbuilddeps checks dependencies mentioned in debian/control file?
[14:22] <c2tarun> I got this error while building a package http://paste.kde.org/6690/, when looked into file I found this line creating the problem http://paste.kde.org/6689/ I need help with the second argument passed in the function, what does it mean? is it typecasting?
[16:49] <DktrKranz> micahg: which version? I pushed 2.0.1 soon after squeeze, isn't that enough?
[16:50] <micahg> DktrKranz: yeah, but natty only has 2.0.0, so I'm wondering about an FFe, I just want to know how bad it affects everything
[16:51] <DktrKranz> micahg: scons upstream is *very* smart about that, so minor versions are all about bugfixes
[16:52] <DktrKranz> there could be some new features, but backward compatibility is almost always a guarantee
[16:52] <micahg> DktrKranz: ok, what about rebuilds, do we need them for all build-depends or just stuff that is experiencing issues
[16:52] <DktrKranz> (e.g. 1.X -> 2.X was a no-op for most of the rdeps)
[16:52]  * micahg thought he saw a new feature or 2, which would require an FFe
[16:52] <DktrKranz> no need to rebuild
[16:53] <DktrKranz> I don't think there will be any differences
[16:53] <DktrKranz> except failing packages which become buildable :)
[16:53] <micahg> DktrKranz: ah, ok, that's great news, thanks
[16:54] <DktrKranz> if you want, I could setup a test framework to rebuild all rdeps, just to make sure it works
[16:55] <DktrKranz> (long time I didn't manage that, though)
[16:55] <micahg> well, I just want to make the release team happy
[16:57] <DktrKranz> also, some rebuilds have been managed by lucas in debian, no major issues reported
[19:54] <delimiter> anyone can mentor me? I'm having trouble getting a package built for redis
[19:57] <Bachstelze> delimiter: what's the problem?
[19:59] <delimiter> I'm trying to get redis 2.2.2 built. when I do the pbuilder build step it bombs out. See http://pastebin.com/mAjUVzuw
[20:20] <LLStarks> what do i apport against if i have a needs-packaging
[20:22] <kklimonda> you don't
[20:23] <kklimonda> you just open a new bug by hand
[20:33] <delimiter> Bachstelze: presumably debian/tmp/redis-server should be auto created since "Package: redis-server" is in debian/control
[20:41] <Bachstelze> delimiter: not 100% sure but I think so, yes
[20:54] <LLStarks> kklimonda, but file against ubuntu, right?
[20:58] <kklimonda> LLStarks: yes
[21:15] <psusi> so is there some sort of magic bridge that connects gtk signals to dbus signals?
[21:24] <broder> psusi: yes, but it's not pure magic. you ahve to tell glib about the dbus signals you care about
[21:25] <broder> hmm...actually i'm not sure if that's true with gdbus. it was with dbus-glib
[21:26] <psusi> ok.  now things are starting to make sense... now if I could just find this magic bridge...
[21:26] <broder> psusi: are you using gdbus or dbus-glib?
[21:27] <psusi> dunno, I'm looking at gnome-power-manager and UPower
[21:27] <broder> dbus-glib, then
[21:27] <broder> at least for g-p-m
[21:27] <psusi> and don't really know anything about gtk or dbus before today ;)
[21:27] <broder> (happened to have the code in front of me already)
[21:27] <psusi> ohh?
[21:28] <broder> so i don't know how things work if you're generating proxy classes from dbus introspection data
[21:28] <broder> but if you're just using DBusGProxy, you use dbus_g_proxy_add_signal to tell the object to listen for the signal
[21:28] <psusi> I've been studying it trying to understand how the gpm gconf keys to disable locking the screen and starting the screen saver got broke... at least when you choose to suspend from the menu
[21:28] <broder> and dbus_g_proxy_connect_signal to setup a callback
[21:30] <psusi> then I think the SIGNAL_SUSPENDING in gpm is vestigial now and should be removed... it is no longer part of the dbus interface and I can't find any code connecting to it within gpm...
[21:31] <psusi> hrm... if you add an argument to a dbus signal, will that break existing clients, or will they just ignore the new argument?
[21:44] <broder> it depends on the framework, but it will likely break existing clients
[21:55] <psusi> broder: damn... so adding an argument to a well known interface like org.freedesktop.UPower.Sleeping is a no go?  Have to add a whole new signal or a property to get the desired info instead?
[21:55] <broder> yeah
[21:56] <broder> i'm fairly positive that python-dbus, at least, would blow up. i think gdbus and dbus-glib will both depend on implementational details, but you'd have to be pretty lucky
[21:56] <broder> networkmanager has had to do this before - c.f. /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.{sleep,Sleep}
[21:57] <broder> well, those are methods not signals, i guess
[21:57] <lucidfox> Oh crap, I seem to have flooded Planet Ubuntu with old posts
[21:57] <lucidfox> any way to undo that?
[21:58] <micahg> slingshot around the sun?
[21:58] <psusi> broder: so something like add a SuspendingEx() signal that has the argument, and emit both?
[21:58] <psusi> err, SleepingEx() rather
[21:59] <broder> psusi: yeah, i think so. or expose the extra piece of information as a property, and sufficiently intelligent clients can query for it when they get the Sleeping signal
[21:59] <psusi> micahg: even doing that, you'd never get to warp factor 10 with current technology ;)
[21:59] <micahg> psusi: that didn't seem to be a requirement before...
[22:00] <warp10> psusi: do you need some warp10?
[22:01] <psusi> micahg: that was the purpose of slingshotting around the sun... to get the kingon bucket of bolts to warp factor 10 for timewarp ;)
[22:01] <micahg> psusi: warp 10 wasn't infinite in TOS, only in TNG and on, and this is getting too offtopic, happy to continue discussion in PM
[22:18] <lucidfox> Okay, I've fixed the RSS so that it outputs the correct dates (it previously formatted month names in Russian...)
[22:19] <lucidfox> will the posts with wrong dates disappear from the front page automatically upon next update?
[22:20] <soren> lucidfox: I think so.
[22:24] <lucidfox> Yay, they went away
[22:24] <lucidfox> foosh
[22:43] <ari-tczew> hellooooo


[01:40] <dude_> can someone help me with openoffice dra?
[01:40] <dude_> *draw?
[01:43] <dude_> please?
[02:11] <bazhang> dude_, have you tried #openoffice.org
[03:07] <kedster> hey
[03:07] <kedster> how is everyone
[07:02] <Animagladius> Night
[07:04] <tygertung> hello
[07:04] <tygertung> is this working?
[08:17] <Vishal> hi everybody
[08:21] <akring> datw -u
[08:21] <akring> date -u
[11:06] <Animagladius> Hi.
[12:49] <ark_> hi ppl
[12:49] <ark_> what's this place?? sorry can anyone tellme
[14:24] <ksdfpr1> hi to all
[14:24] <ksdfpr1> can anyone explain what to do to work my sata (here is the way http://wiki.debian.org/pata_marvell but I m only few minutes user!!!
[14:34] <ksdfpr1> can anyone explain what to do to work my sata (here is the way http://wiki.debian.org/pata_marvell but I m only few minutes user!!!
[14:36] <brookie> hola
[14:36] <brookie> anyone know where the xorg.conf file is in karmic?
[14:37] <pleia2> ksdfpr1, brookie - try #ubuntu for support, this channel is for hosting irc-based classes
[14:37] <pleia2> won't find much help here, I'm afraid
[14:37] <ksdfpr1> ok
[14:38] <brookie> okay, sorry, thought it was a help irc...will come here later though for a class. sounds fun
[14:38] <brookie> cheers
[21:45] <Yaslana> Hey all
[21:47] <m4tic> i need a simple python tutorial for beginners
[21:51] <Yaslana> Anyone have lots of experience with setting up stubborn wireless network cards?
[21:52] <Yaslana> I may have serious need of help >_>


[10:11] <upbaz> !ops
[10:11] <upbaz> bazhang from faggot land
[10:15] <chu> Nice
[10:20] <k1l> isnt he from the same country?
[10:20] <chu> lol
[17:43] <Myrtti> nixoeen: hi
[17:45] <nixoeen> Myrtti: Hey :) You have the access to edit https://wiki.ubuntu.com/IRC/ChannelList ? :)
[17:49] <Myrtti> I probably do, why?
[18:21] <Myrtti> ok then
 Hey, anyone has access to edit https://wiki.ubuntu.com/IRC/ChannelList? The contact person of #ubuntu-ir should be changed there.
[18:24] <k1l> but i still dont know to what it should be changed
[18:29] <k1l> nixoeen: to what do you want the contact person to be changed?
[18:29] <k1l> or whom
[18:30] <nixoeen> Myrtti, k1l: The contacts persons of #ubuntu-ir should be changed from zwnj, MehdiHassanpour to nixoeen, MehdiHassanpour.
[18:36] <k1l> you are the only contact person then?
[18:37] <k1l> nixoeen: i see MehdiHassanpour  and a_skywalker are still listed in the access list of that channel
[18:39] <k1l> and MehdiHassanpour beeing the ir-council leader
[18:45] <nixoeen> k1l: No, MehdiHassanpour stays as one of the contact persons as well. So : "nixoeen, MehdiHassanpour"
[18:49] <k1l> nixoeen: ok
[18:50] <nixoeen> k1l: Great, thanks :)
[21:32] <dax> CIA: i note icesword/yehai evading a ban set on his old cloak using his new cloak about 11 hours ago in here ^
 k1l does not mean k1l. Period.
[21:32] <k1l> i did not even talk to him or to any other user while he joined
[21:33] <Flannel> k1l: That's because it's the same guy.
[21:34] <Flannel> dax: I have the feeling we'll be using that again soon. :P
[21:34] <k1l> yep, its the same guy, using another proxy or tor endnote
[21:35] <Unit193> Flannel: Perhaps, but it makes bots angry.
[21:35] <Flannel> The bots perhaps should be fixed then.


[03:27] <lamalex> DBO, do you know anything about the nvidia 260 driver?
[03:27] <lamalex> works? improvement from what's in natty?
[03:28] <lamalex> trying to get dual monitors working
[04:30] <coz_> lamalex,  if its any consolation... I am running the 260 driver with dual monitors
[04:30] <lamalex> coz_, i got it working with regular natty
[04:30] <lamalex> it's running awesomely
[04:30] <lamalex> disper is a great piece of software
[04:30] <coz_> lamalex,  oh ok sorry... I know you brought this up a while ago
[04:31] <lamalex> coz_ I had just asked dbo if he had done it
[04:31] <lamalex> I hadn't tried it myself
[04:31] <lamalex> I've been in the process of moving
[04:31] <coz_> ah ok :)
[04:31] <lamalex> and my external monitor was sitting in my new apt
[04:31] <coz_> lamalex,  moving is always apain
[04:31] <lamalex> finally moved today :)
[04:31] <lamalex> specially 800 miles
[04:31] <coz_> yikes
[04:31] <coz_> lamalex,  from where to where?
[04:32] <lamalex> Philly to Portland, ME (if you don't know US geography just say so)
[04:32] <coz_> lamalex,  I live outside of pittsburgh ...
[04:32] <coz_> :)
[04:34] <coz_> lamalex,  like to visit philly on occasion
[04:34] <coz_> lamalex,  probably Portland is much safer :)
[04:34] <lamalex> oh yeah?
[04:34] <lamalex> I've lived in Philly my whole life
[04:34] <lamalex> (well, a mix of the city and the burbs)
[04:34] <lamalex> until .. today
[04:34] <coz_> lamalex,  how is Portland ?
[04:34] <lamalex> and an 8 week stint in Paris
[04:34] <lamalex> really nice
[04:34] <lamalex> really really nice
[04:35] <coz_> lamalex,   I bet more relaxing also ..yes?
[04:35] <coz_> and maybe colder ??
[04:35] <lamalex> haha yes
[04:35] <lamalex> quite a bit
[04:35] <lamalex> cleaner air, more nature, less of everything
[04:35] <lamalex> except nature..
[04:36] <coz_> :)
[04:36] <lamalex> I might move to NYC next just to make up for lost time, haha
[04:36] <lamalex> My dad is a huge Steelers fan
[04:36] <coz_> lamalex,  oh no!!! I lived in Queens fro about ayear
[04:36] <lamalex> haha
[04:36] <lamalex> My grandmom is from the Bronx
[04:36] <coz_> lamalex,   then he can tell you the stories :)
[04:36] <lamalex> I think I still have some family scattered about the boroughs
[04:37] <Omega> You had an afro for a year eh coz_.
[04:37] <coz_> Omega,  no but my hair was down to my waiste at that time lol
[04:37] <Omega> You just said you had a fro for a year ):
[04:38] <coz_> lol
[04:38] <coz_> bad typing
[04:38] <Omega> :P, I know, I'm just teasing.
[04:38] <coz_> :)
[04:43] <coz_> lamalex,  what are your feeling about global menu on dual monitors?
[04:43] <coz_> feelings  rather
[04:58] <coz_> hey guys....  I was asked to bring the ccsm icon set here ... i suppose you guys are going to put these in ?
[04:58] <lamalex> coz_, dont know yet honestly
[04:58] <lamalex> I got it working and haven't needed it hah
[04:59] <lamalex> I wish the panel didn't extend across the entire desktop for one thing
[04:59] <coz_> lamalex,  understood...  I have been doing the ccsm icons for a while now...  there is an issue with the unity icon someone put in the set
[04:59] <lamalex> I think mac does it the way we do it (so while that's not everything it's something)
[05:00] <lamalex> It really depends how we want to define what the multi-monitor experience in Unity is about
[05:00] <coz_> lamalex,  does what...the icons for ccsm???
[05:00] <lamalex> coz_, aren't we talking about dual monitors?
[05:00] <coz_> lamalex,  oh lol no
[05:00] <coz_> lamalex,  i was talking about the icons for ccsm
[05:00] <lamalex> i don't know anything about that
[05:01] <coz_> lamalex,  ok
[05:01] <lamalex> are there icons? are they pretty?
[05:01] <coz_> :)
[05:01] <coz_> lamalex,  I can send you the current set
[05:01] <coz_> lamalex,   http://dl.dropbox.com/u/132551/compiz%2B%2B/ccsm-Tango.tar.gz
[05:02] <lamalex> erm, I don't think there's anything I can/should do with them
[05:02] <coz_> lamalex,  no problem
[05:02] <lamalex> if you think it's the wrong icon file a bug
[05:02] <lamalex> Canonical is closed this week
[05:02] <lamalex> so it might take another few days for you to hear back
[05:02] <coz_> lamalex,  yes the Unity plugin icon  is wrong for the set  for sure
[05:02] <lamalex> but come the new year we will look at it
[05:03] <coz_> whoever put that icon in has created a visual bug
[05:03] <lamalex> I vaguely remember a merge request about it
[05:03] <lamalex> but like I said, file a bug report and attach the correct icon
[05:04] <coz_> lamalex,  well  that's a bit difficult since I have been doing the ccsm icons... if they want someone else to do them I think they need to speak with me ...yes?
[05:05] <coz_> whatever... I will wait til next week
[05:05] <lamalex> coz_, someone probably just filed a bug and it got merged in a hurry
[05:05] <lamalex> no harm no foul
[05:06] <lamalex> just a misstep :)
[05:06] <coz_> ok  cool
[05:06] <coz_> I will see what next week brings :)
[05:06] <lamalex> bug me again after new years and I'll make sure it gets looked at
[05:07] <coz_> lamalex,  ok ... I suppose I just really need to know if I am out of the picture doing these icons  and if canonical design team are taking it over
[05:08] <lamalex> coz_, I really have no idea
[05:08] <coz_> understood
[05:08] <lamalex> you can try sending an email to the ayatana list
[05:08] <lamalex> and filing a bug and adding ayatana-design as a project
[05:08] <coz_> I might do that  after next week
[05:08] <lamalex> then someone from design team will look at it
[05:09] <coz_> lamalex,  well its an entire set of icons not just one  ..and it has been the default icons for ccsm for some time now
[05:09] <coz_> but anyway  ,,,next week :)
[05:09] <lamalex> ccsm had its own set of icons?
[05:09] <coz_> yes
[05:09] <lamalex> see, that seems like a bug
[05:09] <coz_> still does
[05:09] <lamalex> well, not really
[05:09] <coz_> a visual bug is still a bug :)
[05:09] <lamalex> but Unity has a brand identity so it makes sense to use the shipped unity icon
[05:09] <coz_> I agree
[05:10] <coz_> wait maybe I misunderstood you
[05:10] <coz_> lamalex,  the current unity plugin icon is the bug with the set .. I am not sure it matters if it is the "official" unity icon ..it doesnt belong with the set
[05:11]  * lamalex looks at ccsm to try and understand
[05:12] <lamalex> ok so what's really the problem?
[05:12] <lamalex> it looks fine to me?
[05:12] <coz_> lamalex,  well ... the  purple Ubuntu Unity Plugin icon looks fine?
[05:13] <coz_> http://dl.dropbox.com/u/132551/NEEDED%20DESKTOP%20STUFF/ccsm/plugin-unityshell.png    << is the current icon
[05:14] <coz_> this is one of the ones I chose    http://dl.dropbox.com/u/132551/compiz-unity/ubuntuunityplugina.svg
[05:14] <coz_> it fits more closely with the entire set... it can also use a little work
[05:16] <lamalex> yeah, see I would imagine we have very specific brand guidelines for what the uniy logo is, just like we do for Ubuntu circle of friends and so on
[05:16] <lamalex> that's a nice icon, but it's not the unity log
[05:16] <lamalex> o
[05:16] <coz_> lamalex,  but this is compiz
[05:16] <lamalex> Unity is a product
[05:16] <coz_> lamalex,  not unity
[05:17] <lamalex> Unity should be able to supply it's own icon to ccsm, even if that means ubuntu distropatching ccsm
[05:17] <lamalex> idk, that's my opinion
[05:17] <lamalex> I'm certainly not an authority on the matter
[05:17] <coz_> no  I disagree but its out of my hands
[05:17] <coz_> it would create a visual bug
[05:18] <coz_> and that seems contrary to the whole concept
[05:18] <coz_> none the less.. it is after midnight here so I am off to bed :)
[05:19] <lamalex> the same
[05:19] <lamalex> goodnight
[05:19] <coz_> yep  same to you
[08:25] <Devil505> hi
[08:26] <Omega> Hello.
[08:26] <Omega> And with that, I hit the hay.
[08:26] <Omega> Goodnight!
[08:28] <Devil505> bye :)
[18:30] <coz_> good day all
[20:49] <lallenlowe> how is Unity handling the maximized window controls, is it an indicator?
[21:17] <lallenlowe> anyone?
[22:59] <lallenlowe> does anyone know how Unity is handling the maximized window controls, is it an indicator?


[14:18] <BUGabundo> yo o/
[18:00] <fta> chrisccoulson, hey, back home?
[18:13] <chrisccoulson> fta - yeah, i'm back home now
[18:13] <fta> how was your flight?
[18:14] <chrisccoulson> it wasn't too bad. it wasn't full, which is unusual, so it was quite a comfortable flight
[18:14] <chrisccoulson> i even slept for a couple of hours too, and then slept for another 3 hours this afternoon at home
[18:17] <fta> i can't sleep in planes
[18:17] <fta> painful when i have to go to california or china
[18:22] <chrisccoulson> yeah, i don't normally sleep on planes. i took some over-the-counter sleep aid tablets with me, and they made me drowsy enough to sleep for a little bit
[18:22] <chrisccoulson> i'm glad that the next UDS is not that far away :)
[18:24] <fta> where is it?
[18:24] <chrisccoulson> the next UDS is in budapest
[18:24] <chrisccoulson> can't remember the exact date yet though
[18:29] <fta> 1400km from paris