Re: Packaging guidelines - validation of AppStream metadata files

[Marcus Müller]

Seconding that, the did, at least in the past, and they do interpret the severity of 
deviations differently than the written standard.


On 24.10.23 14:26, Michael Catanzaro wrote:

On Tue, Oct 24 2023 at 08:06:12 AM -0400, Neal Gompa  wrote:

The two tools don't have incompatible ideas of valid metadata, we
intentionally don't do strict validation.


Well for one example incompatibility, you can review that issue:

https://github.com/ximion/appstream/issues/476

Michael

___
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

___
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

appstream does not allow for being an email address, how to validate? (was: Packaging guidelines - validation of AppStream metadata files)

[Marcus Müller]

Hi list,

just a heads up: because we're talking about how to validate appstream metadata: When 
validating metadata, one of the "default" warnings you get is:


> In the past, mailto: URL schemas to link to email addresses were also supported for 
this URL type. It is recommended to not use them in new metadata, as they provide poor 
usability on most systems when users click on such a link and no local email client is 
configured.


I just got word from upstream that the official standing is that a point of contact for a 
software package can not validly be an email address:


https://github.com/ximion/appstream/issues/331

I believe they do that in good faith ("most probably don't even have an email client set 
up"), but this basically means I can not write *correct* and *valid* metadata at the same 
time:


Our whole social maintenance infrastructure (and, debian all the same) is built on the 
fact that packagers have email addresses. It's the *one* common medium.
I've hence asked whether that ruling could be softened; after all, a user interface 
problem ("can't open mail client upon a click") is not the same as a metadata issue. 
Sadly, appstream maintenance and I seem to disagree here.


Either way, as far as I understand we aim for zero-warning, yet correct metadata. I'm 
involved in upstream packaging of software myself, so I wonder how I can make my upstream 
metainfo ideally 100% applicable for fedora, yet correct. Email *is* the way to reach the 
software maintainers.


Best,
Marcus

___
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: time is running: security issue BZ#2241470

[Marcus Müller]

Hi Marius,,

I'd also point out that if you want to inform the security team about something, you 
should inform directly – and it seems you've done that, by properly labeling that issue 
(which I can't read at all) as sensitive. As the others pointed out, there's nothing that 
can be done publicly before the embargo is lifted, which should coincide exactly with your 
deadline; anything else would amount to publishing a bugfix that you've now publicly 
announced is a fix for a critical security vulnerability!


If, for some reason, the issue you can read and we can't is marked confidential, but you 
see the security team has not taken appropriate attention to it, or don't understand the 
process they're going through, they do have an email address: secalert at [roterhut auf 
Englisch] dot com. Note that it's quite usual that reporters and security teams come to 
different assessments regarding appropriate measures, which is mostly due to different 
scopes of what they need to care about. As you've done here, being nice gets you far :)


Best,
Marcus

On 30.09.23 23:58, Justin Forbes wrote:

On Sat, Sep 30, 2023 at 10:55 AM Kevin Fenzi  wrote:

On Sat, Sep 30, 2023 at 11:13:32AM +0200, Marius Schwarz wrote:

Hi,

this is emerg ping for the security team, to take a look at this bz :

https://bugzilla.redhat.com/show_bug.cgi?id=2241470

If this is an embargoed bug (I can't see it, so no idea if it is, but it
seems likely), please don't discuss it on a public mailing list.

Fedora has no means to secretly build anything, so it may be that the
maintainers of whatever this is are waiting for the embargo to lift to
push fedora updates.

Agreed. I also don't have access to the bug, but no matter the issue,
even if I have the patch months before the lift of embargo, and do
test builds locally, I can not commit a fix to Fedora dist-git and
start a build until an embargo is lifted.  We still typically get such
issues fixed and out to users within a few hours if critical.  That is
part of the open nature of Fedora, we literally do not have a back
channel.  That said, calling something out which is embargoed is
absolutely irresponsible and is not the way to ensure that people
continue to get read in on such issues.  If the bug exists, the
security team is likely well aware, and we do have processes in place.
A public mailing list is no place to discuss any non public bugs.

Justin


If you have access to the bug, thats the place to comment further.

kevin
___
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

___
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

___
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: Packaging guidelines - validation of AppStream metadata files

[Marcus Müller]

I must say that I found appstreamcli to be to unstable in CI of projects that I used to 
maintain, and file format documentation and validator source code reality diverge, and 
behaviour is understandably changed between appstreamcli revisions. We had to disable and 
later re-enable the metainfo tests in GNU Radio for various CI runners, because slightly 
different versions of the same validator couldn't agree amongst each other and with the 
file format documentation what is legal and what not.


There used to be a formal definition of what is legal in that file format (an XSD file), 
but it got, again, understandably, removed by the appstream maintainer, because they 
couldn't stem the workload of writing both a C parser/validator for this XML format as 
well as keep that XSD up to date [1].


So, now: we're left in a situation where we have a human-oriented documentation that we 
can't trust, a choice of two validation tools that are both buggy in our experience, and 
although this is an XML format, no format definition.


If Fedora depends on that validation, we might **really** want to help maintainers get the 
formal specification of the format back into shape. That would also make checking the 
documents tool-independent, and allow for validation in rpmbuild/lint steps without the 
wealth of dependencies that the specific tools bring.


My 2ct, anyway.

Cheers,
Marcus

[1] https://github.com/ximion/appstream/issues/279

On 24.09.23 00:04, Michael Catanzaro wrote:
On Sat, Sep 23 2023 at 10:26:48 PM +0200, Alexander Ploumistos 
 wrote:

Could someone involved
with AppStream please provide some information? Shouldn't our
documentation be changed to reflect these changes? Does the FPC need
to decide on this?


From upstream perspective: appstream-util is indeed obsolete. Upstream software should 
stop using it and switch to appstreamcli instead.


But as you've noticed, it seems Fedora isn't ready for that yet

___
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

___
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: Adding Passim as a Fedora 40 feature?

[Marcus Müller]

Just realized:

- using avahi for local peer discovery, how does this compare to good ole bittorrent with 
Protocol/Message Stream Encryption turned on, and DHT instead of a tracker?


- I guess the "self-signed certificate" discussion stems from the fact that TLS assumes 
you have certificates – which really isn't the case in these peer-to-peer scenarios. All 
you need is a *session key*, which, painting with a broom-sized brush here, can easily be 
agreed on using e.g. Diffie-Hellman/25519 (as implemented in NaCl/libsodium).


Cheers,
Marcus

On 28.08.23 21:55, Richard Hughes wrote:

On Mon, 28 Aug 2023 at 16:27, Leon Fauster via devel
 wrote:

whats the benefit of this "self-signed TLS certificate" (as it does
not provide any "security")? Is this stub for something later ... ?

It's a good question. It provides encryption (so client A can provide
the file to client B without client C being aware what's being sent)
-- and also placates various corporate security teams that say that
HTTP without TLS isn't good enough -- even if it's got two other
layers of protection.

Richard
___
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

___
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: Adding Passim as a Fedora 40 feature?

[Marcus Müller]

That sounds very good, and having a libs package desirable anyway should more 
consumers pop up

On 25.08.23 20:43, Richard Hughes wrote:

On Fri, 25 Aug 2023 at 19:34, Richard Hughes  wrote:

Yes, that's what I have right now. I do need to split out a
passim-libs so that you can remove the daemon and just leave the tiny
client library.

Something like this perhaps?

diff --git a/passim.spec b/passim.spec
index bc51e57..3ad7ccc 100644
--- a/passim.spec
+++ b/passim.spec
@@ -21,10 +21,18 @@ BuildRequires: systemd-rpm-macros
  BuildRequires: systemd >= %{systemd_version}

  Requires: glib2%{?_isa} >= %{glib2_version}
+Requires: %{name}-libs%{?_isa} = %{version}-%{release}

  %description
  Passim is a daemon that allows software to share files on your local network.

+%package libs
+Summary: Local caching server library
+
+%description libs
+libpassim is a library that allows software to share files on your
local network
+using the passimd daemon.
+
  %package devel
  Summary: Development package for %{name}
  Requires: %{name}%{?_isa} = %{version}-%{release}
@@ -69,12 +77,15 @@ appstream-util validate-relax --nonet
%{buildroot}%{_metainfodir}/*.metainfo.xml
  %{_datadir}/dbus-1/system-services/org.freedesktop.Passim.service
  %{_datadir}/icons/hicolor/scalable/apps/org.freedesktop.Passim.png
  %{_datadir}/metainfo/org.freedesktop.Passim.metainfo.xml
-%{_libdir}/libpassim.so.1*
  %{_libdir}/girepository-1.0/Passim-1.0.typelib
  %{_libexecdir}/passimd
  %{_mandir}/man1/passim.1*
  %{_unitdir}/passim.service

+%files libs
+%license LICENSE
+%{_libdir}/libpassim.so.1*
+
  %files devel
  %{_datadir}/gir-1.0/Passim-1.0.gir
  %dir %{_includedir}/passim-1

...then fwupd would hard depend on passim-libs (automatically, via the
shared library use) and would "recommend" passim (the daemon) -- so
the latter could be easily removed.

Richard.

___
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: Adding Passim as a Fedora 40 feature?

[Marcus Müller]

Hi Richard,

On 25.08.23 19:24, Richard Hughes wrote:

So that's the thing; if it's default disabled then I can say with
certainty that almost nobody will use it and we won't see any
reduction in network traffic at all.


I fully agree with that assessment. "Here's a knob you turn that has the potential to make 
your firmware update 2s faster and is generally good for the ecosystem, but you will have 
set it on every machine you set up" will not lead to significant deployment.


Question: I presume you only want to share the metadata, and never downloaded fw images, 
right? If that's the case, it'd alleviate a lot of the privacy concerns I'd have with my 
laptop sharing with a campus network all of the devices for which I've lately downloaded 
firmware.


Can I suggest we make this at most a "Recommends:" dependence for fwupd in any case, so 
that one might uninstall passim without disabling fwupd?


I'm wondering a bit whether you might be reinventing something that the cloud ops folks 
already have as "service recovery compatible cache" or something? Feels like if I pull up 
a lot of docker containers which in turn start fetching data, I'd want to have a happy 
fallover mechanism in case some main repository for some artifacts goes down.


Or, maybe, this is a common problem?
I, for one, find myself working with mock and on containers for my small CI network, and I 
get to download a lot of package metadata a lot of times, same for packages, and I don't 
want to modify the base layers to use my local repo mirror (not am I inclined to set up 
such). I'd actually love if I knew of a way my fedora containers could automagically find 
local package and metadata sources. Knowing that "change dnf to pull data from 
mDNS-announced sources *by default*" is a big change, flying the fwupd balloon first seems 
very attractive to me.


Best,
Marcus
___
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: Podman issue might be breaking toolbx anytime now

[Marcus Müller]

Hi Sumantro and Debarshi, hi fellow podman users,

trying to wade through all this: I don't think there's anything podman can do to solve 
this now.


Background:

- the container format metadata has a field for|RLIMIT_NPROC (i.e., what you set via 
`ulimit -u`)|


|- this field is optional, but important to some use cases, because it can be used to set 
nonstandard limits|


|- podman uses that field at container start time to set the ulimits, which usually always 
works on the same machine, as ulimits rarely decrease

|

|  - this addition of the field by default was recognized as a design mistake and removed, 
so in the future these problems won't happen, unless a user explicitly adds a limit to the 
metadata.

|

|- pre podman 4.6, that field was just generally added to the container metadata at 
container creation, with the values present at creation time|


|- somewhere on the journey, the default ulimits on F38 got decreased
  ** To little surprise, that means that software relying on RLIMIT_NPROC being as it 
used to be breaks **|


|So, to me this very clearly is a fedora regression, where we (probably for good reason) 
reduced that specific ulimit, but forgot to then add a script to go through the toolbox 
containers created on the affected machines to adjust or remove that tag.|


|It's not podman's job to fix toolbox or Fedora's ulimits handling, so I don't think that 
issue on the podman bugtracker has all too much chances of solving the situation.|


|Hotfixes are also easy: just roll out a toolbox update which upon toolbox start, for each 
toolbox container|removes the annotation. The nu-cular way here is [1], i.e. exporting of 
the container filesystem to an archive and recreation of an image from that, and then 
recreation of the toolbox container from that. I'm almost certain there's IO-cheaper 
alternatives (not like one can't fiddle with the container config.json if one knows who 
owns the container).


Cheers,
Marcus

[1] https://github.com/containers/podman/issues/19634#issuecomment-1680734973

On 16.08.23 16:19, Sumantro Mukherjee wrote:


Hey Folks!

This is to flag that there is an issue in Podman [0] which will break
Toolbx's basic
functionality in F37 and F38. Toolbx is currently release blocking and
is a part of
FCOS and Workstation ISO.

We are tracking the issue in [0] and request folks to test updates
when fixes are available.


[0] https://github.com/containers/podman/issues/19634

___
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: Heads-up / for discussion: dnf not working with 1G of RAM or less

[Marcus Müller]

Because it's typically not an option in these kinds of VMs – you'd need 
to create a swapfile, enable it, before you could launch the first DNF 
command. Ideally, disable it after, as chances are a certain bookseller 
is billing you per IOPS.


It's completely out of the questions for (e.g. cgroups) limited 
containers, which can't even tell the kernel to enable swap.


Best,
Marcus

On 8/29/22 12:12, Roberto Ragusa wrote:

On 8/29/22 09:19, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, Aug 22, 2022 at 05:44:26PM -0700, Adam Williamson wrote:



it's quite an old bug, but up until recently, the summary was
apparently accurate - dnf would run out of memory with 512M of RAM, but
was OK with 1G. However, as of quite recently, on F36 at least (not
sure if anyone's explicitly tested F37), dnf operations are commonly
failing on VMs/containers with 1G of RAM due to running out of RAM and
getting OOM-killed.


The discussion in the bug indicates that this memory growth is 
related to

loading of the full filepath dataset. We have been discussing splitting
out the non-primary-filepath-data (i.e. paths that are not /etc, 
/usr/bin,

/usr/sbin), out into a separate lazilly-loaded file.
If it is currently loading stuff that is not really used in the 
computation,

this is a perfect case where swap could help (things would be written
to swap and then forgot on deallocation).
Unfortunately, swap is for some reason considered out-of-fashion, even in
these memory constrained set ups.

Regards.


___
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: CC0 reclassified as "not allowed" for code (reposted from legal list)

[Marcus Müller]

Wait, getting a legal opinion on code is an option? Even if the code is 
GPLv3 but fedora removes some part of it out of fear it *might* infringe 
patent.


Cheers,
Marcus

On 8/6/22 19:49, Gary Buhrmaster wrote:



On Sat, Aug 6, 2022, 10:35 AM Richard Fontana  wrote:

[re FDK-AAC, which has a no-patent-licenses clause]

> That is correct. The clause is considered a no-op and the license
> isn't approved for use outside of this case.

I think it is correct to bring FDK-AAC up in this discussion. 



I would agree that has some use as an example.

For consistency with treatment of CC0, I believe we have to move
it to 'not-allowed' formally, but we can devise some sort of
exception that will keep the specific current use case in place.


So, as I understand it, in the case of
fdk-aac-free, the packager
(with assistance of legal?) reviewed
the code and stripped the patented codecs.

Using that example, packagers wanting to
continue to use CC0 would need to perform
such a review, strip as needed, and need
legal review?

Is that what you are suggesting?


___
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

___
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: F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Marcus Müller]

Uff, that thread has been a … sobering read, on a technical and human level.

Thank you for linking me to it!

Best regards,
Marcus

On 26.07.22 09:58, Peter Oliver wrote:

On Sat, 23 Jul 2022, Marcus Müller wrote:


On 23.07.22 01:37, Peter Oliver wrote:


 The emacs developers discourage use of the GTK-only build on X11. Perhaps
 we will want a wrapper to select the most suitable binary.


Oh, I wasn't aware of that, is there somewhere I can read up on that?


See https://lists.gnu.org/archive/html/emacs-devel/2022-04/msg00761.html


___
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

___
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: Minizip renaming Fedora Change

[Marcus Müller]

ah, true, different sonames solves this :)

On 28.07.22 10:52, Daniel P. Berrangé wrote:

On Thu, Jul 28, 2022 at 10:44:14AM +0200, Marcus Müller wrote:

The latter change seems unwise. Packages which now depend on minizip (to be
minizip-ng) will continue to do depend on whatever Provides(minizip); if you
rename the zlib subpackage to minizip, they will depend on the wrong thing.

Both these packages merely provide an ELF library. As such anything that
depends on them should have automatically gained a Requires against the
SONAME of the contained library - 'libminizip.so.3.0()(64bit)' (for minizip)
vs 'libminizip.so.1()(64bit)' (for minizip-compat).

As such it shouldn't matter what the actual package name is, any dep will
continue to resolve to the correct renamed package at install time.

The only significant impact of the rename should be on BuildRequires
which could end up pulling in the wrong version, but presumably if
the API is different that ought to resolve in a koji build failure
which is easy enough to identify and fix the BuildRequires.

With regards,
Daniel

___
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: Minizip renaming Fedora Change

[Marcus Müller]

The latter change seems unwise. Packages which now depend on minizip (to be minizip-ng) 
will continue to do depend on whatever Provides(minizip); if you rename the zlib 
subpackage to minizip, they will depend on the wrong thing.


Cheers,
Marcus

On 28.07.22 10:31, Lukas Javorsky wrote:

Hi fellow contributors,

Upstream has reported a request for minizip naming change from "minizip" to "minizip-ng" 
(minizip-ng is the official name of the upstream package right now).


As Fedora should match the upstream naming, I believe this change is necessary.

Another naming change is required for the "minizip-compat" package which is the 
subpackage of the "zlib" package. Upstream requests that we should rename 
"minizip-compat" to "minizip".


I agree with renaming this package as well, however, this could lead to multiple 
confusions maybe even conflicts for the users. The problem with renaming this package 
right after renaming the "minizip-ng" could be that the users may be confused about 
which package is the right "minizip" for them.


I believe we could rename the "minizip-compat" to the "minizip" after some larger time 
period so every package that requires "minizip" changes the requirements to "minizip-ng" 
and there is no confusion anymore.


The first step I want to do is to create a Fedora Change, which contains this whole 
process and is well communicated within the community.


This email serves as a heads-up and also opens a possibility for any tips that you can 
give me with this change. This is my first time doing a change like this so it may have 
some bumps along the way, but I'm willing to learn and improve, so feel free to give me 
any advice you think could benefit me with this process.


Thank you for understanding and sorry for quite a long email.
Lukas
--
S pozdravom/ Best regards

Lukáš Javorský

Software Engineer, Core service - Databases

Red Hat 

Purkyňova 115 (TPB-C)

612 00 Brno - Královo Pole

ljavo...@redhat.com





___
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

___
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: F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Marcus Müller]

Oh, I wasn't aware of that, is there somewhere I can read up on that?

On 23.07.22 01:37, Peter Oliver wrote:

On Mon, 18 Jul 2022, Marcus Müller wrote:

Since the pgtk toolkit supports both X and wayland under the hood, I'd very much 
propose that we do not only package an emacs-pgtk binary, but also, that it becomes 
what you get by default (i.e. when you install and run `emacs`).


The emacs developers discourage use of the GTK-only build on X11. Perhaps we will want a 
wrapper to select the most suitable binary.



___
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

___
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

Confusion on pre-implemented Emacs 28 proposal (was: Re: F37 proposal: Emacs 28 (Self-Contained Change proposal))

[Marcus Müller]

He Kevin,

oh, true, after all,
dnf info --releasever=36 emacs
agrees with you. Now, I'm kind of confused about the point of the change 
proposal?

emacs -nw -q --batch --eval '(message system-configuration-options)' 2>&1 | grep native 
compilaion


also tells me that the announced native compilation is also enabled, so maybe something 
slipped through a little early?


Cheers,
Marcus

On 20.07.22 21:36, Kevin P. Fleming wrote:

On 7/20/22 14:57, Marcus Müller wrote:

Oh! That comes as a surprise. Let me try a rebuild!

:( I was really looking forward to emacs-pgtk.

Forgive my relative newbie-ness here, but this proposal is to upgrade Emacs to version 
28 in F37. That seems fine.


This week my F36 system got upgraded to Emacs version 28, so it's already in F36. How is 
that possible?



___
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: F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Marcus Müller]

Oh! That comes as a surprise. Let me try a rebuild!

:( I was really looking forward to emacs-pgtk.

Best regards,
Marcus

On 19.07.22 11:53, Jens-Ulrik Petersen wrote:

On Tue, Jul 19, 2022 at 5:14 AM Marcus Müller  wrote:

Since the pgtk toolkit supports both X and wayland under the hood, I'd very 
much
propose
that we do not only package an emacs-pgtk binary, but also, that it becomes 
what you
get
by default (i.e. when you install and run `emacs`).


Good catch, but it looks to me like pgtk was deferred to Emacs 29!
Seems it is not actually part of 28.

Jens

___
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

___
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: F37 proposal: Emacs 28 (Self-Contained Change proposal)

[Marcus Müller]

Dear Bhavin,

A big "yay!" for packaging 28.1; I've been running my own emacs.spec modifications to play 
around with this, for one reason, and one reason alone:


PGTK support. Without it, emacs is virtually unusable on Wayland on hidpi screens with the 
compositors I've used, as xwayland simply scales pixel-images.


Since the pgtk toolkit supports both X and wayland under the hood, I'd very much propose 
that we do not only package an emacs-pgtk binary, but also, that it becomes what you get 
by default (i.e. when you install and run `emacs`).


Felt too big a change to propose for me, a GNU emacs newbie, but I was surprised to see a 
change proposal for a normal software version bump of emacs (it's not like say GNU Radio 
makes a change proposal every time they bump version), but then not include that, which 
feels a bit like a missed chance to round-off the wayland experience of Fedora!


Best regards,
Marcus

On 18.07.22 19:29, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/Emacs_28

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==

Update GNU Emacs to 28.1 release. This release includes a wide variety
of new features, including native compilation of Lisp files.

== Owner ==

* Name: [[User:Bhavin192| Bhavin Gandhi]]
* Email: bhavin...@fedoraproject.org


== Detailed Description ==

The Emacs package will be updated to 28.1 release of GNU Emacs. This
will have native compilation feature enabled, and will package
additional natively compiled Lisp files.


== Benefit to Fedora ==

This major version of Emacs has bugfixes and new features which also
improve the overall speed of Emacs.

== Scope ==

* Proposal owners: Upgrade the Emacs package to 28.1
* Other developers: N/A
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A

== Upgrade/compatibility impact ==

Users might see some warnings while their installed Emacs packages get
natively compiled after first launch post the upgrade. These warnings
won't break any functionality, though the users are encouraged to
update their Emacs packages.

== How To Test ==

# Run dnf update emacs
# Open Emacs and check if inbuilt functionalities and packages work as indented.

== User Experience ==

https://www.gnu.org/software/emacs/#Releases

* Lisp files are natively compiled, this results in speed improvements
for most of the functionalities
* Much improved display of Emoji and Emoji sequences
* New system for documenting groups of functions

== Dependencies ==
N/A

== Contingency Plan ==

* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change), No

== Documentation ==
* https://www.gnu.org/software/emacs/news/NEWS.28.1
* https://src.fedoraproject.org/rpms/emacs/pull-request/12

== Release Notes ==
The upstream release notes are available at
https://www.gnu.org/software/emacs/news/NEWS.28.1

These can also be accessed from within Emacs by doing `C-h n`.



___
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