[00:16] er spread just says this to me: [00:16] error: invalid project name: "" [00:18] oh is this because my gopath is not in $HOME [00:22] yes [00:22] grumble [01:22] elopio please check my last comment on snapcraft#1552 [01:22] PR snapcraft#1552: tests: replace the first batch of demo tests with snapd integration tests [01:37] PR snapcraft#1559 opened: static: fix flake8 errors in setup.py [01:38] elopio or kyrofa easy one ^ [02:16] PR snapcraft#1560 opened: ci: use travis conditionals === JoshStrobl|AFK is now known as JoshStrobl [04:23] PR snapcraft#1561 opened: rust plugin: record the Cargo.lock file [04:24] elopio, are you still around? [04:26] Nah, nevermind, it's too late [04:56] PR snapcraft#1562 opened: Record rust versions [05:35] kyrofa: I'm here. But yes, I'll EOD, I'll continue meditating about your PR tomorrow :) [05:35] PR snapcraft#1563 opened: tests: simplify a little the data in nodejs unit tests [06:10] brr [06:22] PR snapd#3950 closed: cmd/snap-repair: prefer leaking unmanaged fds on test failure over closing random ones [06:46] PR snapd#3951 opened: snap: add new `snap fold` and use in tests [07:07] PR snapd#3949 closed: cmd/snap-repair: skip disabled repairs === chihchun_afk is now known as chihchun [07:17] * zyga-ubuntu wonders if the rain will stop [07:18] or will it just switch to snow [09:22] PR snapd#3939 closed: interfaces: add Connection type [09:32] * zyga-ubuntu -> cold :/ [09:37] * ogra_ hands zyga-ubuntu a campfire [09:58] * Chipaca helps zyga-ubuntu warm up by running the test suite on all his lab machines [09:58] * Chipaca is lying [09:58] * Chipaca always lies, even now [10:01] huh, just got a unit test dying because of my webcam [10:01] * Chipaca squints [10:05] looks like i'm missing a .h [10:06] * Chipaca hugs “apt build-dep ./” [10:10] * zyga-ubuntu fights with nfs [10:12] seems we have again linode -> github issues [10:13] * Chipaca ponders nfs-aware snapds [10:14] e.g. grab snaps off other snapds, query other snapds acking [10:14] (fear not, only pondering this because waiting for unit tests) [10:20] * zyga-ubuntu has small progress :) [10:36] zyga-ubuntu: I wonder if we could have a box set up running the latest Fedora to run through the latest snapd with setroubleshoot installed and active, and collect all the denials [10:36] from the spread test [10:38] setroubleshoot has an API, so you could use that to collect all the denials related to snappy policy domain [10:44] mmm [10:45] Son_Goku: we could just adjust the spread test run for fedora and somehow collect the results [10:45] Son_Goku: spread has a "residue" system where it could collect a file from the tested system [10:45] is setroubleshoot-server installed and running when the fedora vm is booted? [10:45] without setroubleshoot, you just get shitty AVC denial messages like you do with AppArmor [10:46] Son_Goku: we could bake it into the image [10:47] then the next question is, how do we get the data [10:47] I know it spews messages into the journal [10:47] we'd run it manually on linode and collect it via the resudue [10:47] but I don't know if there's another location too [10:47] we'd have to script things so that there's a file to collect [10:47] right [10:48] mvo: so good news, preliminary testing again staging worked as expected, otoh I think we should disable the snap-repair timers during spread tests or it might get confusing when we start having some? [10:49] pedronis: agreed [10:49] pedronis: having said that, we could do it when we get the first repair [10:50] as you prefer [11:07] ok, I have working NFS support in snapd [11:07] let's propose it piece by piece and let's work on a spread test [11:08] PR snapd#3952 opened: cmd: update "make hack" [11:08] Chipaca: ^ trivial [11:33] PR snapcraft#1563 closed: tests: simplify a little the data in nodejs unit tests [11:39] PR snapcraft#1559 closed: static: fix flake8 errors in setup.py [11:51] mvo: sample runs (with staging): http://pastebin.ubuntu.com/25585711/ === ikey is now known as ikey|zzz === JoshStrobl is now known as JoshStrobl|Store [12:05] $ snapcraft cleanbuild --output [12:05] Error: no such option: --output [12:06] $ snapcraft cleanbuild [12:06] [cpu stuck at 100% but no output, and apparently nothing happens] [12:06] sergiusens: ^ [12:11] elopio: ^ [12:11] kyrofa: ^ [12:12] jdstrand: i just uploaded an app (pulsemixer) which got stuck in review because it has no desktop file (I use the x11 interface). It is a CLI app - no GUI. But the x11 interface is required for pulse to work! [12:12] (known bug?) [12:15] popey: it isn't a bug in the tools. I can add an exception for it [12:15] jdstrand: hey [12:15] jdstrand: I have a POC for nfs support, do you want to have a quick look? [12:16] hey zyga-ubuntu [12:16] jdstrand: I mean a bug in the pulseaudio interface..? [12:17] mvo: #3934 spreads runs seems to be plagued by networking issues :/ [12:17] PR #3934: snap-repair: implement `snap-repair {list,show}` [12:18] pedronis: yeah, I noticed as well, super annoying, so close [12:19] popey: no. pulse uses x11 window properties to find the server. something that is doing that should declare the x11 interface [12:19] ahh [12:19] (ie, we don't want to add X access to the pulseaudio interface) [12:22] zyga-ubuntu: where is it? [12:23] jdstrand: I just pushed it to feature/nfs-support branch [12:23] jdstrand: I tested it successfully on my artful system, I'm working on spread test [12:24] jdstrand: have a look at each patch, I tried to make it logically follow one another [12:31] jdstrand: I was thinking about also parsing etc/fstab and looking for NFS there [12:31] jdstrand: and enabling the workaround if _either_ NFS is actually mounted or fstab says it may be mounted [12:38] zyga-ubuntu: I made a couple of comments. I think the direction is fine and who it is implemented makes sense [12:40] jdstrand: thank you, looking [12:40] zyga-ubuntu: I was initially thinking only nfs home. I guess its possible some of the other policy might allow access to nfs directories depending on the setup, so I guess checking the mount table for anything is ok [12:41] maybe it makes sense to start with only home, and expand if people are affected... [12:41] probably need more people to discuss, but that can happen in PR review [12:42] PR snapcraft#1560 closed: ci: use travis conditionals [12:42] jdstrand: anything that is a subdir of home is a good test as this will let us test this easily and will be constrained how you explained [12:43] jdstrand: as for reexec, that will work automatically thanks to the way the apparmor imports are handled [12:44] jdstrand: I think it makes sense to extend filesystem type to handle samba but I haven't tested that so I'd like to do it as a separate step [12:44] jdstrand: thank you for the quick look, I think this will work fine shortly [12:45] ppisati I don't think we ever supported --output in `cleanbuild` [12:45] zyga-ubuntu: it isn't the imports I was worried about, it was loading the older snap-confine policy when we are reexecing [12:46] * sergiusens waves hello [12:46] zyga-ubuntu: re samba> sounds fine [12:48] jdstrand: older policy? [12:49] jdstrand: when we are re-execing the newer snapd will run snap-confine from core and we already have support for managing that dedicated profile [12:49] jdstrand: and that profile is a derivative of the profile stored in the core snap [12:49] zyga-ubuntu: there is /etc/apparmor.d/usr.lib.snapd.snap-confine.real, but we also end up with usr.lib.snapd.snap-confine.real.rev (or something) [12:49] jdstrand: so it will source the system-wide policy extension for snap-confine [12:49] jdstrand: right but see above, those all source one place [12:50] jdstrand: and we already have setup code that ensures those are reloaded [12:50] it isn't /var/lib/snapd/apparmor/snap-confine.d I am worried about [12:50] that directory is fine (indeed, I suggested it) [12:50] it is that you are hardcoding to apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine.real, not accoutning for usr.lib.snapd.snap-confine.real.rev [12:51] right [12:51] I assume by .rev you mean the core revision [12:51] yes [12:51] I forgot what it looked like for real [12:51] I was trying to explain that IMO this is not needed because the code that manages the per-rev profile is already doing everything we need [12:52] snap.core.2898.usr.lib.snapd.snap-confine [12:52] that's an example ^ [12:52] as it will derive the contents of the .rev file from the profile stored in the core snap [12:52] and then load it [12:52] is there more that we need to manage for per-revision profiles? [12:52] niemeyer, mvo i am taking my son to the hospital to make a bone scan [12:53] cachio: uh, good luck! [12:53] mvo, TX, should be back soon [12:54] sergiusens, hi! unsure if you saw but the bug from yesterday was fix released last night [12:54] mvo: aftering having played a bit with "snap repair", do you think it would make sense to print as field the mtime of the log file do have an idea one things have run? [12:54] s/do have/to have/ [12:54] jdstrand: does my explanation make sense? [12:54] Thanks for the note, and good luck there! [12:54] zyga-ubuntu: looking at the above profile, and reminding myself what shows up in aa-status, I think there may not be a bug. but it seems weird that that code is only loading .real. doesn't that mean we might load .real when we don't have to? [12:55] jdstrand: aha, interesting question; yes, when we are rexeced we don't need to reload the .real profile [12:55] mvo: mmh, s/idea one/idea when/ [12:55] jdstrand: just write the policy and wait for the setup code to reload the right file [12:55] zyga-ubuntu: like, when we are execing the snapd in /snap/core/..., it is going to reload .real [12:56] jdstrand: right, I agree [12:56] oh, standup time [12:56] brb [12:58] pedronis: yeah, I think this is very nice [12:58] pedronis: we should also include it in the log in case of fs corruption [12:58] pedronis: I can add that after the meeting [12:59] thanks [12:59] I'll also rework my branch with some details, so it's ready when review/spread tests are back to being helpful === ShalokShalom_ is now known as ShalokShalom [13:05] sergiusens: ok, but do you happen to know why my 'snapcraft cleanbuild' doesn't do anything? is it normal that i don't get any output? [13:05] ppisati that is not normal, no [13:05] ppisati can you add --debug? [13:06] ppisati also check ps and see that we are not stuck on a lxc call [13:06] nessita thank you [13:06] ogra_: just so you know, we now have this page https://developer.ubuntu.com/target-platforms/boards giving an overview of available images/boards, it's not core exclusive, so if you have others in mind I don't know of (only requirement is to have flashing steps somewhere on the web and a somewhat official image working), let me know [13:08] (also, you can pass the search term through the url, eg https://developer.ubuntu.com/target-platforms/boards#arm64 to have a filtered view) [13:10] sergiusens: root 17092 0.0 0.0 160904 1396 ? Ssl 14:00 0:00 /usr/bin/lxcfs /var/lib/lxcfs/ [13:10] root 18245 0.0 0.0 95016 5472 ? Ss 14:02 0:00 [lxc monitor] /var/lib/lxd/containers first [13:10] flag 19422 97.2 0.5 346624 89224 pts/19 R+ 15:07 2:21 /usr/bin/python3 /usr/bin/snapcraft -d cleanbuild --debug [13:10] flag 19634 0.0 0.0 130284 980 pts/20 R+ 15:09 0:00 grep --color=auto -e lxc -e snapcr [13:10] ops [13:10] sorry [13:10] sergiusens: http://pastebin.ubuntu.com/25586157/ [13:20] ppisati strange that no name for the assigned container is being shown. Can you `lxc list` and figure it out and then `lxc exec -- ps -auxww` [13:26] davidcalle, i have five "community" images too ... not sure if we want to mention them (for nanopi, nanopi-air, beaglebone, hummingboard and sabrelite) [13:27] (and three more boards for "community" images in the pipe) [13:27] sergiusens: http://pastebin.ubuntu.com/25586244/ [13:31] ppisati there is no snapcraft running in that one :-/ [13:32] ppisati and it is not named after the petname triplet we use for those containers [13:32] ppisati oh wait, have you ever used cleanbuild to build kernels? [13:32] ppisati: watch your step! [13:32] ppisati we tar up everything in the source and only then create a container [13:33] and push that tarball into the container [13:33] if you want a somewhat more streamlined version of this try to do `SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft` [13:39] sergiusens: never used cleanbuild, first time [13:40] * ogra_ has never seen cleanbuild fail before :) [13:40] ogra_: it would be a good idea to give them more visibility, where can I learn more about these images? Do you have repos for each or maybe a wiki page? [13:41] ogra_: (I've noticed your forum posts on images, but wondering about other places you might have) [13:42] davidcalle, a wiki is still on my TOD (just didnt get to that yet) ... images are in my people.u.c home at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ ... gadgt source is at my GH account, kernels are scattered around between GH and launchpad [13:42] i need to do some cleanu for the kernels ... and eventually give ppisati a patch for the allwinner support [13:43] davidcalle, i'll try to get to the wikipage over the NYC week and then we can look how/if we link it from some official place [13:43] are you at the rally ? [13:44] ogra_: I think the boards page can be the right place for these (with an official/community images distinction) [13:44] ogra_: no, I won't be in NYC [13:46] ogra_ ppisati so my suspicion is that it feels stuck given the size of the source, we need a nice spinner to show it is not stuck, if you go the envvar path and using a local lxd remote (default), then you get nice bind mounts instead which would speed things up and not pollute your environment and if it is the first run it would feel as close as a [13:46] cleanbuild can feel [13:50] niemeyer: do you have time for a quick chat today? I'm writing some notes for a topic for next week and I would like a sanity check that I'm not thinking not useful stuff [13:50] pedronis: Definitely [13:51] niemeyer: now? or in a bit? [13:51] pedronis: My calendar is quite open today [13:51] pedronis: Now works [13:51] let's do now [13:51] then [13:51] pedronis: Ok, coming back to the standup [14:00] sergiusens: ah, if i wait long enough, the builds finally start - sorry for the noise... :| [14:01] no worries, ppisati if you want, feel free to log a bug that it feels stuck and we will sort it with proper feedback [14:05] * zyga-ubuntu checks 14.04 support [14:06] a few more tweaks and unit tests and I'll propse NFS [14:06] How does one get aliases defined in snapcraft.yaml to work? [14:07] for example, if I have this: usb-only: [14:07] command: bin/usb-only [14:07] plugs: *standard [14:07] aliases: [usb-only] [14:07] bladernr: that's a deprecated approach, next version of snapcraft will say as much [14:08] OK, but I'm not developing on the enxt version of snapcraft, I'm using the snapcraft available today. [14:08] e.g. 2.34 [14:09] bladernr: that's not relevant, since snapd from 2.26 will ignore that field [14:09] bladernr: the new world is described here: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18 [14:09] bladernr: automatic aliases are something now only controlled through the store [14:09] bladernr: you'll just need to make a forum request about the aliases you need [14:10] bladernr: see the last session in that forum topic [14:10] sorry [14:10] section [14:10] and what If I don't want to distribute via the ubuntu snap store? For developpment purposes, I want to distribute the snap from a local store on my MAAS server. [14:11] because uploading a snap to the ubuntu tore takes me upwards of 30 minutes each upload [14:11] or 5 seconds locally [14:11] bladernr: even with delta uploads? [14:11] bladernr: what's a local store? [14:11] roadmr - no idea what that is. [14:11] bladernr: snapcraft should automagically upload just the delta between your last upload and the current one [14:11] PR snapd#3953 opened: snap-confine: fix base snaps on core [14:12] pedronis, I want to serve snaps locally for my maas server (this is orthogonal to the alias question). I just want to push a snap to my maas server and then on a node, snap install from my maas server [14:12] I work around that nowy with a bunch of scp [14:12] bladernr: well if it's supported local store it will still use the same mechanisms [14:12] bladernr: you do that in a script presumably? [14:12] you'd have to "it's possible for the user the setup manual aliases under their control:" [14:12] sigh... [14:12] there will be a store level decclaration [14:13] coming from the main store [14:13] or local (but that is not designed yet at all) [14:13] Ok, it seems maybe my expectations are too high. [14:14] Let me start from the beginning... I have a snap, I want ot put that snap on a node behind my MAAS. What is the way to do that? Do I upload to the ubuntu sture and dhen download it locally? [14:14] err... by download, I mean snap install blah on my node. [14:15] we are working on proxy store that can be setup localy [14:15] but yes for a while all snaps will go through the main store [14:16] So in the future, assuming I start using snaps exclusively for my work, a local, standalone distribution point is a hard requirement. I CAN NOT depend on some internet based snap store. [14:16] will that proxy store replace the stuff that's documented now for local hosting but doesn't work anylonger? [14:16] yes [14:16] e.g. the stuff at the bottom of https://snapcraft.io/docs/core/store [14:16] ahhh ok [14:16] that will help then [14:17] first version will do proxying/caching and some local control [14:17] unfortunately, most of my customers are in segregated environments that likely have zero internet connectivity. [14:17] but it will grow more features over time [14:17] bladernr: you probably want to talk to people driving that about your requirements [14:19] pedronis, ahh thanks. [14:23] is it possible to create a branch on snapd with the same content we have on edge channel? [14:24] mvo, ~ [14:24] cachio: a branch on snapd? (I think it's possible but I may be unclear about what you want) [14:25] roadmr, I need a branch with the same content than the core snap on edge channel [14:26] cachio: ah, the *core* snap. [14:26] cachio: do you know which revision of the core snap that is? (as in, that sequential revision/upload number you get) [14:26] cachio: that should be lp:snapd-vendor [14:26] cachio: well, roughly, let me double check [14:27] cachio: (does mvo's answer work for you? I may be talking about different kind of branch here haha) [14:28] roadmr, yes, mvo has the solution :) [14:28] awesome! disregard me then :) [14:30] + exportfs -r [14:30] exportfs: localhost:/srv/nfs: Function not implemented [14:30] hmmm [14:30] * zyga-ubuntu fires up 14.04 to experiment with nfs [14:33] mvo, I got it, I'll implement the change to clone that repo instead of the github one [14:34] mvo, that, when we run on edge [14:38] PR snapd#3954 opened: snap: introduce structured epochs [14:38] ^^ tadaa ^^ [14:38] now to take a break, have some tea, and then fix some tests [14:38] enjoy :) === JanC_ is now known as JanC === JoshStrobl|Store is now known as JoshStrobl === chihchun is now known as chihchun_afk [14:59] mzanetti ping === chihchun_afk is now known as chihchun [15:05] mzanetti: re the ipv6 problem that ondra told me about, I wonder if it makes a difference if you set "GODEBUG=netdns=cgo" in /etc/environment, i.e. if that changes the behaviour [15:13] mvo, hey, i'm getting http://pastebin.ubuntu.com/25586715/ with master, do we have a new dependency or something? [15:17] so i have a rather urgent, but perhaps obvious, classic snap question. We are building git-ubuntu on LP usingn artful. However, the core snap is (aiui) still 16. The python3 in artful is now linnked against the new glibc in artful, and (looking at unsquashfs -l), even though it's a dependency, the artful glibc is not in my snap. How isthis supposed to work on xenial, e.g. Even on artful, potentially. [15:17] i get messages like: /snap/git-ubuntu/x1/usr/bin/python3: relocation error: /snap/git-ubuntu/x1/lib/x86_64-linux-gnu/libdl.so.2: symbol _dl_catch_error, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference [15:18] i'm 'faking' PATH/LD_LIBRARY_PATH confinement in my snap [15:18] also what's odd is that if I have the CORE_SNAP default library paths first in LD_LIBRARY_PATH, it works fine, but then stuff I've installed in my snap (e.g., xz) fail, because the xz from the core snap is a different version than the one in artful [15:20] confusingly, right now, the snap segfaults on artful hosts! ... i think this is all tied together, but i'm not sure [15:21] pstolowski: hm, with master - strange. what machine is failing? 14.04? [15:21] mvo, hi, is it possible to explicitly define the writable partition in gadget.yaml? it is not usually defined: http://paste.ubuntu.com/25586755/ [15:22] nacc: why are you building on artful? [15:23] Chipaca: i need newer dependencies than are on artful [15:23] *that* are [15:24] (e.g., git from artful, etc.) [15:24] mvo, 16.04, it's my xenial system [15:24] nacc: can't you pull them from git or something like that? [15:25] Chipaca: i'm trying to make sure what we build (e.g., dpkg) is built exactly like the debs, this is for working on source package uploads to Ubunut [15:25] *Ubuntu [15:25] Chipaca: if the answer is that I shouldn't be using the Artful option, I really think it should be disabled in LP [15:26] nacc: if the libc in artful diverges, then yes, I don't think you should be building on artful [15:26] nacc: but … maybe i'm wrong, maybe there's a trick to it that sergiusens or mvo know about? [15:27] Chipaca: that seems ... horribly broke [15:28] Chipaca: right? that it's even an optio? [15:28] I don't see how it can work :) [15:28] I'm also very confused why LD_LIBRARY_PATH's order (core snap libs then my snap's libs) works but the other order (with the same contents!) fails [15:29] nacc: wrt it being an option, you could be building a snap that doesn't use the libc, for example [15:30] Chipaca: unless you recurse and ensure that nothing you depend on uses libc, it doesn't work [15:30] nacc, if you reallly are artful i'd suggest to go artfull all the way and simply drop the core snaps LD_LIBRARY_PATH completely [15:31] Chipaca: e.g., i'm using the python3 from artful (apparnetly, even though it's a dependency of my stage-packages, not explicitly listed) [15:31] (and indeed ship *all* yu need in your snap) [15:31] ogra_: doesn't work [15:31] ogra_: there's *no* libc in my sap [15:31] *snap [15:31] ship one ;) [15:31] ogra_: so i have to explicitly list every dependency? [15:31] (might need some hacking since snapcraft willl ty to strip it out) [15:31] and every depdendency of every dependency [15:31] nacc: it sounds to me like your issue is more with snapcraft that snapd [15:31] nacc: may i suggest you try the rocketchat? [15:32] Chipaca: i have non idea where it is :) [15:32] nacc: rocket.ubuntu.com/channel/snapcraft [15:32] more snapcrafters there [15:32] Chipaca: ok [15:32] nacc: wrt recursing and ensuring, yes, you are responsible for all your dependencies [15:33] Chipaca: i feel like htat's pretty false advertising :) [15:33] Chipaca: as obviously if i'm installing python3-keyring from artful, i want python3 from artful which wants libc from artful [15:33] nacc: what part is false advertising? [15:34] Chipaca: what I just said -- i'm asking for a package to be staged, which obviously means its dependencies [15:34] nacc: right, you're talking about what you tell snapcraft and what it does [15:34] nacc: i'm saying, it's your responsibility to get all the dependencies into the snap [15:35] yeah, that's the false part (to me). i'll ask in rocket [15:35] Chipaca: yep, i get that [15:35] I thought I was! :) [15:35] nacc: yeah [15:35] nacc: snapcraft might not support doing that, or there might be a flag for "ship all of libc" that defaults to 'no' [15:35] yeah [15:35] snapcraft has a blacklist for some packages [15:35] in the early days there was a long list of what is libc, that was skipped for packing [15:35] * zyga-ubuntu scratches head with nfs on trusty [15:36] libc is ne of them iirc [15:36] Chipaca: yeah, i can see that [15:36] but i haven't kept up; it might be smarter today [15:36] but the LP builder needs to be smarter, it feels like [15:36] at least a flag should be doable :-D [15:36] or somethingn does :) [15:36] nacc: snapcraft, probably [15:36] yeah [15:36] if we want this to work at least [15:36] I guess that's true [15:36] but using artful packages is a bad idea in general ... and in classic even wrse [15:36] nacc: of course, the promise-the-sky answer is that what you want is an artful _base_ [15:36] :-) [15:37] Chipaca: right exactly [15:37] and honnestly, at first, that's what i thought i was goingn to get [15:37] build o artful, use artful as your base [15:37] nacc: bases aren't there that [15:37] there yet* [15:37] yea [15:37] Chipaca: ok [15:37] thats still a bit out [15:37] 2.28 will have basic support! 2.29 will be better [15:38] but we wont have usable base snaps yet [15:38] woo! [15:38] 10 GOTO 10 [15:38] * Chipaca snaps that [15:38] even idf snapd can handle them [15:38] mvo: i'll leak that bit of info to whoever it was said we supported android os [15:38] (and my bet is also that we wont look into having an artful base as first thing) [15:38] yeah [15:39] well, it was just surprising, this all worked just until libc moved [15:39] (in artful) [15:39] Chipaca: *cough* [15:39] so i hadn't considered any of this :) [15:39] darn, that was easy, nfs was just disabled on startup [15:39] mvo: 2.28 will have basic support! [15:39] mvo: you can't take it back now [15:39] nacc: sorry :-( good thing artful's release is ages away still right? [15:39] Chipaca, 10 print hello; 20 goto 10 [15:40] Chipaca: well, the snap is already published :) [15:40] Chipaca: and was working until yesterday [15:40] when it happened to rebuild with the new libc [15:40] i think, at least [15:40] i wonder how many other (classic) snaps are now dead [15:40] yeah [15:40] blame infinity ! [15:40] well, i don't know if anyone was 'clever' like me :) [15:40] * ogra_ bets many people were [15:41] well, 1. classic snap, 2. built on artful [15:41] cjwatson: may be able to tell us if it's searchable [15:41] (from a LP admin view, that is) [15:41] * ogra_ just had a discussion this week about LP offering artful builds ... [15:42] ogra_: as in, it shouldn't? :) or what was the discussion? [15:42] seems you are the first one being hit by it :) [15:42] not easily searchable [15:42]