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
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
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
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
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:
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
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?
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
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
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 '[
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
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?
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,
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()
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
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
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
>
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 |
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
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
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
> >
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:
> >
> >
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
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 -
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
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
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
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
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
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.
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
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
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?
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
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
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
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
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
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
> 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
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
>
> 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
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.
>
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
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
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.
> >>
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
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
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
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
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
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
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?
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
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
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.
Whi
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
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
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
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
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 /
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
>
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
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
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
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
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
>
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
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
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
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.
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
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
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
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
> >>
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.
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
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?
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 cryp
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
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 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
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'
>
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
>
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
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
> 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
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
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
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
> >
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
>
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
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
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
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
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
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.
___
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
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
>
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
1 - 100 of 1397 matches
Mail list logo
