[EPEL-devel] Re: Building EPEL-8 package depending on module

2021-09-06 Thread Stefan Bluhm 
Thank you Petr and Stephen,

the background explanations and solutions were really helpful!

I will try to proceed to repackage the troubling packages as I need them 
anyways. That would simplify it a lot.

Best wishes,

Stefan

- Ursprüngliche Mail -
Von: "Stephen John Smoogen" 
An: "epel-devel" 
Gesendet: Montag, 6. September 2021 15:10:30
Betreff: [EPEL-devel] Re: Building EPEL-8 package depending on module

On Mon, 6 Sept 2021 at 07:07, Petr Pisar  wrote:
>
> V Sun, Sep 05, 2021 at 09:47:51PM +0200, Stefan Bluhm napsal(a):
> > I am trying to build a package for EPEL-8.
> > (https://koji.fedoraproject.org/koji/taskinfo?taskID=75036069)
> >
> > The build fails with
> >
> > No matching package to install: 'glassfish-jaxb-api'
> > No matching package to install: 'jaf'
> > Not all dependencies satisfied
> > Error: Some packages could not be found.
> >
> > "glassfish-jaxb-api" and "jaf" are available in AppStream modules 
> > "pki-deps" and "jmc".
> >
> > 1. Why can't these packages be found? I thought koji auto-resolves/flattens 
> > the modules.
> >
> Koji only flattens default module streams. Those are flagged with "[d]" in
> "dnf module list" output. Those streams are "enabled" by default and therefore
> Koji flattens them. Other streams must be explicitly enabled with "dnf module
> enable module:stream" and Koji does not flatten them.
>
> glassfish-jaxb-api belongs to pki-deps:10.6 stream (as found by "dnf module
> provides glassfish-jaxb-api" command).
>
> pki-deps:10.6 is not a default stream (as reported by "dnf module list
> pki-deps"; compare to "dnf module list php").
>
> Therefore Koji does not flatten pki-deps:10.6 module stream and its packages
> are not available in an EPEL build root.
>
> Why is not the stream default? (Even if it's the only pki-deps stream.)
> Because it's an internal dependency for pki-core:10.6 stream perhaps not
> intended for other use.
>
> > 2. What is the right approach to build the package that depends on modules?
> >
> The right approach for building a package that depends on a non-default stream
> is building it as another module.
>

Sadly that doesn't work either in the Koji system, because MBS does
not see those modules as belonging to anything it has built. So it
seems it can only depend on modules which it has built .. So not only
do we have to build this tool as a module, we also have to build
pki-deps:10.6 locally.


> Please note that due to Fedora policies
>  your new module
> can't be made default one. Hence if you decide for creating "xstream"
> module, your users will have to install xstream with "dnf module install
> xstream" (or "dnf module enable xstream && dnf install xstream").
>
> Another option is to skip all the modular things and repackage
> glassfish-jaxb-api in EPEL as any other missing package. This is explictly
> allowed for packages from RHEL non-default streams
> .
>
> -- Petr
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Fedora EPEL 7 updates-testing report

2021-09-06 Thread updates 
The following builds have been pushed to Fedora EPEL 7 updates-testing

dkms-2.8.6-1.el7
mirrormanager2-0.16-1.el7
xorgxrdp-0.2.17-2.el7
xrdp-0.9.17-2.el7

Details about builds:



 dkms-2.8.6-1.el7 (FEDORA-EPEL-2021-830f0be220)
 Dynamic Kernel Module Support Framework

Update Information:

Update to bugfix release 2.8.6.

ChangeLog:

* Sat Sep  4 2021 Simone Caronni  - 2.8.6-1
- Update to 2.8.6.




 mirrormanager2-0.16-1.el7 (FEDORA-EPEL-2021-08ded2bf03)
 Mirror management application

Update Information:

Update to 0.16

ChangeLog:

* Mon Sep  6 2021 Adrian Reber  - 0.16-1
- Update to 0.16
- Added support for admin only categories
- Added support for empty top dirs ('')
* Thu Jul 22 2021 Fedora Release Engineering  - 0.15-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild
* Fri Jun  4 2021 Python Maint  - 0.15-3
- Rebuilt for Python 3.10




 xorgxrdp-0.2.17-2.el7 (FEDORA-EPEL-2021-f8050b5abe)
 Implementation of xrdp backend as Xorg modules

Update Information:

# Release notes for xrdp v0.9.17 (2021/08/31)  ## General announcements *
Running xrdp and xrdp-sesman on separate hosts is still supported by this
release, but is now deprecated. This is not secure. A future release will
replace the TCP socket used between these processes with a Unix Domain Socket,
and then cross-host running will not be possible.  ## New features * The IP
address, port, and user name of NeutrinoRDP Proxy connection are logged in
xrdp.log - these connections may not have a sesman log to use (#1873) * The
performance settings for NeutrinoRDP can be now configured (#1903) * Support for
Alpine Linux in startwm.sh (#1965) * clipboard: log file transfer for the
purpose of audit (#1954) * Client's Keyboard layout now can be overridden by
xrdp configuration for debugging purposes (#1952)  ## Bug fixes * PAM_USER
environment variable is not set when using pam_exec module (#1882) * Allow
common channel settings to be overridden for modules as well as chansrv (#1899)
* The text only-copy/paste interface for the VNC module (used only when chansrv
is not active) has been improved (#1900) * The unsupported `tcutils` utility has
been removed (#1943) * The quality of TLS logging has been improved (#1926) *
Keyboard information is now passed correctly through NeuutrinoRDP, and can be
overridden if required (#1934) * A message is now logged in the sesman log for
unsuccessful login attempts detailing the user used (#1947)  ## Internal changes
* astyle formatting is now checked during CI builds (#1879) * Generalise
development build options, and add --enable-devel-streamcheck (#1887) * Now uses
cppcheck 2.5 for CI builds (#1938) * The SCP protocol is now using a standard
`struct trans` for messaging rather than its own thing (#1925)  ## Changes for
packagers or developers * The `--enable-xrdpdebug` developer option has been
replaced with finer-grained `--enable-devel-*` options. Consequently, specifying
`--enable-xrdpdebug` is now an error (#1913)  ## Known issues  * On-the-fly
resolution change requires the Microsoft Store version of Remote Desktop client
but sometimes crashes on connect (#1869) * xrdp's login dialog is not relocated
at the center of the new resolution after on-the-fly resolution change happens
(#1867)  # Rebuild of xorgxrdp 0.2.17 against xrdp 0.9.17.    This version
includes following features and fixes:  - Avoid potential infinite loop for
rdpUpdate #193

ChangeLog:

* Mon Sep  6 2021 Bojan Smojver  - 0.2.17-2
- Rebuild against xrdp 0.9.17
* Tue Aug 31 2021 Bojan Smojver  - 0.2.17-1
- Bump up to 0.2.17

References:

  [ 1 ] Bug #1999538 - xorgxrdp-0.2.17 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1999538




 xrdp-0.9.17-2.el7 (FEDORA-EPEL-2021-f8050b5abe)
 Open source remote desktop protocol (RDP) server

[EPEL-devel] Fedora EPEL 8 updates-testing report

2021-09-06 Thread updates 
The following Fedora EPEL 8 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-303db869be   
chromium-93.0.4577.63-1.el8


The following builds have been pushed to Fedora EPEL 8 updates-testing

cd-discid-1.4-20.el8
certbot-1.18.0-2.el8
dkms-2.8.6-1.el8
xorgxrdp-0.2.17-2.el8
xrdp-0.9.17-2.el8

Details about builds:



 cd-discid-1.4-20.el8 (FEDORA-EPEL-2021-326121598a)
 Utility to get CDDB discid information

Update Information:

A dependency of `abcde`.

ChangeLog:


References:

  [ 1 ] Bug #1998853 - [RFE:EPEL] Request to add cd-discid to EPEL 8
https://bugzilla.redhat.com/show_bug.cgi?id=1998853




 certbot-1.18.0-2.el8 (FEDORA-EPEL-2021-4db8d305f7)
 A free, automated certificate authority client

Update Information:

add "--preconfigured-renewal" flag to cli.ini so certbot outputs more helpful
error messages

ChangeLog:

* Fri Sep  3 2021 Felix Schwarz  - 1.18.0-2
- enable "--preconfigured-renewal" also for EPEL8 (#1986205)

References:

  [ 1 ] Bug #1971500 - certbot: Add --preconfigured-renewal flag to cli.ini
https://bugzilla.redhat.com/show_bug.cgi?id=1971500




 dkms-2.8.6-1.el8 (FEDORA-EPEL-2021-ebc5391a03)
 Dynamic Kernel Module Support Framework

Update Information:

Update to bugfix release 2.8.6.

ChangeLog:

* Sat Sep  4 2021 Simone Caronni  - 2.8.6-1
- Update to 2.8.6.




 xorgxrdp-0.2.17-2.el8 (FEDORA-EPEL-2021-90fc876bcc)
 Implementation of xrdp backend as Xorg modules

Update Information:

# Release notes for xrdp v0.9.17 (2021/08/31)  ## General announcements *
Running xrdp and xrdp-sesman on separate hosts is still supported by this
release, but is now deprecated. This is not secure. A future release will
replace the TCP socket used between these processes with a Unix Domain Socket,
and then cross-host running will not be possible.  ## New features * The IP
address, port, and user name of NeutrinoRDP Proxy connection are logged in
xrdp.log - these connections may not have a sesman log to use (#1873) * The
performance settings for NeutrinoRDP can be now configured (#1903) * Support for
Alpine Linux in startwm.sh (#1965) * clipboard: log file transfer for the
purpose of audit (#1954) * Client's Keyboard layout now can be overridden by
xrdp configuration for debugging purposes (#1952)  ## Bug fixes * PAM_USER
environment variable is not set when using pam_exec module (#1882) * Allow
common channel settings to be overridden for modules as well as chansrv (#1899)
* The text only-copy/paste interface for the VNC module (used only when chansrv
is not active) has been improved (#1900) * The unsupported `tcutils` utility has
been removed (#1943) * The quality of TLS logging has been improved (#1926) *
Keyboard information is now passed correctly through NeuutrinoRDP, and can be
overridden if required (#1934) * A message is now logged in the sesman log for
unsuccessful login attempts detailing the user used (#1947)  ## Internal changes
* astyle formatting is now checked during CI builds (#1879) * Generalise
development build options, and add --enable-devel-streamcheck (#1887) * Now uses
cppcheck 2.5 for CI builds (#1938) * The SCP protocol is now using a standard
`struct trans` for messaging rather than its own thing (#1925)  ## Changes for
packagers or developers * The `--enable-xrdpdebug` developer option has been
replaced with finer-grained `--enable-devel-*` options. Consequently, specifying
`--enable-xrdpdebug` is now an error (#1913)  ## Known issues  * On-the-fly
resolution change requires the Microsoft Store version of Remote Desktop client
but sometimes crashes on connect (#1869) * xrdp's login dialog is not relocated
at the center of the

[EPEL-devel] Re: Building EPEL-8 package depending on module

2021-09-06 Thread Petr Pisar 
V Mon, Sep 06, 2021 at 09:10:30AM -0400, Stephen John Smoogen napsal(a):
> On Mon, 6 Sept 2021 at 07:07, Petr Pisar  wrote:
> > V Sun, Sep 05, 2021 at 09:47:51PM +0200, Stefan Bluhm napsal(a):
> > > 2. What is the right approach to build the package that depends on 
> > > modules?
> > >
> > The right approach for building a package that depends on a non-default 
> > stream
> > is building it as another module.
> >
> 
> Sadly that doesn't work either in the Koji system, because MBS does
> not see those modules as belonging to anything it has built. So it
> seems it can only depend on modules which it has built .. So not only
> do we have to build this tool as a module, we also have to build
> pki-deps:10.6 locally.
>
I see.  hasn't been touch for
a year.

-- Petr



signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Building EPEL-8 package depending on module

2021-09-06 Thread Stephen John Smoogen 
On Mon, 6 Sept 2021 at 07:07, Petr Pisar  wrote:
>
> V Sun, Sep 05, 2021 at 09:47:51PM +0200, Stefan Bluhm napsal(a):
> > I am trying to build a package for EPEL-8.
> > (https://koji.fedoraproject.org/koji/taskinfo?taskID=75036069)
> >
> > The build fails with
> >
> > No matching package to install: 'glassfish-jaxb-api'
> > No matching package to install: 'jaf'
> > Not all dependencies satisfied
> > Error: Some packages could not be found.
> >
> > "glassfish-jaxb-api" and "jaf" are available in AppStream modules 
> > "pki-deps" and "jmc".
> >
> > 1. Why can't these packages be found? I thought koji auto-resolves/flattens 
> > the modules.
> >
> Koji only flattens default module streams. Those are flagged with "[d]" in
> "dnf module list" output. Those streams are "enabled" by default and therefore
> Koji flattens them. Other streams must be explicitly enabled with "dnf module
> enable module:stream" and Koji does not flatten them.
>
> glassfish-jaxb-api belongs to pki-deps:10.6 stream (as found by "dnf module
> provides glassfish-jaxb-api" command).
>
> pki-deps:10.6 is not a default stream (as reported by "dnf module list
> pki-deps"; compare to "dnf module list php").
>
> Therefore Koji does not flatten pki-deps:10.6 module stream and its packages
> are not available in an EPEL build root.
>
> Why is not the stream default? (Even if it's the only pki-deps stream.)
> Because it's an internal dependency for pki-core:10.6 stream perhaps not
> intended for other use.
>
> > 2. What is the right approach to build the package that depends on modules?
> >
> The right approach for building a package that depends on a non-default stream
> is building it as another module.
>

Sadly that doesn't work either in the Koji system, because MBS does
not see those modules as belonging to anything it has built. So it
seems it can only depend on modules which it has built .. So not only
do we have to build this tool as a module, we also have to build
pki-deps:10.6 locally.


> Please note that due to Fedora policies
>  your new module
> can't be made default one. Hence if you decide for creating "xstream"
> module, your users will have to install xstream with "dnf module install
> xstream" (or "dnf module enable xstream && dnf install xstream").
>
> Another option is to skip all the modular things and repackage
> glassfish-jaxb-api in EPEL as any other missing package. This is explictly
> allowed for packages from RHEL non-default streams
> .
>
> -- Petr
> ___
> epel-devel mailing list -- epel-devel@lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure



-- 
Stephen J Smoogen.
I've seen things you people wouldn't believe. Flame wars in
sci.astro.orion. I have seen SPAM filters overload because of Godwin's
Law. All those moments will be lost in time... like posts on a BBS...
time to shutdown -h now.
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[EPEL-devel] Re: Building EPEL-8 package depending on module

2021-09-06 Thread Petr Pisar 
V Sun, Sep 05, 2021 at 09:47:51PM +0200, Stefan Bluhm napsal(a):
> I am trying to build a package for EPEL-8.
> (https://koji.fedoraproject.org/koji/taskinfo?taskID=75036069)
> 
> The build fails with
> 
> No matching package to install: 'glassfish-jaxb-api'
> No matching package to install: 'jaf'
> Not all dependencies satisfied
> Error: Some packages could not be found.
> 
> "glassfish-jaxb-api" and "jaf" are available in AppStream modules "pki-deps" 
> and "jmc".
> 
> 1. Why can't these packages be found? I thought koji auto-resolves/flattens 
> the modules.
> 
Koji only flattens default module streams. Those are flagged with "[d]" in
"dnf module list" output. Those streams are "enabled" by default and therefore
Koji flattens them. Other streams must be explicitly enabled with "dnf module
enable module:stream" and Koji does not flatten them.

glassfish-jaxb-api belongs to pki-deps:10.6 stream (as found by "dnf module
provides glassfish-jaxb-api" command).

pki-deps:10.6 is not a default stream (as reported by "dnf module list
pki-deps"; compare to "dnf module list php").

Therefore Koji does not flatten pki-deps:10.6 module stream and its packages
are not available in an EPEL build root.

Why is not the stream default? (Even if it's the only pki-deps stream.)
Because it's an internal dependency for pki-core:10.6 stream perhaps not
intended for other use.

> 2. What is the right approach to build the package that depends on modules?
>
The right approach for building a package that depends on a non-default stream
is building it as another module.

Please note that due to Fedora policies
 your new module
can't be made default one. Hence if you decide for creating "xstream"
module, your users will have to install xstream with "dnf module install
xstream" (or "dnf module enable xstream && dnf install xstream").

Another option is to skip all the modular things and repackage
glassfish-jaxb-api in EPEL as any other missing package. This is explictly
allowed for packages from RHEL non-default streams
.

-- Petr


signature.asc
Description: PGP signature
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure