[02:05] <Paladine> hello :)
[02:05] <Paladine> can anyone tell me if there is anything in edubuntu that requires opengl 2?
[02:13] <cafuego_> don't think so
[02:35] <crimsun> the kernel.
[02:36] <cafuego_> that just requires libxml, not opengl2 :-P
[02:37] <crimsun> :p
[02:39] <Paladine> was just curious cos I am building an edubuntu box for my son and missus
[02:39] <Paladine> but it will only take graphics upto opengl 1.4
[02:39] <Paladine> (old athlon xp system)
[02:40] <Paladine> so I just wanted to make sure I didn't have to upgrade the whole system including mainboard
[02:44] <Paladine> so this lot should run edubuntu with no problems then? athlon xp 1800, 512MB SDRAM, 16x DVDRW, 256MB FX5500 PCI Graphics, 80GB WD IDE HDD, 360W ASUS Silent PSU and Silverstone LC10 HTPC case :)
[02:48] <Laser_away> yep, that's almost exactly what I have at home
[02:48] <Paladine> k :) cheap box then with the exception of the case :)
[02:49] <Paladine> I have everything already apart from the case, hdd, graphics and psu :)
[02:50] <Paladine> my son is not even 12 months old yet, but I am sure he will enjoy all the edubuntu stuff
[02:50] <Paladine> and my missus is computer illiterate, so maybe she will learn something too
[02:51] <Paladine> and hopefully now, she will stop messing with my kit :)
[03:01] <cafuego_> Paladine: at worst, some new games might require it (but unlikely)
[03:01] <cafuego_> Paladine: the worst you can throw at it from a Linux point of view would be Google Earth or SecondLife, and they both work fine wotj ogl 1.4
[03:01] <Paladine> I am looking forward to giving this a go
[03:02] <Paladine> my missus is dyslexic too so I am hoping I can find or develop some software to help her with her dyslexia
[03:02] <cafuego_> Paladine: I run it on an athlonxp 2000+ laptop with 512Mb just fine
[03:03] <Paladine> plus it won't have a monitor, it will be going straight out to the tv, which is a more familiar environment for her
[03:04] <cafuego_> so it'll run at 800x600 tops?
[03:04] <cafuego_> or so you have one of those fancy widescreen HD things?
[03:04] <Paladine> well 16:9 so the whatever the 16:9 equivalent is
[03:04] <Paladine> but not HD, just regular crt
[03:05] <cafuego_> well
[03:05] <cafuego_> 320x180 on my ipod ;-)
[03:05] <Paladine> I believe I need to set the DPI to 100 as well for optimised tv output
[03:06] <Paladine> first time I have setup a pc specifically for use with a tv
[03:06] <cafuego_> the pixels on a tv are FAR larger then on a computer screen
[03:06] <cafuego_> PAL or NTSC?
[03:06] <Paladine> PAL
[03:06] <cafuego_> 720x576
[03:06] <Paladine> yeah thats what I figured
[03:07] <Paladine> well no isn't 720x576 4:3 aspect ratio?
[03:08] <Paladine> I have mythtv running in 720x576 on my desktop here and it is 4:3
[03:10] <Paladine> 768x576 I -think-
[03:10] <Paladine> but checking now
[03:13] <Paladine> ooo there is vga-scart converters now
[03:13] <Paladine> which will give better control and otput than svideo
[03:14] <cafuego_> nice
[03:15] <cafuego_> hmm
[11:09] <achandra> howdy guys. Im trying to install edubuntu on G4 (ppc) and get the white screen of death on the install. Can someone help out?
[11:12] <ogra> see the first screen, there is a bootoption listed to avoid that
[11:13] <ogra> (before you boot from the CD)
[11:23] <achandra> ogra: yes I tried with install video=ofonly and it white screens, with the expert mode, the monitor goes into "sleep" mode or appears to have no connection to the system at all.
[11:23] <achandra> this is with the 6.10 version
[11:48] <RichEd> achandra ... do you get two white ASCII squares on a blank screen at around 50-60% install progress ?
[11:49] <RichEd> if so, it may be the video drive not loading from text mode on install to to video mode ... try leaving the installation to continue ... I had keyboard lock-up and screen as described, but 20-30 mins later, my CD ejected, and on reboot, all was 100% okay.
[11:54] <cbx33> hey ogra RichEd
[12:01] <achandra> RichEd: Hi, nope... it white screens almost immediately after the install command is given
[12:01] <achandra> RichEd: even worse when in expert mode it point blank goes into "monitor will go into sleep mode in 5 seconds"
[12:02] <achandra> weird..
[12:18] <achandra> Hi, This is very strange...but the stock...dapper 6.06 when going into live mode...works fine.. so im perplexed here..
[12:23] <ogra> achandra, usplash changed a lot between dapper/edgy ...
[12:23] <ogra> its likely an usplash issue with the framebuffer driver
[12:24] <ogra> did you look in launchad if someone has filed a bug (and probably has a workaround) ?
[12:25] <achandra> actually I tried to google like heck..but didnt see anything...my query was based on two things
[12:26] <achandra> ubuntu edgy on G4 and edubuntu install G4 how to
[12:26] <achandra> and powerpc as well..
[12:26] <achandra> very little there
[12:26] <ogra> i tested the CD before release on an ibook G4 with ati card, worked fine ...
[12:27] <ogra> some users reported distorted bootscreens, but thats about as much as know ...
[12:27] <ogra> the white screen should usually be solved with the ofonly parameter
[12:36] <achandra> k..well. I will see "how far i get with the 6.06 release" and move on from there...I appreciate the insight :)
[12:44] <cbx33> any kerberos users here?
[01:31] <juliux> hey jsgotangco
[01:32] <jsgotangco> hey juliux how are you doing?
[01:32] <juliux> jsgotangco,  i am fine, and you?
[01:32] <juliux> jsgotangco, it's christmas time ;)
[01:36] <jsgotangco> hehehe yeah we just had our christmas tree at home setup yesterday and today at work, they already raised a lot of decors for the holidays as well
[01:40] <juliux> jsgotangco, i have no christmas tree at home
[01:41] <juliux> but there is a lot of christmas stuff in the city
[01:42] <juliux> jsgotangco, but we have here +10 that is very warm for december
[01:42] <jsgotangco> hmmm
[01:42] <jsgotangco> where is this??
[01:42] <juliux> dresden/germany
[01:42] <juliux> normaly we have snow in december
[01:43] <jsgotangco> well global warming does wonders to the weather
[01:44] <juliux> jap
[03:08] <RichEd> hi willvdl ... you there ?
[03:51] <bddebian> Heya
[03:52] <Kamping_Kaiser> hi mate
[03:53] <bddebian> Heya Kamping_Kaiser
[03:53] <bddebian> Nah
[04:22] <coz_> apokryphos, i see that you are also on edubuntu channel
[04:23] <apokryphos> yup
[04:23] <coz_> apokryphos, you use edubuntu/
[04:23] <apokryphos> I have
[04:24] <coz_> apokryphos, nice.. did you like it?
[04:24] <apokryphos> it was pretty decent, yup.
[06:02] <stgraber> hi
[07:05] <rockprincess> hello!
[07:08] <LaserJock> hi rockprincess
[07:08] <rockprincess> hi LaserJock!
[07:09] <rockprincess> does anyone know where i can get the green chalkboard edubuntu background?
[07:10] <LaserJock> hmm, it's on Dapper
[07:10] <rockprincess> is it on edgy as well?
[07:11] <LaserJock> I don't think so
[07:11] <rockprincess> :(
[07:11] <rockprincess> i'm on edgy
[07:12] <LaserJock> gimme a sec and I'll have it for you
[07:12] <rockprincess> thank you!
[07:16] <LaserJock> doh, grabbed the wrong one, just one more minuter
[07:16] <rockprincess> heheh ;)
[07:18] <LaserJock> http://www.laserjock.us/ubuntu/edubuntu_chalkboard.png
[07:18] <rockprincess> thank you Laserjock, you're a sweetheart! xxx
[07:19] <LaserJock> no problem
[07:52] <rockprincess> why was the GNOME window manager chosen for edubuntu?
[07:54] <LaserJock> well ...
[07:55] <LaserJock> it's what the developers of Edubuntu chose
[07:55] <LaserJock> I really don't know the historical reasons
[07:56] <rockprincess> I see....
[07:56] <LaserJock> ogra would probably  know
[07:56] <rockprincess> I for myself prefer the KDE Desktop, but I think I will get used to it.....
[07:56] <LaserJock> yeah
[07:57] <LaserJock> but we really have to pick one
[07:57] <LaserJock> as we don't have room to ship both
[07:58] <stgraber> Maybe simply because the classical Ubuntu uses gnome and the goal of Edubuntu wasn't to propose another desktop environment (I don't know where the Kubuntu development was when the Desktop Environment was choosen for Edubuntu)
[07:59] <LaserJock> yeah, I think that's part of it
[07:59] <LaserJock> I don't think Kubuntu was nearly to the level it is now when Edubuntu was started
[08:01] <LaserJock> so not having to maintain a KDE desktop was a definite plus
[08:07] <rockprincess> ahh I see, thanks for the answers ;))))
[08:30] <Dheeraj_k> how to unrar rar file? if it is password protected?
[08:34] <Burgwork> Dheeraj_k: you need to have unrar-nonfree installed
[08:34] <Burgwork> with that, the archive manager will handle all but the password protected ones
[08:35] <Dheeraj_k> i tried to unrar from terminal
[08:35] <Burgwork> you need unrar-nonfree, not just unrar
[08:36] <Dheeraj_k> oh i just downloaded it
[08:36] <Dheeraj_k> let me try
[08:40] <Dheeraj_k> finally i did it thanx :)
[08:51] <Burgwork> no worries
[08:52] <cbx33> ahhh
[08:53] <cbx33> I reember now I thought it was rar we linuxians couldn't uncompress
[08:53] <cbx33> but it's stuff it isn't it
[08:54] <Dheeraj_k> which is the best pdf doc maker for linux?
[08:55] <cbx33> open office makes a pretty good job
[08:55] <Dheeraj_k> same as acrobat
[08:55] <harrypopof> scribus / Ooo
[08:55] <Dheeraj_k> or pdf editor
[08:55] <harrypopof> evince
[08:56] <Dheeraj_k> but if pdf file is  big than? may be around 10mb
[08:56] <Dheeraj_k> i am sure it will hangup openoffice
[08:57] <Dheeraj_k> and does open office support editing of pdf file?
[08:58] <Dheeraj_k> any good replacement of adobe acrobat?
[09:02] <harrypopof> use Xpdf or evince
[09:03] <Burgwork> there is nothing at allows editing of pdf files
[09:03] <Burgwork> however, you can turn it into a ps and then edit that
[09:04] <Dheeraj_k> there should be some alternative
[09:04] <Dheeraj_k> because i am able to edit pdf file in windows using acrobat
[09:04] <Dheeraj_k> and xpdf is just a pdf viewer
[09:04] <Burgwork> are you talking editing or forms?
[09:05] <Dheeraj_k> editing existing pdf file
[09:05] <Dheeraj_k> like removing or adding text in a existing pdf file
[09:06] <Burgwork> not possible currently
[09:07] <Dheeraj_k> !pdf
[09:07] <ubotu> pdf is the Portable Document Format created by Adobe; viewable in GNU/Linux with xpdf/kpdf/gpdf, evince and also adobe reader (free download, but closed source)
[09:10] <Dheeraj_k> i guess i found something interesting http://applications.linux.com/article.pl?sid=05/01/06/0612209
[09:12] <Dheeraj_k> !firefox
[09:12] <ubotu> firefox is the default web-browser on Ubuntu. To install the latest version, see https://help.ubuntu.com/community/FirefoxNewVersion Installing plugins: https://wiki.ubuntu.com/FirefoxPlugins
[09:13] <harrypopof> mozilla-acroread, great thank you
[09:15] <rockprincess> i think kword can edit pdf files.....
[09:15] <rockprincess> the latest koffice was released just a few days ago....
[10:34] <nixternal> hola compadres


[01:17] <xuser> hey peeps, first time chatter here and big fan of ubuntu. QQ, seems ive noobishly forgotten my xubuntu system password, any ideas or tips on how to reset it before resetting all of it?
[01:17] <arraybolt3> xuser: Easy.
[01:17] <arraybolt3> You didn't use encryption, right?
[01:17] <xuser> nope didnt not
[01:17] <arraybolt3> If so, you can reset the password either with a live USB or from Recovery Mode.
[01:18] <arraybolt3> Recovery Mode works without a USB, if you'd like to do it like that.
[01:18] <arraybolt3> xuser: Do you know if this is a BIOS or UEFI system?
[01:18] <xuser> ahh sweet ty, was trying to get into recovery mode but it didnt seem to want to let me
[01:18] <xuser> its a hp stream 11 which has UEFI disabled for xubuntu to work
[01:19] <arraybolt3> OK. Usually you can get to a GRUB menu by powering on the system and then pressing and holding the left Shift key during early bootup.
[01:19] <arraybolt3> (On BIOS systems, which I believe this is.)
[01:19] <xuser> amazing thank you, love yas work<3
[01:19] <arraybolt3> Nice, now just "Advanced Options for Ubuntu".
[01:19] <arraybolt3> And then the topmost recovery mode entry.
[01:20] <arraybolt3> Once you get booted into that you'll see a menu with some options, select "root" and press Enter.
[01:21] <arraybolt3> Once you have a root shell, you will need to mount the filesystem as read/write, which you can do with "mount -o remount,rw /".
[01:21] <arraybolt3> And then just "passwd <username>", replacing <username> with your username.
[01:26] <arraybolt3> xuser: btw this is a very handy procedure for some stuff, but do be aware that it's just as easy for someone else to do this to your computer as it is for you to do it. Full-disk encryption will prevent someone from being able to just come along and get a root shell on your system. But it also requires that you remember your password.
[04:41] <leonard> hi


[03:24] <krosswindz> I was wondering if someone could help me with a question on packaging for my ppa
[03:25] <krosswindz> i want to build a package for which i want to build-depend on an older version of the package from my ppa rather than a newer version from ubuntu main
[03:25] <krosswindz> I tried to set the version in build depend package foo(= version-bar) then I get an error
[03:26] <krosswindz> "missing build dependencies"
[03:26] <krosswindz> any way I could fix this so that I can build the package with an older version of one of its dependencies
[06:55] <dholbach> good morning
[07:00] <geser> good morning dholbach
[07:00] <dholbach> hi geser
[09:50] <mitya57> dholbach: hi, do you have five minutes for me?
[09:51] <dholbach> mitya57, I'm currently in the middle of fixing a problem I created :)
[09:51] <dholbach> maybe you just explain how I could help and maybe we can figure it out together?
[09:51] <mitya57> ah, I see it on #ubuntu-devel
[09:52] <mitya57> I wanted you to say something good (or bad) about me at https://wiki.ubuntu.com/DmitryShachnev/PPUApplication ...
[09:52] <dholbach> ah ok
[09:52] <mitya57> thanks
[09:52] <dholbach> do you think you could drop me an email about it, so I don't forget?
[09:52] <dholbach> I'm happy to do it!
[09:53] <mitya57> ok, will send now :)
[09:53] <dholbach> awesome, thanks a lot
[13:02] <krosswindz> hi
[13:03] <krosswindz> i was wondering if anybody could help me with a question regarding packaging and ppa
[13:12] <geser> just ask
[13:13] <krosswindz> geser: I am trying to build xbmc 11.0 in my ppa to support nfs using libnfs
[13:14] <krosswindz> The problem being that the version of libnfs in ubuntu repos is new and isnt compatible with xbmc v11.0
[13:14] <krosswindz> I built an older version of libnfs which is comptabile with xbmc in my ppa
[13:15] <krosswindz> I setup the build-depends in the xbmc debian/control file as libnfs-dev (= 1.0.0~git20110902.0804e67)
[13:15] <geser> apt automatically selects the newest version and installs it
[13:15] <krosswindz> is there a way to downgrade or tell apt not to install the newer version
[13:16] <krosswindz> or downgrade to an older version
[13:16] <TheLordOfTime> geser, i have a question, if i enable proposed in a VM to test, apparently it won't "upgrade" a given package's dependencies according to what's needed, unless i specify the version for each.  Any suggestion to get around that and force autoinstall of the deps?
[13:18] <geser> krosswindz: no, you would need to rename that older version to something like libnfs-1.0-dev (and the same with library package itself) so it doesn't collide with the newer version of libnfs
[13:18] <krosswindz> geser: ok thanks for the help
[13:19] <krosswindz> I was hoping one wouldnt have to do it, guess I will have to name it differently
[13:19] <geser> TheLordOfTime: did you try "apt-get install foobar -t ...-proposed"?
[13:20] <marga> Heys.  Long time ago, when Ubuntu was still new and shiny, I remember someone saying that all Debian Developers had automatic (or similar) upload rights to universe.  Is that still the case? Do I have to go through any process to get universe upload rights? (I'm a DD)
[13:20] <TheLordOfTime> geser, no, i'll try that
[13:22] <geser> marga: I don't remember that it was ever the case. But as a DD we trust you to have the needed packaging skills :) and you just need to show knowledge on the Ubuntu-specific processes (mostly about freezes)
[13:22] <marga> geser, ok.  So, is there a process that I need to go through?
[13:25] <geser> marga: I hope the best starting point describing it is https://wiki.ubuntu.com/UbuntuDevelopers
[13:26] <marga> ok... that looks like a lot of steps :).
[13:26] <geser> in short: show interest in Ubuntu, participate through sponsors, apply for MOTU (or PPU for your maintained packages) at the DMB
[13:29] <marga> Yes, well, I just wanted to update a package that already has a patch in the bug queue... participating through sponsoring kind of loses the purpose.
[13:30] <TheLordOfTime> geser, is there a method to get upload permissions to -proposed for a specific package, or is it the same as Ubuntu Dev procedures?
[13:31] <TheLordOfTime> out of curiosity
[13:31] <TheLordOfTime> btw, that apt-get command works :)
[13:31] <geser> TheLordOfTime: if you have upload permissions for that package, you can also upload to -proposed this package
[13:31] <TheLordOfTime> assuming i don't have upload perms for that package, what's the process?
[13:31] <TheLordOfTime> (yet)
[13:33] <geser> TheLordOfTime: for uploading? go through a sponsor. for getting upload rights? show that you have sufficient skills to manage that package (easily by getting uploads sponsored) and apply for PPU rights
[13:35] <geser> marga: I don't know if the DMB has any shortened process for DDs but I guess they would like to see that you really want to care about your packages in Ubuntu too (and the sponsoring is usually pretty quick and easy)
[14:39] <mitya57> A (stupid?) packaging question:
[14:39] <mitya57> I have two packages (retext and retext-wpgen), and I want to merge them, so that
[14:39] <mitya57> retext-wpgen is removed on upgrade
[14:40] <dholbach> I'll start a hangout-on-air about Ubuntu development in 20 minutes - anyone interested in co-hosting?
[14:40] <mitya57> Is a usual Breaks/Replaces fine for that?
[14:41] <coolbhavi> dholbach, m there!
[14:41] <mitya57> (or there should be something like Provides/Breaks/Replaces)?
[14:41] <dholbach> coolbhavi, cool - I'll invite you when I start it
[14:41] <coolbhavi> sure dholbach
[14:43] <geser> mitya57: Breaks/Replaces should be enough (check the Debian policy manual if you want to be sure)
[14:45] <mitya57> geser: policy section 7.6.2 suggests using Provides/Breaks/Replaces, but for a slightly different case
[14:48] <dholbach> coolbhavi, you might want to join #ubuntuonair for the questions/discussions
[14:48] <coolbhavi> done dholbach
[14:48] <dholbach> perfect
[17:37] <obounaim> I want to become a maintainer of a python package, does anybody interested in helping me?
[18:30] <paultag> anyonw know where jodh hangs out?
[18:31] <stgraber> paultag: #ubuntu-devel mostly
[18:31] <paultag> thanks, stgraber
[18:32] <TheLordOfTime> i assume the process for PPU rights is the same regardless of main or universe?
[18:32] <TheLordOfTime> for applying for PPU*
[19:16] <Laney> yes
[20:52] <jtaylor> anyone familiar with typo3?
[20:53] <jtaylor> I'm planing on syncing 4.15.19 to quantal several sec issues but also 3 bugfix releases
[20:55] <jtaylor> asssuming the upstream changelogs are correct it should not need release team ack, but its still quite large and quite late
[20:55] <jtaylor> opinion?
[20:55] <jtaylor> http://wiki.typo3.org/TYPO3_4.5.1[789]
[21:35] <jtaylor> I'll sync it, the fixes seem worth it


[16:18] <thafreak> Playing with freenas, I'm starting to finally understand freebsd better
[16:23] <paultag> :)
[17:27] <thafreak> so, freenas only has transmission available as a downloading plugin
[17:28] <thafreak> which only downloads torrents
[17:28] <thafreak> I got aria2 installed in the jail, and ran the daemon of it
[17:28] <thafreak> now I can send it commands via xmlrpc to have it download just about anything :)
[17:29] <thafreak> just need to figure out how to make a bsd rc.d script for it...


[00:02] -queuebot:#ubuntu-release- New binary: libpappsomspp [arm64] (mantic-proposed/universe) [0.9.12-1] (no packageset)
[00:12] -queuebot:#ubuntu-release- New binary: golang-1.21 [armhf] (mantic-proposed/universe) [1.21~rc1-1] (no packageset)
[00:32] -queuebot:#ubuntu-release- New binary: golang-1.21 [riscv64] (mantic-proposed/universe) [1.21~rc1-1] (no packageset)
[00:48] -queuebot:#ubuntu-release- New: accepted c-munipack [amd64] (mantic-proposed) [2.1.35-1]
[00:48] -queuebot:#ubuntu-release- New: accepted c-munipack [armhf] (mantic-proposed) [2.1.35-1]
[00:48] -queuebot:#ubuntu-release- New: accepted c-munipack [riscv64] (mantic-proposed) [2.1.35-1]
[00:48] -queuebot:#ubuntu-release- New: accepted damo [amd64] (mantic-proposed) [1.8.5-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-1.21 [amd64] (mantic-proposed) [1.21~rc1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-1.21 [armhf] (mantic-proposed) [1.21~rc1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-1.21 [riscv64] (mantic-proposed) [1.21~rc1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-github-bep-helpers [amd64] (mantic-proposed) [0.4.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-github-bep-simplecobra [amd64] (mantic-proposed) [0.3.2-1]
[00:48] -queuebot:#ubuntu-release- New: accepted libpappsomspp [amd64] (mantic-proposed) [0.9.12-1]
[00:48] -queuebot:#ubuntu-release- New: accepted c-munipack [arm64] (mantic-proposed) [2.1.35-1]
[00:48] -queuebot:#ubuntu-release- New: accepted c-munipack [s390x] (mantic-proposed) [2.1.35-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-1.21 [arm64] (mantic-proposed) [1.21~rc1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-1.21 [s390x] (mantic-proposed) [1.21~rc1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted libjodycode [riscv64] (mantic-proposed) [3.0.1-2]
[00:48] -queuebot:#ubuntu-release- New: accepted libpappsomspp [armhf] (mantic-proposed) [0.9.12-1]
[00:48] -queuebot:#ubuntu-release- New: accepted libpappsomspp [s390x] (mantic-proposed) [0.9.12-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-addchain [arm64] (mantic-proposed) [0.2.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-addchain [ppc64el] (mantic-proposed) [0.2.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-addchain [s390x] (mantic-proposed) [0.2.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted c-munipack [ppc64el] (mantic-proposed) [2.1.35-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-1.21 [ppc64el] (mantic-proposed) [1.21~rc1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted libpappsomspp [arm64] (mantic-proposed) [0.9.12-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-addchain [amd64] (mantic-proposed) [0.2.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-addchain [riscv64] (mantic-proposed) [0.2.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted dh-builtusing [amd64] (mantic-proposed) [0.0.1]
[00:48] -queuebot:#ubuntu-release- New: accepted libpappsomspp [ppc64el] (mantic-proposed) [0.9.12-1]
[00:48] -queuebot:#ubuntu-release- New: accepted golang-github-bep-mclib [amd64] (mantic-proposed) [1.20400.20402-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-addchain [armhf] (mantic-proposed) [0.2.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-anstyle-query [amd64] (mantic-proposed) [1.0.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-anstyle-query [armhf] (mantic-proposed) [1.0.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-anstyle-query [riscv64] (mantic-proposed) [1.0.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-critical-section [amd64] (mantic-proposed) [1.1.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-critical-section [armhf] (mantic-proposed) [1.1.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-critical-section [riscv64] (mantic-proposed) [1.1.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-memuse [amd64] (mantic-proposed) [0.2.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-memuse [armhf] (mantic-proposed) [0.2.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-memuse [riscv64] (mantic-proposed) [0.2.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-traitobject [amd64] (mantic-proposed) [0.1.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-anstyle-query [arm64] (mantic-proposed) [1.0.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-anstyle-query [s390x] (mantic-proposed) [1.0.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-critical-section [ppc64el] (mantic-proposed) [1.1.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-memuse [arm64] (mantic-proposed) [0.2.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-memuse [s390x] (mantic-proposed) [0.2.1-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-traitobject [armhf] (mantic-proposed) [0.1.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-traitobject [riscv64] (mantic-proposed) [0.1.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-twox-hash [amd64] (mantic-proposed) [1.6.3-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-twox-hash [armhf] (mantic-proposed) [1.6.3-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-twox-hash [riscv64] (mantic-proposed) [1.6.3-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-anstyle-query [ppc64el] (mantic-proposed) [1.0.0-1]
[00:48] -queuebot:#ubuntu-release- New: accepted rust-critical-section [s390x] (mantic-proposed) [1.1.1-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-traitobject [arm64] (mantic-proposed) [0.1.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-traitobject [s390x] (mantic-proposed) [0.1.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-twox-hash [ppc64el] (mantic-proposed) [1.6.3-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-wyz [amd64] (mantic-proposed) [0.5.1-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-wyz [armhf] (mantic-proposed) [0.5.1-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-wyz [riscv64] (mantic-proposed) [0.5.1-1]
[00:49] -queuebot:#ubuntu-release- New: accepted zint [amd64] (mantic-proposed) [2.12.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted zint [armhf] (mantic-proposed) [2.12.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-critical-section [arm64] (mantic-proposed) [1.1.1-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-traitobject [ppc64el] (mantic-proposed) [0.1.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-twox-hash [s390x] (mantic-proposed) [1.6.3-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-wyz [ppc64el] (mantic-proposed) [0.5.1-1]
[00:49] -queuebot:#ubuntu-release- New: accepted zint [arm64] (mantic-proposed) [2.12.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted zint [riscv64] (mantic-proposed) [2.12.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-memuse [ppc64el] (mantic-proposed) [0.2.1-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-wyz [arm64] (mantic-proposed) [0.5.1-1]
[00:49] -queuebot:#ubuntu-release- New: accepted zint [ppc64el] (mantic-proposed) [2.12.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-twox-hash [arm64] (mantic-proposed) [1.6.3-1]
[00:49] -queuebot:#ubuntu-release- New: accepted zint [s390x] (mantic-proposed) [2.12.0-1]
[00:49] -queuebot:#ubuntu-release- New: accepted rust-wyz [s390x] (mantic-proposed) [0.5.1-1]
[02:20] -queuebot:#ubuntu-release- Unapproved: gallery-dl (jammy-backports/universe) [1.25.5-1~bpo22.04.1 => 1.25.6-1~bpo22.04.1] (no packageset)
[05:17] -queuebot:#ubuntu-release- New binary: ccextractor [amd64] (mantic-proposed/none) [0.94+ds1-2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: ccextractor [armhf] (mantic-proposed/none) [0.94+ds1-2] (no packageset)
[05:18] -queuebot:#ubuntu-release- New binary: ccextractor [s390x] (mantic-proposed/none) [0.94+ds1-2] (no packageset)
[05:19] -queuebot:#ubuntu-release- New binary: ccextractor [ppc64el] (mantic-proposed/none) [0.94+ds1-2] (no packageset)
[05:20] -queuebot:#ubuntu-release- New binary: ccextractor [arm64] (mantic-proposed/none) [0.94+ds1-2] (no packageset)
[05:28] -queuebot:#ubuntu-release- Unapproved: cockpit (kinetic-backports/universe) [292-1~bpo22.10.1 => 294.1-1~bpo22.10.1] (no packageset)
[05:28] -queuebot:#ubuntu-release- Unapproved: cockpit (lunar-backports/universe) [292-1~bpo23.04.1 => 294.1-1~bpo23.04.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit-machines (jammy-backports/universe) [283-1~bpo22.04.1 => 292-1~bpo22.04.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit (jammy-backports/universe) [292-1~bpo22.04.1 => 294.1-1~bpo22.04.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit-podman (kinetic-backports/universe) [62-1~bpo22.10.1 => 71-1~bpo22.10.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit-podman (lunar-backports/universe) [62-1 => 71-1~bpo23.04.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit-podman (jammy-backports/universe) [62-1~bpo22.04.1 => 71-1~bpo22.04.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit-machines (lunar-backports/universe) [283-1 => 292-1~bpo23.04.1] (no packageset)
[05:29] -queuebot:#ubuntu-release- Unapproved: cockpit-machines (kinetic-backports/universe) [283-1~bpo22.10.1 => 292-1~bpo22.10.1] (no packageset)
[05:30] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (jammy-backports) [292-1~bpo22.04.1]
[05:30] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (jammy-backports) [294.1-1~bpo22.04.1]
[05:30] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-podman [source] (kinetic-backports) [71-1~bpo22.10.1]
[05:30] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (lunar-backports) [292-1~bpo23.04.1]
[05:30] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (lunar-backports) [294.1-1~bpo23.04.1]
[05:31] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-podman [source] (jammy-backports) [71-1~bpo22.04.1]
[05:31] -queuebot:#ubuntu-release- Unapproved: accepted cockpit [source] (kinetic-backports) [294.1-1~bpo22.10.1]
[05:31] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-machines [source] (kinetic-backports) [292-1~bpo22.10.1]
[05:31] -queuebot:#ubuntu-release- Unapproved: accepted cockpit-podman [source] (lunar-backports) [71-1~bpo23.04.1]
[05:42] -queuebot:#ubuntu-release- New binary: ccextractor [riscv64] (mantic-proposed/none) [0.94+ds1-2] (no packageset)
[05:58] <LocutusOfBorg> vorlon, can we please hint coqeal and coq-unimath on armhf? (also remove coq-unimath on armhf, it can't be built anymore due to 32bit
[05:58] <LocutusOfBorg> this hopefully can make ocaml go in
[05:58] <LocutusOfBorg> (at least give a better overview of what is still missing, probably only coq-unimath build on arm64)
[07:23] <LocutusOfBorg> autopkgtests infra looks sad
[07:23] <LocutusOfBorg> 504 Gateway Time-out when trying to trigger a test...
[11:22] <mitya57> Hi! Can someone please remove old qgis binaries from armhf to let the new version migrate? See Debian #1037360.
[11:22] -ubottu:#ubuntu-release- Debian bug 1037360 in ftp.debian.org "RM: qgis [armel armhf] -- ROM; FTBFS on armel/armhf" [Normal, Open] https://bugs.debian.org/1037360
[11:35] -queuebot:#ubuntu-release- New binary: gdal [amd64] (mantic-proposed/universe) [3.7.0+dfsg-1] (kubuntu)
[11:35] -queuebot:#ubuntu-release- New binary: gdal [armhf] (mantic-proposed/universe) [3.7.0+dfsg-1] (kubuntu)
[11:39] -queuebot:#ubuntu-release- New binary: gdal [s390x] (mantic-proposed/universe) [3.7.0+dfsg-1] (kubuntu)
[11:41] -queuebot:#ubuntu-release- New binary: gdal [ppc64el] (mantic-proposed/universe) [3.7.0+dfsg-1] (kubuntu)
[11:44] -queuebot:#ubuntu-release- New binary: openmm [amd64] (mantic-proposed/universe) [8.0.0+dfsg-2] (no packageset)
[11:44] -queuebot:#ubuntu-release- New binary: openmm [arm64] (mantic-proposed/universe) [8.0.0+dfsg-2] (no packageset)
[11:52] -queuebot:#ubuntu-release- New binary: openmm [ppc64el] (mantic-proposed/universe) [8.0.0+dfsg-2] (no packageset)
[11:55] -queuebot:#ubuntu-release- Packageset: Removed mozjs102 from i386-whitelist in focal
[11:55] -queuebot:#ubuntu-release- Packageset: Added gcc-13 to i386-whitelist in focal
[11:55] -queuebot:#ubuntu-release- Packageset: Added gcc-13-cross to i386-whitelist in focal
[11:55] -queuebot:#ubuntu-release- Packageset: Added gcc-13-cross-ports to i386-whitelist in focal
[11:55] -queuebot:#ubuntu-release- Packageset: Added llvm-toolchain-16 to i386-whitelist in focal
[11:55] -queuebot:#ubuntu-release- Packageset: Added mimalloc to i386-whitelist in focal
[11:55] -queuebot:#ubuntu-release- Packageset: Added unifdef to i386-whitelist in focal
[11:56] -queuebot:#ubuntu-release- New binary: gdal [arm64] (mantic-proposed/universe) [3.7.0+dfsg-1] (kubuntu)
[13:03] -queuebot:#ubuntu-release- New binary: insighttoolkit5 [amd64] (mantic-proposed/universe) [5.3.0-1] (no packageset)
[13:20] -queuebot:#ubuntu-release- Unapproved: rejected thermald [source] (focal-proposed) [1.9.1-1ubuntu0.7]
[13:23] -queuebot:#ubuntu-release- Unapproved: rejected wireguard [source] (jammy-proposed) [1.0.20210914-1ubuntu<IP_ADDRESS>]
[13:26] -queuebot:#ubuntu-release- Unapproved: rejected gnome-session [source] (jammy-proposed) [42.0-1ubuntu2.2]
[13:27] -queuebot:#ubuntu-release- Unapproved: rejected jansson [source] (jammy-proposed) [2.14-2~22.04.1]
[13:30] -queuebot:#ubuntu-release- New binary: gdal [riscv64] (mantic-proposed/universe) [3.7.0+dfsg-1] (kubuntu)
[14:15] <LocutusOfBorg> vorlon, https://sourceware.org/bugzilla/show_bug.cgi?id=30536 :D
[14:15] -ubottu:#ubuntu-release- sourceware.org bug 30536 in binutils "ppc64el gold linker produces unusable clang-16 binary" [Normal, Resolved: Fixed]
[14:48] -queuebot:#ubuntu-release- Unapproved: libvpoll-eventfd (jammy-proposed/universe) [0.1-2 => 0.1-2ubuntu1] (no packageset)
[15:49] -queuebot:#ubuntu-release- Unapproved: sysdig (jammy-proposed/universe) [0.27.1-0.3ubuntu0.1 => 0.27.1-0.3ubuntu0.2] (kernel-dkms)
[17:14] <vorlon> bluesabre: hi, can we sync about xubuntu image size limits? both jammy and mantic dailies currently ~10% over the listed limit
[17:14] <vorlon> bluesabre: also, it looks like the only person receiving the email notifications about oversized images is Micah, who AFAIK is no longer involved; do you want to update that?
[17:16] <vorlon> LocutusOfBorg: what needs hinted wrt coqeal/armhf? I don't see any blockers
[17:16] <vorlon> LocutusOfBorg: also coq-unimath needs fixed to not exclude riscv64 from the list of 64-bit archs
[17:21] -queuebot:#ubuntu-release- New binary: golang-github-form3tech-oss-jwt-go [amd64] (mantic-proposed/none) [3.2.3-2] (no packageset)
[18:08] <LocutusOfBorg> vorlon, autopkgtest for coq-unimath/20220816-2build2: armhf: Regression ♻
[18:08] <vorlon> LocutusOfBorg: that's coq-unimath, not coqeal?
[18:09] <LocutusOfBorg> coqeal "heal" itself during the day :D
[18:09] <vorlon> ok
[18:09] <LocutusOfBorg> oh yes new coqeal version fixed
[18:09] <LocutusOfBorg> unimath uploaded
[18:10] <LocutusOfBorg> and I'm testing binutils patch
[18:10] <LocutusOfBorg> (in ppa)
[18:13] <LocutusOfBorg> btw if you have spare time, any reason for gnustep-base fail in Ubuntu but not in Debian?
[18:13] <LocutusOfBorg> looks mostly same toolchain
[18:13] <LocutusOfBorg><EMAIL_ADDRESS>[18:26] <vorlon> LocutusOfBorg: I wouldn't have any particular insight into a gnustep failure, I'd be starting from square 1
[18:40] -queuebot:#ubuntu-release- Unapproved: libvirt (jammy-proposed/main) [8.0.0-1ubuntu7.5 => 8.0.0-1ubuntu7.6] (ubuntu-server, virt)
[20:13] -queuebot:#ubuntu-release- Unapproved: php8.1 (lunar-proposed/main) [8.1.12-1ubuntu4 => 8.1.12-1ubuntu4.1] (i386-whitelist, ubuntu-server)
[20:14] -queuebot:#ubuntu-release- Unapproved: php8.1 (jammy-proposed/main) [8.1.2-1ubuntu2.11 => 8.1.2-1ubuntu2.12] (i386-whitelist, ubuntu-server)
[20:14] -queuebot:#ubuntu-release- Unapproved: php8.1 (kinetic-proposed/main) [8.1.7-1ubuntu3.3 => 8.1.7-1ubuntu3.4] (i386-whitelist, ubuntu-server)
[20:27] -queuebot:#ubuntu-release- New source: containerd-app (mantic-proposed/primary) [1.7.2-0ubuntu1]
[20:28] <kanashiro[m]> vorlon: I just uploaded src:containerd-app to apply the same changes I did in docker.io. Could you please take a look at it in NEW?
[20:52] <vorlon> jbicha: any idea why these rust packages you're syncing were uploaded to experimental instead of unstable?
[20:53] -queuebot:#ubuntu-release- New: accepted rust-libspa [sync] (mantic-proposed) [0.6.0-1]
[20:53] -queuebot:#ubuntu-release- New: accepted rust-zbus-macros-1 [sync] (mantic-proposed) [1.9.3-1]
[20:53] -queuebot:#ubuntu-release- New: accepted rust-zvariant-derive-2 [sync] (mantic-proposed) [2.10.0-2]
[20:53] -queuebot:#ubuntu-release- New: accepted rust-pipewire [sync] (mantic-proposed) [0.6.0-1]
[20:53] -queuebot:#ubuntu-release- New: accepted rust-zvariant-2 [sync] (mantic-proposed) [2.10.0-2]
[20:53] -queuebot:#ubuntu-release- New: accepted gdal [arm64] (mantic-proposed) [3.7.0+dfsg-1]
[20:53] -queuebot:#ubuntu-release- New: accepted gdal [riscv64] (mantic-proposed) [3.7.0+dfsg-1]
[20:53] -queuebot:#ubuntu-release- New: accepted insighttoolkit5 [amd64] (mantic-proposed) [5.3.0-1]
[20:53] -queuebot:#ubuntu-release- New: accepted openmm [arm64] (mantic-proposed) [8.0.0+dfsg-2]
[20:53] -queuebot:#ubuntu-release- New: accepted gdal [ppc64el] (mantic-proposed) [3.7.0+dfsg-1]
[20:53] -queuebot:#ubuntu-release- New: accepted openmm [amd64] (mantic-proposed) [8.0.0+dfsg-2]
[20:53] -queuebot:#ubuntu-release- New: accepted golang-github-form3tech-oss-jwt-go [amd64] (mantic-proposed) [3.2.3-2]
[20:53] -queuebot:#ubuntu-release- New: accepted openmm [ppc64el] (mantic-proposed) [8.0.0+dfsg-2]
[20:54] -queuebot:#ubuntu-release- New: accepted ccextractor [amd64] (mantic-proposed) [0.94+ds1-2]
[20:54] -queuebot:#ubuntu-release- New: accepted ccextractor [armhf] (mantic-proposed) [0.94+ds1-2]
[20:54] -queuebot:#ubuntu-release- New: accepted ccextractor [riscv64] (mantic-proposed) [0.94+ds1-2]
[20:54] -queuebot:#ubuntu-release- New: accepted gdal [amd64] (mantic-proposed) [3.7.0+dfsg-1]
[20:54] -queuebot:#ubuntu-release- New: accepted gdal [s390x] (mantic-proposed) [3.7.0+dfsg-1]
[20:54] -queuebot:#ubuntu-release- New: accepted ccextractor [arm64] (mantic-proposed) [0.94+ds1-2]
[20:54] -queuebot:#ubuntu-release- New: accepted ccextractor [s390x] (mantic-proposed) [0.94+ds1-2]
[20:54] -queuebot:#ubuntu-release- New: accepted ccextractor [ppc64el] (mantic-proposed) [0.94+ds1-2]
[20:54] -queuebot:#ubuntu-release- New: accepted gdal [armhf] (mantic-proposed) [3.7.0+dfsg-1]
[20:55] -queuebot:#ubuntu-release- New binary: rust-zbus-macros-1 [amd64] (mantic-proposed/none) [1.9.3-1] (no packageset)
[20:56] -queuebot:#ubuntu-release- New binary: rust-libspa [amd64] (mantic-proposed/none) [0.6.0-1] (no packageset)
[20:56] -queuebot:#ubuntu-release- New binary: rust-zbus-macros-1 [arm64] (mantic-proposed/none) [1.9.3-1] (no packageset)
[20:56] -queuebot:#ubuntu-release- New binary: rust-zbus-macros-1 [s390x] (mantic-proposed/none) [1.9.3-1] (no packageset)
[20:56] -queuebot:#ubuntu-release- New binary: rust-zvariant-derive-2 [ppc64el] (mantic-proposed/none) [2.10.0-2] (no packageset)
[20:56] -queuebot:#ubuntu-release- New binary: rust-libspa [armhf] (mantic-proposed/none) [0.6.0-1] (no packageset)
[20:56] -queuebot:#ubuntu-release- New binary: rust-zvariant-derive-2 [amd64] (mantic-proposed/none) [2.10.0-2] (no packageset)
[20:56] -queuebot:#ubuntu-release- New binary: rust-zbus-macros-1 [ppc64el] (mantic-proposed/none) [1.9.3-1] (no packageset)
[20:56] -queuebot:#ubuntu-release- New binary: rust-zvariant-derive-2 [s390x] (mantic-proposed/none) [2.10.0-2] (no packageset)
[20:57] -queuebot:#ubuntu-release- New binary: rust-libspa [ppc64el] (mantic-proposed/none) [0.6.0-1] (no packageset)
[20:57] -queuebot:#ubuntu-release- New binary: rust-zvariant-derive-2 [armhf] (mantic-proposed/none) [2.10.0-2] (no packageset)
[20:57] -queuebot:#ubuntu-release- New binary: rust-libspa [s390x] (mantic-proposed/none) [0.6.0-1] (no packageset)
[20:58] -queuebot:#ubuntu-release- New binary: rust-libspa [arm64] (mantic-proposed/none) [0.6.0-1] (no packageset)
[20:58] -queuebot:#ubuntu-release- New binary: rust-zvariant-derive-2 [arm64] (mantic-proposed/none) [2.10.0-2] (no packageset)
[20:58] -queuebot:#ubuntu-release- New binary: rust-zbus-macros-1 [armhf] (mantic-proposed/none) [1.9.3-1] (no packageset)
[21:10] -queuebot:#ubuntu-release- New binary: rust-zbus-macros-1 [riscv64] (mantic-proposed/none) [1.9.3-1] (no packageset)
[21:11] -queuebot:#ubuntu-release- New binary: rust-zvariant-derive-2 [riscv64] (mantic-proposed/none) [2.10.0-2] (no packageset)
[21:12] -queuebot:#ubuntu-release- New: accepted rust-libspa [arm64] (mantic-proposed) [0.6.0-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zbus-macros-1 [riscv64] (mantic-proposed) [1.9.3-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zvariant-derive-2 [riscv64] (mantic-proposed) [2.10.0-2]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zbus-macros-1 [armhf] (mantic-proposed) [1.9.3-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zvariant-derive-2 [arm64] (mantic-proposed) [2.10.0-2]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-libspa [amd64] (mantic-proposed) [0.6.0-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-libspa [ppc64el] (mantic-proposed) [0.6.0-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zbus-macros-1 [amd64] (mantic-proposed) [1.9.3-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zbus-macros-1 [ppc64el] (mantic-proposed) [1.9.3-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zvariant-derive-2 [amd64] (mantic-proposed) [2.10.0-2]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zvariant-derive-2 [ppc64el] (mantic-proposed) [2.10.0-2]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-libspa [armhf] (mantic-proposed) [0.6.0-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zbus-macros-1 [arm64] (mantic-proposed) [1.9.3-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zvariant-derive-2 [armhf] (mantic-proposed) [2.10.0-2]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-libspa [s390x] (mantic-proposed) [0.6.0-1]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zvariant-derive-2 [s390x] (mantic-proposed) [2.10.0-2]
[21:12] -queuebot:#ubuntu-release- New: accepted rust-zbus-macros-1 [s390x] (mantic-proposed) [1.9.3-1]
[21:14] -queuebot:#ubuntu-release- New binary: rust-libspa [riscv64] (mantic-proposed/none) [0.6.0-1] (no packageset)
[21:30] -queuebot:#ubuntu-release- New: accepted rust-libspa [riscv64] (mantic-proposed) [0.6.0-1]
[21:41] <vorlon> kanashiro[m]: debian/patches/0001-Skip-test-failing-on-riscv64.patch so how is it that you have a test *running* on riscv64?
[21:42] <vorlon> kanashiro[m]: because riscv64 builds get DEB_BUILD_OPTIONS=nocheck in Ubuntu, and we don't run autopkgtests
[21:43] <kanashiro[m]> vorlon: last time I uploaded this same containerd version (got removed from mantic-proposed) I got a FTBFS in riscv64. It is likely because it was not checking DEB_BUILD_OPTIONS=nocheck before, I added it in this version
[21:43] <vorlon> kanashiro[m]: ok, ack
[21:44] <kanashiro[m]> I can remove the patch then
[21:45] -queuebot:#ubuntu-release- New: accepted containerd-app [source] (mantic-proposed) [1.7.2-0ubuntu1]
[21:46] <kanashiro[m]> vorlon: thanks!
[22:03] <jbicha> vorlon: yes, pipewire & libspa are in Unstable now (initially uploaded to Experimental because they needed newer rustc), the rust-z* are probably ok for Unstable once we get rust-zbus-1 in
[22:06] <jbicha> the earlier rust syncs are part of getting rust-gtk 0.5 in
[22:25] -queuebot:#ubuntu-release- New binary: rust-zbus-names [amd64] (mantic-proposed/universe) [2.5.1-2] (no packageset)
[22:32] -queuebot:#ubuntu-release- New binary: rust-zbus-names [arm64] (mantic-proposed/universe) [2.5.1-2] (no packageset)
[22:32] -queuebot:#ubuntu-release- New binary: rust-zbus-names [s390x] (mantic-proposed/universe) [2.5.1-2] (no packageset)
[22:32] -queuebot:#ubuntu-release- New binary: rust-zbus-names [ppc64el] (mantic-proposed/universe) [2.5.1-2] (no packageset)
[22:35] -queuebot:#ubuntu-release- New binary: rust-zbus-names [armhf] (mantic-proposed/universe) [2.5.1-2] (no packageset)
[22:49] -queuebot:#ubuntu-release- New binary: rust-zbus-names [riscv64] (mantic-proposed/universe) [2.5.1-2] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: rust-zvariant-2 [amd64] (mantic-proposed/universe) [2.10.0-2] (no packageset)
[23:15] -queuebot:#ubuntu-release- New binary: rust-zvariant-2 [ppc64el] (mantic-proposed/universe) [2.10.0-2] (no packageset)
[23:25] -queuebot:#ubuntu-release- New binary: libcotp [amd64] (mantic-proposed/universe) [2.0.1-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: jane-street-headers [amd64] (mantic-proposed/none) [0.16.0-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: libcotp [ppc64el] (mantic-proposed/universe) [2.0.1-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: rust-pipewire [amd64] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: jane-street-headers [ppc64el] (mantic-proposed/none) [0.16.0-1] (no packageset)
[23:27] -queuebot:#ubuntu-release- New binary: libcotp [s390x] (mantic-proposed/universe) [2.0.1-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: jane-street-headers [arm64] (mantic-proposed/none) [0.16.0-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: libcotp [arm64] (mantic-proposed/universe) [2.0.1-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: jane-street-headers [armhf] (mantic-proposed/none) [0.16.0-1] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: rust-pipewire [ppc64el] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:28] -queuebot:#ubuntu-release- New binary: rust-zvariant-2 [arm64] (mantic-proposed/universe) [2.10.0-2] (no packageset)
[23:29] -queuebot:#ubuntu-release- New binary: rust-pipewire [armhf] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:30] -queuebot:#ubuntu-release- New binary: rust-pipewire [arm64] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: rust-zvariant-2 [armhf] (mantic-proposed/universe) [2.10.0-2] (no packageset)
[23:33] -queuebot:#ubuntu-release- New binary: rust-zvariant-2 [riscv64] (mantic-proposed/universe) [2.10.0-2] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: jane-street-headers [s390x] (mantic-proposed/none) [0.16.0-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: rust-pipewire [s390x] (mantic-proposed/universe) [0.6.0-2] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: libcotp [armhf] (mantic-proposed/universe) [2.0.1-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: libcotp [riscv64] (mantic-proposed/universe) [2.0.1-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: rust-pipewire [armhf] (mantic-proposed/universe) [0.6.0-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: rust-zvariant-2 [s390x] (mantic-proposed/universe) [2.10.0-2] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: rust-pipewire [amd64] (mantic-proposed/universe) [0.6.0-1] (no packageset)
[23:35] -queuebot:#ubuntu-release- New binary: rust-pipewire [ppc64el] (mantic-proposed/universe) [0.6.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: jane-street-headers [riscv64] (mantic-proposed/universe) [0.16.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: rust-pipewire [s390x] (mantic-proposed/universe) [0.6.0-1] (no packageset)
[23:38] -queuebot:#ubuntu-release- New binary: rust-pipewire [arm64] (mantic-proposed/universe) [0.6.0-1] (no packageset)
[23:40] -queuebot:#ubuntu-release- New binary: rust-pipewire [riscv64] (mantic-proposed/universe) [0.6.0-2] (no packageset)


[00:11] <linggao> zyga_, sorry, I just want to mention that we are using Ubuntu 16.04 on rpi2/rpi3.
[00:11] <linggao> then we installed snapd.
[00:16] <linggao> Hi ogra_, zyga_ told me that you are using on-board wifi on rpi3. Can you let me know what is your os  and kernel version?   Nothing shows up on dmesg and it doesn't seem to matter what the context is.
[05:03] <f_fox> It happens during the configure hook of the core snap, for instance, but if I skip that task by editing state.json manually everything else seems to work fine.
[05:06] <f_fox> actually scratch that, I just tried it on a fresh image and it seems to work now
[05:16] <wxl> anyone have a clue where to file a bug against a particular snap?
[05:17] <wxl> in this case, speaking specifically of vlc
[05:23] <mup> Bug #1666386 opened: Snap apps do not work on Lubtuntu <Snappy:New> <https://launchpad.net/bugs/1666386>
[05:32] <wxl> yeah i'm fixing that
[06:20] <jjohansen> zyga: the kernels with the fixes are publishing, I'm not sure when these kernels will get rolled into all snaps
[07:37] <zyga> jjohansen: hey, thank you for noticing the question earlier, is that -62 or -63 that should have the fix?
[07:44] <zyga> f_fox: hey, known issues
[07:44] <zyga> f_fox: we disabled the configure hook while we untangle everything
[07:46] <f_fox> zyga: that explains it, thanks
[07:49] <zyga> f_fox: we experienced a sequence of bugs when we introduced the configure hook on the core
[07:49] <zyga> f_fox: a portion of devices did not update successfuly
[07:50] <zyga> f_fox: we're investigating and trying to understand and fix the issue but for now we disabled the configure hook to let devices update
[07:57] <jjohansen> zyga: good question so far only zesty has published, and the bug update is reporting as fixed in 4.10.0-8.10 but my tree is saying its in 4.10.0-9.11
[07:57] <jjohansen> I am going to have to pull down the kernel and test
[07:59] <zyga> jjohansen: what is 8.10 and 9.11?
[08:00] <jjohansen> zyga: zesty kernels, the only ones that have published yet, the new kernels are publishing but it will take a while for all the releases
[08:01] <jjohansen> I expect they will finish some time tonight, zesty obviously goes first as it doesn't have the regression and USN work that xenial and yakkety kernels have
[08:01] <zyga> jjohansen: I see, thanks
[08:01] <zyga> jjohansen: I'll run a check to see that the bug is fixed on zesty images
[08:06] <mup> PR snapd#2889 closed: errtracker: add support for error reporting via daisy.ubuntu.com <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2889>
[08:33] <zyga> ogra_: hey
[08:35] <zyga> ogra_: I was wondering about the joule board
[08:35] <zyga> ogra_: do you know who supports that at canonical?
[08:35] <zyga> ogra_: I would like to publish the gadget snap to github
[08:35] <zyga> ogra_: and to see if we can build
[08:36] <mup> PR snapd#2897 opened: errtracker: mock machine-id path to fix FTBFS in sbuild <Created by mvo5> <https://github.com/snapcore/snapd/pull/2897>
[08:42] <mup> PR snapd#2897 closed: errtracker: mock machine-id path to fix FTBFS in sbuild <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2897>
[09:13] <mup> PR snapd#2898 opened: many: merge 2.22.5 back to master <Created by zyga> <https://github.com/snapcore/snapd/pull/2898>
[09:57] <ogra_> zyga, JohnAgosta can get you in contact with the right people
[10:01] <zyga> ogra_: thanks!
[10:01] <zyga> ogra_: how are you?
[10:02] <ogra_> okayish ...
[10:02] <ogra_> :)
[10:02] <ogra_> trying to keep up with 600 telegram messages atm :P
[10:02] <_prasen_> hi
[10:03] <_prasen_> why does snap install try to download the core snap
[10:03] <_prasen_> nub
[10:03] <_prasen_> pls hlp
[10:04] <ogra_> _prasen_, all snaps are executed in context of the core snap, that is how snaps get distro and release independent
[10:06] <_prasen_> using 16.04
[10:06] <_prasen_> doesnt it already have a snappy core?
[10:06] <ogra_> no
[10:07] <_prasen_> if i want to develop for ubuntu core without any h/w
[10:07] <_prasen_> i need to install core using kvm
[10:07] <_prasen_> ?
[10:08] <_prasen_> the core snap which gets installed isnt the Ubunbtu Core right?
[10:08] <_prasen_> I need to install Ubuntu Core on a pi.
[10:08] <_prasen_> so was trying to run ubuntu core inside kvm
[10:08] <_prasen_> but on the ubuntu host of 16.04
[10:09] <_prasen_> I am stuck at snap install trying to "get" due to corporate proxy
[10:11] <_prasen_> running on kvm till i get hands on the pi
[10:15] <ogra_> _prasen_, well, if you only want to develop snap packages you can do that directly on your desktop without kvm
[10:16] <_prasen_> yes
[10:16] <_prasen_> @oga
[10:16] <nothal> _prasen_: No such command!
[10:16] <_prasen_> oga : did not knew about the core snap usage
[10:17] <_prasen_> was thinking of ssh into the kvm running core and installing snaps developed at the host
[10:17] <_prasen_> nothal : which cmd
[10:20] <_prasen_> even my host is a vm :(((
[10:23] <mup> PR snapd#2899 opened: Kmod use spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2899>
[10:45] <zyga> _prasen_: hey
[10:45] <zyga> _prasen_: with the way snappy works you don't need any separate VM
[10:45] <zyga> _prasen_: just develop snaps locally
[10:45] <zyga> _prasen_: using snapcraft
[10:45] <zyga> _prasen_: and install them on your own system
[10:48] <ogra_> zyga, but what if the company proxy doesntz let you though :)
[10:48] <zyga> ogra_: I snapd can respect proxy settings for a while now
[10:48] <zyga> _prasen_: if that's the problem for you I can show you how to proxy your stuff
[10:49] <ogra_> zyga, depedns wehat the proxy blcks ;)
[10:49] <zyga> ogra_: true
[10:49] <_prasen_> my proxy is blocking
[10:50] <zyga> _prasen_: I think you need to work with your IT to open up the *.ubuntu.com part and the CDN that snappy uses to distribute snaps
[10:50] <ogra_> _prasen_, did you configure your machine properly for the proxy ?
[10:50] <_prasen_> search.apps.ubuntu
[10:50] <_prasen_> yes
[10:50] <_prasen_> i am on iy
[10:50] <_prasen_> it*
[10:50] <zyga> _prasen_: there are plenty of domains under *.ubuntu
[10:50] <zyga> _prasen_: or just cheat and tether your phone ;-)
[10:50] <zyga> (you can get fired for that though)
[10:50] <_prasen_> yes I did that once
[10:50] <_prasen_> ;D
[10:51] <_prasen_> tethered and ran
[10:51] <_prasen_> yes
[10:51] <_prasen_> would need to get permissions for tat
[10:51] <_prasen_> can i download the core snap from any diiferent location other than *.ubuntu
[10:51] <ogra_> well, ifg you have to ask for that you can as well just ask for proxy opening for your machine to the respective urls
[10:51] <_prasen_> launchpad doesnt have it
[10:52] <zyga> _prasen_: no, and you also need assertions
[10:52] <zyga> _prasen_: techically snapd talks to the store at *.ubuntu.com and then gets redirected to a CDN
[10:52] <zyga> _prasen_: so the core snap is really elsewhere
[10:53] <_prasen_> okay
[10:53] <_prasen_> the link really specifies a whole lot
[10:53] <zyga> _prasen_: but hey, they opened IRC for you
[10:53] <zyga> _prasen_: please do let us know, it is an intereting problem to solve
[10:53] <zyga> _prasen_: which URLs are needed to use snapd behind a corporate proxy
[10:54] <_prasen_> html which I dont understand
[10:54] <zyga> _prasen_: ?
[10:55] <_prasen_> okay
[10:55] <_prasen_> wait
[10:55] <_prasen_> I'll try to share the link here
[10:55] <_prasen_> yes it is interesting to solve
[10:56] <_prasen_> but the main work that  i have to do
[10:56] <_prasen_> i am stuck there
[10:56] <_prasen_> xP
[11:01] <_prasen_> Get https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement: x509:
[11:02] <_prasen_> this is the error i get
[11:02] <_prasen_> mozzilla prompts me to add exception
[11:02] <_prasen_> to this
[11:03] <_prasen_> if i do
[11:03] <_prasen_> it shows 405 Method not allowed
[11:12] <mup> PR snapd#2862 closed: cmd/snap, store: change error messages to reflect latest UX doc <Created by pete-woods> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2862>
[11:21] <_prasen_> ogra : should I able to see interfaces before the core snap is present on 16.04
[11:21] <_prasen_> ?
[11:21] <ogra_> i dont think so, no
[11:22] <_prasen_> knowing that helps a lot
[11:22] <_prasen_> ty
[11:22] <_prasen_> nowhere in the official doc
[11:23] <_prasen_> it is said that the first time eecution of snap install will get the core snap first
[11:23] <_prasen_> or the docker snap
[11:23] <_prasen_> tis weird
[11:26] <_prasen_> or any other online resource fails to mention that
[11:26] <ogra_> it shouldnt get rthe docker snap for sure, only the core snap
[11:27] <_prasen_> okay..
[11:27] <ogra_> (unless you did snap install docker indeed)
[11:27] <ogra_> (then it would try to get both)
[11:27] <_prasen_> oh some guy in the office said it would do both
[11:27] <_prasen_> he seems pretty unreliable though
[11:27] <_prasen_> ;p
[11:46] <didrocks> stgraber: hey! I don't find the images:ubuntu-core/16 image and getting an error: not found, was the image removed?
[11:51] <didrocks> stgraber: so, after listing images, I noted that I have 2 available (x86 and i386). I did lxc launch images:ubuntu-core/16/amd64, but getting a download error "Retrieving image: 100% (961.30MB/s)error: multipart: NextPart: EOF" (getting that constantly)
[12:38] <mup> PR snapcraft#1156 opened: python plugin: use stage headers if applicable <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1156>
[12:42] <ogra_> jdstrand, do you see jenny murphys question about the ppp interface ? looking at interfaces/builtin/ppp.go it looks like she should just be able to run pppd and write configs to /etc/ppp directly
[12:42] <ogra_> or am i wrong here
[12:44] <sergiusens> morphis: hey, mind doing a bit of verification for LP: #1665759 ?
[12:44] <mup> Bug #1665759: [SRU] New stable micro release 2.27.1 <verification-needed> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Yakkety):Fix Committed> <snapcraft (Ubuntu Zesty):Fix Released> <https://launchpad.net/bugs/1665759>
[12:45] <morphis> sergiusens: sure, is that already available on the launchpad builders?
[12:45] <morphis> or still in proposed?
[12:46] <sergiusens> morphis: in proposed
[12:46] <morphis> ok
[12:46] <sergiusens> morphis: you could try and enable proposed on launchpad builders and build if you wanted to
[12:46] <sergiusens> but you get all of it
[12:50] <morphis> yes
[13:24] <hangun> jdstrand: hi,  I have a namespaces issue which is similar to this one ( https://bugs.launchpad.net/snappy/+bug/1665590). With zyga suggestion, I upgraded snap to the latest version(2.22.3), but the issue still be there.
[13:24] <mup> Bug #1665590: When snapd is refreshed, it does not regenerate apparmor profiles when interfaces have changed <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1665590>
[13:26] <hangun> jdstrand:   run "dmesg | grep DENIED"  http://pastebin.com/2xJZv3YF
[13:29] <mup> PR snapcraft#1153 closed: contribution guide: add commit message template <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1153>
[13:30] <hangun> jdstrand:  I try to disable apparmor option in linux kernel config and re-build it.  but still have the namespace issue. (http://pastebin.com/PvixSWNr)
[13:38] <jdstrand> hangun: you need to load the profile that is in /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine. This is part of https://github.com/snapcore/snapd/pull/2810
[13:38] <mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
[13:39] <jdstrand> hangun: do: sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine.
[13:39] <jdstrand> err
[13:39] <jdstrand> sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine
[13:39] <jdstrand> hangun: if that works for you, feel free to 'sudo cp /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine /etc/apparmor.d/
[13:41] <jdstrand> ogra_: hi! would you mind running your machinery for linux-generic-bbb?
[13:41] <ogra_> jdstrand, on it
[13:41] <jdstrand> ogra_: thanks! :)
[13:58] <ogra_> jdstrand, btw, did you see my ping about the ppp interface above ?
 jdstrand, do you see jenny murphys question about the ppp interface ? looking at interfaces/builtin/ppp.go it looks like she should just be able to run pppd and write configs to /etc/ppp directly
 or am i wrong here
[14:02] <jdstrand> ogra_: I hadn't yet. you are correct-- that is the intent of the rules
[14:02] <ogra_> k
[14:02] <jdstrand> (and that's what they say)
[14:03] <jdstrand> I think morphis wrote/uses this somewhere. if it isn't working right, should file a bug
[14:04] <liuxg> sergiusens, ping
[14:05] <zyga> jdstrand: hey, how are you
[14:06] <zyga> jdstrand: we have some fire-fighting to do this week but I'd like to re-focus on update-ns when that is done
[14:08] <ogra_> jdstrand, well, looking at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/ppp.go#L34 we might perhaps wnat to also allow ttyS[0-9], after all it is likely that pppd uses serial modems
[14:10] <morphis> ogra_, jdstrand: yeah it is a bit mixed in our case between the network-manager, modem-manager and ppp interface
[14:11] <morphis> needs some cleanup at a future point
[14:11] <morphis> ogra_: what about her using modem-manager instead of ppp directly?
[14:11] <ogra_> morphis, yeah, looks like jenny murphy uses pppd directly from her management snap
[14:11] <ogra_> ask in the mail thread :)
[14:11] <ogra_> (or on rocket, where she is too)
[14:11] <ogra_> (in the snapcraft channel)
[14:11] <morphis> rocket .. too many communication channels .-)
[14:12] <ogra_> yes
[14:12] <ogra_> i'm slowly running out of workspaces :) everything plastered with chat tools
[14:12] <ogra_> telegram, rocket, irc email ...
[14:13] <jdstrand> mvo: hey, where is SNAP_REEXEC set? I see with 2.22.3 "cmd.go:59: DEBUG: re-exec disabled by user" but I don't see it in /etc/environment. I don't remember setting this. this is on xenial
[14:14] <mvo> jdstrand: what version do you get with "snap version"
[14:15] <morphis> ogra_: :-)
[14:15] <mvo> jdstrand: might be a red-herring
[14:15] <jdstrand> $ snap version
[14:15] <jdstrand> snap    2.22.5
[14:15] <jdstrand> snapd   2.22.5
[14:15] <jdstrand> series  16
[14:15] <jdstrand> ubuntu  16.04
[14:15] <mvo> jdstrand: that looks good, so the message is wrong. iirc we fixed this in master
[14:18] <sergiusens> morphis: well read /topic ;-)
[14:18] <jdstrand> mvo: ok, thanks
[14:19] <ogra_> sergiusens' favorite sentence in here recently :)
[14:19] <morphis> sergiusens: yeah :-)
[14:26] <zyga> jdstrand: actually, one tiny review: https://github.com/snapcore/snapd/pull/2881
[14:26] <mup> PR snapd#2881: cmd/snap-confine: don't crash if nvidia module is loaded but drivers are not available <Created by zyga> <https://github.com/snapcore/snapd/pull/2881>
[14:34] <jdstrand> zyga: ack
[14:39] <bulldog> hi guys what package should i ship in my snap to allow my Qt app open external links in system's applications
[14:39] <bulldog> mhall119, hi
[14:40] <bulldog> ogra_, its been long , holla :)
[14:40] <bulldog> xdg-open ??
[14:41] <hangun> jdstrand:  there is only  a "bin" folder in /snap directory, no "core" folder.
[14:42] <bulldog> lol barry
[14:44] <hangun> jdstrand: how I load the profile that is in /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine?
[14:51] <bulldog> help
[14:57] <jdstrand> hangun: it seems you don't have a core snap installed. can you do 'sudo snap install core' ?
[14:57] <jdstrand> hangun: this is on classic, right? (not all snaps?)
[15:02] <sergiusens> ogra_: I;ve never been so eager to tell people to read topic ;-)
[15:02] <ogra_> haha
[15:03] <hangun> jdstrand: what does the "classic" mean?
[15:05] <zyga> bulldog: hey,
[15:05] <zyga> bulldog: you should not need to do anything anymore
[15:05] <zyga> bulldog: but on the host you need to apt-get install snapd-xdg-open
[15:05] <zyga> bulldog: don't put xdg-open into your snap, it will be just useless there
[15:05] <jdstrand> hangun: you are running snappy on a traditional distribution, like Ubuntu, Debian, Arch, etc
[15:05] <zyga> jdstrand: I believe so
[15:05] <zyga> jdstrand: I was working with hangun earlier
[15:06] <zyga> jdstrand: this is xenial userspace + custom kernel + snapd
[15:06] <jdstrand> hangun: as opposed to 'Ubuntu Core', which is a minimal image that can work with only snaps
[15:06] <zyga> jdstrand: the kernel is based off 3.10 with apparmor enablement from some time ago
[15:06] <zyga> jdstrand: I had a look at the error hangun reported where snap confine cannot perform the bind mount capture from the child process
[15:06] <jdstrand> zyga: hangun gave me a paste: http://pastebin.com/2xJZv3YF
[15:06] <zyga> jdstrand: I'm not sure if apparmor changed in the last year that would only make the snap-confine profile work with the more current version of kernel code
[15:07] <zyga> jdstrand: right, that's what I saw
[15:07] <hangun> jdstrand:  I just upgraded snap version to 2.22.5.  I see there are some folders " bin , core, bubblegum96-gadget ,bubblegum96-kernel"
[15:07] <mardy_> jdstrand: hi! I just wanted to make sure you are aware of bug 1664155, to know if it makes sense to you :-)
[15:07] <mup> Bug #1664155: Interface hooks slots should know the name of the client snap <snapd:New> <https://launchpad.net/bugs/1664155>
[15:07] <jdstrand> zyga: I don't have any idea what's going wrong, but it seemed like perhaps the snap-confine profile on disk was wrong, which I thought was because https://github.com/snapcore/snapd/pull/2810 wasn't merged
[15:07] <mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
[15:08] <jdstrand> zyga: but based on all this new info, it seems different
[15:08] <zyga> jdstrand: I think that snap-confine is used from the package (still)
[15:08] <zyga> jdstrand: also hangun rebuilt snapd (by hand) so I'm not sure what is on the system now
[15:09] <jdstrand> zyga: there is no rule in the profile for this: apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" name="/run/snapd/ns/core.mnt" pid=3902 comm="snap-confine" srcname="/proc" flags="rw, bind"
[15:09] <jdstrand> we have mount options=(rw rbind) /proc/ -> /tmp/snap.rootfs_*/proc/,
[15:09] <jdstrand> but that is rbind, not bind
[15:11] <jdstrand> hangun: to unblock yourself, add 'mount,' to the 'mount-namespace-capture-helper' section of /etc/apparmor.d/usr.lib.snapd.snap-confine, then do 'sudo apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine'
[15:11] <jdstrand> hangun: once you get farther along, feel free to file a bug that /etc/apparmor.d/usr.lib.snapd.snap-confine doesn't have everything you need, with all the info to reproduce
[15:13] <hangun> jdstrand:  and zyga:  just following jdstrand's instruction:  1)sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine 2) sudo cp /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine /etc/apparmor.d/   ( it doesn't work  read-only file system)
[15:14] <hangun> 3) snap install hello-world
[15:15] <jdstrand> hangun: well, forget the cp. you seem to be porting to a new device/kernel. this isn't my area of expertise, but if you edit /etc/apparmor.d/usr.lib.snapd.snap-confine directly in the way I suggested, you might get farther along
[15:17] <zyga> (dinner)
[15:18] <jdstrand> mardy_: I think oa needs to be a consideration in the design for trust in snappy, which is something that tvoss is spear-heading. that said, afaik, a) interface hooks don't yet exist and b) you are trying to add ACLs into OA outside of snapd
[15:18] <jdstrand> mardy_: it seems that in unity8 panel when you enable shotwell for the facebook account, that might perform a 'snap connect'
[15:18] <mardy_> jdstrand: interface hooks have landed :-)
[15:20] <mardy_> jdstrand: didn't we say that such interfaces should auto-connect, and the trusted prompt will take care of actually granting the permissions?
[15:20] <jdstrand> mardy_: I'm also not sure if that ACL should live in OA-- trust-store is moving it to snapd. if you moved it to snapd, then you could rearrange things
[15:20] <jdstrand> mardy_: well, if the trusted helper is doing the mediating, yes that's true
[15:21] <jdstrand> mardy_: that then gets to my bit about storing your acls in snapd. again, this is something that should be considered with the trust discussions
[15:21] <mardy_> jdstrand: I think that OA is quite a special case, it's not granting access to a system resource, but to some data which the user has entered into OA itself
[15:22] <EEight> jdstrand: hi, someone told me you are the right person for this question: my snap doesn't connect automagically to the camera interface. I need to run sudo snap connect myapp:camera for it to works.
[15:23] <jdstrand> mardy_: it may be different, but I'm not sure it needs to be treated specially
[15:23] <EEight> jdstrand: I cannot ask my users to run this command after installing the application, is there a way to make it works out-of-the-box?
[15:23] <jdstrand> EEight: what is your application?
[15:23] <EEight> jdstrand: bayam
[15:24] <EEight> jdstrand: an electron application using electron-builder to build the snap
[15:24] <zyga> jdstrand: while that is the case how does it work in ubuntu all the time?
[15:24] <mup> Bug #1666553 opened: snap try works, but executing the application doesn't work in some directories like /tmp <Snappy:New> <https://launchpad.net/bugs/1666553>
[15:24] <EEight> jdstrand: reported here: https://bugs.launchpad.net/snapcraft/+bug/1609577
[15:24] <mup> Bug #1609577: Docs: Your First Snap webcam-webui does not work once installed <Snapcraft:New> <https://launchpad.net/bugs/1609577>
[15:26] <didrocks> zyga: you are quick :)
[15:26] <zyga> didrocks: haha, I just got lucky
[15:26] <jdstrand> EEight: the camera interface is considered privileged in that a malicious or misbehaving app could spy on the user when the interface is connected. this is why the user is given a say as to whether the interface should be connected
[15:26] <zyga> didrocks: I know about this bug, I was wondering what to do in that case
[15:27] <hangun> jdstrand: trouble you again.   How I add 'mount,' to the 'mount-namespace-capture-helper' section of /etc/apparmor.d/usr.lib.snapd.snap-confine ?
[15:27] <jdstrand> EEight: it is technically possible to have the interface autoconnected on install using a snap declaration, but then the user doesn't necessarily know what is happening
[15:27] <didrocks> zyga: yeah, I wonder how hackish a temporary mount point accessible on both side would work
[15:27] <didrocks> zyga: that or at least failing in snap try with some reasoning
[15:27] <didrocks> as we have the list of directories that are shadowed inside the snap
[15:28] <jdstrand> EEight: aiui, there is work to make this more discoverable for users. what some people do is create a small wrapper such that tries to use the resource, notices it cannot, and then tells the user what to do: eg, "Camera not available. Please run: sudo snap connect myapp:camera'
[15:29] <jdstrand> EEight: I suggest bringing this up on the snapcraft@ mailing list and asking about the progress to make interface connections easier for end users
[15:29] <mardy_> jdstrand: regardless of where the ACL lives, do you agree that the snap providing the slot needs to be able to get the name of the client (plug) snap, in order to get its name and icon?
[15:29] <hangun> jdstrand: the /etc folder is read only fs
[15:30] <EEight> jdstrand: does it means that even the final "solution" for this will be to ask the users to run a command line?
[15:30] <jdstrand> EEight: I might also mention that gadget snaps are able to influence auto-connect. so if this snap is part of a device you are creating, you can control the auto-connect yourself
[15:31] <jdstrand> EEight: not necessarily. aiui, snap install will help guide the user
[15:31] <jdstrand> EEight: but I'm not designing that and not up to date on it. I suggest asking on the list
[15:32] <_prasen__> its says ubuntu 16.04 comes with a snappy core but during the first execution of snap install it firsts installs the snap core after downloading it
[15:32] <jdstrand> hangun: I'm a bit confused by your system setup. it sounds like a traditional distro, but /etc is read-only. did it not boot correctly and the boot put / as readonly?
[15:32] <_prasen__> core snap*
[15:32] <EEight> jdstrand: well the instruction on how to install my application on ubuntu is to use software center. don't know how it will help my users.
[15:32] <_prasen__> so that snaps get a reference to be built
[15:33] <jdstrand> hangun: you can cp /etc/apparmor.d/usr.lib.snapd.snap-confine somewhere else, then modify that file, then run apparmor_parser -r on it. that will not survive a reboot
[15:33] <_prasen__> or installed
[15:33] <_prasen__> so that they could be shipped across various distros and versions
[15:33] <_prasen__> *confused*
[15:33] <jdstrand> EEight: re software-center, aiui, that is supposed to tie into snap install
[15:33] <zyga> didrocks: I'll think of something
[15:33] <jdstrand> EEight: again, I'm not designing that so not up to date
[15:33] <_prasen__> *confused*
[15:33] <_prasen__> why isnt 16.04 shipped with the core snap
[15:34] <jdstrand> mardy_: I'm not sure I agree with that. if the design is what you laid out in the bug, probably, but if the design is you calling snap rest api to do things/whatever, maybe not
[15:35] <ogra_> _prasen__, because that would most likely be outdated
[15:35] <EEight> jdstrand: ok i understand (not up to date) but question so that i can ask a good one: if my users install via the command line or via the software center - either way they will need to run eventually sudo snap myapp:camera?
[15:35] <_prasen__> hi ogra
[15:35] <jdstrand> EEight: yes
[15:35] <EEight> damn
[15:35] <jdstrand> EEight: *today*
[15:35] <_prasen__> this is _prasen_ only
[15:35] <_prasen__> left myself logged in
[15:35] <jdstrand> EEight: but there is planned work to make that better. I just don't know the priority or the designs
[15:36] <ogra_> _prasen__, like you should not keep the original kernel on a fresh install but apply all security updates on a classic 16.04 installation when using it in production the same applies to the snappy system
[15:36] <hangun> jdstrand: I copy it into home directory which can be modified.  How I modified this file? I can't understand how to add "mount" to mount-namespace-capture-helper section
[15:37] <ogra_> so when invoking snap for the first time the core snap is pulled freshly from the store
[15:37] <ogra_> sincer that has all the latest fixes and security updates
[15:37] <_prasen__> okay
[15:37] <_prasen__> that clears it
[15:37] <_prasen__> ty
[15:38] <_prasen__> but what about users
[15:38] <ogra_> (and as i said, all yourr snaps are executed in context of the core snap, so you really dont want to have any security holes in that one as it could break the snap confinement of the apps)
[15:38] <_prasen__> who would want to develop locally?
[15:38] <_prasen__> without having any internet access
[15:38] <jdstrand> hangun: open the file in a text editor. put 'mount,' (don't forget the comma) anywhere within the '^mount-namespace-capture-helper (attach_disconnected) { ... }' stanza
[15:38] <ogra_> you would still have to pull the core snap once
[15:39] <_prasen__> though that would never practically happen
[15:39] <jdstrand> hangun: then use 'sudo apparmor_parser -r /path/to/file'
[15:40] <_prasen__> ogra : the classic confinement is related to this ?
[15:40] <ogra_> the classic confinement just means its a deb in a snap dress :)
[15:40] <_prasen__> that breaks the snap confinement tho, doesnt it
[15:40] <_prasen__> ?
[15:41] <ogra_> it behaves like a deb and has the same access to the system a deb has but you can use the advantage of snap packaging for it
[15:41] <ogra_> well, you declare it as "confinement: classic" in the snap metadata
[15:41] <_prasen__> yes
[15:41] <ogra_> so you told it to not use any of the actual confinement
[15:41] <_prasen__> yes
[15:42] <ogra_> it doesnt *break* it ... but you chose to not use it :)
[15:42] <_prasen__> even then it requires the context of snap core ?
[15:42] <_prasen__> ^ignore this then
[15:42] <ogra_> yes, it does
[15:42] <_prasen__> your last statement cleared that up
[15:42] <_prasen__> total nub at this.
[15:42] <ogra_> we all were once, no worries ;)
[15:43] <_prasen__> that gives me a boost
[15:43] <_prasen__> :D
[15:43] <ogra_> :)
[15:44] <ogra_> mvo, do we actually allow sideloading of the core snap for people without any internet access that just want to develop and test their own snaps locally ?
[15:45] <_prasen__> hey
[15:45] <_prasen__> how do we do that?
[15:45]  * ogra_ has never tried to sideload it before snapd initially installed it
[15:46] <ogra_> _prasen__, well, i dont know if your system would be set up properly afterwards, there is likely more store communication involved than just installing the core snap to have a proper setup ... which is why i pinged mvo
[15:47] <_prasen__> yes
[15:48] <ogra_> lets just wait til he finds time to answer and sees the ping :)
[15:49] <hangun> jdstrand:  following your guide, I added "mount" to snap-confine and then reload it.  snap install hello-world, then run hello-world, an error outputs: seccomp_load failed with -22 , abouting: invaild argument
[15:50] <_prasen__> it tries to "get" some more too
[15:50] <hangun> jdstrand: have to go to bed. it's midnight here
[15:51] <jdstrand> hangun: sounds like you maybe don't have seccomp enabled in your kernel or you have a too old libseccomp? again, this isn't really my area of expertise. You might want to send these questions to the devices@ mailing list (or use the porting guide (I don't have the url, perhaps someone here does?))
[15:51] <jdstrand> hangun: mailing list: https://lists.snapcraft.io/mailman/listinfo/devices
[15:52] <jdstrand> hangun: goodnight and good luck! :)
[15:52] <ogra_> hangun, jdstrand https://docs.ubuntu.com/core/en/guides/build-device/image-building
[15:53] <_prasen__> in the snapd.service file we have to set the path to the environment file
[15:53] <_prasen__> where we will set the env variables we want to export
[15:54] <jdstrand> ogra_: noted, thanks
[15:54] <_prasen__> ogra : any doc/resource where I can know more about it?
[15:54] <ogra_> _prasen__, you mean the environment (for a proxy) ? http://askubuntu.com/questions/764610/how-to-install-snap-packages-behind-web-proxy-on-ubuntu-16-04
[15:55] <_prasen__> talking precisely about tis link ;D
[15:56] <ogra_> _prasen__, note that this already points to "EnvironmentFile=/etc/environment"
[15:56] <ogra_> _prasen__, so whatever you add to /etc/environment will be used by snapd
[15:56] <_prasen__> where do I get to learn more about this?
[15:56] <_prasen__> currently i do this to set my https_proxy and http_proxy variables
[15:57] <ogra_> i guess the bug linked in the question above is the best you can get
[15:57] <_prasen__> okay
[15:57] <_prasen__> ty
[15:57] <_prasen__> ogra : savior man _/\_
[15:58] <ogra_> heh
[16:00] <mvo> ogra_: installing a core snap without internet should work if you ack the assertion for the core snap first and then install it
[16:00] <ogra_> how would he do that ack'ing ?
[16:00] <ogra_> is there anything interactive ?
[16:01]  * ogra_ would just have said --dangerous --devmode
[16:01] <ogra_> though i guess that would still try to access the store and install core frome there first ...
[16:01] <ogra_> *from
[16:03] <_prasen__> i guess --dangerous option is invalid with --devmode
[16:04] <ogra_> well, i think you dont need --devmode if using --dangerous, iirc --dangerous automatically sets --devmode nowadays
[16:04] <ogra_> (i'm a bit behind using snaps locally, i tebnd to use everything from the store nowadays)
[16:05] <_prasen__> I think --devmode pnly has to used if confinement is devmode
[16:05] <_prasen__> only*
[16:05] <stgraber> didrocks: hmm, could be a problem with the mirrors or maybe some kind of proxy between you and the server
[16:05] <stgraber> didrocks: is it still failing now?
[16:05] <_prasen__> if confinement is changed to strict
[16:06] <stgraber> (I'm trying on my laptop and it seems happy with images:ubuntu-core/16, currently downloading the image)
[16:06] <_prasen__> then we need to use the dangerous flag if our locally created snap isnt verified by the store
[16:06] <didrocks> stgraber: let me try
[16:07] <didrocks> stgraber: yes: images:ubuntu-core/16 still fails with the fingerprint thingy and images:ubuntu-core/16/amd64 gives Retrieving image: 100% (614.64MB/s)error: multipart: NextPart: EOF
[16:09] <stgraber> didrocks: oh, I didn't read your error too closely, it could actually be a problem with the legacy protocol for the image server. We actually have a change coming in the next LXD release to force change that protocol for everyone.
[16:09] <stgraber> didrocks: lxc remote remove images ; lxc remote add images http://images.linuxcontainers.org --protocol simplestreams
[16:10] <didrocks> stgraber: error: flag needs an argument: --protocol
[16:10] <stgraber> oh, oops
[16:10] <didrocks> ah error: Only https URLs are supported for simplestreams
[16:10] <didrocks> hum
[16:11] <stgraber> didrocks: oh, oops, that was meant to be https://
[16:11] <stgraber> didrocks: lxc remote remove images ; lxc remote add images https://images.linuxcontainers.org --protocol simplestreams
[16:12] <mup> PR snapd#2822 closed: interfaces: add a linux framebuffer interface <Created by femdom> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2822>
[16:12] <didrocks> stgraber: perfect! images:ubuntu-core/16 is now downloadable, thanks! :)
[16:12] <didrocks> stgraber: do you need a bug report for handling the transition if not already?
[16:12] <stgraber> didrocks: nah, the commit was already merged yesterday
[16:13] <stgraber> didrocks: I'll look into why the old protocol doesn't work though, you indeed would have needed to use images:ubuntu-core/16/amd64 for that, but it should still have worked...
[16:13] <didrocks> stgraber: ah ok, that's weird. Good hunt! Thanks for the help on unblocking me
[16:33] <zyga> re
[16:34] <mup> PR snapd#2871 closed: overlord/hookstate/ctlcmd: helper function for creating a deep copy of interface attributes <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2871>
[16:45] <jdstrand> roadmr: hi! can you sync r840 whenever it is convenient?
[16:47] <roadmr> jdstrand: sure! hello :)
[16:51] <zyga> roadmr: hey, long time no see
[16:51] <roadmr> hello zyga  :) how's it going?
[16:51] <roadmr> you've been super busy :)
[16:51] <zyga> roadmr: me? no I just work on night shifts ;-)
[16:52] <roadmr> you vampire :)
[16:52] <zyga> roadmr: it's been good, preparig to move back to Polad this summer, otherwise all good
[16:52] <roadmr> zyga: temporary move or for good?
[16:52] <zyga> roadmr: I may be in Canada this spring
[16:52] <zyga> roadmr: the only permanent move is when I go to the cementary ;)
[16:52] <zyga> roadmr: not sure, for now we need to move
[16:53] <roadmr> zyga: hehe :) ok, hope the move goes well, and the trip to Canada too! spring is nice if you manage to arrive after all the ice melts heh
[16:54] <genii> Not much ice this year so far
[16:54] <zyga> roadmr: I'm not sure if I'll go, or where the sprint is going to be even
[16:54] <roadmr> zyga: well, it'll all become clearer in the coming weeks :)
[16:55] <roadmr> genii: true, I've seen worse. I expect a quick thaw this year
[16:57] <genii> roadmr: In fact, it's like 9C out right now here in Toronto, Wed-Thur up to 15C
[16:57] <roadmr> genii: really? wow, thanks to climate change Toronto is now a tropical city
[16:57] <genii> Heh, almost
[16:58] <roadmr> genii: we're *just* below zero in Montreal.
[17:00] <jdstrand> roadmr: thanks!
[17:12] <noise][> FYI, we are experiencing an outage of the snap download service, see http://status.snapcraft.io/ for status updates
[17:19] <EEight> jdstrand: I didn't want to involve the application name of the company in the mailing-list discussion...
[17:19] <jdstrand> davidcalle: ping re https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/> html is rc5 but pdf is rc6
[17:19] <EEight> I guess it is not possible to modify your post?
[17:20] <jdstrand> EEight: I'm sorry :( the name is an important part of the conversation so I referenced it
[17:20] <jdstrand> niemeyer: ^
[17:20] <jdstrand> niemeyer: is there anything we can do to the mailing list archive (I'm not an admin of the list)
[17:21] <niemeyer> Let me see
[17:22] <EEight> niemeyer: the actual post is: https://lists.ubuntu.com/archives/snapcraft/2017-February/003363.html
[17:23] <niemeyer> There's apparently no way.. I'll have to reach out to our internal support so they can edit the offending post manually
[17:24] <EEight> Is there a form to do that, because there is a risk that Google will show this post when people look for Bayam and security + children = bad
[17:26] <jdstrand> EEight: no form. niemeyer is reaching out now
[17:27] <EEight> niemeyer: thank you very much for this
[17:27] <EEight> jdstrand: I now understand why it's not connected (camera) out-of-the-box
[17:27] <jdstrand> I apologize again. I didn't think it was a problem since it was discussed here
[17:27] <niemeyer> EEight: Done, should be done in the next 24h
[17:27] <EEight> you guys rocks!
[17:28] <niemeyer> EEight: Sorry for the trouble
[17:28] <jdstrand> niemeyer: thanks for taking care of that
[17:28] <niemeyer> EEight: As a side note, you just associated the company name with security in the public logs of this channel
[17:28] <EEight> And lost my job
[17:29] <EEight> I have a plan B, making breads
[17:29] <EEight> No worries for me
[17:29] <niemeyer> :)
[17:29] <niemeyer> It's not a bad plan :)
[17:30] <EEight> Well I should begin to work on it...
[17:33] <EEight> And for the record (and public log) I was talking about the leaf: http://chiap-hup.com/bayam-bulat-0501/ ;)
[18:06] <zyga> Pharaoh_Atem: hey
[18:07] <zyga> Pharaoh_Atem: any chance you use a 16.10 machine to develop base snaps?
[18:53] <joedborg> hey all
[18:53] <joedborg> I'm getting `unusual mode 'rwxr-xr-x' for symlink` errors from ubuntu store when i push a snap build
[18:53] <joedborg> not sure what's unusual about that?
[18:55] <jdstrand> nessita: hey, several hours ago I rejected https://myapps.developer.ubuntu.com/dev/click-apps/6203/rev/6/, but r7 never underwent auto-review and is in 'Task state unknown'
[18:55] <nessita> jdstrand, checking
[18:59] <nessita> still checking
[19:01] <qengho> joedborg: sounds fishy. symlinks don't have their own modes, iirc.  $ find snap prime stage -type l -ls
[19:02] <joedborg> qengho: yeah, i've looked at them in the prime dir, because the full output lists each one
[19:03] <nessita> jdstrand, I rerun the review task, is Manual review pending
[19:03] <joedborg> qengho: and they all look legit, as expected all of the permissions are inherited
[19:03] <jdstrand> nessita: thanks!
[19:04] <nessita> jdstrand, thanks for reporting!
[19:04] <jdstrand> np :)
[19:05] <qengho> joedborg: If you have a URL someone can look at, at https://myapps.developer.ubuntu.com/ , then that might help someone who knows.
[19:06] <joedborg> qengho: https://myapps.developer.ubuntu.com/dev/click-apps/6896/rev/2/
[19:06] <joedborg> qengho: I've submitted for manual review - but I don't understand why symlinks are a build failure - perhaps it's a bug
[19:55] <Pharaoh_Atem> zyga: I don't have a 16.10 machine on hand, but I can set up one, why?
[19:56] <zyga> Pharaoh_Atem: no, just curious
[19:56] <zyga> (no need to set one up)
[20:05] <mup> PR snapcraft#1157 opened: repo: support versioned stage-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1157>
[20:50] <jdstrand> ogra_: hey, just noticed that pc-kernel is way out of date too in all channels
[20:51] <jdstrand> ogra_: and thank you for the bbb update!
[21:27] <cory_fu> elopio: Can you take a look at https://github.com/travis-ci/travis-ci/issues/7318#issuecomment-279860608 and tell me if that's feasible?  Could we fix the snap issue in travis using root inside whatever container they're using?
[21:28] <cory_fu> It seems to me like it would depend on the kernel of the host system?
[21:30] <devil> anyone has a hint for some documentaion on snap security measures?
[21:31] <jdstrand> devil: https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
[21:31] <jdstrand> devil: but read the PDF instead of the html. the html is out of date for some reason
[21:31] <jdstrand> davidcalle: ping ^
[21:31] <devil> jdstrand: thanks. writing an article on security of flatpak and snap
[21:31] <davidcalle> jdstrand: looking
[21:32] <jdstrand> davidcalle: html says rc5 but pdf is rc6
[21:32] <jdstrand> davidcalle: google doc is also rc6
[21:33] <mup> Bug #1666690 opened: Dependency issues when sharing a library through content interface <Snappy:New> <https://launchpad.net/bugs/1666690>
[21:33] <davidcalle> jdstrand: sorry I missed your pings earlier, I think we need to get rid of the HTML version and stick to the PDF, the CMS is not maintained anymore (we are moving out of it page by page) and I'm having issues with publications
[21:33] <davidcalle> jdstrand: how would you feel about only publishing the PDF?
[21:34] <jdstrand> davidcalle: that is fine with me since it means it is easier to be up to date, but, like before, I'm not the main consumer of this
[21:34] <jdstrand> davidcalle: iirc, people wanted the pdf, then they didn't, then now they do
[21:35] <davidcalle> jdstrand: PDF it is then, I'll fight some more with the page to replace the content by an introduction to the whitepaper, then the link. Tomorrow, though.
[21:38] <jdstrand> devil: in addition to that whitepaper (which has a slant towards Ubuntu Core as opposed to classic distributions), you might also want to look at https://github.com/snapcore/snapd/wiki/Interfaces, https://github.com/snapcore/snapd/wiki/Security and https://github.com/snapcore/snapd/wiki/snap-confine-Overview
[21:38] <jdstrand> devil: there is a lot of stuff in https://github.com/snapcore/snapd/wiki
[21:39] <devil> jdstrand: thanks again
[21:39] <jdstrand> np
[21:39] <jdstrand> davidcalle: thanks
[21:39] <devil> what I am particularly interested in is the sandboxing mechanisms
[21:40] <jdstrand> devil: the whitepaper gets into that and so do the specific wiki pages
[21:41] <devil> jdstrand: ok, that'll keep me busy for a while
[21:41] <jdstrand> but there is other info that is related or may give context in the other parts of the wiki
[21:43] <AlbertA> Hi snappy team :) so we've been playing around with content interface as a way to share libraries among snaps, however there are issues concerning dependencies.
[21:43] <AlbertA> we've outlined the problems in the bug: https://bugs.launchpad.net/snappy/+bug/1666690
[21:43] <mup> Bug #1666690: Dependency issues when sharing a library through content interface <Snappy:New> <https://launchpad.net/bugs/1666690>
[21:43] <AlbertA> has there been any talk about potential solutions to those problems?
[21:59] <bdmurray> Is bug 1665756 fixed in snappy core?
[21:59] <mup> Bug #1665756: environment variable setting issue <Snappy:Fix Committed> <https://launchpad.net/bugs/1665756>
[22:00] <bdmurray> Or would it be fixed in snapcraft?
[22:01] <ogra_> bdmurray, likely snapcraft
[22:01] <ogra_> bdmurray, did you see my ping in #ubuntu-bugs from today btw ?
[22:02] <bdmurray> ogra_: How can I run the latest snapcraft? I did see your ping.
[22:03] <ogra_> not sure if the latest did already make it to proposed
[22:03] <ogra_> in any case you can clone the branch from github and just run ./snapcraft in there i think
[22:06] <ogra_> jdstrand, pc-kernel is kind of kernel team's thing to release, i pinged bjf before about them only releasing to beta, not sure how we can fix that (note that we cant release pi kernels at all to stable since we cant update /boot from the gadget snaps yet)
[22:06] <jdstrand> ogra_: ok, thanks
[22:07] <ogra_> jdstrand, (teh pi kernels depend on having the devicetrees in the gadget ... and also usually require new bootloader blobs for major version bumps of the kernel)
[22:07] <ogra_> i'm bumping the bbb kernel now though, thanks for the ping :)
[22:19]  * zyga EODs
[22:19] <zyga> good night everyone
[22:27] <mhall119> devil: ping
[22:27] <devil> mhall119: pong
[22:29] <mhall119> devil: hey, I just wanted to offer to answer any questions you had, or help with your article when it comes to the snaps part (I'm not as familiar with the flatpak side)
[22:30] <mhall119> I'm a community manager here at Canonical
[22:31] <devil> mhall119: thanks for the offer, I will come back to it if I have questions
[22:31] <mhall119> no problem, I look forward to reading it :)
[22:32] <devil> it's gonna be in German and international linux print mags in ~2-3 months. I can point you to it when it hits market
[22:36] <mhall119> ah, thanks. In that case I can answer any questions, but I won't be any help reviewing the german text :)
[22:37] <mhall119> we do have people who can, if you'd like a review before it goes to print
[22:37] <mhall119> but sadly, I myself am mono-lingual
[22:38] <devil> mhall119: I am pretty well informed, because I wrote on the topic before, as these projects are in rapid developement, I just want to get an as recent as possible look on the security models