[EN] 32 bit paintitblack?

[ReinerS]

ReinerS: We tested apt-cacher for iso building - long story short - we don't recommend it

I will keep that in mind and will try to be extremly carefull


regards

Reiner

[melmarker]

@ReinerS: its not about being careful - the cache mechanisms don't fit for iso building

hmm - some ideas:
- one can try reprepro and convert a manifest into a reprepro list file - so one can build a partial debian mirror.
- debian and the siduction files coud be included into pyfll to serve packages not in reprepro

The problems we encounter was mostly old packages in the cache which break our builds - and there was no reliable way to update the cache. with this lists on can do a upgrade in reprepro - problem solved.

if hosted on the build machine or a little server this repo can be used to upgrade several machines - ok, creating a proper list - or some lists could be a little bit tricky, but should worth a try.

The more i though about it reprepro seems the way to go without a full debian mirror

[ReinerS]

I will have a look into reprepro then. I have a bandwitdth still of 384 K here. Others around here are still limited to ISDN ( ).
So working without some cache or mirror is not really an option if you experiment with such tools

regards

Reiner

[melmarker]

i talked with piper yesterday about this - the reprepro way seems a good way to go - but it need a lot of testing. Imho the new created Repo should be the primary repo for the Build, a debian repo should be in the pyfll configuration as fallback - beside the fixes and other siduction repositories. Doing things that way should minimize the needed network traffic dramatically - all one has to to is create such a repo, make it available via a webserver and throw that into his configuration.

So basic tasks will be:
* setup a local webserver (i would suggest nginx for that)
* install, understand and configure reprepro right (its poorly documented, but we have sample configs that work for the siduction repos)
* create a local repository with the needed packages (may be the hardest part because of the several Source-Repositories)
* create some package lists and update rules
* modify the pyfll config(s) the way the local repo is used.

[horo]

But there is no need to build for me. Now I have checked out and I began to read. I want to built an ISO myself. I'd appreciate someone answering my questions and posting his fll.conf.

Hi michaa7,

All the necessary *.conf files are in place, no need to edit something for the first try!
Last week I built two i386 ISOs (lxde and nox as recovery cd) on my amd64 system without any configuration change:
1. as user:

Code: [Select]

git clone git://git.siduction.org/code/pyfll.git2. as root:

Code: [Select]

cd pyfll; ./lxde_next_i386after about 10..120 minutes depending on your machine you'll find the ISO in /srv/iso/lxde/i386

If you have kvm installed you can test it on your machine (found this hint in the wiki):

Code: [Select]

kvm -m 1024 siduction-14.1.0-paintitblack-lxde-i386-201407201841.iso
EDIT: easier call works fine (and faster). -m 1024 allocates 1024 MB instead of the default value of 128 MB

HTH
Ciao, Martin

[michaa7]

...
2. as root:

Code: [Select]

cd pyfll; ./lxde_next_i386...

Thanks Martin,
you are sure it really is neccessary to run this script *as root*?

@ melma(r)ker

thanks for the info about mirror software. I though it could be sufficient to have a *partial* mirror of only the needed packages, so reprepo seems a good idea. But there are still other packages for *partial* mirrors: debmirror, debpartial-mirror or apt-move.

And, BTW, apt-cacher-ng != apt-cacher .

[horo]

Yes, you have to be root because it uses /var/cache/pyfll and puts the ISO into /srv/iso/...
I didn't want to read a lot to change the configuration as it was late at the evening
Maybe someone can clarify if its possible to work as user without a lot of changes?

Ciao, Martin

[melmarker]

micha7: we thested both apt-cacher and apt-cacher-ng. Conclusion: not reliable - reprepro seems to be the much cleaner and sophisticated way to do this. reprepro configured the right way can have some other advances like a central repro for updates, updates out of the build process etc

imho the biggest advantage is the ability fo fill the repro initial without caching and keep the repo up to date with a few simple commands.

[melmarker]

horo: working as user is possible, if sudo is configured the right way. towo introduced sudo su in pyfll a long time ago.

i would suggest a  own user for iso builds - the current user can be added to the group without pain - work with jenkins without flaws.

i can post some very restrictive sudo rules later.

[piper]

Well, root is still needed the way I build, but, I don't use sudo (can edit fll for that), I do however stress to use sudo especially for new people that are tinkering until you get a better understanding

* However, if using jenkins,  sudo is a * MUST *  I can't stress this enough (same with melmarker )

I also don't use  /srv/iso/

Everything is in my /home

Code: [Select]

[ 'options' ]
build_dir = /home/piper/pyfll/pyfll/debbuilder/pbuilder/build
output_dir = /home/piper/pyfll/pyfll/debbuilder/iso-piper
build_log = /home/piper/pyfll/pyfll/build_log/build.log
I am not the greatest with building and it has changed dramatically over the years when kelmo, (founder of pyfll),   sidux team, devil, had to put up with me, especially devil who  *gasp*  spoon-fed  me learnin to build.

When we can build again, I can *try and help, but, like I had to learn, it is trial & error & a lot of swearing.

This is all about stock siduction, please don't pm me or discuss here about  *custom* distro or remaster, your on your own with that.

[michaa7]

...
Everything is in my /home

Code: [Select]

[ 'options' ]
build_dir = /home/piper/pyfll/pyfll/debbuilder/pbuilder/build
output_dir = /home/piper/pyfll/pyfll/debbuilder/iso-piper
build_log = /home/piper/pyfll/pyfll/build_log/build.log

Thanks for that.

... especially devil who  *gasp*  spoon-fed  me learnin to build.

You can't imagine how much I'd loved to see this video documented ;-)

[piper]

You can't imagine how much I'd loved to see this video documented ;-)

That's cutting into my drinking time

[GoinEasy9]

After building this machine close to 2 years ago, I have never seen all 8 cores working full blast.  It looked brilliant on gkrellm

2014-07-28 12:20:21,553 INFO  - creating squashfs filesystem of amd64 chroot...
Parallel mksquashfs: Using 8 processors
Creating 4.0 filesystem on siduction.amd64, block size 131072.
[==========================================================================================-] 127495/127495 100%

After a few problems with dependencies, I seem to have it working.  Geez, I wanted to pyfll for years.

real    52m58.226s
user    14m22.825s
sys     3m58.518s