Re: [qubes-devel] Re: DNF for Debian
Quoting Frédéric Pierret (2020-07-02 18:44:24) > On 2020-07-02 15:46, Mihai Moldovan wrote: > > * On 7/2/20 2:27 PM, Peter Pentchev wrote: > >> On Thu, Jul 02, 2020 at 10:34:19AM +0200, Frédéric Pierret wrote: > >>> - modulemd1 > >> > >> Hmm, I have an ITP bug open for libmodulemd as part of my work on > >> createrepo-c and my libmodulemd package is already in NEW :) > >> https://ftp-master.debian.org/new.html > > Sorry I've missed it. I don't have the whole big picture of Debian > packaging pipelines in mind yet. Please do tell when you get the full picture¹ - I am still struggling at it, after 19 years in Debian. :-) - Jonas ¹ Or take the shortcut and ask Paul Wise... -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [qubes-devel] Re: DNF for Debian
Peter, Mihai, On 2020-07-02 15:46, Mihai Moldovan wrote: > * On 7/2/20 2:27 PM, Peter Pentchev wrote: >> On Thu, Jul 02, 2020 at 10:34:19AM +0200, Frédéric Pierret wrote: >>> - modulemd1 >> >> Hmm, I have an ITP bug open for libmodulemd as part of my work on >> createrepo-c and my libmodulemd package is already in NEW :) >> https://ftp-master.debian.org/new.html Sorry I've missed it. I don't have the whole big picture of Debian packaging pipelines in mind yet. > That's fine. Note that you packaged libmodulemd 2.x, which is not what dnf > needs. I hence named it modulemd1. (Could have went for libmodulemd1 as well, > but that felt odd.) > > AFAIK, the last time I looked, dnf was only compatible with the older > libmodulemd 1.x version. Fedora has also two explicit versions for this: libmodulemd (2.X) and libmodulemd1 (1.X ...) and they keep maintaining both of them. >>> There is mostly one commit above the source of Mihai with >>> "Uploaders"Frédéric Pierret >>> field added. Lintian reports several things to improve but I would >>> like to have some feedback/help on making this moving forward from >>> Debian side first before doing any new moves. Also this set of >>> packages relies on libsolv but the patch set of Mihai has been >>> currently reverted >>> (https://salsa.debian.org/debian/libsolv/-/commit/730e23a04b397cd8d8d28c8081e5ade968e04176) >>> due to pending Debian strategy about global RPM integration. > > I'd welcome this a lot. The libsolv patch is really a big hack to make libsolv > aware of and compatible with (the changes in) Debian's rpm package. This > change > breaks a lot of stuff, including mock. It's painful and the gain is > questionable. The initial idea was to discourage (and essentially make it > impossible) to install rpm packages system-wide. > > That's easily worked around, though, for anything that not uses a chroot, by > just setting %dbpath to the system location, so the whole benefit is > questionable. Worse, in chroot environments (which are typically used when > building software), all this is breaking down and getting a lot more > complicated. FYI, at first from Qubes side, we target only the use of basic DNF workflows. Especially, being able to fetch and download RPM only. We don't plan to use mock inside Debian but that's ours need and maybe that's not sufficient for Debian? > IMHO, a discussion and move to remove that rpm patch was long overdue. > > >> BTW would some of these be better in the RPM packaging group? > > Probably all of them? But the RPM packaging group is kind of stale. I would be fine with it of course. > > Mihai > Thank you for your answers. Frédéric signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] Re: DNF for Debian
* On 7/2/20 2:27 PM, Peter Pentchev wrote: > On Thu, Jul 02, 2020 at 10:34:19AM +0200, Frédéric Pierret wrote: >> - modulemd1 > > Hmm, I have an ITP bug open for libmodulemd as part of my work on > createrepo-c and my libmodulemd package is already in NEW :) > https://ftp-master.debian.org/new.html That's fine. Note that you packaged libmodulemd 2.x, which is not what dnf needs. I hence named it modulemd1. (Could have went for libmodulemd1 as well, but that felt odd.) AFAIK, the last time I looked, dnf was only compatible with the older libmodulemd 1.x version. >> There is mostly one commit above the source of Mihai with >> "Uploaders"Frédéric Pierret >> field added. Lintian reports several things to improve but I would >> like to have some feedback/help on making this moving forward from >> Debian side first before doing any new moves. Also this set of >> packages relies on libsolv but the patch set of Mihai has been >> currently reverted >> (https://salsa.debian.org/debian/libsolv/-/commit/730e23a04b397cd8d8d28c8081e5ade968e04176) >> due to pending Debian strategy about global RPM integration. I'd welcome this a lot. The libsolv patch is really a big hack to make libsolv aware of and compatible with (the changes in) Debian's rpm package. This change breaks a lot of stuff, including mock. It's painful and the gain is questionable. The initial idea was to discourage (and essentially make it impossible) to install rpm packages system-wide. That's easily worked around, though, for anything that not uses a chroot, by just setting %dbpath to the system location, so the whole benefit is questionable. Worse, in chroot environments (which are typically used when building software), all this is breaking down and getting a lot more complicated. IMHO, a discussion and move to remove that rpm patch was long overdue. > BTW would some of these be better in the RPM packaging group? Probably all of them? But the RPM packaging group is kind of stale. Mihai signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] Re: DNF for Debian
On Thu, Jul 02, 2020 at 10:34:19AM +0200, Frédéric Pierret wrote: > Hi, > I've published on Debian mentors the corresponding packages: > > - libcomps > - librepo > - modulemd1 Hmm, I have an ITP bug open for libmodulemd as part of my work on createrepo-c and my libmodulemd package is already in NEW :) https://ftp-master.debian.org/new.html Sorry I did not react sooner and you may have done some work that may have duplicated mine... that's kind of the point of ITP bugs though :) > - libdnf > - dnf > > There is mostly one commit above the source of Mihai with "Uploaders" > field added. Lintian reports several things to improve but I would > like to have some feedback/help on making this moving forward from > Debian side first before doing any new moves. Also this set of > packages relies on libsolv but the patch set of Mihai has been > currently reverted > (https://salsa.debian.org/debian/libsolv/-/commit/730e23a04b397cd8d8d28c8081e5ade968e04176) > due to pending Debian strategy about global RPM integration. BTW would some of these be better in the RPM packaging group? G'luck, Peter > On 2020-06-21 21:31, Frédéric Pierret wrote: > > > > On 2020-05-29 12:43, Holger Levsen wrote: > >> hi Mihai, > >> > >> On Fri, May 29, 2020 at 12:17:13PM +0200, Mihai Moldovan wrote: > >>> Sorry for the late response. I've been busy, and, honestly, also always > >>> forgot > >>> to actually answer. > >> > >> thanks for your reply & don't worry, this happens often & to many people, > >> me > >> included. > >> > >>> unman seems to be interested, if that's good enough, so there's that. > >> > >> that is good enough if not much better than that. > >> > all very very nice! It would be a pity to have this rot, but then, > without > maintenance it will anyway eventually... > >>> > >>> Personally, I will have to "maintain" the package sets anyway, because I'm > >>> building a lot of Fedora/CentOS packages in an automatic fashion on > >>> Debian. > >>> > >>> This "maintenance" just means that I'll probably update stuff every half > >>> a year > >>> or year, though, essentially "whenever it breaks" (which does tend to > >>> happen). > >> [...] > >>> As given in the initial description, I've published source and binary > >>> packages > >>> for Debian Unstable/Sid at > >>> https://packages.x2go.org/debian-test/pool/main/ > >>> > >>> Note that the binaries are a bit old by now and would probably like a > >>> rebuild, > >>> but the source is still the one I'm also using on my package builder. > >>> > >>> Also, the packages became a bit stale version wise (after all, they are 9 > >>> month > >>> old by now) and some included patches have already been applied upstream. > >>> I > >>> haven't tried updating (and testing any updates) yet, though, and > >>> probably won't > >>> come to that shortly either. > >> > >> the important part is whether we'll get these packages ready and up to date > >> until end of 2020 *and* whether we can commit to maintain important fixes > >> after that. > >> > >> end of 2020 because of "key release dates" on https://release.debian.org/ > >> > >> it's ok(ish) if the stuff is outdated today, but in 6 month it really > >> should be current. > >> (and then after the release we can slack a bit again, though usually it's > >> less effort to always package and upload the latest version.) > >> > >> > > > > Hi everyone, > > I've packaged for Qubes all the work (not the dnf plugins as we don't need > > it currently) of Mihai with little few adjustments: > > > > https://github.com/fepitre/qubes-libcomps > > https://github.com/fepitre/qubes-librepo > > https://github.com/fepitre/qubes-libsolv > > https://github.com/fepitre/qubes-libmodulemd1 > > https://github.com/fepitre/qubes-libdnf > > https://github.com/fepitre/qubes-dnf > > > > I've built and tested all of them into Bullseye. With this freshly created > > bullseye template as UpdateVM, it makes dom0 update working like a charm! > > > > I can help into testing/maintaining/any other thing needed to make things > > moving forward for Bullseye and especially having DNF in Debian. -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: [qubes-devel] Re: DNF for Debian
Hi, I've published on Debian mentors the corresponding packages: - libcomps - librepo - modulemd1 - libdnf - dnf There is mostly one commit above the source of Mihai with "Uploaders" field added. Lintian reports several things to improve but I would like to have some feedback/help on making this moving forward from Debian side first before doing any new moves. Also this set of packages relies on libsolv but the patch set of Mihai has been currently reverted (https://salsa.debian.org/debian/libsolv/-/commit/730e23a04b397cd8d8d28c8081e5ade968e04176) due to pending Debian strategy about global RPM integration. Best regards, Frédéric On 2020-06-21 21:31, Frédéric Pierret wrote: > > On 2020-05-29 12:43, Holger Levsen wrote: >> hi Mihai, >> >> On Fri, May 29, 2020 at 12:17:13PM +0200, Mihai Moldovan wrote: >>> Sorry for the late response. I've been busy, and, honestly, also always >>> forgot >>> to actually answer. >> >> thanks for your reply & don't worry, this happens often & to many people, me >> included. >> >>> unman seems to be interested, if that's good enough, so there's that. >> >> that is good enough if not much better than that. >> all very very nice! It would be a pity to have this rot, but then, without maintenance it will anyway eventually... >>> >>> Personally, I will have to "maintain" the package sets anyway, because I'm >>> building a lot of Fedora/CentOS packages in an automatic fashion on Debian. >>> >>> This "maintenance" just means that I'll probably update stuff every half a >>> year >>> or year, though, essentially "whenever it breaks" (which does tend to >>> happen). >> [...] >>> As given in the initial description, I've published source and binary >>> packages >>> for Debian Unstable/Sid at https://packages.x2go.org/debian-test/pool/main/ >>> >>> Note that the binaries are a bit old by now and would probably like a >>> rebuild, >>> but the source is still the one I'm also using on my package builder. >>> >>> Also, the packages became a bit stale version wise (after all, they are 9 >>> month >>> old by now) and some included patches have already been applied upstream. I >>> haven't tried updating (and testing any updates) yet, though, and probably >>> won't >>> come to that shortly either. >> >> the important part is whether we'll get these packages ready and up to date >> until end of 2020 *and* whether we can commit to maintain important fixes >> after that. >> >> end of 2020 because of "key release dates" on https://release.debian.org/ >> >> it's ok(ish) if the stuff is outdated today, but in 6 month it really should >> be current. >> (and then after the release we can slack a bit again, though usually it's >> less effort to always package and upload the latest version.) >> >> > > Hi everyone, > I've packaged for Qubes all the work (not the dnf plugins as we don't need it > currently) of Mihai with little few adjustments: > > https://github.com/fepitre/qubes-libcomps > https://github.com/fepitre/qubes-librepo > https://github.com/fepitre/qubes-libsolv > https://github.com/fepitre/qubes-libmodulemd1 > https://github.com/fepitre/qubes-libdnf > https://github.com/fepitre/qubes-dnf > > I've built and tested all of them into Bullseye. With this freshly created > bullseye template as UpdateVM, it makes dom0 update working like a charm! > > I can help into testing/maintaining/any other thing needed to make things > moving forward for Bullseye and especially having DNF in Debian. > > Best regards, > Frédéric > > signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] Re: DNF for Debian
On 2020-05-29 12:43, Holger Levsen wrote: > hi Mihai, > > On Fri, May 29, 2020 at 12:17:13PM +0200, Mihai Moldovan wrote: >> Sorry for the late response. I've been busy, and, honestly, also always >> forgot >> to actually answer. > > thanks for your reply & don't worry, this happens often & to many people, me > included. > >> unman seems to be interested, if that's good enough, so there's that. > > that is good enough if not much better than that. > >>> all very very nice! It would be a pity to have this rot, but then, without >>> maintenance it will anyway eventually... >> >> Personally, I will have to "maintain" the package sets anyway, because I'm >> building a lot of Fedora/CentOS packages in an automatic fashion on Debian. >> >> This "maintenance" just means that I'll probably update stuff every half a >> year >> or year, though, essentially "whenever it breaks" (which does tend to >> happen). > [...] >> As given in the initial description, I've published source and binary >> packages >> for Debian Unstable/Sid at https://packages.x2go.org/debian-test/pool/main/ >> >> Note that the binaries are a bit old by now and would probably like a >> rebuild, >> but the source is still the one I'm also using on my package builder. >> >> Also, the packages became a bit stale version wise (after all, they are 9 >> month >> old by now) and some included patches have already been applied upstream. I >> haven't tried updating (and testing any updates) yet, though, and probably >> won't >> come to that shortly either. > > the important part is whether we'll get these packages ready and up to date > until end of 2020 *and* whether we can commit to maintain important fixes > after that. > > end of 2020 because of "key release dates" on https://release.debian.org/ > > it's ok(ish) if the stuff is outdated today, but in 6 month it really should > be current. > (and then after the release we can slack a bit again, though usually it's > less effort to always package and upload the latest version.) > > Hi everyone, I've packaged for Qubes all the work (not the dnf plugins as we don't need it currently) of Mihai with little few adjustments: https://github.com/fepitre/qubes-libcomps https://github.com/fepitre/qubes-librepo https://github.com/fepitre/qubes-libsolv https://github.com/fepitre/qubes-libmodulemd1 https://github.com/fepitre/qubes-libdnf https://github.com/fepitre/qubes-dnf I've built and tested all of them into Bullseye. With this freshly created bullseye template as UpdateVM, it makes dom0 update working like a charm! I can help into testing/maintaining/any other thing needed to make things moving forward for Bullseye and especially having DNF in Debian. Best regards, Frédéric signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] Re: DNF for Debian
Hi unman, On Sun, May 03, 2020 at 05:07:14PM +0100, unman wrote: > I'd be happy to take on maintenance of this package, and may be anything > else that's Qubes required but seems to be lapsing in Debian. cool. I'll be happy to review & sponsor these uploads to Debian! > Also, I wonder if there would be value in getting Qubes packages in to > Debian, so they can be installed straight in to HVM - I seem to recall > this was raised some time back, but dont recall outcome. Waste of time? I gave up working on https://wiki.debian.org/Qubes/Devel as I believe dom0 should use something more tailored and shrinked down system then both Debian and Fedora are and because the Qubes and Debian release cycles don't match at all, thus one will probably always need a Qubes apt repo too. I'm not sure to which packages / use-case you are refering to. Can you explain again, please? -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C There are only two kinds of nazis: stupid ones and those without an excuse. (Volker Strübing) signature.asc Description: PGP signature
Re: [qubes-devel] Re: DNF for Debian
On 2020-05-03 18:07, unman wrote: > On Sun, May 03, 2020 at 12:03:40PM +, Holger Levsen wrote: >> Hi Mihai, >> >> On Fri, Sep 13, 2019 at 05:36:55PM +0200, Mihai Moldovan wrote: >>> I've packaged DNF >> >> cool! >> >>> for Debian and would like to find someone to take over these >>> packages and maintain them as part of the distribution. >>> >>> I'm not a DD and while I believe the packages to be of reasonable if not >>> high >>> quality, I already have enough on my plate and know that I will not be able >>> to >>> properly maintain them, keep up with upstream releases etc. >>> Point in case: while I did the original packaging more than a year, I only >>> updated this set of packages recently when they actually broke with newer >>> Fedora >>> releases (i.e., they were too old to create newer Fedora changeroots when >>> used >>> by mock). >> >> hm, I'd be willing to sponsor and mentor those uploads, but I cannot commit >> to maintaining them as well. Is there anybody out there who would? >> >>> == What is DNF? == >> [...] >>> == Why does Debian need DNF? == >> [...] >>> == Prerequisites == >> [...] >>> == Package List == >> [...] >>> == Repository == >> [...] >> >> all very very nice! It would be a pity to have this rot, but then, without >> maintenance it will anyway eventually... >> >> >> -- >> cheers, >> Holger >> > > Hi Holger > > I'd be happy to take on maintenance of this package, and may be anything > else that's Qubes required but seems to be lapsing in Debian. > I'll do the necessary in the morning. unman, do you have any timeline available for this? We are currently facing the problem of making core-agent-dom0-updates not available in Debian due to missing yum/dnf in bullseye. If you lack time, I could manage to build the package for Qubes as a first step/test. > Also, I wonder if there would be value in getting Qubes packages in to > Debian, so they can be installed straight in to HVM - I seem to recall > this was raised some time back, but dont recall outcome. Waste of time? > > cheers > > unman > Best, Frédéric signature.asc Description: OpenPGP digital signature
Re: [qubes-devel] Re: DNF for Debian
On Sun, May 03, 2020 at 12:03:40PM +, Holger Levsen wrote: > Hi Mihai, > > On Fri, Sep 13, 2019 at 05:36:55PM +0200, Mihai Moldovan wrote: > > I've packaged DNF > > cool! > > > for Debian and would like to find someone to take over these > > packages and maintain them as part of the distribution. > > > > I'm not a DD and while I believe the packages to be of reasonable if not > > high > > quality, I already have enough on my plate and know that I will not be able > > to > > properly maintain them, keep up with upstream releases etc. > > Point in case: while I did the original packaging more than a year, I only > > updated this set of packages recently when they actually broke with newer > > Fedora > > releases (i.e., they were too old to create newer Fedora changeroots when > > used > > by mock). > > hm, I'd be willing to sponsor and mentor those uploads, but I cannot commit > to maintaining them as well. Is there anybody out there who would? > > > == What is DNF? == > [...] > > == Why does Debian need DNF? == > [...] > > == Prerequisites == > [...] > > == Package List == > [...] > > == Repository == > [...] > > all very very nice! It would be a pity to have this rot, but then, without > maintenance it will anyway eventually... > > > -- > cheers, > Holger > Hi Holger I'd be happy to take on maintenance of this package, and may be anything else that's Qubes required but seems to be lapsing in Debian. I'll do the necessary in the morning. Also, I wonder if there would be value in getting Qubes packages in to Debian, so they can be installed straight in to HVM - I seem to recall this was raised some time back, but dont recall outcome. Waste of time? cheers unman
