> This is also a valid approach. This is the first alternative proposal
> which makes me say "hmm, this would also work". It is possibly even
> simpler than setting the $PATH. A very small disadvantage is that the
> wrapper would need to do its work every time the binary is called.
> But the
Greetings,
Since Pillow 10 landed in f39 the following packages are FTBFS:
https://src.fedoraproject.org/rpms/python-blockdiag
https://src.fedoraproject.org/rpms/python-actdiag
https://src.fedoraproject.org/rpms/python-nwdiag
https://src.fedoraproject.org/rpms/python-seqdiag
Ever since the
On Mon, May 22, 2023 at 3:50 AM Jens-Ulrik Petersen wrote:
>
> In Fedora the bash prompt is not colored or highlighted by default.
>
> I personally find this a usability issue: it makes it hard to find previous
> commands between long outputs when scrolling back in a terminal. Of course
> in
On Fri, Feb 5, 2021 at 9:06 PM Steven A. Falco wrote:
>
> On 2/5/21 1:05 PM, Jonathan Wakely wrote:
> > On 05/02/21 10:08 -0500, Steven A. Falco wrote:
> >> I see that the master to main conversion has happened. I'd like to know
> >> the recommended way to deal with that.
> >>
> >> Currently,
> The f33 xfce4-pulseaudio-plugin package from updates-testing can now
> work with pipewire and so far so good. I'm of course lacking the features
> I was using with paprefs, but will try to find in the pipewire docs whether
> the same can be achieved with pipewire-specific tooling.
>
> My main
> Same explicit dependency with the xfce4-pulseaudio-plugin package.
>
> I'm now much closer to giving pipewire a try.
The f33 xfce4-pulseaudio-plugin package from updates-testing can now
work with pipewire and so far so good. I'm of course lacking the features
I was using with paprefs, but will
> With the help of Tomas and Jan, we've got this sorted out. Upgrade to
> pipewire 0.3.15 did help with Chrome, Firefox, and OBS being now able to
> share the screen. It doesn't help with UX of pipewire portal dialogs but
> this is something I can live with for time being.
Hi,
I noticed a
On Sat, Dec 26, 2020 at 6:14 PM Kevin Fenzi wrote:
>
> On Thu, Dec 24, 2020 at 07:32:04AM +, Dridi Boukelmoune wrote:
> > > The weakest point in the current system is really the FAS password. If
> > > you have a packager's FAS password you can change the
> The weakest point in the current system is really the FAS password. If
> you have a packager's FAS password you can change the ssh key
> associated with the account to another that you control, and the FAS
> password is also all you need to run a build and submit it to Bodhi.
Or you add an SSH
> It looks like resolved tries to resolve the name on two scopes (global and
> one specific to some interface). This will happen if the name lookup priority
> is the same for both the two scopes.
Interesting, I'll search the docs. I don't recall seeing anything
about priority and that's
> The answers came quickly from address1, and were allegedly cached.
>
> Second bug? subsequent queries will still be cache misses.
Before anyone asks, I have Cache=yes in resolved.conf, I was at least
up to speed with the contents of the resolved.conf(5) manual.
Dridi
> That's totally on me, I read the resolved.conf(5) manual but didn't
> pay attention to the systemd-resolved.service(8) manual in the SEE
> ALSO section: that would have led me to resolvectl. Thanks for the
> pointer, I'll do some reading, probably figure what I mis-configured
> and otherwise
> An unfinished dbus call should only happen when the server fails
> internally and aborts the connection. If there's an error or timeout in
> the query resolution, it should still terminate the connection with
> some response.
>
> Please enable debug logs with 'resolvectl log-level debug' and do
> Instead, we have gnome, NM, systemd-resolved, firefox et all fighting
> over who and how to handle captive portal authentication.
What bothers me first and foremost is that I'm not connecting through
a captive portal, and somehow I can't fully trust systemd-resolved to
DoTheRightThing(tm).
On
> I wouldn't mind the mitigation, if only I could disable it. Does
> anyone know any better? I'm still suspecting I configured something
> wrong but at the same time systemd seems to have a history with
> NXDOMAIN handling.
I found several things, including this related to NXDOMAIN:
On Tue, Dec 8, 2020 at 8:34 PM Marius Schwarz wrote:
>
> Am 08.12.20 um 19:32 schrieb Dridi Boukelmoune:
> >
> >> Petr was so nice to supply a test procedure, i suggest that you use it
> >> also.
> > I'll try to strace stuff to to see what's going on, bu
> Can you pls get another stackframe and compare it ( it won't match 100%
> as differen apps go different way) with this bugreport:
It won't matter much, the next frame is in Varnish code.
Here is the pstack dump of dig:
> Thread 4 (Thread 0x7fee8a3e4640 (LWP 1768516) "isc-socket"):
> #0
Greetings,
I'm not sure whether I am doing something wrong so I'd rather get
someone's opinion before submitting a bug report.
Since the upgrade to f33 I replaced my stubby setup with
systemd-resolved since it is now the default. I was OK with that
change since I didn't lose functionality
On Fri, Dec 4, 2020 at 7:23 AM Dridi Boukelmoune
wrote:
>
> > > Maybe I need to reboot my system for vim to take over again?
> >
> > You will at least need to logout and log back in.
>
> You're right, if I force a login instead of plain sudo it becomes apparent
> > Maybe I need to reboot my system for vim to take over again?
>
> You will at least need to logout and log back in.
You're right, if I force a login instead of plain sudo it becomes apparent:
$ sudo env | grep EDITOR
$ sudo su -c env | grep EDITOR
$ sudo su - -c env | grep EDITOR
> actually Vim ships vim-default-editor subpackage now, which conflicts
I did install it, but that didn't seem to have an immediate effect.
> with nano-default-editor via virtual provide 'system-default-editor'. It
I don't have that package on my system:
$ sudo dnf remove nano-default-editor
On Tue, Oct 27, 2020 at 1:35 AM Micah Shennum wrote:
>
> Thank you, I will be sure to compare specs. On a related note, I am of
> course also open to co-maintainership.
I wish I could say the same, but the reason why I'm currently using
tmuxinator via my copr repository is precisely that I don't
> I will CC myself to the 2 bugzilla tickets.
Ouch, I'm not a sponsor so even if I approve your review requests it
won't be enough.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to
On Sun, Oct 25, 2020 at 8:05 PM Micah Shennum wrote:
>
> I want to unretire tmuxinator, as it is a tool I use and I was surprised to
> find it is currently retired. Searching through the mailing list, it appears
> to have been retired simply due to being orphaned.
When it got retired, it was
> Oddly, the subject of the original post infers getting rid of rpm but
> the post itself sounds like it's proposing something different and
> that's why I decided to speak up.
Yes, poor joke of mine, keeps hitting home though :)
Ditching RPM in favor of DPKG was never meant to be a system-wide
> Simply put, "no". Debian and Ubuntu ".deb" packages too often don't
> follow the File System Hierarchy, they may have different layouts and
> package naming capitalization schemes for matching Fedora packagers
> like "PyYAML", they may have overlapping pre-set uids and mismatched
> group name
On Tue, Jul 14, 2020 at 8:39 PM Dishant Pandya wrote:
>
> Its ok to have something that builds deb packages on Fedora, but in my
> opinion RPM is far more better then debian packages. Also the Dnf and yum
> package manager on Fedora are far more advanced than apt on Ubuntu and other
> Debian
> The tag page for fedora-minimal seems to be working
> https://registry.fedoraproject.org/repo/fedora-minimal/tags/. Do you have a
> link of the page that is blank ?
That's the very link from which I get a blank page, and Firefox
reports an empty resource (^U to view source).
The developer
> The blank pages are flatpaks. We are using the same registry for containers
> and flatpaks and the upstream project[0] used for registry.fp.o does not
> support flatpaks so the page is just blank.
That can't be right, fedora-minimal is a docker/an OCI image, isn't it?
> There has not been
> > microdnf reinstall tzdata
>
> There's a bug about this to split out the UTC tzdata into a minimal
> tzdata so terrible hacks aren't needed to slim things down.
> https://bugzilla.redhat.com/show_bug.cgi?id=1722233
I'll CC myself to this bug but it doesn't look like anything will happen
Greetings,
I'm not sure whether the minimization effort is still going on but I
wanted to report the pitfalls I ran into moving from the fedora Docker
container to fedora-minimal.
For starters I was surprised by the absence of DNF and I had to find
by myself, I don't remember how, that MicroDNF
> == How To Test ==
> Install Fedora 33 (any edition or flavor), check that modular repos
> are still installed and enabled by default.
>
> Update to Fedora 33 (from Fedora 31 or 32), check that modular repos
> are still installed and enabled by default.
>
> Check that you can remove the
On Tue, Jun 9, 2020 at 5:43 PM Samuel Sieb wrote:
>
> On 6/9/20 6:49 AM, Dridi Boukelmoune wrote:
> >> Well, that's really the point. The one you're using is one of the (4? 5?)
> >> other zram implementations. It seems a bit more straightforward than the
&
> Well, that's really the point. The one you're using is one of the (4? 5?)
> other zram implementations. It seems a bit more straightforward than the
> systemd one for sure.
The zram-generator is probably more straightforward (with literally
less layers of indirection) than what the zram package
> Zswap sounds like an excellent idea to look into instead of zram. Not only
> that, but it'd allow traditional entry in fstab to configure it, instead of
> some systemd magic that nobody knows about.
In that case most of everything that happens on my system is magic, I
don't have comprehensive
On Tue, May 26, 2020 at 12:07 PM Jan Kratochvil
wrote:
>
> On Sun, 24 May 2020 05:21:05 +0200, Paul Dufresne via devel wrote:
> > The idea was to push code generation as near as possible of code execution.
> > Because at execution time, you know what are the specific features of the
> > CPU, and
> Having -Wall and -Wextra with -Werror is the perfect footgun, since
> you’re at the mercy of whatever compiler is being used. Get yourself a
> manageable set of warnings and make those fatal instead.
That's what we do at $DAYJOB and we are happy whenever a new gcc or
clang release finds new
On Sun, Feb 23, 2020 at 3:49 PM Mukundan Ragavan wrote:
>
> Hi all,
>
> I have two packages that fail to build from source. As far as I can tell
> from the build logs, they are gcc-10 failures. The typical "extern"
> solution does not work me (or, I am not adding 'extern' at the correct
>
On Wed, Feb 12, 2020 at 3:33 PM Code Zombie wrote:
>
> Hi
>
> Kotlin is an open source project. Are there any plans to include its compiler
> in Fedora (if not already) repositories? Currently, it is installed manually
> on Linux to the best of my knowledge, but Mac systems already install it
On Wed, Feb 12, 2020 at 12:58 PM Pierre-Yves Chibon wrote:
>
> On Wed, Feb 12, 2020 at 11:18:33AM +, Dridi Boukelmoune wrote:
> > On Tue, Jan 21, 2020 at 5:15 PM Pierre-Yves Chibon
> > wrote:
> > Remark: fedpkg's request-side-tag command doesn't appear in the manual
On Wed, Feb 12, 2020 at 11:27 AM Miro Hrončok wrote:
>
> On 12. 02. 20 12:18, Dridi Boukelmoune wrote:
> > Question: can I build for rawhide, in a side tag, on an arbitrary git
> > branch?
>
> You can, but it's very confusing for others if not kept very sel
On Tue, Jan 21, 2020 at 5:15 PM Pierre-Yves Chibon wrote:
>
> Good Morning Everyone,
>
> We are pleased to announce that the work to gate rawhide packages has leveled
> up!
>
> Back in July we announced the first phase where bodhi got the support to gate
> single-build updates. We can now
On Tue, Dec 10, 2019 at 12:28 AM John Reiser wrote:
>
> > If you are running into that kind of problems where
> > plugins/modules/dynamically linked objects may have conflicting
> > requirements
>
> then see dlmopen(): https://sourceware.org/glibc/wiki/LinkerNamespaces
Agreed, my first response
> Not fool proof checked, but I believe this is what would happen. Usually
> one wants to only LD_PRELOAD to replace some glibc symbol, for some kind
> of debug, but any library where there valid usages of LD_PRELOAD should
> not be linked with -Bdynamic-functions.
Having experienced the
On Mon, Oct 28, 2019 at 8:00 PM Troy Dawson wrote:
>
> I would like to introduce a plan I call Square 1 [1][2]
>
> There are two goals to Square 1.
> The first is to get, and keep, the core buildroot[3] packages,
> self-hosting[4].
> The second is to get the list of core buildroot packages as
> Hi,
>
> It looks like some leftover from the past. I don't really see why it
> should be there.
>
> This commit removes that:
>
> https://github.com/fedora-selinux/selinux-policy-macros/commit/5f366657da0c7c67f2448be03620581437c2dfbb
>
> Fixing it also in Rawhide and F31.
Thanks a lot! Can it
On Sun, Nov 3, 2019 at 9:03 PM Orion Poplawski wrote:
>
> On 11/3/19 11:17 AM, Todd Zullinger wrote:
> > Dridi Boukelmoune wrote:
> >> On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
> >>>
> >>> On 11/1/19 1:47 PM, Daniel Walsh wrote:
>
On Sat, Nov 2, 2019 at 2:21 AM Orion Poplawski wrote:
>
> On 11/1/19 1:47 PM, Daniel Walsh wrote:
> > Flat pack should be doing a requires(post): selinux-policy-base
> >
> > To make sure it is installed before flatpack.
>
> Thanks. The proper incantation actually though seems to be:
>
>
On Wed, Oct 16, 2019 at 8:56 PM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Wed, Oct 16, 2019 at 10:49:29AM -0700, Kevin Fenzi wrote:
> > On Wed, Oct 16, 2019 at 10:02:12AM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > I submitted a Change for wrangling today, but I'm also putting it here
> > >
On Tue, Oct 8, 2019 at 6:45 PM Ravindra Kumar via devel
wrote:
>
> Hi,
>
>
>
> I have removed dependency on service B from service A and all references to
> service B. The new package works well for fresh install (service A can be
> started normally), but it does not work for upgrades from
On Tue, Oct 8, 2019 at 12:06 AM Kevin Kofler wrote:
>
> Matthew Miller wrote:
> > A key goal of the modularity project is to allow some of the cases to be
> > better addressed by allowing packagers to think in terms of upstream
> > changes which affect user experience separate from the Fedora
On Sun, Oct 6, 2019 at 1:12 PM Fabio Valentini wrote:
>
> On Sun, Oct 6, 2019, 15:07 Miro Hrončok wrote:
>>
>> Couple of my updates have e-mailed me $subj. Is it something to worry about?
>
>
> I got this too for a lot of my updates, just a few hours ago. I assumed it
> was caused by some kind
On Tue, Oct 1, 2019 at 4:09 PM Stephen Gallagher wrote:
>
> On Mon, Sep 23, 2019 at 10:21 AM Ben Cotton wrote:
> >
> > https://fedoraproject.org/wiki/Changes/ThermalManagementWS
> >
> > == Summary ==
> > Better thermal management and peak performance on Intel CPUs by
> > including thermald in
On Mon, Sep 23, 2019 at 2:21 PM Ben Cotton wrote:
>
> https://fedoraproject.org/wiki/Changes/ThermalManagementWS
>
> == Summary ==
> Better thermal management and peak performance on Intel CPUs by
> including thermald in the default install.
>
> == Owner ==
> * Name: [[User:benzea| Benjamin
On Sun, Sep 15, 2019 at 11:36 PM Neal Gompa wrote:
>
> DNF does have some broken behaviors, but this isn't one of them.
I can't confirm whether this is a broken behavior but I have a strong
heuristic that I suspect would make DNF appear wrong here.
If I have RPM foo-1 installed that obsoletes
On Fri, Sep 13, 2019 at 10:19 AM Kevin Kofler wrote:
>
> And finally, unlike the old YUM, DNF also processes Obsoletes from old
> versions of packages in the GA repositories, so an update can no longer
> safely withdraw an Obsoletes. This is a DNF issue and we need a solution in
> DNF, but the
Hello Nicolas,
On Fri, Sep 13, 2019 at 10:51 AM Nicolas Chauvet wrote:
> Well... I don't qualify as a person with much free time but...
>
> I'm toying with kernel-longterm in a copr for .4.19 branch, and I've
> enabled i686 there.
> The rebuilt is a semi-automated way.
> This i686 build is
> Maybe in other distros, people interested in i686 support actually do
> something about it instead of talking and talking and talking about it
> on mailing lists?
Maybe someone with so much free time on their hands could maintain
such a kernel in Fedora by applying downstream packages of such a
On Wed, Sep 11, 2019 at 12:55 PM Miroslav Suchý wrote:
>
> Do you want to make Fedora 31 better? Please spend 1 minute of your time and
> try to run [*]:
>
> sudo dnf --releasever=31 --setopt=module_platform_id=platform:f31
> --enablerepo=updates-testing distro-sync
>
> If you get this
On Sun, Sep 8, 2019 at 6:51 PM Fabio Valentini wrote:
>
> Hello packagers,
>
> The Stewardship SIG is currently providing only bare-minimum
> maintenance for some Java packages, and none of our packages depend on
> them anymore.
> So, we're looking for someone to take better care of them,
On Tue, Aug 27, 2019 at 11:33 AM Stephen Gallagher wrote:
>
> On Mon, Aug 26, 2019 at 4:21 AM Miro Hrončok wrote:
> >
> > The following packages are orphaned and will be retired when they
> > are orphaned for six weeks, unless someone adopts them. If you know for sure
> > that the package should
> It may be simpler to approach the question from the other side, i.e. is there
> anything that actually ever needs more than 1MB of stack space? If there is,
> I haven't seen it in the decade since I've been using this tweak with various
> Fedora derived distributions.
Any application
> Well, it went through many revisions, and some of the bits are very
> recent. For example, the pre-boot random seed stuff has been added in
> v243, of which we only posted an -rc1 so far,
>
> However, the basics have been around very early on, yes.
Well, from someone not versed in bios, efi and
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package
> or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets
On Sat, Aug 10, 2019 at 10:28 PM Kevin Kofler wrote:
>
> Miro Hrončok wrote:
> > Because if we don't, people just gonna ignore FTBFS forever.
>
> And this would be a problem why exactly?
>
> Packages built for older Fedora releases tend to run on newer Fedora
> releases just fine. If the package:
Sorry for the top posting, "smart" phone...
What about Qubes OS? Isn't their dom0 using xen, based on Fedora?
Do they use Xen as packaged by Fedora? If not, couldn't they contribute
whatever they do that Fedora doesn't here?
It might be worth getting in touch with them. They look like a
Hi,
> That only works properly on distros that implement the boot loader
> spec and the boot loader interface properly:
>
> https://systemd.io/BOOT_LOADER_SPECIFICATION
> https://systemd.io/BOOT_LOADER_INTERFACE
Thanks for the links, I looked briefly when you replied but figured
I'd need a quiet
On Wed, Jul 31, 2019 at 7:17 AM Pierre-Yves Chibon wrote:
>
> On Tue, Jul 30, 2019 at 01:13:50PM -0400, Tim Zabel wrote:
> >Hello,
> >I'm a little late to this conversation, but is fpaste in Category 4 due
> > to
> >the high legal costs, or because of a lack of a maintainer?
> >
> $ repoquery --repo=rawhide-source --whatrequires /usr/bin/python --exact
> 0ad-0:0.0.23b-6.fc31.src
> cherrytree-0:0.38.5-5.fc30.src
> chocolate-doom-0:3.0.0-2.fc30.src
> distro-info-0:0.18-3.fc30.src
> distro-info-data-0:0.38-2.fc30.src
> dtrx-0:7.1-13.fc29.src
> gcc-0:9.1.1-2.fc31.src
>
> What is certain is that I won't have time to proverbially sit down (on
> my standing desk) and track bugs down, either as a reporter or as a
> maintainer. Same thing for my stalled review requests I was hoping to
> get done much sooner.
I may be back on track in a couple weeks actually, I may
> Anyways, there are easy ways in Autotools to archieve this, and I can
> craft a patch, if you guide me to the canonical upstream of audit.
And even if you don't patch it, the need to export [1] a PYTHON
variable in the environment is exactly what should be done.
The tragedy of autotools is
Hi,
> By following the process, all of your packages will get orphaned.
> If that is your desire, shall we do it directly?
That part, please don't :)
The reason why I'm encouraging people to become co-maintainers is
because I won't be unavailable forever, but longer than the orphan
grace
Greetings fellow package maintainers,
I'm starting the non-responsive maintainer process on myself because
the time I can dedicate to Fedora will significantly drop for the next
3 months. It wasn't that much to begin with...
I don't think I will be able to follow up on anything, especially
On Mon, Jul 15, 2019 at 7:58 AM Vitaly Zaitsev via devel
wrote:
>
> Hello, Dridi Boukelmoune.
>
> Mon, 15 Jul 2019 06:59:33 + you wrote:
>
> > game that cannot move to 64bit support because it's dragging binaries
> > for which it doesn't have source code.
>
>
> I don't think we can drop multilib until at least steam/wine are ready
> for it at least.
Will they ever be though? Thanks to Wine I can run an open source
game that cannot move to 64bit support because it's dragging binaries
for which it doesn't have source code. I reverse-engineered one of
> I disagree about the user/group creation, at least the way it's being
> planned in here.
>
> The way openSUSE solved this problem probably makes sense for dealing
> with issues like needing the users+groups to exist before package is
> being installed:
>
> 1. sysusers are in their own
> Also, macOS is switching from bash to zsh (?) I don't know why.
> https://support.apple.com/en-ca/HT208050
Probably because they stuck to an old version of bash to avoid the
GPLv3 re-licensing, or so I've been told. Maybe the version of bash
they use is going EOL as well.
Dridi
On Wed, Jun 26, 2019 at 3:06 PM José Abílio Matos wrote:
>
> On Wednesday, 26 June 2019 13.03.44 WEST Vít Ondruch wrote:
> > I agree with the "# Stop linting code in %%check and measuring coverage,
> > this is upstream's business" reasoning. Shouldn't we mention that
> > somewhere in guidelines?
> Could this ugly hack work?
>
> %{endif __with_rebar3}
>
> Assuming the %endif macro would ignore any parameters.
This won't work... But RPM could "learn" this syntax and let spec
writers add that kind of comment inside the macro.
A bit far-fetched, I won t disagree :)
Dridi
> > Not sure if I understand. Are you saying that
> >
> >%endif%{discard:__with_rebar3}
> >
> > will not work either?
>
> Yes, that's what I'm saying. Or rather, you'd get the warning with that
> too. It all *behaves* exactly the same as before, so it continues to "work".
Could this ugly
On Mon, Jun 17, 2019 at 8:59 PM Terry Bowling wrote:
>
> Oh, I forgot to add that related to parallel installations, when conflicting
> modules are desired, generally containerization or virtualization is the
> recommended solution. However, this is from the RHEL user persona
> perspective.
> > Thanks to soname, library are perfect use case for parallel installation
> > of multiple versions.
>
> +1
>
> We could go a step further and extend rpm and dnf to support multiple
> versions of same named packages for installation. This is doable but
Both rpm and dnf can do that, try running
On Thu, May 23, 2019 at 3:22 PM Tomas Tomecek wrote:
>
> This is still on my backlog, ideally, to also add python2 support and
> add it to epel7. Miro was so nice and fixed the package in rawhide so
> it works with python3.
Why add python2 support? epel7 has python3 support nowadays.
> Feel
Hi,
I was browsing getfedora.org looking for the f31 PGP key that DNF is
currently prompting me to accept or reject. I found that the old URL [1]
is gone and doesn't redirect to the new one [2] that currently shows
keys up to f30.
Is there a reliable location where I can verify the f31 key
On Thu, May 16, 2019 at 9:49 AM Martin Gansser wrote:
>
> Hi,
>
> I'm trying to compile the program olive with the help of a spec file [1],
> which unfortunately fails when creating the Makefile.
> Have somebody a idea or solution ?
>
> [1]
On Thu, May 16, 2019 at 9:41 AM Zbigniew Jędrzejewski-Szmek
wrote:
>
> On Thu, May 16, 2019 at 09:11:21AM +0200, Dridi Boukelmoune wrote:
> Let me also add my +1 to the write-up itself, a very nice story.
>
> Zbyszek
I may have accidentally skipped the +1 step and jumped straight
> configure with feature autodetection is a PITA :/
The PITA doesn't come from auto-detection, rather auto-selection of
(optional) dependencies. I tend to prefer explicit --with-* or --enable-*
flags for anything optional and fixed defaults.
It would be worse if we had to tell a configure script
On Thu, May 16, 2019 at 3:46 AM Jerry James wrote:
>
> I finally found some time to look at the xindy failure to build.
> First, let me say that I've got a workaround for the problem, which
> resulted in the beautiful green colors in this xindy-enabled scratch
> build of texlive-base:
>
>
On Mon, May 13, 2019 at 7:57 PM Jakub Jelinek wrote:
> > Sorry for digging up this thread, but since this is a recurring change
> > it appears that the mass rebuild is not enough by itself. As of today
> > lcov doesn't work with GCC 9.x [1] and it would be nice if either:
> >
> > - gcc provided
On Tue, Jan 22, 2019 at 10:30 AM Jakub Jelinek wrote:
>
> On Tue, Jan 22, 2019 at 10:02:22AM +0100, Miro Hrončok wrote:
> > This is already happening, gcc was updated, I see bugs for gcc 9 related
> > FTBFS being open. This is not a proper way to coordinate this kind of thing.
>
> I'm sorry, I
On Sun, May 5, 2019 at 1:45 PM Zbigniew Jędrzejewski-Szmek
wrote:
> This makes the assumption, which was also made earlier in the thread,
> that it's somehow impossible to check what bootloader is installed.
> Why? My bootloader is happy to tell me its version:
> $ bootctl
> ...
>
On Sat, May 4, 2019 at 9:36 PM Chris Murphy wrote:
>
> While handling this bug with a Common Bugs report is suboptimal, it
> has long been expected that users should read Common Bugs before
> installing or upgrading their systems. Making that advice more
> prominent might be reasonable.
I never
On Thu, May 2, 2019 at 5:31 PM Irina Boverman wrote:
>
> and this:
> dnf install -y --allowerasing git zip unzip python krb5-workstation
> java-1.8.0-openjdk java-1.8.0-openjdk-devel authconfig expect python3
> python3-requests python3-websockets pycurl which
> Fedora 29 - x86_64 - Updates
On Fri, May 3, 2019 at 8:18 PM Nicolas Mailhot via devel
wrote:
>
> Le vendredi 03 mai 2019 à 19:59 +0200, Dridi Boukelmoune a écrit :
> > On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel
> > wrote:
> > > Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko
On Fri, May 3, 2019 at 1:45 PM Nicolas Mailhot via devel
wrote:
>
> Le vendredi 03 mai 2019 à 12:04 +0100, Tomasz Kłoczko a écrit :
> > On Fri, 3 May 2019 at 11:04, Nicolas Mailhot via devel
> > wrote:
> > [..]
> > > You're assuming the only use is roolback. It's not
> >
> > Point taken. Can you
> Have you reported this to the dnf maintainers via bugzilla?
Not yet, I dumped my upgrade notes here and then browsed bugzilla for
error messages happening during my first f30 boot (turns out there's
already a ticket for all of them) and then time ran out.
Dridi
On Thu, May 2, 2019 at 8:30 AM Samuel Sieb wrote:
>
> On 5/1/19 8:16 AM, Dridi Boukelmoune wrote:
> > Here I had to remove the following packages (and they took some of
> > their dependencies away with them) beforehand:
> >
> > - python2-hawkey-0.31.0-2.fc29.x86_64
Hi,
On Tue, Apr 30, 2019 at 4:01 PM Matthew Miller wrote:
>
> It's been six months, and like clockwork, we release Fedora 30 today!
Congratulations! I have done in-place upgrades since Fedora 15 and I
was never let down. This time I even had scheduled a set of offline
tasks to do while my
On Sat, Apr 27, 2019 at 10:13 AM Jaroslav Mracek wrote:
>
snip
>> I just hope the DNF team would implement a retry on failed downloads
>> to not consider a repository unavailable right off the bat especially
>> when we have a list of mirrors to pick from.
>>
>
> We are working on improvement.
On Thu, Apr 25, 2019 at 11:50 PM Jan Pokorný wrote:
>
> On 25/04/19 09:35 +0200, Dridi Boukelmoune wrote:
> > Also please note that fedora-cisco-openh264.repo ships with
> > "skip_if_unavailable=true".
>
> off-topic: which in fact doesn't matter much, since you
1 - 100 of 277 matches
Mail list logo
