Re: Files missing in RPM database

[Michael Schwendt]

On Wed, 1 May 2024 12:49:32 -0500, W. Michael Petullo wrote:

> This clean up process has been going on since Fedora 1.

FWIW, my mass-filings of "unowned directory" bugzilla tickets has had poor
responses by packagers eventually and therefore has been discontinued.

Instead, a section has been included in the packaging guidelines:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/
--
___
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: Switching XZ for ZSTD?

[Michael Schwendt]

On Thu, 04 Apr 2024 13:51:59 +, Arnie T via devel wrote:

> The 'basic issue' I see is the "one or two" developers, some that nobody 
> knows in person, vis-à-vis "many" developers on a big project.
> 

The same sort of a secret agent's infiltration attack on a project would
also be possible with contributors knowing themselves "in person". It's
not about someone gaining commit access and impatiently running wild
within the next week already, but about a much longer period of time.
"Another pair of eyes" on any commit as well as on pull requests is always
a good idea. Not because you don't trust other contributors but because
even basic peer review often helps with spotting bugs and regression.
--
___
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: NTFS corruption with Fedora 37 and 38

[Michael Schwendt]

On Mon, 31 Jul 2023 18:50:30 +0100, Richard W.M. Jones wrote:

> Did you get to the bottom of what's really happening here?

As in the message that opened this topic, it is suspected that there
has been a change to mount with kernel ntfs3 instead of ntfs-3g.

I remember I've not had corruption with fuse/ntfs-3g, but for some time
with Fedora 37 and 38, ntfs3 is used. Test with an USB drive:

# mount|grep -i ntfs
/dev/sda1 on /run/media/ms38/HD-PCU2 type ntfs3 
(rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8,uhelper=udisks2)

# lsmod|grep -i ntfs
ntfs3 323584  1

> We use and test ntfs-3g
> extensively and have not seen any reports of corruption.

Right, but it is kernel ntfs3 that causes the corruption. Even if only
copying a single folder to a drive and unmounting + safe-removing the drive
with Nautilus.
___
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: NTFS corruption with Fedora 37 and 38

[Michael Schwendt]

On Tue, 25 Jul 2023 16:29:20 +0200, Ralf Corsépius wrote:

> [1] I've only sporadically used NTFS, before, but for a couple of weeks, 
> I had to use it more frequently.

I would also call my usage "sporadic" (accessing NTFS USB sticks and
camera SD cards), but the worst symptoms I've had ever had before was
default auto-mounting in Nautilus offering only a read-only mount. Never
corruption while simply copying a single folder to NTFS (and, btw,
correctly unmounting and safe-removing the media).

A bit of Google searching suggests ntfs-3g has been the more stable but
slower solution so far.

Here's another Fedora 38 user reporting corruption:
https://unix.stackexchange.com/questions/751529/ntfsfix-volume-is-corrupt-you-should-run-chkdsk-even-after-chkdsk
___
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

NTFS corruption with Fedora 37 and 38

[Michael Schwendt]

Trying to figure out what has changed in Fedora land that causes NTFS
corruption for some time. This is with default workstation with GNOME
Shell auto-mounting external storage media when plugging them in.

A ticket in bugzilla suggests there has been a changed from ntfs-3g to ntfs3:

https://bugzilla.redhat.com/2182206
( udisks switched to kernel ntfs3 driver instead of ntfs-3g for mounting ntfs 
since the kernel 6.2 update )

The current state of development is highly dangerous.
___
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: mass rebuild status - 2022-01-25

[Michael Schwendt]

On Thu, 27 Jan 2022 15:06:31 +0100, František Šumšal wrote:

> I've indeed noticed the other warnings. However, given this mass rebuild was
> done with a new snapshot of gcc-12, the error is probably related to that,
> that's why I pointed out the most severe issue (since it's an error, not
> a warning).

There is nothing like that in the build.log for the other archs, so my
original question about armv7hl remains.
___
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: mass rebuild status - 2022-01-25

[Michael Schwendt]

On Thu, 27 Jan 2022 14:01:40 +0100, František Šumšal wrote:

> Looks like the culprit is:

You may have noticed that there are many more compiler errors in the build.log,
but it seems you've missed that the src.rpm builds fine for all other archs.
What gives?
___
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: mass rebuild status - 2022-01-25

[Michael Schwendt]

On Tue, 25 Jan 2022 10:04:32 -0800, Kevin Fenzi wrote:

> After that we will be done and it will be on maintainers to sort out
> FTBFS issues. 

What's up with the armv7hl arch being _the only one_ (!) that failed?
https://koji.fedoraproject.org/koji/taskinfo?taskID=81787304
___
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: Non-responsive maintainer check for bpepple

[Michael Schwendt]

On Fri, 17 Dec 2021 11:50:42 -0500 (EST), Scott Talbert wrote:

> Does anyone know how to contact them?  Direct email and bug reports have 
> had no response.

His twitter profile points at a few contact options as a last resort.
https://twitter.com/bpepple
___
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 rawhide compose report: 20210727.n.0 changes

[Michael Schwendt]

On Tue, 27 Jul 2021 15:26:31 +0200, Petr Pisar wrote:

> It's a locale in sed:
> 
> $ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' 
> /usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=C.UTF-8 sed 
> 's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!'
> 48 /* 3.8-devel */
> $ grep '[ ]*#define[ ]*_AUD_PLUGIN_VERSION[ ]\+' 
> /usr/include/libaudcore/plugin.h 2>/dev/null | LC_ALL=en_US.UTF-8 sed 
> 's!.*_AUD_PLUGIN_VERSION[ ]*\([0-9]\+\).*!\1!'
> 48

What has changed and where?
Why does [0-9]+ cover more than the numerical part of the string?
___
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 rawhide compose report: 20210727.n.0 changes

[Michael Schwendt]

Something in grep/sed/rpm is broken since today or yesterday.

On July 24th, a %global definition in a spec file still worked.
It still works with a local Mock build for Rawhide/F35.
It fails in koji Rawhide:
https://kojipkgs.fedoraproject.org//work/tasks/3604/72743604/build.log
___
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: How to replace the rpm-build package with my own in a mock container

[Michael Schwendt]

On Sun, 16 May 2021 13:11:09 -, Mikhail Gavrilov wrote:

> I am already added my local repository to 
> `/etc/mock/templates/fedora-rawhide.tpl` with locally builded rpm-build  
> package.

Did you include that template file from within the mock .cfg file?
What does the root.log file contain?

Did earlier access to your local repo work from mock?
___
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: Orphaned packages looking for new maintainers (a.k.a. the Return of the Javapocalypse)

[Michael Schwendt]

On Mon, 3 May 2021 10:23:02 +0200, Miro Hrončok wrote:

> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2021-05-03.txt
> grep it for your FAS username and follow the dependency chain.

Some more detail would be helpful in this case:

Too many dependencies for dpdk, not all listed here

> mschwendt: dpdk

Doesn't ring a bell. And the depchain above isn't complete. Is this package
a low-level requirement for NetworkManager?
___
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: GNOME Shell startup app issue with /tmp

[Michael Schwendt]

On Sat, 16 Jan 2021 08:44:54 -0600, Michael Catanzaro wrote:

> > Most likely you want to use $XDG_RUNTIME_DIR instead, which is private
> > to your user, and not shared with other users. Use glib's
> > g_get_user_runtime_dir() as a wrapper for accessing that variable.  
> 
> Or g_dir_make_tmp()

No. The created tmp directory must be known to any other CM instances,
and using a mkdtemp variant is not applicable in that case. But Lennart's
suggest of g_get_user_runtime_dir() is plausible. I've sent a question
about that to upstream devs.
___
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: GNOME Shell startup app issue with /tmp

[Michael Schwendt]

On Sat, 16 Jan 2021 15:34:44 +0100, Lennart Poettering wrote:

> Regardless of the actual issue ran into: taking a predictable name
> like that in /tmp/ is a DoS vulnerability. /tmp/ is a shared
> namespace, any local program can take any name in there, and hence
> block you out from starting Claws mail — simply by creating a file or
> directory by that name there under their own ownership.

That would be a mostly theoretical/academical attack vector, since
Claws Mail refusing to start and printing an error message would alert
the user, and the user could take proper action against the attacker.

> Most likely you want to use $XDG_RUNTIME_DIR instead, which is private
> to your user, and not shared with other users. Use glib's
> g_get_user_runtime_dir() as a wrapper for accessing that variable.

From the Claws Mail FAQ:

| Why does Claws Mail allow me to open more than one instance at the same
| time for the same user on a network?
| 
| Claws Mail opens a Unix-domain socket using a name constucted from your
| TMPDIR path plus your UID. This socket is used to arbitrate multiple
| instances on a given machine. In Linux, at least, named Unix-domain
| sockets are known only locally, to the creating machine. Pointing your
| TMPDIR environment variable to /home/yours/tmp doesn't have the desired
| effect, as the socket definition would need to be propagated across the
| LAN and isn't.
| 
| Setting an alternate configuration directory (--alternate-config-dir
| option) overrides TMPDIR value and places the socket under the alternate
| directory.
___
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

GNOME Shell startup app issue with /tmp

[Michael Schwendt]

Noticed that when setting Claws Mail to become a startup app in F33
GNOME Shell, it doesn't create its /tmp/claws-mail-$UID directory.

Claws Mail relies on g_get_tmp_dir() for retrieval of the path, so it seems
when the program is launched, either /tmp doesn't exist yet or there are
problems creating files in it.

Has anything changed related to the GNOME startup app procedure?
___
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: How did this file end up in the lookaside cache?

[Michael Schwendt]

On Tue, 12 Jan 2021 00:13:21 +, Cristian Morales Vega wrote:

> Not sure exactly when, but it looks like me creating
> https://src.fedoraproject.org/rpms/doxygen/pull-request/9 has
> triggered a process uploading the tarball to the lookaside cache.
> 
> The tarball inside
> https://kojipkgs.fedoraproject.org//work/tasks/5674/59445674/doxygen-1.9.1-1.fc34.src.rpm
> is fine. But when I later tried to build the same sources in copr I
> got a 404 error when downloading the tarball from the lookaside cache
> (https://download.copr.fedorainfracloud.org/results/reddwarf/personal/srpm-builds/01876339/builder-live.log.gz).
> The thing is that
> https://src.fedoraproject.org/lookaside/pkgs/doxygen/doxygen-1.9.1.src.tar.gz/sha512/a84fbea1874921317b58345c53fc4eac0382c9e593f0e1ee899a31e67ead3fd12b2da8145b37e2e09d665e28d060e6717c92de7e8d0a31fc5f24fdcc4715f54d/doxygen-1.9.1.src.tar.gz
> is a 19 MiB monster (instead of the 5 MiB of the real tarball) with,
> obviously, the wrong hash.
> 
> How did this happen? Is it "expected" even if I don't understand it?
> Is it a bug somewhere?

The tarball you refer to first is gzipped and matches the commit diff for
the "sources" file:

$ sha512sum doxygen-1.9.1.src.tar.gz 
637496c549a4a150cfaeb5d4913de512262145ecd7d455d7b7f3dd68f9416e47d931a6c1efd8a17d931e4baf4a8a9f2ed21124664003b123b6f89ca4abf263ed
  doxygen-1.9.1.src.tar.gz

The later one ends with .tar.gz but is uncompressed and matches the "sources"
file in Fedora dist-git:

$ file doxygen-1.9.1.src.tar.gz
doxygen-1.9.1.src.tar: POSIX tar archive
$ grep doxygen sources
SHA512 (doxygen-1.9.1.src.tar.gz) = 
a84fbea1874921317b58345c53fc4eac0382c9e593f0e1ee899a31e67ead3fd12b2da8145b37e2e09d665e28d060e6717c92de7e8d0a31fc5f24fdcc4715f54d
$ sha512sum doxygen-1.9.1.src.tar.gz
a84fbea1874921317b58345c53fc4eac0382c9e593f0e1ee899a31e67ead3fd12b2da8145b37e2e09d665e28d060e6717c92de7e8d0a31fc5f24fdcc4715f54d
  doxygen-1.9.1.src.tar

So, it seems a Fedora maintainer of doxygen has uploaded the huge 
uncompressed tarball to the lookaside cache accidentally or unknowingly
because of its .gz extension.
___
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: can't install package pipewire-jack-audio-connection-kit

[Michael Schwendt]

On Fri, 01 Jan 2021 15:28:48 -, Leigh Scott wrote:

> > On Fri, Jan 1, 2021 at 5:07 AM Michael Schwendt  > wrote:
> > 
> > PipeWire replaces libjack and the JACK daemon, so the Conflicts are 
> > correct.  
> 
> How?
> 
> $ rpm -q --requires libavdevice |grep jack
> libjack.so.0()(64bit)

Just in case, above that is a misattributed quote. I didn't write that.
___
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: can't install package pipewire-jack-audio-connection-kit

[Michael Schwendt]

On Fri, 1 Jan 2021 10:26:13 -0500, Nico Kadel-Garcia wrote:

> > Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit:
> > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970
> >
> > Conflicts in distribution packages are bad, bad, bad and typically a dead
> > end when someone runs into them due to dependencies.  
> 
> They're commonplace for packages that use the same binary or config file 
> names.
> or when one package obsoletes another. This is happening right now
> with "createrepo" and the renamed package "createrepo_c".

createrepo_c has NEVER done that via conflicts! It has followed the
packaging guidelines to replace the createrepo package via a pair of
Obsoletes/Provides tags.
___
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: can't install package pipewire-jack-audio-connection-kit

[Michael Schwendt]

On Fri, 1 Jan 2021 06:58:43 -0500, Neal Gompa wrote:

> > Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit:
> > https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970
> >
> > Conflicts in distribution packages are bad, bad, bad and typically a dead
> > end when someone runs into them due to dependencies.  
> 
> PipeWire replaces libjack and the JACK daemon, so the Conflicts are correct.

Replacing packages is done via "Obsoletes", so depsolving tools can do
the right thing automatically. As can be seen on above koji page, the
"Obsoletes" tag is empty.
___
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: can't install package pipewire-jack-audio-connection-kit

[Michael Schwendt]

On Thu, 31 Dec 2020 16:26:15 +0100, Matthias Runge wrote:

> On 31/12/2020 16:10, Martin Gansser wrote:
> > this means that jack-audio-connection-kit  has been replaced by 
> > pipewire-jack-audio-connection-kit ?  
> 
> >- package pipewire-jack-audio-connection-kit-0.3.13-4.fc33.i686 
> > conflicts with jack-audio-connection-kit provided by 
> > jack-audio-connection-kit-1.9.14-5.fc33.x86_64  
> 
> 
> This messes with i686 and x86_64? Usually that means, something else is 
> broken.
> Personally, I'd try to get rid of the 32bit binary as quickly as 
> possible. Either by rpm -e --nodeps  && dnf install 
> to get the 64 bit version instead of 32 bit.

Explicit "Conflicts" here, at least, in pipewire-jack-audio-connection-kit:
https://koji.fedoraproject.org/koji/rpminfo?rpmID=24326970

Conflicts in distribution packages are bad, bad, bad and typically a dead
end when someone runs into them due to dependencies.
___
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 GNOME Shell rendering problem

[Michael Schwendt]

On Wed, 23 Dec 2020 12:11:53 +0100, Olivier Fourdan wrote:

> > The last time I had asked about Nvidia+Fedora was in 2018 when booting
> > an installation would end up with a terribly slow GNOME Shell:
> >
> > https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/EC7T7MN3DXN6XU5QHNG2DE3VHMTXOIDV/
> >  
> 
> I'm not sure a problem with Fedora 28 and a thread more than two years old
> is actually relevant to the issue at stake here though.

The only relevance is that I insist on running with Nouveau rather than
using the proprietary drivers as packaged by RPM Fusion. IOW, I deliberately
reject people's primary choice because I'm willing to test the default even
if it might break. That issue in 2018 showed that Fedora Workstation by
default couldn't handle this hardware safely. Sometimes it worked, but
usually it didn't.

This damaged character is not specific to Fedora 33. It has been observed
before. 

So, when it happens, I need ideas what to try. Alternatively, I could
try running with a modified configuration as to see whether the symptoms
won't show up ever again.
___
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 GNOME Shell rendering problem

[Michael Schwendt]

On Tue, 22 Dec 2020 17:15:32 +0100, Olivier Fourdan wrote:

> Can you check and look for GL_OUT_OF_MEMORY messages in the journalctl logs
> for gnome-shell? (Xwayland being spawned by gnome-shell, the messages from
> Xwayland will be marked as gnome-shell in the logs)
> 
> Xwayland uses glamor by default, and I can think of are a number of known
> nouveau issues which can eventually lead to GL_OUT_OF_MEMORY errors in
> glamor, with various effects, so it could possibly be the root cause of the
> issue.

Regardless of VRAM size? It happens also with 6GB VRAM, so an OOM condition
(even if it were by mistake) straight after booting into GNOME Shell would
be a very, very bad scenario.

I don't know a reproducer yet. When it occurs, it doesn't make the system
unstable or slow, it doesn't cause any other harm. It's just odd to
observe a single damaged character. Such symptoms typically imply some
sort of data/memory corruption in some place.

The last time I had asked about Nvidia+Fedora was in 2018 when booting
an installation would end up with a terribly slow GNOME Shell:
  
https://lists.fedoraproject.org/archives/list/t...@lists.fedoraproject.org/thread/EC7T7MN3DXN6XU5QHNG2DE3VHMTXOIDV/

That isn't reproducible anymore, but other issues (might) remain.
Some can be worked around by switching to Xorg.
___
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 GNOME Shell rendering problem

[Michael Schwendt]

On Mon, 21 Dec 2020 08:09:50 -0500, Owen Taylor wrote:

> Most likely the GPU driver. This is a symptom of a corrupted Xft glyph
> cache inside the Xwayland X server.
> 
> (It's not impossible that the glyph was corrupted before upload by
> some other component, but that's much less likely - especially if it
> seems to be hardware dependent.)

It's been observed on Nouveau driver based installations / with no Nvidia
related packages from RPM Fusion as to test whether default installations
of Fedora Workstation would work acceptably out of the box.
___
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

Fedora GNOME Shell rendering problem

[Michael Schwendt]

In the attached screenshot excerpt it's the bold "a" character that is
missing everywhere within the entire main window of Claws Mail. In other
cases, it's a different character. Sometimes it is not missing but
visually corrupted, looking like random "garbage" data.

Fedora 33 x86_64 GNOME Shell on Wayland, and Claws Mail is based on GTK+ 2.

What part of the rendering process could be the culprit? Pango?
___
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

Bodhi failed to get a resource from PDC ...

[Michael Schwendt]

Bodhi fails with this error message. Any suggestion on how to continue?

Builds : Unable to create update.
Bodhi failed to get a resource from PDC at the following URL
"https://pdc.fedoraproject.org/rest_api/v1/component-branches/?active=true_path=true=global_component=f32_size=100=rpm_component=claws-mail;.
The status code was "503".
The error was "".
___
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: Unannounced soname bump: libreport

[Michael Schwendt]

On Fri, 14 Aug 2020 16:37:28 +0200, Fabio Valentini wrote:

> > As a side note, the update now has arch specific BuildRequires, so the SRPM
> > cannot be rebuilt on anything but .
> >
> > https://koschei.fedoraproject.org/package/libreport?collection=f33  
> 
> Aaaw ... stuff like this makes me sad :(

What makes me sad is the poorly maintained package %changelog. Instead of
summing up changes to the RPM package, it sums up changes internal to
libreport. It does not list any of the spec file changes.

A massive commit to the package without any %changelog entry:
https://src.fedoraproject.org/rpms/libreport/c/246d3174118e03cbb345f1d434f3fbe11864b015?branch=master

And later the addition of a %changelog entry that doesn't cover any of the
package changes.
___
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: A few questions about rpmdev-bumpspec tool

[Michael Schwendt]

On Thu, 13 Aug 2020 18:41:23 +0800, Qiyu Yan wrote:

> In the latest version of rpmdevtools, rpmdev-bumpspec has changed to
> use time+date in the changelog it generates[1], while the packaging
> guidelines have not been updated accordingly[2], should the guideline
> be updated to the rpmdev-bumpspec change?

The git commit message for that change is vague, since it only refers to
an RPM version but doesn't sum up what the goal of this change is.

> I am packaging fcitx5 using forge macros, and upstream have never
> tagged a version, in this case, I am packaging like this [3] (The
> snapshot dates and git short commit hashesin changelog is manually
> added). With this spec file, I noticed that when I try to use
> rpmdev-bumpspec to generate a changelog, it will give things like this
> [4].

The forge macros you use mess with %dist, which is highly questionable.

The rpmdev-bumpspec script itself doesn't evaluate any RPM macros. It only
recognizes a variety of version/release schemes used by Fedora.

For the %changelog comment, it relies on an "rpm" command-line call in
order to determine the full E:VR for the %changelog entry. Since %dist is
not to be included in %changelog comments, %dist gets undefined, but then
the %forge macro stuff is lost.

As a side-note: The E:V-R details right of the email address in changelog
comments are not everyone's cup of tea. They are not mission critical but
optional. If truncated, they don't break the rpmbuild. In your case, V-R
is complete and accurate. The left most-significant part of %release is
included in the V-R and is sufficient, and while the git commit hash is
missing, it is just noise in changelog comments.
___
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: Duplicate package was reviewed

[Michael Schwendt]

On Fri, 31 Jul 2020 12:48:44 +0200, Tomasz Torcz wrote:

>   What about bringing old, possibly unmaintained library into Fedora?
> It may contain unfixed security bugs.  Not that I know of any, but it's
> a possibility.

1) First it would need to pass the review process. Submitter _and_
reviewer both ought to notice that it is "old, possibly unmaintained"
software. In case of a lib, there's also the related question of "what
will use this lib?". Later it will be "what still uses this lib?" and
"are there alternatives or a successor?".

2) Once a package has been included in the package collection, "old,
possibly unmaintained" software is sort of a grey area. There are
thousands of packages in the collection, "possibly" with undiscovered
security issues. For those that are known to contain major vulnerabilities
and are unmaintained (like wxGTK2), it may be necessary to remove a
package from the collection.
___
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: Duplicate package was reviewed

[Michael Schwendt]

libqmatrixclient vs libquotient

Absolutely no conflict whatsoever. Different SONAME, different file/folder
names, different package names, different project name. Even if they came
from the same project, the old compat- naming scheme would not have applied.
___
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: Orphaning a bunch of my packages (part 1 of X)

[Michael Schwendt]

On Sat, 6 Jun 2020 12:06:28 +0200, Andy Mender wrote:

> I'm a heavy LXQt user. Does that mean that if those packages get orphaned
> for good, they will be dropped from the repositories?

It is explained here:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers
___
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: Unretiring abcMIDI

[Michael Schwendt]

On Tue, 02 Jun 2020 10:46:45 -0400, Stuart D. Gathman wrote:

>  2.  The GPLv2 license is buried in readme.txt.  I added a LICENSE file
> to my git mirror.  Should I include that as a patch?

https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text

>  4.  The original package was
> named abcMIDI.  Should I rename to abcmidi?  Upstream is a mixture. 
> Must be a Windows shop. :-)

https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/

Particulary:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_case_sensitivity
___
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: Bodhi: "how to install" is supposed to work?

[Michael Schwendt]

On Tue, 02 Jun 2020 09:32:27 +0200, Alessio wrote:

> In Bodhi there is a dnf command in the "How to install" section, in
> order to install the package to test. Something like:
> 
> sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-
> 81a3b3df7d
> 
> Is it supposed to work? Because every time I tried it, it didn't work.


> In addition a package received a negative karma due to that ^_^;

Seems to refer to

  https://bodhi.fedoraproject.org/updates/FEDORA-2020-81a3b3df7d

where user "jpbn" downvoted the update only because above command
couldn't find the package 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

Re: F30 security update submitted for stable "marked obsolete" instead of being pushed

[Michael Schwendt]

On Fri, 29 May 2020 16:55:37 +0200, Kevin Kofler wrote:

> Miro Hrončok wrote:
> > AFAIK this was never the case, but I'm not sure. I remember in the past
> > the updates just kinda stuck in limbo (being pushed to stable for
> > eternity). At least now they are marked as obsolete.  
> 
> I think there really ought to be a guarantee that everything queued before 
> the deadline actually gets pushed in one last push, as opposed to saying 
> "sorry, the last push was actually hours earlier than the official deadline, 
> you're screwed forever because we will never do a push again for that 
> release".

With a properly implemented deadline, the Updates System would close its
doors at a well-defined time prior to a last push. Anything that has entered
the "pending -> stable" queue early enough, would be pushed. Everything else
would be locked and would not be able to change state from testing to stable,
for example.
___
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: What's pulling in a bunch of texlive packages?

[Michael Schwendt]

On Sat, 30 May 2020 16:11:16 +0100, José Abílio Matos wrote:

> Most probably something that provides documentation, e.g. on pdf.

docbook-utils-pdf is a likely candidate.
___
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: python3-pyparsing: conflicting error

[Michael Schwendt]

On Fri, 29 May 2020 15:09:34 +0200, Jun Aruga wrote:

> I opened the issue ticket for systemtap.
> https://bugzilla.redhat.com/show_bug.cgi?id=1841558

Why would you do that?
It's "python3" (3.8) -> "python3.9" dependency breakage.
___
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: Retired packages with maintainers

[Michael Schwendt]

On Tue, 12 May 2020 at 14:13, Fabio Valentini  wrote:
>
> > - Do we have a documented way to mark modules as orphaned or retired?
>
> I think we do. I seem to remember seeing "dead.module" files in some
> module repositories I looked at ...

Well, the "dead.package" file in dist git has been the standard way to
mark packages as retired. "fedpkg retire DESCRIPTION" adds it, too,
and _without_ marking the package as orphaned anywhere.
___
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 pagure confusion wrt EPEL

[Michael Schwendt]

On Tue, 5 May 2020 at 10:33, Pierre-Yves Chibon  wrote:
>
> The scripts syncing information from dist-git to bugzilla have been broken 
> for a
> long time (less than 5 years though) and we've picked them up, fixed and clean
> them so they work again.
> This has been announced here and on devel-announce over the past few months
> (including an email from yesterday about the move of the bugzilla overrides to
> dist-git itself).
>
> So after looking at the bug above (the only package I could find in this
> thread), I went to: https://src.fedoraproject.org/rpms/claws-mail clicked 
> "Edit"
> on the left hand side column and changed the bugzilla assignee in EPEL to
> `orphan`. At the next run of the script, the EPEL tickets will be re-assigned 
> to
> orphan.
>
> Now I ran into this thread a little bit by chance while checking my emails. If
> you have such issue in the future you may want to actually report it, ie: 
> open a
> ticket on https://pagure.io/fedora-infrastructure/issues so we can either fix
> the bug if there is one or tell explain how the situation can be adjusted.

None of that explains why and when I've been assigned to EPEL packages.
This is a thread from January.

It's the same with all other packages. The web page you refer to now explicitly
claims that somebody is a "Bugzilla Assignee" for EPEL even if a package
isn't available in the EPEL dist and despite a person not being active
within the
EPEL project at all.

While it is good to know that assigning to "orphan" may do something (I had
only tried extras-orphan which is the alias that is used in bugzilla, but it was
rejected), the information shown on the web page would be misleading and
would show that also for packages that don't exist in EPEL. Also, the
claws-mail EPEL package branches have been retired in January due to this
thread, and nevertheless somewhere I was made the bugzilla assignee again
since then. No idea where and when. Hence this thread from January!
___
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 pagure confusion wrt EPEL

[Michael Schwendt]

On Mon, 04 May 2020 20:12:58 -0400, James Cassell wrote:

> > Can this stop, please?
> > 
> > Again somebody has used a script to assign bugzilla EPEL tickets to me
> > again, although I am not responsible for the EPEL packages and have never
> > been responsible for them.
> > 
> > I feel offended.
> > 
> > Whoever is behind this, *please* stop!
> > 
> > Example:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1293581
> >   
> 
> Looks like some automation, not attributed to a person:
> 
> Fedora Admin user for bugzilla script actions 2020-05-04 17:04:23 UTC 
> Assigneeextras-orphan   bugs.michael
> 
> I'm sure someone knows...

Automation since when? The ticket is five years old! It was assigned to
orphan owner since end of January. Who decided to start a script after
such a long time?

If this cannot be stopped, perhaps it's time to orphan or retire the
package. I've never signed up as EPEL maintainer. Not even retiring the
EPEL packages four months has fixed this mess.

:-/
___
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 pagure confusion wrt EPEL

[Michael Schwendt]

> This incident turns into a growingly unpleasant experience for me.
> I've asked you to clean up the mess in bugzilla and reassign the EPEL
> packages properly, because I am not responsible for those packages.
> You've not done that. I've had to do it myself. Team work doesn't mean
> that you assign tickets to me, which have been neglected/ignored for
> almost five years. This isn't a hot-potato-dropping contest.

Can this stop, please?

Again somebody has used a script to assign bugzilla EPEL tickets to me
again, although I am not responsible for the EPEL packages and have never
been responsible for them.

I feel offended.

Whoever is behind this, *please* stop!

Example:
https://bugzilla.redhat.com/show_bug.cgi?id=1293581
___
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: Aarch64 build failure: hidden symbol `__aarch64_ldadd4_acq_rel' in /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced by DSO

[Michael Schwendt]

On Sat, 2 May 2020 12:36:29 +0200, Sandro Mani wrote:

> Hi
> 
> I'm stuck on the following build failure of the aarch64 build here [1]
> 
> /usr/bin/ld: .libs/geod: hidden symbol `__aarch64_ldadd4_acq_rel' in 
> /usr/lib/gcc/aarch64-redhat-linux/10/libgcc.a(ldadd_4_4.o) is referenced 
> by DSO
> /usr/bin/ld: final link failed: bad value
> collect2: error: ld returned 1 exit status
> 
> Never seen anything like this, any ideas?

Since it's about libgcc and aarch64, it's very likely related to the
earlier thread "Hundreds of aarch64 failures with gcc 10.0.1-0.13".
___
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: Hundreds of aarch64 failures with gcc 10.0.1-0.13

[Michael Schwendt]

> Seems like a lot of things just started to fail to build on aarch64.

I also get the following only for aarch64:

/usr/bin/ld: index.lib.o: in function `IndexBase::clear(void (*)(void*, int))':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/index.cc:48: undefined 
reference to `__aarch64_ldadd8_acq_rel'
/usr/bin/ld: index.lib.o: in function `IndexBase::insert(int, int)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/index.cc:86: undefined 
reference to `__aarch64_ldadd8_acq_rel'
/usr/bin/ld: ringbuf.lib.o: in function `RingBufBase::alloc(int)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/ringbuf.cc:60: undefined 
reference to `__aarch64_ldadd8_acq_rel'
/usr/bin/ld: ringbuf.lib.o: in function `RingBufBase::destroy(void (*)(void*, 
int))':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/ringbuf.cc:84: undefined 
reference to `__aarch64_ldadd8_acq_rel'
/usr/bin/ld: strpool.lib.o: in function `String::raw_ref(char const*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/strpool.cc:143: undefined 
reference to `__aarch64_ldadd4_acq_rel'
/usr/bin/ld: strpool.lib.o: in function `String::raw_unref(char*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/strpool.cc:160: undefined 
reference to `__aarch64_ldadd4_acq_rel'
/usr/bin/ld: 
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/strpool.cc:163: undefined 
reference to `__aarch64_cas4_acq_rel'
/usr/bin/ld: strpool.lib.o: in function `Getter::found(StrNode*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/strpool.cc:98: undefined 
reference to `__aarch64_ldadd4_acq_rel'
/usr/bin/ld: strpool.lib.o: in function `Remover::found(StrNode*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/strpool.cc:109: undefined 
reference to `__aarch64_cas4_acq_rel'
/usr/bin/ld: tinylock.lib.o: in function `tiny_lock(char*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tinylock.cc:29: undefined 
reference to `__aarch64_swp1_acq'
/usr/bin/ld: tinylock.lib.o: in function `tiny_lock_read(unsigned short*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tinylock.cc:37: undefined 
reference to `__aarch64_ldadd2_acq_rel'
/usr/bin/ld: 
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tinylock.cc:39: undefined 
reference to `__aarch64_ldadd2_acq_rel'
/usr/bin/ld: tinylock.lib.o: in function `tiny_unlock_read(unsigned short*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tinylock.cc:46: undefined 
reference to `__aarch64_ldadd2_acq_rel'
/usr/bin/ld: tinylock.lib.o: in function `tiny_lock_write(unsigned short*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tinylock.cc:52: undefined 
reference to `__aarch64_cas2_acq_rel'
/usr/bin/ld: tinylock.lib.o: in function `tiny_unlock_write(unsigned short*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tinylock.cc:58: undefined 
reference to `__aarch64_ldadd2_acq_rel'
/usr/bin/ld: tuple.lib.o: in function `TupleData::ref(TupleData*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tuple.cc:391: undefined 
reference to `__aarch64_ldadd4_acq_rel'
/usr/bin/ld: tuple.lib.o: in function `TupleData::unref(TupleData*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tuple.cc:398: undefined 
reference to `__aarch64_ldadd4_acq_rel'
/usr/bin/ld: tuple.lib.o: in function `TupleData::copy_on_write(TupleData*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tuple.cc:407: undefined 
reference to `__aarch64_ldadd4_acq_rel'
/usr/bin/ld: tuple.lib.o: in function `TupleData::unref(TupleData*)':
/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tuple.cc:398: undefined 
reference to `__aarch64_ldadd4_acq_rel'
/usr/bin/ld: /builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tuple.cc:398: 
undefined reference to `__aarch64_ldadd4_acq_rel'
/usr/bin/ld: 
tuple.lib.o:/builddir/build/BUILD/audacious-4.0.3/src/libaudcore/tuple.cc:391: 
more undefined references to `__aarch64_ldadd4_acq_rel' follow
collect2: error: ld returned 1 exit status
Failed to link libaudcore.so!
___
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: Orphaning soundtracker

[Michael Schwendt]

On Thu, 9 Apr 2020 07:10:48 -0700, Erich Eickmeyer wrote:

> soundtracker is FTBFS and is basically gnome 1 software that
> necro-limped along like a zombie for a few years (read: decades). As it
> FTBFS and is dead upstream, I believe it's suffering bitrot so it's
> probably time to let it die.
> 
> As such, I'm orphaning this package, and it will probably be retired.

It should largely depend on either your personal interest in this tool and
whether you are aware of anyone still using it to compose music with it.
There have been many, more capable music tracker editors since the original
one from 1987.

There has been a v1.0.1-pre1 release for GTK2 in February 2020 (as update
for the 1.0.0 release from Dec 2019) while Fedora's package is stuck at
0.6.8 for GTK1. There is a branch for GTK3, too. Either one could help
with the FTBFS issue in case you want to keep this tool alive.
___
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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Michael Schwendt]

On Sat, 1 Feb 2020 at 19:58, Stephen John Smoogen  wrote:
>
>> From
>> https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/#_deal_with_reported_bugs_in_a_timely_manner
>>  :
>>
>> It is recommended that non-coder packagers should find
>> co-maintainers who are familiar with the programming language used
>> by their package(s)
>>
>
> That rule like many others was written and worked when Fedora was a small 
> band of people where everyone knew each other.  However over time, the mix of 
> people have changed and the ability to find a co-maintainer who has the the 
> time and energy to help out is rare.
>

It is less due to a changing "mix of people" but more because of
experienced people from the FPC or FESCo sitting together and coming
up with helpful SHOULD items rather than strict MUST items. Above
guideline is much longer than what was quoted here and covers more
cases than what was quoted here. The quoted sentence is ripped out of
its context. Above guideline is still valid and useful, and I assume
that FESCo still agrees with it, but it is about bugs in general,
including simple FTBFS issues and basic code customizations for
Fedora. As obvious as it may be to ask for help when facing an issue
you cannot fix yourself, without such guidelines, many people would
shy away from becoming a package maintainer.
___
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: RFC: Security policy adjustments to make it easier to implement and more friendly to maintainers

[Michael Schwendt]

On Thu, 30 Jan 2020 at 15:47, Richard Shaw  wrote:
>
> 4. I'm not a C/C++ programmer and certainly not a security expert. If I can 
> find a link to a fix for another distro, such as debian, I'll apply it but 
> more often than not there's nothing there when I look. I'll even file an 
> issue upstream but most of the time it's ignored.
>

Programming language knowledge doesn't imply intimate knowledge of
every software development framework a program written in that
language may be based on. Neither does it imply intimidate knowledge
of the program and its source code. That is when packagers consult
upstream developers, and not even for upstream developers all security
issues are trivial to fix. Sometimes potential fixes are controversial
and require software development that goes far beyond what packagers
do.

> 5. A of times it's for an EPEL package that's much older than the current 
> release so the fix for Fedora can't be easily applied to EPEL.
>

Also true.
___
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 pagure confusion wrt EPEL

[Michael Schwendt]

On Fri, 31 Jan 2020 at 20:45, Robbie Harwood  wrote:
>
> You received a total of between 4 and 8 emails depending on how bugzilla
> batched them.  My apologies for the extra 3-7.

More than eight because of needinfo notifications, "assigned" and "Cc"
changes and tracker ticket changes.

> >> Andreas Bierfert (awjb), who was recently declared non-responsive.
> >
> > That could have been mentioned.  Is that when some process transferred
> > EPEL packages to me without prior asking?
>
> I did mention it.  My words were that "the maintainer is no longer
> active in Fedora, and you're the default assignee for the package".

Whenever the non-responsive maintainer procedure was complete, what
happened next? The unmaintained EPEL packages ought to have been
orphaned or retired properly, and existing bugzilla components
reassigned to orphan owner. All within EPEL and without forcefully
assigning five years old tickets to a Fedora packager.

> Your response, by the way, was: "Would you mind becoming familiar with
> the Fedora Project a bit?".

EPEL and the Fedora package collection are two separate projects with
different maintainers. It's not that the Fedora packages must be
anything like "upstream" for the EPEL packages.

Once more, I am not the EPEL maintainer of that package. And I've
pointed you at the EPEL FAQ:
https://fedoraproject.org/wiki/EPEL/FAQ#I_maintain_a_package_in_Fedora._Do_I_have_to_maintain_it_for_EPEL_now.2C_too.3F

When you learned that the EPEL maintainer of that package is no longer
available, what made you think that you could simply assign the
tickets to the Fedora maintainer?

> >> My view is that there's an open security bug, so it's reasonable to want
> >> to know whether it's going to be fixed.
> >
> > You consider it reasonable to look into ancient security issues after
> > almost five years?  The related tracking bugs did serve no purpose for
> > almost five years?
>
> Yes?  This shouldn't come as a surprise to you.  The whole process of
> security bugs, CVEs, and the like exists to get them *fixed*.  If they
> are in fact not, you might not care about EPEL, but EPEL doesn't want to
> ship vulnerable software any more than you do.

What do you refuse to understand? I am _not_ the EPEL maintainer of
this package. I don't do EPEL packaging. What maintenance procedures
are in place for EPEL to handle cases like that without forcefully
assigning tickets and/or packages to a Fedora package maintainer?

> You are repeatedly ignoring that I'm not concerned about the Fedora
> package.  Please stop.

You've assigned EPEL tickets to a Fedora packager. Can't be so hard to
understand that. I've told you about the difference in private email.

> You are subject mater expert for the project.
> No one is better suited than you to answer the question of whether a
> given version is affected or not.

Have these CVEs been reported about the Fedora package, too, five
years ago? Then look up the tracker tickets and the Fedora specific
tickets, and the CVE numbers will appear in the package %changelog
because of packaging guidelines. Also, have the security issues been
reported to upstream or only EPEL?

> > As pointed out, I don't keep an eye on EPEL. I'm completely surprised
> > that all of a sudden I am expected to look into EPEL packaging
> > matters. I still don't understand why I have become the assignee of
> > EPEL tickets and possibly EPEL packages, too, when I never asked for
> > that.
>
> I mentioned that in my emails, and people have repeatedly explained it
> to you here too.

Not yet. I've never signed up as the maintainer for EPEL packages.

>  I *also* mentioned in my email that if no one is
> responsible for them to your knowledge, the proper thing to do was to
> remove the branches, and provided you information on how to do so.

Why me? Why did the EPEL package collection contain unmaintained
packages? Is no cleanup done for EPEL to properly orphan/retire such
packages? Why would you ask a Fedora packager to do it rather than
somebody from the EPEL project? Nothing in bugzilla gives a hint that
I would be able to do it for EPEL. It was just out of coincidence that
I could touch the EPEL packages due to Provenpackager access. Again, I
am not an EPEL packager!

> This isn't a silo.  We're supposed to be working together, and helping
> each other.  Your responses of refusing to even consider answering
> questions about EPEL, replete condescension, and refusal to actually
> read what I (and others) have been saying continues to make this
> difficult.  Please stop.

This incident turns into a growingly unpleasant experience for me.
I've asked you to clean up the mess in bugzilla and reassign the EPEL
packages properly, because I am not responsible for those packages.
You've not done that. I've had to do it myself. Team work doesn't mean
that you assign tickets to me, which have been neglected/ignored for
almost five years. This isn't a hot-potato-dropping contest.

Re: Fedora pagure confusion wrt EPEL

[Michael Schwendt]

On Fri, 31 Jan 2020 at 18:11, Robbie Harwood  wrote:
>
> I could have also needinfo(Michael) (and in hindsight I probably should
> have), but based on their reaction, I don't think they would have been
> any happier with that.

I would have preferred private email over assigning multiple tickets
to me and causing bugzilla spam for all the ticket changes including
(!) multiple needinfo inquiries.

> Andreas Bierfert (awjb), who was recently declared non-responsive.

That could have been mentioned.
Is that when some process transferred EPEL packages to me without prior asking?

> My view is that there's an open security bug, so it's reasonable to want
> to know whether it's going to be fixed.

You consider it reasonable to look into ancient security issues after
almost five years? The related tracking bugs did serve no purpose for
almost five years?

> Someone responsible for another branch of the
> package should be able to check trivially - and is indeed the best
> person to ask, since they're the most locally knowledgeable.

As I've pointed out in private email, with proper reporting and
tracking of those CVEs, the CVE ids would be mentioned in the spec
%changelog of the Fedora package, where typically a much newer version
is packaged. If none of those security issues has been reported for
Fedora, it should be safe to assume that the Fedora packages have not
been deemed vulnerable.

> In communication with Michael, I did explain that if no one was
> responsible for these branches, they should retire the branches.
> Michael's view in that discussion seemed to be that the problem was one
> I had created, and therefore one I should fix.  (Michael can retire the
> branches while I, an unrelated contributor without ProvenPackager,
> cannot.)

As pointed out, I don't keep an eye on EPEL. I'm completely surprised
that all of a sudden I am expected to look into EPEL packaging
matters. I still don't understand why I have become the assignee of
EPEL tickets and possibly EPEL packages, too, when I never asked for
that.
___
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 pagure confusion wrt EPEL

[Michael Schwendt]

On Fri, 31 Jan 2020 at 00:56, Fabio Valentini  wrote:
>
>> > It seems the "support" in PkgDB was also a "lie", because BugZilla
>> > doesn't even support default assignees per-branch.
>>
>> It just worked, and when somebody opened a ticket about an EPEL package,
>> the EPEL-specific maintainer became the assignee _by default_. Whether
>> bugzilla knows a separate "default assignee" is beyond my interest,
>> unless somebody or some script reassigns tickets to me which are not of
>> my concern.
>
>
> Did you actually read what I wrote? I said "per branch maintainership" is not 
> supported, and never really was. But I explicitly wrote that you're able to 
> make a destinction between bug assignees for fedora and EPEL versions of your 
> package ...
>

You are talking in riddles then. Either bugzilla can handle different
assignees for EPEL and Fedora, or it can't. Even prior to pkgdb, we
had a list in cvs with different "package owners" for EPEL and Fedora,
and e.g. for rpmfusion I created a script that synced the data to
bugzilla, so we could create new components in bugzillla and update
them, too, simply by running a script periodically. It just worked.
EPEL package had different assignees than Fedora packages. And orphans
would be assigned to orphan owner appropriately.

> So what you want to achieve (not get bugs for EPEL component assigned to you) 
> still works today and will keep working, with UI for it on the way ...

As in the original email that starts this thread, I never signed up as
a maintainer for EPEL packages and don't want to become an assignee
(and/or "default assignee") for them either. In this mysterious pagure
webui I cannot even see what I'm assigned to and what fellow packagers
are assigned to. All I see for "claws-mail" is that there is only a
single "member", but I cannot see any data that would give hints about
what's up with the EPEL packages.
___
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 notifications bug: 404 Not Found

[Michael Schwendt]

On Fri, 31 Jan 2020 at 02:47, Kevin Fenzi  wrote:

> Can you provide more info?
> Was this an irc or email message?
> or was it in the git push?

It was an email notification.
___
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 pagure confusion wrt EPEL

[Michael Schwendt]

On Thu, 30 Jan 2020 23:57:03 +0100, Fabio Valentini wrote:

> Did you at least check if the packages were used by something else? ...

No, and that doesn't interest me at all. I am not doing EPEL packaging,
and I consider it inacceptable that somebody assigns five years old EPEL
tickets to me and expects me to handle the tickets as well as the packages.

> That's because per-branch maintainership is no longer "supported", as
> mentioned on recent other threads.

That doesn't sound good.

Is it anything final that has been communicated on devel-announce list
in a clear way? Or is it buried beneath hundreds to thousands of posts
on devel list?

> It seems the "support" in PkgDB was also a "lie", because BugZilla
> doesn't even support default assignees per-branch.

It just worked, and when somebody opened a ticket about an EPEL package,
the EPEL-specific maintainer became the assignee _by default_. Whether
bugzilla knows a separate "default assignee" is beyond my interest,
unless somebody or some script reassigns tickets to me which are not of
my concern.
___
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 pagure confusion wrt EPEL

[Michael Schwendt]

On Thu, 30 Jan 2020 14:44:50 +0100, Kevin Kofler wrote:

> Fabio Valentini wrote:
> > Until this functionality is merged into pagure's dist-git plugin, there is
> > a way, but it's a bit convoluted.

And it's too obscure. Instead, I just retired the two EPEL branches.

> And we have to do that for every single package we maintain? That is not 
> reasonable. It is Fedora policy that we cannot be forced to care about EPEL. 
> The software needs to actually implement that policy.

With pkgdb I could see who maintains which "branches" and which branches
exist. With this new web UI, I don't find where I could take a look at
who maintains which branch. For some packages I see socalled "members", a
"main admin", an "admin", people with "commit" access, but without any idea
who maintains which branches.

All this would not even interest me at all, but almost a week ago someone
from Red Hat Security decided it would be a good idea to assign to me
(without asking first) ancient EPEL tickets, which are almost five years (!)
old. Apparently, no proper tracking of those tickets has been done for a
very long time. It is entirely wrong and unexpected to assign those EPEL
tickets to me only because something under the hood knows only a default
assignee or such.
___
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

Fedora notifications bug: 404 Not Found

[Michael Schwendt]

No idea where to report these:


| Notification time stamped 2020-01-30 09:55:53 UTC
| 
| mschwendt pushed 1 commit to rpms/claws-mail (el6)
|   https://src.fedoraproject.org/rpms/claws-mail/branch/el6

Not Found

The requested URL was not found on the server. If you entered the URL manually 
please check your spelling and try again.


| Notification time stamped 2020-01-30 09:57:08 UTC
| 
| mschwendt pushed 1 commit to rpms/claws-mail (epel7)
|   https://src.fedoraproject.org/rpms/claws-mail/branch/epel7

Not Found

The requested URL was not found on the server. If you entered the URL
manually please check your spelling and try again.
___
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 pagure confusion wrt EPEL

[Michael Schwendt]

On Thu, 30 Jan 2020 12:23:01 +0300, Vascom wrote:

> No way.
> You can add comaintainer for EPEL builds of your packages.

That can't be right.

Who has made me the "owner" of claws-mail in EPEL? And why?

https://fedoraproject.org/wiki/EPEL/FAQ#I_maintain_a_package_in_Fedora._Do_I_have_to_maintain_it_for_EPEL_now.2C_too.3F
___
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

Fedora pagure confusion wrt EPEL

[Michael Schwendt]

I don't do EPEL packaging. I never signed up as an "owner" of EPEL packages.
I don't want to be the new default owner of EPEL bugzilla tickets.
Where may I be able to stop this mess?

___
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: peek package

[Michael Schwendt]

On Sat, 4 Jan 2020 08:36:07 +0100, Vitaly Zaitsev via devel wrote:

> > Which is something you can only fix with an RPM Fusion package,
> > if you "control" (= build) all depending packages.  
> 
> RPM Fusion will need to copy and rebuild all such packages and this is a
> huge headache for maintainers and currently forbidden by repo's policy.

And yet it would be the only way to do it for some applications
and/or libraries. That said, as an ex-livna packager I'm aware of the
project goals, so it isn't necessary to refer to the current "policy".
___
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: peek package

[Michael Schwendt]

On Fri, 3 Jan 2020 16:30:54 +0100, Vitaly Zaitsev via devel wrote:

> On 03.01.2020 11:14, Michael Schwendt wrote:
> > What sort of "huge headache" would that be?  
> 
> 1. Most of ffmpeg-capable applications use compile-time checks for
> available codecs presence.

Which is something you can only fix with an RPM Fusion package,
if you "control" (= build) all depending packages.

> 2. Sync errors between repositories like chromium and
> chromium-libs-media-freeworld.

Not any more "headaches" than ordinary add-on packages in a 3rd party repo
with dependencies in the base dist repo(s).

> > Third party repos like RPM Fusion can still use package Epoch to replace 
> > base distribution packages.  
> 
> RPM Fusion strictly forbid this.

And yet it would create less problems than conflicting replacement packages.
___
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: peek package

[Michael Schwendt]

On Fri, 3 Jan 2020 12:14:37 +0100, Dominik 'Rathann' Mierzejewski wrote:

> > > > I suspect there would be interest in having a royalty free version of 
> > > > FFMPEG
> > > 
> > > No, please, don't do this. It will be a huge headache for RPM Fusion
> > > maintainers.  
> > 
> > What sort of "huge headache" would that be? Third party repos like RPM 
> > Fusion
> > can still use package Epoch to replace base distribution packages.  
> 
> We have a strict policy of not doing that.

Which implies that the "huge headache" is self-induced.

This has been discussed years ago already for various 3rd party repos, who
did override base dist packages. The policy could be less strict with
regard to add-on packages, which would duplicate a Fedora dist package and
fork it with more features built in.

No need to do that for core system libs like glibc, but sometimes it
would reduce the maintenance requirements. For some apps and libs the
feature set cannot be completed via add-ons/plugins. And RPM Fusion replaces
some base dist packages via conflicts anyway in some cases. Example:
audacity-freeworld vs. audacity

> We do try to maintain add-on
> and alternative packages like chromium-libs-media-freeworld (alternative
> for chromium-libs-media built with all codecs) which is a headache to
> maintain in sync with Fedora's chromium.

Anything with inter-dependencies requires some maintenance. Forked
"alternative packages", which implicitly or explicitly conflict with base
dist packages, don't reduce the maintenance requirements.
___
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: peek package

[Michael Schwendt]

On Thu, 2 Jan 2020 13:07:40 +0100, Vitaly Zaitsev via devel wrote:

> On 02.01.2020 10:05, Benson Muite wrote:
> > I suspect there would be interest in having a royalty free version of 
> > FFMPEG  
> 
> No, please, don't do this. It will be a huge headache for RPM Fusion
> maintainers.

What sort of "huge headache" would that be? Third party repos like RPM Fusion
can still use package Epoch to replace base distribution packages.
___
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: peek package

[Michael Schwendt]

On Thu, 2 Jan 2020 11:24:08 +, Tom Hughes wrote:

> Actually I believe PACKAGENAME-maintainers@ (with an s) is now the
> preferred form and -owner is regarded as deprecated.

Is this documented _anywhere_?

The following page still mentions the -owner alias
  https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb
and would be a good place where to mention a switch to something else.
___
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: peek package

[Michael Schwendt]

On Thu, 02 Jan 2020 10:02:25 +, Mattia Verga via devel wrote:

> In my original post I had CC'ed `peek-maintai...@fedoraproject.org` and 
> I supposed this would have reached you directly. I did not know this 
> isn't working anymore (I later received an unreachable address in 
> reply). So I didn't "sneaky ask" anything.

It has _never_ worked before, because it is PACKAGENAME-owner@ instead.
___
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: What's up with GStreamer 0.10 in F31?

[Michael Schwendt]

On Tue, 5 Nov 2019 at 15:07, Fabio Valentini wrote:
>
> >   
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages
>
> Note that these Guidelines explicitly only apply to *renaming* and
> *replacing*existing packages, not the plain removal / retirement of
> packages.
> gstreamer1-foo doesn't replace gstreamer-foo, so Obsoleting it is not
> the correct thing anyway.

I disagree. GStreamer 1.x is the successor of GStreamer 0.10.x, which
has been kept alive out of convenience and to allow for a long-term
migration of dependencies to GStreamer 1.x. Technically, GStreamer 1.x
replaces GStreamer 0.10.x as an upgrade, particularly if dropping the
latter from the distribution. For that it doesn't need to be API/ABI
compatible, and the fact that both have been parallel installable for
some time is entirely unrelated.

Btw, even the retirement commit messages said "Obsoleted by 1.0 version":
https://src.fedoraproject.org/rpms/gstreamer/c/80b168e5f2038409d9b5f6b78ab5b48e006a4942?branch=master

> Arguably, the only reasonable thing would be to add gstreamer-foo to
> fedora-obsolete-packages, and only if any of the retired packages
> would cause issues during or after the upgrade to the affected fedora
> release.

That has not been done either.
___
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: What's up with GStreamer 0.10 in F31?

[Michael Schwendt]

On Tue, 5 Nov 2019 13:52:00 +0100, Miro Hrončok wrote:

> gstreamer was retired
> https://src.fedoraproject.org/rpms/gstreamer/c/21fd6753e6c7f1fa1dee1045596b25fdb8c71f37?branch=f31
> 
> the commit was reverted
> https://src.fedoraproject.org/rpms/gstreamer/c/1ce6b77242c27c450179e32a2fc7833300aa8759?branch=f31
> 
> But the package was never unretired or rebuilt.

That can't be the full story. Why has the GStreamer 0.10.x framework been
removed without checking for dependency breakage and without warning packagers
about it? All I can see is that releng has rebuilt the packages during the F31
cycle, and later the build dependencies have been removed from the dist, so
the packages cannot even be rebuilt anymore.

Currently, no gstreamer1* package contains Obsoletes tags that would
retire those packages properly. It seems to me that the guidelines have
not been followed at all:

  
https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages


Information for RPM gstreamer1-plugins-base-1.16.1-1.fc31.x86_64.rpm
Obsoletes   No Obsoletes

https://koji.fedoraproject.org/koji/rpminfo?rpmID=19158674
Obsoletes   No Obsoletes

Information for RPM gstreamer1-plugins-good-1.16.1-2.fc31.x86_64.rpm
Obsoletes   gstreamer1-plugin-mpg123 < 1.13.1
___
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

What's up with GStreamer 0.10 in F31?

[Michael Schwendt]

On Wed, 25 Sep 2019 10:45:45 +0200, Kalev Lember wrote:

> On 9/24/19 14:50, Michael Catanzaro wrote:
> > On Thu, Aug 22, 2019 at 9:04 am, Tom Callaway wrote:  
> >> or know of some reason it shouldn't be brought back  
> > 
> > Well this looks like gstreamer 0.10. I'm really surprised we still have 
> > this in the distro. It's been obsolete for the better part of a decade 
> > and is probably filled with security bugs. I remember openSUSE got rid 
> > of its 0.10 packages 5+ years ago.
> > 
> > Why not let it die? Whatever is using it surely needs to go.  
> 
> I second to that. I think it's time to let gstreamer 0.10 get removed 
> from the distro.

What has happened here?

It seems GStreamer 0.10 has been removed from F31 prior to release, but
only partially, breaking dependencies, leaving behind packages that
cannot be installed. And packagers have not been warned/informed either.


# dnf install gstreamer-plugins-base
Last metadata expiration check: 0:06:09 ago on Tue 05 Nov 2019 13:07:19 CET.
Error: 
 Problem: conflicting requests
  - nothing provides libgstbase-0.10.so.0 needed by 
gstreamer-plugins-base-0.10.36-24.fc31.i686
  - nothing provides libgstcontroller-0.10.so.0 needed by 
gstreamer-plugins-base-0.10.36-24.fc31.i686
  - nothing provides libgstdataprotocol-0.10.so.0 needed by 
gstreamer-plugins-base-0.10.36-24.fc31.i686
  - nothing provides libgstreamer-0.10.so.0 needed by 
gstreamer-plugins-base-0.10.36-24.fc31.i686
  - nothing provides gstreamer >= 0.10.36 needed by 
gstreamer-plugins-base-0.10.36-24.fc31.i686
  - nothing provides libgstreamer-0.10.so.0()(64bit) needed by 
gstreamer-plugins-base-0.10.36-24.fc31.x86_64
  - nothing provides libgstbase-0.10.so.0()(64bit) needed by 
gstreamer-plugins-base-0.10.36-24.fc31.x86_64
  - nothing provides libgstcontroller-0.10.so.0()(64bit) needed by 
gstreamer-plugins-base-0.10.36-24.fc31.x86_64
  - nothing provides libgstdataprotocol-0.10.so.0()(64bit) needed by 
gstreamer-plugins-base-0.10.36-24.fc31.x86_64
  - nothing provides gstreamer >= 0.10.36 needed by 
gstreamer-plugins-base-0.10.36-24.fc31.x86_64
  - nothing provides libgstbase-0.10.so.0 needed by 
gstreamer-plugins-base-0.10.36-18.fc27.i686
  - nothing provides libgstcontroller-0.10.so.0 needed by 
gstreamer-plugins-base-0.10.36-18.fc27.i686
  - nothing provides libgstdataprotocol-0.10.so.0 needed by 
gstreamer-plugins-base-0.10.36-18.fc27.i686
  - nothing provides libgstreamer-0.10.so.0 needed by 
gstreamer-plugins-base-0.10.36-18.fc27.i686
  - nothing provides gstreamer >= 0.10.36 needed by 
gstreamer-plugins-base-0.10.36-18.fc27.i686
  - nothing provides libgstreamer-0.10.so.0()(64bit) needed by 
gstreamer-plugins-base-0.10.36-18.fc27.x86_64
  - nothing provides libgstbase-0.10.so.0()(64bit) needed by 
gstreamer-plugins-base-0.10.36-18.fc27.x86_64
  - nothing provides libgstcontroller-0.10.so.0()(64bit) needed by 
gstreamer-plugins-base-0.10.36-18.fc27.x86_64
  - nothing provides libgstdataprotocol-0.10.so.0()(64bit) needed by 
gstreamer-plugins-base-0.10.36-18.fc27.x86_64
  - nothing provides gstreamer >= 0.10.36 needed by 
gstreamer-plugins-base-0.10.36-18.fc27.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
___
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 to be retired (~400 during this week)

[Michael Schwendt]

On Mon, 9 Sep 2019 23:49:17 +0200, Miro Hrončok wrote:

> Request package ownership via releng issues:
> https://pagure.io/releng/issues

How?
___
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: Undelivered Mail Returned to Sender

[Michael Schwendt]

On Sun, 24 Feb 2019 11:50:45 +0100, Dridi Boukelmoune wrote:

> >The mail system
> >
> >  (expanded from ): 
> > connect
> > to mail1.ATrpms.net[160.45.254.20]:25: Connection refused  
> 
> That's unfortunate, I was hoping to discuss this this the apt-rpm
> downstream maintainers, but no response from them so far.
> 
> The weird thing in the email is that AT right after the @ symbol which
> looks like a copy-paste-edit mistake. Does anyone know how to contact
> Axel Thimm?

Nothing weird with that, since AT are his initials, and "ATrpms" at atrpms.net
has been his RPM packages project for (many) years.
___
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: Problem with portaudio linking

[Michael Schwendt]

On Fri, 4 Jan 2019 10:41:46 +0100, Michal Ruprich wrote:

> Hi,
> 
> has anyone encountered a problem on F28 when building a package that
> uses portaudio? I was building newer version of wireshark a month ago
> and -lportaudio worked fine. Now the build with the same version fails
> with message 'checking for Pa_Initialize in -lportaudio... no' and
> 'configure: error: Linking with libportaudio failed'. The build still
> works on F29 and in Rawhide, only F28 hits this issue. Anyone else has
> seen this happening?

Have you tried a build with

  %configure || cat config.log

to check why the library linking test has failed?
___
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: Self Introduction: J."MUFTI" Scheurich

[Michael Schwendt]

On Mon, 10 Dec 2018 11:25:55 +0100, J. Scheurich wrote:

> https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Introduce_yourself
> 
> | When a new package maintainer joins the Fedora Project, we request 
> that he/she introduces
> | themselves on the Fedora devel 
>  
> mailing list.
> 
> I am a programmer/maintainer of white_dune ( 
> http://wdune.ourproject.org/ ) and i am trying to
> include it into fedora.
> 
> I got the following mail
> 
> basset  has sponsored you for membership in 
> the cla_fpca
> group of the Fedora account system. If applicable, this change should
> propagate into the e-mail aliases and git repository within an hour.
> 
> 
> but i don't know, if it is sufficent to build a fedora package.

Have you been sponsored as part of the package review process?
If so, the Wiki tells how to proceed when the package has been approved:
https://fedoraproject.org/wiki/Package_Review_Process
___
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: please help retire libocrdma

[Michael Schwendt]

On Tue, 6 Nov 2018 21:48:16 +0800, Honggang LI wrote:

> hi,
> 
> libocrdma had been merged into rdma-core in upstream, so libocrdma is
> obsoleted by rdma-core.
> 
> The package owner Selvin tried to retire this package, but failed
> with authentication.
> 
> We need someone who manages/maintains fedora package repos to retire
> libocrdam for us.

It has been retired 8 hours ago:

https://src.fedoraproject.org/rpms/libocrdma/commits/master
and
https://src.fedoraproject.org/rpms/libocrdma/blob/master/f/dead.package
___
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: Unretire recordmydesktop

[Michael Schwendt]

On Sun, 4 Nov 2018 12:17:00 +, Richard W.M. Jones wrote:

> recordmydesktop was retired in F27:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4RCB6MBC4JVGG4SYLIKUDOOT2REGA6N4/
> 
> It's claimed that it doesn't work and is full of crash bugs, but I was
> able to compile it on F29 and it works fine for me, and it's a very
> useful little tool.

Quoting https://bugzilla.redhat.com/1538352#c1

| Yes, recordmydesktop was intentionally retired due to the project being
| abandoned (no new release in 10 years), it contained many crash bugs,
| and was not at all working on Wayland.

There are various WONTFIX and EOL issues tracked in bugzilla. Bringing
back the package without going through those tickets first doesn't sound
like a good idea.
___
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 Self-Contained Change: GnuTLS enables TLS 1.3 by default

[Michael Schwendt]

On Wed, 26 Sep 2018 09:20:30 -0600, Nathanael D. Noblet wrote:

> I get what I think is a similar error with the google 'Online accounts'
> 
> I get a certificate error. The message is:
> 
> "No SNI provided; please fix your client."
> 
> Would this be a related issue?

Yes. If Google hands out certificates for other secure services in the
same way as it does on its IMAP servers, any other TLS based client will
need to be developed further.
___
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 Self-Contained Change: GnuTLS enables TLS 1.3 by default

[Michael Schwendt]

On Mon, 24 Sep 2018 11:27:49 +0200, Florian Weimer wrote:

> Actually, I assume Google simply made a mistake here.  But this is
> getting off-topic.

As I've mentioned in the Fedora bugzilla ticket, pointing at the gnutls
API is not a solution. libetpan upstream would appreciate a pull request.

  https://github.com/dinhviethoa/libetpan/issues/258#issuecomment-423823453

Patching Claws Mail won't be enough.
___
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 Self-Contained Change: GnuTLS enables TLS 1.3 by default

[Michael Schwendt]

On Sat, 22 Sep 2018 16:32:07 -0500, mcatanzaro gnome org wrote:

> You'll need to add a call to gnutls_server_name_set(), see:
> 
> https://www.gnutls.org/manual/gnutls.html#Server-name-indication

That an update for SNI may be required is clear, but it doesn't answer
the question where a change will be needed.

> The problem is explained quite well in the other linked bug:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1611815

No, it isn't, because fetchmail doesn't use gnutls. Claws Mail does,
and additionally it is based on libetpan, which uses gnutls
internally, too.
___
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 Self-Contained Change: GnuTLS enables TLS 1.3 by default

[Michael Schwendt]

On Wed, 18 Jul 2018 17:26:06 -0400, Ben Cotton wrote:

> This change enables TLS 1.3 (draft28) support on the gnutls crypto library.

> == Upgrade/compatibility impact ==
> That change should have no impact on upgrade or compatibility. The TLS
> 1.3 protocol is designed in a way that does not cause incompatibility
> issues with existing (and even broken) implementations.

> == User Experience ==
> That change should not be noticeable by users except for applications
> which report the connected protocol.

Apparently, this change breaks Google Mail IMAP for Claws Mail.
https://bugzilla.redhat.com/1629151
___
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: Nonresponsive maintainer: Luke Macken (lmacken)

[Michael Schwendt]

On Thu, 16 Aug 2018 16:13:07 +0200, Miro Hrončok wrote:

> On 16.8.2018 16:11, Dusty Mabe wrote:
> > 
> > 
> > On 08/16/2018 07:29 AM, Miro Hrončok wrote:  
> >> Luke Macken (lmacken) is not responsive.
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1610474
> >>
> >> Anyone knows how to contact the maintainer?
> >>  
> > 
> > ping him on twitter? https://twitter.com/lmacken  
> 
> 
> https://twitter.com/hroncok/status/1030095001064271877

His twitter page says "Former @Fedora developer" though.
___
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/APZZS5AP3OTGBGQRRSKG3RQIT5Q5NHHZ/

Re: Compilation issue after gcc removal

[Michael Schwendt]

On Fri, 20 Jul 2018 01:08:55 +0200, Marcin Zajączkowski wrote:

> On 2018-07-20 00:26, Artur Iwicki wrote:
> > I looked at libattr and in the changelog, there's this:  
> >> * Tue Jul 17 2018 Kamil Dudka  2.4.48-3
> >> - temporarily provide attr/xattr.h symlink until users are migrated 
> >> (#1601482)  
> > 
> > The bugzilla ticket says that attr/xattr.h was removed from libattr and is 
> > now a symlink to sys/xattr.h. Taking a look at those two files, the old 
> > attr/xattr.h has these lines in it:  
> >> #ifndef ENOATTR
> >> # define ENOATTR ENODATA/* No such attribute */
> >> #endif  
> > These are absent in sys/xattr.h, so the compiler rightfully complains that 
> > it does not know of ENOATTR. I guess you should either add a patch that 
> > replaces usages of ENOATTR to ENODATA, or a patch that adds this define 
> > somewhere.  
> 
> Thanks Artur for your findings! Trying to report that problem upstream I
> founded this thread: https://github.com/iustin/pyxattr/pull/15
> 
> I will give it a few days to work out some general way to solve it.

The fix is valid. It also affects other projects.
For reference:
http://git.savannah.nongnu.org/cgit/attr.git/commit/?id=7921157890d07858d092f4003ca4c6bae9fd2c38
___
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/M6FZOBL7LKNOMMEJBERIDIOMDNX3JWQH/

audiofile package to become an orphan

[Michael Schwendt]

When I picked up the package in 2015, the upstream maintainer(s) apparently
had stopped the maintenance already. Meanwhile, there have been a few CVEs
and other fixes that have been ignored upstream. Recently, another CVE has
been assigned to an issue, and there isn't any upstream interest either.
___
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/DWV2ZWNYJH4IJXOHIIWV6WKHZNXCHLV6/

Notifications about "builds started to fail in Fedora rawhide"

[Michael Schwendt]

Can the service that creates these notifications be improved to include
an excerpt of the problems that cause a build to fail?

[...]

Begin forwarded message:

Date: Fri,  1 Jun 2018 23:37:57 + (UTC)
From: notifications fedoraproject org
Subject: claws-mail's builds started to fail in Fedora rawhide


Notification time stamped 2018-06-01 23:37:54 UTC

claws-mail's builds started to fail in Fedora rawhide
https://apps.fedoraproject.org/koschei/package/claws-mail?collection=f29
___
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/6WBV57WLA7QCS6YWYVVE7PATJ3JRTGBZ/

Re: The update system has the wrong package

[Michael Schwendt]

On Tue, 29 May 2018 16:54:00 -0400, Steve Dickson wrote:

> Hello,
> 
> I'm trying to update the rpcsvc-proto package. 
> When I try to create a new update, the system
> only gives me rpcsvc-proto-devel as a choice
> not rpcsvc-proto.
> 
> Where do I open up a ticket to get this taken 
> care of? 

Koji doesn't display any update for F28 or older, so which candidate
build do you refer to? For Rawhide F29 you don't need to file update
tickets in bodhi.
___
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/7QALKDQVCMW4IUJF6ELG2RCBO3W6TROM/

Re: greenwave is a GO on ampache_browser-1.0.0-3.20180408.fc27 for "bodhi_update_push_stable" (fedora-28)

[Michael Schwendt]

On Sun, 8 Apr 2018 13:46:55 +0200, Michael Schwendt wrote:

> Please make such a message flood opt-in by default instead of opt-out.
> The communication about such new services and their purpose is extremely
> poor IMO.

There is not even a contact address on the page!
Only a cryptic table. No documentation.
16 messages, each looking the same, for two builds.

> greenwave is a GO on ampache_browser-1.0.0-3.20180408.fc27 for 
> "bodhi_update_push_stable" (fedora-28)
>   
> https://taskotron.fedoraproject.org/resultsdb/results?item=ampache_browser-1.0.0-3.20180408.fc27=koji_build
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fw: fedmsg notification

[Michael Schwendt]

Please make such a message flood opt-in by default instead of opt-out.
The communication about such new services and their purpose is extremely
poor IMO.

[...]

Begin forwarded message:

Date: Sat,  7 Apr 2018 23:42:01 + (UTC)
From: notifications fedoraproject org
Subject: fedmsg notification



https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/upstream-fedora-pipeline-trigger/detail/upstream-fedora-pipeline-trigger/8682/pipeline/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fw: greenwave is a GO on ampache_browser-1.0.0-3.20180408.fc27 for "bodhi_update_push_stable" (fedora-28)

[Michael Schwendt]

Please make such a message flood opt-in by default instead of opt-out.
The communication about such new services and their purpose is extremely
poor IMO.

[...]

Begin forwarded message:

Date: Sat,  7 Apr 2018 23:59:31 + (UTC)
From: notifications fedoraproject org
Subject: greenwave is a GO on ampache_browser-1.0.0-3.20180408.fc27 for 
"bodhi_update_push_stable" (fedora-28)


greenwave is a GO on ampache_browser-1.0.0-3.20180408.fc27 for 
"bodhi_update_push_stable" (fedora-28)

https://taskotron.fedoraproject.org/resultsdb/results?item=ampache_browser-1.0.0-3.20180408.fc27=koji_build
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best way to handle sub-package conflicts

[Michael Schwendt]

On Sun, 18 Mar 2018 12:44:37 -0400, Digimer wrote:

>   I think "Conflict" is the way to go. However, given how much the guide
> urges not to use 'Conflicts', I worry that will make it
> harder/impossible later to have the package accepted into Fedora.
> 
>   Would a use-case like this be an acceptable exception, would you guess?
> 
>   As I mentioned in my reply to Micheal, I am not worried about
> auto-removal. If it simply refused to install one sub-package until the
> other is gone, that's fine.

There are runtime solutions, such as using "alternatives", which you may
need to use to get such packages accepted into the Fedora package
collection.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best way to handle sub-package conflicts

[Michael Schwendt]

On Sun, 18 Mar 2018 11:22:23 -0400, Digimer wrote:

> So the .spec creates four RPMs; "anvil-core", "anvil-striker",
> "anvil-node" and "anvil-dr".
> 
> All machines require "anvil-core", plus one (and only one) of the other
> three packages. There is no scenario where, for example, 'anvil-node'
> and 'anvil-striker' would be installed on the same machine. So if a user
> has 'anvil-striker' RPM installed, and they try to install 'anvil-node',
> I want that to remove 'anvil-striker'. Similarly, if a machine has
> 'striker-node' already installed and the user tries to install
> 'anvil-dr', I want 'anvil-node' removed. This is because a single
> machine can only play one role at a time.
> 
> So this isn't a version conflict, as seems to be what Conflicts and
> Obsoletes are designed to handle, if I understand properly.

The description of the packaging scenario is not complete yet.
If -striker, -node and -dr are mutually exclusive, why is that?
Are there implicit conflicts in the packaged files? Then you cannot
avoid Conflicts tags. Or are there runtime conflicts? Then you should
look into a solution that would resolve the conflict with a configuration
file, which would define the operation mode of the software.

So far, the scenario sounds very much as if you want to add Conflicts tags
to the subpackages as to achieve that only one of them can be
installed. Trying to simulate automatic removal of conflicts through
Obsoletes tags is not the right thing to do in your scenario. You would
end up with circular Obsoletes, which would confuse depsolvers or lead
to random behavior.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Best way to handle sub-package conflicts

[Michael Schwendt]

On Sun, 18 Mar 2018 10:22:49 -0400, Digimer wrote:

> Hi all,
> 
>   I am creating a new RPM package for a cluster project we've created.
> There is a common "core" package, and then three other packages that are
> installed depending on the machine's role in the cluster;
> 
> foo-core
> foo-A
> foo-B
> foo-C
> 
>   If 'foo-A' is installed, I want 'foo-B' and 'foo-C' to be removed, and
> 'foo-B' replaces 'foo-A' and 'foo-C', etc. I originally planned to use
> 'Conflicts: ' in our spec, but reading this:
> 
> https://fedoraproject.org/wiki/Packaging:Conflicts
> 
>   It seems like 'Conflicts' is strongly discouraged. So instead I tried
> 'Obsoletes', and this seemed to work in that, if 'foo-A' was installed
> and I tried to install 'foo-B', it would remove 'foo-A'. So I thought I
> was ok, until I bumped the version and tried to to an update. With
> 'foo-A' installed, it wanted to install 'foo-B' and 'foo-C' and failed,
> which makes sense now that I think of it.
> 
>   What is the best way to handle this in the .spec file? I'm having
> trouble finding the right term to search form.

Could you proof-read your mail and correct the update scenario?
First you wanted foo-A to replace foo-B and foo-C. Next you write that
foo-B replaces foo-A and foo-C. Something's wrong in your description.
Under normal circumstances, a subpackage would never replace a
package with a different %name.

Better split your packaging scenario in two clear parts:
1) The packages that have been published before and which you start with.
Describe them and their inter-package dependencies.
2) The set of packages you want to continue with after a major upgrade
that replaces/removes packages. Describe them and their inter-package
dependencies.

Obsoletes tags usually are versioned, so they only remove older packages
up to a maximum version. That way you can reintroduce packages in the future.
If you keep building subpackages you've obsoleted before, they remain
available to be installed, and you would need to increase the version in
your Obsoletes tags to cover them. Nevertheless, subpackages with
different names would never replace eachother. Unless you've added
Obsoletes tags to do that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 FTBFS bugs?

[Michael Schwendt]

On Thu, 15 Mar 2018 11:01:00 +0100, Daiki Ueno wrote:

> 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.

Those tickets are misleading and would have deserved a better
explanation. At some point, builds have failed for unknown reasons (and
the logs have expired already, so one cannot examine them anymore), and
therefore builds may still be missing within koji if no later build has
completed successfully.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

librsvg2 CVEs

[Michael Schwendt]

Why are CVEs about librsvg2 not being tracked within the package?
Bugzilla shows several CLOSED EOL and a few current ones not mentioned
within the package %changelog.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

> The example in "man encrypt" is the culprit. It extracts the bits from
> each byte upwards into the bit vector, i.e. offset 0 = bit 0 from byte 0,
> offset 1 = bit 1 from byte 0, offset 2 = bit 2 from byte 0 and so on.
> 
> If doing it as in the Claws Mail source code, the ciphertext is the same
> for all three DES APIs. Claws Mail unpacks the bits in decreasing (!) order.
> 
> That looks promising.

The following patch would be one solution:
https://mschwendt.fedorapeople.org/claws-mail-3.16.0-encrypt-nettle.patch
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Mon, 12 Mar 2018 13:12:49 +0100, Michael Schwendt wrote:

> On Fri, 9 Mar 2018 16:32:17 +0100, Florian Weimer wrote:
> 
> > GnuTLS uses Nettle, but does not provide access to DES.  You can use 
> > Nettle directly:
> > 
> > https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES
> > 
> > OpenSSL will work as well, but as Nettle is a preexisting dependency, 
> > it's probably the right choice here.  
> 
> They don't seem to be compatible.
> 
> Whereas Nettle is fully compatible with glibc's rpc/des_crypt.h API, it
> offers a completely different interface than encrypt(), which operates on
> arrays of 64 bytes for each 64-bit block of input.
> 
> The ciphertext returned by encrypt() differs compared with Nettle and
> des_crypt (and that's with the bit vector transformation from the man page).

The example in "man encrypt" is the culprit. It extracts the bits from
each byte upwards into the bit vector, i.e. offset 0 = bit 0 from byte 0,
offset 1 = bit 1 from byte 0, offset 2 = bit 2 from byte 0 and so on.

If doing it as in the Claws Mail source code, the ciphertext is the same
for all three DES APIs. Claws Mail unpacks the bits in decreasing (!) order.

That looks promising.

$ ./encrypt 
passkey = passkey0
Before encrypting: eggplant
After encrypting:  fd 1a 5d 03 ad e5 a6 c2 
After decrypting:  eggplant
$ ./des_crypt
passkey = passkey0
Before encrypting: eggplant
After encrypting:  fd 1a 5d 03 ad e5 a6 c2 
After decrypting:  eggplant
$ ./nettle 
passkey = passkey0
Before encrypting: eggplant
After encrypting:  fd 1a 5d 03 ad e5 a6 c2 
After decrypting:  eggplant
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Fri, 9 Mar 2018 16:32:17 +0100, Florian Weimer wrote:

> GnuTLS uses Nettle, but does not provide access to DES.  You can use 
> Nettle directly:
> 
> https://www.lysator.liu.se/~nisse/nettle/nettle.html#DES
> 
> OpenSSL will work as well, but as Nettle is a preexisting dependency, 
> it's probably the right choice here.

They don't seem to be compatible.

Whereas Nettle is fully compatible with glibc's rpc/des_crypt.h API, it
offers a completely different interface than encrypt(), which operates on
arrays of 64 bytes for each 64-bit block of input.

The ciphertext returned by encrypt() differs compared with Nettle and
des_crypt (and that's with the bit vector transformation from the man page).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Fri, 9 Mar 2018 16:14:39 +0100, Florian Weimer wrote:

> On 01/29/2018 03:38 PM, Michael Schwendt wrote:
> > The reason why I ask is that Claws Mail still uses encrypt() with the sole
> > purpose of being able to decrypt old passwords. It doesn't convert them to
> > different encryption algorithms automatically, unless the user changes the
> > password, and it doesn't force the user to set a Master Password either.
> > Only the latter would add security since Claws Mail 3.14.0 (2016), which
> > added that as a new feature.  
> 
> Which cryptographic library does Claws Mail use to implement the other 
> encryption algorithm?

GnuTLS
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Mon, 29 Jan 2018 15:38:00 +0100, Michael Schwendt wrote:

> On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:
> 
> > = System Wide Change: Replace glibc's libcrypt with libxcrypt =
> > https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
> > 
> > Change owner(s):
> > * Björn Esser 
> > * Florian Weimer 
> > 
> > There are plans to remove libcrypt from glibc, so we should have a 
> > replacement.
> >   
> 
> Please clarify what exactly the plan is.
> 
> To replace libcrypt with a compatible library and with a grace period for
> apps to stop using deprecated functions that may be removed in the future?
> 
> Or to replace libcrypt with an incompatible library immediately with no
> grace period?
> 
> 
> The reason why I ask is that Claws Mail still uses encrypt() with the sole
> purpose of being able to decrypt old passwords. It doesn't convert them to
> different encryption algorithms automatically, unless the user changes the
> password, and it doesn't force the user to set a Master Password either.
> Only the latter would add security since Claws Mail 3.14.0 (2016), which
> added that as a new feature.

I had hoped there would be a response to this.
Another try with the two change owners in Cc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Appstream metadata compose failures

[Michael Schwendt]

On Sat, 03 Mar 2018 19:42:48 +0100, Kevin Kofler wrote:

> PS:
> 
> I wrote:
> 
> > Richard Hughes wrote:  
> >> 64x64 is a very low bar indeed, compared to all of the other
> >> platforms, e.g. Windows Store or the Apple AppStore.  
> > 
> > All that's going to happen with such a requirement is that specfiles are
> > going to run the icon through scale2x or hq2x if you're lucky, through a
> > dumb ImageMagick convert resize if you're not.  
> 
> … or in the worst case, they will just do nothing and AppStream will keep 
> ignoring the application, which is sadly the current status quo for many 
> packages.

This new opt-in style has never been a good idea. The software features
an "All" button, which doesn't show all packages, which is misleading.

And then there's category "Communication & News", and an Email client is
stored within the "Chat" subcategory. Ouch.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Appstream metadata compose failures

[Michael Schwendt]

On Fri, 02 Mar 2018 16:11:23 +0100, Kevin Kofler wrote:

> Richard Hughes wrote:
> > 64x64 is a very low bar indeed, compared to all of the other
> > platforms, e.g. Windows Store or the Apple AppStore.  
> 
> All that's going to happen with such a requirement is that specfiles are 
> going to run the icon through scale2x or hq2x if you're lucky, through a 
> dumb ImageMagick convert resize if you're not.
> 
> You cannot expect the packager to draw a new icon for upstream software.

One cannot even expect upstream to ship appdata files. The Claws Mail
developers have had some in their tarball for short time for every
plugin, then have dropped them again in the next minor release.
Probably due to maintenance overhead and missing translations.
http://git.claws-mail.org/?p=claws.git;a=tree;f=appdata;hb=HEAD
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Michael Schwendt]

On Thu, 8 Feb 2018 18:39:19 +0100, Petr Stodulka wrote:

> > The following:
> > %files
> > /some/directory/
> > 
> > is equivalent to:
> > %files
> > %dir /some/directory
> > /some/directory/*
> > 
> > 
> > There's nothing wrong here.
> > 
> >   
> 
> Exactly. IMHO, use of %dir macro for "top" pkg directories is more clean 
> solution, but
> doesn't matter in case the rpm is packaged correctly.

That makes no sense, if you restrict yourself to a "top" directory.
It could be a huge tree with lots of subdirectories. How would you
package it then? With explicit %dir everywhere? Or with %dir only for
the "top" directory?

Including complete directory trees with

  /foo/bar/

is fine and clean and is an advertised solution for many years.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please review use /$ in %files (Was: Re: Escaping macros in %changelog)

[Michael Schwendt]

On Thu, 8 Feb 2018 18:09:25 +, Tomasz Kłoczko wrote:

> I'm sure that in the past it was difference here :|

You are mistaken about that.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaned packages seeking new point of contact

[Michael Schwendt]

On Mon, 5 Feb 2018 07:42:45 -0500, Josh Boyer wrote:

> >> rpms/gqview  
> >
> > Really?!  
> 
> Congratulations, you have just explained why absentee maintainers are
> bad and why we orphan things.

No. I've only shown how surprised I am to discover that it is an orphan
in the Fedora package collection for many years. Or that maybe somebody
has adapted it despite the dead.package message I had added many years
ago:

  https://src.fedoraproject.org/cgit/rpms/gqview.git/plain/dead.package

Till Maas has found the culprit apparently.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Orphaned packages seeking new point of contact

[Michael Schwendt]

On Fri, 2 Feb 2018 10:32:33 -0800, Kevin Fenzi wrote:

> rpms/gqview

Really?!

It is unmaintained for over 10 years.

It has been forked into Geeqie (package "geeqie") roughly 10 years
ago, and Geeqie at least has seen several releases since then.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Replace glibc's libcrypt with libxcrypt

[Michael Schwendt]

On Tue, 9 Jan 2018 18:46:06 +0100, Jan Kurik wrote:

> = System Wide Change: Replace glibc's libcrypt with libxcrypt =
> https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
> 
> Change owner(s):
> * Björn Esser 
> * Florian Weimer 
> 
> There are plans to remove libcrypt from glibc, so we should have a 
> replacement.
> 

Please clarify what exactly the plan is.

To replace libcrypt with a compatible library and with a grace period for
apps to stop using deprecated functions that may be removed in the future?

Or to replace libcrypt with an incompatible library immediately with no
grace period?


The reason why I ask is that Claws Mail still uses encrypt() with the sole
purpose of being able to decrypt old passwords. It doesn't convert them to
different encryption algorithms automatically, unless the user changes the
password, and it doesn't force the user to set a Master Password either.
Only the latter would add security since Claws Mail 3.14.0 (2016), which
added that as a new feature.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: GCC broken in rawhide?

[Michael Schwendt]

On Fri, 26 Jan 2018 14:52:24 +0100, Remi Collet wrote:

> DEBUG util.py:439:  Error: Transaction check error:
> DEBUG util.py:439:file /usr/share/info/dir conflicts between
> attempted installs of annobin-3.2-1.fc28.x86_64 and info-6.5-1.fc28.x86_64
> 
> Seems related to
> https://src.fedoraproject.org/cgit/rpms/annobin.git/commit/?id=6b89f3290cbc9d2419bce617928b2f78b54836b8
> 

If the package would rebuild, I would have fixed it to fix the buildroot,
but it fails in the test suite.

diff --git a/annobin.spec b/annobin.spec
index f7891a6..1be0937 100644
--- a/annobin.spec
+++ b/annobin.spec
@@ -3,7 +3,7 @@
 Name:annobin
 Summary: Binary annotation plugin for GCC
 Version: 3.2
-Release: 1%{?dist}
+Release: 2%{?dist}
 
 License: GPLv3+
 URL: https://fedoraproject.org/wiki/Toolchain/Watermark
@@ -18,6 +18,9 @@ Source:  
https://nickc.fedorapeople.org/annobin-%{version}.tar.xz
 # This is a gcc plugin, hence gcc is required.
 Requires: gcc
 
+Requires(post): info
+Requires(preun): info
+
 BuildRequires: gcc-plugin-devel pkgconfig coreutils
 
 %description
@@ -63,12 +66,21 @@ touch doc/annobin.info
 
 %install
 %make_install
+rm -f %{_buildroot}%{_infodir}/dir
 
 %if %{with tests}
 %check
 make check
 %endif
 
+%post
+/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :
+
+%preun
+if [ $1 = 0 ] ; then
+  /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
+fi
+
 %files
 %{ANNOBIN_PLUGIN_DIR}
 %{_bindir}/built-by.sh
@@ -78,8 +90,7 @@ make check
 %exclude %{_datadir}/doc/annobin-plugin/COPYING3
 %exclude %{_datadir}/doc/annobin-plugin/LICENSE
 %doc %{_datadir}/doc/annobin-plugin/annotation.proposal.txt
-%{_infodir}
-%doc %{_infodir}/annobin.info.gz
+%{_infodir}/annobin.info*
 
 
#-
 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: libcdio soname bump in rawhide

[Michael Schwendt]

On Thu, 25 Jan 2018 15:24:38 +0100, Adrian Reber wrote:

> /usr/include/qt5/QtGui/qstatictext.h:70:18: note:   no known conversion for 
> argument 1 from 'QString' to 'const QStaticText&'
> 
> Which does not seem to be libcdio related. Is this a know error
> in audacious-plugins?

It is due to Qt 5.10 and fixed by:
https://src.fedoraproject.org/rpms/audacious-plugins/c/2d2eb8305f973f399a862beab84ac34c788ef4ec?branch=master
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org