[08:39] <mup> Bug #2017938 changed: Missing ability to automatically activate Windows Server 2022 <MAAS:Invalid> <https://launchpad.net/bugs/2017938>
[08:54] <mup> Bug #2009209 changed: snap deployed maas is not able to use openstack nova power type due to missing python3-novaclient dependency <MAAS:Won't Fix> <MAAS 3.3:Won't Fix> <https://launchpad.net/bugs/2009209>
[09:00] <mup> Bug #2009209 opened: snap deployed maas is not able to use openstack nova power type due to missing python3-novaclient dependency <MAAS:Won't Fix> <MAAS 3.3:Won't Fix> <https://launchpad.net/bugs/2009209>
[09:03] <mup> Bug #2009209 changed: snap deployed maas is not able to use openstack nova power type due to missing python3-novaclient dependency <MAAS:Won't Fix> <MAAS 3.3:Won't Fix> <https://launchpad.net/bugs/2009209>
[13:54] <mup> Bug #2019210 opened: move away from abstractproperty which is deprecated <MAAS:New> <https://launchpad.net/bugs/2019210>
[14:24] <mup> Bug #2019216 opened: Flaky test- dhcp notify <MAAS:New> <https://launchpad.net/bugs/2019216>
[14:27] <mup> Bug #2019216 changed: Flaky test- dhcp notify <MAAS:New> <https://launchpad.net/bugs/2019216>
[14:30] <mup> Bug #2019216 opened: Flaky test- dhcp notify <MAAS:New> <https://launchpad.net/bugs/2019216>
[15:54] <mup> Bug #2019229 opened: 3.4.0~beta1 maas-region-api fails to start with pylxd 2.3.2~alpha1-420-10-g.72426bf~ubuntu22.04.1 <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/2019229>
[15:57] <mup> Bug #2019229 changed: 3.4.0~beta1 maas-region-api fails to start with pylxd 2.3.2~alpha1-420-10-g.72426bf~ubuntu22.04.1 <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/2019229>
[16:00] <mup> Bug #2019229 opened: 3.4.0~beta1 maas-region-api fails to start with pylxd 2.3.2~alpha1-420-10-g.72426bf~ubuntu22.04.1 <cdo-qa> <foundations-engine> <MAAS:New> <https://launchpad.net/bugs/2019229>
[16:54] <mup> Bug #2019235 opened: `machines creates` complain about invalid architecture while it's in fact missing an image <MAAS:New> <https://launchpad.net/bugs/2019235>
[17:00] <mup> Bug #2019235 changed: `machines creates` complain about invalid architecture while it's in fact missing an image <MAAS:New> <https://launchpad.net/bugs/2019235>
[17:03] <mup> Bug #2019235 opened: `machines creates` complain about invalid architecture while it's in fact missing an image <MAAS:New> <https://launchpad.net/bugs/2019235>


[19:30] <akgraner> pleia2, I popped into ubuntu-devel and asked for people to check the calendar - Do you want me to email Ubuntu-devel for some reason I thought I had
[19:31] <pleia2> you did
[19:31] <akgraner> oh ok
[19:31] <pleia2> https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034419.html :)
[19:31] <akgraner> Oh good :-)
[19:33] <akgraner> I saw the exchange with mdz - so I just wanted to double check - I should have pulled up the archives and just looked
[19:33] <pleia2> yeah, no one reads email
[19:33] <pleia2> hehe
[19:33] <akgraner> so it seems :-)
[19:38] <Myrtti> acute case of geranium
[19:38] <Myrtti> :-P
[19:38] <Myrtti> it's an old joke
[19:38] <Myrtti> "went to a doctor and he said I've got geranium" "eh what" "yeah. have you seen my new dementias on the windowsill?"
[19:39] <Myrtti> and I've got selective geranium myself
[19:39] <Myrtti> so I'm no better :-/
[20:49] <akgraner> pleia2, new RT ticket filed - cc'd editors, you and elmo


[00:02] <IrcsomeBot1> <Tolga Erok> Unable to connect to windows shared printers. Kubuntu 20.04
[06:11] <Quantos> Hi, KUbuntu 20.04 LTS x64 - when I partition and format a drive why do I then have to take ownership of it?
[06:11] <Quantos> That should be part and parcel of partitioning and formatting
[06:13] <Quantos> For some reason the drives belong to root, I don't really want to do this for every drive
[06:15] <Quantos> The same thing happens whether I tried KDE Partition Manager or GParted
[06:17] <diogenes_> that's because you have to run gparted as root, use gnome-disk-utiloty
[06:17] <diogenes_> utility*
[06:17] <Quantos> Why is it doing the same thing with KDEPM?
[06:18] <Quantos> Is it something I set up wrong?
[06:18] <diogenes_> i have no clue about kde.
[06:18] <Quantos> Oh okay
[06:18] <Quantos> Fair enough
[06:18] <Quantos> Thanks, I'll give that utility a try
[06:18] <Quantos> I appreciate it
[06:37] <Quantos> diogenes_: Cheers mate, fixed it up quality :P
[06:37] <Quantos> Have a great evening
 Fwd from SharGen19: How to remove those drivers and revert back
 (Photo, 1280x720) https://irc-attachments.kde.org/1t8PmNLn/file_39231.jpg I installed drivers from here and it causing errors
 Help me please 🥺
[07:25] <viewer|56> Bonjour,
[07:25] <viewer|56> Hello
[07:26] <viewer|56> i have a computer with windows 10 and i want to install kubuntu
[07:27] <viewer|56> with USB key, installation begin normally but when i am at the stage LVM there is my USB key but not main disk partition
[12:54] <BluesKaj> Hi folks
[14:39] <user|60> (kubuntu 20.04,,,plasma 5.18.5,,,frameworks 5.68.0,,, qt 5.12.8,,, kernel 5.4.0-54 ) dolphin search function stopped working. can't find a file I'm looking at. ran balooctl disable, then purge the enable ,,, still the same problem. looked at many support forums, no suggestions helped
[14:41] <BluesKaj> try the find command in the konsole
[14:41] <BluesKaj> or locate
[14:44] <user|60> I tried [ ~& find *pol* ]  nothing. tried [ ~& locate *pol*]   it found only one file. I place 2 files with names containing 'pol'
[14:50] <user|60> tried this  [ find . -name "*pol*" ]     it worked and found all the files that contain    pol  in their names
[15:08] <user|60> I'll just continue to use the terminal. never had a problem with  dolphin until now. web search highlighted the same problem reported by many #?# but no practical solutions offered...
[15:11] <tinom> Hello
[15:16] <tinom> Kate is a good code editor, but i have a bug. Chinese chars will Sink a few pixels, when the Chinese chars and English chars in the same line, "_" will be hidden. Does anyone have the same problem?
[15:41] <IrcsomeBot1> <Tolga Erok> Hi all. I'm having trouble with kubuntu accessing the network printers. States forbidden access/maintenance?  … I have edited my smb.conf file so the system can see and connect to my USB on my smb1 router.  … I.e. …  client min protocol = NT1 …  server min protocol = NT1
[17:18] <not_me_again> Hi, I'm trying to install Kubuntu to a somewhat troubling system and Grub2 is not overwriting the old grub2 even though I'm very certain that it's writing to the right drive (/dev/sda no partition number)
[17:19] <not_me_again> it installs sucessfully but then on reboot the old grub2 gets loaded
[17:19] <not_me_again> for what it's worth I'm using GPT with real BIOS
[17:22] <eeos> not_me_again: do you ave the grub into a separat boot partition?
[17:23] <not_me_again> Hmm... actually, that might be the case.. yes
[17:23] <not_me_again> so, /dev/sda1?
[17:24] <not_me_again> Or rather, is it that grub2 is by default installing to it but there's another grub in the mbr?
[17:28] <eeos> not_me_again: are you sure that is the partition and not the whole disk? Can you run a df for me , please?
[17:28] <not_me_again> It's on a different device but I can do that soon as I just re-installed kubuntu with the bootloader on an old USB stick and that is booting right now
[17:29] <not_me_again> What would you expect to see in df? By boot partition I mean the legacy bios partition that's available with GPT - it would not show up in df output
[17:30] <not_me_again> /boot is on the @ subvolume (using btrfs for /)
[17:31] <eeos> not_me_again: I think it could be useful to format the boot partition again, that is what I would do, a reinstall the grub
[17:32] <eeos> not_me_again: not sure grub can go into btrfs though .... never tried that.
[17:38] <not_me_again> /boot is perfectly fine on btrfs as long as grub2 understands the features in use i.e. 20.10 supports raid1c34 feature but grub2 might be too old to understand it; it might also not like zstd compression - 20.04 definitely didn't like it, iirc
[17:39] <not_me_again> but /boot only contains the later parts of grub(2) - the core bootloader has to be where the BIOS/UEFI can find it which would be MBR or ESP
[17:43] <not_me_again> also /boot isn't a partition - it's just a subfolder of / which itself is a btrfs subvolume named @ as is kubuntu default
[17:44] <not_me_again> anyway, I think I'll just keep on booting from the usb stick - it's old and too small for modern live usb images so I didn't really have anywhere else to use it anyway. Thank you for tyring to help
[17:44] <not_me_again> Bye, bye.
[21:50] <thenanaomonster> can you help me with ubuntu
[21:50] <thenanaomonster> paste.ubuntu.com
[21:51] <Mamarok> thenanaomonster: you just ask the questiooh well...
[21:51] <Mamarok> so much for zero aptience...
[21:51] <Mamarok> patience, eve
[21:51] <Mamarok> n
[22:59] <Armendz> hello
[23:00] <Armendz> can't install Kubuntu on Ideapad
[23:00] <Armendz> i get, AMD Vi : Unable to write to IOMMU
[23:34] <rogier> So I found an old PC in the street. Put KDE NEON. It works great.
[23:34] <rogier> I had to replace the hard disk data cable but other than that it's great. It has an AMD proccesor plenty of memory and a nvidea videocart
[23:34] <rogier> There is a huge coolblok? on the cpu. Only problem the fans in front an behing make a lot of noise.
[23:34] <rogier> I installed simple system monitor and it is running at 11 degree celcius.
[23:34] <rogier> If I stop the fans it goes to 20
[23:35] <rogier> degree
[23:35] <rogier> Is this okey? Can I just remove the fans?
[23:35] <rogier> I stop them now with some papers stuffed in them. But would rather just remove them


[00:12] <hggdh> stpere, probably, yes. I do not consider 2.24.3 stable enough, so it will probably be a SRU
[00:12] <stpere> SRU?
[00:13] <greg-g> Stable Release Update
[00:13] <stpere> oh ok
[00:13] <stpere> thanks
[00:13] <stpere> because I'm having a very bad bug here
[00:13] <greg-g> https://wiki.ubuntu.com/StableReleaseUpdates
[00:13] <stpere> a sent email that get sent over and over again
[00:13] <stpere> everyday
[00:13] <stpere> it doesn't get out of outbox
[00:14] <stpere> it's marked as deleted in the outbox, so it's hidden
[00:14] <stpere> but is sent again anyway
[00:14] <stpere> very embarrassing
[00:31] <hggdh> indeed, and I have not heard of such before
[00:36] <savvas> the pythonistas bugs really need a check for incomplete/invalid/outdated bug reports: https://bugs.launchpad.net/~pythonistas/+packagebugs
[00:40] <Rocket2DMn> can somebody who knows something about backtraces have a look at bug 325903 and tell me if they think the root of the problem is in lib4vl
[00:40] <Rocket2DMn> im terrible at reading down traces
[00:41] <sectech> why does it have a "Medium" and a "new" status?
[00:41] <Rocket2DMn> bug 322368 actually crashes at the same line in telepathy's nain
[00:41] <Rocket2DMn> main*
[00:42] <Rocket2DMn> sectech, i think apport does that when it gets a complete backtrace
[00:42] <sectech> Ahh ok...
[00:42] <sectech> explains a few that I have seen previously then
[00:42] <Rocket2DMn> yaeh its actually getting fairly common
[00:42] <sectech> I actually had a person report a bug against a "known problem" which he even quoted was in the release notes.
[00:43] <sectech> I guess he didn't read to NOT report bugs related to those.
[00:43] <Rocket2DMn> lol
[00:44] <sectech> I didn't want to spend too much time for that one so I kindly explained that it was a known issue, hence his quote of the release notes and set it to "Won't fix" so he couldn't fiddle with the status
[00:44] <sectech> I could have dup'd it by searching for the original issue, but the point would seem kind of moot
[00:44] <Rocket2DMn> heh, well, any ideas about those traces?
[00:45] <sectech> Hmm let me pull up the bug
[00:45] <Rocket2DMn> im thinking actually since there are 2 bugs crashing initially at the same line in the program, it is a program problem
[00:45] <Rocket2DMn> not a lib4vl issue
[00:46] <sectech> First I would look through the traces for sensitive information, and if there is none mark it public
[00:46] <sectech> I'm not the best at traces but I'll see if anything pops out at me
[00:46] <hggdh> Rocket2DMn, this seems to be  an abort signal from glib
[00:47] <Rocket2DMn> good to know hggdh , how can you tell that glib is the source of the problem?
[00:47] <Rocket2DMn> i mean, glib is in practically every gnome crash report
[00:48] <hggdh> oh, I cannot. signal 5 is sigabrt, a request to abort the programme
[00:48] <hggdh> glib generated it
[00:48] <hggdh> probably as a result of the processing in first entry in the BT
[00:49] <sectech> hggdh, where did you see the sig 5?
[00:49] <hggdh> in the title and the description of the bug
[00:49] <sectech> heh, helps if I scrolled up
[00:49] <sectech> I was looking though the traces
[00:50] <hggdh> this is more probably an issue in the package itself (telepathy)
[00:51] <Rocket2DMn> ok hggdh , but the big question is: how do i know the true source of the problem
[00:51] <hggdh> heh
[00:51] <nschembr_> I think I found a bug in the livecd boot process. I need to talk to some before I submit a bug report.
[00:52] <Rocket2DMn> hggdh, both bugs i listed crashed at the same line in the program's main.c, a lot of the traces are similar, but they end differently at 0
[00:52] <hggdh> Rocket2DMn, you would have to go to the source, and look it up in the glib docs on why it would generate an abort
[00:52] <hggdh> huh -- I had not noticed the second bug
[00:53] <Rocket2DMn> /headdesks
[00:53] <nschembr_> any one working on the livecd
[00:54] <hggdh> Rocket2DMn, yes, both of them ended in sigabrt. Also both BTs show that glib is processing an assertion, and that this assertion failed
[00:54] <hggdh> perhaps the users were running with --g-fatal-warnings ?
[00:55] <Rocket2DMn> i have no idea what that option is
[00:55] <hggdh> any failed assertion will cause the programme to terminate
[00:55] <Rocket2DMn> so you think the bug needs to be filed against glib?
[00:56] <Rocket2DMn> glib2.0 to be specific
[00:56] <hggdh> Rocket2DMn, I do not think so, not so far
[00:57] <hggdh> I do not know telepathy, so this can still be a telepathy issue
[00:57] <hggdh> although glib bugs do happen, they are quite rare
[00:57] <Rocket2DMn> that's what i would hav einitially thought
[00:57] <Rocket2DMn> look at the bottom of both stacktraces, they crash at the samea line in main
[00:58] <Rocket2DMn> stream-engine-main.c:335
[01:00] <hggdh> yes -- this is probably where it is registering itself with glib
[01:01] <Rocket2DMn> so i guess i should file this against telepathy on freedesktop
[01:02] <hggdh> yes, sounds so
[01:03] <Rocket2DMn> man there are a fair number of bugs reported, how the heck am i supposed to find dups
[01:03] <Rocket2DMn> wish they had a dup-finder like gnome
[01:05] <Rocket2DMn> hmm none jump out at me
[01:07] <hggdh> yes, this would help -- the dup finder rocks
[01:24] <Rocket2DMn> ok, i have question about defining an upstream link on LP
[01:25] <Rocket2DMn> telepathy-stream-engine package has no upstream links defined, and i think "stream-engine" is what is needed
[01:25] <Rocket2DMn> I was going to add that as an upstream series, but i'm not 100% sure
[02:39] <hggdh> Rocket2DMn, sorry for the delay, in a work technical discussion
[02:39] <hggdh> Rocket2DMn, you copy copy & paste the link to the bug upstream
[02:39] <hggdh> s/copy copy/just copy/
[02:48] <Rocket2DMn> hggdh, say again?
[02:48] <Rocket2DMn> i asked in #launchpad and they said to go ahead and make the connection
[02:49] <Rocket2DMn> hggdh, bug 322368 - i connected that ubuntu package with stream-engine (which is part of Telepathy)
[02:50] <Rocket2DMn> that package didnt have an upstream project associated with it yet
[02:52] <Rocket2DMn> anyway, thanks for the help, im signing off now.  peace
[05:39] <saivann> bdmurray : In case you're here, my membership in the bugcontrol team is about to expire and I would like to ask you to renew my membership if possible. I've not been as active with bugs in 2008 compared to 2007 but I'm still contributing when I have time and I expect to continue in that way in the next years.
[05:41] <saivann> bdmurray : I'm going outside now but if you want, you can email me at anytime or ping me on IRC
[10:30] <shankhs> was navigating through LP to prepare for the Global Bug Jam I ran into this : https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/294991 the page says that its confirmed then triaged and I think its an upstream bug(right?) is there any more information I can get about this bug?
[10:33] <shankhs> anybody there?
[10:38] <dholbach> shankhs: what do you want to know exactly?
[10:38] <dholbach> it's an upstream bug, yes
[10:38] <dholbach> one part of it seems to be fixed upstream already
[10:39] <dholbach> just click on the links in the "assigned to" column
[10:50] <shankhs> dholbach: there are 2 links. both of them are trying to fix the bugs? Or is it that the bug affects both of them?
[10:50] <dholbach> that's what I think
[10:50] <dholbach> but I did not investigate it muchly and am no expert
[10:52] <shankhs> dholbach: it also says that the bug is triaged and is confirmed that its an upstream bug then why ubuntu bothers to keep it in LP why not let gnome tackles it ?
[10:52] <dholbach> shankhs: we still track it in LP, it's not resolved yet
[10:53] <bdmurray> In case there is a fix upstream that we want to add as a patch to the ubuntu package.
[11:03] <pedro_> shankhs: btw empathy bug is already fixed on jaunty, but a task in Ubuntu for telepathy-sofiasip needs to be open to keep tracking of the upstream one
[13:23] <calc> a couple bugs that i noticed that make triaging a bit harder are bug 291968 and bug 291980
[13:26] <calc> bdmurray: do you know how to escalate issues like the above to the launchpad team?
[13:26] <calc> bdmurray: i didn't know if this meeting was the appropriate place to raise the above issues
[14:45] <kagou> Hi
[14:46] <kagou> where should I report bug for the gnome login sound (glitches)... pulseaudio ?
[14:46] <kagou> in 9.04
[14:53] <bdmurray> mvo bug 274737
[14:59] <mangilimic> kagou: I think that the best place for that kind of bugs is gnome-control-center , although I'm not an expert so... let's wait for some more suggestions!
[15:01] <kagou> may be seb128 have a better idea ?
[15:02] <seb128> no clue, open a pulseaudio bug on launchpad
[15:03] <kagou> thanx
[15:03] <kagou> cya
[15:03] <mangilimic> kagou: :)
[15:04] <mangilimic> kagou: I told you that it was better to wait for some more suggestions!
[15:39] <allquixotic> With the new updates, Kubuntu networkmanager works in Jaunty again :)
[16:16] <kagou> mangilimic, at leat my bug report is confirmed by someone else :)
[16:36] <thekorn> MrKanister, I updated the hugday-tools package in my PPA this morning, I should work now without pulling py2.4
[16:37] <thekorn> this sqlite thing should also be fixed
[16:40] <MrKanister> thekorn: Thank you very much. The "hugday init" now works with "--cookie" (the ppa version), I will try the "--moinmoin-id" way later
[16:41] <thekorn> super, thanks fr testing
[16:42] <MrKanister> thekorn: Great. "--wiki-id" is working like a charm :)
[16:49] <thekorn> cool, if you have any ideas how this tool can be improved, I'm happy to hear about them
[16:50] <pedro_> thekorn: I've added an agenda item to the QATeam for next week asking for testing on the hugday-tools
[16:51] <pedro_> btw folks if you have something to discuss https://wiki.ubuntu.com/QATeam/Meetings
[16:51] <pedro_> something new and cool you want to talk about just add it
[16:51] <pedro_> gotta run now, see you later guys
[17:41] <mbwjr12> hey all
[17:46] <mbwjr12> on Ubuntu's website, under the BugSquad section, under Getting Involved, I think there is a bug in the link to bugs without a package.
[17:46] <mbwjr12> the entire top part of the list are bugs that need packaging, and i believe this is a different problem
[17:47] <mbwjr12> or, it might be a bug in the search for bugs without a package, as requests for packages inherently have no package
[18:02] <thekorn> mbwjr12, I think the problem here is that an important part is missing in the descriptive text of this section on the wiki page
[18:02] <thekorn> something like "there are also some workflow related bugreports, like needs packaging bugs"
[18:05] <thekorn> I'm bad in phrasing such texts
[18:10] <mbwjr12> thekorn: using the advanced search function to find bugs without packages also returns bugs with [needs-packaging] in them
[18:13] <thekorn> mbwjr12, right, because all this needs packaging bugs are not targeted to any package/project yet
[18:15] <thekorn> and this is what should be explained on this wiki page, that there are alot of easy to triage bugs where the reporter was unable name a package,
[18:15] <mbwjr12> thekorn: right, the search function is correct, they don't have a package. however, i think it would makes more sense not to list them because they will never have a package, they will be closed whenever they do get a package
[18:17] <mbwjr12> can i just assign them a package with the name of whatever they want packaged?
[18:17] <thekorn> but there are also this "needs packaging" workflow bugreports
[18:18] <thekorn> no, because this package does not exist in ubuntu, and so it does not exist in launchpad
[18:18] <thekorn> unfortunatly it is impossible to exclude this kind of bugs in the searchresults in launchpad
[18:20] <thekorn> because there is no "exclude" tags (or similar) option in the search (yet)
[18:21] <mbwjr12> ok
[18:22] <thekorn> rule of thumb is: don't touch such workflow bugs unless you know what you are doing
[18:23] <thekorn> and this has to be added to this "getting involved" page
[18:25] <mbwjr12> using the same page to show bugs, and according to https://wiki.ubuntu.com/Bugs/HowToTriage/ under the section "Needs Packaging Bugs", there are number of bugs which need to have the wishlist status assigned to them if they aren't already in ubuntu or debian
[18:26] <mbwjr12> for instance, this bug https://bugs.launchpad.net/ubuntu/+bug/263554 needs to be confirmed and set to wishlist importance.
[18:27] <mbwjr12> i see that i have permissions to confirm it, so should i confirm it and then let someone else come along and decide the importance? what is the proper course of action to take?
[18:28] <charlie-tca> Normally, you mark it confirmed and then request here it be marked wishlist
[18:28] <mbwjr12> ok
[18:29] <mbwjr12> i have another question, brb
[18:30] <sectech> I marked that bug as wishlist
[18:30]  * thekorn is wondering if the reporter of this bug is a (spam) bot or something
[18:31] <sectech> Although the license part needs to be corrected. "open source" is a  little vague
[18:31] <mbwjr12> thekorn: lol, this is what my next question was going to be
[18:31] <thekorn> he filed about 600 bugs, almost all of them seem to be autogenerated needs packaging bugs
[18:31] <mbwjr12> why do people think that will somehow make ubuntu more likely to include the package?
[18:32] <thekorn> maybe this is the reason why is account has already been deaktivatid
[18:33] <charlie-tca> That would seem logical
[18:34] <mbwjr12> so what would be the thing to do with this bug?
[18:34] <sectech> Which bug?
[18:34] <mbwjr12> https://bugs.launchpad.net/ubuntu/+bug/263554
[18:34] <sectech> As in here and bug-control will mark it as wishlist
[18:35] <sectech> If it looks complete, which it wasn't.  It had the license as being "open source". I found the package source and verified it as GPL
[18:35] <sectech> and corrected it
[18:35] <thekorn> I think we should talk to the motu guys how they would like to handle this 600 bugs, maybe close them all as invalid by a script
[18:36] <thekorn> and ask to reopen it if somebody really wants to have this package in ubuntu
[18:37] <mbwjr12> i also just found the source and it looks to affero gpl v3
[22:26] <maxb> There isn't any way to get apport to attach its stuff to an existing bug report is there?
[22:26] <charlie-tca> none that I know. Usually just have to use duplicate


[09:39] <FLOZz> Hello all  _o/
[09:40] <mac_v> !logs
[13:04] <dashua> Good morning.
[13:06] <SiDi_> heya dashua
[13:07] <dashua> Hey SiDi_
[13:07] <dashua> How's things?
[13:08] <SiDi_> fine, you ?
[13:08] <dashua> Good good.
[13:09] <dashua> Had a silly idea with the gconf settings in notify-osd.
[13:09] <dashua> Not even sure if it would be possible, but I don't see why not.
[13:09] <dashua> Would a compiz plugin be possible?
[13:10] <SiDi_> hm
[13:10] <SiDi_> I dont know anything about compiz :P
[13:10] <SiDi_> but surely, i think its possible
[13:10] <SiDi_> all you have to do is manipulate keys, so w/e app using gconf / xfconf is compatible
[13:11] <SiDi_> of course the compiz plugin wouldnt work on xubuntu :p
[13:11] <dashua> Yeah, that's the problem
[13:11] <SiDi_> anyway, since we dont use gconf, we'll have to have our own 'theming' utility aside from the one used for the gnome notify-osd
[13:11] <dashua> There's already a positioning code for edge behaviors
[13:11] <SiDi_> so that shouldnt stop you
[13:12] <dashua> I'll look into it.  I'm not sure of the compiz code as it is being rewritten
[13:12] <SiDi_> Actually
[13:12] <SiDi_> a python app correctly written could handle both
[13:13] <dashua> The configuration menu is in python.
[13:13] <SiDi_> for now i think the best is to let notify-osd mature and let it land in karmic, w/out exposing the features
[13:13] <SiDi_> then i'll see how i can write an app that can be put directly into the xfce settings window
[13:14] <dashua> Nice
[13:14] <SiDi_> that app could also be used w/ gconf, i think (since you can handle import errors very very easily in python)
[13:16] <dashua> Ah
[13:28] <mac_v> dashua: look at how dust does the compiz changes
[13:28] <mac_v> you could just copy the file and use your own settings
[13:29] <dashua> I was thinking of an actual plugin for CCSM that would be configurable.
[13:30] <dashua> But that may work just to set the gconf settings if notify-osd
[13:30] <mac_v> dashua: that would be too much work , compiz devs wont easily allow new plugins
[13:31] <mac_v> and cmopiz is too complex , a plugin has an impact on every other component
[13:31] <dashua> Yeah and I'm not familiar with the new C++ code
[13:31] <mac_v> compiz*
[13:31] <SiDi_> dashua: i'll probably write some notify-osd utilies at some tme
[13:31] <SiDi_> i began writing an history browser in vala but i'll probably go for python
[13:31] <dashua> SiDi_, Sweet.
[13:31] <SiDi_> so there will be only one package for n-o and n-o-xfce :p
[13:34] <mac_v> dashua: do you want any changes to the buttons? or are they fine as is?
[13:36] <dashua> mac_v, I have no problems thus far.  Waiting for input from other users, but nothing yet.
[13:36] <dashua> They look very good to me.
[13:37] <mac_v>  :)
[13:37] <dashua> Have you tested it out?
[13:37] <mac_v> dashua: other users? as in SiDi_ ;p
[13:37] <dashua> Hehe
[13:38] <SiDi_> metacity ?
[13:38] <SiDi_> i asks screenshots :)
[13:38] <SiDi_> let me know when you wanna release btw dashua so i'll do the xfwm the day before :p
[13:38] <SiDi_> (i know ive been lagging out the last few months, but well :P)
[13:38] <dashua> https://wiki.ubuntu.com/Artwork/Incoming/Karmic/Hanso?action=AttachFile&do=get&target=terminal_metacity.png
[13:38] <dashua> Ok cool
[13:39] <dashua> I have 0.3.1 for coming soon
[13:39] <mac_v> i'v used it and my obseravtions are almost the same since yesterday ;)
[13:40] <SiDi_> the menu button is definately sexy :)
[13:40] <SiDi_> dashua: do you have a screenshot of an app with a statusbar in the bottom ?
[13:40] <dashua> Not on the Wiki yet
[13:41] <dashua> You want a shot of Nautilus?
[13:42] <SiDi_> i saw one on the wiki
[13:42] <SiDi_> you didnt change the bottom of metacity till then, right ,
[13:42] <SiDi_> ?
[13:42] <dashua> http://www.ubuntu-pics.de/bild/23835/screenshot_014_964Kna.png
[13:42] <mac_v> dashua: 1: light shade for the metacity bottom , 2: use same maximize animation for both normal and maximized windows , 3: i prefer app icons ;p
[13:42] <dashua> No, that is still the same
[13:43] <dashua> mac_v, Get rid of the square you think?
[13:43] <mac_v> dashua: i would think the square is better for both , just use it reversed for the maximized windows
[13:44] <mac_v> or what you could do is
[13:44] <dashua> Ok, get rid of the arrows pointing inward and out then?
[13:44] <mac_v> dashua: use the square for normal and the prelight as the arrows
[13:45] <mac_v> if you want it that way^ , i have an idea of an icon for that
[13:45] <dashua> Ok, I'll try some variations
[13:47] <SiDi_> you should do something for the shadow of the forward label dashua :)
[13:47] <mac_v> dashua: if you are using the square , we can use the arrows on the sides of the square , similar to the fullscreen icons
[13:48] <mac_v> but without the square
[13:50] <dashua> SiDi_, The shadow I would like to change, but not sure how =/
[13:51] <mac_v> SiDi_: you cant...
[13:51] <dashua> mac_v, Cool, I will try these different variations
[13:51] <mac_v> dashua: let me know if you can :)
[13:51] <dashua> mac_v, I don't know of any way
[13:51] <SiDi_> mac_v: im sure you can ! :P
[13:51] <SiDi_> you can has cheezburger
[13:51] <dashua> Haha
[13:51] <mac_v> ;p
[13:52] <SiDi_> its the shadow of deactivated text in toolbars
[13:52] <SiDi_> that should be reachable :P
[13:52] <mac_v> dashua: where is the shadow variable set?
[13:52] <dashua> Insensitive text maybe?
[13:52] <mac_v> there *must* be something for that
[13:53] <mac_v> Cimi: hi... any ideas, where how shadows for the inactive text are set?
[13:53] <mac_v> *where/how
[13:54] <mac_v> dashua: insenstive text? i didnt understand?
[13:54] <SiDi_> dashua: i think its insensitive yes
[13:55] <dashua> Yeah, that changes the text, but not the shadow of the icons
[13:56] <mac_v> dashua: GtkStatusbar     ::shadow-type       	= GTK_SHADOW_NONE
[13:56] <SiDi_> yay
[13:56] <mac_v> dashua: GtkToolbar     	::shadow-type       = GTK_SHADOW_NONE
[13:56] <dashua> mac_v, w00t
[13:56] <dashua> Nice
[13:56] <mac_v> \o/
[13:57] <dashua> I already have those set though
[13:57] <Cimi> mac_v, in the engine, in the code
[13:57] <mac_v> thanks
[13:59] <mac_v> dashua: try shadow		= OUT   or shadow		= IN
[13:59] <dashua> Ok
[13:59] <mac_v> works for pixmaps , not sure how it works for the rest
[14:06] <mac_v> ah doesnt work :/
[14:08] <dashua> http://www.ubuntu-pics.de/bild/23844/screenshot_015_yo039j.png
[14:08] <dashua> Better?
[14:26] <SiDi_> YES :]
[14:27] <SiDi_> what does it give if you unsaturate the insensitive text ?
[14:28] <mac_v> dashua: \o/ how did you do that ?
[14:30] <Cimi> mac_v, fg[INSENSITIVE]
[14:31] <mac_v> Cimi: oh... thats what that is , hehe
[14:46] <SiDi_> dashua: could you please send me those desaturated status icons you use, with their sources if possible ?
[14:48] <mac_v> --
[14:48] <mac_v> Steve Dodier
[14:48] <mac_v> OpenPGP : 1B6B1670
[14:48] <mac_v> IRC : SiDi on irc.freenode.net
[14:48] <mac_v> Jabber<EMAIL_ADDRESS>[14:48] <mac_v><EMAIL_ADDRESS>[14:48] <mac_v> https://launchpad.net/~sidi
[14:48] <mac_v> lol! ;p
[14:59] <dashua> mac_v, I didn't change the icons, just the config
[15:00] <dashua> Just pushed them to trunk, now to the metacity
[15:00]  * mac_v checking
[15:01] <SiDi_> mac_v: whats wrong with my signature ? :P
[15:04] <SiDi> Damn ISP
[15:04] <SiDi> dashua: i dont know if you got my message :P
[15:04] <dashua> Which one?
[15:05] <mac_v> lol
[15:05] <SiDi> When i asked you if you could send me the panel status icons you use in your screenshot
[15:05] <SiDi> the grayish ones
[15:05] <SiDi>  w/ the sources if possible :p
[15:06]  * mac_v knows which ... hehe.... <evil grin>
[15:07] <dashua> Oh shit, thought that was mac_v
[15:07] <dashua> Too many names in here
[15:07] <SiDi> only mac_v you, SiDi_ and me
[15:07] <dashua> I have no sources it just does it in the theme
[15:07] <dashua> 50/50 shot andd I guess wrong =/
[15:07] <SiDi> send me the theme then please :P
[15:07] <dashua> Ok
[15:07] <mac_v> dashua: he's talking about humanity
[15:08] <mac_v> panel icons ;)
[15:08] <SiDi> mac_v: i dont think it was humanity x_x
[15:08] <SiDi> but yeah i speak about the panel iconz
[15:09] <dashua> I am confused now.  SiDi what theme are you asking for?
[15:09] <mac_v> dashua: he *is* talking about humanity and doesnt know it ;p
[15:09] <SiDi> https://wiki.ubuntu.com/Artwork/Incoming/Karmic/Hanso?action=AttachFile&do=get&target=desktop_full.png
[15:09] <SiDi> the one with the grey volume icon in this screenshot
[15:09] <SiDi> mac_v: i use humanity and never saw these icons :P
[15:09] <dashua> Oh yeah
[15:10] <dashua> They are mac_v's creations
[15:10] <SiDi> why is mac_v keeping secret icons out of my reach ? :P
[15:10] <mac_v> SiDi: they are in the humanity theme , latest revs
[15:11] <dashua> bzr branch lp:humanity
[15:11] <SiDi> i see
[15:11] <SiDi> i use the PPA
[15:11] <SiDi> got xcf/svg sources ? :P
[15:12] <dashua> No they are rendered in trunk
[15:12] <mac_v> SiDi: all the humanity icons are svg , just pull them from bzr
[15:12] <SiDi> okey
[15:13] <dashua> mac_v, The bars are back for nm-applet :)
[15:13] <dashua> No more circles, eh?
[15:13] <mac_v> dashua: the nm icons were not Dan's idea
[15:13] <mac_v> he didnt like them
[15:14] <mac_v> dashua: as i said earlier ,they dont match the rest of the icons which are crisp , Dan felt the same too , before i could even mention it he had them changed ;)
[15:14] <mac_v> already
[15:15] <dashua> Yeah, after you mentioned that I noticed it.
[15:16] <mac_v> dashua: the funny thing is , i had done a very similar icons as those but did not show Dan , because they didnt match the theme
[15:16] <dashua> I need to talk to Cory about getting those into Breathe, so much nicer
[15:16] <dashua> Or something similar
[15:16] <SiDi> mac_v: shouldnt audio-volume-muted show a little 'muted' cross ?
[15:17] <mac_v> yeah my thoughts exactly,
[15:17] <mac_v> SiDi: have to discuss it first
[15:18] <mac_v> thanks for reminding, i had been meaning to change that for 2 days :)
[15:19] <mac_v> SiDi: ^
[15:20] <SiDi> discuss it with kwwii ? :P
[15:20]  * mac_v wonders why SiDi thinks kwwii is the author
[15:20] <SiDi> kwwii is the main author of Humanity, right ?
[15:21] <SiDi> but i understood you're the author of these sexy icons, mac_v :P
[15:21] <mac_v> wrong
[15:21] <SiDi> oh ?
[15:21] <SiDi> why is it in his PPA then ? :/
[15:21] <mac_v> SiDi: for testing ,
[15:22] <mac_v> SiDi: Daniel Fore , you could have just checked the lp
[15:22] <SiDi> okey
[15:22] <SiDi> sorry for that confusion :P
[15:23] <mac_v> SiDi: we have been discussing this right under you nose in ayatana and you never knew it ,   it was so funny the other day when you kept asking kwwii
[15:23] <SiDi> mac_v: you're evil :D
[15:24] <mac_v> ;p
[15:36] <mac_v> dashua:	GtkButton      ::focus-line-width  = 0
[15:36] <mac_v> try adding that and check out how it looks^
[15:36] <SiDi> mac_v: oh you icon expert
[15:36] <SiDi> https://wiki.ubuntu.com/NotifyOSD?action=AttachFile&do=get&target=notify-osd-default-icon-set.png
[15:36] <SiDi> where are these wireless icons from ?
[15:36] <mac_v> SiDi: thats kwwii/mat_t
[15:37] <mac_v> SiDi: why the doubt?
[15:56] <SiDi> What do you mean by doubt  ?/P
[15:58] <wers> !theming
[15:58] <wers> !gtk
[15:58] <mac_v> SiDi: wondered why you asked about the notify-osd icons...?
[15:59] <SiDi> mac_v: i just didnt manage to find these in any theme
[15:59] <SiDi> i know usually the design document is modified by mat
[15:59] <SiDi> but i was wondering if you'd know which version of which theme these icons are in
[15:59] <mac_v> SiDi: it is in Human
[15:59] <SiDi> in karmic ? :p
[16:00] <mac_v> SiDi: oh those...! those were the initial designs... i think macSlow will has them
[16:01] <wers> If you like the humanity icon theme, i recommend checking out Erectus. Very complete, human-ish, and tango-compliant http://www.gnome-look.org/content/show.php/Erectus?content=100254
[16:01] <mac_v> SiDi: *i think macslow has them
[16:01] <mac_v> he uses them in his screencasts
[16:43] <mrdoob> http://ubuntuforums.org/showthread.php?t=1257165&page=2
[16:44] <mrdoob> thoughts anyone?
[16:46] <mac_v> mrdoob: is that your handy work? looking good :)
[16:46] <mrdoob> handy work?
[16:46] <mrdoob> I was trying to make it more simple :)
[16:47] <mrdoob> less borders
[16:47] <mrdoob> you know
[16:47] <mac_v> how was it previous;y , i remember it without the explanations , is that alpha 5?
[16:47] <mrdoob> top of the page = old
[16:47] <mrdoob> bottom of the page = new
[16:47] <mrdoob> I mean..
[16:48] <mrdoob> top of the page = current
[16:48] <mac_v> hehe , gotcha
[16:48] <mrdoob> bottom of the page = my suggestion
[16:48] <mac_v> mrdoob: have you tried to contact the guys?
[16:48] <mrdoob> which guys?
[16:48] <mac_v> who are doing the slideshow
[16:48] <mrdoob> no idea who it is doing it :)
[16:49] <mrdoob> that's the main problem I'm finding while trying to contribute
[16:49] <mac_v> ;)
[16:49] <mac_v> mrdoob: wait let me get you the link
[16:51] <mrdoob> did MadsRH did that one?
[16:53] <SiDi> MadsRH did the look of the current slideshow
[16:53] <SiDi> i remember helping him with css
[16:53] <SiDi> i think there is a ubuntu-slideshow lp project
[16:53] <mrdoob> ok, I'll ping him then
[16:59] <mrdoob> thanks SiDi
[17:00] <dashua> mac_v, Ok, I had it, then reverted
[17:05] <dashua> wers, Erectus is ok, Breathe combined with Humanity still makes the best set IMHO
[17:07] <wers> dashua, breath looks good but I still prefer Erectus because it fits the rest of the desktop. i know that trying to get the oxygen look is great but it will take a while before it oxygen-ize the whole desktop
[17:07] <wers> it will always lack visual consistency because apps will always follow tango guidelines
[17:09] <wers> as for Humanity, it's not really tango as well. i guess, it fits the preference of many users because of its modern look but for a larger audience (official themes for release), i prefer tango compliant ones
[17:09] <dashua> True, there are some inconsistencies but still is or was in  active development
[17:10] <dashua> mac_v, http://www.ubuntu-pics.de/bild/23853/screenshot_016_zcoidW.png
[17:10] <wers> yep. it's in very active development. it's nice to see where it is heading but before it completely changes every tango icon on the gnome desktop, they're not really for production imho
[17:10] <dashua> I don't like this focus and was a serious area of contention for the Human theme in Jaunty
[17:11] <mac_v> dashua: hmmm.. i didnt understand?
[17:11] <wers> dashua, which focus? the one on check buttons?
[17:12] <mac_v> dashua: i *hated* the lines around them , that was one of the reasons i was hunting for the focus
[17:12] <dashua> mac_v, I like the effect it has on the button itself but it does some ugly things elsewhere
[17:13] <dashua> I just remember it being a big issue in Human with the murrine engine
[17:13] <mac_v> hehe i thought it was better ;p
[17:13] <dashua> Cimi, fixed it right before release
[17:13] <mac_v> dashua: or try this> GtkButton      ::interior-focus	      = 0
[17:14] <mac_v> remove the previous line and try this one^
[17:15] <wers> i think, it would help if the focus is more pronounced. the solution could be keeping the lines or darkening the highlight
[17:16] <dashua> mac_v, I messed with all of the options and could not come to a reasonable compromise
[17:16] <mac_v> hehe ;p
[17:23] <dashua> mac_v, SiDi_, http://www.ubuntu-pics.de/bild/23855/screenshot_017_nn1xHq.png
[17:23] <dashua> Look better than the previous insensitive?
[17:24] <mac_v> looks better , :)
[17:24] <mac_v> dashua: which are the lines you adjusted?
[17:24] <dashua> The fg[INSENSITIVE]  for dark
[17:24] <mac_v> mrdoob: you need to get in touch with the ubiquity-slideshow mailing list...
[17:24] <SiDi_> yes dashua
[17:24] <SiDi_> much easier to read
[17:25] <dashua> It matches more along with the metacity
[17:25] <dashua> Ok cool, I thought so too :)
[17:25] <SiDi_> but i think you should try to make the saturation identical to the one of the icons dashua
[17:25] <SiDi_> ie. more grey
[17:25] <mac_v> eeek!
[17:25] <mac_v> no , its nice now :)
[17:26] <dashua> SiDi_, icons should be the same as before
[17:27] <dashua> Grey or brown, whatcha think?
[17:27] <mac_v> for which?
[17:27] <dashua> fg[INSENSITIVE] for dark
[17:28] <mac_v> dashua: give the current full value you are using  , let me test it out
[17:28] <dashua> fg[INSENSITIVE]   = "#664E30"
[17:29] <dashua> This is against the brown pixmap toolbar as well
[17:30] <mac_v> dashua: hmm... i think you have adjusted something else as well , its not the same for me as the screenshot
[17:31] <dashua> http://www.ubuntu-pics.de/bild/23856/screenshot_018_fI3nfw.png
[17:31] <mac_v> dashua: could you push to branch
[17:31] <dashua> There is SiDi_'s recommendation
[17:31] <dashua> Sure, grey or brown?
[17:32] <dashua> Consensus?
[17:32] <dashua> Out of the two last screenies
[17:32] <mac_v> hehe , i must say SiDi_ is always right
[17:32] <dashua> :P
[17:32] <mac_v> greay
[17:32] <mac_v> grey
[17:32] <dashua> Yeah, he is =/
[17:32] <dashua> Ok one sec
[17:33] <SiDi_> mac_v: dashua <3
[17:34] <mac_v> i imagined grey= lightgrey!
[17:34] <dashua> Pushed
[17:34] <SiDi_> with grey it is as easy to read but brings less the attention, making it more clear that its insensitive ;p
[17:34] <dashua> Thanks for the input
[17:34] <SiDi_> you're welcome
[17:34] <mac_v> dashua: what else is easier than input ;p
[17:34] <mac_v> ;)
[17:34] <dashua> You think that would look good on the unfocused metacity?
[17:34] <dashua> Brown now
[17:35] <mac_v> let me check
[17:35] <dashua> Let me test
[17:36] <mac_v> dashua: the humanity battery icons are fixed \o/
[17:36] <dashua> http://www.ubuntu-pics.de/bild/23857/screenshot_019_zNBkMq.png
[17:36] <dashua> Wow
[17:36] <dashua> That does look nice
[17:36] <dashua> mac_v, Sweet
[17:36] <dashua> I uninstalled g-p-m
[17:37] <dashua> Monitor would not sleep with it installed
[17:37] <mac_v> hmm... you can use $xset s 300
[17:37] <mac_v> that will solve it or
[17:37] <dashua> Yeah, I never had to that before
[17:37] <dashua> Something has changed
[17:38] <mac_v> dashua: that is not a gpm problem ,it is actually xorg problem
[17:38] <mac_v> the two just keep getting confused :/
[17:38] <mac_v> each thinks the other is working!
[17:38] <dashua> Yeah, but the patches were sent upstream for the xorg-xserver and they still do not work
[17:38] <dashua> I thought they were pushed to Karmic
[17:39] <mac_v> no they havent fixed xorg yet
[17:39] <mac_v> dashua: only gpm is fixed and the screensaver works fine now , no problems there
[17:40] <dashua> Hrm
[17:40] <dashua> I just get a black blank screen that is not asleep
[17:40] <mac_v> now the screen does go to sleep also.
[17:41] <dashua> Hrm ok, I don't really need g-p-m or haven't missed it thus far
[17:41] <mac_v> have you tried locking the screen?
[17:41] <dashua> I wish it would work though
[17:41] <mac_v> ;)
[17:41] <dashua> No, I didn't try that
[17:41] <dashua> Works fine on my netbook where I do need it to work
[17:42] <dashua> mac_v, Alright, lots of nice enhancements pushed to trunk
[17:42] <dashua> Now, I will mess the button icons
[17:42] <dashua> You guys are making this a killer theme :)
[17:46]  * dashua --> Lunch
[17:46] <dashua> Feel like MacSlow now ;)
[17:51] <SiDi_> dashua: /away /back
[17:51] <SiDi_> thanks :P
[18:01] <mac_v> phew... i feel much better after fixing the gpm icon problem! \o/ that drove me crazy
[18:05] <SiDi_> you ARE crazy
[18:39] <mrdoob> Another version...
[18:39] <mrdoob> http://ubuntuforums.org/showthread.php?t=1257165&page=3
[18:48] <mac_v> mrdoob: the forums is not a good place for the mockups :( , it wont reach the devs
[18:49] <mrdoob> Yeah I can imagine, but I find the mailing lists tedious :(
[18:49] <mrdoob> maybe with a bit of luck
[18:49] <mrdoob> someone will repost on their list
[18:49] <mac_v> if you are willing to contact the ML , alone any time spent is useful , else its just for your timepass
[18:50] <mrdoob> :)
[18:50] <mrdoob> I pinged MadsRH, he'll consider it if he likes it
[18:51] <mrdoob> better than subscribing to a ML, posting and unsubscribing
[18:51] <mac_v> mrdoob: did madsRh do the first one?
[18:52] <mrdoob> as far as I know, yes
[18:52] <mrdoob> http://anotherubuntu.blogspot.com/2009/08/ubiquity-slideshow-for-ubuntu.html
[18:53] <mac_v> mrdoob: man , you are lazier than me ;p
[18:54] <mrdoob> yeah
[18:55] <mrdoob> doing the bootscreen
[18:55] <mrdoob> I was told I should contact macslow
[18:55] <mrdoob> so he could let me know about the limitations
[18:55] <mrdoob> he never replied
[18:55] <mrdoob> the whole workflow is random
[18:55] <mac_v> mrdoob: i told you!
[18:55] <mrdoob> you told me he'll never reply?
[18:56] <mrdoob> or to contact him?
[18:56] <mac_v> mrdoob: people dont reply to mails unless they know who you are
[18:56] <mrdoob> haha
[18:56] <mrdoob> right
[18:56] <mrdoob> I do :P
[18:56] <mrdoob> oh well
[18:56] <mrdoob> bad luck
[18:56] <mac_v> u need to understand though you mean well , there are several who just spam!
[18:56] <knome> good evening
[18:56] <mac_v> since the email id in on the lp page
[18:57] <mac_v> knome: hola  ;)
[18:57] <knome> hello mac_v
[18:57] <mrdoob> yeah I understand that
[18:57] <mrdoob> but you know, I was linking to my work
[18:57] <knome> mac_v, is your nick pronounced like mac(gy)v(er)
[18:57] <mac_v> knome: hows the wallpaper coming?
[18:57] <mrdoob> I was kind of saying who I was, but well
[18:58] <knome> still http://emonk.fi/open/xubuntu/9.10/Mockups/06-hires.png
[18:58] <mrdoob> It'll last whatever it'll last
[18:58] <mac_v> knome: nope , it was an old one , it was supposed to mean mach 5
[18:58] <knome> a-ha!
[18:58] <knome> but should the v be a capital V in that case? :)
[18:58] <knome> *shouldn't
[18:59] <mac_V> better? ;)
[18:59] <knome> hehe yup ;)
[18:59] <knome> the romans had no "U" because it would have been too hard to write on a stone so it became just "V"
[19:00] <mac_V> interesting ... hm..
[19:01] <mac_V> yeah... thinking about it.... all the roman numerals are just scratches
[19:01] <knome> yup
[19:02] <mac_V> knome: hehe finally i ended making wireless icons for humanity ;p
[19:02] <knome> it's really intelligent otherwise as well as it uses minimum possible characters :P
[19:02] <knome> \o/
[19:02] <knome> i still haven't looked at humanity properly
[19:02] <knome> i should
[19:02] <mac_V> bzr branch lp:humanity
[19:03] <knome> i know
[19:03] <knome> i am not home right now
[19:03] <mac_V> oh
[19:03] <mac_V> the icon set is awesome , but i'v only done the panel icons
[19:04] <knome> yeah, SiDi is talking about it all the time
[19:04] <knome> ;)
[19:04] <mac_V> the funny thing was until today he didnt know who made them
[19:04] <knome> haha
[19:04] <mac_V> he kept constantly asking kwwii "you are the author of humanity, right?"
 :P
[19:56] <mac_v> SiDi: the mailman is slow , so you might not have recieved it
[20:19] <mac_v> SiDi: the volume mute has been edited
[20:21] <SiDi> mac_v: it lacks a cross :d
[20:21] <mac_v> yup , no cross ;p
[20:22] <mac_v> *every* theme does that!


[09:01] <dcz> hello guys
[09:01] <dcz> i am trying to use vte terminal while learning vala. i created a window and vte inside of it , but i cant type anything, here is my code http://hastebin.com/erogihiros.avrasm
[10:25] <maxed> Should analyzing (CPU profiling) my app on real device work from Ubuntu IDE? If so, are there any special actions I should take to make it work?
[10:36] <maxed> I think it needs valgrid to be installed on device. How do I do that?
[10:37] <ogra_> ubuntu
[10:37] <ogra_> lol ... EFOCUS
[11:07] <snizzo> how can I change header color? theme property appears not to be present anymore in both MainView and Page
[11:09] <snizzo> ok found
[13:12] <snizzo> appdevs i received the email saying my new version of an app has been published but on website interface it says pending for manual review. Is this normal?
[13:13] <beuno> snizzo, hi. It isn't, we're making some changes, it'll be back to normal on Monday
[13:13] <snizzo> beuno: ok. Here is a small picture of web interface http://i.imgur.com/K7N3zcw.png
[13:13] <snizzo> I'll check on monday :)


[00:22] <hads> ajmitch: Yeah, a local shop would fix that as you'd be paying GST anyway.
[00:32] <ojwb> though not the clearance fees
[00:32] <ojwb> and if you're gst registered...
[19:31] <ibeardslee> morning
[20:02] <ajmitch> morning
[20:19] <Atamira> morning
[20:29] <Atamira> say that ZaReason shop, when its gonna be open on the website anyone know?
[20:29] <Atamira> i wanna get my partner a laptop, preferably with ubuntu already on it
[20:29] <ibeardslee> You can order from the website now, to be delivered to NZ
[20:35] <Atamira> mmm
[20:46] <ibeardslee> we've had one guy from work already do that, and we have another couple looking at doing the same in the next few days.
[20:46] <ajmitch> hopefully there's enough demand here for the local shop
[20:49] <ibeardslee> yeah. the pricing will have to be competitive because "Battery Life: Up to 3 hrs." sure as hell ain't
[20:50] <ajmitch> maybe people looking for a cheap system to put a pirated copy of windows on :)
[20:50] <ibeardslee> meh, I look foor good systems that I don't have to pay for any copy of windows
[20:53] <chilts> morning
[20:53] <ajmitch> ibeardslee: not everyone is like you, though
[20:58] <ibeardslee> aye, this is true, there can only be so much awesome in the world ;)
[20:59] <ajmitch> I don't think we could handle another you
[21:30] <ojwb> morning
[21:52] <kcj> Morning.
[22:41] <hads> morning
[23:15] <snail> i've been hearing about a wellington-based (volunteer-run) art gallery that has some ubuntu machines installed and is now having problems maintaining them. is there a back story here? any hints who might have installed these machines?
[23:19] <ibeardslee> do you know the gallery's name?
[23:44] <snail> i think it's http://www.enjoy.org.nz/ ?


[07:43] <SamuraiAlba> Good bacon to all!
[09:22] <JonathanD> Morning.
[09:26] <rmg51> morning JonathanD
[09:28] <JonathanD> Morning rmg51
[09:28] <rmg51> o/
[11:11] <SamuraiAlba> MorniN!
[11:11] <SamuraiAlba> Firewall and Switch on the way!
[11:11] <SamuraiAlba> :)
[13:21] <MutantTurkey> any tips on bots?
[13:21] <MutantTurkey> supy bot is the good one right?
[14:12] <jedijf> @later tell MutantTurkey @later tell blah blah
[14:12] <PennBot> jedijf: Command Succeeded.
[14:13] <jedijf> @later tell MutantTurkey @later tell <nick> blah blah
[14:13] <PennBot> jedijf: Command Succeeded.
[14:13] <MutantTurkey> thanks
[17:26] <passstab> phoronix does NOT like 12.04
[17:26] <passstab> http://www.phoronix.com/scan.php?page=article&item=ubuntu_pangolin_power&num=1
[17:26] <PennBot> Title: [Phoronix] Ubuntu 12.04 Is A Mixed Power Story (at www.phoronix.com)
[17:35] <ChinnoDog> There are a few places I don't think they are being fair. In some cases the performance of applications goes up significantly because of additional hardware support. The raw power usage isn't as important here as the overall efficiency.
[17:36] <ChinnoDog> If your fps doubles but your power usage only goes up by 20% that is a significant improvement.
[17:37] <ChinnoDog> It would be more fair if they enabled a frame rate limiter and then measured power consumption
[17:41] <jedijf> ChinnoDog++
[17:49] <ChinnoDog> Or another way would be to calculate watts per frame. Or in the case of timed benchmarks like Apache where less time is better you would want to measure watt-hours per test.
[17:50] <ChinnoDog> If the same benchmark takes less watt-hours for the same job then it is more efficient.
[17:58] <ChinnoDog> I think I can't use Chrome in Ubuntu anymore. It consumes obscene amounts of memory.
[18:03] <MobileTurkey> yes
[18:03] <MobileTurkey> such is life
[18:04] <ChinnoDog> :-(
[19:43] <passstab> i don't have the patitence to read 10 page articles
[19:44] <passstab> but i think it did acknowledge that
[19:51] <pleia2> jedijf: upgraded wordpress for the installs on the -us linode (incl pennsylvania)
[19:51] <pleia2> no errors, so you should be good, just a heads up :)
[20:29] <jedijf> pleia2: thanks
[20:29] <jedijf> now i need a new target for vulns :D ;)
[20:30] <jedijf> passstab: then don't editorialize on them
[20:31] <jedijf> :) ^
[20:33] <jedijf> and there are like a zillion reviews, uwn had links for a good half dozen or so
[20:39] <jedijf> @later tell passstab uwn would be great project to get involved with!
[20:39] <PennBot> jedijf: Command Succeeded.
[20:40] <jedijf> hope he comes back with the extra s


[08:28] <jpds> stub, jml: Thanks for the db review.
[10:09] <jpds> noodles775: Ping.
[10:10] <noodles775_> Hi jpds
[10:10] <jpds> noodles775_: Hi there, when you have time, I think I need a UI review for https://code.edge.launchpad.net/~jpds/launchpad/fix_361650/+merge/16749 .
[10:12] <noodles775_> jpds: great! I'll take a look in a bit.
[10:14] <jpds> Awesome, thanks.
[11:25] <noodles775> jpds: hi! Can you add some details about testing your MP? (ie. steps to demo the new functionality, who to log in as, a url to access etc.).
[11:26] <noodles775> Just for next time perhaps...
[11:29] <jpds> noodles775: Just a sec.
[11:30] <noodles775> jpds: i've already looked at the code, so np this time. It's just helpful to provide them in the MP.
[11:31] <jpds> noodles775: OK, I'll add the details next time.
[12:10] <noodles775> jpds: what's the reasoning behind not doing this as an admin-only field displayed on the normal edit form?
[12:12] <intellectronica> adiroiban: what's the branch? have you already arranged to have someone review it, or would you like me to look at it now?
[12:13] <adiroiban> https://code.edge.launchpad.net/~adiroiban/launchpad/bug-340662/+merge/16629
[12:13] <adiroiban> intellectronica: hm... I did not arranged any review. Just created a MP and add it to the topic, to let you know it needs review
[12:14] <adiroiban> this is how it went for my previous branches
[12:14] <adiroiban> were there any changes in the MP process?
[12:14] <intellectronica> adiroiban: cool, i'll review it
[12:24] <al-maisan> intellectronica: could you please also review the branch I queued (http://tinyurl.com/yhj8h7l) when you get to it?
[12:25] <intellectronica> al-maisan: sure, will look at it as soon as i finish adiroiban's branch
[12:26] <al-maisan> intellectronica: thanking you :)
[12:26] <jpds> noodles775: Do you mean the +review form?
[12:32] <noodles775> jpds: no, I meant the +edit form (but i'm logged in as an admin, maybe that's not presented for mirror-admins...). Checking now.
[12:33] <jpds> noodles775: I wanted to make it a little obvious by having the separate button for it.
[12:35] <intellectronica> adiroiban: looks fine to me. i will run the tests and land on your behalf if it passes cleanly
[12:36] <adiroiban> intellectronica: thanks. Let me know if there are any errors. Before creating the MP I did a full test for translations module
[12:37] <jpds> noodles775: And mirror registrants shouldn't be able to see the checkbox themselves.
[13:01] <intellectronica> al-maisan: i must break for lunch, but will review your branch as soon as i'm back
[13:01] <al-maisan> intellectronica: enjoy your lunch!
[13:43] <noodles775> Hi intellectronica, can I add mthaddon's branch to the queue? https://code.edge.launchpad.net/~mthaddon/launchpad/buildjob-nagios-check-perms/+merge/16532
[14:18] <intellectronica> noodles775: sure
[14:21] <intellectronica> al-maisan: can you please add a comment before the then-block on line 33 of the diff? just to distinguish it from the condition
[14:21] <al-maisan> intellectronica: sure, no problem.
[14:21] <intellectronica> al-maisan: cool. r=me, everything else looks flawless
[14:22] <al-maisan> intellectronica: thank you very much!
[14:38] <abentley> jpds: Does your change break any existing pagetests?
[14:40] <jpds> abentley: No.
[14:41] <jpds> abentley: They change the message with ... .
[14:41] <jpds> abentley: check*
[14:44] <abentley> jpds: In that case, what would you think about adding a pagetest that ensures the correct text and link is used?
[14:45] <abentley> jpds: I see that the bug is not triaged.  Have you discussed your change with anyone on the bugs team?
[14:46] <jpds> abentley: No, I filed it during the holidays.
[14:47] <abentley> deryck: jpds has a branch fixing bug #499997, which is untriaged.  Do you agree it should be fixed?
[14:47] <mup> Bug #499997: Duplicate warning box should link to duplicate bug report <Launchpad Bugs:In Progress by jpds> <https://launchpad.net/bugs/499997>
[14:48]  * deryck looks
[14:50] <deryck> abentley, yup, a link would be nice.  I'll mark it accordingly triaged.
[14:50] <abentley> deryck: thanks.
[14:52] <abentley> jpds: What would you think about adding a pagetest that ensures the correct text and link is used?
[14:53] <jpds> abentley: I'm looking for the test now to add that.
[15:02] <jpds> abentley: Pushed revision with link test.
[15:06] <abentley> jpds: Thanks!  Looking...
[15:08] <noodles775> sinzui: I've just added you as a ui reviewer for jpds' branch - I hope that's ok.
[15:08] <abentley> jpds: r=me.  Has this branch passed the full test suite?
[15:08] <jpds> abentley: For bugs, yes. That took a while to run...
[15:08] <sinzui> noodles775: yes
[15:09] <abentley> jpds: When it has passed the full test suite, I can land it for you.  We don't land anything that hasn't passed the full test suite.
[15:20] <abentley> salgado-lunch: r=me
[15:21] <abentley> intellectronica: I just reviewed that.
[15:22] <intellectronica> ah, cool
[19:43] <EdwinGrubbs> abentley: can you review a branch for me? https://code.edge.launchpad.net/~edwin-grubbs/launchpad/bug-482176-add-team-member-ajax-part3/+merge/16804
[19:43] <abentley> EdwinGrubbs: Sure, just a minute.
[19:47] <abentley> EdwinGrubbs: What is the new behavior for addMember?
[19:54] <abentley> EdwinGrubbs: It is a bit strange to see the names of James Blackwell and Jeff Waugh.  They are former Canonical people, so I'd expect to see them only in old tests.
[19:56] <abentley> What would you think about getting foo.bar by email rather than 'name16'?
[19:56] <EdwinGrubbs> abentley: I'm fine with switching it to get foobar by email rather than name16.
[19:56] <abentley> EdwinGrubbs: I think that would make it a bit easier to understand.
[19:57] <EdwinGrubbs> abentley: addMember() now takes into account whether the user is an admin of both teams. If they are, there is no reason to make them go through the invite/accept-invitation dance. Just add the member as active.
[19:58] <abentley> EdwinGrubbs: Cool.
[19:59] <abentley> EdwinGrubbs: The behaviour of inTeam is not what I would expect.
[19:59] <EdwinGrubbs> abentley: Well, I decided to use James Blackwell, etc, since I'm trying to avoid a part4 of this branch.
[20:01] <abentley> EdwinGrubbs: I would expect that (x.inTeam(y)) == (y in x.allmembers)
[20:01] <abentley> EdwinGrubbs: Sorry, that should be (y.inTeam(x)) == (y in x.allmembers)
[20:04] <EdwinGrubbs> abentley: can you tell me in which file you are looking at inTeam()?
[20:05] <abentley> EdwinGrubbs: I am looking at your diff for lib/lp/registry/doc/teammembership.txt
[20:06] <abentley> EdwinGrubbs: http://pastebin.ubuntu.com/351412/
[20:10] <EdwinGrubbs> abentley: yes, that is just the bizarro behavior, where the owner of a team can leave the team but still be the owner. I don't know why we let that happen to begin with, but that is too big of an issue to tackle here.
[20:11] <EdwinGrubbs> abentley: inTeam() is used by the security layer, so that's why they don't have it match currently.
[20:13] <abentley> EdwinGrubbs: It's the behaviour of inTeam in that circumstance that's surprising, not so much the fact that the circumstance can arise.  inTeam is used by our security stuff, too.  We may have to reconsider this.
[20:13] <leonardr> salgado, i made a change to my anonymous-oauth branch back on december 16th. can you take a quick look at it and change your vote from 'needs fixing' so i can land it?
[20:18] <salgado> leonardr, will do.  do you have the URL of the m-p?  btw, did you add a comment to the m-p after you made the changes?  I rely heavily on email to do reviews, so commenting on the m-p when there's changes made to the branch is a good idea
[20:18] <leonardr> salgado: https://code.edge.launchpad.net/~leonardr/launchpad/anonymous-oauth/+merge/16199
[20:18] <leonardr> i didn't leave a comment. i probably got the branch cleared with gary since i remember him agreeing to land it for me, but since that was a long time ago i want to finish it properly
[20:20] <salgado> leonardr, do you have an incremental diff?  I really don't want to go through the whole thing all over again
[20:20] <leonardr> salgado: check out revisions 10558 and 10559...
[20:21] <leonardr> hm, launchpad isn't cooperating
[20:22] <leonardr> salgado: here you go
[20:22] <leonardr> https://pastebin.canonical.com/26172/
[20:23] <salgado> thanks leonardr
[20:29] <salgado> leonardr, just updated the m-p; r=me
[20:40] <abentley> EdwinGrubbs: Is the doc correct?  It looks inverted: http://pastebin.ubuntu.com/351422/
[20:41] <bac> hi abentley - can you review another?  https://code.edge.launchpad.net/~bac/launchpad/bug-498179/+merge/16806
[20:41] <EdwinGrubbs> abentley: The doc is incorrect. Thanks for catching that.
[20:41] <abentley> bac: I will try, but the one I'm currently reviewing is large.
[20:42] <bac> abentley: ok.  trying is good.
[20:45] <EdwinGrubbs> bac: I can review that one for you.
[20:45] <bac> EdwinGrubbs: hey, that's great
[20:47] <abentley> EdwinGrubbs: Wow, doctests sure punish us for adding useful return values!
[20:51] <abentley> EdwinGrubbs: r=me
[20:51] <EdwinGrubbs> abentley: thanks alot
[20:51] <EdwinGrubbs> abentley: I started reviewing Brad's branch, in case you didn't see that message.
[20:52] <abentley> EdwinGrubbs: I did, thanks.
[21:00] <EdwinGrubbs> bac: What is the purpose of adding the pub_member to the pub_team? It appears to have no effect on the test.
[21:00] <bac> EdwinGrubbs: likely a mistake
[21:01] <bac> EdwinGrubbs: oh, i was going to show that even though pub_owner could see private parts the mere pub_member could not
[21:01] <bac> EdwinGrubbs: i think that's still a good thing to do, i just forgot to do it
[21:05] <bac> EdwinGrubbs: this is what i intended:  http://pastebin.ubuntu.com/351429/
[21:06] <EdwinGrubbs> that looks good
[21:30] <EdwinGrubbs> bac: I was thinking about the test to see if the user is in getDirectAdministrators(), and it seems like it would cause a problem for teams that are owned by another team. Therefore, you should probably use can_edit_team(invited_team, user)
[21:32] <bac> EdwinGrubbs: good idea, i think
[21:37] <EdwinGrubbs> bac: review sent
[21:37] <bac> EdwinGrubbs: thanks
[21:41] <bac> EdwinGrubbs: what do you think about this instead?  http://pastebin.ubuntu.com/351446  it avoids some redundant checking for admins that would happen if i used can_edit_team


[00:30] <andrewsmedina> its done
[00:30] <andrewsmedina> niemeyer, hazmat https://codereview.appspot.com/5702055
[00:35] <niemeyer> andrewsmedina: Woohay!
[00:35] <andrewsmedina> niemeyer: :)
[00:36] <niemeyer> andrewsmedina: You should have a review by the morning tomorrow
[00:36] <andrewsmedina> niemeyer: ok :D
[00:37] <andrewsmedina> niemeyer: I will continue to work on local provider (lxc)
[00:47] <hazmat> andrewsmedina, nice
[00:48] <hazmat> i thought that gofmt removed formatting concerns
[00:48] <hazmat> besides subordinates i see alot of formatting/spacing diffs in there
[01:07] <andrewsmedina> hazmat: how I update a issue with other patch using lbox ?
[01:08] <hazmat> andrewsmedina, just lbox propose -cr  again.. it will update in place
[01:09] <andrewsmedina> hazmat: ok, I will fix the format
[01:18] <niemeyer> andrewsmedina: Just run "go fmt"
[01:18] <niemeyer> andrewsmedina: It will auto-format for you
[01:20] <andrewsmedina> niemeyer: I know :p
[01:25] <andrewsmedina> hazmat, niemeyer done :D https://codereview.appspot.com/5702055/
[01:26] <hazmat> andrewsmedina, thanks much nicer
[01:31] <niemeyer> andrewsmedina: How long have you been coding with Go?
[01:34] <andrewsmedina> niemeyer: since carnaval
[01:34] <andrewsmedina> niemeyer: why?
[01:35] <niemeyer> andrewsmedina: Just happy to see how fast you've produced a nice change set for integration
[01:35] <andrewsmedina> niemeyer: I contribute with several projects
[01:36] <niemeyer> andrewsmedina: From a quick look over it, looks very reasonable
[01:36] <andrewsmedina> niemeyer: Most projects that use python
[01:37] <andrewsmedina> niemeyer: I want do more for this project
[01:38] <niemeyer> andrewsmedina: From what I can see so far, you're very welcome to stay
[01:38] <niemeyer> andrewsmedina: make sure you're subscribed to the mailing list too, so that you can also participate in design decisions etc
[01:52] <niemeyer> Woohay.. just cut down the store tests timing by half.. was overlooking a silly setup/teardown cycle
[01:57] <andrewsmedina> niemeyer: If you have more small issues to let me know
[01:57] <niemeyer> andrewsmedina: Thanks, they'll certainly show up, and I'll make sure to ping you to see if you're interested
[01:59] <andrewsmedina> niemeyer: I'm waiting for you :D
[01:59] <andrewsmedina> niemeyer: Now, I will try install c client for zookeper on mac os ou centos
[01:59] <andrewsmedina> =/
[02:01] <niemeyer> andrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of gozk from source
[02:01] <niemeyer> Sorry
[02:01] <niemeyer> andrewsmedina: Hmmm.. there's a chance that gozk can actually work if you compile the C client of *zookeeper* from source
[02:01] <niemeyer> andrewsmedina: It's not too painful..
[02:01] <andrewsmedina> niemeyer: I'm not found the c client .tar.gz
[02:02] <niemeyer> andrewsmedina: It's the same source
[02:02] <niemeyer> andrewsmedina: The C client lives under src/c
[02:02] <niemeyer> andrewsmedina: ./configure && make
[02:03] <andrewsmedina> niemeyer: I know, I found this in svn repo, but not in tar.gz package
[02:03] <andrewsmedina> I will try again
[02:04] <andrewsmedina> niemeyer: you were right
[02:05] <niemeyer> andrewsmedina: You'll have to tweak the source of gozk so that the CFLAGS line in zk.go has something like -I/path/to/your/src/c/include
[02:06] <niemeyer> andrewsmedina: We should have a default entry like that pointing to /usr/local/include so that you could just make install it
[02:06] <niemeyer> andrewsmedina: Not there yet, though
[02:08] <andrewsmedina> niemeyer: your project lpad, it's broken with the last weekly version
[02:08] <andrewsmedina> niemeyer: because contains two packages
[02:08] <niemeyer> andrewsmedina: I've already fixed it, but it's lacking the tag I suppose
[02:08] <niemeyer> andrewsmedina: Let me tag it
[02:09] <niemeyer> andrewsmedina: Please try again
[02:09] <andrewsmedina> I have fixed this in my machine :p
[02:09] <andrewsmedina> removing the example.go
[02:13] <niemeyer> andrewsmedina: That works too :)
[02:14] <andrewsmedina> niemeyer: Can I change zk.go to point to /usr/local/include ?
[02:14] <niemeyer> andrewsmedina: Yeah, we can certainly add that in the stock package
[02:14] <niemeyer> andrewsmedina: Just add it at the end, please
[02:20] <niemeyer> Okay.. I really ought to have some sleep now
[02:21] <niemeyer> Have a good night all
[02:21] <niemeyer> Or at least those that approach their bed time ;
[02:21] <niemeyer> )
[11:29] <fwereade> niemeyer, hazmat: will you be free for a chat about constraints in ~90 minutes? (I need to collect Laura and eat lunch pretty soon)
[11:30] <niemeyer> fwereade: I will, but I believe hazmat must be asleep by now
[11:30] <niemeyer> fwereade: Morning, btw
[11:30] <fwereade> niemeyer, heyhey :)
[11:30] <fwereade> niemeyer, ah, ok, he was up late? I often seem to see him come on at about this time
[11:31] <niemeyer> fwereade: Ah, maybe he's changed his working hours
[11:31] <niemeyer> fwereade: I was assuming that just based on his TZ
[11:32] <fwereade> niemeyer, I couldn't swear that's been normal recently, though, it's more a general impression that I developed at some stage
[11:45] <rog> fwereade: so... i did a test implementation of the relation-get thing the way i suggested, and it seemed over complex
[11:45] <fwereade> rog, yeah, I peered through the docs a little and wasn't sure it'd save me much
[11:45] <rog> fwereade: but...
[11:45] <rog> fwereade: i thought this was better: http://paste.ubuntu.com/861798/
[11:45] <rog> fwereade: i think the streaming stuff is overkill
[11:46] <rog> fwereade: for the primitives we're implementing, i don't think there's any need to see output as it's produced.
[11:47] <rog> fwereade: the client side would look like this: http://paste.ubuntu.com/861802/
[11:48] <fwereade_> rog, I'll think about that, but I have to run to collect laura -- sorry
[11:49] <rog> fwereade_: np
[12:50] <rog> lunch
[13:30] <andrewsmedina> morning
[13:50] <andrewsmedina> niemeyer: https://codereview.appspot.com/5702055/
[14:24] <rog> fwereade_: any thoughts about that suggestion?
[14:25] <fwereade_> rog, well, it'd surely work, but it still feels more correct to stream the output back, and I don't really think the setup is that onerous
[14:27] <rog> fwereade_: won't this always be used in a scripting situation where it won't make any difference?
[14:28] <rog> fwereade_: apart from anything else it means that we can rely on a well tested RPC framework rather than rolling our own
[14:29] <fwereade_> rog, well, it seems that it won;t make any difference only if we guarantee that output never grows too irritatingly large to prefer streaming over copying
[14:29] <fwereade_> rog, I think the protocol is independent of the streaming question
[14:30] <fwereade_> rog, we can still stream stuff back with rpc
[14:30] <rog> fwereade_: yeah, but it's a fair amount of complexity. i'm questioning whether that complexity is worth it for some log messages.
[14:30] <rog> fwereade_: the streaming is what makes things more complex, AFAICS
[14:31] <fwereade_> rog, well,and the important output too
[14:31] <rog> fwereade_: but the output is relatively small, right?
[14:31] <rog> fwereade_: no more than 1MB, say
[14:31] <fwereade_> rog, indeed, probably not
[14:31] <rog> fwereade_: (do people put enormous things in relations?)
[14:32] <fwereade_> rog, and, indeed, the stderr output will probably not be ruinously big either
[14:32] <rog> fwereade_: i guess i'm just suggesting an "as simple as possible" approach. the client API looked identical for the streaming RPC version i did
[14:32] <fwereade_> rog, mainly it just feels like packing complete output streams into strings is the Wrong Thing To Do
[14:33] <fwereade_> rog, and I strongly favour implementing all our commands as Commands
[14:34] <rog> fwereade_: it's trivial to make it so there's a single entry that invokes the correct command if that's what we want
[14:34] <rog> fwereade_: (actually i had that before, but thought it might be better with several entry points)
[14:35] <fwereade_> rog, ok, I think we agree here, there's no sense hand-rolling the protocol
[14:35] <rog> fwereade_: even with multiple entry points, i don't think there's a reason we couldn't use Command
[14:36] <fwereade_> rog, out point of disagreement seems to be whether stdout and stderr socket paths should be passed as part of the remote procedure call
[14:36] <fwereade_> our point^^
[14:36] <rog> fwereade_: yeah.
[14:36] <rog> fwereade_: i think that we should just go the ultra-simple route until we encounter a command that actually produces lots of output
[14:36] <rog> YAGNI...
[14:37] <fwereade_> rog, most of my arguments come back to my feeling that it's truer to the nature of a stream to let it be a stream; and that I'm not convinced that it's an unreasonable burden for the codeto bear
[14:38] <rog> fwereade_: if in doubt i'd delete 120 lines of code...
[14:41] <rog> fwereade_: i know what you mean about streams wanting to be streams, but i don't think it's worth it here.
[14:41] <fwereade_> rog, I'm not sure exactly where you're getting that number... we can certainly lose the protocol, this much is agreed
[14:42] <fwereade_> rog, that it feels inelegant and lumpen to convert a stream to a []byte to send it to another process so it can output it again as a stream
[14:43] <rog> fwereade_: i don't mind so much. it takes 0 lines of code to do that.
[14:43] <rog> fwereade_: and it's not going to make any practical difference
[14:43] <rog> fwereade_: i can't think of a way that the difference is going to be observable.
[14:44] <fwereade_> rog, hm;someone running them with --debug would like to see output more-or-less as it happens, maybe?
[14:45] <rog> fwereade_: BTW for reference, here's the server implementation using streaming with RPC: http://paste.ubuntu.com/861987/
[14:46] <rog> fwereade_: is it possible to run them at an interactive shell prompt?
[14:46] <rog> fwereade_: i thought they needed to be run within the context of a hook
[14:47] <fwereade_> rog, (1) I think hook-debug might enable something like that, but that may be FUD because Idon't recall using it
[14:47] <rog> fwereade_: (... and the client: http://paste.ubuntu.com/861989/)
[14:47] <fwereade_> (2) I'm sure there has been talk of allowing the commands to actually work outside of the hook context, but I'm not sure where to look for it
[14:48] <fwereade_> rog, or, hmm, wait; was that just getting access to relation context in non-relation hooks?
[14:48] <fwereade_> rog, sorry, that one makes more sense
[14:49] <rog> fwereade_: no, i think you were right: https://juju.ubuntu.com/docs/hook-debugging.html
[14:49] <fwereade_> rog, cool
[14:50] <rog> fwereade_: i didn't know about that
[14:50] <rog> fwereade_: but i still don't think it's sufficient justification
[14:51] <rog> fwereade_: all the in-hook commands are going to be short lived
[14:51] <rog> fwereade_: they essentially do a single zk transaction, right?
[14:51] <fwereade_> rog, I'll look through your code again, my cursory look suggested you were doing more than I was; is it that I missed significant functionality?
[14:52] <rog> fwereade_: what would happen with your code if two things executed relation-get in parallel?
[14:52] <fwereade_> rog, probably, yes, in the working-correctly case
[14:53] <fwereade_> rog, nothing too much with a moderate amount of care taken in dealing with the different client contexts' caches
[14:53] <rog> heh, most people using relation get will be doing x=$(relation-get) anyway...
[14:53] <rog> fwereade_: it seemed to dial the same socket several times. i couldn't see how the different streams were separated.
[14:54] <rog> fwereade_: (if there were concurrent calls)
[14:54] <rog> i haven't looked too closely though.
[14:54] <fwereade_> rog, ah, yes, I would appear to be on crack :/
[14:54]  * rog has another look
[14:56] <niemeyer> rog, fwereade_: That should be the end of the importer: https://codereview.appspot.com/5704056
[14:56] <rog> fwereade_: i did really like my stream-over-RPC code, BTW. the possibility has been in my head for ages. i'll save the code. but i think it's more complexity than we need.
[14:56] <fwereade_> niemeyer, cheers
[14:56] <niemeyer> Will just submit a command to run that in another CL
[14:56] <fwereade_> cool
[14:57] <rog> niemeyer: i'll have a look
[14:57] <niemeyer> fwereade_: Then, at least as far as I recall, the HTTP API we need is trivial
[14:57] <niemeyer> Which means we _migth_ have it ready by tomorrow
[14:57] <niemeyer> jcastro: ^
[14:57] <fwereade_> niemeyer, according to my fuzzy memories, that's right
[14:57] <fwereade_> niemeyer, awesome!
[14:59] <jcastro> niemeyer: woo!
[15:00] <rog> niemeyer: i'm not entirely happy about the trend towards multi-line error messages. i quite liked the approach taken by go/parser, where the error says "some error (and 27 more)" and the underlying error type provides a way to get all of them if desired.
[15:01] <niemeyer> jcastro: This doesn't mean it will be live tomorrow, by any means :)
[15:01] <niemeyer> jcastro: But you can start planning
[15:02] <niemeyer> rog: That means even the first error message may not be relevant
[15:02] <rog> niemeyer: all the error messages are relevant, no?
[15:02] <niemeyer> rog: So we end up with "branch errors" as a message
[15:02] <niemeyer> rog: Not if you strip their content :-)
[15:02] <jcastro> niemeyer: yeah this will be Good Enough
[15:03] <rog> niemeyer: i'm suggesting keeping the first error message encountered (and indicating that there are more)
[15:03] <niemeyer> rog: and I'm saying the first error message may have multiple lines
[15:03] <niemeyer> rog: Because it comes from bzr
[15:03]  * rog isn't too happy about that either
[15:04] <rog> niemeyer: messages are often written to log files, and it's useful that log file lines are consistently prefixed
[15:04] <niemeyer> rog: Heh
[15:05] <niemeyer> rog: The actual error is several orders of magnitude more interesting in a log file than its prefix
[15:05] <niemeyer> rog: If you're suggesting stripping the errors from the log file to keep it pretty, that's a big no-no
[15:05] <rog> niemeyer: agreed.  but prefixes are often used to extract relevant info.
[15:06] <niemeyer> rog: Please let's be realisitc
[15:06] <niemeyer> rog: We're not dropping the error message out of the log file.. I'm happy to have solutions, but that by itself is not one of them
[15:07] <rog> niemeyer: it looks like all the errors are logged anyway
[15:07] <niemeyer> rog: So what you are suggesting is ... ?
[15:08] <rog> niemeyer: i'm not exactly sure. i just don't like Error() returning a multi-line error :-)
[15:09] <rog> sorry
[15:36] <niemeyer> rog: The only reasonable thing I can think of is to make BranchErrors string return a "one or more branches failed to be published" message from Error
[15:38] <rog> niemeyer: as i said, i think the approach taken here (see ErrorList.Error) is a reasonable one: http://weekly.golang.org/src/pkg/go/scanner/errors.go
[15:39] <niemeyer> rog: That doesn't work in this case for the reason I explained
[15:39] <rog> niemeyer: but it won't work if some of the errors are already multi-line. perhaps bzr errors could be joined into a single line or something.
[15:39] <niemeyer> rog: Heh
[15:40] <niemeyer> rog: Let's stay on the reasonable side.. joining 10 lines in 1 won't improve the situation at all
[15:40] <rog> bzr errors are that big?
[15:40] <niemeyer> rog: Any command line tool can print an arbitrary amount of content in their standard error stream
[15:41] <rog> niemeyer: and we're treating that as "the" error message. i'm not keen. (not that i see a better approach yet though)
[15:42] <niemeyer> rog: Yeah, repeating that you're not keen isn't helpful.. I provided a suggestion. Does that help?
[15:42] <niemeyer> rog: Do you have a better one?
[15:43] <rog> niemeyer: try to work out the actual error line in the bzr output? (saving the rest for callers that want to see the whole thing)
[15:44] <rog> niemeyer: perhaps just finding the first line beginning "bzr: ERROR: " would be sufficient
[15:45] <niemeyer> rog: We still have to fall back in case we don't find it, and we still have to log the whole error message
[15:47] <niemeyer> rog: I think I'll just stick a static error message in there for now. That solves your main concern, and doesn't really change the overall behavior in any way.
[15:48] <niemeyer> We can improve that later as we find the need to
[15:48] <niemeyer> rog: Sounds good?
[15:48] <rog> niemeyer: yeah, it's better.
[15:48] <niemeyer> Cool
[15:48] <rog> niemeyer: was just looking in the bzr source to see how errors are dealt with
[15:49] <niemeyer> rog: It doesn't matter, really.. whatever heuristics we put to find an error message is still heuristics, and needs to have a fallback
[15:49] <rog> niemeyer: yeah, but the fallback for bzr could be easy - just use the first line regardless.
[15:49] <niemeyer> rog: It's human oriented text.. not a protocol, unfortunately
[15:50] <rog> niemeyer: (or all the lines joined, or whatever)
[15:50] <rog> niemeyer: but it's rare enough that it wouldn't matter, i think.
[15:51] <rog> niemeyer: it seems to me that the first line has all the relevant info - the rest is just suggestions like "However, you can get around this by doing this"
[15:51] <niemeyer> rog: See above..
[15:52] <niemeyer> rog: It's not clear what you're trying to achieve.
[15:52] <niemeyer> rog: We'll be logging the whole message to aid in solving problems..
[15:53] <niemeyer> rog: What's the problem you're trying to solve?
[15:54] <rog> niemeyer: sometimes verbosity can hide problems. to my mind, looking at the possible bzr errors, (http://paste.ubuntu.com/862070/) they look like Go errors. that's what the first line would give you. but i guess it's possible you can get several errors in a row.
[15:55] <niemeyer> rog: There are several errors in there that have \n in them.. what are you trying to show me?
[15:56] <rog> niemeyer: hmm. yeah, there are some problems.
[15:56] <rog>     _fmt = "%(target)s\n" \
[15:56] <rog>             "is not compatible with\n" \
[15:56] <rog> bah humbug
[15:56] <rog> oh well
[15:57] <niemeyer> I'll have some quick lunch.. back in a bit
[15:57] <rog> just strip out \n...
[15:57] <rog> niemeyer: ok
[15:57] <rog> niemeyer: enjoy
[15:57] <niemeyer> rog: Stripping out \n == huge message == what is rog trying to do?
[15:57]  * niemeyer steps out for real
[16:10] <rog> niemeyer: yeah, it's a difficult call. but on balance i think i'd prefer an error message that conformed to the usual one-line convention, even if the one line was very long, to one that didn't.
[16:34] <hazmat> do we log this channel?
[16:34] <hazmat> jcastro, i thought we had that setup.. but i don't see the logger/mup around
[16:42] <rog> hazmat: if we don't, we should...
[16:43] <hazmat> i don't really have any insight into getting _mup_ on here.. niemeyer ?
[16:44] <jcastro> hazmat: we did, it must have gone missing, I'll check
[17:15] <niemeyer> rog: I'd rather have something that is readable instead. Let's keep it as-is until we find a better scheme.
[17:15] <rog> niemeyer: fair enough.
[18:00] <fwereade__> bother it's 7, bbl if I can
[18:36] <niemeyer> The world is falling!
[18:36] <niemeyer> I mean.. it's raining..
[18:43] <niemeyer> The volume of water falling here is amazing..
[18:46] <jimbaker> niemeyer, sounds like the snowstorms we sometimes get here. best appreciated when it comes suddenly during a 22 deg C day in the spring, while wearing shorts
[18:47] <rog> i like rainstorms
[18:47] <rog> i'm off for the night, BTW. i smell spag boll!
[18:47] <rog> see ya tomorrow
[18:47] <niemeyer> rog: Cheers! Enjoy!
[19:42] <andrewsmedina> why Go port dont have providers module?
[19:57] <niemeyer_> andrewsmedina: It's called environs
[19:57] <niemeyer> andrewsmedina: After some back and forth we ended up renaming it
[19:57] <niemeyer> andrewsmedina: Well.. consolidating might be a better way to put it
[19:57] <niemeyer> andrewsmedina: Python has both environments and providers
[19:57] <niemeyer> andrewsmedina: Go has only environments
[19:58] <andrewsmedina> niemeyer: hmm
[19:59] <andrewsmedina> niemeyer: I updated gozk to use the last gocheck version
[20:00] <niemeyer> andrewsmedina: Ah, nice.. do you want to propose it?
[20:01] <andrewsmedina> niemeyer: I'm at work now
[20:01] <niemeyer> andrewsmedina: Ah, super
[20:02] <andrewsmedina> niemeyer: tonight I propose
[20:02] <niemeyer> andrewsmedina: Super
[20:02] <niemeyer> andrewsmedina: What's you daily project, btw?
[20:02] <andrewsmedina> niemeyer: I work at globo.com
[20:03] <niemeyer> andrewsmedina: Ah, right.. what project there?
[20:03] <niemeyer> andrewsmedina: (if that's public info)
[20:03] <andrewsmedina> niemeyer: now, I'm in working in a private PaaS using Openstack + juju + cloudfoundry
[20:03] <niemeyer> andrewsmedina: Hah, nice.. I heard about those. ;-)
[20:03] <andrewsmedina> niemeyer: I work with flaviamissi
[20:04] <flaviamissi> :)
[20:06] <niemeyer> flaviamissi: Buenas :)
[20:06] <andrewsmedina> niemeyer: I met you at pyconbrasil 2007 in joenvile
[20:07] <flaviamissi> niemeyer: hi!
[20:08] <niemeyer> andrewsmedina: Wow.. really? My memory sucks..
[20:08] <andrewsmedina> niemeyer: I'm a django guy
[20:09] <niemeyer> I miss Dorneles..
[20:09] <andrewsmedina> niemeyer: me too =/
[20:09] <andrewsmedina> niemeyer: In 2007 I was a only brazilian django guy at pycon
[20:09] <flaviamissi> andrewsmedina: y u no work?!
[20:10] <flaviamissi> andrewsmedina: HAEUheauhEAhAEAE
[20:10] <niemeyer> flaviamissi: Let me know if you need anything.. happy to see you guys using juju there
[20:10] <andrewsmedina> flaviamissi: oO
[20:11] <flaviamissi> niemeyer: sure! you'll hear a lot from us, or read... whatever
[21:07] <hazmat> hmm.. adding the alias expansion to the scheduler is harder than i thought, it really wants to reduce redundant events.. and the expansion is redundant.
[21:08] <niemeyer> hazmat: It's the machine raising against us!
[21:21] <niemeyer> Time for some outsiding.. back later
[21:43] <hazmat> niemeyer, i'm thinking its time to revisit the notion that hook errors on relation events, drop the event. i'm starting to think we should keep/replay the event post resolved
[21:43] <hazmat> it doesn't feel quite sane otherwise
[21:54] <hazmat> sigh.. feels like there are a couple of bugs here
[23:38] <hazmat> jimbaker, what's the rationale for juju do
[23:39] <hazmat> on its face it seems highly suspect to me
[23:39] <jimbaker> hazmat, i do have some use cases in the proposal that are derived from it
[23:39] <jimbaker> hazmat, i certainly would entertain any suggestions for alternatives that enable out-of-band hook exec
[23:40] <hazmat> jimbaker, your confusing the client with hooks calling other hooks
[23:40] <hazmat> ie. the bugs wasn't about the user invoking arbitrary hooks
[23:40] <jimbaker> hazmat, i address that in a separate section
[23:40] <hazmat> k
[23:41] <jimbaker> it is certainly ok with me if we don't implement. to quote, i'm not absolutely sure of anything...
[23:41] <jimbaker> except perhaps the well-ordered principle ;)
[23:48] <hazmat> yeah.. its not on the table.. imo.. its insane.. but i haven't finished reading.. so i'll defer discussion till then
[23:53] <jimbaker> hazmat, please certainly put that feedback in the email
[23:53] <jimbaker> then we can definitively capture that it's a bad idea
[23:53] <hazmat> i'm just reviewing in reitveld
[23:54] <jimbaker> hazmat, sure, that's a good place to review, but the high-level feedback needs to be on the mailing list
[23:54] <jimbaker> otherwise juju stakeholders are unlikely to see it
[23:55] <hazmat> i think you've lost most of the relevant stake holders.. outside of the first paragraph
[23:55] <hazmat> the rest is effectively spec merge review
[23:57] <jimbaker> hazmat, ok, i'm just trying to follow the process in https://lists.ubuntu.com/archives/juju/2011-November/000931.html
[23:58] <hazmat> jimbaker, fair enough
[23:58] <hazmat> jimbaker, and thanks for doing so
[23:58] <jimbaker> hazmat, no
[23:58] <jimbaker> problem


[01:31] -queuebot:#ubuntu-ci-eng- pete-woods jgdx, https://bileto.ubuntu.com/#/ticket/2610 Ready to build (/:, /: Failed to update local lp:indicator-network cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:indicator-network, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:indicator-network, zesty/to, zesty/update). Successfully built (xenial/indicator-network, zesty/indicator-network)
[01:57] -queuebot:#ubuntu-ci-eng- pete-woods jgdx, https://bileto.ubuntu.com/#/ticket/2610 Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:indicator-network, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:indicator-network, zesty/to, zesty/update). Successfully built (xenial/indicator-network, zesty/indicator-network)
[02:21] -queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Needs rebuild due to higher version at destination (xenial/ubuntu-system-settings, zesty/ubuntu-system-settings). Ready to build (/:, /: Failed to update local lp:ubuntu-system-settings cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-system-settings, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:ubuntu-system-settings, zesty/to, zesty/update)
[02:44] -queuebot:#ubuntu-ci-eng- jgdx, https://bileto.ubuntu.com/#/ticket/2140 Needs rebuild due to higher version at destination (xenial/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-system-settings, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:ubuntu-system-settings, zesty/to, zesty/update)
[05:58] -queuebot:#ubuntu-ci-eng- mzanetti dednick, https://bileto.ubuntu.com/#/ticket/2373 Failed to upload (xenial/qtmir-gles, zesty/qtmir). Needs rebuild due to new commits (zesty/unity-api, zesty/unity8). Ready to build (/:, /: Failed to update local lp:qtmir cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:qtmir, xenial/lp:unity-api, xenial/lp:unity8, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:qtmir, zesty/lp:unity-api, zesty/
[06:22] -queuebot:#ubuntu-ci-eng- mzanetti dednick, https://bileto.ubuntu.com/#/ticket/2373 Failed to upload (xenial/qtmir-gles). Needs rebuild due to new commits (zesty/qtmir, zesty/unity-api, zesty/unity8). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:qtmir, xenial/lp:unity-api, xenial/lp:unity8, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:qtmir, zesty/lp:unity-api, zesty/lp:unity8, zesty/to, zesty/update). Success
[06:51] -queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Needs rebuild due to higher version at destination (xenial/ubuntu-system-settings). Ready to build (/:, /: Failed to update local lp:ubuntu-system-settings cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-system-settings, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:ubuntu-system-settings, zesty/to, zesty/update). Successfully built (zesty/ubun
[06:51] -queuebot:#ubuntu-ci-eng- Trevinho, duflu, https://bileto.ubuntu.com/#/ticket/3190 Ready to build (/:, /: Failed to update local lp:ubuntu-themes/xenial cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-themes/xenial, xenial/to, xenial/update). UNAPPROVED queue (xenial/ubuntu-themes)
[07:00] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3199 Pending binary packages
[07:14] -queuebot:#ubuntu-ci-eng- Trevinho, duflu, https://bileto.ubuntu.com/#/ticket/3190 Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-themes/xenial, xenial/to, xenial/update). UNAPPROVED queue (xenial/ubuntu-themes)
[07:15] -queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Needs rebuild due to higher version at destination (xenial/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-system-settings, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:ubuntu-system-settings, zesty/to, zesty/update)
[07:40] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3199 Diff missing
[08:01] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3200 Pending binary packages
[08:20] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3200 Diff missing
[09:38] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3157 Needs rebuild due to higher version at destination
[09:51] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3171 Needs rebuild due to higher version at destination
[09:56] -queuebot:#ubuntu-ci-eng- jamespage, https://bileto.ubuntu.com/#/ticket/3171 Abandoning ticket
[11:41] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3200 Pending binary packages
[12:01] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3200 Diff missing
[12:31] -queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Needs rebuild due to higher version at destination (xenial/ubuntu-system-settings). Ready to build (/:, /: Failed to update local lp:ubuntu-system-settings cache., xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-system-settings, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:ubuntu-system-settings, zesty/to, zesty/update). Successfully built (zesty/ubun
[12:47] -queuebot:#ubuntu-ci-eng- Trevinho oSoMoN, https://bileto.ubuntu.com/#/ticket/3201 Preparing packages
[12:55] -queuebot:#ubuntu-ci-eng- artmello, https://bileto.ubuntu.com/#/ticket/2670 Needs rebuild due to higher version at destination (xenial/ubuntu-system-settings). Needs rebuild due to new commits (zesty/ubuntu-system-settings). Ready to build (/:, xenial/Failed, xenial/cache., xenial/local, xenial/lp:ubuntu-system-settings, xenial/to, xenial/update, zesty/Failed, zesty/cache., zesty/local, zesty/lp:ubuntu-system-settings, zesty/to, zesty/update)
[13:28] -queuebot:#ubuntu-ci-eng- Trevinho oSoMoN, https://bileto.ubuntu.com/#/ticket/3201 Successfully built
[13:40] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3199 Proposed pocket
[14:05] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3196 Publishing packages
[14:20] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3196 Proposed pocket
[15:38] -queuebot:#ubuntu-ci-eng- Trevinho, https://bileto.ubuntu.com/#/ticket/3196 Release pocket
[15:39] -queuebot:#ubuntu-ci-eng- cpaelzer, https://bileto.ubuntu.com/#/ticket/3199 Release pocket
[15:43] -queuebot:#ubuntu-ci-eng- coreycb, https://bileto.ubuntu.com/#/ticket/3123 Updates pocket