Re: [SOLVED] Re: [gentoo-user] Ebuild: How to deal with external repositories properly (best practise)?
On Tue, Aug 4, 2020 at 7:51 PM tastytea wrote: > > This seems to affect only api.github.com, packages in ::guru use > https://github.com//archive/.tar.gz instead, which is not > affected (just checked with net-wireless/rtl8192eu-0_pre20200123). Ah, didn't notice that. This is the more common approach for Gentoo packages, if they use hashes at all. Usually tags are preferred. And if upstream actually has an official source tarball that is what gets used. The only reason anybody in Gentoo uses github links at all is either because upstream uses it officially, or upstream doesn't even bother to release source tarballs. -- Rich
Re: [SOLVED] Re: [gentoo-user] Ebuild: How to deal with external repositories properly (best practise)?
On 2020-08-04 19:36-0400 Rich Freeman wrote: > On Tue, Aug 4, 2020 at 6:57 PM Alexey Mishustin > wrote: > > > > вс, 2 авг. 2020 г. в 13:52, Ramon Fischer > > : > > > > > > I decided to use "EGIT_COMMIT" to let the ebuild pulling a > > > certain commit. > > > > And even that would not give the sense of security... > > > > Just read in gentoo-dev [1]: > > ...unannounced serverside change by GitHub, which broke download of > > tarballs by git-tree-hash, e.g. previously https:// > > api.github.com/repos/JuliaLang/MbedTLS.jl/tarball/ > > 2d94286a9c2f52c63a16146bb86fd6cdfbf677c6 would give the tarball for > > that tree- hash, while it now gives the tarball for master instead. > > This seems to affect only api.github.com, packages in ::guru use https://github.com//archive/.tar.gz instead, which is not affected (just checked with net-wireless/rtl8192eu-0_pre20200123). > I'm pretty sure EGIT_COMMIT will fetch by commit ID using git, not > download a hash-labeled tarball, so I don't think this issue would > impact you if that is how you're fetching things. Correct. > […] > Still, unless github fixes this we'll probably have to fix a bunch of > links in the repositories - at least any based on hashes. I'm not > sure if this impacts tags. The SRC_URIs are still invalid and we > don't want to maintain that state as new mirrors won't be able to > retrieve the file, and we generally want a valid SRC_URI for > everything. Devs can always just upload the tarball to any random > webserver and change the URI to point to it. My guess though is that > everybody will want to give this a few days to see if github fixes > their links. A quick grep indicated that the only packages in ::gentoo using api\.github\.com.*tarball are net-analyzer/tcpflow, dev-python/mypy, dev-lang/julia and app-forensics/dfxml. > Really this could happen with any web hosting service - github is just > a really prominent one. Back in the day if sourceforge suddenly went > down a whole bunch of SRC_URIs would have broken too. >
Re: [SOLVED] Re: [gentoo-user] Ebuild: How to deal with external repositories properly (best practise)?
On Tue, Aug 4, 2020 at 6:57 PM Alexey Mishustin wrote: > > вс, 2 авг. 2020 г. в 13:52, Ramon Fischer : > > > > I decided to use "EGIT_COMMIT" to let the ebuild pulling a certain commit. > > And even that would not give the sense of security... > > Just read in gentoo-dev [1]: > ...unannounced serverside change by GitHub, which broke download of > tarballs by git-tree-hash, e.g. previously https:// > api.github.com/repos/JuliaLang/MbedTLS.jl/tarball/ > 2d94286a9c2f52c63a16146bb86fd6cdfbf677c6 would give the tarball for > that tree- hash, while it now gives the tarball for master instead. > I'm pretty sure EGIT_COMMIT will fetch by commit ID using git, not download a hash-labeled tarball, so I don't think this issue would impact you if that is how you're fetching things. If you did use a hash tarball with SRC_URI and a conventional download, then emerge would still refuse to use the tarball if it failed the manifest hash check, so it wouldn't be installing anything you didn't want. Generally this isn't going to immediately break anything used by the Gentoo repo since 99% of this stuff will be mirrored, and the mirrors check hashes too. So, when github breaks the download link the mirrors will preserve their existing tarballs and refuse to replace them with new ones that don't have a matching hash (I'm talking about the actual hash of the file using multiple algorithms, not the hash in the filename). When you fetch from a mirror you'll still get the correct version of the file. If for some reason you can't reach any mirrors then you would download the broken link from github and then emerge would reject the file due to hash mismatch. Still, unless github fixes this we'll probably have to fix a bunch of links in the repositories - at least any based on hashes. I'm not sure if this impacts tags. The SRC_URIs are still invalid and we don't want to maintain that state as new mirrors won't be able to retrieve the file, and we generally want a valid SRC_URI for everything. Devs can always just upload the tarball to any random webserver and change the URI to point to it. My guess though is that everybody will want to give this a few days to see if github fixes their links. Really this could happen with any web hosting service - github is just a really prominent one. Back in the day if sourceforge suddenly went down a whole bunch of SRC_URIs would have broken too. -- Rich
Re: [SOLVED] Re: [gentoo-user] Ebuild: How to deal with external repositories properly (best practise)?
вс, 2 авг. 2020 г. в 13:52, Ramon Fischer : > > I decided to use "EGIT_COMMIT" to let the ebuild pulling a certain commit. And even that would not give the sense of security... Just read in gentoo-dev [1]: ...unannounced serverside change by GitHub, which broke download of tarballs by git-tree-hash, e.g. previously https:// api.github.com/repos/JuliaLang/MbedTLS.jl/tarball/ 2d94286a9c2f52c63a16146bb86fd6cdfbf677c6 would give the tarball for that tree- hash, while it now gives the tarball for master instead. [1] - https://archives.gentoo.org/gentoo-dev/message/41d8c5457df392ed0309153651db5b3c -- Best regards, Alex
Re: [gentoo-user] hplip network scanning port
On 01/08/2020 03:03, Adam Carter wrote: I used to be able to scan on my gentoo box from an HP officejet pro on the network. This is now failing and i can see that the gentoo box is attempting to connect to TCP/6566 on the HP, but the HP is not listening on that port. Test command is; hp-scan -dhpaio:/net/HP_Officejet_Pro_8620?ip= Is 6566 scan attempt using the correct port? Have you accidentally closed the port on the scanner (not sure whether that's possible, but ...) I use "scan to network" from the printer, but that may not be possible on yours. Just open a samba port and the scanner saves the file there. But that isn't foolproof either - when I changed scanner (from Dell to HP) one user stopped working ... ?? Cheers, Wol
Re: [gentoo-user] External hard drive and idle activity
On 04/08/20 08:42, Wols Lists wrote: > Both LVM and btrfs offer snapshotting, so you take a snapshot before > doing an in-place rsync, giving you one full backup per snapshot, but > the drive is actually only storing the changes between snapshots. > Probably run the backup much faster too. Just strikes me this would be near ideal for an SMR drive, because this would be copy-on-write, so the backup would just be streaming new data to disk. And by judiciously choosing when to delete snapshots, you have considerable control over when the drive decides to do a defrag. Cheers, Wol
Re: [gentoo-user] Strange portage behaviour
On Monday, 3 August 2020 23:01:07 BST Peter Humphrey wrote: > On Monday, 3 August 2020 20:15:45 BST Rich Freeman wrote: > > On Mon, Aug 3, 2020 at 3:01 PM Peter Humphrey wrote: > > > On Monday, 3 August 2020 14:18:22 BST Rich Freeman wrote: > > > > Sounds like you want --usepkgonly y --binpkg-respect-use y (the first > > > > is the same as -K). At least, I think that is what you're getting at > > > > - I could be misunderstanding your goal. > > > > > > Not exactly. I'm finding that emerge -K installs every package whose > > > binpkg > > > exists, regardless of whether it's installed in the system already. > > > Emerge > > > -k doesn't. Neither of them takes any notice of what packages are > > > installed in the system, and I think they should. > > > > -k/K have nothing to do with package selection - just the use of > > binary packages. > > > > If you run emerge @core then anything in @core should get installed. > > Adding -K or -k will either allow or force the use of binary packages, > > but it shouldn't cause stuff that isn't in @core to get installed > > unless it is a dependency. > > That's exactly the problem. It does. I mean, it does while in the chroot. Perhaps I'm setting something up wrongly. -- Regards, Peter.
Re: [gentoo-user] External hard drive and idle activity
On 04/08/20 04:17, Dale wrote: > This drive is formatted with ext4. It doesn't have LVM or anything just > straight ext4. Given it is external, I didn't see the point of having > LVM on it and adding another layer to deal with when there is no > benefits to it. LVM has a big advantage if not much (relatively) changes between backups. If you have let's say 900GB of data, your backup disk is 1TB, and say 20GB of data changes between backups, with LVM that drive could store 5 *full* backups! You could use btrfs to the same effect. Both LVM and btrfs offer snapshotting, so you take a snapshot before doing an in-place rsync, giving you one full backup per snapshot, but the drive is actually only storing the changes between snapshots. Probably run the backup much faster too. If this drive is used to store full backups, and only stores the one copy, it won't be that expensive/risky to reformat and try that? Cheers, Wol
