Re: [gentoo-dev] Sparc and Ia64 keyword clean up
15.05.2015 02:33, Jack Morgan пишет: > I'm actively working on stablereq for sparc and ia64. It took some > weeks to get my systems and process working. I hope to reduce the open > bugzilla in the next several weeks. Please don't just drop stable > keywords, even though the bugzilla has been open for a long time. I'd > appreciate it if you could send me a quick email asking to do your > package first, instead of just dropping the keyword. I'll put your > request at the top of my queue. > > Once I’m done with stablereq queue, I'll look to keywordreq queue. My > over plan is to reduce the total number of keyworded packages to a > more maintainable level. I'll send out more specific details for each > arch this week. Any help is greatly appreciated > > > Thanks, > ++ I went through some sparc STABLEREQs too.
Re: [gentoo-dev] Hey arch teams, we need your input!
El mar, 28-04-2015 a las 11:07 +0200, Tobias Klausmann escribió:
[...]
> There is one corner case where that format is not enough:
> multiple ebuilds/versions with non-homogenic archs, i.e.:
>
> cat-egory/packageA-1.2.3amd64 x86 alpha
> cat-egory/packageB-2.3.9amd64 alpha
> cat-egory/packageC-3.99 amd64 x86 ppc64
> cat-egory/packageD-10.2.5a alpha
>
> The format I used here seemes to be slightly more common than
> others and it is good enough for me™.
>
> Any add-on prose should be _after_ the standardized bit.
>
Yeah, we also use that format for gnome stuff... anyway, I don't mind
having a different option -> provide "list-${arch}" attachments with the
concrete lists per arch :/
Any preference?
Re: [gentoo-dev] Sparc and Ia64 keyword clean up
On 05/14/15 20:05, Rich Freeman wrote: On Thu, May 14, 2015 at 7:33 PM, Jack Morgan wrote: My over plan is to reduce the total number of keyworded packages to a more maintainable level. Many thanks. This is really the best possible solution. Arch teams can stabilize packages at their discretion, and if they get in over their heads they can de-stabilize at their discretion. This gives the arch team the most control over their own workload and the experience of their users, while not being a burden on package maintainers either. I'd like to add that ppc and ppc64 are also in a fairly healhty state healthy state now thanks to ago, jer, jmorgan and others. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] News item review: SquashDelta syncing support
Title: SquashDelta syncing support Author: Michał Górny Content-Type: text/plain Posted: 2015-05-xx Revision: 1 News-Item-Format: 1.0 Display-If-Installed: >=sys-apps/portage-2.2.19 Starting with Portage 2.2.19, a new SquashDelta syncing method has been introduced. It is meant to provide lightweight and efficient solution for stable systems. The whole repository is contained within a single pre-generated SquashFS image file. The daily snapshot of the repository is first fetched from the mirrors, and afterwards updated in-place using deltas (without repacking). In order to enable SquashDelta syncing, please install dev-util/squashmerge utility first: $ emerge -v dev-util/squashmerge Afterwards, you can use a repos.conf entry similar to the following: [gentoo] location = /var/db/repos/gentoo sync-type = squashdelta sync-uri = mirror://gentoo/../snapshots/squashfs During the initial sync, Portage will fetch the current Gentoo SquashFS snapshot from the mirrors (~105M). For the synces following, it will only fetch a single delta, and use squashmerge to quickly update the local copy. If possible, Portage will automatically mount (or remount) the SquashFS after syncing. However, you may want to add an explicit /etc/fstab entry for the filesystem to make it available before invoking 'emerge --sync': /var/cache/portage/squashfs/gentoo-current.sqfs /var/db/repos/gentoo \ squashfs defaults 0 0 Please note that the current syncing code does not verify the OpenPGP signature to confirm the authenticity of fetched snapshots and deltas. This feature will be added as soon as gentoo-keys support in Portage is available. -- Best regards, Michał Górny pgpaH0O8FrL2X.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] News item review: SquashDelta syncing support
On Fri, May 15, 2015 at 7:51 AM, Michał Górny wrote: > Starting with Portage 2.2.19, a new SquashDelta syncing method has been > introduced. It is meant to provide lightweight and efficient solution > for stable systems. The whole repository is contained within a single > pre-generated SquashFS image file. The daily snapshot of the repository > is first fetched from the mirrors, and afterwards updated in-place using > deltas (without repacking). This sounds nice, but the news item currently leaves me wondering what sort of improvements I should expect. It says the new method is "lightweight and efficient", but it would be nice to quantify this a little bit, or add a link to a page with more details. I think the default sync method in the handbook up to now has always been rsync? A comparison (both in terms of upside and in terms of downside) would be nice. Also, whether we want to make this the new default at some point, and if so, when. Cheers, Dirkjan
Re: [gentoo-dev] News item review: SquashDelta syncing support
On Fri, 15 May 2015 08:23:27 -0700 Dirkjan Ochtman wrote: > On Fri, May 15, 2015 at 7:51 AM, Michał Górny > wrote: > > Starting with Portage 2.2.19, a new SquashDelta syncing method has > > been introduced. It is meant to provide lightweight and efficient > > solution for stable systems. The whole repository is contained > > within a single pre-generated SquashFS image file. The daily > > snapshot of the repository is first fetched from the mirrors, and > > afterwards updated in-place using deltas (without repacking). > > This sounds nice, but the news item currently leaves me wondering what > sort of improvements I should expect. It says the new method is > "lightweight and efficient", but it would be nice to quantify this a > little bit, or add a link to a page with more details. I think the > default sync method in the handbook up to now has always been rsync? A > comparison (both in terms of upside and in terms of downside) would be > nice. Also, whether we want to make this the new default at some > point, and if so, when. > > Cheers, > > Dirkjan > > I've read the pdf article of Michał Górny and from my expirience with emerge-delta-webrsync and app-portage/getdelta in the past this good old new feature looks mostly useful for bad Internet connections (too slow or too expensive ones) and looks mostly useless for syncing relative to rsync method from local mirror like I use http://mirror.yandex.ru/gentoo-distfiles/ from my local region. eix-sync gave me the following statistics (before introducing new portage sync with repos.conf wich has stopped upgrade in the middle atm because >=app-portage/layman-2.3.0 haven't been stabilised yet): * Time statistics: 19 seconds for syncing 17 seconds for eix-update 1 seconds for eix-diff 51 seconds total or this one the other day: * Time statistics: 37 seconds for syncing 11 seconds for eix-update 1 seconds for eix-diff 67 seconds total So it takes usually 15-40 seconds for syncing using usual rsync method. This deltas have their own drawbacks like "delta is under generation, please wait half an hour or even more" or "your state is not the same what was while generating delta on the host and lets do additional work with more deltas". )) Although, nice try with experimenting and trying to improve sync mechanism. )
Re: [gentoo-dev] News item review: SquashDelta syncing support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/05/15 12:15 PM, Diamond wrote: > On Fri, 15 May 2015 08:23:27 -0700 Dirkjan Ochtman > wrote: > >> On Fri, May 15, 2015 at 7:51 AM, Michał Górny >> wrote: >>> Starting with Portage 2.2.19, a new SquashDelta syncing method >>> has been introduced. It is meant to provide lightweight and >>> efficient solution for stable systems. The whole repository is >>> contained within a single pre-generated SquashFS image file. >>> The daily snapshot of the repository is first fetched from the >>> mirrors, and afterwards updated in-place using deltas (without >>> repacking). >> >> This sounds nice, but the news item currently leaves me wondering >> what sort of improvements I should expect. [...] > > I've read the pdf article of Michał Górny and from my expirience > with emerge-delta-webrsync and app-portage/getdelta in the past > this good old new feature looks mostly useful for bad Internet > connections (too slow or too expensive ones) and looks mostly > useless for syncing relative to rsync method from local mirror like > I use [...] Although this thread should be a review of the news item rather than a review of the feature, I think both of these guys have a point. The main benefit to this new feature is that it allows users to use a squashfs image for their gentoo repo (portage tree) without having to (re)generate it themselves locally every time they --sync, AND without having to re-download an entire image from gentoo mirrors each time either. The new item doesn't really cover this much -- that the feature is for supporting storage and synchronization of the gentoo repo on squashfs rather than on a regular filesystem. Perhaps it would be enough to link to an article describing the benefits of using a squashfs'ed portage tree, so users could chose whether they want this or not based on that? Similarly, it would probably be good to mention that this new feature deprecates squash_portage and the other tools/methods out there for doing the same thing locally. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlVWO9kACgkQ2ugaI38ACPA1vwD9ELIdOgSSTfly3rT5zU6dzhGb 62LtN8loiRFhKfyAe/8A/24xw95j7qav/himVRA5OOjM3qTE++iBY/2yXPgLWpI5 =1+2r -END PGP SIGNATURE-
Re: [gentoo-dev] News item review: SquashDelta syncing support
On Fri, May 15, 2015 at 2:32 PM, Ian Stakenvicius wrote: > > The new item doesn't really cover this much -- that the feature is for > supporting storage and synchronization of the gentoo repo on squashfs > rather than on a regular filesystem. Perhaps it would be enough to > link to an article describing the benefits of using a squashfs'ed > portage tree, so users could chose whether they want this or not based > on that? Similarly, it would probably be good to mention that this > new feature deprecates squash_portage and the other tools/methods out > there for doing the same thing locally. > That makes sense to me. Some of the likely benefits would be: 1. Less disk space use. 2. Vastly less inode use. 3. Much less CPU/IO to update. 4. I suspect much less fragmentation/write/etc for storage on flash. Then again, on filesystems like btrfs fragmentation might be worse due to all the internal writes. 5. Probably better read performance (less disk IO, more CPU). Downsides include: 1. No way to sync more frequently than whatever the update cycle is. It would be more like emerge-webrsync and less like emerge --sync. 2. Impossible to tweak ebuilds without setting up an overlay. This might be annoying for devs/etc. -- Rich
Re: [gentoo-dev] News item review: SquashDelta syncing support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/05/15 03:33 PM, Rich Freeman wrote: > On Fri, May 15, 2015 at 2:32 PM, Ian Stakenvicius > wrote: >> >> The new item doesn't really cover this much -- that the feature >> is for supporting storage and synchronization of the gentoo repo >> on squashfs rather than on a regular filesystem. Perhaps it >> would be enough to link to an article describing the benefits of >> using a squashfs'ed portage tree, so users could chose whether >> they want this or not based on that? Similarly, it would >> probably be good to mention that this new feature deprecates >> squash_portage and the other tools/methods out there for doing >> the same thing locally. >> > > That makes sense to me. Some of the likely benefits would be: > > 1. Less disk space use. 2. Vastly less inode use. 3. Much less > CPU/IO to update. 4. I suspect much less fragmentation/write/etc > for storage on flash. Then again, on filesystems like btrfs > fragmentation might be worse due to all the internal writes. 5. > Probably better read performance (less disk IO, more CPU). > > Downsides include: 1. No way to sync more frequently than whatever > the update cycle is. It would be more like emerge-webrsync and less > like emerge --sync. 2. Impossible to tweak ebuilds without setting > up an overlay. This might be annoying for devs/etc. > Given the importance of this is to me more about the squashfs storage than the sync method, it may even be pertinent to change the title of the news item to something like: "SquashFS repo, SquashDelta syncing support" -BEGIN PGP SIGNATURE- Version: GnuPG v2 iF4EAREIAAYFAlVWSygACgkQ2ugaI38ACPAXdgEApXmmfrFJB1b4L0B4hKnNAuLs Njl9rWczgmR4SjMgvBwA/AwIOujrtoiQd1iT4j9oqQAjYJ9S8O/vVJe/9yWJXpj/ =WI2a -END PGP SIGNATURE-
