[06:23] <ochosi> bluesabre: maaan, i thought i had a completely compatible version of css in greybird for both versions of lightdm. sucks to see that the menubar is partly borked now... but great work on the ppa! :)
[15:05] <micahg> knome: I haven't forgotten, just been busy
[15:19] <knome> micahg, good good :)
[16:56] <pnarciso> hello guys
[16:56] <knome> hello.
[16:57] <pnarciso> so, are guys already testing xubuntu saucy
[16:57] <knome> well, daily images are being built
[16:58] <knome> bbl ->
[16:59] <pnarciso> I've been away from xubuntu testing, but I have more time now and I'll be following saucy
[17:00] <daim2k5> pnarciso: i will start to help
[17:00] <daim2k5> pnarciso: do you test with virtualbox? or seperate pc?
[17:00] <pnarciso> i'm typing from a daily right now
[17:00] <pnarciso> pc
[17:01] <pnarciso> I've installed the daily through usb and everything went fine
[17:01] <daim2k5> ok
[17:02] <daim2k5> so i need the old pc back from my parents :D
[17:02] <pnarciso> right now I only have one annoying bug, which is, when I want to restart or shutdown the machine it asks me for root password
[17:02] <pnarciso> which is not normal behavior
[17:02] <daim2k5> jep
[17:03] <pnarciso> is this known bug or is it just me
[17:03] <micahg> it should ask for an admin password if you shutdown with another user logged in
[17:04] <pnarciso> well there's only one user logged which is myself :)
[17:04] <pnarciso> so it's no normal behavior
[17:05] <pnarciso> could this be the result of the migration to systemd logind
[17:09] <micahg> idk
[17:09] <pnarciso> ?
[18:41] <ochosi> pnarciso: what systemd/logind migration were you referring to?
[18:41] <ochosi> afaik ubuntu won't use systemd in the near future
[18:48] <pnarciso> ochosi, systemd and logind are installed in saucy
[18:51] <ochosi> by defaultß
[18:51] <ochosi> ?
[18:52] <lderan> that'll be cool
[18:54] <pnarciso> http://ubuntuforums.org/showthread.php?t=2140174
[18:54] <pnarciso> it seems my theory could be right
[18:56] <ochosi> well it'd surprise me if they'd simply and silently scrapped upstart
[18:56] <ochosi> but all is possible after last cycle
[18:57] <pnarciso> is there any plans to improve artwork in xubuntu
[18:58]  * drc ducks
[19:00] <ochosi> pnarciso: errm, say what?
[19:01] <pnarciso> improved theme, icons, wallpaper, etc
[19:01] <ochosi> yeah, i'm working on all of those areas (except wallpaper, knome has dibs on that)
[19:02] <pnarciso> good, I love greybird
[19:02] <ochosi> i'm currently working towards a new icon-theme addon and also tweaking some stuff in greybird, if that's what you're asking ;)
[19:03] <pnarciso> the only issue with it, is that title bars are a little bit small for for 2560 resolutions
[19:03] <pnarciso> you have a greybird small theme, so a big greybird theme could make sense
[19:03] <ochosi> hm, could
[19:04] <ochosi> you have a high density display?
[19:04] <pnarciso> i have a dell 27 2560x1440
[19:04] <pnarciso> xubuntu by default looks very small
[19:05] <ochosi> yeah, there's no proper support for that resolution yet
[19:05] <pnarciso> I enlarged dpi and icon size, but can't do anything about title bars
[19:06] <pnarciso> also , i'm playing right now with compton compositor, it's great for xfce, no more tearing :)
[19:06] <pnarciso> and it's super lightweight
[19:07] <ochosi> mm, haven't tested that ever
[19:07] <ochosi> only recently tried gala once
[19:07] <pnarciso> well u don't know what u are missing
[19:08] <ochosi> so what does it do that xfwm4 doesn't?
[19:08] <pnarciso> vsync
[19:08] <pnarciso> and proper unredirection of fullscreen windows
[19:08] <pnarciso> which is great for games
[19:08] <pnarciso> it support opengl too
[19:09] <Unit193> !info compton saucy
[19:09] <ochosi> hm, there was a patch for that for xfwm4, but i think it never got merged
[19:10] <pnarciso> that patch won't work with nvidia, and it stil had tearing in the top of the screen, compton is perfect
[19:10] <Unit193> Well, anyway it isn't in the repo but it is a nice one, forked off of xcompmgr but I haven't personally used it.
[19:11] <pnarciso> there's a ppa for it
[19:11] <micahg> debian 679551
[19:11] <pnarciso> saucy is not added yet
[19:12] <pnarciso> I recomend compton with xfce, great combination, and the it works good along side xfwm4
[19:12] <Unit193> http://mentors.debian.net/package/compton indeed.
[19:12] <ochosi> is it helping at all with video-tearing?
[19:12] <pnarciso> yep
[19:12] <pnarciso> no more tearing
[19:12] <ochosi> hm, then i'll give it a shot
[19:13] <pnarciso> go here as a guide http://www.neowin.net/forum/topic/1148464-using-compton-for-tear-free-compositing-in-xfce/
[19:14] <pnarciso> I had to play a bit with the options to achieve perfect and smooth performance with my nvidia card
[19:14] <ochosi> right, wanna share the config then? (nvidia here too)
[19:15] <pnarciso> no prob
[19:15] <pnarciso> are you using proprietary
[19:15] <ochosi> yup
[19:15] <pnarciso> ok, first thing is to enable triple buffer in the driver
[19:16] <[uzver]> i'he no tearing in video playback with nvidia 319.* driver with compton on or off
[19:16] <ochosi> pnarciso: i don't see that option in the settings-gui, don't tell me i need to fiddle with xorg.conf
[19:17] <pnarciso> make a script with this options compton --backend glx --paint-on-overlay --glx-no-stencil --vsync opengl --glx-no-rebind-pixmap --unredir-if-possible --config ./.compton.conf -b &
[19:18] <pnarciso> yes, just add this line to your device options Option "TripleBuffer" "true"
[19:18] <[uzver]> place compton config in ~/.config/compton.conf
[19:19] <pnarciso> you could place the config file where you want but you must change that in the script
[19:20] <[uzver]> i have all startup keys in compton.conf, and start it just executin >compton
[19:21] <ochosi> yeah, only problem is i don't have any xorg.conf anymore
[19:21] <pnarciso> just type sudo nvidia-xconfig and it generates one
[19:21] <ochosi> and i'm not sure i want one, because i'm constantly switching between my external monitor and internal laptop monitor setups
[19:21] <ochosi> i remember getting that setup was tedious back in the xorg.conf days
[19:22] <pnarciso> that xorg file won't mess with that
[19:22] <pnarciso> nvidia drivers improved a lot
[19:23] <pnarciso> but you could test compton without messing with xorg, but in my testing I have found that triple buffer improves the performance with vsync
[19:24] <pnarciso> and not only with compton, with everything, because without it, framerate could flucuate from 60 to 30
[19:25] <ochosi> so what's in your compton.conf? (pastebin?)
[19:25] <ochosi> also, is there a --replace option i can add to replace xfwm4 in the running session or am i expected to kill it off by hand?
[19:26] <pnarciso> the only thing you do is to disable xfwm4 compositor and run the script
[19:27] <pnarciso> comton wont replace xfwm4 it only add composition
[19:27] <ochosi> seems the config file isn't autogenerated
[19:28] <pnarciso> no but you could use the sugestion in the site above
[19:28] <ochosi> k, thought you had tweaked that already to resemble greybird's shadow delta and everything ;)
[19:29] <pnarciso> the shadow radius and other stuff you tweak it to you liking
[19:29] <ochosi> why is firefox amongst the shadow-excludes?
[19:30] <knome> allö
[19:31] <pnarciso> I think the guy who wrote the guide dont like the shadow in firefox download notification so it added firefox, but you can remove it
[19:31] <ochosi> hm, not good, the notifications are now 100% not transparent :/
[19:32] <ochosi> also seems the "hide content of windows when moving" option of xfwm4 doesn't work with compton
[19:32] <ochosi> guess i have to restart to let that xorg.conf take effect...
[19:32] <pnarciso> yes, some things are not working
[19:33] <[uzver]> logout, to restart X
[19:33] <pnarciso> or it takes a little bit of tweaking
[19:33] <ochosi> brb
[19:33] <pnarciso> ok
[19:36] <ochosi> hm, feels quite smooth so far
[19:36] <ochosi> at least the window-fading and everythin
[19:36] <pnarciso> :)
[19:37] <ochosi> hm, resizing isn't that smooth
[19:40] <pnarciso> so, what do you think
[19:40] <ochosi> video-playback with mplayer2 regressed, while with vlc it seems better than before
[19:41] <ochosi> definitely worth a try though
[19:41] <pnarciso> regressed in what way
[19:41] <ochosi> it's stuttering
[19:42] <pnarciso> play with the video backends
[19:43] <ochosi> you mean in mplayer2?
[19:44] <pnarciso> I mean changing to opengl, vdpau, etc
[19:44] <pnarciso> parole works good with compton also
[19:45] <ochosi> window-movement is totally smooth, really curious that resizing works so badly
[19:45] <pnarciso> well, have you haver tried resizing with compiz? It's terrible, that because when you resize only a square appears
[19:46] <knome> compiz isn't really the compositor for any comparisons...
[19:46] <pnarciso> just found a minor thing with parole, when fullscreen the volume button is dark and the rest of the controls are blue
[19:47] <ochosi> pnarciso: yeah, we're working towards resolving that
[19:47] <ochosi> probably not in parole 0.5.1, but it's planned
[19:48] <pnarciso> well for now compton is replacing xfwm 4 compositor, it has more advantages
[19:48] <knome> exactly - if something is supposed to be super smooth, i wouldn't set compiz as the comparison point ;)
[19:49] <pnarciso> alsa resizing speed is not that bad, i only have issues with resizing in steam client
[19:50] <pnarciso> other apps seems to resize with good speed
[19:52] <lderan> poor compiz :P
[19:54] <pnarciso> compiz only started to perform good in 13.04, but with MIR with doomed to dissapear
[19:54] <pnarciso> compiz only started to perform good in 13.04, but with MIR it's doomed to dissapear
[19:54] <ochosi> i like compton so far, it seems to be a bit buggy though: http://www.zimagez.com/zimage/screenshot-05062013-095440pm.php
[19:55] <ochosi> (happens after resizing the temrinal a bit)
[19:55] <knome> ochosi, it's still Kaurismäki, not Kaurismäkki
[19:55] <knome>  ;>
[19:56] <ochosi> hehe, yeah, probably wasn't me who named it that way ;)
[19:57] <pnarciso> what's wrong with your pic
[19:57] <ochosi> look at the broken lines in the terminal
[19:58] <pnarciso> sorry can't see what's wrong lol
[19:59] <pnarciso> what lines?
[19:59] <ochosi> ah, nvm
[19:59] <ochosi> i'll test compton for a longer period, otherwise it's hard to say anything anyway
[20:03] <pnarciso> it could be a nice adition to xubuntu :)
[20:11] <ochosi> possible, would need quite a bit of testing on different hardware/setups though
[20:23] <pnarciso> compton can use xrender and opengl backend, so it works on all machines
[20:24] <ochosi> yeah, but we'd have to test it against xfwm4 on "all" machines for a serious comparison
[20:24] <ochosi> first step would be to get it into the ubuntu repos imo
[20:24] <ochosi> then it's easier for people to test it
[20:25] <ochosi> then we could post an article describing how to set it up and see how people respond
[20:26] <pnarciso> the ideal solution is xfce devs to take compton code and merge it with xfwm4
[20:27] <ochosi> not really, i think the ideal solution is a real patch that solves the tearing in xfwm4
[20:27] <pnarciso> xfce seems dead, devs missed released date and no news from them
[20:28] <ochosi> there was a 4.10.1 maintenance release just a day ago
[20:28] <ochosi> including a new release of thunar etc
[20:28] <pnarciso> they could use some of the compton code and use it in xfwm4
[20:28] <pnarciso> to add opengl in xfwm4
[20:29] <pnarciso> without it it's not possible have proper vsync
[20:32] <pnarciso> but any news about 4.12
[20:32] <ochosi> guess the motto is "release when ready"
[20:33] <ochosi> there's a ppa with some 4.12 components for Quantal (and I think raring too)
[20:33] <pnarciso> they could at least give the a preview of what is new
[20:34] <pnarciso> raring have all of them by default
[20:34] <pnarciso> and saucy
[21:04] <micahg> with an LTS coming within a year, we won't push in 4.12 unless we're sure we can stabilize it in time
[21:06] <ochosi> i guess much depends on when 4.12 is actually released
[21:07] <skellat> 4.12 is still stuck at an early stage the last time I checked
[21:12] <Noskcaj> new bug: clicking new partition table make a new table whether or not you click "confirm"
[21:13] <ochosi> skellat: depends on what you're checking. the roadmap isn't very accurate
[21:13] <skellat> ochosi: Alrighty
[21:14] <Noskcaj> is the bug in partman or ubiquity? it happens when you click the X
[21:15] <ochosi> skellat: it's not great, but this seems to be the best way to track the progress of 4.12: http://git.xfce.org/?s=idle
[21:24] <Noskcaj> Why does everything in the installer have a maximise button which doesn't always work?
[21:24] <Noskcaj> \
[21:31] <ochosi> Noskcaj: you're referring to ubiquity?
[21:32] <ochosi> in the ubiquity standalone-session or in the xubuntu-live session?
[21:41] <Noskcaj> ochosi, stand alone
[21:42] <ochosi> Noskcaj: so does it show the maximize button in all of the slides?
[21:43] <Noskcaj> ochosi, i think so, only just noticed
[21:43] <ochosi> i guess ubiquity should be setting some wm_hints then
[21:43] <ochosi> xnox: ^ ?
[21:44] <ochosi> Noskcaj: anyway, feel free to file a bugreport about it
[21:44] <ochosi> g2g
[21:44] <Noskcaj> ok, ty. bye
[22:19] <Noskcaj> bug 1177115 bug 1177116


[15:14] <cmaloney> Good morning
[16:51] <n0p> anyone use unattended-upgrades? i have it on for a few servers and just found my /boot partition full of kernels. Trying to see if a way to blocklist them..
[16:51] <n0p> best i found so far is this http://ubuntuforums.org/showthread.php?t=1500630
[16:52] <n0p> but some hack about tweaking the unattended-upgrades script direct (since it doesnt support regex in the Blacklist)
[16:54] <n0p> hmm, /me wonders if just uninstalling the inux-image-generic pkg will do it
[16:55] <n0p> i'll report back after a long hiatus ;-)
[16:57] <jrwren_> n0p: i've hit the same issue. I've never found a good solution.
[16:59] <n0p> the servers in question did have the meta generic image package, i uninstalled it and will see if that helps
[17:00] <n0p> i'm all ntp patched up now
[17:00] <n0p> http://www.ubuntu.com/usn/usn-2449-1/
[17:05] <rick_h_> n0p: isn't there a command to auto clean older kernels?
[17:08] <n0p> ¯\_(ツ)_/¯ I have one liner sed script to list em out (then remove), but would be nice to be preventative on the issue
[17:10] <n0p> other issue may be that the running kernel was the oldest kernel (since all the others were auto added since last start)
[17:11] <n0p> I'll get over it, but if I can figure a way to avoid the work, you know I'm there
[17:32] <mrgoodcat> dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge
[17:32] <mrgoodcat> ^^ cron that
[17:33] <mrgoodcat> if you're brave enough that is
[17:33] <mrgoodcat> mrgoodcat from the internet says its ok :)
[17:34] <cmaloney> Well then
[17:36] <mrgoodcat> but really i have run that line and it does work.
[17:36] <mrgoodcat> cron at your own risk though
[17:39] <mrgoodcat> n0p: uninstalling linux-image-generic will make it so you don't get prompted for kernel updates. i'd suggest keeping it
[17:39] <mrgoodcat> all it does is depend on the most recent kernel package
[17:48] <rick_h_> heh, I thought it was automted but seems to be a frequent enuogh question https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels and http://askubuntu.com/questions/2793/how-do-i-remove-or-hide-old-kernel-versions-to-clean-up-the-boot-menu
[18:32] <brousch_> rick_h_: No need to update your Apple, they will do it for you http://www.reuters.com/article/2014/12/23/us-apple-cybersecurity-idUSKBN0K108W20141223


[11:26] <dickhall> ifconfig?
[11:26] <dickhall> unless you're behind a router
[11:26] <xwolf-> i am
[11:26] <dickhall> ah
[11:26] <uniq> blaze: remove the package named 'libartsc0'
[11:26] <JavaGeek> klerfayt: since I usually keep my laptop on, I haven't actually looked if hibernate/suspend works
[11:27] <dickhall> well, your computer doesn't know it's external ip
[11:27] <dickhall> you could try whatismyip.com
[11:27] <blaze> uniq, is it only for KDE?
[11:27] <uniq> _rigonatti_: ah.. /dev/dsp isn't created.. looks like a driver problem then.
[11:27] <JavaGeek> or ismyiphotornot.com
[11:27] <dickhall> or are you wanting to do it programatically or something?
[11:27] <JavaGeek> :)
[11:28] <XVampireX_> godlkwrth: Thanks :)
[11:28] <_rigonatti_> uniq: can we solve this, doc ??  =P
[11:28] <uniq> blaze: only for KDE apps.
[11:28] <crimsun> _rigonatti_: pastebin ``cat /proc/asound/cards && amixer''
[11:28] <_rigonatti_> hi jack!
[11:28] <godlkwrth> XVampireX_, okay "save" should save all of these settings and you should be able to use it now without a problem
[11:28] <Jack_Sparrow> Hello
[11:28] <godlkwrth> even through reboot
[11:28] <blaze> ok, uniq, 10x a lot :)
[11:29] <godlkwrth> what it does, is it edits the configuration file /etc/network/interfaces for you
[11:29] <godlkwrth> it's just a nice frontend to that, I think
[11:29] <Jack_Sparrow> imBrandon was supposed to come back and show me how to install his XP THeme
[11:30] <godlkwrth> XVampireX_, you may need to issue a "killall -9 dhclient dhcpcd"
[11:30] <godlkwrth> to stop the current dhcp client
[11:30] <uniq> _rigonatti_: I have to go to bed now, i can barely see the text on the screen. But it shouldn't be impossible to make sound work.
[11:30] <_rigonatti_> uniq http://kubuntu.pastebin.com/745663
[11:30] <godlkwrth> or, find the process in the KDE Process Viewer and kill it from there
[11:31] <crimsun> _rigonatti_: ``lspci -v && lsmod''
[11:31] <_rigonatti_> uniq: txs, man!! Take care!
[11:31] <beber> is a big community here!!!
[11:31] <XVampireX_> How do I access the KDE Process viewer?
[11:31] <uniq> xvampirex_: ctrl+esc
[11:31] <uniq> nite all.
[11:32] <XVampireX_> Alright :)
[11:32] <XVampireX_> thanks
[11:32] <XVampireX_> good night
[11:32] <_rigonatti_> crimsun: http://kubuntu.pastebin.com/745667
[11:33] <godlkwrth> XVampireX_, do you see dhclient or dhcpcd in the process list
[11:33] <XVampireX_> I don't know, it's my friend, I'm just helping him :P
[11:34] <crimsun> _rigonatti_: can you disable the modem in bios?
[11:34] <Jack_Sparrow> When I reinstall windows it will kill my grub loader right?
[11:34] <_rigonatti_> crimsun: Im not shure ....but i can try ... its my modem the trouble ?
[11:35] <crimsun> _rigonatti_: perhaps irq
[11:35] <XVampireX_> godlkwrth: "I have dhclient3"
[11:35] <XVampireX_> "no dhpcd"
[11:35] <godlkwrth> okay issue a kill
[11:35] <godlkwrth> to that process
[11:35] <_rigonatti_> humm...ok...but i think thats is not possible in BIOS
[11:35] <_rigonatti_> crimsun: have another way ?
[11:35] <godlkwrth> should be in the menu options somewhere, or a right click may have it
[11:36] <XVampireX_> godlkwrth: But next time the computer is restarted, it will be there again, right?
[11:36] <crimsun> _rigonatti_: please check the bios at least
[11:36] <godlkwrth> shouldn't
[11:36] <XVampireX_> Alright :)
[11:36] <_rigonatti_> ok...let me finish my Adept update....is almost 98%
[11:36] <XVampireX_> godlkwrth: "insufficient permissions"
[11:37] <godlkwrth> ah
[11:37] <godlkwrth> what does the title say
[11:37] <XVampireX_> I told him to get the PID and do kill through konsole
[11:37] <godlkwrth> "KDE System Guard"?
[11:37] <godlkwrth> yeah that will work too
[11:38] <godlkwrth> sudo killall -9 dhclient3
[11:38] <XVampireX_> Okey :)
[11:39] <godlkwrth> and hopefully it hasn't renewed the lease since the time we edited it
[11:39] <XVampireX_> It did once
[11:40] <XVampireX_> But he put it back to the DNS server
[11:40] <XVampireX_> and then killed it
[11:40] <godlkwrth> i wish all network devices would play nice, so this wouldn't be necessary :P
[11:41] <XVampireX_> Yeah :-/
[11:41] <godlkwrth> what router is it?
[11:41] <XVampireX_> Thanks again :)
[11:42] <XVampireX_> It's b-focus 312+
[11:42] <XVampireX_> It's router integrated in a modem
[11:42] <godlkwrth> ok, so everything works now?
[11:42] <XVampireX_> Supposedly, yeah
[11:44] <godlkwrth> cool.
[11:46] <XVampireX_> Thanks :D
[11:46] <godlkwrth> np
[11:47] <ederich> hallo, anybody know if kubuntu live comes with KILE installed?
[11:47] <xwolf--> what is it?
[11:47] <dickhall> latex
[11:47] <ederich> kile the latex enviroment
[11:47] <dickhall> I don't think so... kubuntu Breezy doesn't have it, at least
[11:51] <godlkwrth> it's in universe
[11:58] <james_xxx> would there be anyone here who is familiar with the Opera web browser? i am having issues with it
[11:58] <ederich> a bit
[11:59] <apokryphos> !helpme
[11:59] <ubotu> If you do not actually ask a question, we cannot actually help you. :)
[11:59] <james_xxx> ederich: well, i had installed opera a few weeks ago. and it worked fine until this afternoon. now it won't work at all
[12:00] <james_xxx> when i type 'opera' into the terminal , i get 'segmentation fault'
[12:00] <ederich> ?
[12:02] <james_xxx> yeah, i have no clue either. i have tried re-installing opera... i have un-installed it... and then installed it once more. nothing seems to help
[12:02] <james_xxx> apokryphos: do you have any suggestions?
[12:03] <chuck> Hi, I can not change my screen resoulation off of 640x480 any suggestions


[00:14] <slangasek> xnox: I feel like you might be the person to ask about stray dirmngr processes left hanging around in an image chroot after apt has been run
[00:16] <xnox> slangasek, yeah....
[00:16] <slangasek> xnox: how can I fix this?
[00:16] <xnox> pkill ?
[00:16] <slangasek> mmhmm :)
[00:17] <xnox> on a more serious note, things should not be hitting the network, or trying to retrieve gpg keys.
[00:17] <slangasek> "things"?
[00:17] <xnox> soemthing somewhere calls gnupg and doesn't clean up. You don't mean that a simple "apt update" results in stray dirmngr?
[00:18] <slangasek> xnox: probably the apt-key call
[00:18] <xnox> yes, apt-key would do it. one should not call apt-key.... and just ship key snippets (like ubuntu-keyring does)
[00:18] <xnox> or are you adding/enabling PPAs with apt-key?
[00:18] <slangasek> ppa
[00:19] <xnox> ... and not using add-apt-repository?
[00:19] <slangasek> this script *also* uses add-apt-repository
[00:19] <slangasek> let me see if the apt-key stuff is superfluous
[00:19] <xnox> if add-apt-repository results in stray dirmngr, i should fix that.
[00:19] -queuebot:#ubuntu-release- New: accepted qbs [amd64] (zesty-proposed) [1.7.0+dfsg-3]
[00:19] -queuebot:#ubuntu-release- New: accepted qbs [armhf] (zesty-proposed) [1.7.0+dfsg-3]
[00:19] -queuebot:#ubuntu-release- New: accepted qbs [powerpc] (zesty-proposed) [1.7.0+dfsg-3]
[00:19] -queuebot:#ubuntu-release- New: accepted qbs [s390x] (zesty-proposed) [1.7.0+dfsg-3]
[00:19] -queuebot:#ubuntu-release- New: accepted qbs [arm64] (zesty-proposed) [1.7.0+dfsg-3]
[00:19] -queuebot:#ubuntu-release- New: accepted qbs [ppc64el] (zesty-proposed) [1.7.0+dfsg-3]
[00:19] -queuebot:#ubuntu-release- New: accepted qbs [i386] (zesty-proposed) [1.7.0+dfsg-3]
[00:19] <slangasek> however, there's also a cleanup phase here of 'sudo apt-key del ${ppa_key}'
[00:19] <slangasek> is that going to provoke dirmngr?
[00:20] <xnox> that should be safe.
[00:20] <xnox> apt-key adv is not.
[00:20] <slangasek> ok
[00:21] <slangasek> that does seem like a bug in apt-key, anyway
[00:22] <xnox> that it doesn't clean up dirmngr (or any other spawned agents) post-adv command? (which are actually passthrough to gpg command, which now started to spawn garbage)
[00:22] <slangasek> yes
[00:23] <slangasek> apt-key appears to run with a temporary GNUPGHOME dir
[00:23] <slangasek> and anything spawned that references that dir is lost
[00:24] <slangasek> and add-apt-repository adds the ppa, but packages from that ppa are listed as unauthenticated
[00:24] <slangasek> unpleasant
[00:24] <xnox> slangasek, $ gpgconf --list-components | sed 's/:.*//' | xargs -L1 gpgconf --kill
[00:25] <xnox> probably slightly better (e.g. don't try to kill gpg "component") is needed.
[00:25] <xnox> add-apt-repository should have been fetching a key =/ iff it can access things (do you need proxy to access ubuntu keyserver?!)
[00:26] <slangasek> xnox: but doesn't that require the matching GNUPGHOME, so gpgconf can see which of the running processes is its?
[00:26] <xnox> sure it does, hence it should be in the apt-key cleanup.
[00:26] <xnox> (as in apt-key itself should be doing that)
[00:27] <xnox> which btw is just a fancy pkill
[00:27] <slangasek> right
[00:27] <slangasek> so we agree it's an apt-key bug
[00:27] <xnox> but i thought that add-apt-repository did the right thing (tm)
[00:27] <xnox> so possibly two bugs.
[00:27]  * slangasek nods
[00:28] <slangasek> oh
[00:28] <slangasek> hmm
[00:33] <slangasek> xnox: add-apt-repository doesn't know to fetch ppa keys for a private ppa :P
[00:34] <xnox> oh, you want that
[00:34] <slangasek> well, all things considered, I really do not
[00:34] <slangasek> ;)
[00:34] <slangasek> but I currently have
[00:34] <xnox> slangasek, use curl to fetch private ppa key off keyserver and pipe it into a file.
[00:35] <slangasek> alternatively, I can batch-copy things out of the private to a public one because thbt
[00:37] <xnox> slangasek, or you can specify [trusted=yes] on the ppa entry you are using.
[00:37] <xnox> given you delete the key afterwards anyway... and building in secure environment anyway....
[00:37] <xnox> and forget about keys.
[00:53] <slangasek> xnox: same problem with add-apt-repository
[00:54] <xnox> marvelous.
[00:54] -queuebot:#ubuntu-release- Unapproved: lxc (xenial-proposed/main) [2.0.6-0ubuntu1~ubuntu16.04.1 => 2.0.6-0ubuntu1~ubuntu16.04.2] (ubuntu-server)
[00:54] <xnox> killall dirmngr sounds appropriate size of ikea hammer.
[00:55] <slangasek> Executing: /tmp/tmp.DaevBURr1s/gpg.1.sh --keyserver keyserver.ubuntu.com --recv
[00:55] <slangasek> gpg: keybox '/tmp/tmp0_lqr33e/pubring.gpg' created
[00:55] <slangasek> root      2600  0.0  0.0 175736  4088 ?        Ssl  16:51   0:00  \_ dirmngr --daemon --homedir /tmp/tmp0_lqr33e
[00:55] -queuebot:#ubuntu-release- Unapproved: lxc (yakkety-proposed/main) [2.0.6-0ubuntu1~ubuntu16.10.1 => 2.0.6-0ubuntu1~ubuntu16.10.2] (ubuntu-server)
[00:55] <slangasek> yeah
[00:55] <xnox> also, i'm confused why gpg doesn't just kill dirmngr at the end of execution....
[00:57] <slangasek>                      root       4891 .rce. gpg-agent
[00:57] <slangasek> wat
[00:57] <xnox> yeah that too
[00:58] <xnox> apperantly gpg-agent is needed to store keys....
[00:58] <stgraber> why did they make such a mess with gpg2...
[00:58]  * xnox was not kidding when i said pipe curl from keyserver into /etc/apt/trusted.gpg.d/foo.gpg file
[00:58] <xnox> gpg2.1, i think gpg2.0 was still sane.
[00:59] <stgraber> it's really tempting to distro patch gpg to record what it auto-spawns and kill them all on exit, basically re-introducing good old gpg1 behavior (except it used to do everything in-process)
[00:59] <xnox> racy
[01:00] <stgraber> not if you have them listen on a per-process temp path :)
[01:00] <xnox> one can spawn to /usr/bin/gpg which are waiting on results from e.g. the same dirmgr
[01:00] <xnox> hahaha
[01:00] <xnox> i think upstream rejected systemd socket activation =)
[06:46] -queuebot:#ubuntu-release- Unapproved: systemd (trusty-proposed/main) [204-5ubuntu20.20 => 204-5ubuntu20.21] (core)
[10:00] <LocutusOfBorg> novaclient.exceptions.OverLimit: Quota exceeded for ram: Requested 8192, but already used 48640 of 51200 ram (HTTP 413) (Request-ID: req-ecaa7c79-5e1f-4106-8b3f-7664a086b1cf)
[10:00] <LocutusOfBorg> ERROR (OverLimit): Quota exceeded for ram: Requested 8192, but already used 48640 of 51200 ram (HTTP 413) (Request-ID: req-ecaa7c79-5e1f-4106-8b3f-7664a086b1cf)
[10:00] <LocutusOfBorg> Laney, ^^ seems that retrying poppler autopkgtestsuite against libreoffice fails on i386
[10:00] <LocutusOfBorg> I would like to finish that poppler stuff :/
[10:03]  * LocutusOfBorg leaves
[10:05] <LocutusOfBorg> rmadison -u ubuntu cups-ipp-utils
[10:05] <LocutusOfBorg> universe ^^
[10:05] <LocutusOfBorg> doko, promote to main and unblock cups?
[10:05] <Laney> It'll retry itself
[10:06] <LocutusOfBorg> cups-filters-core-drivers/* unsatisfiable Depends: cups-ipp-utils
[10:06] <Laney> libreoffice wants a large instance
[10:06] <LocutusOfBorg> thanks Laney :)
[10:06] <LocutusOfBorg> I'm already trying the reverse-dependencies
[10:06] <LocutusOfBorg> if the laptop battery resists, I'll also set up a ben file
[10:07] <LocutusOfBorg> cups needs a move to main of cups-ipp-utils anyway I guess
[10:09] <LocutusOfBorg> poppler is already on ben
[10:35] -queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (yakkety-proposed) [2.0.6-0ubuntu1~ubuntu16.10.2]
[10:36] -queuebot:#ubuntu-release- Unapproved: accepted lxc [source] (xenial-proposed) [2.0.6-0ubuntu1~ubuntu16.04.2]
[10:42] -queuebot:#ubuntu-release- Unapproved: accepted sbuild-launchpad-chroot [source] (yakkety-proposed) [0.13.1ubuntu16.10.1]
[10:58] -queuebot:#ubuntu-release- Unapproved: accepted util-linux [sync] (yakkety-proposed) [2.28.2-1ubuntu1.1]
[11:02] -queuebot:#ubuntu-release- Unapproved: accepted util-linux [sync] (xenial-proposed) [2.27.1-6ubuntu3.2]
[11:02] <ginggs> would an ubuntu-archive admin remove python-sunpy and python3-sunpy 0.7.3-1 on armhf and arm64 from -proposed please? LP: #1643151
[11:02] <ubot5`> Launchpad bug 1643151 in sunpy (Ubuntu) "Please remove sad pandas and friends" [Undecided,New] https://launchpad.net/bugs/1643151
[14:54] -queuebot:#ubuntu-release- New source: bubblewrap (xenial-proposed/primary) [0.1.5-1~ubuntu16.04.1]
[16:16] <barry> tsimonq2: how did your revert test go?
[16:25] <apw> ginggs, looking
[16:27] <apw> ginggs, done
[16:56] <mvo> can someone please release snapd 2.20.1ubuntu1 for xenial and 2.20.1+16.10ubuntu2 for yakkety? verification is done. there is an autopkgtest failure on ppc64el but despite what the tracker says this is not a real regression because there was a hickup in a previous upload and that was responsible for this "passed on ppc64el" result
[17:02] -queuebot:#ubuntu-release- New binary: yaz [ppc64el] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
[17:04] -queuebot:#ubuntu-release- New binary: yaz [s390x] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
[17:05] -queuebot:#ubuntu-release- New binary: yaz [amd64] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
[17:05] -queuebot:#ubuntu-release- New binary: yaz [powerpc] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
[17:06] -queuebot:#ubuntu-release- New binary: yaz [arm64] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
[17:06] -queuebot:#ubuntu-release- New binary: yaz [armhf] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
[17:08] -queuebot:#ubuntu-release- Unapproved: accepted update-manager [source] (xenial-proposed) [1:16.04.5]
[17:11] -queuebot:#ubuntu-release- New binary: yaz [i386] (zesty-proposed/universe) [5.19.2-0ubuntu1] (no packageset)
[18:08] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-release-upgrader [source] (xenial-proposed) [1:16.04.21]
[18:17] -queuebot:#ubuntu-release- Unapproved: ubuntu-gnome-meta (xenial-proposed/universe) [0.58.1 => 0.58.2] (ubuntugnome)
[18:19] <dmj_s76> When are we expecting kernel 4.8 to land in the daily iso for 16.04.2?
[18:21] <jbicha> bdmurray: if you can, please look at accepting ubuntu-gnome-meta 0.58.2 in to xenial-proposed so it's ready in time for 16.04.2
[18:39] -queuebot:#ubuntu-release- Unapproved: accepted ubuntu-gnome-meta [source] (xenial-proposed) [0.58.2]
[18:40] <jbicha> thank you!
[19:22] <slangasek> infinity: ^^ 4.8 in xenial dailies? done?
[20:10] <tkamppeter> Hi, I have synced cups-filters 1.13.2 from Debian to Zesty some days ago, why did it not make it from -proposed to the release?
[20:33] <nacc> tkamppeter: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says unsatisfiable depends cups-ipp-utils
[20:34] <tkamppeter> nacc, why unsatisfiable depends on cups-ipp-utils? cups-ipp-utils is part of the cups source package which is in main.
[20:34] <slangasek> which means the binary needs promoting to main
[20:34] <slangasek> (done now)
[20:35] <nacc> tkamppeter: yeah it was a mismatch http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed
[20:35] <tkamppeter> slangasek, thanks.
[20:35] <tkamppeter> nacc, also thanks.
[20:36] <nacc> tkamppeter: np
[21:12] -queuebot:#ubuntu-release- Unapproved: accepted graphviz [source] (xenial-proposed) [2.38.0-12ubuntu2.1]
[21:15] -queuebot:#ubuntu-release- Unapproved: accepted graphviz [source] (yakkety-proposed) [2.38.0-15ubuntu1.1]
[21:17] <juliank> I feel like we should let apt 1.2.18 enter xenial-updates now. While nobody verified 1592817 as fixed, there seem to be no new reports in it for -proposed (bdmurray). There's a ton of other bugs verified fixed, and it's really important to get this done now, as it apparently breaks upgrades to yakkety for some people. Most of this has been waiting since November's 1.2.16 upload, so it really is a bit older than overviews make you think :)
[21:18] <juliank> There were some autopkgtest failures, but those are not regressions caused by apt since the last apt upload
[21:21] -queuebot:#ubuntu-release- Unapproved: accepted overlay-scrollbar [source] (xenial-proposed) [<IP_ADDRESS>+16.04.20151117-0ubuntu<IP_ADDRESS>]
[21:21] <bdmurray> How are the autopkgtest failures not regressions?
[21:23] -queuebot:#ubuntu-release- Unapproved: accepted overlay-scrollbar [source] (yakkety-proposed) [<IP_ADDRESS>+16.04.20151117-0ubuntu<IP_ADDRESS>]
[21:29] -queuebot:#ubuntu-release- Unapproved: accepted fcitx [source] (xenial-proposed) [1:<IP_ADDRESS>-1ubuntu<IP_ADDRESS>]
[21:32] -queuebot:#ubuntu-release- Unapproved: accepted fcitx [source] (yakkety-proposed) [1:<IP_ADDRESS>-4ubuntu1]
[21:33] -queuebot:#ubuntu-release- Unapproved: libseccomp (trusty-proposed/main) [2.2.3-2ubuntu1~ubuntu14.04.1 => 2.1.1-1ubuntu1~trusty3] (core)
[21:35] -queuebot:#ubuntu-release- Unapproved: accepted maas [source] (xenial-proposed) [2.1.3+bzr5573-0ubuntu1~16.04.1]
[21:35] <juliank> bdmurray: They happen in apport, autopkgtest, and sbuild; and if you look at the logs, already earlier (even with 1.2.15). I think all of them started as soon as yakkety opened.
[21:38] <juliank> It would be a wise thing to fix them at some point, but I have not gotten around to that, and apparently nobody else either :/
[21:42] <juliank> apport actually started failing in August, at that point, the wily ddeb archive started showing signature errors in apt - without a change in apt.
[21:42] <juliank> These tests will stop working even more once wily is dropped from the archive.
[21:43] <juliank> or well, that was the issue
[21:43] <juliank> the ddebs were dropped at that time
[21:45] -queuebot:#ubuntu-release- Unapproved: accepted initramfs-tools [source] (xenial-proposed) [0.122ubuntu8.8]
[22:13] <jdstrand> bdmurray: happy new year! I could you take a look at libseccomp on trusty in the unapproved queue?
[22:13] <jdstrand> s/I could/could/
[22:13] <jdstrand> bdmurray: this is to address bug 1653487
[22:13] <ubot5`> bug 1653487 in libseccomp (Ubuntu) "seccomp argument filtering not working on trusty" [High,In progress] https://launchpad.net/bugs/1653487
[23:03] <bdmurray> jdstrand: I was on a call, looking now
[23:05] <bdmurray> jdstrand: its meant to supersede the existing upload?
[23:06] <jdstrand> bdmurray: yes. it includes everything that was in it
[23:06] <bdmurray> jdstrand: I guess I meant you don't care if the other doesn't get released first?
[23:08] <jdstrand> bdmurray: do not release the other first (there is no point since this SRU is for snappy and the previous upload doesn't work with snappy amd64)
[23:08] <jdstrand> bdmurray: basically, this fixes the verification-failed of Tyler's upload
[23:09] <bdmurray> jdstrand: got it
[23:09] <jdstrand> bdmurray: so reject Tyler's, and accept this one (which is Tyler's plus patches to fix the failure)
[23:09] <jdstrand> cool
[23:11] <bdmurray> fyi bug 1653487 has no trusty task
[23:11] <ubot5`> bug 1653487 in libseccomp (Ubuntu) "seccomp argument filtering not working on trusty amd64" [High,In progress] https://launchpad.net/bugs/1653487
[23:12] <jdstrand> bdmurray: fixed
[23:15] -queuebot:#ubuntu-release- Unapproved: accepted libseccomp [source] (trusty-proposed) [2.1.1-1ubuntu1~trusty3]
[23:15] <jdstrand> bdmurray: thanks!
[23:16] <bdmurray> jdstrand: I think there's something wrong with your "Send" button
[23:16] <jdstrand> mm?
[23:23] -queuebot:#ubuntu-release- Unapproved: accepted os-prober [source] (xenial-proposed) [1.70ubuntu3.2]
[23:54] -queuebot:#ubuntu-release- Unapproved: accepted systemd [source] (xenial-proposed) [229-4ubuntu14]


[07:04] <mborzecki> morning
[07:56] <mborzecki> mvo: morning
[07:56] <mvo> good morning mborzecki
[07:59] <mup> PR snapd#9835 closed: tests: apply workaround done for snap-advise-command to apt-hooks test <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9835>
[08:08] <mborzecki> mvo:  can you land https://github.com/snapcore/snapd/pull/9831 ? the failures are in apt-hooks and snap-advise-command again
[08:08] <mup> PR #9831: interfaces/builtin: fix unit test expecting snap-device-helper at /usr/lib/snapd <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9831>
[08:17] <mvo> mborzecki: sure thing
[08:19] <mborzecki> mvo: https://github.com/snapcore/snapd/pull/9819#discussion_r556493129 /etc/dbus-1 is in centos-*, amzn2, 14.04, and must be in other other systems too
[08:19] <mup> PR #9819: snap-confine: make host /etc/ssl available for snaps on classic <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9819>
[08:19] <mup> PR snapd#9831 closed: interfaces/builtin: fix unit test expecting snap-device-helper at /usr/lib/snapd <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9831>
[08:19] <mborzecki> i can push a tweak there
[08:20] <mvo> mborzecki: but dbus-1 does not come from the host?
[08:20] <mvo> mborzecki: or am I missing something?
[08:21] <mborzecki> mvo: ahh right, i need my morning coffee clearly
[08:21] <mvo> mborzecki: does my reply in there make sense?
[08:21] <mvo> mborzecki: ok :) no worries!
[08:22] <pstolowski> morning
[08:22] <mborzecki> mvo: /etc/nsswitch is doubly problematic, it's a file in most systems, but a symlink on fedora ;) which we skip by default
[08:22] <mborzecki> let me check /etc/alternatives
[08:24] <mvo> mborzecki: alternatives are a debian thing, not sure if those ever were adopted someplace else
[08:26] <mborzecki> mvo: hm looks like only arch is missing it, which is ok i think?
[08:31] <zyga> mvo, I think suse has those as well
[08:31] <zyga> are we finally exploring untangling /etc
[08:34] <zyga> good morning
[08:34]  * zyga is trying to drop the coffee
[08:39] <mvo> mborzecki: +1
[08:39] <mvo> mborzecki: I can update (unless you have this ready)
[08:39] <mborzecki> zyga: hey, can you take a quick look at https://build.opensuse.org/request/show/862869 with your morning coffee?
[08:40] <zyga> mborzecki, I stopped using coffee :)
[08:40] <zyga> but yeah, sure :)
[08:40] <mborzecki> mvo: the spread run is still in progress, if it's successful i'd rather merge it and do a follow up
[08:40] <mvo> mborzecki: sounds great
[08:41] <mvo> mborzecki: fwiw, samuele marked it as "needs-samuele-review" so we only only land after his +1
[08:41] <mborzecki> mvo: right, in which case i may push a tweak for that test then :)
[08:41] <mvo> zyga: no untangling of etc yet :( not sure I will ever see this day
[08:41] <mvo> mborzecki: yeah
[09:06] <pstolowski> mborzecki: thanks for the review of validation-sets
[09:07] <mborzecki> pstolowski: yw
[09:07] <pstolowski> mborzecki: btw, snapd-generator fix is ready fo re-review ;)
[09:24] <zyga> mborzecki, is the system:snappy approval enough or do you need me to do some follow up steps?
[09:25] <mborzecki> zyga: no, having a 2nd pair of eyes glance at the spec is enough, thanks!
[09:29] <mup> PR snapd#9513 closed: snapshotstate: detect duplicated snapshot imports <Needs Samuele review> <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9513>
[09:30] <ogra> mvo, did anyone test the classic snap on UC20 (should we delist it finally ? or just make it print "please use lxd" ... or something like that) ... https://forum.snapcraft.io/t/uc-20-snapcraft-install-issue/22162/4
[09:30] <mvo> ogra: great point, we should probably suggest using lxd at this point
[09:30] <pstolowski> mvo: ^ #9513, finally! \o/
[09:31] <mup> PR #9513: snapshotstate: detect duplicated snapshot imports <Needs Samuele review> <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9513>
[09:31] <ogra> yeah
[09:31] <mvo> pstolowski: nice
[09:31] <pstolowski> any idea why tests/go.mod gets updated behind my back sometimes?
[09:32] <mvo> pstolowski: compiling go things inside tests
[09:32] <mvo> pstolowski: in a meeting
[09:33] <pstolowski> hmm, interesting, thanks
[09:36] <jamesh> mvo: here's the output run against the snapd snap: https://paste.ubuntu.com/p/m5RHWNs7jn/ -- there's obviously some false positives w.r.t. the NSS plugins, since they look like regular libraries
[09:38] <mvo> jamesh: thanks, still in a meeting but will get back to you
[09:42] <mborzecki> mvo: #9819 failed in the dirs-not-shared-with-host test, i'll push a tweak to use /etc/alternatives
[09:42] <mup> PR #9819: snap-confine: make host /etc/ssl available for snaps on classic <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9819>
[10:01] <mborzecki> mvo: hah, there's no /etc/alternatives in the core snap
[10:01] <mvo> mborzecki: oh, fun!
[10:01] <mborzecki> maybe it got removed at some point
[10:02] <mborzecki> mvo: i suppose we stay with apparmor.d for now, and just blacklist the systems where it's not on the host
[10:04] <mvo> mborzecki: do we need to blacklist? /etc/ssl is also not available and still works, no?
[10:04] <mvo> mborzecki: also in a meeting still
[10:18] <mborzecki> mvo: haha, more fun, /etc/os-release on debian has no ID_LIKE=debian ;)
[10:23] <mvo> mborzecki: woah! just woah!
[10:23] <mvo> mborzecki: well, I guess it makes sense
[10:23] <mvo> mborzecki: but :)
[10:23] <mborzecki> mvo: i'm looking into fixing that
[10:24] <mvo> mborzecki: ta
[10:40] <mup> PR snapd#9838 opened: asserts: sort by revision with Sort interface <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9838>
[10:54] <pstolowski> mborzecki: ^
[10:57] <mborzecki> pstolowski: will look in a bit
[10:57] <mborzecki> mvo: pushed the changes to #9819 please take a look
[10:57] <mup> PR #9819: snap-confine: make host /etc/ssl available for snaps on classic <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9819>
[10:58] <mborzecki> ogra: have you already applied for BeagleV?
[10:59] <mborzecki> looks like the initial batch of those boards is going to be quite small
[10:59] <mvo> mborzecki: thank you, checking
[11:15] <ogra> mborzecki, only heard about it yesterday ... havent yet,m no ... but i plan to in a later batch
[11:53] <mborzecki> pstolowski: couple more comments https://github.com/snapcore/snapd/pull/9817
[11:53] <mup> PR #9817: cmd/snapd-generator: don't create mount overrides for snap-try snaps inside lxc <Bug> <Needs security review> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9817>
[11:53] <pstolowski> ty
[12:38] <mborzecki> pstolowski: mvo: can we merge https://github.com/snapcore/snapd/pull/9732 ? 2 +1, the error on xenial is unrelated
[12:38] <mup> PR #9732: asserts: snapasserts method to validate installed snaps against validation sets <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9732>
[12:42] <pstolowski> mborzecki: yes, totally, but may need manual merge again
[12:45] <mup> PR snapd#9839 opened: tests: spread log analyzer that could be used for re execute failed tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9839>
[12:45] <mup> PR snapd#9840 opened: interfaces/builtin: Allow DBus property access on org.freedesktop.Notifications <Created by kbroulik> <https://github.com/snapcore/snapd/pull/9840>
[13:01] <pstolowski> pedronis: #8532 has +1 from me, with some tweaks
[13:01] <mup> PR #8532: tests: install new snapd deb into preseed image <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8532>
[13:06] <pedronis> pstolowski: thx, I queued it but not sure when I'll get to it
[13:06] <pedronis> pstolowski: I might have questions
[13:28] <ijohnson> morning folks
[13:52] <mup> PR snapcraft#3404 closed: build(deps): bump lxml from 4.5.0 to 4.6.2 <dependencies> <python> <Created by dependabot[bot]> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3404>
[13:52] <mup> PR snapcraft#3417 closed: Allow validation assertions to be revoked <Created by nessita> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3417>
[13:59] <mvo> pstolowski: I can merge 9732 if the current run is not green, just ping me
[13:59] <pstolowski> mvo: ty
[14:01] <mup> PR snapd#9834 closed: tests: normalize test tools - part 1 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9834>
[15:04] <zyga> good morning ijohnson
[15:04] <ijohnson> hey zyga
[15:04] <zyga> ijohnson, how do you find focus to work in the last few days?
[15:04] <ijohnson> ha
[15:04] <ijohnson> memes, lots and lots of memes
[15:04] <zyga> is sergio around?
[15:05] <zyga> ijohnson, I think we all want to wake up in Feb
[15:05] <ijohnson> zyga: huh yeah Sergio was in SU, not sure why he's not on IRC
[15:05] <zyga> ah, no worries, I'll wait
[15:06] <ijohnson> zyga: yeah that's what everybody kept saying about after November "I can't wait for XXX to be over" :-P
[15:06] <mup> PR snapd#9732 closed: asserts: snapasserts method to validate installed snaps against validation sets <validation-sets :white_check_mark:> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/9732>
[15:06] <zyga> ijohnson, yeah, I really hope it's one of those shows where the finale is just boring though
[15:07] <ijohnson> indeed, that's all our hopes really
[15:07] <zyga> ijohnson, not sure how it looks from your point of view but I was not expecting any of that to happen
[15:07]  * zyga waits for debootstrap to run
[15:07] <zyga> let me grab some water quickly
[15:07] <ijohnson> yeah it was really unexpected, I mean I was nervous something was gonna happen, but I never imagined that it would come to that
[15:11] <mvo> pstolowski: if you merged master into 9838 it will be a lot smaller now, yes?
[15:13] <pstolowski> mvo: yes, going to do in a sec
[15:18] <mvo> mborzecki: I added some comments to 9819. thanks a lot for updating it!
[15:22] <mup> PR snapcraft#3418 closed: project: always set target arch even if not cross compiling <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3418>
[15:31]  * cachio lunch
[15:31] <pstolowski> mvo: updated
[15:38] <mvo> ta
[15:45] <pstolowski> mborzecki: can you +1 #9838?
[15:45] <mup> PR #9838: asserts: sort by revision with Sort interface <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9838>
[16:58] <pstolowski> just saw interesting failure of uc20-create-partitions test: https://paste.ubuntu.com/p/VCjQWKwP72/
[16:58] <pstolowski> mvo: ^
[17:10] <mvo> pstolowski: woah, "bad message" ?!?
[17:11] <pstolowski> mvo: that was on #9838, so nothing related to my branch
[17:11] <mup> PR #9838: asserts: sort by revision with Sort interface <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9838>
[17:12] <mup> PR snapcraft#3410 closed: project: enable experimental target-arch support for core20 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3410>
[17:12] <mvo> pstolowski: right
[18:01] <ijohnson> mvo: that mount error message seems to be because the kernel is returning silly error messages for bad CRC detection:
[18:01] <ijohnson> > This is because kernel uses EBADMSG errno for "Bad CRC detected" situation.
[18:01] <ijohnson> from https://bugzilla.redhat.com/show_bug.cgi?id=1496764
[18:31] <mvo> ijohnson: thanks
[18:54] <jdstrand> jjohansen: hey, what is the status of the quiet profile flag?
[18:59] <jjohansen> jdstrand: currently scheduled for 3.1 but it could get pushed to 3.2 if higher priority items don't give me time to finish up the work on it
[19:02] <jdstrand> jjohansen: thanks!
[19:28] <ijohnson> hey jdstrand, what is the status of https://bugs.launchpad.net/snapd/+bug/1868051? the mentioned pr was merged, so can I mark it as fixed ?
[19:28] <mup> Bug #1868051: browser-support[allow-sandbox=true] should not grant access to /var/lib/snapd/desktop/applications <snapd:In Progress by jdstrand> <https://launchpad.net/bugs/1868051>
[19:52] <mup> PR snapcraft#3350 closed: project loader, schema: add advanced grammar support for build-environment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3350>
[19:57] <mup> PR snapd#9829 closed: tests: cleanup the run-checks script <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9829>
[20:04]  * cachio afk
[20:10] <jdstrand> ijohnson: let me check
[20:16] <jdstrand> ijohnson: yep, fixed. I updated the bug
[20:17] <jwheare> does anyone in here use the irccloud snap? if so would you mind testing the latest edge/candidate release before i promote it to stable? i just significantly rejigged our build process and bumped the main deps (including electron) several major versions  and want to make sure i didn't mess anything up. thanks https://snapcraft.io/irccloud
[20:28] <zyga> jwheare, that's nice, I suggest talking about it on the forum as well
[20:59] <ijohnson> thanks jdstrand
[21:00] <ijohnson> jwheare: sure I can give it a spin
[21:24] <ijohnson> jwheare: seems to work fine for me, no problems that I can tell, I'm on revision 43
[21:32] <jwheare> ijohnson: amazing, thanks so much for checking
[22:29] <ijohnson> np
[23:38] <mup> PR snapcraft#3336 closed: package repositories: introduce path property for exact paths <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3336>
[23:43] <mup> PR snapcraft#3416 closed: repo: default to target arch for stage package cache <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3416>


[04:08] <RAOF> Bah! Test the new code, not a copy of the old code somewhere else!
[04:14]  * duflu takes notes
[04:19] <racarr_> namespace mb = mir::benchmarks
[04:19] <racarr_> WHYA NOT
[04:30] <duflu> racarr_: Because it's 9:30pm?
[04:34] <racarr_> duflu: Oh im migrating to burning man time.
[04:34] <racarr_> which is at least 3 time zones east of west coast
[05:33] <RAOF> Hm. RPATH!!!!!
[06:17] <RAOF> Alright. So, stripping out the rpath from our binaries fixes the doubly-included protobuf issue.
[06:19] <duflu> RAOF: Propose away
[06:20] <RAOF> I'm currently testing it manually :(
[06:21] <duflu> RAOF: Oh we have an rpath in released binaries? To /usr ?
[06:21] <duflu> Or rather non-released binaries
[06:21] <RAOF> CMake is all about the rpath.
[06:21] <RAOF> It embeds a lot of them.
[06:21] <duflu> I know :P
[06:21] <duflu> make install strips them
[06:21] <duflu> But that doesn't help CI much
[06:22] <RAOF> For example: lib/libmirclient.so: RPATH=/home/chris/Canonical/Mir/mir/private-library-loading/partial-armhf-chroot/lib:/home/chris/Canonical/Mir/mir/private-library-loading/partial-armhf-chroot/lib/arm-linux-gnueabihf:/home/chris/Canonical/Mir/mir/private-library-loading/partial-armhf-chroot/usr/lib:/home/chris/Canonical/Mir/mir/private-library-loading/partial-armhf-chroot/usr/lib/arm-linux-gnueabihf
[06:22] <RAOF> And rpath conveniently preempts basically all other ld behaviour.
[06:23] <duflu> RAOF: Except LD_LIBRARY_PATH I think
[06:23] <RAOF> Nope, preempts that too.
[06:23] <RAOF> At least empirically. I've got LD_LIBRARY_PATH exported, and the tests fail until I strip the rpath.
[06:26] <RAOF> Let's try to unrpath the CMake!
[06:27] <duflu> RAOF: CMake uses it for basic stuff like "make test". It might be hard to avoid completely
[06:27] <RAOF> Nope, that'll be easy to handle.
[06:27] <duflu> Kay
[06:27] <RAOF> We've already got the infrastructure required to set LD_LIBRARY_PATH
[08:17] <RAOF> Alright. And with that, EOW!
[08:23] <alan_g> Have a good weekend


[05:40] <marcoagpinto> Heya
[05:56]  * enyc meows marcoagpinto
[05:56] <marcoagpinto> hey hey hey
[05:57] <marcoagpinto> enyc!
[05:57] <marcoagpinto> >:)
[06:15] <enyc> Hrrm, I'm curious about OSX-like desktop-interfaces can suggest to others may transition from OSX.  There is Elementary-OS, how are ubuntu cinnamon, budgie, ...  puzzle =)
[06:49] <lordievader> Good morning
[07:36] <ducasse> good morning
[07:37] <ducasse> enyc: i thought cinnamon was ok, not tried the others. the thing about osx is that everything is tightly integrated and uniform, not true for linux desktops
[07:50] <enyc> ducasse: hrrm not entirely convinced myself tho tbh =)
[07:50] <enyc> ducasse: 'tightly integrated' 'uniform'  a bit abstract to me
[07:50] <enyc> you add all sorts of 3rd-party-software to OSX too, etc
[07:50] <enyc> FOSS too
[07:51] <enyc> you can say  ubuntu package repository is better-integrated already
[07:52] <ducasse> all osx apps look the same, uses the same apis and os services etc is basically what i mean
[07:53] <enyc> oh hrrm ... like integration of menu-bars and all that
[07:57] <ducasse> yeah, for example
[08:07] <enyc> hrrm, file browser and otherwise is adifferent I guess
[08:08] <enyc> e.g. gnome and kde and so-on  calling different "select file" dialogs etc
[08:09] <ducasse> yeah, that's one example
[11:18] <lotuspsychje> !party
[17:12] <Eickmeyer> lotuspsychje: An error with the Ubuntu website is completelly outside of the scope of the #ubuntu-ops room, that is strictly IRC-related.
[17:13] <lotuspsychje> Eickmeyer: wasnt there like a team for web on irc too?
[17:14] <Eickmeyer> lotuspsychje: Perhaps internally at Canonical, #canonical-systadmin might be able to point you in the right direction. But, it's not their responsibility either as they deal with infrastructure.
[17:15] <lotuspsychje> ok tnx
[18:33] <tomreyn> lotuspsychje: most ubuntu.com / canonical.com web pages have a "report a bug on this site" link on the bottom. and, most surprisingly (i'm not joking, this is like a first time experience for me) those actually work to report it at the right (or at least close enough to right place).
[18:42] <lotuspsychje> oh tnx tomreyn
[20:13] <ravage> tomreyn: i stepped out of that windows rescue mission an hour ago :D
[20:14] <tomreyn> ravage: silly me ;)


[00:01] <lamont> slangasek: they do.
[00:01] <slangasek> yeah
[00:01] <lamont> seems the mirrors get busy around release time
[00:01] <lamont> so we quit using them. :-(
[00:01] <slangasek> so I need some help unwinding this mess quickly
[00:02] <slangasek> but first it seems I need to do another upload of initscripts to fix this bug, which I didn't even notice because it's in a binary package I wasn't looking at :/
[00:02] <lamont> sigh
[00:02] <lamont> so you want the world on manual, for starters?
[00:02] <slangasek> lamont: prolly
[00:02] <lamont> set-builder --all --manual
[00:02]  * lamont hugs the api
[00:03] <lamont> afk for about 5.  OTOH, you're fortunate I was idling
[00:06] <lamont> back
[00:07]  * slangasek frowns.  Not sure how this worked *before*; no /usr/share/sysvinit/inittab in the old package either
[00:08] <lamont> interesting
[00:08] <lamont> also, have we fixed the libc6-breaks-debootstrap-with-no-/var/run bug yet?
[00:08] <slangasek> that's exactly what I was in the middle of fixing
[00:09] <slangasek> aha, got it - something changed that caused debian/postinst to be picked up into the sysvinit-utils package where it hadn't been before
[00:09] <slangasek> it'll be the fact that upstream switched to debconf, sysvinit used to be the first package in debian/control, and we nuke that \o/
[00:12] <slangasek> lamont: sysvinit 2.88dsf-13.10ubuntu3 is the package we need to get build to unbreak the chroots; and sysvinit-utils needs to be put on hold in each of them to get it built
[00:13] <lamont> slangasek: all 4 architectures, eh?
[00:14] <lamont> do we want to have this discussion in #u-d, or drag infinity here?
[00:14] <slangasek> either way :)
[00:14] <slangasek> yes, all 4 archs
[00:19] <lamont> slangasek: I'm understanding you to say you want the chroots with the only change being that sysvinit-utils is on hold, yes?
[00:19] <slangasek> lamont: yes
[00:20] <slangasek> I trust that the apt config will dtrt with other packages not upgradable due to unsatisfiable versioned dependencies
[00:20] <slangasek> (the build-dependencies will all be installable)
[00:22]  * lamont taps his foot at annonaceae
[00:27] <lamont> slangasek: I expect that tomorrow I'll freshen the oneiric chroots, once you've fixed debootstrapping
[00:28] <lamont> ditto for natty, without the prereq
[00:28] <slangasek> sounds good :)
[00:35] <lamont> did you already score sysvinit through the roof?  (as in are you ready for a build?
[00:35] <lamont> tarballs are uploading now
[00:37]  * lamont goes on a scorathon
[00:37] <lamont> kicking builds off
[00:38] <infinity> lamont: Okay.
[00:39] <lamont> 4 builds running, world on manual again (roseapple allspice adare araceae)
[00:39] <infinity> lamont: If you're doing the hacked-up chroots, I can return the status quo when you're off.
[00:39] <lamont> switching the world is one command
[00:39] <lamont> set-builder --all --auto :)
[00:39] <infinity> Erm.
[00:39] <infinity> I meant the chroots, not the buildds.
[00:39] <infinity> But sure.
[00:39] <lamont> I want to wait and make sure the builds finish before I restore the chroot tarball
[00:40] <lamont> Uploading build on roseapple
[00:40] <lamont> \o/
[00:40] <wgrant> (#launchpad-ops would appreciate notification about stuff like this, FWIW)
[00:40] <lamont> wgrant: sorry
[00:41] <infinity> wgrant: Bah. ;)
[00:41] <lamont> there
[00:41] <wgrant> Do we have an ETA?
[00:41] <wgrant> We have non-Platform users :)
[00:41] <infinity> Not until we crank a manual publisher run.
[00:41] <lamont> wgrant: once the freshly built packages are published
[00:41] <wgrant> We really need a better way to do this.
[00:42] <lamont> chroots are now correct (old)
[00:42] <lamont> wgrant: a way to tell lp-buildd to not dist-upgrade the chroot would be (1) a start, and (2) violate a few holies
[00:42] <infinity> slangasek: You want to turn the publisher handle, or shall I?
[00:43] <infinity> lamont: You could mitigate the ickiness of that by pushing chroots that are fully up-to-date except for the package you want on hold, but I agree, it's just a different form of ugly.
[00:43] <lamont> wgrant: all of the virtual builders are back to auto
[00:43] <lamont> infinity: it helps if the release is debootstrappable
[00:43] <wgrant> lamont: Thanks!
[00:43] <lamont> since I started rolling chroot tarballs from whole cloth for repeatability
[00:44] <infinity> lamont: Only because you insist on building your chroots from scratch every time. ;)
[00:44] <lamont> infinity: there was lots of cruft in them when I shot them in the head
[00:44] <infinity> lamont: (I agree it's a decent sanity check, but not quired every day either)
[00:44] <infinity> required*
[00:44] <lamont> wgrant: of course, anyone building oneiric is going to find that their builds fail until the publisher run happens
[00:44] <wgrant> Yes, but it's oneiric.
[00:44] <infinity> lamont: Yeah, I used to regularly deborphan and hunt stale conffiles, etc.  I assume that ended about a day after I left.
[00:45] <lamont> infinity: ./make-chroot.sh -d oneiric --lp  <-- far more trivial than fetching and unpacking the tarball
[00:45] <infinity> (Except when it doesn't work) ;)
[00:45] <lamont> that's a distro problem. :-p
[00:45] <infinity> Also, I think vorlon fell into a black hole.
[00:45] <infinity> I'm going to crank the publisher.
[00:46] <lamont> the current hack of the moment (used to bootstrap libjboss-buildmagic-java) was to /STAGE2=/""/\/var\/run\/agentx/
[00:46] <lamont> crank away
[00:47]  * slangasek climbs back out of the black hole
[00:47] <slangasek> infinity: armel is still building?
[00:47] <slangasek> doesn't that make it premature to crank?
[00:48] <infinity> Lamont led me to believe it was done. :P
[00:48] <infinity> Good thing the publisher's sad.
[00:48] <lamont> dude.
[00:48] <infinity> Did someone kill it mid-run?
[00:48] <lamont> you said you were gonna crank it, I assumed you had looked
[00:48] <infinity> *giggle*
[00:48] <infinity> Either way.  No harm done.
[00:48] <infinity> But yeah, did someone kill the previous publisher run by hand?
[00:48] <infinity> Cause stale locks concern me.
[00:49] <lamont> not me.
[00:49] <infinity> -r--r--r-- 1 lp_publish lp_publish 1 Jul 13 21:09 /srv/launchpad.net/ubuntu-archive/cron.daily.lock
[00:49] <lamont> and arm is in installdocs
[00:49] <lamont> and now it's stripping
[00:49] <infinity> Yeah, I'm watching now. :P
[00:49] <slangasek> infinity: yes, I did
[00:50] <slangasek> to prevent publishing the precise version of sysvinit that broke the chroots (though for a different reason)
[00:50] <infinity> lamont: Hahahaha.  Nine 5s.  Nice.
[00:50] <lamont> it's a historical value
[00:50] <infinity> lamont: Except that it's only eight. :(
[00:50] <lamont> only 8 5s
[00:50] <slangasek> infinity: lock removed
[00:50] <lamont> it's more "pound on the 5 key"
[00:51] <lamont> and yet, the troll refuses to die
[00:51] <infinity> And uploading...
[00:52] <infinity> And publishing.
[00:55] <slangasek> yay
[00:55] <infinity> lamont: So, where does your shiny chroot tool live?
[00:56] <lamont> https://code.launchpad.net/~lamont/launchpad-buildd/chroot-scripts
[00:57] <lamont> see also https://code.launchpad.net/launchpad-buildd
[00:57] <lamont> the wanna-build tree being the dump of history from the forkpoint for wanna-build, for wgrant's happiness
[00:58] <lamont> how much longer on the publisher?
[00:58] <infinity> "Until it's done".
[00:58] <lamont> heh
[00:58] <infinity> vorlon's hasty killing of the earlier run means it had some backlog to chew through. :P
[00:58] <lamont> heh
[00:58] <slangasek> it was not hasty
[00:58] <slangasek> it was premeditated
[00:59] <lamont> murder-one
[00:59] <infinity> And, apparently, it takes 20 seconds to process every effin' kde-l10n-uzbekistnification_all.deb
[00:59] <slangasek> the upload that /led/ to the killing was what was hasty
[00:59] <infinity> Dearest Soyuz.  WTF, over.  No love, Me.
[01:00] <slangasek> ?
[01:00] <infinity> slangasek: I just don't recall it being this slow. :P
[01:00] <lamont> slangasek: I think he's remembering some of the rough edges
[01:00] <wgrant> infinity: We are running at DB capacity.
[01:00] <wgrant> infinity: Because our master is getting a disk upgrade.
[01:00] <infinity> This is sort of like dating a girlfriend you dumped a decade ago.
[01:00] <wgrant> And apparently we can't extend arrays live.
[01:01] <lamont> infinity: I wasn't going to go there
[01:01] <lamont> infinity: and the girlfriend hasn't changed, eh?
[01:01] <wgrant> Also, Soyuz is terrible, but the DB isn't helping.
[01:02] <infinity> lamont: Not so much, no.  Neither the real one, nor the current metaphor.  But I'm smart enough to stay away from the former.
[01:02] <lamont> infinity: smart man
[01:02] <lamont> I was going with the metaphor only
[01:02] <infinity> lamont: Sadly, that intelligence didn't extend to staying away from Soyuz. ;)
[01:03] <lamont> infinity: after all the devs left, someone has to tend to it.
[01:03] <lamont> s/left/got dragged off to other things/
[01:03] <infinity> There we go.  Moving on to on-disk mangling finally.
[01:03] <lamont> well.
[01:04] <lamont> it's more soyuz got stuffed into the greater whole, and lots it's dedicated crew of minions/wranglers
[01:04] <infinity> Indeed.
[01:04] <wgrant> :(
[01:04] <infinity> And no more complimentary cowboy hats with every commit.
[01:04] <infinity> Sad times.
[01:04] <lamont> heh
[01:04] <lamont> say when master is current and I'll light the sky
[01:08] <infinity> It's thinking about it.
[01:08]  * lamont waits for proc 8939 to exit
[01:08] <lamont> I'm guessing that's all it needs
[01:08] <lamont> well, 7035 actually
[01:08] <infinity> When dists.new disappears, it's good.
[01:09] <infinity> Well, or the world has exploded.
[01:09] <infinity> In which case, we have nothing to worry about.
[01:09] <lamont> fsvo "we"
[01:10] <infinity> Loving all these apt-ftparchive warnings about malformed overrides.  Are we abusing something intentionally, or do we actually have a bug, I wonder...
[01:16] <wgrant> (those files are generated by scripts maintained by Platform, FWIW, not us)
[01:17] <infinity> I know.
[01:18] <infinity> Singed release files...
[01:18] <infinity> Almost there.
[01:19] <lamont> and dists.new is gone
[01:19]  * lamont lights things
[01:21] <lamont> wgrant: fwiw, if we had a way to put a particular DAS on hold, and then override that hold on a build-record basis, we wouldn't have to do the things we do
[01:21] <wgrant> Yeah.
[01:21] <wgrant> No Soyuz team to do that, though.
[01:22] <infinity> I have Celso's home number.
[01:22] <infinity> I'll just call him every hour, on the hour, until he agrees to work for me.
[01:22] <lamont> heh
[01:22] <wgrant> A maintenance squad might be able to do it eventually, but not until http://webnumbr.com/launchpad-critical-bugs reaches 0.
[01:22] <wgrant> As you can see, it's going well.
[01:22] <persia> Why does it need a Soyuz team?  can't we just file a bug and get someone to whine at the stakeholders meeting about it?
[01:23] <lamont> persia: I will not push it for stakeholders
[01:23] <infinity> persia: It's not really nearly as critical as a lot of other features we need last year.
[01:23] <lamont> there are bigger fish to fry
[01:23] <persia> Oh, of course.  I'm not saying it's *most* important.
[01:23] <persia> I just wonder if it needs a dedicated "Soyuz" team for anything to happen.
[01:23] <lamont> it doesn't, actually
[01:24] <wgrant> persia: Without a team that cares, it needs to be escalated or it will never happen.
[01:24] <wgrant> That's how things are now :(
[01:24] <persia> wgrant, Are there teams that care for anything at this point?
[01:24] <wgrant> No.
[01:25] <persia> Right.  Then it *does* need whining, but it's in our interest to have folk whine about other things first.
[01:25] <wgrant> Right. The bandwidth available by whining is smaller and different from the bandwidth that was available last year.
[01:26] <persia> Ah.  Now I understand.  Yes, that is bad.
[01:28] <infinity> (Gave back everything in chroot-wait, BTW)
[01:28] <ScottK> Well, it's not like LP is anything more than some web app thing.
[01:28] <slangasek> and publisher back on auto
[01:29] <slangasek> lamont, infinity: thanks much :)
[01:29] <infinity> ScottK: It's pretty much just phpBB with a different skin.
[01:29] <slangasek> I'm going to be afk much of the evening; if anyone finds a critical bug in sysvinit that I *didn't* catch in the nick of time, feel free to ring me :P
[01:30] <ScottK> All you soyuz elitists are just claiming you need a special team and stuff.  Soyuz makes web pages just like the rest of LP.
[01:33] <infinity> slangasek: Oh, should this sysvinit upload actually fix debootstrap, BTW?
[01:33] <slangasek> infinity: yes
[01:33] <persia> It doesn't seem to have done
[01:33] <infinity> slangasek: \o/
[01:34] <slangasek> persia: oh?
[01:34]  * persia started debootstrap *after* things were lit
[01:34] <persia> Same error I got before "W: Failure trying to run: chroot /var/lib/schroot/chroots/oneiric-armel dpkg --force-depends --install /var/cache/apt/archives/libc6_2.13-9ubuntu2_armel.deb"
[01:34] <infinity> persia: Not from ftpmaster.internal, you didn't.
[01:34] <infinity> persia: Mirrors are being pulsed now. :P
[01:34] <slangasek> were you debootstrapping after the packages were published to the world, though :)
[01:34] <persia> Aha!
[01:34]  * slangasek nods
[01:34]  * persia waits for mirror pulse
[01:35] <infinity> Which reminds me, we need to move the mirror pulse in cron.daily to happen right after dsync-flist...
[01:35] <infinity> Delaying it until after cron.germinate and such seems silly.
[01:35] <wgrant> Speaking of dsync, can we remove it?
[01:35] <infinity> wgrant: Why?
[01:35] <infinity> wgrant: I was planning to pick up maintenance and get it building on modern OSes, would that make you happy?
[01:36] <wgrant> infinity: It's slow and shouldn't save anything significant, should it?
[01:37] <infinity> It only sometimes saves some space on ftpmaster, I'll admit.  If it's being run on cesium, it probably saves a ton.
[01:37] <infinity> It's not that slow, though.
[01:37] <wgrant> By cesium you mean germanium?
[01:37] <wgrant> cesium should have no persistent data.
[01:37] <infinity> Err, yes.
[01:37] <infinity> Sorry.  It's been a while. :P
[01:38] <wgrant> We could possibly run it over PPA pools, but we don't.
[01:38] <wgrant> germanium is dead enough as it is.
[01:38] <infinity> Either way, it took all of 56s on the primary archive.
[01:38] <infinity> It's not exactly slow.
[01:38] <infinity> In other words, it took less time than processing two arch:all BPRs. :P
[01:39] <infinity> *cough*
[01:39]  * lamont afk, laters
[01:40]  * persia tries again with 2.88dsf-13.10ubuntu3 this time
[01:58] <infinity> slangasek: libc6 is still a sad panda, trying to touch /var/run/init.upgraded
[01:59] <infinity> slangasek: So, still no debootstrap.
[02:01] <persia> Worked for me
[02:01] <infinity> slangasek: Oh, wait, I might be pulling a persia here, my local mirror's still pulsing. :P
[02:01]  * infinity taps his foot.
[02:01] <persia> (just got "I: Base system installed successfully." about the same time you posted)
[02:02] <infinity> Normally, being 30 minutes behind ftpmaster doesn't bug me in the least.  Sometimes, it's really annoying...
[02:02] <persia> 30 minutes?  I really need to configure push-mirroring at some point.
[02:03] <infinity> I need to weasel my way back into the push-primary rotation again.
[04:54] <slangasek> heh
[04:54] <slangasek> infinity: bootstrapping looking happier now? :)
[04:59] <infinity> slangasek: Indeed.
[10:55]  * cjwatson continues to attempt to get lucid images to build :-/
[17:12] <cjwatson> jibel: All the cronned lucid builds (Ubuntu desktop, Ubuntu alternate, Ubuntu server, Ubuntu DVD, Kubuntu desktop, Kubuntu alternate) should be up to date now
[17:12] <cjwatson> jibel: I can't vouch for them working
[17:13] <cjwatson> well, ia64 and sparc didn't build; I don't know whether we care
[17:13] <cjwatson> does anyone know if the 2.6.32-33 ABI is intended for 10.04.3?
[18:22] <jibel> cjwatson, desktop i386 is ok. I'll sync the other images this evening and try them tomorrow.
[21:59] <skaet> cjwatson, kernel we're hoping to use for 10.04.3 is 2.6.32-33.70.    Based on tracking bug 807175,  looks like its gone through cert and testing, so should be good to move to updates.  However not sure I understand where the ABI ref is coming in from, and the concern.  Can you elaborate?
[21:59] <ubot4> Launchpad bug 807175 in linux (Ubuntu Lucid) (and 10 other projects) "linux: 2.6.32-33.70 -proposed tracker (affects: 4) (dups: 4) (heat: 44)" [Medium,In progress] https://launchpad.net/bugs/807175
[22:03] <infinity> skaet: If lucid's meant to update from 32.62 to 33.70, that'll be an ABI bump (and hence new package names) from -32- to -33-, which will require a d-i upload, and some fiddling, that's all.
[22:04] <infinity> skaet: So, if that's the plan, we should get it into -security,-updates and get with the mangling before testing images that aren't remotely valid. ;)
[22:04] <infinity> skaet: s/meant to update from 32.62 to 33.70/meant to update from 32.62 to 33.70 for the point release/
[22:06] <skaet> infinity,  need to check with security team, but its ready to go to updates based on cert/QA results in the bug.
[22:12] <infinity> I think Colin's question wasn't so much "is it ready?" as "do you want it on the point release images?" :)
[22:14] <infinity> And I think the above constitutes a "yes", so yeah, just need to shove it through and then rebuild d-i, and then images.
[22:15] <skaet> infinity,  as long as security doesn't throw up a red flag in the final stages of the process.    Yes please.


[07:25] <dholbach> good morning
[07:38] <nhaines> Morning!
[07:41] <nhaines> I got to practice my German with a little friend Saturday!  Gave him his overdue birthday present.  His eyes lit up when I said it wasn an Überraschung, but I think we was just thinking of Kinder Surprise Eggs.
[07:41] <nhaines> Luckily, a nice computer joystick was met with approval even in the face of such fierce competition.
[10:11] <dpm> yay, new UGJ events, first one in Africa! http://loco.ubuntu.com/events/global/2967/
[14:42] <mhall119> yay!
[14:42] <mhall119> up to 13
[15:27] <nhaines> That's a much beter number than before.  :)
[18:13] <Muhammad> Hello
[18:14] <Guest32404> Hello
[18:16] <Guest32404> anyone there
[18:21] <pleia2> hello there


[15:33] <ogra_> hrm
[15:33] <ogra_> alan_g, i just filed https://github.com/MirServer/mir/issues/35 ... only to notice later that mir-kiosk is its own GH project ...
[15:34] <ogra_> should i close and re-file or can you move it over somehow ?
[15:34] <alan_g> ogra_: not anymore we rolled MirAL into Mir 0.28
[15:34] <ogra_> well, there is no snapcraft.yaml anywhere else
[15:35] <ogra_> (and the bug refers to "please add additional apps to snapcraft.yaml)
[15:35] <alan_g> ogra_: sorry, misread. Yes, better under mir-kiosk
[15:36] <alan_g> AlbertA: greyback: ^^ who's the snap guy?
[15:37] <greyback> alan_g: eehhh I guess I can be
[15:39] <alan_g> greyback: if you hate the idea I guess I could have a go.
[15:41] <greyback> alan_g: no I'm fine with it
[15:45] <ogra_> greyback, alan_g moved it to https://github.com/MirServer/mir-kiosk/issues/3 under the correct project now
[15:46] <greyback> ogra_: thanks!
[15:53] <AlbertA> ogra_: yeah we'll transition to that github project... still using the launchpad one one last time
[15:54] <ogra_> yeah, i'm fine with that ... i just didnt realize the snap bits live in an extra branch
[15:57] <AlbertA> perhaps we should just merge it into the mir project actually... we'll see...
[16:13] <alan_g> AlbertA: I guess it depends whether we want (long term) to pull debs from the PPA or always build it.
[16:14] <AlbertA> alan_g: well I'm thinking more to build it as part of the "release process", either with build.snapcraft.io or CI
[16:59] <alan_g> AlbertA: yeah, I just have the impression we rework the snaps more often than we release. (But that /shouldn't/ be the case.)
[18:10] <AlbertA> alan_g: that's true... usually for reasons other than mir...
[18:10] <AlbertA> so probably makes sense to keep it in its own project for now