I switched a desktop F33 machine from pulseaudio to pipewire and it seems to
work fine at a quick glance:
$ sudo dnf swap pulseaudio pipewire-pulseaudio --allowerasing
--enablerepo=updates-testing
$ systemctl --user enable pipewire pipewire-pulse
Now I have the problem when I re-plug my
Hi Cristian,
thank you for contributing to Fedora :-)
Am 07.01.21 um 13:05 schrieb Cristian Morales Vega:
My failed attempt has left me with some questions.
I think I don't understand what you tried so far and what failed exactly (maybe
I misunderstood your email).
- Can this be done?
I
Am 05.01.21 um 16:01 schrieb Neal Gompa:
Welcome to Fedora, Frédéric! I'm looking forward to see efforts around
reproducible builds in Fedora. :)
+1 from me.
I think this is really on example where free software can really show its
strengths and if there is some easy tooling in Fedora to
Am 13.12.20 um 17:18 schrieb Aoife Moloney:
Hiding branches
- Question: Is it possible to hide these retired branches from the UI?
Say, hide branch names with f30 or lower?
- Answer: This is not possible currently
I think it would be more useful (also in the general sense) to make
Am 08.12.20 um 19:56 schrieb Japheth Cleaver:
With point releases, at least there was the possibility of flag days around EPEL
ABI changes, however with a rolling release format there seems to need to be an
active synchronization around such changes, as "expected" breakages aren't
really
Am 04.12.20 um 21:35 schrieb Stephen John Smoogen:
Anecdata which is as 'useful' as any other.
just some additional experience from my side:
- Fedora provides a recent PHP (unlike RHEL 7) but also ships the full PHP stack
required to run popular PHP applications like WordPress/NextCloud/...
(Disclaimer: Just an XWayland user, so I might be totally wrong)
Am 01.12.20 um 10:58 schrieb Fabio Valentini:
I assume there are also at least *some* improvements (other than
XWayland improvements) in the xserver repo that are not released yet?
I think one example could be:
xwayland: Add
On 30.11.20 10:54, Miro Hrončok wrote:
Hence wrt backwards compatibility: pip might now refuse to uninstall the RPM
installed package, while previously it would have done so happily. That is an
improvement, but technically is not 100% backwards compatible behavior.
Oh, I can live with THAT
Am 29.11.20 um 23:11 schrieb Donald Stufft:
Unless there’s something fedora specific going on, that should be correct.
Upstream side, anytime pip installs from a Wheel it produces a dist-info
instead of a egg-info, so if there was some compatibility issue, it should have
been exposed awhile
Hey,
I just noticed that the new packaging macros create a .dist-info directory
instead of .egg-info.
Just to be sure: There is no incompatibility between these two, right? So
setuptools-based code can still retrieve all the package metadata in .dist-info
directories?
(If so I can just
Hi Daniel,
Am 18.11.20 um 18:41 schrieb Daniel Pocock:
Firmware binary code that isn't yet present in linux-firmware.git
- is there any way to extract that binary from another platform?
you probably noticed this yourself, but just in case:
Am 16.11.20 um 14:03 schrieb Vitaly Zaitsev via devel:
Most of casual packagers simply ignore all pull requests and don't even check
their mail. It is much more easier to fix the package manually than waiting 2-3
weeks for a response.
I think this is the root cause and a real problem (I
Hi Miro,
just wanted to say thank you. It took me much longer than expected to actually
try your suggestions but they were spot-on. :-)
Felix
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to
Am 16.11.20 um 13:16 schrieb Vitaly Zaitsev via devel:
The main upstream for Fedora packages is the Fedora Package Sources. If the
package need to be fixed, it must be fixed.
I agree with you here. The only point (though important imho) I want to make is
that provenpackagers should not
Am 16.11.20 um 10:28 schrieb Miro Hrončok:
If it is not urgent, provnpackagers should not go and make packaging changes
without talking to the maintainer first.
+1
I think the main idea is that we try not to create artificial "hierarchies".
Especially for a volunteer maintainer who
Am 09.11.20 um 22:35 schrieb Dan Čermák:
I have filed the respective ticket in Bugzilla [1] as I have seen no
development in the tracking bug to update grpc[2]. The outdated version
of grpc is currently blocking me from updating Bear to anything beyond
3.0.0.
Not directly relatived but:
I
Hey,
Thunderbird 78 changed its tech stack and integrated OpenPGP support so the
enigmail plugin does not work anymore.
Enigmail 2.2.x does not contain any OpenPGP functionality besides a migration
tool which migrates keys to Thunderbird's internal keyring. Since Thunderbird
78 was pushed to
Hi,
it seems that the packager dashboard does not synchronize my data anymore:
https://packager.fedorainfracloud.org/fschwarz
For example it still shows bug #1874669 ("Please build python-cssselect2 for
EPEL8") as NEW even though that bug is closed since 2020-09-19.
Also a lot of new bugs are
Am 03.10.20 um 00:53 schrieb Fabio Valentini:
> - python3-certbot-dns-google is newer in 32 than in 33:
> 0:1.7.0-1.fc32 > 0:1.5.0-1.fc33
>
> This is caused by python-certbot-dns-google being FTBFS for fedora 33+.
> There was no FTBFS bug reported for it, but both releng builds have failed.
>
Hi,
I wanted to update python-dns-lexicon. Version 3.4 uses poetry and tox so I
thought it would be a good idea to get a grip on %generate_buildrequires, %tox
etc.
Unfortunately I'm a bit stuck at the moment. Maybe this is just because I'm
starring for too long on some spec file (and probably my
Just wanted to mention that the F31 update needs one more karma so it can be
pushed to stable:
https://bodhi.fedoraproject.org/updates/FEDORA-2020-dd4e4e78ef
Maybe a F31 user can take a look?
Felix
___
devel mailing list --
Hi,
I'm working towards updating python-dns-lexicon. It can handle many different
dns APIs and for some APIs the code needs additional libraries (some of these
are not packaged for Fedora).
Upstream handles this by using "extras" requirements and the CLI throws an
error message if you try to use
Hey,
I'm trying to update a package which now depends on "requests[security]"
instead of just "requests".
If I understand https://fedoraproject.org/wiki/Changes/PythonExtras correctly
there no mechanism right now to pull in "requests[security]" (along with its
dependencies) so I need to patch
Hi Troy,
thank you for the pointer and sorry if my tone was a bit harsh.
I filed also https://bugzilla.redhat.com/show_bug.cgi?id=1851642 - is that
the right place?
Felix
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe
This morning I got an email notification:
Package Arch Version Repository Size
Am 25.06.20 um 14:55 schrieb Pierre-Yves Chibon:
> Here is an updated list:
>
> @certbot-sig
>
> Please do try to fix this soon!
I'd love to but unfortunately I'm only a user for the certbot sig and even
though I think I'm probably the de-facto maintainer of the certbot stack now I
was not
Am 23.06.20 um 18:26 schrieb Tomas Hrnciar:
> fschwarz pdfarranger python-ndg_httpsclient python-pdfrw python-pyrfc3339
> python-tinycss2
I fixed python-ndg_httpsclient, python-pdfrw, python-pyrfc3339 and
python-tinycss2
dreua fixed pdfarranger.
Felix
Am 23.06.20 um 18:26 schrieb Tomas Hrnciar:
> fschwarz pdfarranger python-ndg_httpsclient python-pdfrw python-pyrfc3339
> python-tinycss2
I fixed python-ndg_httpsclient, python-pdfrw, python-pyrfc3339 and
python-tinycss2
dreua fixed pdfarranger.
Felix
Am 15.06.20 um 19:00 schrieb Petr Šabata:
* What is the scope of Modularity? (contyk, 15:35:03)
* AGREED: Modular-only packages are not allowed and modular versions
are only be allowed as alternatives to non-modular packages. (+9, 0,
-0) (contyk, 15:58:47)
(...)
Thank you, FESCo
Am 13.06.20 um 22:10 schrieb Pierre-Yves Chibon:
> bpereto
Benjamin was a previous maintainer of borgbackup. After the Python 3.9 rebuild
I noticed that a new ticket was still assigned to him [1]. If I understood
your email correctly this is because there is no corresponding bugzilla account?
Am 21.05.20 um 10:52 schrieb Ankur Sinha:
> The packaging team is generally quite stretched, and we frankly need
> more people helping us out.
Agreed.
There might be another simple thing how we could get new contributors: I
noticed that sometimes users asked in bugzilla/on a mailing list if
Am 12.06.20 um 06:09 schrieb Kevin Fenzi:
> Overall things went pretty good from my view, and I would really like to
> thank the awesome fedora community for being patient with us.
Well - thank you (and the other awesome admins).
I hit a few issues but as you communicated the move pretty well
Am 04.06.20 um 07:07 schrieb Sérgio Basto:
> Please what ticket ?
I think Troy was referring to
"bodhi times out on update with many (almost 300) packages"
https://pagure.io/fedora-infrastructure/issue/8949
Felix
___
epel-devel mailing list --
Am 04.06.20 um 05:49 schrieb Kevin Fenzi:
> To clarify we knew it was having problems and tried a bunch of things to
> get it working, and it seems that it is now?
At least it worked for me. I was able to promote a few updates (single builds
but also an update with ~a dozen packages) to stable.
Am 01.06.20 um 17:25 schrieb Troy Dawson:
> I was having a similar problem last week, I opened a
> fed-infrastructure ticket and they extended the time out time. But it
> looks like things have gotten so bad that even that extended time
> isn't good enough.
> I have re-opened the ticket.
Thank
Hi,
I'm unable to submit updates to EPEL 7 stable:
$ bodhi updates request FEDORA-EPEL-2020-d8b45f1e30 stable
fedora.client.ServerError:
ServerError(https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-d8b45f1e30/request,
504, Error returned from json module while processing
Am 29.05.20 um 09:19 schrieb Miro Hrončok:
> The side tag is being merged right now.
Thank you for all the work (also in advance with all the alpha/beta versions)
:-)
Seems like quite a few Python packages were rebuilt in rawhide during your
mass rebuild. Did that happen in the past as well?
builds for borgbackup done (finally):
- borgbackup-1.1.11-3.el7
- borgbackup-1.1.11-5.fc31
Please add these once you submit the final update.
Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Am 24.05.20 um 18:47 schrieb Antonio Trande:
> This mail for asking to the maintainers of `R-argon2` `borgbackup`
> `gtkhash` how we want to rebuild the packages against latest `libb2`
> update as required by rhbz#1836534 and rhbz#1836535.
>
> By buildroot override?
> By a side-tag method?
>
Am 24.05.20 um 11:49 schrieb Antonio Trande:
> Can i include all dependent packages without related permissions? (i'm
> not the maintainer of `R-argon2` `borgbackup` `gtkhash`)
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812
Yes. Submitting an update does not
Am 24.05.20 um 11:49 schrieb Antonio Trande:
> Can i include all dependent packages without related permissions? (i'm
> not the maintainer of `R-argon2` `borgbackup` `gtkhash`)
>
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-628ff99cfc#comment-1383812
Yes. Submitting an update does not
Am 22.05.20 um 23:16 schrieb Felix Schwarz:
> We should push broken updates to EPEL 7/F31.
obviously this should read "We should NOT push broken updates" ;-)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an e
Am 22.05.20 um 23:16 schrieb Felix Schwarz:
> We should push broken updates to EPEL 7/F31.
obviously this should read "We should NOT push broken updates" ;-)
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe
Hey,
seems like you already built libb2?
I hoped we could coordinate the update a bit more so there won't be any
breakage. I just added buildroot override (still waiting for it to become
active) and I can rebuild borgbackup.
I hoped you could do the koji build and then dependent packages would
Hey,
seems like you already built libb2?
I hoped we could coordinate the update a bit more so there won't be any
breakage. I just added buildroot override (still waiting for it to become
active) and I can rebuild borgbackup.
I hoped you could do the koji build and then dependent packages would
Am 22.05.20 um 12:47 schrieb Miro Hrončok:
>> I was not aware that python-genshi is still part of the initial bootstrap
>> sequence. The package does not work with Python 3.9 (upstream problem, the
>> usual AST changes). I hope that won't make your life too difficult.
>
> genshi is used in some
Am 22.05.20 um 03:06 schrieb Miro Hrončok:
fschwarz babel python-genshi
I was not aware that python-genshi is still part of the initial bootstrap
sequence. The package does not work with Python 3.9 (upstream problem, the
usual AST changes). I hope that won't make your life too difficult.
Am 19.05.20 um 15:55 schrieb Richard Shaw:
> Thanks! I do overall enjoy contributing to Fedora but like a lot of us 10 year
> plus packagers, I'm accumulated many packages (some a lot more trouble than
> others!) and while I have no intention of taking a hiatus or anything I'm
> trying to find a
Am 19.05.20 um 14:56 schrieb Igor Raits:
> I think we should get people who maintain Qt on board when updating
> Python so that they make sure to backport necessary patches from
> upstream when we upgrade Python.
Yeah, I think Richard got pretty unlucky when it comes to PySide2 (though
congrats
I see that the server returns "401 Unauthorized" when I try to change this via
s.f.o. Is changing the bugzilla assignee only allowed for main admins?
Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Am 19.05.20 um 11:25 schrieb Fabio Valentini:
> Maybe the reason is that the @certbot-sig is registered as a
> "tracking" type group, whereas e.g. the new @java-maint-sig is
> registered as a "pkgdb" type group? I was able to successfully set
> overrides for the latter one.
You are probably right
Hi,
it seems it is possible to use a -sig group as default bugzilla assignee but I
don't know how to do it.
If I go to pagure (src.fedoraproject.org) I can edit the bugzilla assignee but
using "@certbot-sig" (or "certbot-sig") does not work (error message "Unable
to update the bugzilla
Am 16.05.20 um 20:42 schrieb clime:
> I am a long term epel user and I had no idea about PowerTools.
Yeah, I don't think you are the only one. Most EPEL 8 users do not need
anything from PowerTools so it goes pretty much unnoticed.
I got 3 or 4 bug reports about this when I added certbot to
Am 16.05.20 um 19:39 schrieb Antonio Trande:
> `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a
> soname bump, so all dependent packages need to be rebuilt:
>
> $ repoquery --whatrequires libb2-devel --disablerepo=*
> --enablerepo=*-source
> R-argon2-0:0.2.0-8.fc32.src
>
Am 16.05.20 um 19:39 schrieb Antonio Trande:
> `libb2-0.98.1` has been required on F31 [1] and EPEL7 [2]; it expects a
> soname bump, so all dependent packages need to be rebuilt:
>
> $ repoquery --whatrequires libb2-devel --disablerepo=*
> --enablerepo=*-source
> R-argon2-0:0.2.0-8.fc32.src
>
Am 12.05.20 um 12:32 schrieb Ty Young:
> Right, I figured it was some Fedora policy and not up to you. I suppose I
> should have been more clear there. Sorry for any confusion, it was aimed at
> the Fedora project as a whole as this is a Fedora issue.
This is not a Fedora issue but a consequence
Hey Fabio,
thank you very much for your work.
I can't take on more Fedora work but still wanted to express my gratitude :-)
Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
Am 12.05.20 um 10:35 schrieb Ty Young:
> JUST PACKAGE THE PRE-COMPILED BUILDS!!!
Don't take me as rude but this is not possible.
This is documented in Fedora's packaging policies:
https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#prebuilt-binaries-or-libraries
What is the Fedora policy regarding Python 2 packages in F33?
If there was a Fesco exception for some package last year can we assume that
we can/should keep the package also in F33? I did not find anything about the
assumed scope of these Fesco exceptions.
Specifically this is about bug
Hi Jens,
Am 05.05.20 um 21:28 schrieb Adrian Adrian:
> I was looking to join Fedora development, and as I'm most familiar with
> Python, I thought the Python SIG would be my way to go. Following the
> https://fedoraproject.org/wiki/SIGs/Python/JoinSIG guide, it suggests to post
> a
Am 20.04.20 um 22:19 schrieb Dominik 'Rathann' Mierzejewski:
> Unfortunately, we don't have that many sponsors, and many of the
> existing ones are not very active. Please be patient.
Though my impression was that there are several Fedora sponsors who are
willing to sponsor new packagers. So
Am 16.04.20 um 20:05 schrieb Göran Uddeborg:
> As the suggestion was sent off list, I didn't want to say that.
No reason to keep it secret :-)
Until now I did not realize I sent you a private message (just wondered about
the privat reply ;-)
Felix
___
Hi Justin,
Am 12.04.20 um 03:40 schrieb Justin Coffman:
> There’s a bug currently open requesting that “tinyfugue” be packaged for EPEL
> 8.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1762158
>
> There hasn’t been any response to the original requestor since it was opened
> in October.
Am 24.03.20 um 12:04 schrieb Felix Schwarz:
> If I have some spare cycles I'll try to run the upstream test suite with
> msgpack 1.0.
just fyi: borgbackup upstream was not compatible with python-msgpack 1.0 but
upstream was (again) very helpful so the next version of borgbackup will also
s
Hi,
following the policy for non-responsive package maintainers [0], I'm
asking here if anybody knows how to contact elyscape (Eli Young).
Eli, if you're still interested in maintaining your packages, please respond.
Open bugs:
- python-digitalocean-1.15.0 is available
Am 10.04.20 um 13:40 schrieb Miro Hrončok:
> On 10. 04. 20 12:05, Felix Schwarz wrote:
>> What is the best way to get a Python 3 version for EPEL 7?
>
> Do a new package review request for an epel7 only package called
> python3-configobj that looks like:
Thank you for your ad
Hi,
I want to move certbot from Python 2 -> Python 3 in EPEL 7. As you might
imagine this means getting Python3 packages of all required libraries. Most of
them are pretty straight forward (I hope) - just build the Python 3 version
also on EPEL 7.
However there is python-configobj which is
Am 01.04.20 um 08:42 schrieb Clement Verna:
> I think this feeling comes from the mixing of git forge and dist-git use case
> that you have pointed out.
That seems to be the core of all the talk about "feature gaps" - obviously
pagure is not nearly as advanced as gitlab/github when you want "some
Am 31.03.20 um 12:42 schrieb Kevin Kofler:
> I think that using anything other than Free Software as the hosting platform
> for Fedora should be an absolute no go. In other words, self-hosted GitLab
> CE or Pagure, no other options.
+1 with one minor(?) exception:
I'm ok with using a hosted
Am 31.03.20 um 12:03 schrieb Lukas Zapletal:
> I have a subpackage which is not needed anymore in the new version of the
> package. Is my assumption correct that for a smooth upgrade path I should
> simply delete the subpackage and make the main package to obsolete it:
>
> Obsoletes:
Am 24.03.20 um 11:49 schrieb Fabian Affolter:
> A month ago was msgpack 1.0.0 released. I'm planning to update the
> package in rawhide in the near future.
>
> This should start a conversation about a coordinated approach to keep
> the update smooth for all packages which depends on
The ROCm stack would be nice to have in Fedora. Tom Stellard started to
package parts of it but afaik the effort stalled a while ago.
I think the ROCm stack is pretty challenging because it is mostly in-house
software and not much effort was spent to make the build process
distribution-friendly.
Am 18.03.20 um 12:51 schrieb Antonio Trande:
> I'm going to update `msgpack` to the release 3.1.0 on EPEL7.
> It shouldn't provide a newer library version than the current 1.4.1 release.
Thank for the heads up.
Just to be sure - this does not affect python36-msgpack, right?
(otherwise I'd have
Am 14.03.20 um 10:35 schrieb Felix Schwarz:
> I just tried to push some changes to git but was unable to do.
...
>
> What I can do to get this fixed?
I tried again and somehow it worked the second time.
Felix
___
devel mailing list
Hi,
I just tried to push some changes to git but was unable to do.
$ git push
Please visit
Hi Erich,
Am 02.03.20 um 21:24 schrieb Erich Eickmeyer:
> As these attempts were over a week ago, I guess my next step is to submit a
> FESCo issue with the bug links. However, since this is my first post
> specifically looking for bsjones unlike my previous post, perhaps I should
> give it
Am 02.03.20 um 04:43 schrieb J. Scheurich:
> What is wrong ?
Bugzilla + the build system are not magically linked. You need to close the
bug manually after building the package in rawhide and F32.
Just from a quick glance I think your rebuilds were successful so you can
close the bug report.
Am 05.02.20 um 09:55 schrieb Code Zombie:
> What do you mean? The source code built successfully on my Fedora 31 system
> with JDK 11 (using ant).
I don't know the Netbeans code but in Fedora we need to build each package
from source (no precompiled jars). That means we also need to ship *all*
Am 31.01.20 um 15:22 schrieb Felix Schwarz:
> (Also you should not presume that shipping gstreamer 0.10 in Fedora is a
> given, see Dominik's answer and Miro's attempt to clarify the security
> policy.)
^^^ Michael's answer of cour
Am 31.01.20 um 15:06 schrieb Julen Landa Alustiza:
> We don't have any problem to retire open source packages that works because
> they don't move to python 3 for example, but at the same time we hold dead old
> libraries due to proprietary software.
>
> It looks unfair at least
The main
Am 31.01.20 um 03:01 schrieb Kevin Fenzi:
> I am with you on open source, but I don't understand the 'self-hosted'
> requirement. I guess I agree that self hosting should be possible, in
> case someone wants to fork our distro and use our tools, but if we can
> convince a open source project to
Hi Bill,
Am 30.01.20 um 07:25 schrieb Bill Chatfield via devel:
> According the procedure for retired packages, I'm announcing my intention to
> take ownership of checkstyle, checkstyle-maven-plugin, and
> google-http-java-client. They are all retired as far as I can tell.
Welcome to Fedora -
Am 26.01.20 um 01:10 schrieb Bill Chatfield via devel:
> That's a very sad story. I had no idea. So it sounds like you mainly need
> maintainers for Java packages. I have worked on building RPMs but I have
> never been a package maintainer. However I have 20 years of experience as a
> Java
Am 22.01.20 um 11:00 schrieb Neal Gompa:
> Yes, but neither of those communities actually have terribly special
> requirements. In fact, those communities either had *nothing* in terms
> of infrastructure (FreeDesktop/Xorg) or were willing to throw
> everything away for GitLab (GNOME). We would
Am 21.01.20 um 22:31 schrieb Michael Catanzaro:
> Well since we have a request for requirements: I propose requirements #1 and
> #2 are to be self-hosted and open source.
+1
Felix
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe
Am 21.01.20 um 21:48 schrieb Guido Aulisi:
> I totally agree with Fabio, I can’t think of a single reason we should dismiss
> pagure.
Gitlab is used by many free software communities like Freedesktop, Gnome,
Debian. Using the same tools could help to facilitate
inter-process/inter-distro
Am 16.01.20 um 21:15 schrieb Zbigniew Jędrzejewski-Szmek:
>> Accommodating component versioning would mean deploying
>>
>> /usr/lib/pythonxx/site-packages/something-semver.zip
>
> This path includes xx, which contains the major and minor numbers. So
> adding "semver" would only allow
Am 16.01.20 um 21:15 schrieb Zbigniew Jędrzejewski-Szmek:
>> Accommodating component versioning would mean deploying
>>
>> /usr/lib/pythonxx/site-packages/something-semver.zip
>
> This path includes xx, which contains the major and minor numbers. So
> adding "semver" would only allow
Am 16.01.20 um 13:37 schrieb Nicolas Mailhot via devel:
> If we start messing with the Python tree it would be nice to put each shared
> python component in a separate zip/xz/whatever, and allow versioning those
> archives
>
> (ie use the highest semver zip present unless the code explicitely
Am 15.01.20 um 23:11 schrieb Victor Stinner:
> This solution is well supported by unmodified Python: it's part of the
> default sys.path search path:
>
> $ python3
> Python 3.7.6 (default, Dec 19 2019, 22:52:49)
import sys; sys.path
> ['', '/usr/lib64/python37.zip', ...]
>
> It's the
Am 13.01.20 um 14:05 schrieb Vít Ondruch:
> While I like the annotated tag proposal, I would really appreciate if
> the first step was replacing the:
(..:)
> %changelog
>
> %include changelog
>
> ~~~
>
> where the `changelog` file would be either available with the original
> changelog content
Am 09.01.20 um 00:03 schrieb Breno Brand Fernandes:
> It seems that the package was retired on 2019-02-11[1].
I think you need to follow the general un-retirement procedure:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Retired_Package
Felix
Am 06.01.20 um 20:48 schrieb Robbie Harwood:
To actually get removed from your package in Fedora typically takes at
least three months during which you have to be mostly non-responsive. I
only package a few things in Fedora, but it's far more frustrating to me
as a maintainer when a
Am 23.12.19 um 01:23 schrieb John M. Harris Jr:
> So long as Python2 remains installable, I don't see why you feel the need to
> rip it out of the distro.
Also imho I expect that Fedora packages will receive security fixes and
serious bugs will be fixed (of course still considering that Fedora
Am 22.12.19 um 02:49 schrieb John M. Harris Jr:
> Unfortunately, this package will eventually be hurt by this new FESCo policy
> to remove Python2. It is unfortunate, but cannot really be avoided. If it
> doesn't get a FESCo exception (and FESCo has denied several exceptions,
> regardless of
I recently became co-maintainer for davfs2 and noticed that the package
featured an outdated license tag (davfs2 switched to the GPLv3 10 years ago)
-License:GPLv2+
+License:GPLv3+
Felix
___
devel mailing list --
Am 13.12.19 um 07:29 schrieb Frank R Dana Jr.:
> As a follow-up to RHBZ 1779063 and in accordance with the non-responsive
> maintainer policy[1],
You should also cc Chris - maybe he is no longer actively following
fedora-devel.
Felix
___
devel
Am 11.12.19 um 13:51 schrieb Felix Schwarz:
> I filed https://github.com/abrt/faf/issues/856 - hopefully that is the right
> place.
Upstream mentioned that this is a conscious design decision as the exception
message could expose private date:
https://github.com/abrt/faf/wiki/uReport#ano
Am 11.12.19 um 13:08 schrieb Lumir Balhar:
> I don't know these tools but you can guess what happened from the file/line
> combination in the stack and from the error name which contains the name of
> the exception.
Well, unfortunately this is not the case for certbot. It crashes in a generic
I'm wondering if there is a way to get the Python exception message via
retrace/abrt?
From what I can see the web interface only shows the call stack but without a
specific exception there is not much I can do.
(I saw the exception message when a user created a bugzilla bug)
Example:
1 - 100 of 182 matches
Mail list logo
