On 4 January 2014 19:42, Tollef Fog Heen <tfh...@err.no> wrote: > ]] Dimitri John Ledkov > >> Also which upstream are staying with? systemd upstream git history[4] >> has only one branch, which is linear with linear version number >> increments, without any stable release branches or other indications >> of which patches are stable (or possibly security) bugfixes. > > That's generally communicated in the release announcements as well as on > the systemd-devel mailing list. >
having a easily accessible stable branches, as e.g. by Zbigniew Jędrzejewski-Szmek, would help a wider range of developers and sysadmins to check for bugfixes of discovered bugs. >> Fedora 19 appears to be packaging patches from v204-stable branch >> which I can't find anywhere public. Thankfully it's not a single giant >> patch as it's done by RedHat for their kernels, but actually git am >> formatted series of 116 patches[5]. > > Were you unable to find > http://pkgs.fedoraproject.org/cgit/systemd.git/log/?h=f19 ? It's where > Fedora has all of their packaging.. > As explained by Zbigniew Jędrzejewski-Szmek, that is not actually where that happens. that is a one to one mapping with src.rpms and builds dispatched to Koji. I am well aware of Fedora packaging practices, and although I am yet to have an update/package accepted into fedora, I frequently monitor and cherrypick patches from Fedora for packages that I maintain, or bugfixes I work on. My comments were raised on inspection of that repository (or src.rpm which are equivalent) and spec file, to notice that a static git patch series is maintained from non-identified location, which I have also failed to locate. >> Fedora/RPM based distributions are significantly different, thus it is >> inevitable that we'll have to maintain a fork of systemd for best >> integration into Debian. This does not seem evident from the current >> systemd maintainers, which file bugs to disable/remove/override debian >> functionality and components with inferior systemd counterparts. > > Can you provide bug numbers for those allegations, please? > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;bug=716812 Rejections on mailinglists and else where to split: /lib/systemd/systemd-multi-seat-x /lib/systemd/systemd-timedated /lib/systemd/systemd-localed /lib/systemd/systemd-logind /lib/systemd/systemd-hostnamed from systemd package to individual packages binary packages, or at least together but separate from systemd-init. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719738 - udev "follow upstream" change, granted, steps have later been taken back to preserve backwards compat. These are just some that I have been involved in. >> [4] it appears that upstream git is used as packaging basis, instead >> of the tarball which has pre-generated documentation and loads of >> other files. > > If you here are talking about the systemd packaging, it seems you've > misunderstood something. What are you missing in the source package? > I've downloaded systemd_204.orig.tar.gz from debian mirror - 3ba441b51a390c6afc21e9a8a4811698 And i've downloaded systemd-204.tar.xz from systemd upstream - a07619bb19f48164fbf0761d12fd39a8 The diff between the two is http://paste.debian.net/74333/ - 477 files changed, 566 insertions(+), 246 deletions(-). I don't believe i'm missing anything in the source package, but because packaging doesn't seem to use debian/patches directory, does not use upstream published tarball, and does not have recommended get-orig-source target, it's very hard to see and instepect how and why upstream tarball is repackaged and more importantly what's changed. Even further looking at the git history in the declared packaging: it mixes upstream commits with packaging, not-rebased and not-linear, with some git-buildpackage features - e.g. the pristine-tar branch and commits of the upstream 204.orig.tar.xz, which at the end is not the tarball uploaded into the archive. Does this answer what I am missing in the source package? apart from physical files, audit trail would be a good start or at least following any of the practices adviced by the debian policy - patch target, 3.0 (quilt) format, using upstream tarballs, get-orig-source target if upstream tarball is not used, or after all that README.source explaining things... -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluja7dm_gddt_b6ioxdpmwmws9v1xpkgs84-lu50_n8...@mail.gmail.com
