Op Wed, 04 May 2016 11:51:14 +0100 schreef Bob Ham <[email protected]>:
> Definitely. The fact that Ucclia packages were manually developed > was a massive turn off for helping. Understandable. The main reason to go manual was the trouble we had with the openoffice.org package. It also seemed a cleaner approach. > > Code repository contains helper scripts instead of patches. > > For Trisquel it contains both, e.g. > > https://devel.trisquel.info/trisquel/package-helpers/blob/belenos/helpers/DATA/fop/replace-sRGB-profile.patch > https://devel.trisquel.info/trisquel/package-helpers/blob/belenos/helpers/make-fop > > where the helper script applies a patch. There's quite a few of > those. Patches are a more common way of sharing changes than modifying scripts. Debian likes to know about the patches in its derivatives [1]. > > Could only be used for 1 distro at a time. > > I don't understand this. Do you mean you want to bring packages from > more than one upstream, like Debian and Ubuntu? The terminology in Debian is a bit confusing sometimes. By distribution [2] I mean a particular major version, e.g. Ucclia. When we used Builder for gNS 2 we could only work on DeltaH because the configuration allowed only 1 codename, 1 upstream, 1 blacklist etc. And multiple instances of Builder would clobber each other. > Perhaps it would be a good idea to be very clear here about what the > goal of gNewSense is. Would you care to share what your personal > goals are with gNewSense, Sam? And for that matter, anyone else > looking to help? > > Personally, what I want is a version of Debian modified to adhere to > the FSF's Free System Distribution Guidelines, nothing more. It > doesn't make sense to me to do anything beyond bringing a > non-FSDG-compliant distro into compliance and making it presentable. > From the perspective of software freedom, it seems like there are > bigger fish to fry. That's the biggest part of it. But ideally we would also include new developments or improved configuration with respect to freedom and privacy. I'm thinking of software like Ring [3] and support for new libre file formats. But this might lead us in the the messy realm of backports. > > Packages that need changes to binary content (like openoffice.org in > > gNewSense 2) are very hard or impossible to handle. > > Could you explain a little more about this, particular why it's > difficult to handle? Do you know how Trisquel have dealt with this > problem? IIRC, the openoffice.org source package was made up of several archives and at least 1 of those contained several archives that in turn contained archives that contained Uuencoded archives. Doing all the unpacking and repacking in the helper script is not a problem, but if you modify a file within an archive then the resulting diff is binary (because it diffs the archive and not it's contents). The dpkg scripts choked on that. In the end I did the repackaging manually. That worked, but it meant that we had to let Builder include the package as a package. And so we needed to have the whole openoffice.org source package in the data folder in VCS. Pushing that to Savannah would not have been very nice, so we had to move our VCS repo to our own server. All that took quite a bit of figuring out and testing. And of course that kind of mess always happens to the packages with huge build times. That contributed quite a number of days to our current release lag. If I ever have to do that again, I quit. > From http://www.gnewsense.org/Processes/Packaging: > > > we want to include software that is not (yet) in Debian, but which > > is very useful to free software users. > > Could you give an example of such software? Personally, I'm happy to > live with Debian's slow releases. That's one of the consequences of > Debian's high quality and I'm happy to live with it. If I wanted more > up-to-date software, I'd just use Trisquel :-) See examples above. If the FSF announce some awesome news about how free software users can now finally access some data format (think Gnash, libdvdcss) or about a new threat to freedom (think LibreJS) then it would be nice to have it supported in the recommended distributions. > One question I have is: does gNewSense have builder machines running > pbuilder or whatever? In fact, is there any information about > gNewSense's infrastructure anywhere? I couldn't find anything on the > wiki. Karl once wrote a bit of that [4], [5]. Although the rebuildd setup broke and I invoke pbuilder manually now. [1] https://wiki.debian.org/Derivatives/Census/gNewSense, patches repo (not filled because we don't have 1 repo for patches) [2] https://wiki.debian.org/Glossary#distribution [3] https://ring.cx/en [4] http://www.gnewsense.org/DevelopmentTeam/NewStyleBuildds [5] http://www.gnewsense.org/kgoetz/RebuilddSetup _______________________________________________ gNewSense-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/gnewsense-dev
