Re: Non-responsive maintainer Daiki Ueno
Hello, Peter Oliver writes: > As per the non-responsive package maintainer process > (https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/), > does anyone know how to contact Daiki Ueno? fedora-active-user isn’t > working for me at the moment, so I haven’t been able to check his > activity within Fedora, but he is active elsewhere (e.g., > https://gitlab.com/dueno). > > There is a backlog of pull requests for the Fedora Emacs package > (https://src.fedoraproject.org/rpms/emacs/pull-requests). Marc-André > Lureau and I have volunteered to become co-maintainers to help merge > them, but we have not had a response. > > https://bugzilla.redhat.com/show_bug.cgi?id=2239916 I'm still active in Fedora and willing to help emacs when time permits; I just updated the bug. Sorry for not responding to the co-maintainer request sooner; you two should have the commit rights now. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
looking for new maintainers of the emacs package
Hello, Since I picked up the package from Jan a few years ago, I admit I haven't been quite active in maintaining it, while Dan (Cc'ed) has helped a lot. These days, the bug reports are accumulating and it's unlikely that I would spare time to commit to it regularly. Therefore we decided to start searching for new maintainers. If anyone is interested in taking on the responsibilities, please reach out to us. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Potential kTLS issue with TLS-PSK, GnuTLS + Rawhide - how to debug it?
Hello Simon, Thanks for looking into it! Simon Farnsworth writes: > On Friday, 25 November 2022 13:57:26 GMT Richard W.M. Jones wrote: >> Turns out this is fixed in upstream gnutls (not the version in >> Rawhide). The commit which fixes it is: >> >> commit 67843b3a8e28e4c74296caea2d1019065c87afb3 >> Author: Frantisek Krenzelok >> Date: Mon Sep 5 13:05:17 2022 +0200 >> >> KTLS: fallback to default >> >> If an error occurs during setting of keys either initial or key update >> then fallback to default mode of operation (disable ktls) and let the >> user know >> >> Signed-off-by: Frantisek Krenzelok >> >> lib/handshake.c| 7 ++- >> lib/tls13/key_update.c | 23 +++ >> 2 files changed, 25 insertions(+), 5 deletions(-) >> >> With full debugging you can see the message caused by this commit: >> >> nbdkit: null[1]: debug: gnutls: 4: HSK[0x7fc9e00010a0]: TLS 1.3 set read key >> with cipher suite: GNUTLS_CHACHA20_POLY1305_SHA256 > nbdkit: null[1]: debug: >> gnutls: 13: BUF[HSK]: Emptied buffer >> nbdkit: null[1]: debug: gnutls: 13: BUF[HSK]: Emptied buffer >> nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Start of epoch >> cleanup > nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Epoch #0 >> freed nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: Epoch #1 >> freed nbdkit: null[1]: debug: gnutls: 5: REC[0x7fc9e00010a0]: End of epoch >> cleanup nbdkit: null[1]: debug: gnutls: 1: disabling KTLS: failed to set >> keys >> Is this because kTLS doesn't support PSK? >> > kTLS doesn't do key management, so it doesn't know the difference between PSK > and X.509 (it gets the symmetric keys from userspace after the key exchange > is > done). > > However, looking at https://gitlab.com/gnutls/gnutls/-/blob/master/lib/system/ > ktls.c, GnuTLS only supports using kTLS with GNUTLS_CIPHER_AES_128_GCM and > GNUTLS_CIPHER_AES_256_GCM cipher suites, while your debugging output shows > that this connection is using GNUTLS_CHACHA20_POLY1305_SHA256. Yes, that is the case. With gnutls-cli: $ gnutls-cli -d1 -p 5556 localhost --pskusername psk_identity --pskkey "..." --priority NORMAL:-KX-ALL:+ECDHE-PSK |<1>| disabling KTLS: failed to set keys If you disable CHACHA20-POLY1305, it works without that message: $ gnutls-cli -d1 -p 5556 localhost --pskusername psk_identity --pskkey "..." --priority NORMAL:-CHACHA20-POLY1305:-KX-ALL:+ECDHE-PSK I've filed an issue so those ciphersuites are eventually supported: https://gitlab.com/gnutls/gnutls/-/issues/1434 Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
libunistring license change
Hello, The new libunistring release (1.0) has been announced with a change of license: from "LGPLv3+ or GPLv2" to "LGPLv3+ or GPLv2+". Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: guile22 -> gnutls -> lots of virt packages
Neal Gompa writes: > On Wed, Jul 7, 2021 at 9:06 AM Richard W.M. Jones wrote: >> >> >> I hope a reasonable summary is: >> >> * The core toolchain maintainers don't want guile to be a requirement. >> >> * The guile maintainers don't want guile to be a dependency of the >> core toolchain either. >> >> * With a small adjustment, Makefiles which use guile can be changed >> even if make itelf doesn't support it. > > Yep. > >> >> How about dropping the gnutls -> guile22 BR? >> > > Ask the GnuTLS maintainer. :) I am for dropping the BR, and perhaps it might also make sense to split out the gnutls guile binding from the upstream distribution. That said, the current gnutls build would bring in guile22 BR anyway, indirectly through the autogen/libopts BR (if we bootstrap). We want to replace the tool with something minimal, but haven't had time to move it forward. For the meantime, thanks Tomáš Korbař for stepping up and taking those packages; much appreciated. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Fedora 34 Change proposal: Modular GNOME Keyring services (Self-Contained Change)
Michael Catanzaro writes: > On Wed, Nov 4, 2020 at 1:12 pm, Ben Cotton wrote: >> Despite its original goal to be the central cryptographic service on >> desktop, the scope of GNOME Keyring has been gradually reduced over >> years. Notable examples are >> [https://bugzilla.gnome.org/show_bug.cgi?id=750514 gpg-agent removal] >> in 2015, [https://bugzilla.gnome.org/show_bug.cgi?id=791401 PKCS #11 >> module deprecation] > > Any plans to finish the PKCS#11 module deprecation work? Currently the > module cannot be removed as it implements public gcr API needed by > GNOME applications like geary. It's a bit off-topic to this Change proposal, but let me briefly answer: the original plan was to make the gcr API to use p11-kit-trust.so instead of gnome-keyring.so to store the trust assertion information. Later we realized that this approach requires significant effort, including the enablement of p11-kit-trust's per-user trust store by default, which is currently disabled at compile time. On the other hand, the use-case is quite limited (the only affected application I know of is geary). I suspect a more practical plan might be to let gcr maintain trust assertions in a local file by its own. I haven't had time to investigate this possibility further, but if anyone is willing to work on it, that would be certainly appreciated. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: nss vs. nspr - shipping overlapping set of built binary packages?
Hello Fabio, Fabio Valentini writes: > I just noticed (because of a failed build due to NVR mismatch in an > exact dependency) that *two* packages provide the "nspr" and > "nspr-devel" binary packages - nss and nspr. > > Is there a reason for both those packages to exist, if nspr and > nspr-devel are built from the "nss" source package, as well as from > the "nspr" source package? The .spec files do not seem to contain an > explanation. The idea is to merge nspr into nss in F34+. Although there were some hiccups, the latest compose shouldn't have the problem. I've just retired nspr package in rawhide. See the original rationale in the PR: https://src.fedoraproject.org/rpms/nss/pull-request/14 and some follow-up discussions on: https://bugzilla.redhat.com/show_bug.cgi?id=1892874 Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: Orphaned packages
Jan Synacek writes: > I orphaned my packages, feel free to take them: > [...] > https://src.fedoraproject.org/rpms/emacs Thank you for all your effort maintaining that package. As a regular Emacs user I tentatively took it, though I am not sure if I have enough time to spend on that package (I admit I have only only used the editor from the git for a decade :-). Let me now if anyone is more keen on maintaining it. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: NSS dbm support removal
Hello Igor, Sorry for the delay. Igor Raits writes: > On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote: >> https://fedoraproject.org/wiki/Changes/NSSDBMRemoval >> >> == Summary == >> Network Security Services (NSS) historically supports 2 different >> database backends, based on SQLite and dbm. Since Fedora 28, the >> SQLite backend has been used by default and the dbm backend has been >> deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format >> SQL]]). This Change is about removing the support for the dbm backend >> entirely. >> >> == Owner == >> * Name: [[User:ueno| Daiki Ueno]] >> * Email: du...@redhat.com >> >> == Detailed Description == >> Applications that use the NSS library often use a database for >> storage >> of keys, certificates and trust. NSS supports two different storage >> formats, one is based on SQLite and another one is based on dbm >> files. >> >> Today's default file format used by NSS, used when applications omit >> the type parameter, is the SQLite file format, and the older dbm >> format has been considered as deprecated since Fedora 28, because it >> has several drawbacks such as lack of support for parallel access to >> the storage. >> >> As the default change was made 2 years ago, and NSS provides a >> transparent migration mechanism from the dbm format to the SQLite >> format, the suggestion is to completely disable the dbm backend. >> >> == Benefit to Fedora == >> There are a few benefits: >> * By disabling the dbm database, the size of the library binary will >> be slightly smaller >> * The NSS developers will be able to focus on the new file format >> >> == Scope == >> * Proposal owners: >> A build time environment variable (NSS_DISABLE_DBM) needs to be set. >> >> * Other developers: N/A >> * Policies and guidelines: N/A (not a System Wide Change) >> * Trademark approval: N/A (not needed for this Change) >> >> == Upgrade/compatibility impact == >> The impact should be limited, as long as the users always update from >> the previous version. That would ensure the existing databases on the >> system are properly migrated. Therefore, we propose this as a Self >> Contained Change, rather than a System Wide Change. > > Does it mean that people who upgrade from F31 to F33 will work just > fine? That should, as long as the NSS databases had been created or accessed with the default method (that is SQLite) on F31. On the other hand, if a database is created explicitly as dbm, it needs to be converted before upgrading to F33. If it is too worrisome, I'm willing to provide a script that checks if the databases on the known locations are already converted. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: dropping NSS DBM format support in F33+
Ankur Sinha writes: >> NSS (the crypto library used by Firefox) historically supports 2 >> database formats: SQLite and DBM. The latter is considered legacy and >> we switched the default database format to SQLite in F28[1]. Since then >> I presume most of the applications have switched to the new format. >> Therefore we are planning to phase out the support of DBM, targetting >> F33+. >> >> Please let me know if there is any concern. > > I personally don't have any concerns, but perhaps a "self contained > change" would be good simply to ensure that everyone clearly aware of > this change? Thanks Ankur, that makes sense. I have proposed a change now: https://fedoraproject.org/wiki/Changes/NSSDBMRemoval Now that pesign package has been updated to use the new SQLite format, I'm going to re-disable dbm in the F-33 build soon. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
nettle 3.6 soname bump
Hello, I'm going to build nettle in rawhide, with the following soname bumps: - libnettle.so.7 -> libnettle.so.8 - libhogweed.so.5 -> libhogweed.so.6 I will enable bootstrapping in the package so it shouldn't break anything, but the dependent packages are suggested to be rebuilt against the newer libs. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: dropping NSS DBM format support in F33+
"James Cassell" writes: > On Sat, Apr 25, 2020, at 6:21 AM, Ondrej Mosnacek wrote: >> On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek wrote: >> > On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek >> > wrote: >> > > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno >> > > wrote: >> > > > Hello, >> > > > >> > > > I am not sure if this deserves a Fedora Change proposal, so I'd like to >> > > > hear any opinions first before proceeding with the process. >> > > > >> > > > NSS (the crypto library used by Firefox) historically supports 2 >> > > > database formats: SQLite and DBM. The latter is considered legacy and >> > > > we switched the default database format to SQLite in F28[1]. Since >> > > > then >> > > > I presume most of the applications have switched to the new format. >> > > > Therefore we are planning to phase out the support of DBM, targetting >> > > > F33+. >> > > > >> > > > Please let me know if there is any concern. >> > > >> > > It seems this broke the kernel build. I did some scratch build today >> > > to test some patches, but it failed with this: >> > > >> > > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir >> > > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s >> > > pesign: Could not initialize nss. >> > > NSS says "The certificate/key database is in an old, unsupported >> > > format." errno says "No such file or directory" >> > > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) >> > > RPM build errors: >> > > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) >> > > Child return code was: 1 >> > >> > Probably related: https://github.com/rhboot/pesign/issues/34 >> >> I filed a bug against pesign here: >> https://bugzilla.redhat.com/show_bug.cgi?id=1827902 >> > > Shouldn't > https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql have > prevented such bugs? I.e., why didn't the default change get picked up > automatically here? Usually, if the NSS database is created on-the-fly on the system, it should be automatically migrated. However, it doesn't help in this case because the pesign package embeds NSS database only in the old format (as you see with rpm -ql pesign). Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: dropping NSS DBM format support in F33+
Hello Ondrej, Ondrej Mosnacek writes: > On Fri, Apr 24, 2020 at 11:12 PM Ondrej Mosnacek wrote: >> On Fri, Apr 24, 2020 at 8:50 PM Ondrej Mosnacek wrote: >> > On Wed, Apr 22, 2020 at 10:12 AM Daiki Ueno wrote: >> > > Hello, >> > > >> > > I am not sure if this deserves a Fedora Change proposal, so I'd like to >> > > hear any opinions first before proceeding with the process. >> > > >> > > NSS (the crypto library used by Firefox) historically supports 2 >> > > database formats: SQLite and DBM. The latter is considered legacy and >> > > we switched the default database format to SQLite in F28[1]. Since then >> > > I presume most of the applications have switched to the new format. >> > > Therefore we are planning to phase out the support of DBM, targetting >> > > F33+. >> > > >> > > Please let me know if there is any concern. >> > >> > It seems this broke the kernel build. I did some scratch build today >> > to test some patches, but it failed with this: >> > >> > + /usr/bin/pesign -c 'Red Hat Test Certificate' --certdir >> > /etc/pki/pesign-rh-test -i arch/x86/boot/bzImage -o vmlinuz.signed -s >> > pesign: Could not initialize nss. >> > NSS says "The certificate/key database is in an old, unsupported >> > format." errno says "No such file or directory" >> > error: Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) >> > RPM build errors: >> > Bad exit status from /var/tmp/rpm-tmp.YKqoK0 (%build) >> > Child return code was: 1 >> >> Probably related: https://github.com/rhboot/pesign/issues/34 > > I filed a bug against pesign here: > https://bugzilla.redhat.com/show_bug.cgi?id=1827902 Good catch, and thank you for filing the bug. For the meantime I reverted the DBM disablement to unblock the kernel package build: https://src.fedoraproject.org/rpms/nss/c/fc0174ead16bac476cce55fb2918fbfd9b448023?branch=master Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
dropping NSS DBM format support in F33+
Hello, I am not sure if this deserves a Fedora Change proposal, so I'd like to hear any opinions first before proceeding with the process. NSS (the crypto library used by Firefox) historically supports 2 database formats: SQLite and DBM. The latter is considered legacy and we switched the default database format to SQLite in F28[1]. Since then I presume most of the applications have switched to the new format. Therefore we are planning to phase out the support of DBM, targetting F33+. Please let me know if there is any concern. Footnotes: [1] https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: nettle: heads up soname bump
Nikos Mavrogiannopoulos writes: > The latest nettle (3.5.1) update will break ABI on rawhide. The API > remains the same hence recompilation will be sufficient to address any > issues. Thanks to the suggestion from Miro, the new nettle and gnutls built against it are now in rawhide. I am using the approach bundling 2 versions of nettle shared libs in the single package, so I will drop the old ones once the rest of packages are built. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
Re: NSS package consolidation
Robert-André Mauchin writes:
>> https://copr.fedorainfracloud.org/coprs/ueno/nss-consolidate/
> Could we also remove the old cruft?
Thank you! I have updated the PR based on the suggestions.
> - Consider using a URL for Source0:
>
> Source0: https://hg.mozilla.org/projects/nss/archive/%
> {nss_tag}.tar.gz
That really makes sense, though I'd like to use the URLs from the
upstream release announcements, that are in the form:
https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/%{nss_tag}/src/%{name}-%{nss_archive_version}.tar.gz
Regards,
--
Daiki Ueno
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: NSS package consolidation
Tom Hughes writes: > If it's going to one source rpm producing the same three binary > rpms then you are indeed correct. Thank you for the suggestions. Then I will go ahead and retire nss-util and nss-softokn source packages once we are sure that the generated binary packages are sane enough. I have created a copr repository for testing: https://copr.fedorainfracloud.org/coprs/ueno/nss-consolidate/ firefox and java-openjdk maintainers: could you check if these builds don't break anything? Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
NSS package consolidation
Hello, We currently have 3 source packages for NSS (nss-util, nss-softokn, and nss), split from upstream release tarball. This splitting was introduced for FIPS certification purposes in RHEL, where only nss-softokn part is certified. In Fedora, however, this doesn't apply (as we don't certify), and had rather caused troubles, such as upgrade path issues, incomplete buildroot overrides, etc. Therefore we are considering merging those source packages back into a single package[1]. The same set of binary packages will still be produced and they should be compatible with the current ones. The question is, is there any documented procedure to do this kind of package merge safely? I guess at least the unnecessary packages (nss-util and nss-softokn) would need to be retired. Suggestions appreciated. Footnotes: [1] https://src.fedoraproject.org/rpms/nss/pull-request/3 Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: F29 System Wide Change: NSS load p11-kit modules by default
Zbigniew Jędrzejewski-Szmek writes: > The "how to test section" doesn't have too many details. > >> 1. install a PKCS#11 module, say softhsm >> 2. create an NSS database >> 3. list modules registered to the NSS database, and check that there is >> softhsm > > *Please* provide explicit instructions how to create the softhsm > module, how to do the other steps, and how to verify that it works. > > It would also be great if you could provide analogous instructions > for a _hardware_ module. > > The easier we make this to test for a people who don't have prior > knowledge, the higher the chances of success. Thank you for the suggestion. I have expanded the section a bit. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/TY5OU6N6T6IUOVXTAJO6EISWI4QOHSRA/
F28 FTBFS bugs?
Hello, Yesterday I received a couple of new FTBFS bugs, apparently triggered by the F28 mass rebuild: https://bugzilla.redhat.com/show_bug.cgi?id=1556047 https://bugzilla.redhat.com/show_bug.cgi?id=1556162 As the mentioned koji builds are back in February, I am wondering if those are something I should still worry about. I suspect the former was failing due to a Vala regression recently fixed[1], and the latter could be a false-positive as it points to the build against f27-candidate. Footnotes: [1] https://bugzilla.gnome.org/show_bug.cgi?id=793299 Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)
Adam Williamson <adamw...@fedoraproject.org> writes: >> > On Fri, 2017-10-13 at 10:38 -0700, Josh Stone wrote: >> > > On 10/12/2017 05:34 PM, Adam Williamson wrote: >> > > > In this case there's an even worse consequence; if you do attempt to >> > > > update to nss 3.33.0 without nspr 4.17.0 dnf will 'skip' *most* of the >> > > > nss packages (as it notices that they are missing dependencies), but it >> > > > *will* install nss-softokn-freebl . With this mix of packages (most of >> > > > nss at 3.32.0, but nss-softokn-freebl at 3.33.0), nss and anything that >> > > > depends on it just fails to work at all - e.g. curl and dnf...so that's >> > > > an extremely bad outcome. >> > > >> > > Then isn't this a packaging bug? They currently use ">=" requirements, >> > > but if a greater version doesn't work, shouldn't they be "="? >> > >> > Well, there's *additionally* probably a packaging bug, yeah: nss- >> > softokn-freebl should be more strictly tied to the other packages. >> >> I still don't figure out why this causes a problem. nss-softokn-freebl >> is parallel installable with older nss* packages and that could run into >> a problem if nss-softokn-freebl used a new symbol from a newer nspr. >> However, as far as I know nspr 4.17 doesn't add any new symbol so it's >> shouldn't be a problem at least in this case. > > I definitely observed the half-upgraded case causing problems, but > didn't really prove that it was the nss-softokn-freebl causing the > problem, I guess. I suppose it could equally well just have been a > mismatch between NSS 3.32.0 and NSPR 4.17.0? I realized that this is an ABI issue between nss-softokn-freebl and nss-util, not nspr. The upstream bug[1] introduced the aligned malloc functions which are only available in the newer nss-util package in Fedora[2] (not that nss-softokn-freebl dlopen's nspr and nss-util). I guess the fix would be to add either a versioned dependency on nss-util or stubs for those functions in nss-softokn-freebl. As this issue makes rpm non-functional, I would suggest people to ensure that nss-util is updated to 3.33 before updating nss-softokn-freebl, until it is fixed. Footnotes: [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1390129 [2] https://taskotron.fedoraproject.org/artifacts/all/f2a2d24a-a82f-11e7-b9f4-525400817a8f/task_output/nss-util-3.33.0-1.0.fc26.log Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Interdependent packages *must* go in the same update - a reminder (ref. nss and nspr)
Adam Williamson <adamw...@fedoraproject.org> writes: > There are currently separate updates for nss 3.33.0 and nspr 4.17.0 in > both Fedora 26 and 27. However, nss 3.33.0 requires nspr 4.17.0. > > As a reminder, this is a violation of the Updates Policy: > > https://fedoraproject.org/wiki/Updates_Policy#Updating_inter-dependent_packages > > "When one updated package requires another (or more than one other), > the packages should be submitted together as a single update." > > The problem with doing things this way is that, if the nss update > happened to be pushed stable before the nspr update (which could easily > happen due to human error, network issues etc. even if the maintainer > *intends* to push them together!), the dependencies in the stable > repository will be broken; nss will not be installable. Thank you for the reminder; there was indeed a fuss in updating nspr/nss this time. I have submitted the nss updates for F27/F26 stable, after nspr 4.17 got pushed to stable. > On Fri, 2017-10-13 at 10:38 -0700, Josh Stone wrote: >> On 10/12/2017 05:34 PM, Adam Williamson wrote: >> > In this case there's an even worse consequence; if you do attempt to >> > update to nss 3.33.0 without nspr 4.17.0 dnf will 'skip' *most* of the >> > nss packages (as it notices that they are missing dependencies), but it >> > *will* install nss-softokn-freebl . With this mix of packages (most of >> > nss at 3.32.0, but nss-softokn-freebl at 3.33.0), nss and anything that >> > depends on it just fails to work at all - e.g. curl and dnf...so that's >> > an extremely bad outcome. >> >> Then isn't this a packaging bug? They currently use ">=" requirements, >> but if a greater version doesn't work, shouldn't they be "="? > > Well, there's *additionally* probably a packaging bug, yeah: nss- > softokn-freebl should be more strictly tied to the other packages. I still don't figure out why this causes a problem. nss-softokn-freebl is parallel installable with older nss* packages and that could run into a problem if nss-softokn-freebl used a new symbol from a newer nspr. However, as far as I know nspr 4.17 doesn't add any new symbol so it's shouldn't be a problem at least in this case. Regards, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
mock error on armv7hl koji
Hello, When rebuilding 'nss' package, I got the following failure on the armv7hl machine in koji: Task 17179597 on arm04-builder19.arm.fedoraproject.org Task Type: build (noarch) Link: https://koji.fedoraproject.org/koji/taskinfo?taskID=17179597 file removal failed (code 9) for /var/tmp/koji/tasks/9610/17179610 I initially thought that it was an intermittent failure, but after re-submitting the task twice, I still get: error building package (arch armv7hl), mock was killed by signal 9; see root.log for more information I suspect this might be specific to the nss package. Does anyone have any idea how to fix (or investigate) this? The relevant task is: https://koji.fedoraproject.org/koji/taskinfo?taskID=17230493 Thank you, -- Daiki Ueno ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: unintentional soname bump of libgettextpo
Rex Dieter <rdie...@math.unl.edu> writes:
> I'd suggest you track library sonames instead of using globs as is current:
> %files libs
> %{_libdir}/libasprintf.so.*
> %{_libdir}/libgettextpo.so.*
> ...
>
> using something like:
> %files libs
> %{_libdir}/libasprintf.so.0*
> %{_libdir}/libgettextpo.so.0*
> ...
> instead.
>
> So this won't come as a surprise when/if it happens again.
Thanks for the suggestion. I have made that change.
Regards,
--
Daiki Ueno
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: unintentional soname bump of libgettextpo
Daiki Ueno <u...@fedoraproject.org> writes: > I am very sorry that the recent build of gettext-0.19.8-1 package, which > has already been pushed to F24, had an unintentional soname bump of > libgettextpo that affected the following packages: I was able to unpush the update. Sorry for the noise (though it is still the case in rawhide). Regards, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
unintentional soname bump of libgettextpo
Hello, I am very sorry that the recent build of gettext-0.19.8-1 package, which has already been pushed to F24, had an unintentional soname bump of libgettextpo that affected the following packages: fcitx gtranslator kdesdk-thumbnailers poxml May I ask to rebuild those? Thanks, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
libmsgpack.so.* removal
Hello, Fedora Branched Report <rawh...@fedoraproject.org> writes: > Broken deps for x86_64 > -- > [groonga] > groonga-5.1.2-2.fc24.x86_64 requires libmsgpack.so.4()(64bit) > groonga-libs-5.1.2-2.fc24.i686 requires libmsgpack.so.4 > groonga-libs-5.1.2-2.fc24.x86_64 requires libmsgpack.so.4()(64bit) > groonga-plugin-suggest-5.1.2-2.fc24.x86_64 requires > libmsgpack.so.4()(64bit) > [tmate] > tmate-2.2.1-1.fc24.x86_64 requires libmsgpack.so.4()(64bit) Apologies for having overlooked and not announcing the upstream change of eliminating the C++ library (it's now header only, rebuilding should fix the broken deps): https://github.com/msgpack/msgpack-c/pull/402 Thanks, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Specs using %define
Jason L Tibbitts III <ti...@math.uh.edu> writes: > baekmuk-bdf-fonts (ueno) > baekmuk-ttf-fonts (ueno) > ibus-gucharmap (ueno) > un-core-fonts (ueno) > un-extra-fonts (ueno) Done in rawhide. Regards, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
msgpack license change: ASL 2.0 → Boost 1.0
Hello, The license of the msgpack package has changed from ASL 2.0 to Boost 1.0 in versions 1.3.0 and later. Regards, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: New gettext in Rawhide causing builda failures?
Richard Hughes hughsi...@gmail.com writes: po/gscan2pdf-ab.po:7: header field 'Last-Translator' still has the initial default value po/gscan2pdf-ab.po:7: warning: header field 'Language' missing in header msgfmt: found 2 fatal errors This builds fine in F20. I think a newer gettext may be being more strict about Last-Translator and Language For the record, this change has been introduced as a fix of: https://savannah.gnu.org/bugs/index.php?40262 any ideas or best practices on how to fix it? Patching 33 .po files in a spec file seems like the Wrong Way (tm). However, the non-warning errors have been there for a long time. Isn't it time to fix them? If this is really too strict, we can revert this in the next minor release and advise users until the next major release. (But, oh, msgfmt seems to mistreat the warning here. Sorry about that and will fix it ASAP.) Regards, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New gettext in Rawhide causing builda failures?
Richard Hughes hughsi...@gmail.com writes: I think quite a lot of software will fail to rebuild (mostly stuff using rosetta) with this change in the pending F21 mass rebuild. (But, oh, msgfmt seems to mistreat the warning here. Sorry about that and will fix it ASAP.) I think a warning is fine, an error is somewhat draconian IMHO :) I see. So, just applied a patch to turn the missing-header errors into warnings (should be available as 0.19-2). Thanks for catching this quickly. Regards, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Proposed F19 Feature: libkkc - a new Japanese Kana Kanji input library
Daiki Ueno u...@fedoraproject.org writes: Thanks for testing. Well, when I drafted the feature page, I didn't plan to change the default without hearing the opinions from actual users of sentence-based Japanese input. But it might be good to start with a wider scope and fallback to ibus-anthy if needed. So I'll update the wiki to cover the default change. I did some performance measure of libkkc and Anthy and libkkc was significantly better[1]. So I updated the feature page to suggest the default change. Regards, Footnotes: [1] http://blog.du-a.org/?p=1004 -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: libkkc - a new Japanese Kana Kanji input library
Mamoru TASAKA mtas...@fedoraproject.org writes: I tried ibus-kkc and it seems to be working to a certain degree. So does this Feature mean that the default input method (for Japanese) will be changed from ibus-anthy to ibus-kkc? If so, I think it is better that wiki page explicitly suggest so. Thanks for testing. Well, when I drafted the feature page, I didn't plan to change the default without hearing the opinions from actual users of sentence-based Japanese input. But it might be good to start with a wider scope and fallback to ibus-anthy if needed. So I'll update the wiki to cover the default change. Regards, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18
Bill Nottingham nott...@redhat.com writes: Package man-pages-ko (orphan) I have taken ownership of this one. Regards, -- Daiki Ueno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Korean default font change (un-core-*-fonts - nanum-*-fonts)
Hi all, Forwarding this to get more attention from Korean users and developers. If no one objects, I'll start working on the transtion so that it can be tested with F17 Alpha. Regards, Start of forwarded message Message-ID: m37h0s8207.fsf-u...@fedoraproject.org From: Daiki Ueno u...@fedoraproject.org To: fo...@lists.fedoraproject.org Subject: Korean default font change (un-core-*-fonts - nanum-*-fonts) Date: Mon, 16 Jan 2012 17:01:39 +0900 Hi, I heard that Ubuntu is going to change the default Korean font from un-core to nanum within their P release cycle: http://permalink.gmane.org/gmane.linux.ubuntu.devel.discuss/13090 https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/836430 Since I maintain both font packages in Fedora, I would like to ask Korean users whether it is a good thing to do as well in F17. AFAIK, the only concern discussed there was that they dropped nanum-coding font (a monospace variant of nanum-gothic, distributed as a separate upstream tarball) from the default install, due to size limitation. I guess we could also simply mark it as optional in comps (like un-extra-*-fonts). Regards, -- Daiki Ueno ___ fonts mailing list fo...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fonts http://fonts.fedoraproject.org/ End of forwarded message -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
