On Fri, Jul 07, 2023 at 16:15:14 -0500,
Michael Catanzaro wrote:
The local collection is a bit of a hole, but I like your suggestion to
put a short time limit on that. Perhaps we can collect for something
like one hour locally, then delete if the user has not consented to
upload before
On Thu, Jul 06, 2023 at 19:53:12 -0500,
Michael Catanzaro wrote:
Well this change proposal is for Fedora Workstation specifically.
That's in the title. :) I would envision installing
eos-event-recorder-daemon via a Recommends: from the
gnome-control-center and gnome-initial-setup packages
On Thu, Jul 06, 2023 at 14:32:04 -0500,
Michael Catanzaro wrote:
On Thu, Jul 6 2023 at 08:19:07 PM +0200, Vitaly Zaitsev via devel
wrote:
All telemetry collection MUST be an opt-in feature (disabled by
default). I'm strongly against enabling it by default.
As explained in the proposal
On Thu, Jul 06, 2023 at 20:17:27 -0500,
Michael Catanzaro wrote:
Remember, for avoidance of doubt, we will NEVER enable telemetry
upload without the user's consent, which is indicated by either (a)
not flipping the telemetry switch in gnome-initial-setup to the off
position, or (b)
On Thu, Feb 23, 2023 at 10:36:17 -0600,
Bruno Wolff III wrote:
Phillip is really close to releasing 4.6 and I want to get some
testing in rawhide before that happens. If we do find a problem, it
will be easier on him if we find it before the release. I ran a test
script that tests
Phillip is really close to releasing 4.6 and I want to get some testing
in rawhide before that happens. If we do find a problem, it will be easier
on him if we find it before the release. I ran a test script that tests
the features we mostly use, so I'm not expecting any problems.
On Fri, Jan 27, 2023 at 18:43:56 -0800,
Gordon Messmer wrote:
Second, I'd like to suggest that in the future, at least in Fedora,
for any "install" or "update" operation that dnf performs, dnf's
default behavior should be checking all of the direct and indirect
dependencies of the packages
On Thu, Jun 02, 2022 at 12:33:55 +0200,
Aleksandra Fedorova wrote:
Hello, everyone,
Please participate in the Fedora Annual Contributor Survey 2022!
* https://fedoraproject.limequery.com/2022
The survey is anonymous, it has 44 questions targeting Fedora
contributors of all kinds and asks
On Fri, Apr 01, 2022 at 10:06:35 -0700,
Kevin Fenzi wrote:
Short version:
We updated to koji 1.28.0 yesterday. It has a bug in it where it writes
out signed rpms as mode 0600, which prevents our sync process from
syncing those things. The compose finished and tried to sync, but of
course
Today's rawhide compose is taking a long time to sync on the primary mirrors.
It has been a mix of the update from the 28th and the one for today for
at least a couple hours. That is much longer than normal.
Did something fail part way through?
___
On Thu, Mar 24, 2022 at 21:06:44 +0100,
Fabio Valentini wrote:
On Thu, Mar 24, 2022 at 8:57 PM Bruno Wolff III wrote:
I don't really understand what you're saying here. Unless your update
is blocked by something else that is not "stable" yet *and* you don't
(or cannot) use a
On Thu, Mar 24, 2022 at 10:58:17 -0700,
Adam Williamson wrote:
On Thu, 2022-03-24 at 18:52 +0100, Ralf Corsépius wrote:
> If it was the latter, I couldn't find it in your message. Sorry.
It's actually quite simple: There are dozens if not hundreds of unpushed
updates pending due to the
On Wed, Mar 09, 2022 at 19:58:30 -,
Leigh Scott wrote:
On Wed, Mar 09, 2022 at 09:06:01 -0600,
Chris Adams
That is a very poor excuse for a slip, why would any one need it?
That is specified in the release criteria. I believe the rational is covered
there if you are really
On Wed, Mar 09, 2022 at 12:23:41 -0600,
Bruno Wolff III wrote:
On Wed, Mar 09, 2022 at 09:06:01 -0600,
The Fedora 36 beta is likely to slip because firefox was not building
successfully on i686, but was on other arches.
It is actually more complicated than I remembered. Firefox needed
On Wed, Mar 09, 2022 at 09:06:01 -0600,
Chris Adams wrote:
So I guess this is the part I don't really understand (and I guess why I
don't see this proposal as a "win") - how is i686 painful to package
maintainers for non-delivered packages? Maybe I'm just missing
something, but what causes
On Mon, Mar 07, 2022 at 15:04:21 -0500,
Robbie Harwood wrote:
Fabio Valentini writes:
For example, as far as I know, you need the 32-bit host libraries for
running 32-bit Windows applications in Wine. Dropping that would make
our Wine packages almost useless, since a large fraction of
On Wed, Feb 09, 2022 at 17:44:35 +,
"Daniel P. Berrangé" wrote:
Using API tokens over username/password is a good thing from a security
POV, but as you say, the process of creating the token and getting it
over to the client is horribly user unfriendly.
That depends on ypur threat
It looks like qt3, kdb and pgadmin3 still need to be rebuilt after the
recent build of postgresql 14.1 in rawhide, because they depend on
libpq.so.private13-5()(64bit).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
On Thu, Dec 30, 2021 at 12:19:14 +0100,
Vitaly Zaitsev via devel wrote:
On 30/12/2021 09:21, Chris Murphy wrote:
CPU is proprietary, the firmware is proprietary. Guess we can't trust
our computers?
RISC-V.
RISC-V isn't the answer. It is an ISA (with varients), not a computer. A
RISC-V
On Tue, Dec 28, 2021 at 14:51:35 +0100,
Kevin Kofler via devel wrote:
Can we trust the security code submitted by a Huawei employee to not contain
hidden government-developed backdoors? (Basically the same question as for
the existing NSA SELinux code…)
I think that same question could be
On Tue, Dec 28, 2021 at 14:45:59 +0100,
Kevin Kofler via devel wrote:
But there is the inherent assumption there that the set of software released
by Fedora is identical to the set of software the user trusts. In practice,
those sets will, sure, be overlapping (non-disjoint), but still
On Thu, Dec 16, 2021 at 17:27:29 -0500,
Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/DIGLIM
More specifically, it will make a system running Fedora attestable
without the need of using dedicated remote attestation protocols. In
fact, the assertion that a system is running a
On Thu, Nov 25, 2021 at 16:52:59 -0500,
Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/PostgreSQL_14
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 13 to version 14 in the non-modular (main) builds.
== Feedback ==
I'm all for it. I
On Sat, Oct 23, 2021 at 23:40:25 +0200,
Peter Boy wrote:
Fedora 35 comes obviously without Postgres module 9.6. Unfortunately, the
release change set doesn’t mention that. We need a clear indication and warning
of this.
That might be because 9.6 gets its last update in about two weeks.
On Thu, Oct 07, 2021 at 18:23:00 +0200,
Miro Hrončok wrote:
On 07. 10. 21 17:45, Ben Cotton wrote:
* We suggest users to remove packages that are no longer maintained
and may contain security vulnerabilities.
This makes perfect sense.
* We make sure that archaic packages do not break
On Mon, Sep 20, 2021 at 18:16:17 +0200,
Jonathan Schleifer wrote:
Am 20.09.21 um 13:31 schrieb Miro Hrončok:
0ad ignatenkobrain, orphan, pwalter 1
weeks ago
I would be interested in becoming a (co)maintainer for this, but would
need sponsorship.
I think I
On Tue, Sep 21, 2021 at 17:44:07 -0500,
Bruno Wolff III wrote:
So it looks like, one way or another the mozjs78 stuff will need to
get patched after the source gets extracted in the build step.
I found the reference to how to patch mozjs78 in 0ad. You need to
have your patch file drop off
On Tue, Sep 21, 2021 at 16:06:24 -0500,
Bruno Wolff III wrote:
I thought of that. I tried some naive ways to do that without success.
I'm not sure if any extra python packages are needed. Probably not,
but if so it won't work since those will be for 3.10.
There doesn't seem to be a standard
On Tue, Sep 21, 2021 at 23:03:12 +0200,
Miro Hrončok wrote:
On 21. 09. 21 19:19, Bruno Wolff III wrote:
If there is no Python version runtime dependency there, you could
temporaily use the python3.9 package to build the bundled mozjs78.
I thought of that. I tried some naive ways to do
On Mon, Sep 20, 2021 at 18:16:17 +0200,
Jonathan Schleifer wrote:
Am 20.09.21 um 13:31 schrieb Miro Hrončok:
0ad ignatenkobrain, orphan, pwalter 1
weeks ago
I would be interested in becoming a (co)maintainer for this, but would
need sponsorship.
The main
On Tue, Jul 06, 2021 at 18:13:45 +0200,
Miro Hrončok wrote:
On 06. 07. 21 17:13, Zbigniew Jędrzejewski-Szmek wrote:
This is Python 3.10 related.
https://docs.python.org/3.10/whatsnew/3.10.html#removed
"Remove deprecated aliases to Collections Abstract Base Classes from the
collections
On Sat, Aug 14, 2021 at 09:19:55 -0700,
Kevin Fenzi wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1920183
basically OOM kills kojid, which restarts kojid, which restarts the
build, which kills kojid, etc...
I've tried all kinds of things here, but haven't been able to find any
way to
On Wed, Aug 04, 2021 at 05:08:40 -0500,
Bruno Wolff III wrote:
On Tue, Aug 03, 2021 at 12:51:41 +0200,
"Antonio T. sagitter" wrote:
Hi all.
I need help for failed builds of IceCat bacause of this error (in
x86_64 and i386 architectures only):
Thanks for working on that. The
On Tue, Aug 03, 2021 at 12:51:41 +0200,
"Antonio T. sagitter" wrote:
Hi all.
I need help for failed builds of IceCat bacause of this error (in
x86_64 and i386 architectures only):
Thanks for working on that. The last good icecat in rawhide doesn't work
with the latest glibc. Because I use
The upstream fix looks good and squashfs-tools-4.5-2 has the patch and is
in today's rawhide compose.
There will be a minor point release for squashfs-tools in the near future
with the fix. But phillip is waiting a short bit to see if any other
problems get discovered before making a new
On Fri, Jul 23, 2021 at 02:20:50 -0500,
Bruno Wolff III wrote:
Phillip released 4.5 which has some new functionallity, some clean up
and some bug fixes. It looks like he worked pretty hard on it for
I had a successfull build after tonight's compose started, so the
earliest it will show up
Phillip released 4.5 which has some new functionallity, some clean up and
some bug fixes. It looks like he worked pretty hard on it for about
the last 6 months. I don't think that the new functionallity will break
any of our normal stuff, but if something breaks that uses it, that would
be a
I knew that a bunch of java stuff was going away, but I am not sure what
the impact of that is going to be. Is there a feature page or similar
that summarizes what the effect we be?
I have one package that produces a java program using ant that I like to be
able to keep building somehow.
On Thu, Jun 03, 2021 at 21:34:22 +0200,
Miro Hrončok wrote:
On 03. 06. 21 20:29, Matthew Miller wrote:
On Thu, Jun 03, 2021 at 01:00:23PM -0500, Bruno Wolff III wrote:
Given that badges are being handed out, it is clear the survey is
not anonymous.
When the survey is complete, you get
On Wed, Jun 02, 2021 at 18:14:50 +0200,
Aleksandra Fedorova wrote:
Hello, everyone,
Please participate in the Annual Fedora Contributor Survey 2021!
* https://fedoraproject.limequery.com/2021
The survey is anonymous, it has 44 questions and It is targeting
Fedora contributors of all kinds
On Wed, Feb 17, 2021 at 07:35:20 -0600,
Bruno Wolff III wrote:
Is their going to be an updated build soon? I tried to build rc4
(which looks to be what was released), but I need to figure out how to
get both x86_64 and i686 rpms built when using fedpkg local. If there
isn't going
On Fri, Feb 05, 2021 at 16:17:12 +1000,
David Airlie wrote:
Has anyone got a backtrace they could put in a bug? I'm not seeing a
crash with X.org here in my test VMs.
I have only had problems with wine so far. But I use xfce and lightdm and
they seem to work. I filed bug 1924933 for the
On Wed, Nov 11, 2020 at 16:53:26 +0100,
Vitaly Zaitsev via devel wrote:
On 11.11.2020 16:09, Bruno Wolff III wrote:
If not, should I replace the - with a . in the version or should I
move git.1 into the release. This is the first tag using this naming
pattern, so I don't know the next tag
I looked at
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
and didn't see dashes specifically covered.
In my case, squashfs-tools has a new upstream release tagged 4.4-git.1 .
I'm guessing that using 4.4-git.1 as the version would be at least
confusing and might be
On Wed, Sep 02, 2020 at 00:12:34 -0600,
Chris Murphy wrote:
No user creation in Workstation Live, for a long time. First user is
created by GNOME Initial Setup. Root user is not enabled.
I was using the XFCE spin, so that might be different.
___
On Tue, Sep 01, 2020 at 22:09:57 -0600,
Chris Murphy wrote:
On Tue, Sep 1, 2020 at 8:16 PM John M. Harris Jr wrote:
You're using net installer? The Live doesn't have user configuration
in the installer.
I did some live installs last week of rawhide and was able to create one
user
On Tue, Jul 07, 2020 at 15:16:22 -0400,
Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/PostgreSQL_13
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
They are going to release 13beta3
On Tue, Jul 07, 2020 at 15:16:22 -0400,
Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/PostgreSQL_13
== Summary ==
Update of PostgreSQL (`postgresql` and `libpq` components) in Fedora
from version 12 to version 13 in the non-modular (main) builds.
While I like to have the latest
On Thu, May 21, 2020 at 18:46:14 -0400,
Dennis Payne wrote:
The reason for the crashing on startup is that it is not loading the
font.
I have fixes for this out. Even though this currently just affects rawhide,
I have fixed builds for f31 and f32 as well, so if a font file moves a
simple
On Fri, May 22, 2020 at 09:56:48 -0500,
Bruno Wolff III wrote:
On Fri, May 22, 2020 at 09:03:31 -0500,
Bruno Wolff III wrote:
I'll look harder to see if I can get a copy of 3.67. It isn't
available any more from where I got it and I may have lost the copy
I had downloaded to evalute
On Fri, May 22, 2020 at 09:56:48 -0500,
Bruno Wolff III wrote:
On Fri, May 22, 2020 at 09:03:31 -0500,
Bruno Wolff III wrote:
I'll look harder to see if I can get a copy of 3.67. It isn't
available any more from where I got it and I may have lost the copy
I had downloaded to evalute
On Fri, May 22, 2020 at 09:03:31 -0500,
Bruno Wolff III wrote:
I'll look harder to see if I can get a copy of 3.67. It isn't
available any more from where I got it and I may have lost the copy I
had downloaded to evalute a number of years ago.
There is some source code archived at:
https
Copying me directory was a good idea to get my attention. Fedora list
mail goes to another folder and it is easy for me to miss stuff, though
I was planning to double check this thread for objections before doing
a retire.
On Thu, May 21, 2020 at 18:46:14 -0400,
Dennis Payne wrote:
The
On Wed, May 20, 2020 at 11:31:37 -0400,
Neal Gompa wrote:
On Wed, May 20, 2020 at 11:06 AM Zbigniew Jędrzejewski-Szmek
wrote:
I'm seeing this when running fedora-review:
$ fedora-review -b 1838033
INFO: Processing bugzilla bug: 1838033
...
INFO: Installing built package(s)
warning: Found
The current nethack-vultures uses a very old version of nethack. It is
bundled because a customized version is used to support the isometric view.
There exists source for a slight more recent version, but it is still
very old. The upstream web site is now dead and they weren't very good
about
On Wed, May 13, 2020 at 13:32:19 +0200,
Bohdan Khomutskyi wrote:
For optimization of the SquashFS, I will work on requesting the
support of the required functionality in the Pungi compose build
software.
Note that squashfs-tools 4.4 just went into rawhide a couple of days ago.
By default
I finally built 4.4 for rawhide. We already had back-ported zstd, but this
gives us reproducible builds and a few other things.
I'm noting this here, because squashfs-tools is used for some important
stuff and in the case it breaks something I wanted people to know
that it might be due to
On Mon, Apr 06, 2020 at 16:02:34 +0100,
Leigh Griffin wrote:
Our stakeholder and engagement point as a team is Fedora Council. If you
have issues with how this was handled from a relationship perspective then
please take that up with the Council. We have engaged with fesco in the
past at the
On Wed, Apr 01, 2020 at 17:21:14 -0400,
Paul Frields wrote:
That statement rings hollow for me, when Github is arguably the single
biggest vendor of open source in the world, no part of itself is open
source, and thanks to its pervasiveness, open source has won the war
of how development
On Wed, Apr 01, 2020 at 12:39:21 +0200,
Florian Weimer wrote:
* Bruno Wolff, III:
RHEL is a special case, as CENTOS provides a free drop in replacement
and switching from CENTOS to Fedora shouldn't be much work. Is there
other proprietary software at the OS level or above, that is used
On Tue, Mar 31, 2020 at 13:08:05 -0400,
Matthew Miller wrote:
We did communicate as the very top line of our gathered requirements that
open source is essential to our community and central to our feedback. I'm
not trying to be soft on that. Let's just not do purity-test level
assessments and
On Tue, Mar 31, 2020 at 10:33:46 -0400,
Matthew Miller wrote:
I understand the attachment we have as a project to Pagure -- someone
in our community made it, after all, and lots of others have made
direct and indirect contributions. I feel that too! But, we all know
that it needs significant
On Tue, Mar 31, 2020 at 12:55:39 +0200,
Tomasz Torcz wrote:
Being self-hosted is a nice goal, but not important enough.
There are parts of Fedora infrastructure which are not using Fedora,
but other distributions like RHEL. We seem to have not problem in
using proprietary SAAS solutions for
On Mon, Mar 30, 2020 at 15:30:20 -0400,
Neal Gompa wrote:
I barely remember plague (it was going away when I started as a
packager). Plague was free software, but the build system for Fedora
Core was not. That and Plague were both replaced with Koji in 2007. It
was a great day, indeed.
On Mon, Mar 30, 2020 at 14:42:33 -0400,
Alex Scheel wrote:
Have you tried to use Pagure as a development based git forge? And not
just as a dist-git hosting location? It needs a lot of help! More than the
current resources provide.
I've used the PR features a bit in a dist-git context. I
On Mon, Mar 30, 2020 at 17:20:04 +0100,
Leigh Griffin wrote:
On Mon, Mar 30, 2020 at 5:06 PM David Kaufmann wrote:
We are trying to reduce the total ownership of the team to allow us to
provide value on initiatives that are requested of us by our stakeholders.
Pagure has value beyond
On Mon, Mar 09, 2020 at 18:11:32 +0100,
Fabio Valentini wrote:
On Mon, Mar 9, 2020 at 5:57 PM Bruno Wolff III wrote:
I'm also not sure how you would detect that from the package metadata
... query all packages for their file contents, and then show
conflicts when two packages own the same
On Fri, Mar 06, 2020 at 21:35:52 +0100,
Fabio Valentini wrote:
Hi all,
With the fedora 32 release drawing near, it might be a good time to
check if any of your packages still have broken dependencies in the
fedora 32 (+testing) repositories. I've been working on just the thing
you need:
Is
On Mon, Feb 17, 2020 at 21:32:30 +,
Ronaldo Mercado wrote:
I would like to see an example package where you experience this problem.
In my case, greyhounds was the normal case. raidem was the enum should have
been a typedef case.
For greyhounds, I didn't make an exception in the
On Sun, Feb 16, 2020 at 07:24:10 -0600,
Richard Shaw wrote:
So I have several FTBFS bugs most likely from the new gcc being more
pedantic. I understand the bug at a high level but I think it would be nice
if someone who really understood it could perhaps document strategies for
figuring out
On Thu, Feb 06, 2020 at 07:32:09 -0600,
Bruno Wolff III wrote:
5.6.0-0.rc0.git2.1.fc32.x86_64 works. If last nights rawhide compose
finishes successfully this morning, there should be a working kernel
in the repo. The nodebug repo hasn't been updated since the work
around was implemented
On Thu, Feb 06, 2020 at 13:02:32 +,
"Richard W.M. Jones" wrote:
I tried out this kernel:
- kernel-5.6.0-0.rc0.git1.2.fc32.x86_64
It gets to grub, lets you select the kernel, but apparently no
further. It's kind of frustrating to debug because either it produces
*no* messages at all even
I filed ticket https://pagure.io/releng/issue/9197 to request that
glob2 be unretired. The ticket is closed as completed, but the f32
branch still appears as a dead package. Am I supposed to fix this,
more time is needed for the process to really finish or did something
get missed?
P.S.
On Wed, Jan 22, 2020 at 10:28:52 -0500,
Neal Gompa wrote:
We don't need to. There are improvements that people would like, and
that does take development effort. That's the piece that requires
manpower to go faster.
In my opinion, I think this is where Red Hat should be helping. Pagure has
On Mon, Sep 16, 2019 at 13:15:08 -0700,
Samuel Sieb wrote:
On 9/16/19 1:08 PM, Alessio wrote:
- Can a user running a 32 bit F30 upgrade to F31?
No. From the change page:
"686 users will not be able to upgrade, and will have to move to
another supported arch. "
You can crossgrade using
On Mon, Sep 09, 2019 at 19:01:59 -,
vvs vvs wrote:
No, I don't think so. I'm using some (non Fedora related) applications which
use every bit of available memory. It's a bit stressed just as it is, but
losing additional couple of megabytes for no useful reason will be too much a
hit.
On Mon, Sep 09, 2019 at 18:23:18 -,
vvs vvs wrote:
Anyway, I'm not expecting that something will change because of that
discussion. It is just bad that the interests of users are of a lower priority
then some purely bureaucratic reasons.
It isn't happening because of bureaucratic
On Mon, Sep 09, 2019 at 18:06:02 -,
vvs vvs wrote:
Yes, thanks. Sadly, I see that I have no choice but to switch to another
distribution even though I'm using 64-bit CPU. It's just that the memory can't
be upgraded and buying new computer just to keep running Fedora is not viable.
It's
On Mon, Sep 09, 2019 at 17:55:06 -,
vvs vvs wrote:
First of all thanks for the link. It just proves that the SIG's expectations
were too high.
If I understand it all correctly, the main reason to drop i686 repo was the
mailing list inactivity? Is that right? So everyone interested in
On Mon, Sep 09, 2019 at 14:52:07 -,
vvs vvs wrote:
May be there are more interested people that we know, but they are not reading
that list. There will just be just every man for himself and Fedora has failed
to recognize that.
This requires time and effort too. Nobody will appear just
On Fri, Aug 30, 2019 at 11:17:11 -0700,
Kevin Fenzi wrote:
Well, in the squashfs-tools case these are in the looaside cache, so you
could (all be it ugly looking), use:
I got a warning about not having urls for a couple of files in the
squashfs-tools package from release monitoring.
The bug which has the comment is:
https://bugzilla.redhat.com/show_bug.cgi?id=1747102
These are based on some man pages used in Debian at one time, but do not
track changes in the
I cross graded a laptop from i686 to x86_64 yesterday using dnf and it
went pretty well without a reinstall. It also ran fine using an x86_64
kernel with i686 user space during the transition.
I noticed that at least with using --forcearch=x86_64 that installing
two packages that had names
On Wed, Jun 26, 2019 at 14:19:26 -0600,
Chris Murphy wrote:
Short version: Fedora should take responsibility for the bootloader
being up to date, by updating it during major version upgrades. This
is already the case on UEFI with conventional installations. I'd like
to make sure it always
On Mon, Jun 24, 2019 at 23:17:30 -0500,
Justin Forbes wrote:
It is not a violent cheat. It was proposed this way 2 years ago. At
the time a SIG was created to maintain i686 so that it could continue
as a secondary arch. They are inactive. See the post in the SIG there.
When a call for a
On Wed, Jun 19, 2019 at 10:44:41 -0700,
Kevin Fenzi wrote:
The last rawhide compose that completed was 2019-06-09 (10 days ago now).
A lot of the incomplete composes are actually usable for updates and I have
been getting systems updated and things have worked reasonably for the most
On Fri, Jun 07, 2019 at 08:37:57 -,
Petr Pisar wrote:
On 2019-06-06, Stephen Gallagher wrote:
Might be worth asking if there's a reason to need this offline. If the
exact commit ID is stored in Koji and is authoritative, also tagging
it into git might be convenient for offline purposes.
On Mon, Jun 03, 2019 at 12:47:53 +0200,
Hans de Goede wrote:
I once maintained this, it seems that Bruno, who took it over,
no longer has time to maintain this.
Yeah, but leave me as a co-maintainer as things might get better. I did some
CI work for squashfs-tools a couple of weeks ago, so
On Mon, Jan 07, 2019 at 22:00:25 -0500,
Matthew Miller wrote:
Since there is no personal information attached, I don't see how on the face
of it this is a privacy violation. I want to take this concern seriously,
but I need more to go on than "this is inherent". Can you elaborate?
From the
On Tue, Jan 08, 2019 at 00:44:26 -0500,
John Harris wrote:
On Tuesday, January 8, 2019 12:32:45 AM EST Bruno Wolff III wrote:
The cost for pretending to be lots of machines is also reduced a lot in
this scheme over having to connect from lots of different IP addresses.
Though at some point
On Mon, Jan 07, 2019 at 21:43:46 -0500,
Matthew Miller wrote:
On Mon, Jan 07, 2019 at 02:27:39PM -0600, Bruno Wolff III wrote:
Is this going to happen on install or upgrade before there is a
chance to turn it off?
Maybe? Keep in mind that you are _already_ contacting the mirror systems
On Mon, Jan 07, 2019 at 17:44:59 -0500,
John Harris wrote:
We don't need to be thinking of more things to track about the user, but ways
to prevent tracking and still get the counts the Council wants.
There are two mutually opposed sides here. The users need to consider how they
might be
On Mon, Jan 07, 2019 at 22:54:46 +0100,
Tom Gundersen wrote:
You could move the rotation to the client by hashing the UUID with a
timestamp of sufficiently coarse granularity (a week?) before submitting it.
Then you make sure that all UUIDs submitted by a given machine during a
given time
On Mon, Jan 07, 2019 at 17:04:11 -0500,
John Harris wrote:
On Monday, January 7, 2019 5:00:48 PM EST Stephen Gallagher wrote:
I think the only useful data we could get from unknown variants would
be "the number of times we see an unknown variant". So I think
throwing it away and just
On Mon, Jan 07, 2019 at 16:41:46 -0500,
John Harris wrote:
On Monday, January 7, 2019 4:31:29 PM EST Bruno Wolff III wrote:
If the strings aren't checked when they are received, they could be
anything.
The system varient also has the same issue. You shouldn't trust
the clients supplying
On Mon, Jan 07, 2019 at 16:00:46 -0500,
John Harris wrote:
On Monday, January 7, 2019 3:27:39 PM EST Bruno Wolff III wrote:
Are the UUIDs going to be sanity checked so that NSFW UUIDs don't show up
in reports?
I don't see how a UUID could possibly be NSFW, or why UUIDs would ever
Is this data only going to be sent to the metalink or do the mirrors actually
used, get the data?
Is the data going to be sent along with requests to non-Fedora repos (e.g.
rpmfusion)?
This will make it much easier to spoof being lots of systems. Is there some
plan to mitigate this risk?
On Wed, Dec 19, 2018 at 11:28:16 +0100,
Igor Gnatenko wrote:
Seems that I missed writing announcement, but there is a package
called `gnupg1` which provides `gpg1` binary.
So you should be fine with that I hope. And sorry for this trouble.
Thanks for the help.
I'm not sure why I didn't
gnupg2 is now obsoleting gnupg and the previous gpg command is not available.
The change page said gpg would be renamed gpg1, but this was not done.
Unfortunately gpg2 will not read my existing secret keys. (They are pretty
old and probably should be replaced.) For now using rpm --nodeps
On Wed, Dec 12, 2018 at 12:37:24 -0600,
Bruno Wolff III wrote:
On Thu, Dec 06, 2018 at 14:29:15 +,
"Richard W.M. Jones" wrote:
Anyway it seems like Rawhide isn't getting new nodebug kernels.
- Latest nodebug kernel:
kernel-4.20.0-0.rc1.git4.2.fc30.x86_64.
1 - 100 of 1085 matches
Mail list logo
