=== chihchun_afk is now known as chihchun
[05:16] <kyrofa> liuxg, did you ever get those packaging problems resolved?
[05:17] <kyrofa> liuxg, I seem to be running into a 401 when trying to install my just-published .snap
[05:17] <liuxg> kyrofa, it is very late for you, right? so far, it is fine for me.
[05:17] <kyrofa> liuxg, heh, yeah we switched places :)
[05:17] <kyrofa> liuxg, and you didn't need to do anything?
[05:17] <liuxg> kyrofa, yeah, I talked to the online service team, and they helped me to configure sth at the backend. The the problem disappeared.
[05:18] <kyrofa> liuxg, bueno etc.? Nothing you could walk me through, I suppose?
[05:18] <liuxg> kyrofa, for now, for each snap app, I need to talk to matiasb to help to configure. they are trying to solve the problem.
[05:19] <liuxg> kyrofa, yeah, bueno's team is responsible for it.
[05:19] <kyrofa> liuxg, that's too bad-- it seems pretty broken
[05:20] <liuxg> kyrofa, yes, I just got my 3 snaps published. he manually fine-tuned something for me.
[05:20] <kyrofa> liuxg, alright I'll ping matiasb in the morning, then
[05:20] <kyrofa> liuxg, thanks for the advice :)
[05:20] <liuxg> kyrofa, late on, he said that it would be automatic. it is really annoying
[05:21] <kyrofa> liuxg, yeah. Growing pains I guess :)
[05:21] <liuxg> kyrofa, yes, it seems that is the only way. I think you probably need to go to bed. it is really too late for you.
[05:21] <kyrofa> liuxg, great minds think alike ;)
[05:21] <kyrofa> liuxg, have a great day!
[05:22] <liuxg> kyrofa, by the way, thanks for your help to review my slides. I really learned a lot from you!
[05:22] <liuxg> kyrofa, have a good night :)
[05:22] <kyrofa> liuxg, my pleasure :)
[05:22] <kyrofa> liuxg, night!
[05:22] <miken> kyrofa: I can push the right button if you need it...
[05:23] <miken> But right, if it's that late, sleep and have it done in the morning :)
[08:10] <fgimenez> good morning
[08:42] <LefterisJP> hey guys, how can one clean the output of `sudo snappy-debug.security scanlog`? It has irrelevant warnings that i fixed days ago and takes quite some time to reach the end :P
[09:28] <robert_ancell> mvo, what is the correct way to search for snappy packages? The REST API for snapd doesn't seem to have any search functionality, but the command line tool does (I think it goes directly to search.apps.ubuntu.com)
[10:06] <JamesTait> Good morning all!  Happy Wednesday, and happy Penguin Awareness Day! 😃
[10:21] <blr> JamesTait: sadly, our yellow eyed penguins in Dunedin are not doing particulary well :(
[10:31] <JamesTait> blr, how so?
[12:39] <kyrofa> Good morning
[12:46] <kyrofa> LefterisJP, truncate your syslog
[12:56] <kyrofa> mvo, I'd like to get an all snaps image on my rpi2 (that's where I can use classic, right?). How do I go about that?
[13:11] <mvo> kyrofa: its here http://people.canonical.com/~mvo/all-snaps/
[13:15] <kyrofa> Thanks mvo :) . Booting now
[13:23] <kyrofa> mvo, another question: I know that ubuntu-core itself is automatically updated, but does is _ever_ .snap automatically updated by default?
[13:23] <kyrofa> s/ever/every/
[13:24] <kyrofa> mvo, I think the answer is "yes" but I want to make sure. Other .snaps aren't updated enough for me to know from experience, heh
[13:29] <vir17> hi, i am new here. I am interested to learn more about snappy for things. Any good tutorials out there?
[13:29] <kyrofa> vir17, welcome! Start here: https://developer.ubuntu.com/en/snappy/ :)
[13:32] <vir17> thank you kyrofa , I have already read the information of this link,thank you, I want more of a guide/article explaining a real concept so I can follow the steps and learn in the process
[13:32] <vir17> if anyone is aware of something like this
[13:32] <kyrofa> vir17, have you visited https://developer.ubuntu.com/en/snappy/build-apps/ then?
[13:35] <LefterisJP> kyrofa: how can I truncate syslog in snappy? Doing `sudo cat /dev/null > /var/log/syslog` gives me a permission denied error. Also tried to use the systemd journal way with `journalctl --vacuum-time=1m" but that had no effect.
[13:36] <vir17> thanks kyrofa i will try that
[13:38] <kyrofa> LefterisJP, try `sudo dd if=/dev/null of=/var/log/syslog`
[13:39] <kyrofa> vir17, note that link was linked from the original page I shared, near the top (named "Build apps")
[13:40] <mvo> kyrofa: yes :) every snap auto-udpates
[13:40] <kyrofa> mvo, excellent, thank you for the verification
[13:41] <LefterisJP> kyrofa: thanks! it worked. Curious why cat did not work.
[13:42] <kyrofa> LefterisJP, redirects don't get your privileges
[13:42] <kyrofa> LefterisJP, so you could also have sudo su - and THEN done the redirect
[13:43] <kyrofa> LefterisJP, so the cat was happening with sudo, but the redirection was happening as you. Make sense?
=== devil is now known as Guest77896
[13:54] <LefterisJP> kyrofa: yeah it does, thank you - should have thought about that :)
[13:55] <kyrofa> LefterisJP, any time :)
=== retrack is now known as Guest3469
=== Michaela is now known as Mikaela
=== LarreaMikel1 is now known as LarreaMikel
[14:06] <jdstrand> LefterisJP: hey, fyi it is pulling from /var/log/syslog. the tool itself could definitely be smarter, but a log rotation would also do the trick
[14:06] <kyrofa> jdstrand, question for you
[14:06] <jdstrand> kyrofa: hey
[14:07] <kyrofa> jdstrand, there are some applications that host a vast amount of data (e.g. owncloud)
[14:07] <jdstrand> mvo: not sure if you saw it, but you should have gotten an email regarding mksquashfs/unsquashfs hashes. I don't need an answer now, just want to make sure you saw it
[14:08] <kyrofa> jdstrand, such collections of data really shouldn't be copied upon upgrade, etc.
[14:09]  * jdstrand is waiting for the question
[14:09] <kyrofa> jdstrand, that also leads to another point: say you're running on the rpi2, but want to host owncloud's data on an external hard drive instead of in SNAP_APP_DATA_PATH or something. Is that a problem you're considering as far as hw-assign goes?
[14:09] <kyrofa> jdstrand, or capabilities, I guess
[14:10] <LefterisJP> kyrofa: jdstrand: I have to go right now, be back in 1 hour or so, but I have the exact same problem with the framework I am developing. The data (the blockchain) is stored in $SNAP_APP_DATA_PATH and is copied with each upgrade, which is not a good solution (it starts to become too big). Wonder how it could be done better.
[14:10] <jdstrand> on Touch the data dirs are not versioned. I initially suggested we do the same for snappy, but it was decided that snappy should have versioned data dirs to support rollbacks (which isn't supported on Touch)
[14:11] <kyrofa> jdstrand, indeed, and that's actually awesome for the database i'm hosting there
[14:11] <kyrofa> jdstrand, but I feel like we're missing that other capability
[14:11] <jdstrand> which other capability-- the hard drive or having some sort of optional "share data between versions" or something?
[14:12] <kyrofa> jdstrand, the share data bit, but in my head they're the same problem-- store data outside of the typical snappy paths
[14:13] <jdstrand> I think the sharing data between versions is a conversation point for the snappy architects. It could perhaps start as a bug
[14:14] <jdstrand> the hard drive point actually isn't a hard drive device-- it is just an alternate directory. I don't see why that couldn't be handled by capabilities
[14:14]  * jdstrand jots that down on the list of things to bring up with zyga
[14:16] <kyrofa> Alright, thanks jdstrand!
[14:17] <jdstrand> kyrofa: I can say that the thing with rollbacks is, aiui, you don't have infinite number of them. you get one. that isn't exactly what you'd like I know, but at least there is an upper limit
[14:17] <kyrofa> jdstrand, oh interesting, actually I didn't know that. Are versions older than "the previous one" cleaned up, then?
[14:18] <jdstrand> maybe there is an opt in behavior there. do the copy, and if you don't rollback, get rid of the old data dir
[14:18] <jdstrand> kyrofa: I'm not sure what the implementation does now, but aiui, that is the plan. perhaps mvo can shed more light on that
[14:30] <kyrofa> elopio, you may still be in the QA call, eh?
[14:30] <mvo> kyrofa: sorry, in a meeting right now, I can reply in a bit but I can't read backlog currently
[14:31] <kyrofa> mvo, no problem
[14:33] <kyrofa> elopio, ping me if you want to standup :)
[14:48] <kyrofa> mvo when you get a minute, any idea why `make` would be segfaulting in the classic dimension?
[14:51] <mvo> kyrofa: its doing what - segfaulting? huuuu
[14:52] <kyrofa> mvo yeah even just make clean
[14:52] <mvo> kyrofa: that sounds more like a bad sd card or something, do you have a backtrace?
[14:53] <elopio> kyrofa: sorry, my other meeting ran long.
[14:53] <elopio> kyrofa: I don't want to stand up, my throat hurts. I think I've already said today all the words I usually say in a week.
[14:53] <kyrofa> mvo, http://pastebin.ubuntu.com/14582510/ with strace
[14:53] <elopio> kyrofa: do you need something from me for today?
[14:54] <kyrofa> elopio, no problem :)
[14:54] <kyrofa> elopio, and no, you're good!
[14:55] <elopio> :)
[14:55] <mvo> kyrofa: thats on the rpi2 I assume?
[14:55] <kyrofa> mvo, indeed
[14:55] <kyrofa> mvo, never seen this before
[14:55] <mvo> kyrofa: I suspect some HW issue, but I will try to reproduce, just need to fiddle with the serial cable of my rpi2 to get it going again
[14:56] <kyrofa> mvo, thanks for the help! Yeah the only thing I can get out of make is --help. Even -v segfaults. But I was able to setup classic and install snapcraft and everything without issue
[15:00] <mvo> interessting
[15:22] <mvo> kyrofa: http://paste.ubuntu.com/14582659/ - works here :/
[15:22] <kyrofa> mvo, what on earth
[15:23] <mvo> kyrofa: let me try to upgrade everything so that I'm really on the latest everything
[15:24] <kyrofa> mvo I don't see any real problem in the strace either-- it lists the entries in /dev a few times and then closes the /dev fd right before it segfaults
[15:26] <mvo> kyrofa: does gdb show anything meaningful? but before that, can you try "sudo apt install --reinstall make" ?
[15:26] <mvo> kyrofa: and maybe its dependencies, I still suspect some sd card issue
[15:28] <kyrofa> mvo, no gdb is useless: http://pastebin.ubuntu.com/14582689/
[15:28] <kyrofa> mvo, reinstalling make doesn't help
[15:28] <kyrofa> mvo I might have another card here I can try
[15:28] <kyrofa> mvo I hate hardware sometimes :P
[15:31] <mvo> kyrofa: worth a shot to try with a different sd card I would say, we had a bunch of sd card issues when testing with the bbb, quite a few issues were faulty HW
[15:35] <opmodoro> Hello, I'm building my first snap using go as in the tutorial. When I install it apparmor deny it asking for capability net_admin, if I add it in the yaml it won't install with an error. Any tought?
[15:36] <kyrofa> opmodoro, what is your snap doing?
[15:36] <opmodoro> actually a simple http server at 127.0.0.1:8080
[15:37] <kyrofa> opmodoro, what version of Ubuntu Core are you running?
[15:38] <opmodoro> uhm, I'm on vagrant box ubuntu-core-edge-15
[15:39] <kyrofa> opmodoro, to double check, `cat /etc/lsb-release`. It's 15.04?
[15:40] <opmodoro> kyrofa, yes 15.04 vivid
[15:41] <kyrofa> opmodoro, can you please pastebin the apparmor denial you're seeing, as well as your snapcraft YAML (assuming you're using snapcraft)?
[15:41] <opmodoro> ok, just a moment
[15:42] <jdstrand> opmodoro, kyrofa: that is a harmless denial
[15:42] <jdstrand> if you use snappy-debug.security scanlog, it will tell you that
[15:43] <jdstrand> https://launchpad.net/bugs/1465724
[15:43] <ubottu> Launchpad bug 1465724 in Snappy "net_admin apparmor denial when using Go" [High,Confirmed]
[15:43] <opmodoro> jdstrand, kyofa, I found something similar on launchpad. However logs are not helping and netstat -nat doesn't show it
[15:43] <kyrofa> jdstrand, oh, nice. What's being denied there? What does net-admin give you?
[15:44] <kyrofa> opmodoro, he's saying you should be able to safely ignore it-- it shouldn't be affecting your .snap
[15:44] <jdstrand> kyrofa: it is a kernel bug. its logic is wrong when trying to see if something has access to some proc file iirc
[15:44] <opmodoro> jdstrand, I do not have such command
[15:44] <jdstrand> opmodoro: sudo snappy install snappy-debug
[15:44] <kyrofa> opmodoro, `sudo snappy install snappy-debug`. Very handy tool
[15:44] <opmodoro> great thanks!
[15:45] <kyrofa> Thanks for jumping in there jdstrand :)
[15:45] <jdstrand> np :)
[15:45] <tzununbekov_> asac, jdstrand hi, have you received our message on mail?
[15:46] <jdstrand> tzununbekov_: it went through, yes. I didn't respond since we chatted on irc and was waiting for the conversation to pickup
[16:07] <opmodoro> kyrofa, jdstrand thank you! It is working now. I've added the correct caps now. Best
[16:17] <kyrofa> opmodoro, excellent!
[16:20] <kyrofa> mvo, alright, trying with a second SD card
[16:20]  * kyrofa crosses his fingers
[16:22] <Guest35435> quick question, there's no way to add repositories like Deluge or anything right now yeah?
[16:25] <ogra_> Guest35435, you can use an lxc container, a docker container or the classic mode to use debs .... in plain snappy there is no deb support though
[16:25] <ogra_> you would rather use snapcraft with the copy plugin to create a snap of your project instead
[16:27] <Guest35435> okkkk thanks! I'll look into all that
[16:36] <kyrofa> mvo, segfault again
[16:37] <kyrofa> sergiusens, did you try the classic dimension on the rpi2?
[16:42] <elopio> mvo: are you still working? I wanted to ask you about this https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/update_os_test.go#L45
[16:42] <elopio> but if it's too late for you, I can do it earlier tomorrow.
[16:48] <mvo> elopio: sure, still here
[16:48] <kyrofa> elopio, can you take another quick look at https://github.com/ubuntu-core/snapcraft/pull/241 when you're able?
[16:48] <mvo> elopio: just addressed your pull request comments (thanks for those!)
[16:48] <elopio> mvo: so, when I run snappy update, where are the bootloader files that will be used after the reboot?
[16:48] <mvo> elopio: what do you want to know in particular? the new syle boot dir is simple on grub: its empty (except for the UEFI stuff that is mandatory)
[16:49] <mvo> elopio: in uboot its /boot/uboot/snap-blob-name/{vmlinuz,initrd.img}
[16:49] <elopio> mvo: yes, uboot case.
[16:49] <elopio> mvo: so, after the new snaps are installed, they overwrite the system boot. That's all I needed to know.
[16:50] <mvo> elopio: http://paste.ubuntu.com/14583211/
[16:50] <elopio> I'll make the test pass on rpi.
[16:51] <elopio> kyrofa: ack
[16:52] <kyrofa> elopio, make sure the code style is what you were going for
[16:52] <mvo> elopio: here are the vars used: http://paste.ubuntu.com/14583223/
[16:52] <mvo> elopio: \o/
[16:52] <mvo> elopio: let me know if there is anything else you need to know
=== tasdomas` is now known as tasdomas
[16:56] <elopio> mvo: I got that workaround with the env vars covered on my pull request from monday.
[16:57] <elopio> mvo: maybe you can look at it tomorrow. It's simple, and m-o is happy: https://github.com/ubuntu-core/snappy/pull/343
[17:00] <LefterisJP> guys is there any way to add another editor instead of VI inside snappy? For debugging purposes I need to be editing different files and then rerun snap services, but my VI editing skills are a bit ... well ..
[17:00] <LefterisJP> (I am an emacs user)
[17:00] <ogra_> just create an emacs snap then ?
[17:01] <ogra_> (or use the classic mode)
[17:01] <elopio> LefterisJP: +1 to the emacs snap. I would like your snap very much.
[17:02] <elopio> I'm wondering how do we allow a snap to read all files, and write all the writable files, like an emacs snap would need.
[17:02] <ogra_> (we might end up to even drop vi from the core OS at some point)
[17:02] <ogra_> elopio, probably simply via sideloading :)
[17:03]  * ogra_ has a htop snap, a debootstrap and a wget snap he uses like that
[17:03] <mvo> elopio: sure
[17:03] <ogra_> i.e. http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/files ...
[17:03] <mvo> ogra_: aha, did you see all my messages about all-snaps & arm64 from the other day ?
[17:04] <ogra_> mvo, hmm, perhaps not ... IRC ? mail ?
[17:04] <mvo> ogra_: irc
[17:04] <elopio> ogra_: why do you need the wget snap sideloaded? It seems it could be a good citizen touching only its dirs.
[17:04] <mvo> ogra_: I created an arm64 alls-snap image but can't test it because i have no board
=== rickspencer3_ is now known as rickspencer3
[17:05] <ogra_> elopio, because it is annoying to fish your files out of SNAP_APP_USER_DATA_PATH
[17:05] <ogra_> mvo, damn and i didnt bring mine to the UbuCon
[17:05] <mvo> ogra_: if you have the HW maybe we can talk about this tomorrow?
[17:05] <mvo> ogra_: oh, you are at ubucon, ok
[17:05] <mvo> ogra_: no worries then, its not urgent
[17:05] <elopio> ogra_: maybe a link to ~/Downloads.
[17:05] <ogra_> yeah, sorry .... i was pondering to bring it with me but found it to risky to lose it
[17:06] <mvo> ogra_: I guess all my irc message will show up on your other client when you are back home ;)
[17:06] <ogra_> hmm, let me kill that
[17:06] <ogra_> (and yes, you might be right)
[17:09] <fgimenez> elopio, about https://travis-ci.org/ubuntu-core/snapcraft/jobs/103540103, it seems that it's trying to send the info stored under /home/ubuntu, the path where the tests were executed inside the container
[17:09] <fgimenez> elopio, but outside the container that route doesn't seem to exist, maybe you should execute coveralls inside the container? or change the path in the report?
[17:09] <elopio> fgimenez: I mount the path, so it's the same dir in the container and in the host.
[17:09] <elopio> *should be. At some point it worked.
[17:10] <elopio> I tried executing coveralls inside the container, and it complained about many things. I can retry that.
[17:11] <elopio> ahh, maybe there's something new here. It didn't seem to link the coverage with the absolute path before.
[17:12] <fgimenez> elopio, now when it sends the report it looks for paths like /home/ubuntu/snapcraft/__init__.py, as in "No source for /home/ubuntu/snapcraft/__init__.py"
[17:13] <elopio> yeah, that's a good clue.
[17:18] <fgimenez> leaving, have a nice day o/
[17:20] <kyrofa> mvo, FYI, installing regular old Ubuntu on the rpi2, make works fine
[17:38] <sergiusens> kyrofa, yes, I did try the classic dimension, it is how I built the face stuff
[17:38] <sergiusens>  ogra_, mvo I think that olli is bringing one for me here, I can lend it while here
[17:38] <Lefteris`> elopio: ogra_: yeah an emacs sideloaded snapp would be perfect for debuging and dev purposes. Should not be that hard to make.
[17:38] <kyrofa> sergiusens, yeah that's what I thought. It's odd-- I tried it twice, on two different SD cards, and make was segfaulting
[17:38] <kyrofa> sergiusens, I finally just installed Ubuntu on one of the SD cards and now it works fine
[17:39] <kyrofa> sergiusens, no clue what's happening
[17:39] <kyrofa> sergiusens, it works for both you and mvo
[17:39] <elopio> Lefteris`: it would be fun to explore the integration with elpa.
[17:39] <elopio> how a snap can install "plugins".
[17:43] <Lefteris`> :)
[17:45] <sergiusens> kyrofa, is your clock bonkers?
[17:46] <kyrofa> sergiusens, currently it's UTC. I didn't check in ubuntu core though-- you think that would cause `make -v` to segfault?
[17:48] <sergiusens> kyrofa, no, not really
[17:50] <kyrofa> sergiusens, yeah... a head scratcher for sure. I didn't see anything odd here-- you? http://pastebin.ubuntu.com/14582510/
[17:53] <sergiusens> kyrofa, try make on something simpler. Why does it stat all the dev nodes?
[17:53] <kyrofa> sergiusens, that was only a make clean-- a single rm -rf call
[17:53] <kyrofa> sergiusens, I got the same thing from `make -v`
[17:54] <kyrofa> sergiusens, which obviously does _nothing_
[17:54] <kyrofa> sergiusens, great question regarding the stat. No clue
[17:54] <sergiusens> ah, weird; do you have anything strange hooked up to your device which would cause the stat call to die?
[17:54] <kyrofa> sergiusens, no, and they aren't dying-- they're returning 0 (no error)
[17:55] <kyrofa> sergiusens, hmm... actually I wonder now if the piglow might have something to do with it
[17:55] <kyrofa> sergiusens, that's the only thing hooked up. Do you have one hooked up?
[17:55] <sergiusens> kyrofa, classic is a container iirc, so accessing things that are denied might cause unexpected behavior on old software
[17:55] <sergiusens> kyrofa, no, I have  a barebones pi2; from before the merch was avail
[17:56] <kyrofa> Hmmmmm.... mvo how about you?
[17:56] <kyrofa> sergiusens, after I finish building here I'll try taking it off and trying again
[17:56] <sergiusens> kyrofa, he has a regular one as well iirc
[17:56] <kyrofa> sergiusens, but yeah... make does more than I thought, apparently :P
[18:08] <sergiusens> ogra_, can you sponsor an upload for me?
[18:10] <kyrofa> elopio, can you verify that I can set bug #1534802 to Fix Committed?
[18:10] <ubottu> bug 1534802 in Snapcraft "gopaste example fails because sqlite tries to chown" [Undecided,New] https://launchpad.net/bugs/1534802
[18:12] <enoch85> kyrofa, hey, now I'm online
[18:12] <kyrofa> Hey enoch85 :)
[18:12] <elopio> kyrofa: nop, the bug is still there. What I made was a workaround to get the example running.
[18:12] <kyrofa> elopio, ah, okay
[18:13] <elopio> maybe a better name for the bug would be good.
=== xnox_ is now known as xnox
=== dasjoe_ is now known as dasjoe
=== benoitc_ is now known as benoitc
[18:36] <blr> JamesTait: they're endangered, and their numbers are declining... predation from introduced species (stoats) and apparently climate change is affecting fish stocks.
[18:59] <JamesTait> blr :(
[19:18] <vir17> can I use python to create snaps?
[19:30] <kyrofa> vir17, you mean can python be used within a .snap?
[19:30] <vir17> yes
[19:30] <kyrofa> vir17, certainly
[19:31] <kyrofa> There are py2 and py3 examples here: https://github.com/ubuntu-core/snapcraft/tree/1.x/examples
[19:32] <vir17> thanks kyrofa very useful :)
[19:41] <fazer> can someone look at this please: https://github.com/ubuntu-core/snapcraft/pull/245
[19:42] <kyrofa> fazer, I've gotcha
[19:42] <kyrofa> Sorry for the delay
[19:42] <fazer> thanks
[19:42] <fazer> no problem
[19:42] <kyrofa> fazer, looks like you got the squash, though?
[19:43] <fazer> kyrofa, yup, it was pretty painful the first time. But the second was better. I understood what exactly I was doing, better.
[19:44] <kyrofa> fazer, excellent! Yeah this looks great
[19:49] <fazer> kyrofa thanks. much appreciated
[19:52] <kyrofa> fazer, no problem, you're getting pretty good at jumping through the hoops!
[19:54] <kyrofa> elopio, I learned the downside of specifying multiple build threads all the time
[20:02] <kyrofa> Gaaah.... come on rpi2... you can do it...
=== chihchun is now known as chihchun_afk
[20:36] <kyrofa> elopio, I need a cluster of rpis just to build stuff
[20:52] <elopio> kyrofa: hah, but with a single thread isn't it just as slow?
[20:53] <kyrofa> elopio, well I'd bump it back up, duh :P
[20:53] <kyrofa> elopio, this has been running since this morning
[20:53] <elopio> I have a cluster of two rpis here :)
[20:54] <kyrofa> Hahaha
[20:54] <kyrofa> elopio, got a sec for a python question?
[20:54] <elopio> kyrofa: sure.
[20:55] <kyrofa> elopio, if your code is built using setuptools, is easy-install.pth required to run it?
[20:57] <elopio> ja, no idea. Maybe barry is around.
[20:57] <barry> heyho
[20:57] <kyrofa> Ah, barry was my backup plan
[20:57] <kyrofa> Hey barry!
[20:57] <barry> kyrofa: hi!
[20:57] <kyrofa> barry, I don't know anything about setuptools
[20:58] <barry> kyrofa: ok
[20:58] <kyrofa> barry, but I'm curious if easy-install.pth plays a role at runtime, or if it's more of a version manager. What happens if it's not there?
[20:59] <barry> kyrofa: where do you see easy-install.pth?  pth files are kind of an abomination ;)
[21:00] <barry> they hack the path in non-evident ways
[21:00] <kyrofa> barry, bug #1531570
[21:00] <ubottu> bug 1531570 in Snapcraft "Can't have two python3 parts using setuptools" [Undecided,New] https://launchpad.net/bugs/1531570
[21:00] <barry> looking
[21:00] <kyrofa> barry, yeah, and I'm wondering if it buys you anything in a .snap
[21:03] <barry> kyrofa: can you pastebin what's in that .pth file?  you should be able to delete it since it shouldn't be doing anything that isn't already set up (e.g. modifying sys.path, but .pth files can do other evil things).
[21:05] <kyrofa> barry, here's one of them: http://pastebin.ubuntu.com/14585410/
[21:05] <kyrofa> barry, and the other: http://pastebin.ubuntu.com/14585415/
[21:09] <barry> kyrofa: okay, i think i see what these are doing.  i don't think you strictly need the .pth files if you have control over the command line and can e.g. export PYTHONPATH=foo.egg:bar.egg
[21:10] <kyrofa> barry, alright, I'm experimenting now
[21:10] <kyrofa> barry, thank you for your help!
[21:10] <barry> essentially i think that's what this .pth file is doing-  putting some eggs on sys.path.  eggs essentially fancy zips that python can import from
[21:10] <barry> kyrofa: k, good luck!
[21:11] <kyrofa> So as long as they're in the path, it should work regardless
[21:11] <barry> right
[23:17] <elopio> I'm going to finish earlier today to attend a workshop about mqtt.
[23:18] <elopio> bbl
=== Guest77896 is now known as devil_