[gentoo-dev] Large files still in files/

[gentoo-dev] Large files still in files/

[Michael Sterrett -Mr. Bones.-]

I'd like to highlight the larger files still found in files/ directories:

(86K) games-emulation/nwwine/files/wine-alsa.patch
(85K) mail-filter/amavisd-new/files/amavisd.conf
(78K) gnome-base/gnome-session/files/gnome-splash.png
(78K) gnome-base/gnome-session/files/gentoo-splash.png
(70K) sys-kernel/linux-headers/files/linux-headers-2.6.10-appCompat.patch
(70K) app-accessibility/speech-tools/files/1.2.3-gcc3.4.patch
(68K) media-gfx/imgseek/files/imgSeek-0.8.4-sizetype.patch
(65K) media-libs/freetype/files/2.1/freetype-2.1.5-autohint-cjkfonts-20031105.patch
(64K) app-i18n/chinput/files/chinput-3.0.2-debian.patch
(63K) net-misc/vnc/files/vnc-3.3.4-platform-fixes.patch
(62K) media-gfx/maya/files/maya-5.0.1.md5sum
(60K) sys-kernel/linux-headers/files/linux-headers-2.6.8.1-appCompat.patch

Please locate the ones you're responsible for and move them to the mirrors.

Thanks,

Michael Sterrett
   -Mr. Bones.-
mr_bones_@gentoo.org
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Large files still in files/

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 6752 bytes --]

Here is a more complete list, of every file over the 20K limit that repoman complains about.
If all of these were removed, there would be saving of ~4Mb in rsync size.

88K ./games-emulation/nwwine/files/wine-alsa.patch
84K ./mail-filter/amavisd-new/files/amavisd.conf
80K ./gnome-base/gnome-session/files/gnome-splash.png
80K ./gnome-base/gnome-session/files/gentoo-splash.png
72K ./sys-kernel/linux-headers/files/linux-headers-2.6.10-appCompat.patch
72K ./app-accessibility/speech-tools/files/1.2.3-gcc3.4.patch
68K ./media-libs/freetype/files/2.1/freetype-2.1.5-autohint-cjkfonts-20031105.patch
68K ./media-gfx/imgseek/files/imgSeek-0.8.4-sizetype.patch
64K ./net-misc/vnc/files/vnc-3.3.4-platform-fixes.patch
64K ./media-gfx/maya/files/maya-5.0.1.md5sum
64K ./app-i18n/chinput/files/chinput-3.0.2-debian.patch
60K ./x11-wm/fvwm/files/fvwm-2.5.9-translucent-menus.diff.gz
60K ./sys-kernel/linux-headers/files/linux-headers-2.6.8.1-appCompat.patch
60K ./media-video/ati-drivers/files/fglrx-3.9.0-regparm.patch
60K ./app-i18n/unicon/files/unicon-3.0.4-debian.patch
56K ./x11-base/xorg-x11/files/xpm-secfix-thomas.diff
56K ./sys-libs/db/files/db.1.85.patch
56K ./sys-kernel/linux26-headers/files/linux26-headers-2.6.8.1-appCompat.patch
56K ./app-text/rcs/files/conf.sh
52K ./sys-devel/egcs64-sparc/files/egcs64_19980921-4.diff
52K ./app-text/ispell/files/ispell-3.1.20.diff
48K ./x11-libs/openmotif/files/openmotif-2.1.30-xpm2.diff
48K ./net-ftp/ftp/files/netkit-ftp-0.17+ssl-0.2.diff
48K ./media-gfx/gimp/files/psd_save.c
44K ./x11-plugins/wmnet/files/wmnet-1.06-misc.patch
44K ./sys-kernel/linux26-headers/files/linux26-headers-2.6.7-appCompat.patch
44K ./sys-devel/binutils/files/2.14/binutils-2.14.90.0.7-ppc-reloc.patch
44K ./media-sound/alsa-driver/files/alsa-driver-1.0.7-ioctl32.patch-r2
44K ./mail-mta/qmail/files/1.03-r9/qmail-1.03-starttls-smtp-auth.patch
44K ./mail-mta/qmail/files/1.03-r8/qmail-1.03-starttls-smtp-auth.patch
40K ./x11-terms/xvt/files/xvt-2.1.diff.gz
40K ./sys-devel/binutils/files/2.14/binutils-2.14.90.0.7-tls-section-alignment.patch
40K ./media-video/mpeg-tools/files/1.5b/libpnmrw.c
40K ./mail-mta/sendmail/files/sendmail.cf
40K ./mail-mta/sendmail/files/sendmail-procmail.cf
40K ./gnome-base/nautilus/files/nautilus-2.8-x-printers.patch
40K ./gnome-base/nautilus/files/nautilus-2-x-printers.patch
40K ./games-misc/bsd-games-non-free/files/bsdgames_2.13-11.diff
40K ./app-admin/skey/files/skey-1.1.5-gentoo.diff.gz
36K ./x11-plugins/wmsysmon/files/wmsysmon-0.7.6-s4t4n.patch
36K ./sys-boot/grub/files/splash.xpm.gz
36K ./net-www/mozilla-firefox/files/mozilla-firebird-amd64.patch
36K ./net-www/apache/files/patches/1.3.31/00_gentoo_apachectl.patch
36K ./net-www/apache/files/patches/1.3.31-r2/00_gentoo_apachectl.patch
36K ./net-www/apache/files/patches/1.3.31-r1/00_gentoo_apachectl.patch
36K ./media-video/xmovie/files/xmovie-gcc3-gentoo.patch
36K ./dev-lang/pm3/files/pm3-1.1.15.patch
36K ./app-office/openoffice/files/1.1.4/gcc34.patch.bz2
36K ./app-office/openoffice-ximian/files/1.1.3/gcc34_2.patch.bz2
36K ./app-office/openoffice-ximian/files/1.1.3/gcc34.patch.bz2
32K ./x11-libs/gtk+/files/gtk+-2.4-smoothscroll.patch
32K ./sys-devel/binutils/files/2.14/binutils-2.14.90.0.6-ppc-bfd.patch
32K ./sci-calculators/rpc/files/rpc-0.98-gcc-34.patch
32K ./net-ftp/ftp/files/netkit-ftp-0.17-ssl-0.2.patch
32K ./games-fps/ut2003-demo/files/misc.tar.bz2
32K ./games-fps/unreal-tournament-infiltration/files/Infiltration.ini
32K ./app-misc/mc/files/mc-4.6.0-utf8.patch.bz2
32K ./app-admin/longrun/files/longrun-0.9-r1-debian-gcc-3.diff
28K ./x11-wm/windowmaker/files/xinerama.patch
28K ./x11-plugins/wmbutton/files/wmbutton-buttons.xpm
28K ./sys-devel/binutils/files/2.14/binutils-2.14.90.0.6-conf.patch
28K ./net-www/apache/files/patches/1.3.31/00_gentoo_base.patch
28K ./net-www/apache/files/patches/1.3.31-r2/00_gentoo_base.patch
28K ./net-www/apache/files/patches/1.3.31-r1/00_gentoo_base.patch
28K ./net-p2p/qtorrent/files/qtorrent-0.9.6.1-sizetype.patch
28K ./net-p2p/bittorrent-stats/files/bittorrent-stats-3.2.1b.patch
28K ./net-misc/wget/files/wget-1.9.1+ipvmisc.patch
28K ./net-irc/supybot/files/supybot-0.77.2-cvsadditions-2004-06-10.patch
28K ./media-sound/wavplay/files/wavplay-1.4.patch
28K ./media-sound/terminatorx/files/terminatorx-3.80.GNOMEpresent.patch
28K ./dev-util/subversion/files/subversion-1.1.2-perl.patch
28K ./app-text/html2text/files/html2text-gcc3.3.patch
28K ./app-emulation/qemu/files/qemu-0.6.1-20041126.patch
28K ./app-admin/sysklogd/files/sysklogd-1.4.1-2.6.headers.patch
28K ./app-admin/fam/files/fam-2.7.0-dnotify.patch
28K ./app-accessibility/speech-tools/files/speech-tools-gcc3.3.diff
24K ./sys-libs/slang/files/slang-debian-utf8.patch
24K ./sys-devel/binutils/files/2.15/52_all_binutils-20040527-uclibc-100-conf.patch
24K ./sys-devel/binutils/files/2.14/binutils-2.14.90.0.6-merge-speedup.patch
24K ./sys-boot/silo/files/silo_1.2.5-1.diff
24K ./sys-boot/elilo/files/elilo-3.4
24K ./sys-boot/dvhtool/files/dvhtool-1.0.1-2.diff
24K ./sys-apps/mii-diag/files/libmii.c-2.10
24K ./net-www/mozilla/files/mozilla-1.7.3-4ft2.patch
24K ./net-www/mozilla-firefox/files/mozilla-firefox-1.0-4ft2.patch
24K ./net-www/apache/files/conf/commonapache.conf
24K ./net-wireless/kwavecontrol/files/kwavecontrol-0.3-installdirs.diff
24K ./net-misc/wget/files/wget-1.8.2-2Glimit.diff
24K ./net-irc/epic4/files/local
24K ./net-ftp/ftp/files/netkit-ftp-0.17-ipv6.patch
24K ./net-dns/bind/files/dyndns-samples.tbz2
24K ./media-video/xanim/files/Makefile.amd64
24K ./media-video/xanim/files/Makefile
24K ./media-video/bcast/files/bcast-2000c-gcc3-gentoo.patch
24K ./media-sound/alsa-driver/files/alsa-driver-1.0.7-configure.patch
24K ./media-libs/libsdl/files/1.2.8-libcaca.patch
24K ./media-libs/libsdl/files/1.2.7-libcaca.patch
24K ./mail-mta/exim/files/exiscan.conf
24K ./mail-client/mozilla-thunderbird/files/mozilla-thunderbird-0.9-4ft2.patch
24K ./kde-base/kdebase/files/3.4.0_beta2/kdmrc
24K ./gnome-extra/gnome-system-monitor/files/gnome-system-monitor-devicesviewimprovements.patch
24K ./games-arcade/koules/files/1.4-gcc3.patch
24K ./app-office/qhacc/files/qhacc-3.2.2-sandbox.patch
24K ./app-misc/mc/files/mc-4.6.0-can-2004-0226-0231-0232.patch.bz2
24K ./app-arch/zoo/files/zoo-2.10-gcc33-issues-fix.patch
24K ./app-admin/webalizer/files/2.01.10/webalizer.conf

Generated with:
find -size +20k -printf '%k %p\n' |sort -ngr |grep /files/ |sed 's, ,K ,g'

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Large files still in files/

[Michele Noberasco]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Sat, 5 Mar 2005 21:09:00 -0800
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> Here is a more complete list, of every file over the 20K limit that
> repoman complains about. If all of these were removed, there would be
> saving of ~4Mb in rsync size.
> 36K ./x11-plugins/wmsysmon/files/wmsysmon-0.7.6-s4t4n.patch
Just moved this to distfiles.

My regards,
Michele Noberasco

-- 
* knghtbrd does the ET thing
<knghtbrd> anybody got a speak-n-spell?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Michele Noberasco]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

On Sat, 5 Mar 2005 21:09:00 -0800
"Robin H. Johnson" <robbat2@gentoo.org> wrote:

> 44K ./x11-plugins/wmnet/files/wmnet-1.06-misc.patch
This is gone, too...

Now I think I'll stop posting these messages, otherwise what is gained
in Portage size will be lost in increased mailing list traffic ;-)

Bye
Michele

-- 
"So.. humans have easily injured knees. My race will find this
information very useful indeed. Mwahwahahahaha!"
 --Morbo

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Mark Loeser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Sterrett -Mr. Bones.- wrote:
| I'd like to highlight the larger files still found in files/ directories:

There's also quite a large amount of binary files still in the tree.  A
lot of them seem to be compressed patches.  I'm not sure what should be
done with those, but I thought putting binary files into the tree was
discouraged unless absolutely necessary.  Lots of 4k compressed patches
doesn't seem to be something absolutely necessary.

Mark Loeser
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCKpSjCRZPokWLroQRAmY2AKCJm4FeZ0SbeQDNe246TBHGoA5JegCeIBvj
P+Wh0vFQStmaishA4JpoErw=
=y+ER
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Large files still in files/

[Anthony de Boer]

Mark Loeser wrote:
> There's also quite a large amount of binary files still in the tree.  A
> lot of them seem to be compressed patches.  I'm not sure what should be
> done with those, but I thought putting binary files into the tree was
> discouraged unless absolutely necessary.  Lots of 4k compressed patches
> doesn't seem to be something absolutely necessary.

Tying this to the Portage-tree collection-copyright issue, it might be a
good idea for all third-party-sourced patches, with e-mail headers or
other such authorship/source/copyright information still intact at the
start (and happily skipped by the patch command), to be gzipped and put
in distfiles, and the tree itself to be reserved for stuff written
specifically for the Gentoo project.

This does still leave large Gentoo-supplied patches in question; I'm
uncomfortable with the idea of us getting *that* far from the upstream
sources, though.

-- 
Anthony de Boer
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Large files still in files/

[Cory Visi]

On Sun, Mar 06, 2005 at 01:10:24PM -0500, Anthony de Boer wrote:
> Mark Loeser wrote:
> > There's also quite a large amount of binary files still in the tree.  A
> > lot of them seem to be compressed patches.  I'm not sure what should be
> > done with those, but I thought putting binary files into the tree was
> > discouraged unless absolutely necessary.  Lots of 4k compressed patches
> > doesn't seem to be something absolutely necessary.
> 
> Tying this to the Portage-tree collection-copyright issue, it might be a
> good idea for all third-party-sourced patches, with e-mail headers or
> other such authorship/source/copyright information still intact at the
> start (and happily skipped by the patch command), to be gzipped and put
> in distfiles, and the tree itself to be reserved for stuff written
> specifically for the Gentoo project.
> 
> This does still leave large Gentoo-supplied patches in question; I'm
> uncomfortable with the idea of us getting *that* far from the upstream
> sources, though.

I kind of like this idea, however, I think it's idealistic. Patches need 
to be modified very frequently. Especially when we combine multiple 
patches and make them all work with USE flags.

A great deal of our patches really are written specifically work with our 
ebuilds.

What is the real percentage of space usage from compressed or uncompressed 
patches? How big of a problem is it?

-Cory
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Large files still in files/

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

On Sun, 2005-03-06 at 20:25 +0000, Cory Visi wrote:
> On Sun, Mar 06, 2005 at 01:10:24PM -0500, Anthony de Boer wrote:
> > Mark Loeser wrote:
> > > There's also quite a large amount of binary files still in the tree.  A
> > > lot of them seem to be compressed patches.  I'm not sure what should be
> > > done with those, but I thought putting binary files into the tree was
> > > discouraged unless absolutely necessary.  Lots of 4k compressed patches
> > > doesn't seem to be something absolutely necessary.
> > 
> > Tying this to the Portage-tree collection-copyright issue, it might be a
> > good idea for all third-party-sourced patches, with e-mail headers or
> > other such authorship/source/copyright information still intact at the
> > start (and happily skipped by the patch command), to be gzipped and put
> > in distfiles, and the tree itself to be reserved for stuff written
> > specifically for the Gentoo project.
> > 
> > This does still leave large Gentoo-supplied patches in question; I'm
> > uncomfortable with the idea of us getting *that* far from the upstream
> > sources, though.
> 
> I kind of like this idea, however, I think it's idealistic. Patches need 
> to be modified very frequently. Especially when we combine multiple 
> patches and make them all work with USE flags.
> 
> A great deal of our patches really are written specifically work with our 
> ebuilds.
> 
> What is the real percentage of space usage from compressed or uncompressed 
> patches? How big of a problem is it?
> 

Also the problem is that especially if you have a rapid changing
package, where the patches changes a lot, putting it in distfiles is a
pita, as you have to scp it, then wait an hour to 3 depending on how
lucky you are, and then only commit.  And especially if you forgetful
like me, you tend to forget to either come back and commit the new
version/revision, or to copy the new tarball to distfiles ...

-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Malte S. Stretz]

On Monday 07 March 2005 17:57 CET Martin Schlemmer wrote:
> On Sun, 2005-03-06 at 20:25 +0000, Cory Visi wrote:
> > On Sun, Mar 06, 2005 at 01:10:24PM -0500, Anthony de Boer wrote:
> > > Mark Loeser wrote:
> > > > There's also quite a large amount of binary files still in the
> > > > tree.  A lot of them seem to be compressed patches.  I'm not sure
> > > > what should be done with those, but I thought putting binary files
> > > > into the tree was discouraged unless absolutely necessary.  Lots of
> > > > 4k compressed patches doesn't seem to be something absolutely
> > > > necessary.
> > >
> > > Tying this to the Portage-tree collection-copyright issue, it might
> > > be a good idea for all third-party-sourced patches, with e-mail
> > > headers or other such authorship/source/copyright information still
> > > intact at the start (and happily skipped by the patch command), to be
> > > gzipped and put in distfiles, and the tree itself to be reserved for
> > > stuff written specifically for the Gentoo project.
> > >
> > > This does still leave large Gentoo-supplied patches in question; I'm
> > > uncomfortable with the idea of us getting *that* far from the
> > > upstream sources, though.
> >
> > I kind of like this idea, however, I think it's idealistic. Patches
> > need to be modified very frequently. Especially when we combine
> > multiple patches and make them all work with USE flags.
> >
> > A great deal of our patches really are written specifically work with
> > our ebuilds.
> >
> > What is the real percentage of space usage from compressed or
> > uncompressed patches? How big of a problem is it?
>
> Also the problem is that especially if you have a rapid changing
> package, where the patches changes a lot, putting it in distfiles is a
> pita, as you have to scp it, then wait an hour to 3 depending on how
> lucky you are, and then only commit.  And especially if you forgetful
> like me, you tend to forget to either come back and commit the new
> version/revision, or to copy the new tarball to distfiles ...

Didn't this discussion already happen about half a year ago and one of the 
conclusions was that a possible solution could be a special set of patches 
server from which those files are pulled on demand?  Those servers could 
even be (some of the) the rsync mirrors.

>From a user point of view, this would hopefully have the advantage that the 
tedious 'emerge sync' runs (which often happen to time out for some reason, 
might be my internet connection) could be a lot (?) faster as only a 
percentage of the current tree would me mirrored locally -- the longest 
taking part of the rsync process is the "generating file list" one.

For the servers it could have the advantage that there's less load from 
rsync -- I guess even if the patches etc were pulled from the same servers 
via HTTP it would be less load as the files are (a) fetched on demand and 
(b) it wouldn't use the rsync protocol but plain HTTP.  But I don't have 
any numbers, maybe I'm wrong, and I don't know what additional traffic this 
would produce.

Just 2 cents from the peanut gallery.

Cheers,
Malte

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Large files still in files/

[Aron Griffis]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

Azarah wrote:[Mon Mar 07 2005, 11:57:04AM EST]
> Also the problem is that especially if you have a rapid changing
> package, where the patches changes a lot, putting it in distfiles is a
> pita, as you have to scp it, then wait an hour to 3 depending on how
> lucky you are, and then only commit.

I know this has been covered before, but what is the problem with
putting files on dev.gentoo.org?  The automatic scripts should suck it
into distfiles and portage should check mirrors before "upstream" (in
this case dgo) first, so I'd think the load on dgo shouldn't be
significant.

Regards,
Aron

--
Aron Griffis
Gentoo Linux Developer


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1069 bytes --]

On Mon, 7 Mar 2005 12:54:20 -0500 Aron Griffis <agriffis@gentoo.org>
wrote:
| Azarah wrote:[Mon Mar 07 2005, 11:57:04AM EST]
| > Also the problem is that especially if you have a rapid changing
| > package, where the patches changes a lot, putting it in distfiles is
| > a pita, as you have to scp it, then wait an hour to 3 depending on
| > how lucky you are, and then only commit.
| 
| I know this has been covered before, but what is the problem with
| putting files on dev.gentoo.org?  The automatic scripts should suck it
| into distfiles and portage should check mirrors before "upstream" (in
| this case dgo) first, so I'd think the load on dgo shouldn't be
| significant.

Infra have politely (where by politely I mean "with threats of
decapitation and feeding to the goats") asked us not to do this because
of reliability and load issues. I'd say that they probably know best...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Mon, 2005-03-07 at 12:54 -0500, Aron Griffis wrote:
> I know this has been covered before, but what is the problem with
> putting files on dev.gentoo.org?  The automatic scripts should suck it
> into distfiles and portage should check mirrors before "upstream" (in
> this case dgo) first, so I'd think the load on dgo shouldn't be
> significant.

The load isn't insignificant.  That and the people providing hosting for
dgo mind quite heavily when we use dgo as a distribution point.  Add
that to the complete lack of redundancy with dgo and you have a recipe
for disaster... ;]

Think about what the load would be for, say, any KDE patches for the 4
hours between a new KDE going into the tree and the distfiles mirrors
picking up the files.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]

On Mon, 2005-03-07 at 18:57 +0200, Martin Schlemmer wrote:
> > I kind of like this idea, however, I think it's idealistic. Patches need 
> > to be modified very frequently. Especially when we combine multiple 
> > patches and make them all work with USE flags.
> > 
> > A great deal of our patches really are written specifically work with our 
> > ebuilds.
> > 
> > What is the real percentage of space usage from compressed or uncompressed 
> > patches? How big of a problem is it?
> > 
> 
> Also the problem is that especially if you have a rapid changing
> package, where the patches changes a lot, putting it in distfiles is a
> pita, as you have to scp it, then wait an hour to 3 depending on how
> lucky you are, and then only commit.  And especially if you forgetful
> like me, you tend to forget to either come back and commit the new
> version/revision, or to copy the new tarball to distfiles ...

This was why we were asking for a "packages.gentoo.org" that could
either be a single or multiple machines.  It could even replace
the /space/distfiles-local, as everything from it could be pushed out to
be synched to distfiles.  This would make them immediately available,
and would alleviate the problem.  Once the main distfiles mirrors got
the files, they could be deleted from packages.gentoo.org

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

Chris Gianelloni wrote:
> On Mon, 2005-03-07 at 18:57 +0200, Martin Schlemmer wrote:
> 
>>>I kind of like this idea, however, I think it's idealistic. Patches need 
>>>to be modified very frequently. Especially when we combine multiple 
>>>patches and make them all work with USE flags.
>>>
>>>A great deal of our patches really are written specifically work with our 
>>>ebuilds.
>>>
>>>What is the real percentage of space usage from compressed or uncompressed 
>>>patches? How big of a problem is it?
>>>
>>
>>Also the problem is that especially if you have a rapid changing
>>package, where the patches changes a lot, putting it in distfiles is a
>>pita, as you have to scp it, then wait an hour to 3 depending on how
>>lucky you are, and then only commit.  And especially if you forgetful
>>like me, you tend to forget to either come back and commit the new
>>version/revision, or to copy the new tarball to distfiles ...
> 
> 
> This was why we were asking for a "packages.gentoo.org" that could
> either be a single or multiple machines.  It could even replace
> the /space/distfiles-local, as everything from it could be pushed out to
> be synched to distfiles.  This would make them immediately available,
> and would alleviate the problem.  Once the main distfiles mirrors got
> the files, they could be deleted from packages.gentoo.org

You mean patches.gentoo.org. Yes, ideally this is something we need to setup. I
recall having this topic a few months back, but I forgot where it left off.
Right now dev.g.o is a single point of failure. If it dies, everything you host
there dies.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operational Manager

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-dev] Large files still in files/

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 465 bytes --]

On Mon, 2005-03-07 at 12:52 -0600, Lance Albertson wrote:
> You mean patches.gentoo.org. Yes, ideally this is something we need to setup. I
> recall having this topic a few months back, but I forgot where it left off.
> Right now dev.g.o is a single point of failure. If it dies, everything you host
> there dies.

Yeah, sorry... that's what I meant.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

On Mon, 2005-03-07 at 12:52 -0600, Lance Albertson wrote:
> Chris Gianelloni wrote:
> > On Mon, 2005-03-07 at 18:57 +0200, Martin Schlemmer wrote:
> > 
> >>>I kind of like this idea, however, I think it's idealistic. Patches need 
> >>>to be modified very frequently. Especially when we combine multiple 
> >>>patches and make them all work with USE flags.
> >>>
> >>>A great deal of our patches really are written specifically work with our 
> >>>ebuilds.
> >>>
> >>>What is the real percentage of space usage from compressed or uncompressed 
> >>>patches? How big of a problem is it?
> >>>
> >>
> >>Also the problem is that especially if you have a rapid changing
> >>package, where the patches changes a lot, putting it in distfiles is a
> >>pita, as you have to scp it, then wait an hour to 3 depending on how
> >>lucky you are, and then only commit.  And especially if you forgetful
> >>like me, you tend to forget to either come back and commit the new
> >>version/revision, or to copy the new tarball to distfiles ...
> > 
> > 
> > This was why we were asking for a "packages.gentoo.org" that could
> > either be a single or multiple machines.  It could even replace
> > the /space/distfiles-local, as everything from it could be pushed out to
> > be synched to distfiles.  This would make them immediately available,
> > and would alleviate the problem.  Once the main distfiles mirrors got
> > the files, they could be deleted from packages.gentoo.org
> 
> You mean patches.gentoo.org. Yes, ideally this is something we need to setup. I
> recall having this topic a few months back, but I forgot where it left off.
> Right now dev.g.o is a single point of failure. If it dies, everything you host
> there dies.
> 

Well, missed this - I am all for it when some infra monkey gets the
time :)


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Large files still in files/

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 851 bytes --]

On Sun, 2005-03-06 at 13:10 -0500, Anthony de Boer wrote:
> Tying this to the Portage-tree collection-copyright issue, it might be a
> good idea for all third-party-sourced patches, with e-mail headers or
> other such authorship/source/copyright information still intact at the
> start (and happily skipped by the patch command), to be gzipped and put
> in distfiles, and the tree itself to be reserved for stuff written
> specifically for the Gentoo project.

Really, they should all be in distfiles.

> This does still leave large Gentoo-supplied patches in question; I'm
> uncomfortable with the idea of us getting *that* far from the upstream
> sources, though.

They could get a copyright notice and get stuck in distfiles.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]