On Tuesday 14 October 2008 10:43:47 wrote Christoph Thiel:

On Sun, Oct 12, 2008 at 05:32:46PM +0200, Ralf Prengel wrote:

...

I m using ftp://ftp5.gwdg.de/pub/opensuse/factory/repo/ but my question ist now if there is somewhere something like a daily build. I ve several hardware problems (not caused by suse) but I m hoping that for example the latest kernel will solve parts of of my problems.

Adrian and team are working on publishing factory on a daily / automatic basis. This should become available real soon.

yes, but you can anyway always look in the devel project in the build service, it might have already newer code and built rpms. bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

Adrian and team are working on publishing factory on a daily / automatic basis. This should become available real soon.

Are you sure this is a good thing? For instance, my adsl is not fast enough to ensure update during a single day. Yes, it is. If you report something and it gets fixed next day, then you don't have to wait another ten days until the next sync just to find,

Hello, Carlos E. R. írta: that the fix still needs some polishing. For example beta2 for PPC was completely broken (wrong link on installer, no 32bit glibc), and as there was no update ever since, I still don't have anything to test. I reported now many bugs for openSUSE and SLES beta2 for x86, but my main interest is PPC, which can't be tested right now. Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Tue, Oct 14, 2008 at 12:27:05PM +0200, Carlos E. R. wrote:

On Tuesday, 2008-10-14 at 10:43 +0200, Christoph Thiel wrote:

...

Adrian and team are working on publishing factory on a daily / automatic basis. This should become available real soon.

Are you sure this is a good thing? For instance, my adsl is not fast enough to ensure update during a single day.

The update rate always depends on the rate of change we currently have -- ie. how many packages we check in for rebuild. Best, Christoph -- Christoph Thiel, Tech. Project Management, Research & Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Carlos E. R. schreef:

On Tuesday, 2008-10-14 at 13:01 +0200, Christoph Thiel wrote:

...

On Tue, Oct 14, 2008 at 12:27:05PM +0200, Carlos E. R. wrote:

...

...

On Tuesday, 2008-10-14 at 10:43 +0200, Christoph Thiel wrote:

...

Adrian and team are working on publishing factory on a daily / automatic basis. This should become available real soon.

Are you sure this is a good thing? For instance, my adsl is not fast enough to ensure update during a single day.

...

The update rate always depends on the rate of change we currently have -- ie. how many packages we check in for rebuild.

Unless there is a long enough inactivity period, people with slow networks will not be able to install at all.

-- Cheers, Carlos E. R.

What do you mean exactly, that it should be resynced in two days? Actualy to sync more often is the best what could happen, if these syncs contain 'missing' pkgs: half broken system is not valid to test. Unfullfilled Pkgs deps are/can be desastrous for an os, as i noticed on several occasions..;) -- Enjoy your time around, Oddball (Now or never...) OS: Linux 2.6.27-rc7-12-default x86_64 Huidige gebruiker: oddball@AMD64x2-sfn1 Systeem: openSUSE Beta 2 (x86_64) KDE: 4.1.2 (KDE 4.1.2) "release 1.4" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, On Fri, 17 Oct 2008, Carlos E. R. wrote:

On Friday, 2008-10-17 at 10:53 +0200, Oddball wrote:

...

...

...

The update rate always depends on the rate of change we currently have -- ie. how many packages we check in for rebuild.

Unless there is a long enough inactivity period, people with slow networks will not be able to install at all.

What do you mean exactly, that it should be resynced in two days? Actualy to sync more often is the best what could happen, if these syncs contain 'missing' pkgs: half broken system is not valid to test. Unfullfilled Pkgs deps are/can be desastrous for an os, as i noticed on several occasions..;)

I mean that if the repo is updated daily, every day, I will not have time to update before it changes again. It will change during my update, because a "zyper dup" has to download more than a gigabyte and my adsl is 1Mbit. Add the install time, that doubles or triples the used time, and the failures.

That is the right szenario to build a local mirror. Updating your local mirror would need about 2 hours for a gigabyte changes. Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

Hi, On Sat, 18 Oct 2008, Carlos E. R. wrote:

On Friday, 2008-10-17 at 12:14 +0200, Eberhard Moenkeberg wrote:

...

...

I mean that if the repo is updated daily, every day, I will not have time to update before it changes again. It will change during my update, because a "zyper dup" has to download more than a gigabyte and my adsl is 1Mbit. Add the install time, that doubles or triples the used time, and the failures.

That is the right szenario to build a local mirror. Updating your local mirror would need about 2 hours for a gigabyte changes.

How many machines do you think I have? >:-)

One is more than enough.

Even if I have the space, an rsync of the entire repo is a larger download than just the files I use. And long time, probably.

You really should try it. rsync has an excellent exclude parameter. Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

Hi, On Sat, 18 Oct 2008, Carlos E. R. wrote:

On Saturday, 2008-10-18 at 15:03 +0200, Eberhard Moenkeberg wrote:

...

...

...

That is the right szenario to build a local mirror. Updating your local mirror would need about 2 hours for a gigabyte changes.

How many machines do you think I have? >:-)

One is more than enough.

Mmmm...

...

...

Even if I have the space, an rsync of the entire repo is a larger download than just the files I use. And long time, probably.

You really should try it. rsync has an excellent exclude parameter.

I know.

But you have to feed it a tremendous list of packages not to download, which you have to learn from "rpm -qa" and some scripting. I'd need a script to generate the list of non needed packages, one by one - and this would fail as soon as the devs split or change a package name,

Of course I can exclude the entire 64 tree, but that is not enough.

It is 12 gigs the i586 repo alone at the moment... (at /#ftp:ftp5.gwdg.de/pub/opensuse/factory/repo/oss/suse/i586 on this very instant, says 'mc').

12069864 Kbytes / 100KB/s = 120698.64 seconds --> 33 hours download. Impossible, it is more than a day.

Besides excluding directories, you could also exclude all files with -debuginfo- or -debugsource- in name. This may cut the size to half. To test how far you will come down is size before downloading anything, rsync has the dryrun parameter. Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

Hi, On Sat, 18 Oct 2008, Stephan Binner wrote:

On Saturday 18 October 2008 19:19:16 Eberhard Moenkeberg wrote:

...

...

It is 12 gigs the i586 repo alone at the moment... (at /#ftp:ftp5.gwdg.de/pub/opensuse/factory/repo/oss/suse/i586 on this very Besides excluding directories, you could also exclude all files with -debuginfo- or -debugsource- in name. This may cut the size to half.

Debug packages are actually supposed to appear in repo/debug repository.

"supposed to", maybe. Rsync gives a total of 10 838 110 640 bytes with these excludes: --exclude /iso/ --exclude /repo/src/ --exclude /repo/oss/suse/x86_64/ --exclude *-debuginfo-* --exclude *-debugsource-* Without these two debug excludes it is 16 806 025 115 bytes. Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

Hi, On Sat, 18 Oct 2008, Carlos E. R. wrote:

On Saturday, 2008-10-18 at 20:35 +0200, Eberhard Moenkeberg wrote:

...

...

...

...

It is 12 gigs the i586 repo alone at the moment... (at /#ftp:ftp5.gwdg.de/pub/opensuse/factory/repo/oss/suse/i586 on this very Besides excluding directories, you could also exclude all files with -debuginfo- or -debugsource- in name. This may cut the size to half.

Debug packages are actually supposed to appear in repo/debug repository.

"supposed to", maybe.

Rsync gives a total of 10 838 110 640 bytes with these excludes:

--exclude /iso/ --exclude /repo/src/ --exclude /repo/oss/suse/x86_64/ --exclude *-debuginfo-* --exclude *-debugsource-*

Without these two debug excludes it is 16 806 025 115 bytes.

It is still too much for me. I can't donwload that much before it changes.

Give it a try. rsync creates the remote file list at the beginning, and if you run into a big factory change, lots of old files will not get transferred (because they are gone meanwhile). So your run will end earlier, and you can restart earlier to fetch the new files. And you can create a "durable" list of exclude patterns for unwanted big files like kernel-debug-* or similar. Using *, you need to obey that the shell can not resolve the pattern (because it matches some file in .). Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

Hi, On Sat, 18 Oct 2008, Carlos E. R. wrote:

On Saturday, 2008-10-18 at 19:19 +0200, Eberhard Moenkeberg wrote:

...

To test how far you will come down is size before downloading anything, rsync has the dryrun parameter.

Ah, didn't know that, thankyou. I'll try doing some tests.

The correct parameter is --dry-run or -n. You need to create the upmost destination directory by hand before using it; --dry-run really does run "dry", without changing anything locally. Viele Grüße Eberhard Mönkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Mönkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) Am Fassberg 11, 37077 Göttingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschäftsführer: Prof. Dr. Bernhard Neumair Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Göttingen Registergericht: Göttingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-10-18 at 14:43 +0200, Gerald Pfeifer wrote:

On Tue, 14 Oct 2008, Carlos E. R. wrote:

...

Are you sure this is a good thing? For instance, my adsl is not fast enough to ensure update during a single day.

One standing request I have for FACTORY is to make updates (quite a bit) smaller.

That would surely help :-) You should also consider creating a file that contains the "release number" of the entire repo, so that this can be reported on Bugzillas. It could be a timestamp, stored as another line in "SuSE-release", perhaps.

Among others this should include not updating packages which really have not seen material changes -- for example there really is no need to push all those updates for opensuse-manual_en all the time.

Of course. Maybe you can come up with some method to change just the release number without actually downloading the package. Symlinks?

Let's see what Adrian and team are going to come up with. ;-)

You could also consider making an alternate weekly frozen repo. Or saying "we will not push updates on weekends", so that we can count on having that time to do the "zypper dup" at that period on homes. Not everybody all the world around has a fast network at home. I haven't, just a 1mbit adsl. Others have even less. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj5344ACgkQtTMYHG2NR9WpdQCdG+jl6I01Kp6QwlKB/oywaoqy iA0AnA4MbgR2/6uVVXX2bcdP6Dc5zbq9 =e7mC -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-10-18 at 15:37 +0200, Bernhard Walle wrote:

* "Carlos E. R." <> [2008-10-18 15:07]:

...

That would surely help :-)

+1. But I think that's hard to implement without loosing the "rebuild every dependent package" feature. You cannot have all: The current concept of clean builds makes perfectly sense for a distribution with releases, but not as much for a Factory distribution.

Well, update the release version or whatever of each package, but somehow don't download it all. I have no idea how, of course, don't know enough of the internals.

...

You should also consider creating a file that contains the "release number" of the entire repo, so that this can be reported on Bugzillas. It could be a timestamp, stored as another line in "SuSE-release", perhaps.

That would not help since that stuff is not archived. That would mean: Even if you have that number, you cannot get a system to that state because the files are not there any more. For snapshots, we have Beta. Factory is a moving target.

Okay, with the OBS you would have at least the source that produced the binary build, which sometimes is sufficient.

It would help when reporting to know how "old" is the factory and whether the reported problem might have disappeared. Not only for you, who can learn that info from the rpm versions numbers, but for the rest of people on the mail list who can't. As you intend to keep updating factory faster than before, we will not know what factory version we have installed. Also, if we have, say, version 1990 locally and zypper is upgrading to version 1992, if we detect that the number has changed to 1993 on the repo while running "zypper dup", we know (and zypper can know) that we have to restart zypper, instead of seeing strange errors about "package not found". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj59D4ACgkQtTMYHG2NR9WwkACfYJ/KHqAuaAgjVfPQu5B1A372 O2gAoIHRQIfXsJIAVkl0kCiBoUu50gAf =RFQJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2008-10-18 at 16:49 +0200, Bernhard Walle wrote:

...

...

...

That would surely help :-)

+1. But I think that's hard to implement without loosing the "rebuild every dependent package" feature. You cannot have all: The current concept of clean builds makes perfectly sense for a distribution with releases, but not as much for a Factory distribution.

Well, update the release version or whatever of each package, but somehow don't download it all. I have no idea how, of course, don't know enough of the internals.

But how do you determine if you need to download the package?

Well, I said I have no idea how :-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj5+bMACgkQtTMYHG2NR9UtrQCeIp18/Hyf8sQNi966sBvGXkSM Bx4AoIMxwFU8VAjH3l5KPuslgNNTd6e9 =EQFz -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2008-10-20 at 11:55 +0200, Stephan Kulow wrote:

The key is to provide delta rpms. So you would still update opensuse_manual, but only download the diff - which should be in the range of bytes instead of megabytes. Unfortunately we have to many tasks for too little people - as it's "just" work to do, but by some key people that have many other important jobs to do.

How would this work with the daily updates you (suse) are proposing? I mean, how many days back would you keep the daily deltas? - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj8YeIACgkQtTMYHG2NR9W4/ACfS3EHL3PVpFtd5C1Q/YV3GW/H L9wAnimnhOEi8MlTJlHmTtPHq5Gy/qWn =XLBb -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday 20 October 2008 04:55:51 am Stephan Kulow wrote:

by some key people

Which suggest that you can't outsource that to community? Or? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Stephan Kulow schreef:

Am Montag 20 Oktober 2008 schrieb Rajko M.:

...

On Monday 20 October 2008 04:55:51 am Stephan Kulow wrote:

...

by some key people

Which suggest that you can't outsource that to community? Or?

Well, I wouldn't even know what's left to do, leave alone explaining it to someone. Of course if someone superbright supplies a patch to the build service sources it's all done.

Greetings, Stephan

Delta-rpm's are diff patches with changed pkg number only? They are/were used to update the pkgs with the suse-updater.... This is the most smart and useble way of updating imaginable.. Why exactly are the pkgs rebuild in the buildservice, if that can be done in the boxes? (as i am now updating to beta3, downloading some 2.75 gig....;) -- Enjoy your time around, Oddball (Now or never...) OS: Linux 2.6.27-rc7-12-default x86_64 Huidige gebruiker: oddball@AMD64x2-sfn1 Systeem: openSUSE Beta 2 (x86_64) KDE: 4.1.2 (KDE 4.1.2) "release 1.4" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rajko M. schreef:

On Sunday 26 October 2008 11:01:42 am Oddball wrote:

...

Delta-rpm's are diff patches with changed pkg number only? They are/were used to update the pkgs with the suse-updater.... This is the most smart and useble way of updating imaginable.. Why exactly are the pkgs rebuild in the buildservice, if that can be done in the boxes?

Deltas are build from current and previous package version, so you have to have both packages to generate delta. If package has changed a lot using only new version, instead to create delta can save some time.

In other words: They can only be used on a stable system, with 'known' pkg-versions? (or am i wrong here?) -- Enjoy your time around, Oddball (Now or never...) OS: Linux 2.6.27.1-2-default x86_64 Huidige gebruiker: oddball@AMD64x2-sfn1 Systeem: openSUSE 11.1 Beta 3 (x86_64) KDE: 4.1.2 (KDE 4.1.2) "release 1.13" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org