32 bit paintitblack?

[melmarker]

First: The developer - right, we have limited manpower, so only one developer care about the lxqt stuff
Second: The binariese are there, apt will tell you more.
Third: From today the binaries are available {i386, amd64} {qt4, qt5} - all untested, bleeding edge - but they compile. And that was a time consuming process with a lot of work, swear words,  upstream patches.

if you need a iso with your architecture - sorry, not available at the moment, but you can use pyfll to create one - and no, it isn't created and tested yet, we have only our release iso for LinuxTag Berlin. I'm sure that would change in the next few weeks.

If it is to slow for you: Get involved or provide the money so the dev can have a living without a regular day job.

[VladimirVilimaitis]

How long will it take until Siduction LxQt release on x86 release, approximately? Can I expect it  until the end of summer?

[melmarker]

maybe - maybe not - there is no eta

Please keep in mind that paintitblack is not a regular release - its a dev release. So if things stabilize and it make sense, we will make a new dev-iso - or not. I'm sure we will release a new dev with LXQt 0.8 - when ever it will be released. It will be done, when it is done.

[michaa7]

...
Second: The binariese are there, apt will tell you more.
...

Could you please more specific?


@ all
It is cristal clear, that limited manpower prevents siduction devs from releasing whatever or from support for pyffl. There shouldn't be any complaints about this fact.

It would be helpfull, though, if people (not devs) who did built an ISO themselves jumped in and give some infos. It would be very helpfull if someone with deeper understanding could comment *his* fll.conf a bit more. Maybe or probably a well commented fll.conf would enable more people to build there own ISO which as I see it would be a benefit to the distribution.

I myself am a guy who gets discouraged easily from a project if the number of my (may be stupid) questions superates a certain amount, no matter whether they are relevant or not. As an *example*, not knowing what *pyfll* realy means doesn't technically prevent me from building an ISO but nontheless creates uncertainty. The less uncerainty I feel, the more I am able to care about mistakes I make during a new lesson.
[EDIT] reeding /git/pyfll/pyfll/doc/fll.8.txt helps: fll=fullstory, the old sidux repo, pyfll=python fullstory scrips. So this part is solved[/EDIT]

So here is my proposal: I post here the original ffl.conf with some additional comments or questions. I'd appreciate it very much if users with experience in building an ISO could make comments to an in it (please, for readability and better orientation choose an other color):

########################################
# I assume this works like any **python**-script, so I comment out
# what I don't need
# adapt paths to my local specifics
# and write down questions as a comment
# Hopefully I get some answers as new comments in this script
########################################

[ 'sourcedistro' ]
# this section is experimental, modify at your own risk
#   name = debian
#   codename = unstable

[ 'packages' ]
# I might choose the DE between those defined in /git/pyfll/pyfll
profile = lxde

# may I comment within the following list or do I need to delete lines with unwanted i18n_s?
i18n = """
        de_DE
        en_GB
        en_US
        it_IT
        pl_PL
        pt_BR
"""

# same here
lang = """
        de_DE
        en_GB
        en_US
        it_IT
        pl_PL
        pt_BR
"""

#   do I need to make a list of all wanted packages here?
#packages = """
#"""

#
#deps = """
#"""

#
#debconf = """
#"""

[ 'archs' ]
# ok, seems clear, here i choose the architekture
        [[ 'i386' ]]
        linux = siduction-686

       #[ 'amd64' ]]
       #linux = siduction-amd64

[ 'repos' ]
       [[ 'debian' ]]
       label          = debian
       uri            = http://ftp.de.debian.org/debian/
       #cached         = http://176.9.46.77:3142/ftp.de.debian.org/debian/
# would my local archive /var/cache/apt/archives suit here
# although it is not an URL but a path to a directory?
       suite          = unstable
       components     = main

       [[ 'base' ]]
       label          = base
       uri            = http://packages.siduction.org/base
       #cached         =  http://176.9.46.77:3142/packages.siduction.org/base
       suite          = unstable
       components     = main
# what do I do here? Use your key?
       #gpgkey        = 151E2489
       #gpgkey        = /usr/share/aptosid-archive-keyring/0xE3BD538B.asc
       keyring        = siduction-archive-keyring

       [[ 'extra' ]]
       label          = extra
       uri            = http://packages.siduction.org/extra
      # cached         = http://176.9.46.77:3142/packages.siduction.org/extra
       suite          = unstable
       components     = main
       # gpgkey       = 151E2489
       # gpgkey       = /usr/share/aptosid-archive-keyring/0xE3BD538B.asc
       keyring        = siduction-archive-keyring

       [[ 'fix' ]]
       label          = fixes
       uri            = http://packages.siduction.org/fixes
       #cached         = http://176.9.46.77:3142/packages.siduction.org/fixes
       suite          = unstable
       components     = main contrib non-free
       #gpgkey        = 45C45076
       #gpgkey        = /usr/share/siduction-archive-keyring/45C45076.asc
       keyring        = siduction-archive-keyring

       # [[ 'kdenext' ]]
       # label        = kdenext
       # uri          = http://packages.siduction.org/kdenext
       # suite        = unstable
       # components   = main
       # gpgkey       = /usr/share/siduction-archive-keyring/45C45076.asc

       # [[ 'experimental' ]]
       # label        = experimental
       # uri          = http://packages.siduction.org/experimental
       # cached       = http://176.9.46.77:3142/packages.siduction.org/experimental
       # suite        = unstable
       # components   = main contrib non-free
       # #gpgkey      = 45C45076
       # #gpgkey      = /usr/share/siduction-archive-keyring/45C45076.asc
       # keyring       = siduction-archive-keyring

       [[ 'release' ]]
       label        = release
       uri          = http://packages.siduction.org/release
       #cached       = http://176.9.46.77:3142/packages.siduction.org/release
       suite        = unstable
       components   = main contrib non-free
       #gpgkey      = 45C45076
       #gpgkey      = /usr/share/siduction-archive-keyring/45C45076.asc
       keyring      = siduction-archive-keyring

[ 'options' ]
#build_dir = /var/cache/pyfll
# would "build_dir = /home/<user>/git/<sidon>/pyfll" be a valid choice?

# here I am lost
output_dir = /home/debbuilder/iso-agaida

#build_log = #/path/to/build.log

#media_include = /path/to/release/notes

#apt_preferences = /etc/apt/preferences
#http_proxy =
#ftp_proxy =

#boot_cmdline = quiet

#boot_timeout = 30

#apt_recommends = yes

# since cdebootstrap is borked, overwrite default with
# debootstrap. Reverted towo's change (hardcoded debootstrap)
bootstrapper = debootstrap

#squashfs_comp = xz

[ 'distro' ]
# I assume this could serve to personalize the ISO.
# For now it may be ok as is.
FLL_DISTRO_NAME = "siduction"
FLL_DISTRO_URL =  "http://siduction.org"

FLL_IMAGE_DIR  = "siduction"
FLL_IMAGE_FILE = "siduction"
#FLL_IMAGE_FS = "ext4"
#FLL_IMAGE_MB = "16384"
FLL_UNION_MODULE = "aufs"
FLL_MOUNTPOINT = "/fll/siduction"
FLL_MEDIA_NAME = "siduction.iso"
FLL_LIVE_USER        = "siducer"
FLL_LIVE_USER_GROUPS = "dialout dip fuse cdrom audio video plugdev users floppy netdev powerdev scanner vboxusers kvm lp"

FLL_WALLPAPER        = "/usr/share/wallpapers/siduction-desperado"
FLL_GFXBOOT_THEME    = "12.1-desperado"
FLL_IRC_SERVER       = "irc.oftc.net"
FLL_IRC_PORT         = "6667"
FLL_IRC_CHANNEL      = "#siduction"
#FLL_CDROM_INDEX      = "siduction release notes"
#FLL_CDROM_INDEX_ICON = "release/release-notes"

# here it may be a good idea to adapt the naming appropriately
FLL_DISTRO_VERSION           = 12.1
FLL_DISTRO_CODENAME_SAFE     = desperadobeta
FLL_DISTRO_CODENAME          = Desperado-Beta
FLL_DISTRO_CODENAME_REV_SAFE =
FLL_DISTRO_CODENAME_REV      =

[melmarker]

@michaa7: pyfll is doumented enough - there are the configuration files for every iso in git. so one can checkout the repo and is nearly done with the configuration. Maybe some pathes or special memory settings, but it should work out of the box. 

I would be glad if someone would write a Wiki entry   - but wait - its done: http://wiki.siduction.de/index.php?title=Erstellen_eines_siduction-%C3%A4hnlichen_ISO

Sure, there is room for improvement, but hey - its a wiki. Some additions: I don't see the need for a own partition - but why not. I've setup a debian mirror for our isos to speed up the build process a little bit - this may be a little bit of overkill for a home user, but hey - its really cool - One need only approx 350 G for the repo in booth architectures and a internet connection that allows approx 5-15G daily download to maintain the mirror. I also setup the build dir in tmpfs - 5-8 G sould be sufficient, i take 20, because we share the buildplace with pbuilder.

There are three time consuming  things within the build: 1. Downloading the needed packages (approx 1..3G, it depends), not that bad with a good connection, 2. unpack and configure the packages (nice, if one have enough Ram, one should use it), 3. Creating the squash filesystem (more and faster Processors are better, doing that in Ram is cool too).

On a normal PC with a good Internet connection a build should take approx 15-30 mins, we need 4-7 min on the buildserver, so one can add the time for downloading the finished iso. But the really timeconsuming thing is create/modify/debug a configuration, that can take some  days.

[michaa7]

Instead of this romance it would have been more helpfull to answer my questions.

@michaa7: pyfll is doumented enough

Sure, for you.

Code: [Select]

....so one can checkout the repo and is nearly done with the configuration. Maybe some pathes or special memory settings, but it should work out of the box. 

I am sure it does, exept for my questions.

I would be glad if someone would write a Wiki entry   - but wait - its done: http://wiki.siduction.de/index.php?title=Erstellen_eines_siduction-%C3%A4hnlichen_ISO

I did read it as stated above.

There are three time consuming  things within the build: 1. Downloading the needed packages (approx 1..3G, it depends)

See? After "apt-get autoclean" I have

# df -h /var/cache/apt/archives
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/sdb3        11G    7,5G  2,5G   76% /var/cache/apt/archives

. So It would be a shame to redownload what I already have avaliable. Do I really need a mirror software or is there a way to point pyfll to this directory, and if not, where does pyfll store the packages. I should be able to mount my partition containing the apt archive to this folder, isn't it?

3. Creating the squash filesystem ....

This is to short for me ...

If it is too time consuming, don't answer. But I you do, please do it to my questions.

[melmarker]

you may ask piper or dibl for help

[piper]

Little late for me  tonight, perhaps tomorrow, I can help him with just a stock build, mind you, if debian is broke, so will building

[GoinEasy9]

I'm following along too.  If I can build the iso's here, I can check to see how they install with my UEFI motherboard.  That is, if it's ready for UEFI.

[melmarker]

GoinEasy9 & all: it makes no sense to try a build now - pyfll is partly broken, some packages are gone - i will take care today (and weekend) - i think, some changes are ongoing.

[michaa7]

Little late for me  tonight, perhaps tomorrow, I can help him with just a stock build, mind you, if debian is broke, so will building

Thank's piper.

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.

And if it were advisable to install a debian mirror software (to avoid the new d/l of packages which sure as hell I have in my 7,5GB /var/cache/apt/archive), whichone should I use? apt-mirror? debpartial-mirror? debmirror? apt-move? reprepro?

And then it seems I have to wait until pyfll is fixed ...

[ReinerS]

Re. Mirror Software: I use apt-cacher-ng for providing/caching packages for my boxes.

regards

Reiner

[melmarker]

forget about apt caches - it will not work reliable. But hey - one has to make his own experiences. devil can eventually talk about approx or apt-cacher. and reprepro is not a cache - after over a half year of testing and trying we came to the conclusion, that a mirror owned by us is a clean and working solution. but ymmv.

[ReinerS]

hmm, using apt-cacher-ng as cache now since long time as I have very limited bandwidth over here. So far it has been quite reliable for that. I'll see how it will work with pyfll (If its working again).

regards

Reiner

[melmarker]

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

mmh - Maybe, if one like not reproduceble build errors or like a new adventure - in that case i would recommend approx or app-cacher. But to be true - pyfll is enough of an adventure for me.