IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 19 October 2019 (all times are UTC)
| 05:04 | <alkisg> Leolo_2: is centos 6 using systemd?
| |
| 05:11 | Google says it's using sysvinit; so nah; let's keep ltsp19 only for systemd distributions
| |
| 05:12 | But I thought that bcg already had working packages for ltsp5 on centos...
| |
| 05:17 | quinox has left IRC (quinox!~quinox@ghost.qtea.nl, Quit: WeeChat 2.4) | |
| 05:19 | quinox has joined IRC (quinox!~quinox@ghost.qtea.nl) | |
| 06:38 | woernie has joined IRC (woernie!~werner@p5B296156.dip0.t-ipconnect.de) | |
| 07:04 | <alkisg> woernie: did you manage to solve all the issues?
| |
| 07:14 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 07:23 | adrianor1 has joined IRC (adrianor1!~adrianorg@179.179.75.131) | |
| 07:25 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.173.66, Ping timeout: 240 seconds) | |
| 07:46 | Leolo_2 has left IRC (Leolo_2!~fil@184-75-132-167.dr.cgocable.ca, Ping timeout: 240 seconds) | |
| 07:52 | <bcg> my work is for centos 7, not 6
| |
| 07:54 | <alkisg> Ah they're not compatible? E.g. ltsp5 runs from ubuntu 12.04 to 18.04 without changes...
| |
| 07:55 | <bcg> centos 6 is initd and very old, 7 is systemd.
| |
| 07:55 | <alkisg> OK, ty
| |
| 07:56 | Btw I'm trying to move ltsp.org and epoptes.org to *.github.io sites, if anyone knows jekyll, I'd welcome some initial pointers...
| |
| 08:58 | statler has joined IRC (statler!~Georg@p5B30EE2F.dip0.t-ipconnect.de) | |
| 09:38 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 09:38 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
| 11:12 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 11:13 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
| 11:14 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Max SendQ exceeded) | |
| 11:16 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
| 11:17 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Client Quit) | |
| 11:18 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
| 11:27 | ltsp_user35 has joined IRC (ltsp_user35!4fd398fa@p4FD398FA.dip0.t-ipconnect.de) | |
| 11:30 | ltsp_user35 has left IRC (ltsp_user35!4fd398fa@p4FD398FA.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 13:08 | ltsp_user57 has joined IRC (ltsp_user57!53371506@6.red-83-55-21.dynamicip.rima-tde.net) | |
| 13:09 | <ltsp_user57> hi
| |
| 13:13 | ltsp_user57 has left IRC (ltsp_user57!53371506@6.red-83-55-21.dynamicip.rima-tde.net, Remote host closed the connection) | |
| 14:25 | <alkisg> OK https://epoptes.github.io is starting to be readable; https://ltsp.github.io will follow within the week...
| |
| 17:05 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 17:21 | <alkisg> vagrantc: the new epoptes site, based on jekyll: https://epoptes.github.io - I will do ltsp.github.io with the same software/theme in a couple of days...
| |
| 17:29 | <vagrantc> alkisg: still looks about the same, but with very wide margins
| |
| 17:29 | :)
| |
| 17:31 | alkisg: so, would it be worth having ltsp19 ship "ltsp-server" instead of "ltsp" which is marked with Provides: "ltsp" ?
| |
| 17:31 | long-term, i think it'd be nicer to just ship ltsp.
| |
| 17:34 | and i'm torn on shipping an ltsp-server metapackage regardless
| |
| 17:35 | but if we'll ship "ltsp-server" as part of ltsp 19.x ... it'd be good to do that on the initial upload so it doesn't get stuck in NEW
| |
| 17:43 | <alkisg> vagrantc: ltsp would be the client package
| |
| 17:44 | So having ltsp-server provide ltsp, sounds a bit strange
| |
| 17:44 | (08:29:46 PM) vagrantc: alkisg: still looks about the same, but with very wide margins ==> the web gurus say it's better that way, people focus on reading narrow columns. Go figure.
| |
| 17:45 | But comparing to the existing ltsp.github.io. it's surely better
| |
| 17:45 | We may ship an ltsp-server metapackage though, unrelated to provides etc
| |
| 17:49 | <vagrantc> alkisg: the provides trick was just to workaround the NEW queue ... but long-term i don't think it's the right way
| |
| 17:50 | e.g. i could upload to experimental today, but would have to rename a bunch of the files in debian/ltsp.* -> debian/ltsp-server.* and update debian/control ... but could probably upload it today instead of waiting
| |
| 17:50 | <alkisg> vagrantc: I mean, if one wants to install ltsp in a chroot, he'd do "apt install ltsp", and he'd see ltsp-server getting installed, and get confused
| |
| 17:50 | (while he'd only want ltsp-client)
| |
| 17:50 | <vagrantc> alkisg: yes, it's not ideal, like i say, it's immediacy vs. correctness :)
| |
| 17:50 | <alkisg> I could prepare a metapackage tomorrow
| |
| 17:51 | <vagrantc> alkisg: but what i'm hearing is you'd rather wait :)
| |
| 17:52 | alkisg: so, ltsp-server metapackage ... then we might have to handle upgrades or something... i guess it coudl just be in README.Debian ...
| |
| 17:53 | existing installs wouldn't be able to have them side-by-side ...
| |
| 17:53 | or NEWS.Debian
| |
| 17:56 | <alkisg> If we ship what you said, they can be installed side-by-side?
| |
| 17:56 | <vagrantc> no
| |
| 17:57 | side-by-side installs would mean ltsp 19.x would have to only ship "ltsp" and not an ltsp-server metapackage ... (sort of)
| |
| 17:58 | the sort of being that any existing installs would probably continue to work, but you'd loose the infrastructure to update old installs ...
| |
| 17:59 | alkisg: if we shipped "ltsp" and ... "ltsp-default-install" with depends and/or recommends set appropriately, it could co-exist with ltsp5
| |
| 17:59 | <alkisg> I think we don't want to bother with automatically upgrading old installs
| |
| 17:59 | <vagrantc> agreed
| |
| 18:00 | basically, what i would prefer moving forward is "ltsp" and a metapackage that is not named "ltsp-server" to avoid conflicting with the existing ltsp-server packages
| |
| 18:00 | not sure what a name for the metapackage should be
| |
| 18:01 | would it be so bad for "ltsp" to recommends all the stuff currently in suggests?
| |
| 18:01 | <alkisg> We'd need an ltsp-client package otherwise
| |
| 18:02 | Currently, the ltsp package contains all the code, but corresponds to the ltsp-client package
| |
| 18:04 | Maybe we could grow an ltsp-server-dnsmasq package, but that would just avoid the installation line, nothing major
| |
| 18:07 | Maybe the best is to just leave it in the new queue... we gain the ability for them to coexist
| |
| 18:11 | In the future, we might actually desire a long installation line... "select one of the following lines, depending on what you want... dnsmasq? isc-dhcp? ipxe? syslinux? grub? etc"
| |
| 18:12 | <vagrantc> i guess it could make default assumptions based on what's installed?
| |
| 18:12 | a little counter to how debian packages generally work
| |
| 18:13 | <alkisg> I don't think packages can do that. Unless if you mean an `ltsp install` line, in which case we don't need an ltsp-server package
| |
| 18:13 | <vagrantc> well, last i looked, it was worth landing in experimental (which is good to do since it's going through NEW anyways)
| |
| 18:13 | so ... tag 19.10 ?
| |
| 18:13 | <alkisg> Sure!
| |
| 18:13 | I'll work on the site for the next days, soI won't be touching the code
| |
| 18:14 | After that, I'll check if it runs on xenial etc, and modify whatever's needed
| |
| 18:14 | <vagrantc> 19.11 is right around the corner anyways :)
| |
| 18:14 | * alkisg likes that versioning scheme | |
| 18:14 | <alkisg> Also mesa and drm are going to following, and maybe even xorg
| |
| 18:14 | I'll switch epoptes to that too
| |
| 18:15 | <vagrantc> it's one thing ubuntu did that i wish debian would adopt
| |
| 18:17 | <alkisg> Meh multitasking creates the stupidest typos... "following" instead of "follow it"...
| |
| 18:17 | <vagrantc> heh
| |
| 18:18 | alkisg: so you're fine with me tagging? i think there were a few more minor typos i'd like to clean up, but otherwise it seemed ready enough for the NEW queue waiting game
| |
| 18:19 | alkisg: also, is it plausible for you to start doing signed tags?
| |
| 18:21 | <alkisg> vagrantc: sure, go ahead and tag please,
| |
| 18:22 | re: signed tags, no objection at all, I'll just need to read up on how to do that
| |
| 18:28 | <vagrantc> git tag --sign TAG vs. git tag TAG
| |
| 18:28 | and have access to a signing key
| |
| 18:28 | of course :)
| |
| 18:34 | alkisg: i was a bit configused with ltsp image -m in the ltsp-image manpage ... passing mksquashfs arguments requires using spaces ... and it worked fine for me to add spaces ... but the man page warns against using spaces?
| |
| 18:38 | <alkisg> vagrantc: I mean, "dont do this:" ltsp image -m param1 param2, but -m "param1 param2"
| |
| 18:38 | If the explanation is lacking, let's fix it
| |
| 18:39 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 18:39 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
| 18:40 | <vagrantc> alkisg: i'll try to update the wording now that it's clear what you mean :)
| |
| 18:57 | alkisg: we should record hashes of the downloaded binaries and check them, at least...
| |
| 18:57 | alkisg: which means keeping copies of all the versions you might ever ship
| |
| 19:00 | alkisg: e.g. https://example.org/downloads/binaries/sha256/asdfasdf1214436.../memtest.0
| |
| 19:00 | <alkisg> vagrantc: that would require us shipping a new ltsp version for each ipxe update
| |
| 19:00 | <vagrantc> alkisg: no, you keep the old ones there
| |
| 19:01 | <alkisg> I mean, if we upload a new ipxe.efi, then the old ltsp doesn't know its hash
| |
| 19:01 | <vagrantc> true
| |
| 19:01 | <alkisg> So a new ltsp is needed before the new ipxe.efi can be used
| |
| 19:01 | <vagrantc> but it also means that someone else can't put arbitrary stuff on that URL
| |
| 19:01 | <alkisg> At which point, it would be better to just include them in the binary
| |
| 19:01 | In the .deb
| |
| 19:01 | <vagrantc> alternately, signed binaries
| |
| 19:01 | can't ship binaries in debian packages that aren't built from source
| |
| 19:02 | but not having any trust path beyond https is ... dubious
| |
| 19:02 | <alkisg> What's microcode?
| |
| 19:03 | <vagrantc> in debian, microcode not build from sources is not in main
| |
| 19:03 | e.g. technically outside of debian
| |
| 19:03 | <alkisg> Btw, we'll be able to avoid all those once debian packages them
| |
| 19:03 | How can we sign/verify binaries?
| |
| 19:03 | Also, npm * is in debian
| |
| 19:04 | And it's downloading things from online, without hashes
| |
| 19:04 | wget too
| |
| 19:04 | <vagrantc> i'm not saying nothing does that, but it's very much frowned upon to download an execute arbitrary code
| |
| 19:04 | with no trust path...
| |
| 19:05 | <alkisg> Why isn't https enough?
| |
| 19:05 | <vagrantc> because certificate authorities that have demonstrated little to no competence are still able to certify all web sites?
| |
| 19:07 | the best way forward is to package what we need ... failing that, ship signed sha256sum files and include the public key ltsp trusts in ltsp and verify the signature on the signing file (or each individual file)
| |
| 19:08 | e.g. checksums.signed includes checksums for the current files, and are signed by a trusted key.
| |
| 19:08 | <alkisg> The initial though was to download them directly from boot.ipxe.org,
| |
| 19:08 | but then I thought I would avoid putting strain on their servers...
| |
| 19:08 | <vagrantc> i balked at it earlier too :)
| |
| 19:09 | <alkisg> OK I guess we can include a public signature
| |
| 19:09 | <vagrantc> so, i'd still be willing to push to experimental without that, but i wouldn't want it to move to unstable/testing/stable in Debian
| |
| 19:10 | alkisg: what exactly is needed to package it?
| |
| 19:10 | alkisg: some custom ipxe? memtest86*?
| |
| 19:10 | <alkisg> And the ltsp developers would keep the private key a secret? Or would I be the only one that would have it?
| |
| 19:11 | <vagrantc> alkisg: alternately, you have a keyring for validity ... e.g. my key, your key, etc.
| |
| 19:11 | <alkisg> vagrantc: afaik, we'd just need to uncomment a few lines in the debian ipxe package
| |
| 19:11 | <vagrantc> alkisg: the memtest stuff seems like optional features, but ipxe seems kind of fundamental :)
| |
| 19:11 | <alkisg> And include the targets in the deb, of course
| |
| 19:12 | We could also use /boot/memtest86+.bin, but it's less compatible, and it doesn't allow getting back to the menu with Esc
| |
| 19:12 | And I guess all distributions would need to do those changes too; not sure if ipxe is there in centos or fedora
| |
| 19:13 | And, we wouldn't be able to ship newer ipxe's outside of the distribution channels; that's not too bad I guess, we can tell users to manually download newer versions if they need them
| |
| 19:14 | Also, I'm not sure that ipxe for x86 would be there in non-x86 architectures
| |
| 19:14 | Or grub.signed, if we implement that
| |
| 19:15 | <vagrantc> yeah, not sure what architectures ipxe supports
| |
| 19:15 | <alkisg> So I'd have a hard time making a raspberry an ltsp server for x86 clients
| |
| 19:15 | <vagrantc> with debian and family, you can use multi-arch to get cross-architecture dependencies
| |
| 19:16 | well, not dependencies exactly...
| |
| 19:16 | requires more sysadmin work, but you're talking about cross-architecture servers, so ...
| |
| 19:16 | <alkisg> Additionally, if I wanted to boot ubuntu from debian, with secure boot on... I'd have a hard time getting grub.signed from ubuntu, installed on debian
| |
| 19:17 | I would be much easier if we just used signatures
| |
| 19:17 | <vagrantc> fair enough
| |
| 19:18 | since it's a number of fairly small binaries, might be best to just sign them directly, too
| |
| 19:18 | skips the complication of a signed checksum file (and potential security mistakes)
| |
| 19:19 | still not immune to downgrade attacks ... but we can only do so much :)
| |
| 19:19 | <alkisg> Not sure how to "sign binaries"...
| |
| 19:19 | They're not elf
| |
| 19:19 | <vagrantc> you can just sign arbitrary data with gpg
| |
| 19:20 | <alkisg> And is it still bootable?
| |
| 19:20 | <vagrantc> no, you'll need to extract the binary from the signed result, or used detached signatures
| |
| 19:20 | <alkisg> ...or a checksum file? :)
| |
| 19:21 | <vagrantc> same problem, with an added layer of indirection
| |
| 19:21 | <alkisg> I think the code would be simpler... but I don't mind with whatever we can do in shell
| |
| 19:23 | <vagrantc> gpg --sign FILE # produces FILE.gpg
| |
| 19:23 | gpg -d FILE.gpg > FILENEW
| |
| 19:23 | sha256sum FILE FILENEW
| |
| 19:23 | the latter just to verify proof that they match
| |
| 19:24 | <alkisg> OK but people can't just wget them if they want
| |
| 19:24 | They'll need to know that dance
| |
| 19:25 | With a separate file, it might be easier for the users to select arbitrary files from history versions
| |
| 19:26 | <vagrantc> you mean a checksum file?
| |
| 19:27 | the dance should be implemented in the ltsp tool, no?
| |
| 19:27 | <alkisg> Well someone might want to get ipxe.efi to put it in his boot partition
| |
| 19:27 | Or, get ipxe.efi from upstream
| |
| 19:27 | It would be confusing to have to un-gpg them
| |
| 19:28 | I do like to keep things as simple as possible for the users... if possible...
| |
| 19:28 | As not all of them are sysadmins; some are teachers and have never heard of gpg
| |
| 19:28 | <vagrantc> which is why the "ltsp" tool should handle it for them?
| |
| 19:29 | <alkisg> There's no ltsp tool in a standalone pc where the user would want to download ipxe.efi
| |
| 19:29 | <vagrantc> and then they just copy ipxe.efi from where the tool downloaded it to?
| |
| 19:29 | <alkisg> Hmm
| |
| 19:29 | <vagrantc> isn't that outside the scope of "ltsp" then?
| |
| 19:29 | <alkisg> I don't know it sounds complicated
| |
| 19:29 | Is it insecure to use a separate file?
| |
| 19:29 | <vagrantc> e.g. they either have "ltsp" and they use the tool, or they do things manually
| |
| 19:30 | <alkisg> "what is ipxe.efi.signed?" - I'm trying to avoid hearing that question from users
| |
| 19:30 | <vagrantc> alkisg: there have been some historic mistakes around signing data, and i think my simple example even implemented some of those mistakes :)
| |
| 19:30 | <alkisg> Like ubuntu-live.iso.signed; they avoided that
| |
| 19:31 | <vagrantc> alkisg: you can have both copies of the file present ... signed and unsigned ... and maybe even in a separate directory ... but the tool should handle it securely.
| |
| 19:31 | well... "securely" :)
| |
| 19:32 | alkisg: anyways, happy to postpone this till after ltsp gets through NEW
| |
| 19:32 | <alkisg> OK, great. I don't mind the separate signatures/checksums file, but I don't like the ipxe.efi.signed idea...
| |
| 19:33 | <vagrantc> is there a developer TODO file somewhere? or i guess i file an issue
| |
| 19:34 | <alkisg> I think I had a TODO in the wiki, and then I deleted it in favor of issues
| |
| 19:34 | <vagrantc> makes sense
| |
| 19:36 | so then it comes down to: sha256sum * > checksums.sha256 && gpg --detach-sign checksums.sha256
| |
| 19:37 | (or sha512, or some other reasonably secure checksum tool)
| |
| 19:37 | <alkisg> Nice
| |
| 19:37 | And we'd ship our keyrings in the ltsp package
| |
| 19:38 | <vagrantc> and then wget https://..../checksums.sha256 https://..../checksums.sha256.gpg && gpgv --keyring path/to/keyring.gpg checksums.sha256.gpg && sha256sum -c checksums.sha256 .... i think
| |
| 19:38 | could also do clearsigned checksums files, but that has had some security problems in the past, but it would also mean a single file.
| |
| 19:40 | see https://deb.debian.org/debian/dists/buster/InRelease vs. https://deb.debian.org/debian/dists/buster/Release.gpg + Release
| |
| 19:41 | those are more complicated examples than just using sha256sum ...
| |
| 19:41 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 19:41 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
| 19:42 | <vagrantc> but they illustrate the differences ... tricky part is if someone man-in-the-middles InRelease and appends stuff to it
| |
| 19:42 | the output of gpg hasn't exactly been always correct in that case
| |
| 19:42 | <alkisg> Ouch; that sounds.... like a bug in gpg?!
| |
| 19:43 | Shouldn't it just say "this messaged has been tampered with?"
| |
| 19:43 | <vagrantc> sort of
| |
| 19:43 | <alkisg> *message/content/whatever
| |
| 19:43 | <vagrantc> it's complicated :)
| |
| 19:43 | <alkisg> Also, maybe we could just check our https certificate?
| |
| 19:44 | (ourselves, instead of leaving it just up to wget)
| |
| 19:44 | <vagrantc> like against a specific certificate authority?
| |
| 19:44 | <alkisg> Against our own certificate file in ltsp.deb
| |
| 19:44 | <vagrantc> i treat https as either the belt or suspenders, but if you really need to hold pants up, use both :)
| |
| 19:45 | shored has left IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi, Read error: Connection reset by peer) | |
| 19:45 | shored has joined IRC (shored!~shored@87-92-122-167.bb.dnainternet.fi) | |
| 19:46 | <vagrantc> i think https actually helped against the InRelease attack actually, even with self-signed certs ... but that's a whole different story
| |
| 19:47 | alkisg: so, there are a variety of options
| |
| 19:47 | i'll file an issue
| |
| 19:47 | <alkisg> E.g. I see `wget --ca-certificate=file`, not sure if it's safe enough if we just provide that file
| |
| 19:51 | <vagrantc> github might change which ca they use, and break ltsp until we figure out what they changed to
| |
| 19:51 | and figure out weather the change was legitimate
| |
| 19:52 | this is why i would prefer to just blindly trust the certificate authorities and also provide another independent signed checksum mechanism for the files
| |
| 19:52 | where we have more control over the signing keys
| |
| 19:54 | well, blindly trust, as pretty much all web browsers blindly trust
| |
| 19:55 | i guess there's some support for pinning... but that's probably a lot harder than just shipping signed checksum files
| |
| 19:59 | hrm. can't find the typo i found earlier ... found a new one though... time to tag and upload, i guess
| |
| 20:06 | woernie has left IRC (woernie!~werner@p5B296156.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 20:33 | <vagrantc> alkisg: uploaded to experimental/NEW ... now to wait...
| |
| 20:33 | unless i messed something up
| |
| 20:36 | <alkisg> Yey!
| |
| 20:37 | vagrantc: so now we're waiting for the ftp masters to review?
| |
| 20:38 | And if it migrates to testing, will ltsp5 be removed from testing?
| |
| 20:39 | (if so, I should do a last upload to the ltsp5 ppa)
| |
| 20:40 | <vagrantc> alkisg: the way it's currently packaged, they coexist without issues
| |
| 20:40 | at least, i *think* they can coexist
| |
| 20:40 | oh, but...
| |
| 20:40 | <alkisg> vagrantc: isn't it a problem if they both have source:ltsp?
| |
| 20:40 | <vagrantc> oh, but will need to upload an ltsp5 source package at some point.
| |
| 20:40 | yeah, exactly
| |
| 20:41 | <alkisg> Do we want that? To maintain ltsp5 for another... 10 years or so?
| |
| 20:41 | <vagrantc> no, i don't
| |
| 20:41 | <alkisg> Maybe we can just omit the ltsp5 package then, and just point users that need it to a ppa
| |
| 20:42 | <vagrantc> so it can't exist in the archive, but they could, for example, install the ltsp 5.x packages from buster on a bullseye system, or install the new ltsp 19.x packages from buster-backports when they land
| |
| 20:42 | <alkisg> Sounds fine to me
| |
| 20:42 | Also, I like the ability to boot the same chroot/vm either in ltsp5 or in ltsp19 mode
| |
| 20:43 | <vagrantc> this rewrite seems much easier to maintain and develop :)
| |
| 20:43 | <alkisg> I think that if someone spends a week and ports it to fedora/opensuse etc, it'll be very easy to maintain it for many distributions too
| |
| 20:44 | <vagrantc> i couldn't come up with a better name, but ltsp-next was kind of a silly name for the initramfs-tools hook :)
| |
| 20:44 | <alkisg> E.g. I don't need to have a fedora server to test; just a fedora vm or iso, to test the client side
| |
| 20:44 | <vagrantc> yes, that part is amazing :)
| |
| 20:44 | very excited about the future
| |
| 20:44 | <alkisg> I think some new users arrived too; let's see
| |
| 20:45 | <vagrantc> maybe i should actually set up some LTSP stuff on the local network :)
| |
| 20:45 | so i actually use it :)
| |
| 20:45 | then again ... it probably wouldn't change much
| |
| 20:47 | <alkisg> I need to remember to pull, then push so that it goes to the launchpad mirror, THEN build the recipe...
| |
| 20:47 | Building, let's see if it succeeds in xenial... https://code.launchpad.net/~ltsp/+recipe/ltsp-proposed
| |
| 20:48 | <vagrantc> can't launchpad just mirror github?
| |
| 20:48 | <alkisg> It can, with a 4 hours delay or so
| |
| 20:48 | And with occasional hiccups
| |
| 20:49 | So I prefer to just have two push targets
| |
| 20:51 | <vagrantc> ah
| |
| 20:52 | and the launchpad mirrors aren't pushable, i presume
| |
| 20:54 | <alkisg> If they're automatic mirrors, then no; so I always do it manually
| |
| 20:58 | <vagrantc> there are probably some github features that could be used instead...
| |
| 20:58 | but that probably requires more work for the moment :)
| |
| 20:59 | https://github.com/features/actions
| |
| 21:45 | <alkisg> vagrantc: is it possible to upload epoptes to buster with just a url change?
| |
| 21:46 | epoptes.org is expiring in a couple of days, so we move to epoptes.github.io
| |
| 21:46 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 21:50 | * alkisg reads https://www.debian.org/doc/manuals/developers-reference/ch05.html#upload-stable ... | |
| 22:04 | <vagrantc> alkisg: not likely...
| |