[03:54]  * kiall really hopes I havent found another eucalyptus bug ;) Metadata sent in via EC2 PHP SDK ends up as jibberish :/
[04:24] <kiall> <-- feels stupid ... needed tp base64_encode it ;)
[04:25] <kiall> (But - at least EC2 told me .. unlike ueca :P)
[06:10] <kiall> grr - UEC elastic IP "stuck" on an instances that no longer exists .. cant disassocate it :/
[07:04] <Makere> how do I remove the store-images from cloud and disk?
[11:13] <TritoLux_> Hello there, I upgraded my cloud from 10.04LTS to 10.10, nodes went fine, but the CLC is now extremely slow with high cpu usage, even when eucalyptus is shut down. It seems like if the kernel is not doing well. Did anybody experience the same here or is willing to point me to the right direction to solve this annoying problem please?
[11:15] <TritoLux_> If I run top, then all processes seem at 0%, but cpu usage is always between 10% and 50% anyway. The CLI is quite unresponsive and I cannot even troubleshoot well.
[11:18] <TritoLux_> ksoftirqd processes often reach 20%, it seems that the system is struggling
[11:22] <TritoLux_> the ubuntu forums are down at the moment, so there's not much room for investigation out there at the moment. any help here would be appreciated
[11:25] <kiall> TritoLux_, I havent updated from 10.04, but my 10.10 install is pretty responsive (unless i do loads of euca-get-consoleoutput's in a row .. where euca-cloud will chew 100%*Num of cores for a few mins!)...  Cant be of any real help tho .. sorry ;)
[11:27] <TritoLux_> thanks kiall, my problem persists even if eucalyptus is not running actually
[11:27] <kiall> Wait - the CLC is slow even when all euca services are stopped? It cant be UEC related then!
[11:27] <kiall> dooh .. beat me to it ;)
[11:27] <TritoLux_> I have no idea what is going wrong
[11:28] <TritoLux_> yes kiall, I just found out that it is UEC unrelated
[11:28] <TritoLux_> it took me ages to shut down eucalyptus though
[11:29] <kiall> I presume you didnt do any HW changes at the same time? and you've shut down everything you can in case its another service?
[11:30] <kiall> Beyond that .. it kinda has to be a kernel issue once you have everything off, and know the hardware's good..
[11:30] <TritoLux_> I still trying to understand what other service could be, but apart from ksoftirqd all other processes seem to be sleeping
[11:30] <TritoLux_> the HW is still the same, I performed an ssh upgrade
[11:31] <TritoLux_> the server is quite fast and it was running well with  10.04
[11:32] <kiall> I wonder if you had any 3rd party hardware drivers installed (RAID cards etc) that you may be using an open source alternative now?
[11:33] <TritoLux_> I had not installed any driver manually to be honest, I have an Areca controller that was automatically recognized flawlessly with 10.04
[11:33] <TritoLux_> and since the system starts, I guess that it was recognized on 10.10 as well
[11:34] <TritoLux_> hey wait a sec..
[11:35] <TritoLux_> it is apparently eucalyptus related
[11:35] <kiall> Humm? I thought euca was off?
[11:35] <TritoLux_> it just took more than 30 mins to shutdown the cloud
[11:35] <TritoLux_> but now the system is responsive again
[11:35] <TritoLux_> 99.9% idle
[11:35] <kiall> Oh - wow. that cant be right
[11:35] <kiall> anything in the logs between 30mins ago and now¿
[11:36] <TritoLux_> I'll try to see the logs now.. as I finally can access them
[11:41] <TritoLux_> I received a mail from the cloud saying: [FATAL] There is nothing to do here, since there are no nodes with any plugins.  Please refer to http://munin-monitoring.org/wiki/FAQ_no_graphs at /usr/share/munin/munin-html line 38
[11:42] <kiall> I was wondering why munin was a dep ;) .. but that *probably* shouldnt cause any major issues... nothing else?
[11:42] <TritoLux_> I'm checking
[11:43] <kiall> `tail -n 50 /var/log/eucalyptus/* | less` and done ;)
[11:44] <TritoLux_> I have many java cloud errors
[11:45] <kiall> Not sure .. I dont get many errors showing up in mine ..
[11:46] <TritoLux_> ERROR [TxHandle:New I/O server worker #1-7] javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Cannot open connection
[11:46] <TritoLux_> javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Cannot open connection
[11:46] <kiall> Cant connect the the database .. something must have mucked up during the upgrade
[11:47] <TritoLux_> to be honest, at the end of the CLC-CC-SC-Wlarus machine upgrade, I received some weird errors, such as:
[11:47] <TritoLux_> File descriptor 42 (/dev/pts/0) leaked on lvs invocation. Parent PID 3754: /bin/sh
[11:47] <TritoLux_>   /dev/etherd/e0.4p1: read failed after 0 of 4096 at 0: Input/output error
[11:47] <TritoLux_>   /dev/etherd/e0.5p1: read failed after 0 of 2048 at 0: Input/output error
[11:47] <TritoLux_>   /dev/etherd/e0.6p1: read failed after 0 of 4096 at 0: Input/output error
[11:47] <TritoLux_>   /dev/etherd/e0.6p2: open failed: No such device
[11:48] <kiall> looks like it was shutting down some EBS volume exports, or trying to?
[11:48] <TritoLux_> those are the only ones I saw, apart from a non fatal dhcpd3 failure
[11:49] <TritoLux_> the reasons I wanted to upgrade to 10.10 is actually because I suspected some AoE issues
[11:50] <kiall> humm ... anyway .. i've gotta run! good luck
[11:50] <TritoLux_> thanks kiall
[11:50] <kiall> (btw - its be 99% that failing to connect to the DB is your issue ...)
[11:51] <kiall> (assuming that log repeats a few times a min ...)
[11:51] <TritoLux_> yes, it's quite often
[11:51] <TritoLux_> what should I look for in order to troubleshoot this DB issue?
[11:53] <kiall> Honestly - Not sure .. still at the trial stage here :)
[11:53] <kiall> i'd check /var/lib/eucalyptus/db/ and find out how hsql or whatever its called works!
[12:00] <TritoLux_> ok thanks
[17:47] <TritoLux_> kiall, dunno if you are still there.. about the slow response issue after my maverick upgrade, the funny part is that if I reboot the server I have a slow system, but if I manage to stop eucalyptus and then I start it manually, then the system is responding fine. As if there is some conflict during startup.
[17:48] <TritoLux_> those db messages were only reported during the shut down process, which took ages, so the system was still looking for the db I guess
[17:50] <TritoLux_> why eucalyptus is slow at startup and whyh ittakes ages to be stopped.. that I dunno yet
[17:50] <TritoLux_> but it works fine if I manually start it again, really weird
[18:02] <TritoLux_> did anybody else experience the above slow response at startup?


[01:59] <pandaR> hello. i need to make the scroll bar of a qlist bigges so its easier to control with a touch screen. im using pyqt4. any idea?
[02:00] <tsimonq2> I'd consider pyqt4 deprecated. ;)
[02:01] <pandaR> well any idea how to do taht with pyqt5
[02:01] <tsimonq2> I'd have to reference the docs.
[02:21] <pandaR> if anyone intereste i made it
[02:21] <pandaR> i make it work just added a line:   self.setStyleSheet("QScrollBar:vertical { width: 50px; }")  where self is the main qwidget


[04:42] <DarkTrick> **Q**: What is a good way to migrate application settings from gconf to dconf?
[04:43] <DarkTrick> One specific problem: Ubuntu had a mapping layer for gconf-access, but it seems like the mapping differs between ubuntu versions. How do I tackle that?
[08:05] <utkarsh2102> hello, is there a way to get udebs from a PPA?
[08:06] <utkarsh2102> I tried using pull-ppa-udebs -a i386 --ppa utkarsh/multipath-tools-disable-fexceptions multipath-tools but that says no udebs found there, which probably means they're not built there in the first place?
[08:06] <utkarsh2102> is there a way to ensure that udebs are built in a PPA?
[08:55] <xnox> utkarsh2102:  for which release?
[08:58] <utkarsh2102> xnox: impish
[09:23] <xnox> utkarsh2102: all ppa's inherit allow/block-lists of packages to build from the parent ubuntu distribution. by default impish does not build udebs. If you want to build udebs for multipath-tools in your ppa, you need to change debian/rules to export DEB_BUILD_PROFILES=!noudeb
[09:23] <xnox> see mentions about this in dpkg uploads
[09:24] <xnox> utkarsh2102:  but note that this will still not quite result in having i386 d-i working at all..... may i ask what are you trying to achieve? cause for you to run i386 multipath-tools udeb i would expect you to rebuild it in a release that at least has i386 debian-installer.... like bionic
[09:28] <utkarsh2102> xnox: the ultimate goal that we have is to drop the delta that we've been carrying; this one: https://git.launchpad.net/~utkarsh/ubuntu/+source/multipath-tools/commit/?h=merge-multipath-tools-impish&id=920df384351ddc43bdef435643c47d5742537360.
[09:28] <utkarsh2102> so to check that we wanted a udeb to test on. I'll use ppc64el instead of i386, thanks, again!
[09:31] <xnox> utkarsh2102:  we do not make udebs in impish.
[09:31] <xnox> utkarsh2102:  you should not be testing any udebs from impish =)
[09:32] <xnox> utkarsh2102:  you can drop any delta that applies to udeb builds only..... since we don't build udebs anymore
[09:32] <utkarsh2102> xnox: aah! gotcha! that is perfect :)
[09:32] <utkarsh2102> cpaelzer^^ \o/
[09:33] <xnox> utkarsh2102: we do not have d-i anymore....
[09:35] <cpaelzer> xnox: legacy images stopped after focal right?
[09:35] <cpaelzer> or are they just better hidden and still needed?
[09:35] <xnox> cpaelzer:  we have not built legacy images since 20.04.1. Even .2 release does not have them....
[09:35] <cpaelzer> yep, ok that is what I see on the cdimage pages
[09:35] <xnox> cpaelzer:  checkout rmadison and note the lack of multipath udebs being built or produced.....
[09:36] <cpaelzer> xnox: well, that for eample still existed in groovy
[09:37] <xnox> but not in hirsute, nor impish.
[09:37] <cpaelzer> which confuses a bit, but probably only as carry over from focal
[09:37] <xnox> it took us some time to remove them all properly.
[09:37] <cpaelzer> indeed
[09:37] <cpaelzer> thanks for the hints xnox
[09:37] <xnox> but since the .udeb is not there for two releases now, it is gone =)
[09:37] <cpaelzer> once = accident, twice = gone :-P
[09:39] <utkarsh2102> indeed, multipath-udeb was last seen in groovy
[09:39] <utkarsh2102>  multipath-udeb | 0.8.4-4ubuntu2                 | groovy/universe/debian-installer
[09:39] <utkarsh2102> time to say bye-bye o/
[09:39] <utkarsh2102> thanks, xnox!
[12:59] <LocutusOfBorg> hello, anybody wants to discuss a glibc change for the syslog function?
[12:59] <LocutusOfBorg> I have a process reading /dev/log, but what happens, if the process reading it, stops or crashes for whatever reason, the whole system becomes stuck because syslog becomes blocking when the queue is full
[12:59] <LocutusOfBorg> I changed the syslog glibc socket to NONBLOCK and I fixed the issue
[13:00] <LocutusOfBorg> I would like to discuss it with some glibc-savvy people
[15:07] <smoser> bdmurray: any chance that you could take a look at bug 1923232 today? just wondering what further is expected to mark it as 'verification-done'.  I'd do it, but I don't want to step on toes.
[15:43] <xnox> LocutusOfBorg:  why do you think /dev/log has anything to do with glibc? =)
[15:43] <xnox> LocutusOfBorg:
[15:43] <xnox> $ ls -latr /dev/log
[15:43] <xnox> lrwxrwxrwx 1 root root 28 Jun 21 09:42 /dev/log -> /run/systemd/journal/dev-log
[15:45] <xnox> normally it is expected for it to be a blocking one, as otherwise you might loose log messages with is dataloss. It is expected to fill up, until something processes / forwards / stores all the messages.
[15:46] <xnox> on regular ubuntu system, that is systemd-journald, which in-turn forwards things to a classic syslog daemon, which then in default configuration stores things on disk.
[15:46] <xnox> if on the other hand /dev/log became non-blocking, it would appear that lots of services are writting logs to syslog.... and yet they go missing and get dropped on the floor.
[15:47] <xnox> LocutusOfBorg:  so lets go to the beginning. why are you reading /dev/log directly? one should instead read `journalctl -f` or syslog
[15:48] <xnox> LocutusOfBorg:  are you writing a syslog daemon (aka something that is drop in replacement for journald / syslog / syslog-ng) in that case you must adhere to the expectations of handling all messages correctly. not dropping them on the floor. and storing them. If need be, mark yourself to autorespawn on crashes & have a heartbeat to be restarted when getting "stuck".
[16:20] <LocutusOfBorg> xnox, where did I mention Ubuntu? XD
[16:21] <LocutusOfBorg> I'm doing a thing, an embedded system, with systemV and dev/log being read by a dlt-system daemon (dlt is a common logging system used in automotive industry)
[16:21] <LocutusOfBorg> problem is that if you fill up the /dev/log, even the init system gets stuck on the first write to syslog
[16:21] <LocutusOfBorg> so you can't reboot, launch scripts, log anything, the board is just stuck, for all processes doing a write to syslog
[16:22] <LocutusOfBorg> also journald,syslog,syslog-ng might one day have a bug with a deadlock, or something similar preventing the queue from being empty
[16:25] <LocutusOfBorg> I'm not alone btw https://www.endpoint.com/blog/2013/08/22/log-jam-be-careful-with-local-syslog
[16:25] <LocutusOfBorg> this happens when you redirect syslog into a slower device
[16:26] <LocutusOfBorg> https://lists.balabit.hu/pipermail/syslog-ng/2005-June/007588.html
[16:45] <xnox> LocutusOfBorg:  where is `dlt-system daemon`? can you point me at it to read sources of that?
[16:46] <xnox> LocutusOfBorg:  if your log daemon is crap, then yes your system is as reliable as that. Also note that good inits have protections against log jam, i.e. systemd does not fallover when journald stops responding. And there is a lot of failsafe built into journald with handling disks going readonly MIA etc.
[16:46] <xnox> LocutusOfBorg: also you say "systemV" ..... but which implementation in particular do you mean? there is about half a dozen of things that are "systemV"
[16:47] <xnox> some are better than others.
[16:48] <xnox> LocutusOfBorg:  there are good implementations of inits & logging daemons that do not suffer from cloging up /dev/log. I'm not sure glibc upstream would be open of making it less reliable, in the common cases, for most systems, to accomodate less resilient implementations.
[16:51] <xnox> LocutusOfBorg:  what you might find, is that lots of applications expect logging to be blocking; and if you change it to nonblocking lots of apps will start failing.
[16:51] <xnox> and assumptions about using Ubuntu is because this is #ubuntu-devel =)
[16:51] <xnox> not #glibc-devel
[16:52] <xnox> LocutusOfBorg:  so you move bug from one place, to many new places.
[16:52] <xnox> make your init & logging daemon more reliable, and fix bugs in them.
[17:15] <xnox> laney:  Libarchive 3.4.3 had many zstd improvements. I wonder if we it makes sense to rebuild the snap with libarchive 3.4.3 backport to focal and check if that "fixes everything"
[17:16] <xnox> laney:  in launchpad there is a way to force using newer series too, on the snap via api one can set it to "please build it in hirsute"
[17:23] <laney> xnox: it's probably easiest for you to fork it and play with changes yourself
[17:24] <bdmurray> smoser: I'm just testing an upgrade from F to G given that 4.0.6 isn't in Groovy
[17:25] <smoser> bdmurray: thank you.
[19:01] <seb128> LocutusOfBorg, hum, what was the point of that poppler sync? there is 0 change outside the debian/cjhangelog and it was on a revision that would autosync, also I did a new version upload today that is actually worth syncing and that I was going to sync once it's published...
[21:53] <diddledan> doko, I see you're listed as contact for openjdk-16 packages - it looks like focal builds have only been published for amd64 and i386, with all other architectures unaccounted for. I'm not sure where to look to find out whether the builds weren't attempted at all or have failed in some way - the PPA seemingly has the packages in question so something has gone awry in publishing to universe
[21:54] <diddledan> e.g. https://packages.ubuntu.com/focal/openjdk-16-jdk-headless
[22:53] <cjwatson> diddledan: Or packages.ubuntu.com is just wrong.
[22:53] <cjwatson>  openjdk-16-jdk-headless | 16.0.1+9-1~20.04 | focal-updates/universe   | amd64, arm64, armhf, i386, ppc64el, riscv64, s390x
[22:53] <cjwatson> (rmadison openjdk-16-jdk-headless)
[22:53] <diddledan> odd
[22:54] <cjwatson> amd64 and i386 are the two architectures on archive.ubuntu.com (as opposed to ports.ubuntu.com), so maybe it's something to do with that
[22:54] <cjwatson> IDK; packages.u.c is maintained by a community member
[22:54] <cjwatson> Oh actually, try https://packages.ubuntu.com/focal-updates/openjdk-16-jdk-headless
[22:55] <cjwatson> packages.u.c's view here is very confusing.  openjdk-16-jdk-headless isn't actually in the "focal" suite in terms of the archive at all; it's in focal-security and focal-updates
[22:55] <diddledan> I've been talking with someone in snapcrafters about a build failure they hit with seemingly unable to find non-x86 builds of the package
[22:56] <cjwatson> so I guess it must be looking at security.u.c and merging that into focal somehow ...
[22:56] <cjwatson> Anyway packages.u.c is probably a red herring for whatever you're investigating
[22:56] <cjwatson> Link to the build failure?
[22:58] <diddledan> https://launchpadlibrarian.net/544874175/buildlog_snap_ubuntu_focal_amd64_snapcraft-gradle-4ee03a_BUILDING.txt.gz
[22:58] <cjwatson> And that's on amd64
[22:59] <cjwatson> The error there doesn't seem to be anything to do with not finding openjdk-16-jdk-headless?
[22:59] <cjwatson> + rm /build/snapcraft-gradle-4ee03a/parts/java/install/usr/lib/jvm/default-java/lib/security/cacerts
[22:59] <cjwatson> rm: cannot remove '/build/snapcraft-gradle-4ee03a/parts/java/install/usr/lib/jvm/default-java/lib/security/cacerts': No such file or directory
[22:59] <diddledan> yeah, I think they gave me the wrong log :-)
[23:00] <diddledan> aha, they've just updated me - they made a wrong assumption based on package.u.c not showing the arches
[23:00] <cjwatson> Right :)
[23:01] <diddledan> thanks for helping :-)
[23:01] <cjwatson> Unfortunately with snapcraft remote-build working the way it does I can't currently guess the build log URL for other architectures even given buildd-manager logs ...
[23:02] <cjwatson> I was going to suggest reporting a bug on packages.u.c, but I think this might be https://bugs.launchpad.net/pkg-website/+bug/1866833?
[23:02] <diddledan> yeah, finding the logs is a bit of a pain - even when you have access via snapcraft.io's build service they're not immediately sharable without inspecting the page to find the underlying frame's url
[23:02] <cjwatson> Slightly different manifestation but it's probably the same cause
[23:03] <diddledan> yeah that looks similar
[23:06] <cjwatson> I can't find the code/config to investigate
[23:07] <cjwatson> Suspect it needs Rhonda to dig
[23:08] <cjwatson> https://packages.ubuntu.com/about/ is very outdated and even correcting for the current git location of upstream webwml there's no "ubuntu-master" branch there
[23:10] <diddledan> https://salsa.debian.org/webmaster-team/packages/-/tree/ubuntu-master
[23:10] <cjwatson> Oh maybe ... just found that
[23:11] <cjwatson> By gratuitous guesswork in salsa :)
[23:12] <cjwatson> I think wrapping my brain round this is more than I can manage at this time of night though, good luck ... night
[23:13] <diddledan> nn


[08:25] <apw> [1]rsa_sean [N,BFTL], not heard reports of that, cirtainly we should get a bug filed against "linux" at least
[08:26] <apw> ubuntu1404usb32 [N,BFTL], not heard reports of that, a bug against "linux" would contain h/w info whihc may help
[14:13] <stgraber> FYI i filed bug 1344049 for a cherry-pick of a netns/userns fix
[14:19] <rtg> stgraber, working on it
[14:20] <stgraber> rtg: great, thanks!
[14:21] <rtg> stgraber, its not a clean cherry-pick, but the backport looks simple enough
[14:23] <stgraber> oh, I guess something must have happened to linus' tree before net-next was merged then, because the commit as was pushed to net-next was applying cleanly on 3.13 (that's what I'm running here)
[14:24] <stgraber> rtg: http://paste.ubuntu.com/7814633/
[14:25] <rtg> stgraber, yeah, I'm looking at the patch. try the cherry-pick yourself.
[14:25] <rtg> capable() morphed into netlink_capable()
[14:29] <stgraber> ah yeah, apparently you need to replace ns_capable(userns, CAP_NET_ADMIN) by netlink_ns_capable(skb, userns, CAP_NET_ADMIN)
[14:31] <stgraber> the source of the conflict is: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/net/sched/?id=5f013c9bc70214dcacd5fbed5a06c217d6ff9c59
[14:32] <rtg> right. I'm just gonna do a simple backport so I don't have to deal with an upstream merge resolution


[19:37] <munz> itnet7: i have a cloak now, thx :)
[21:42] <itnet7> munz: sweet!!
[22:49] <bluebomber> Hola, todo
[22:53] <bluebomber_satel> Happy Memorial Day weekend, everyone.


[05:10] <mup> PR snapd#5851 closed: tests: don't fail interfaces-bluez test if bluez is already installed <Created by plars> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5851>
[05:10] <mborzecki> morning
[05:12] <mvo> mborzecki: hey, good morning
[05:14] <mborzecki> mvo: hey hey, how was your trip back?
[05:15] <mvo> mborzecki: hey, it was mostly good, one train was super delayed but fortunately I found  an alternative so no harm done
[05:16] <mborzecki> mvo: nice
[05:16] <mvo> mborzecki: and you? had a good trip as well?
[05:16] <mborzecki> mvo: yup, no hiccups, though i got home around midnight
[05:17] <mvo> mborzecki: nice
[05:24] <mup> PR snapd#5847 closed: overlord/snapstate: improve cleaup in mount-snap handler <Parallel installs> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5847>
[05:35] <mup> PR snapd#5809 closed: tests: using single sh snap in interface tests <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5809>
[05:36] <mborzecki> 40 PRs, not bad
[05:36] <mup> PR snapd#5855 opened: tests: cleanup copy/paste dup in interfaces-network-setup-control <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5855>
[06:33] <mup> PR snapd#5855 closed: tests: cleanup copy/paste dup in interfaces-network-setup-control <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5855>
[07:01] <pstolowski> mornings
[07:07] <mborzecki> pstolowski: hey
[07:16] <mvo> hey pstolowski
[07:20] <mup> PR snapd#5672 closed: tests: make nfs test available for more systems <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5672>
[07:27] <mborzecki> mvo: have you seen this? https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/30
[07:33] <mvo> mborzecki: no, let me see
[07:34] <mvo> mborzecki: hm, that is a complication indeed
[07:34] <mvo> mborzecki: do we considered it metered if GUESSS is set? or only if we know for sure?
[07:37] <mborzecki> mvo: yes, it's both NM_METERED_YES and NM_METERED_GUESS_YES
[07:38] <mborzecki> mvo: YES is only set if it was explicitly marked by the user, otherwise it's GUESS_YES
[07:38] <mvo> mborzecki: aha, I see
[07:42] <mborzecki> mvo: the idea of defaulting to refresh.metered=hold only on classic devices is actually quite appealing
[07:43] <mvo> mborzecki: yeah, it looks like thats the best way out of this mess
[07:43] <mborzecki> mvo: in the notes from friday niemeyer mentioned more strings for refresh.metered, do you recall any examples?
[07:44] <mvo> mborzecki: I think there was a slight misunderstanding in that there was this notation that the old config option was a yes/no boolean
[07:44] <mvo> mborzecki: but it was not iirc, it is already "" or hold
[07:44] <mvo> mborzecki: iirc that were the bits we talked about
[07:45] <mborzecki> mvo: ah, ok, well it's kind of 2 state now to be fair :)
[07:46] <mvo> mborzecki: yeah, its boolean :) but also using mostly sensible names (not just yes/no)
[07:48]  * pstolowski does the expensify. yuck
[07:49] <mvo> zyga: quick question - when you did the flock to mount you mentioned that systemd did timeout on boot when the mounts are serialized. how many snaps did you had installed when trying this?
[08:05] <mborzecki> mvo: left a note under #5792
[08:05] <mup> PR #5792: [RFC] {config,snap}state: add new refresh.metered=force option and flip default <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5792>
[08:07] <mvo> mborzecki: ta
[08:08] <Chipaca> moin moin
[08:10] <Chipaca> mborzecki: wrt metered, how's it looking?
[08:11] <Chipaca> reading the feedback from field, it sounds like we might want an 'auto' setting that only looks at _yes (and not _guess_yes)
[08:11] <mborzecki> Chipaca: hey, some updates in the forum topic, https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/30
[08:11] <Chipaca> yeap, was just reading that
[08:12] <mborzecki> Chipaca: well, _yes is half solution for desktop users
[08:13] <Chipaca> mborzecki: yes, otoh they're much more able to tweak it than devices out there
[08:13] <mborzecki> Chipaca: we could tweak the nm wrapper to return whether the result is a guess or not and use that to pick proper default for desktop/device scenario
[08:14] <zyga> Hey hey. I just want to say I’m off today.
[08:14] <Chipaca> zyga: are you sure? because you don't _look_ off
[08:15] <Chipaca> mborzecki: it's looking like we'll need something like that t make erryone happy
[08:18] <mborzecki> Chipaca: that and 'refresh.metered=force', you could mark the connection as metered for some other application but would stiill want snap updates
[08:19] <Chipaca> mborzecki: 'force' was the 'ignore metered', right? and what was 'assume metered'?
[08:21] <mvo> zyga: thanks! enjoy your time off
[08:22] <zyga> Chipaca: yeah, servicing my laptop now
[08:22] <zyga> See you later :-)
[08:22] <Chipaca> zyga: boot your mac sometime
[08:22] <mborzecki> Chipaca: there wasn't, there's 'hold' which covers yes && guess_yes, and default '' which was like ignore-metered
[08:23] <Chipaca> zyga: ah you already have, thanks :-D
[08:23] <Chipaca> … wait no it's dead
[08:23] <Chipaca> drat
[08:23] <Chipaca> mborzecki: we need to map out scenarios
[08:23] <Chipaca> mborzecki: i think
[08:27] <kyrofa> Chipaca, buy your own mac! popey might be able to help as well
[08:27] <popey> wat wat
[08:28] <Chipaca> kyrofa: I possess one of AFAIK 2 canonical-owned macs!
[08:28] <Chipaca> kyrofa: alas it's too old to be useful at this point
[08:28] <popey> I have a macbook air if needed
[08:29] <kyrofa> Chipaca, yeah I have one of the first intel ones, I know what you mean
[08:29] <Chipaca> popey: good to know in case something urgent comes up; zyga has a lab I can ssh into for a bunch of different things and his mac is just one of 'em, and I thought I'd test https://github.com/sergiusens/homebrew-snapcraft on it ahead of Sergio, but it's not urgent at all
[08:29] <popey> kk.
[08:30] <Chipaca> I tested it using linuxbrew, which is probably good enough for now :-)
[08:39] <popey> Chipaca: i know you love terminals. Did you know on a bare tty, the tickmark next to a verified snap is a green diamond?
[08:39] <Chipaca> popey: yes
[08:39] <popey> ok
[08:39] <Chipaca> popey: I thought that wasn't too bad
[08:39] <Chipaca> popey: I'm open to being wrong though
[08:40] <popey> I haven't investigated the alternatives. I expect you're right.
[08:40] <Chipaca> popey: add --unicode=never to see if it'd be better with "linux terminals don't do unicode"
[08:40] <popey> a green asterisk
[08:41] <popey> I am honestly not sure which I prefer.
[08:42] <zyga> Chipaca: I’ll boot it in 30 min
[08:43] <popey> wonder what it would look like on this bad boy... https://www.ebay.co.uk/itm/WANG-Computer-WANG-Terminal-Model-2246-Computer-IBM-XT-AT-DEC-SPERRY/113221449456
[08:43] <popey> so tempted
[08:43] <zyga> Returning home from apple support shop
[08:48] <Chipaca> popey: eww, AZERTY
[08:49] <ogra> diamonds are forever, stay with it !
[08:55] <mup> PR snapd#5823 closed: snapcraft.yaml: add workaround for LP:#1791871 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5823>
[09:00] <Chipaca> popey: also: it'd be cheaper, easier and more reliable to take a too-old-to-be-useful laptop and use it to boot linux as a dumb serial terminal
[09:00] <Chipaca> popey: OTOH, not as cool
[09:00] <Chipaca> and this wasn't ever about cheap, easy, nor reliable :-)
[09:00] <popey> May I point you at my ThinkPad X61S running Ubuntu Core :D
[09:01] <popeycore> That's me! :D
[09:05] <Chipaca> popeycore: you can point all you want, but my virtual reality irc headset isn't working to see where you're pointing at
[09:06] <Chipaca> mvo: can we refresh go-flags, or was ppc bocking that?
[09:07] <mvo> Chipaca: lets try it
[09:07] <mvo> Chipaca: if it needs an updated sys/unix we are in trouble
[09:07] <Chipaca> mvo: some nice fixes landed over the weekend
[09:08] <Chipaca> mvo: if you look at 'man snap', and search for '^ *info', you'll see a bug
[09:08] <Chipaca> that's fixed :-)
[09:09] <Chipaca> mvo: it does not depend on sys/unix
[09:09] <Chipaca> its unit tests no longer work with 1.6, alas, but that's another issue
[09:09] <Chipaca> (easy to distro-patch a fix if needed)
[09:09] <Chipaca> (and what we currently use has the same issue afaik)
[09:09] <mvo> Chipaca: "easy" ;)
[09:09] <mvo> Chipaca: but yeah
[09:09] <Chipaca> souper easy
[09:09] <Chipaca> :-)
[09:10] <mvo> Chipaca: it will be a small pain for the debian downstream
[09:10] <Chipaca> mvo: are they still on 1.6?
[09:10] <Chipaca> 1.7 works
[09:10] <mvo> Chipaca: oh, right, sorry
[09:10] <mvo> Chipaca: of course not
[09:10] <Chipaca> phew
[09:10] <mvo> Chipaca: so hopefully no problem for anyone except us
[09:11] <mvo> Chipaca: and we don't run the unit tests of it so …
[09:11] <Chipaca> hehe
[09:11] <Chipaca> mvo: if we vendor it, we're fine
[09:11] <mvo> Chipaca: yeah, we do
[09:23] <mborzecki> Chipaca: mvo: how does this sound? https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/32
[09:25] <Chipaca> mborzecki: terrible, awful, it's the worst thing to ever be put up on the internet, and it's all the wrong colour
[09:25] <mborzecki> hahaha
[09:25] <Chipaca> mborzecki: maybe I should click the link
[09:35] <mborzecki> anyone using discord under KDE?
[09:37] <zyga> Chipaca: re
[09:37] <zyga> Chipaca: do you need access now?
[09:37] <popey> mborzecki: i am
[09:37] <Chipaca> zyga: I could use it, i dont need it
[09:37] <zyga> Chipaca: try now
[09:37] <zyga> it should be up
[09:38]  * zyga just rented the house for TV production on Wednesday
[09:39] <Chipaca> zyga: computer says yes
[09:39] <zyga> whee
[09:39] <zyga> Chipaca: FYI today is the day when a new macOS is available, you can try now and then later when I upgrade
[09:39] <Chipaca> zyga: didn't you have homebrew installed?
[09:39] <zyga> Chipaca: I think the next OS doesn't leave any old apps behind so you can reasonably expect everyone to be using this version soon
[09:40] <zyga> Chipaca: no, I didn't
[09:40] <zyga> Chipaca: want me to install it?
[09:40] <zyga> Chipaca: I have go installed
[09:40] <Chipaca> zyga: I should be able to do it myself without sudo even
[09:40] <zyga> but not homebrew
[09:41] <zyga> Chipaca: cool, let me know if you need anything
[09:41] <Chipaca> zyga: hmm, it's asking me for sudo to do thinks in /usr/local. It seems doing it in my home needs more options. Which would you rather I do?
[09:41] <zyga> Chipaca: just use sudo
[09:41] <zyga> I gave you access
[09:42]  * zyga hugs and trusts Chipaca with his main computer :)
[09:42]  * Chipaca accepts the hug, and trusts the brew people for this
[09:46] <mborzecki> damn, desktop files are a mess
[09:50] <zyga> Chipaca: there's an update to command line tools for Xcode (aka the toolchain)
[09:50] <zyga> Chipaca: shall I ignore that for the duration of your experiments?
[09:51] <Chipaca> zyga: yes please
[09:51] <zyga> ok
[09:55] <Chipaca> zyga: now you have more go than before!
[10:01] <niemeyer> Hellos o/
[10:02] <pstolowski> hey niemeyer!
[10:05] <Chipaca> zyga: done
[10:06] <Chipaca> zyga: what's the difference between today's update and before? so I can write "tested with _____"
[10:06] <mvo> niemeyer: hey! how are you? good trip back?
[10:06] <zyga> Chipaca: today is macOS high sierra
[10:06] <zyga> Chipaca: tomorrow is macOS Mojave
[10:06] <zyga> hey mvo, niemeyer
[10:06]  * zyga is off b
[10:07] <niemeyer> mvo: Yeah, that was surprisingly easy :)
[10:07] <zyga> but apparently terrible at it :)
[10:07] <niemeyer> Was lucky enough to get out of the plane and straight into the bus
[10:07] <zyga> though I really want to take a nap, sleeping with two kids and a dog in one bed is ... not perfect
[10:07] <niemeyer> I was home in no time
[10:07] <zyga> niemeyer: nice change, right? :)
[10:07] <niemeyer> zyga: 8)
[10:10] <mvo> niemeyer: nice!
[10:22] <Chipaca> currently "snap interface"'s help says "List snap interfaces" and "snap interfaces"' help says "List interfaces in the system"
[10:23] <Chipaca> would "Show details of snap interfaces" and "List interface slots and plugs in the system" be better and more accurate?
[10:23] <Chipaca> niemeyer: zyga: ^
[10:23] <niemeyer> Chipaca: +1
[10:23] <niemeyer> Chipaca: First one should probably be singular
[10:24] <niemeyer> ... of snap interface
[10:24] <Chipaca> niemeyer: if you just do "snap interface" it lists them all though
[10:24] <zyga> yeah, that's a nice change
[10:24] <niemeyer> Chipaca: while the second should be plural
[10:24] <niemeyer> List interfaces ...
[10:24] <zyga> Chipaca: all instantiated and connected
[10:24] <niemeyer> Ah, no.. slots and plugs
[10:24] <zyga> aaah
[10:24]  * zyga runs and tries to be off
[10:24] <Chipaca> zyga: which were you adding to there
[10:24] <niemeyer> Chipaca: Ah, interesting
[10:25] <Chipaca> niemeyer: ¯\_(ツ)_/¯
[10:25] <Chipaca> trying to make it less interesting :-)
[10:25] <niemeyer> Chipaca: +1 either way :)
[10:25] <Chipaca> "List interfaces' slots and plugs" works too
[10:26] <Chipaca> but then we get the dreaded "plural possessive" discussion
[10:26] <Chipaca> :-)
[10:26] <Chipaca> I blame degville
[10:49] <mup> PR snapcraft#2289 opened: local source: only filter out snapcraft artifacts <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2289>
[11:02] <mup> PR snapd#5856 opened: cmd/snap: tame the help zoo <Created by chipaca> <https://github.com/snapcore/snapd/pull/5856>
[11:02] <Chipaca> niemeyer: can you make it so I can request a review from degville? (currently I can't)
[11:03] <niemeyer> Hmm, I guess he's not in the org yet
[11:03] <degville> I  am looking through though - how about `List slots and plugs for all interfaces' as an alternative?
[11:04] <Chipaca> degville: if you could say so on the PR, then we can keep tabs on it all
[11:04] <degville> Chipaca: will do.
[11:04] <Chipaca> degville: thanks
[11:05] <Chipaca> I expect "Admin" to be contentious, just didn't find anything better and thought it best to just push it and see
[11:06] <niemeyer> Chipaca: Done
[11:06] <niemeyer> degville: You should have received an invite
[11:06] <degville> niemeyer: got it, thanks.
[11:15] <mvo> Chipaca: I reworked 5717 a bit with gustavos input in mind, would be great if you could have another look to see if looks sane. it will unblock two more PRs
[11:16]  * Chipaca is afk, punching trees
[11:16] <Chipaca> j/k. Looking.
[11:20] <mvo> ta
[11:26] <Chipaca> mvo: q: why can't one do GET things in degraded mode?
[11:36] <mvo> Chipaca: I was simply conservative, happy to allow that
[11:37] <Chipaca> mvo: I'd just make it degraded -> nothing but GET
[11:38] <Chipaca> mvo: but I don't know if there are exceptions that would warrant the flag
[11:38] <Chipaca> I don't _think_ so :-)
[11:38] <Chipaca> by definition, GET should not be writing state
[11:38] <mvo> Chipaca: lets say YAGNI and I will just allow get and we add the flag again when we need it?
[11:38] <Chipaca> and we never have bugs
[11:38] <Chipaca> so, \o/
[11:38] <Chipaca> mvo: sgtm!
[11:38] <Chipaca> mvo: less flags -> less code -> less bugs
[11:39] <Chipaca> huzzah
[11:40] <mvo> !!!
[11:40]  * mvo goes and makes it so
[12:01] <mup> PR snapd#5857 opened: userd: extend the list of supported XDG Desktop properties when autostarting user applications <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5857>
[12:01]  * Chipaca ~> lunch break
[12:07] <mborzecki> off to pick up the kids
[12:37] <mborzecki> Chipaca: can you check what's the value of XDG_CURRENT_DESKTOP in your env?
[12:38] <Chipaca> mborzecki: my EAAS costs are 2¢ per request, and .5¢ per byte response
[12:39] <mborzecki> Chipaca: EAAS - env as a service? :)
[12:39] <Chipaca> mborzecki: your request was: $XDG_CURRENT_DESKTOP
[12:39] <Chipaca> mborzecki: your response is: "Unity"
[12:39] <mborzecki> Chipaca: ooh, that's 16.04?
[12:40] <Chipaca> mborzecki: you account is now overdrawn by 2.3¢
[12:40] <Chipaca> I think there's a bug in my accounting software
[12:40] <Chipaca> mborzecki: yes :-)
[12:40] <mborzecki> Chipaca: i'm sure i can expense it to canonical :D
[12:41] <Chipaca> mborzecki: why?
[12:41] <Chipaca> how did you get from "Unity" to "16.04"?
[12:41] <mborzecki> Chipaca: i figured it would be GNOME on 18.04
[12:41] <mborzecki> mvo: are you on 18.04 by any chance?
[12:42] <Chipaca> mborzecki: I have that on my tablet downstairs, I think (haven't turned it on in a couple of months now)
[12:42] <Chipaca> grmbl grmbl kernel broke the touchscreen grmbl
[12:44] <mborzecki> Chipaca: pieces of autostart handling look at XDG_CURRENT_DESKTOP when deciding if the app should be started, I wonder if GNOME specific settings should be applied under unity too
[12:45] <Chipaca> mborzecki: making that desktop-dependent will probably confuse app devs more than not
[12:45] <Chipaca> unless they're _wanting_ it to not autostart on non-gnome (or bicerveza)
[12:51] <mborzecki> Chipaca: discord sets X-GNOME-Autostart-enabled atm, don't know what they set for unity though
[12:51] <Chipaca> installing discord...
[12:54] <Chipaca> mborzecki: in what file do they set that?
[12:56] <Chipaca> mborzecki: the option to autostart defaults to enabled, and grep finds no X-GNOME-Autostart
[12:56] <Chipaca> mborzecki: but I also find no desktop file under ~/snap/discord
[12:56] <Chipaca> so … dunno what I'm looking for
[12:56] <mvo> mborzecki: I'm on 18.04 - yes
[12:57] <Chipaca> mborzecki: haha, I disabled it, and it created the file
[12:57] <Son_Goku> mvo, zyga, so I'm currently working on compilation failures with snapd on el7
[12:57] <Chipaca> mborzecki: so it looks like they have a bug :-)
[12:58] <Son_Goku> seems like there's a bad interaction with partial static linking now :(
[12:58] <Chipaca> mborzecki: and they do create the file, with X-GNOME-Autostart-enabled=false in it
[12:58] <Chipaca> Son_Goku: nobody uses e17 anyway
[12:58] <Son_Goku> Chipaca: hah definitely no one uses e17
[12:58] <Son_Goku> at least, I hope not
[12:59] <Chipaca> (I seriously read that the first time and did a double-take)
[12:59] <Son_Goku> :D
[12:59] <Son_Goku> mvo, as you're aware, parts of snapd's go code is statically linked to support bases properly
[13:00] <Son_Goku> so I'm trying to figure out how things are blowing up
[13:00] <mup> PR snapd#5854 closed: interfaces/docker-support: add rules to read apparmor macros <Created by anonymouse64> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5854>
[13:01] <Chipaca> popey: discord snap has a bug, fwiw, want a irc rantoid, or a github issue?
[13:02] <popey> pull request pls :D
[13:02] <popey> https://github.com/snapcrafters/discord
[13:02] <popey> issue is fine
[13:04] <mborzecki> Chipaca: yeah, the file is dropped only when you tigger the radio button :/
[13:07] <Chipaca> popey: https://github.com/snapcrafters/discord/issues/46 fwiw
[13:08] <popey> <3
[13:09] <mborzecki> popey: would you like a PR with autostart desktop file support too? :)
[13:14] <popey> PR's are always welcome :)
[13:14] <popey> Also, I have a bug for you guys :)
[13:14] <popey> snap install something --edge, then replace it with snap install ./something --dangerous
[13:14] <popey> snap list says x1 edge, as if I am tracking edge, even though I am now on a local install
[13:17] <mup> PR snapcraft#2290 opened: pluginhandler: update build should overwrite organize <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2290>
[13:30] <Chipaca> popey: not sure that's a bug, exactly
[13:30] <Chipaca> popey: snap install ./something --dangerous  and tehn  snap switch --edge something  works
[13:31] <popey> surely if i install something locally, I should stop tracking the store?
[13:31] <Chipaca> popey: you can then do 'snap amend'
[13:32] <Chipaca> niemeyer: I could hear _something_ in the background, but thought it was just aggressive audio compression
[13:32] <niemeyer> Chipaca: Cool, so not enough to be a nuisance
[13:32] <Chipaca> popey: er, i meant 'snap refresh --amend'
[13:33] <Chipaca> niemeyer: unless you're degville
[13:33] <Chipaca> :-D
[13:34] <Chipaca> niemeyer: what do you think? should "snap install ./something" when you already have 'something' installed break the 'tracking' relationship?
[13:34] <Chipaca> actually
[13:34] <niemeyer> Chipaca: Isn't that the case already?
[13:34] <Chipaca> maybe 'snap install --dangerous' should refuse to work if you have an installed something
[13:34] <Chipaca> yeah, that sounds like what should happen
[13:34] <Chipaca> niemeyer: nope, you can have a local snap tracking the store
[13:35] <Chipaca> niemeyer: ("snap switch" works on local snaps)
[13:35] <niemeyer> Chipaca: That's a bit awkward..
[13:35] <Chipaca> niemeyer: you then can use "snap refresh --amend"
[13:35] <niemeyer> Chipaca: I don't think it should work, and my memories are that it didn't
[13:35] <niemeyer> Chipaca: Ah, okay, so it won't refresh until that takes place?
[13:35] <Chipaca> refreshes are blocked, yes
[13:35] <niemeyer> Cool, ok
[13:36] <Chipaca> it's a bit weird
[13:36] <Chipaca> but in any case, we probably want to block the asserted -> unasserted install
[13:36] <Chipaca> unasserted -> unasserted is fine, used for dev all the time
[13:37] <Chipaca> unasserted -> asserted also fine i think
[13:37] <Chipaca> asserted -> unasserted, you're trying to do something you shouldn't
[13:39] <Chipaca> (otoh you did say --dangerous)
[13:39] <Chipaca> ¯\_(ツ)_/¯ dunno, send help
[13:39]  * Chipaca goes to the gym
[13:42] <niemeyer> Chipaca: Yeah, not sure.. we need to think about the actual issues on these cases
[13:42] <Chipaca> thinking is hard
[13:49]  * Chipaca aborted the gym trip, gets back to work
[14:29] <niemeyer> Chipaca: gym is harder? :P
[14:30] <Chipaca> niemeyer: it's going to be rough :-) but nah, i just missed my window
[15:03] <stokachu> i had ot make adjustments in how we built conjure-up, now juju/jujud aren't being included in the snap
[15:03] <stokachu> https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml
[15:03] <stokachu> so not sure what im missing here now
[15:04] <stokachu> this is came about b/c we're now forced to move our snap specific wrapper scripts outside of snap dir
[15:15] <stokachu> sergiusens, ^
[15:28] <sergiusens> stokachu: did I not propose a PR?
[15:28] <stokachu> sergiusens, nah
[15:28] <sergiusens> I just landed now, so I think I will ask kyrofa to look at your repo
[15:29] <stokachu> ok thanks
[15:29] <stokachu> cory_fu, with charmtools had to do something similar wrt the snap/wrappers die
[15:29] <stokachu> dir*
[15:30] <stokachu> kyrofa, the workaround i have in there for the wrapper scripts work now, but juju/jujud isn't being included in the snap anymore
[15:30] <stokachu> would like to not have to use the workaround with snapcraftctl prime though
[15:31] <cory_fu> stokachu: I think the reason juju's not being included is that you don't call `snapcraftctl build` at the top of the override-build section
[15:31] <stokachu> ah
[15:32] <stokachu> cory_fu, good catch
[15:32] <stokachu> rebuilding now to see
[15:32] <cory_fu> stokachu, kyrofa, sergiusens: I would really like to know of a better way to manage the wrappers, because having to use override sections is messy
[15:33] <cory_fu> Originally tried to use dump plugin parts but could never get the paths to work out correctly
[15:33] <cory_fu> It was particularly frustrating because the pwd seemed to change depending on whether an override section was present or not
[16:41] <stokachu> snapstore seems down too, Store upload failed: ('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution'))
[16:42] <stokachu> that's from launchpad
[16:45] <cjwatson> no, that's a SUPER WEIRD problem on one of the Launchpad script servers, not a store problem
[16:56] <kyrofa> cory_fu, stokachu, why not create a new part for the wrappers instead of trying to do it from an unrelated part?
[16:56] <kyrofa> Hard-coding paths like that isn't stable
[16:58] <cory_fu> kyrofa: Tried that originally and couldn't get it to work.
[17:00] <stokachu> that's what we had originally
[17:02] <cory_fu> kyrofa: First issue we hit was the change from things not being allowed in the snap directory anymore.  Even once we moved it out of there, though, for charm-tools at least, I couldn't get it to include the file in the built snap properly.
[17:03] <stokachu> cjwatson, ah ok
[17:03] <stokachu> cjwatson, it looks like it was uploaded?
[17:03] <stokachu> im getting a different error now
[17:03] <stokachu> binary_sha3_384: A file with this exact same content has already been uploaded
[17:15] <cjwatson> stokachu: Yeah, unfortunately some errors aren't currently retryable sensibly (we have a plan but it's not implemented yet), so in this situation you have to rebuild
[17:16] <stokachu> cjwatson, ok cool, np
[17:17] <cjwatson> And the worker in question hasn't been restarted, so there's a 1/3 failure chance
[17:17] <cjwatson> It is really very mysterious
[17:17] <stokachu> :D
[17:20] <kyrofa> cory_fu, which file exactly seems to not make it?
[17:22] <cory_fu> kyrofa: For charm-tools, there's one wrapper in https://github.com/juju/charm-tools/tree/master/helpers/snap-wrappers and I was trying to get it into bin/wrappers/
[17:23] <cory_fu> Seems like it should be pretty straightforward, but I tried for a long time to get it to work
[18:07] <kyrofa> cory_fu, hoo boy is this a hefty snap. I'll make a PR shortly
[18:13] <cory_fu> kyrofa: Thanks!
[18:14] <kyrofa> cory_fu, https://github.com/juju/charm-tools/pull/449
[18:14] <mup> PR juju/charm-tools#449: snapcraft.yaml: add new part for wrappers <Created by kyrofa> <https://github.com/juju/charm-tools/pull/449>
[18:17] <ogra> you call that a hefty snap ? you havent seen the gimp snap yet, have you ? :)
[18:17] <kyrofa> ogra, not in size, in build time
[18:17] <kyrofa> ogra, but yes I'll admit: I haven't messed with the gimp snap
[18:18] <ogra> oh, seems popey or diddledan have cleaned it up ... last time i looked the snapcraft.yal had 1800 lines !
[18:18] <ogra> *yaml
[18:18] <diddledan> yeah, moving to core18 allowed a LOT of dependency trimming
[18:19] <cory_fu> kyrofa: So that's going to hit the the issue that originally started all of this, which was the dump plugin failing with a "part modified" error.  We worked around this at first by adding "source-type: git" but then that had path issues or something.  I know there was a snapcraft fix for that, but I don't know if it's available on the LP builders now?
[18:19] <ogra> yeah, it was a bit like a novel before
[18:19] <ogra> missing chapters though
[18:19] <kyrofa> cory_fu, you got "part modified" because you were using the snap dir
[18:19] <cory_fu> kyrofa: Oooh
[18:20] <diddledan> I believe reading it in it's entirety would have opened up a portal to hell
[18:21] <ogra> lol
[18:21] <ogra> necronomicon.yaml
[18:21] <kyrofa> cory_fu, snapcraft makes the assumption that it owns the snap/ dir (we'll ignore the fact that this assumption wasn't at all well-communicated). It writes caches into it, and so on. Then if you say `source: snap/` it picks up the changes it wrote itself as source changes
[18:22] <cory_fu> kyrofa: Hrm.  But we originally got the "part modified" error on the versions part, which is why we have the source-type in it still
[18:22] <diddledan> halloween just around the corner, too ;-p
[18:22] <ogra> heh
[18:22] <cory_fu> kyrofa: And that doesn't touch the snap dir
[18:22] <diddledan> I really don't get why folk want to put random stuff in ./snap/
[18:22] <ogra> yeah, i' also always surprised
[18:23] <ogra> *i'm
[18:23] <cory_fu> kyrofa: Although, maybe I'm confusing multiple bugs, because there was also this: https://github.com/juju/charm-tools/pull/445
[18:23] <mup> PR juju/charm-tools#445: Fix version causing build signature issues <Created by johnsca> <Merged by johnsca> <https://github.com/juju/charm-tools/pull/445>
[18:23] <kyrofa> cory_fu, certain git commands can update the timestamp of the .git directory as well, which can trigger that behavior
[18:24] <diddledan> looking at you, vscode!
[18:24] <kyrofa> Yeah vscode does it, intellij does it, and git describe does it, I think
[18:24] <diddledan> I "fixed" the alsa remote part by specifying a source even though I'm using `plugin: nil`
[18:25] <cory_fu> kyrofa: Yeah, we did originally have "source: snap/" in the versions part, so that's what it was
[18:25] <kyrofa> Ah, yeah there you go
[18:25] <cory_fu> kyrofa: Would you mind terribly also removing the source-type line from the versions part in your PR?
[18:26] <kyrofa> cory_fu, we're trying to make that a little more friendly, but if you want to be absolutely safe just leave the snap dir alone except for stuff that is supposed to go in there (hooks, plugins, snapcraft.yaml, desktop files, etc.)
[18:26] <kyrofa> Sure
[18:26] <cory_fu> kyrofa: That makes perfect sense.
[18:27] <kyrofa> cory_fu, want me to squash?
[18:27] <cory_fu> kyrofa: I'll squash when I merge it.
[18:27] <cory_fu> kyrofa: But either wya
[18:28] <kyrofa> Done
[18:29] <kyrofa> Alright, it's 2030 here, I'm off. Have a good rest of the day, folks!
[18:35] <cory_fu> kyrofa: Have a good evening.  o/
[18:37] <cory_fu> I just noticed that the previous build of the charm snap failed to to release and I have no idea why.  I don't see anything in the log: https://launchpadlibrarian.net/389460316/buildlog_snap_ubuntu_xenial_amd64_681cc7a9b635a1e50b11af9067b472ad-xenial_BUILDING.txt.gz
[18:45] <popey> " Store upload failed: [Errno 12] Cannot allocate memory "
[18:45] <popey> one for w_grant or c_jwatson
[19:08] <cory_fu> popey: Thanks.  It looks like the latest build released fine
[22:33] <joelkraehemann> hi all
[22:34] <joelkraehemann> https://snapcraft.io/nongnu-gsequencer/listing
[22:34] <joelkraehemann> ^^ I am new to snapcraft
[22:34] <joelkraehemann> how does the review process complete?
[23:14] <joelkraehemann> Error: The provided video url does not match any of the currently supported services.