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 be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
I plan to
On 1/4/19 12:19 PM, Michael Schwendt wrote:
> 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
On Mon, Jan 07, 2019 at 08:58:06AM +0100, Miro Hrončok wrote:
> Depending on: lzma (23), status change: 2017-10-10 (64 weeks ago)
> afflib (maintained by: kwizart, rebus)
> afflib-3.7.16-7.fc29.src requires lzma-devel = 4.32.7-21.fc29
afflib was rebuilt this morning without the
On Fri, Jan 04, 2019 at 03:05:14PM -0500, Randy Barlow wrote:
> Following is the list of topics that will be discussed in the
> FESCo meeting Monday at 15:00UTC in #fedora-meeting-1 on
> irc.freenode.net.
> = New business =
>
> #topic #2021 F30 Change: Migrate Python-based Nautilus extensions to
>
Dne 05. 01. 19 v 19:57 Stephen John Smoogen napsal(a):
> On Sat, 5 Jan 2019 at 04:10, J. Scheurich wrote:
>> Hi,
>>
>> Still searching for a wdune fedora sponsor.
>> Who is the fedora sponsor for aqsis ?
> The maintainers for aqsis can be found from:
> https://src.fedoraproject.org/rpms/aqsis 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 07. 01. 19 11:09, Leigh Scott wrote:
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 retire
On Sat, 2019-01-05 at 14:35 +, Andrew Bauer wrote:
> I've got a couple of review requests in need of a reviewer:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1659709
Hello,
I'll review dymo-cups-drivers, could you review qt5-qtpbfimageformat
[1] in return?
Thanks,
Nikola
[1] https://bug
>
> You should adapt cinnamon away from lzma.
> I will retire lzma, you need to take it or deal with that.
Cinnamon never required lzma, it was it's 'Requires: openbox' that generated
the deps issue.
___
devel mailing list -- devel@lists.fedoraprojec
@mhroncok
Can you rerun the broken deps generator again as kio-extras is fixed, the list
will be a lot shorter :-)
https://koji.fedoraproject.org/koji/buildinfo?buildID=1177618
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send
On Mon, Jan 07, 2019 at 01:10:55PM -, Leigh Scott wrote:
>
> >
> > You should adapt cinnamon away from lzma.
> > I will retire lzma, you need to take it or deal with that.
>
> Cinnamon never required lzma, it was it's 'Requires: openbox' that generated
> the deps issue.
The dependency is
Hi all,
I've recently joined Red Hat in Brno, Czech Republic. I'll be working
part-time in "Plumbers team" and I'll be helping out with maintenance of
low-level packages like systemd, dracut and initscripts.
Best regards,
Jan Macku
___
devel mailing lis
On Mon, 2019-01-07 at 10:08 +0100, Zbigniew Jędrzejewski-Szmek wrote:
> Let's add https://pagure.io/fesco/issue/2047
> #2047 Need +1: policy change re. module default stream changes &
> Fedora Changes
Added.
signature.asc
Description: This is a digitally signed message part
_
OLD: Fedora-Rawhide-20190106.n.0
NEW: Fedora-Rawhide-20190107.n.0
= SUMMARY =
Added images:2
Dropped images: 6
Added packages: 0
Dropped packages:0
Upgraded packages: 22
Downgraded packages: 0
Size of added packages: 0 B
Size of dropped packages:0 B
Size
No missing expected images.
Compose FAILS proposed Rawhide gating check!
6 of 47 required tests failed, 4 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING**
below
Failed openQA tests: 22/131 (x86_64), 1/24 (i386), 1/2 (arm)
New failures (same test not fa
On 07. 01. 19 14:22, Leigh Scott wrote:
@mhroncok
Can you rerun the broken deps generator again as kio-extras is fixed, the list
will be a lot shorter :-)
It won't be that shorter, I can rerun it, but please wait for a compose and
mirrors and stuff.
--
Miro Hrončok
--
Phone: +420777974800
I found that here blame patch 201 efi-lockdown.patch.
I was build kernel with fedpkg without this patch and problem was gone.
# cat /sys/kernel/debug/dri/0/amdgpu_gca_config | xxd -e -
: 0003 0004 0004 0010
0010: 0001 0004 0010 0100 .
Thanks! I'll get on it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.o
https://fedoraproject.org/wiki/Changes/GNOME3.32
= GNOME 3.32 =
== Summary ==
Update GNOME to the latest upstream release, 3.32.
== Owner ==
* Name: [[User:Kalev| Kalev Lember]]
* Email: klem...@redhat.com
* Product: Workstation
* Responsible WG: Workstation
== Detailed Description ==
The new f
This is your final reminder that System-Wide Change proposals and
Change proposals that require a mass rebuild are due by the end of the
day on Tuesday 8 January.
Self-Contained changes are due 29 January. For more information on
Changes, see the Changes Policy page[1] on the Fedora Wiki.
[1] htt
On 1/7/19 1:58 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 be retired, please do so now with a proper
> reason:
> https://fedoraproject.org/wik
On 07. 01. 19 15:52, Gwyn Ciesla wrote:>> pygtk2
alexl, alt-gtk-de-sig, 0
weeks ago
caillon, caolanm, gnome-sig,
johnp, orphan, raveit65,
rhughes, rstrode,
On Mon, 07 Jan 2019 14:36:16 -
"Mikhail Gavrilov" wrote:
> I found that here blame patch 201 efi-lockdown.patch.
> I was build kernel with fedpkg without this patch and problem was
> gone.
>
> # cat /sys/kernel/debug/dri/0/amdgpu_gca_config | xxd -e -
> : 0003 0004 0004
In case someone finds the cloned repositories no longer work (missing `rpms` in
url), run in folder with said repositories:
```
ls -d * | xargs -i bash -c "cd {} || exit 255 ; git status &>/dev/null || exit
1 ; git remote -v | grep ^origin | tr -s '\t' ' ' | cut -d' ' -f2 | grep -v
rpms | sort
https://fedoraproject.org/wiki/Changes/DNF_UUID
== Summary ==
Right now, we estimate installed Fedora systems by counting unique IP
addresses which show up in our updates mirror statistics. We need
better data than that. There are some proposals for more complicated
systems, but a quick thing we
=
#fedora-meeting-1: FESCO (2019-01-07)
=
Meeting started by bowlofeggs at 15:00:00 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-01-07/fesco.2019-01-07-15.00.log.html
.
Meetin
Hello,
are there any plans to fix the package from FTBFS state since Fedora 25?
Does anybody disagree with me updating that package to the recent
upstream release (8.0.1)?
Cheers,
Björn aka besser82
signature.asc
Description: This is a digitally signed message part
__
Hello,
are there any plans to fix the package from FTBFS state since Fedora 25?
Does anybody disagree with me updating that package to the recent
upstream release (1.7.0)?
Cheers,
Björn aka besser82
signature.asc
Description: This is a digitally signed message part
__
Nice, so the script is broken and does not report the dependencies
correctly [1] and now js-jquery2 went unnoticed and get retired although
it is required by rubygem-jquery-rails, similarly to js-jquery1. I'm
going to ask for unretirement and I hope I did not miss the two week window.
Vít
[1]
ht
Dne 07. 01. 19 v 18:13 Vít Ondruch napsal(a):
> Nice, so the script is broken and does not report the dependencies
> correctly [1] and now js-jquery2 went unnoticed and get retired although
> it is required by rubygem-jquery-rails, similarly to js-jquery1. I'm
> going to ask for unretirement and I
On Mo, 07.01.19 11:34, Ben Cotton (bcot...@redhat.com) wrote:
> === Constraints ===
> * The Fedora community cares about privacy and is adverse to tracking
> measures. We don't want to track; just count.
Uh, so what's the story there? i mean, if you pass over the uuid you
make clients trackable,
On Monday, January 7, 2019 11:34:47 AM EST Ben Cotton wrote:
> The Fedora community cares about privacy and is adverse to tracking
> measures. We don't want to track; just count.
If this is ever implemented, we should probably notify end users and provide
an easy way to disable this. If you pass
On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
> > * The Fedora community cares about privacy and is adverse to tracking
> > measures. We don't want to track; just count.
> Uh, so what's the story there? i mean, if you pass over the uuid you
> make clients trackable, regardless
On Mon, Jan 07, 2019 at 12:30:53PM -0500, John Harris wrote:
> > The Fedora community cares about privacy and is adverse to tracking
> > measures. We don't want to track; just count.
> If this is ever implemented, we should probably notify end users and provide
> an easy way to disable this. If yo
On Mon, 7 Jan 2019 at 12:32, John Harris wrote:
>
> On Monday, January 7, 2019 11:34:47 AM EST Ben Cotton wrote:
> > The Fedora community cares about privacy and is adverse to tracking
> > measures. We don't want to track; just count.
>
> If this is ever implemented, we should probably notify end
On Monday, January 7, 2019 1:29:42 PM EST Matthew Miller wrote:
> On Mon, Jan 07, 2019 at 12:30:53PM -0500, John Harris wrote:
>
> > > The Fedora community cares about privacy and is adverse to tracking
> > > measures. We don't want to track; just count.
> >
> > If this is ever implemented, we sh
* Matthew Miller:
> On Mon, Jan 07, 2019 at 12:30:53PM -0500, John Harris wrote:
>> > The Fedora community cares about privacy and is adverse to tracking
>> > measures. We don't want to track; just count.
>> If this is ever implemented, we should probably notify end users and provide
>> an easy w
On Mon, Jan 07, 2019 at 07:39:08PM +0100, Florian Weimer wrote:
> >> If this is ever implemented, we should probably notify end users and
> >> provide
> >> an easy way to disable this. If you pass an identifier, that enables
> >> client
> >> tracking.
> > I agree -- it'll go in the release note
Once upon a time, Matthew Miller said:
> Hmmm. We have fedora.pool.ntp.org, in fact. I'm not sure who actually runs
> that!
That's the public NTP pool, which is usually the best option if you
don't want to (or have the resources for) operate your own NTP
infrastructure.
--
Chris Adams
_
searching by pygtk2 we have 367 matches , it is all to be retired ?
dnf repoquery --disablerepo='*' --enablerepo=rawhide
--enablerepo=rpmfusion-{,non}free-rawhide --available --whatrequi
res pygtk2 --alldeps --qf "%{repoid} %{sourcerpm}" --quiet | sed
's|\(-[^-]\+\)\{2\}src.rpm||' | sort
raw
On Mo, 07.01.19 13:32, Stephen John Smoogen (smo...@gmail.com) wrote:
> On Mon, 7 Jan 2019 at 12:32, John Harris wrote:
> >
> > On Monday, January 7, 2019 11:34:47 AM EST Ben Cotton wrote:
> > > The Fedora community cares about privacy and is adverse to tracking
> > > measures. We don't want to t
This change would appear more acceptable if it was combined with removing the
Fedora user agent patch for Firefox
(https://src.fedoraproject.org/rpms/firefox/blob/master/f/firefox-fedora-ua.patch),
which is simultaneously a worse privacy risk and a worse way to count users
than randomized UUIDs
After upgrading this morning I ran into some nasty issues with
sqlite-3.26.0-1.fc29 which seems utterly broken now with
python3-django-2.0.9-1.fc29 as described in this bug[0]. I thought I'd
start by consulting
https://bodhi.fedoraproject.org/updates/?packages=sqlite to see what
changed but m
On Mo, 07.01.19 13:28, Matthew Miller (mat...@fedoraproject.org) wrote:
> On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
> > > * The Fedora community cares about privacy and is adverse to tracking
> > > measures. We don't want to track; just count.
> > Uh, so what's the story
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?
I
On Mon, Jan 07, 2019 at 08:27:00PM -, Mark Otaris wrote:
> This change would appear more acceptable if it was combined with removing
> the Fedora user agent patch for Firefox
> (https://src.fedoraproject.org/rpms/firefox/blob/master/f/firefox-fedora-ua.patch),
> which is simultaneously a worse
On Mon, Jan 07, 2019 at 09:33:51PM +0100, Lennart Poettering wrote:
> I wonder if it is worth introducing an entirely new tracking concept
> here if you actually don't want to track but just count. The NTP
> approach has the benefit that you introduce no new tracking concept at
> all, but you just
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 be
included in reports regardless. The point is supposedly counting, n
On Monday, January 7, 2019 3:18:10 PM EST Lennart Poettering wrote:
> hence my recommendation to derive the any uuid for purposes like this
> from /etc/machine-id, by using a HMAC of some kind (see other mail).
I really don't think that this should be derived in any way from a machine id,
if it r
Adam Williamson writes:
> On Thu, 2019-01-03 at 22:40 -0600, Jason L Tibbitts III wrote:
>
>> But to be fair, MIT krb5 is not known for having great error output.
>> Not being able to start at all because the K/M has an enctype which is
>> acceptable and not at all deprecated according to the doc
On Mon, 7 Jan 2019 at 15:19, Lennart Poettering wrote:
>
> On Mo, 07.01.19 13:32, Stephen John Smoogen (smo...@gmail.com) wrote:
>
> > On Mon, 7 Jan 2019 at 12:32, John Harris wrote:
> > >
> > > On Monday, January 7, 2019 11:34:47 AM EST Ben Cotton wrote:
> > > > The Fedora community cares about
On Mon, Jan 07, 2019 at 04:04:24PM -0500, John Harris wrote:
> On Monday, January 7, 2019 3:18:10 PM EST Lennart Poettering wrote:
> > hence my recommendation to derive the any uuid for purposes like this
> > from /etc/machine-id, by using a HMAC of some kind (see other mail).
>
> I really don't t
On Mon, Jan 07, 2019 at 11:34:47AM -0500, Ben Cotton wrote:
> == Summary ==
> Right now, we estimate installed Fedora systems by counting unique IP
> addresses which show up in our updates mirror statistics. We need
> better data than that. There are some proposals for more complicated
> systems, b
On Mo, 07.01.19 16:04, John Harris (joh...@splentity.com) wrote:
> On Monday, January 7, 2019 3:18:10 PM EST Lennart Poettering wrote:
> > hence my recommendation to derive the any uuid for purposes like this
> > from /etc/machine-id, by using a HMAC of some kind (see other mail).
>
> I really don
On Monday, January 7, 2019 4:32:04 PM EST Lennart Poettering wrote:
> On Mo, 07.01.19 16:04, John Harris (joh...@splentity.com) wrote:
>
>
> > On Monday, January 7, 2019 3:18:10 PM EST Lennart Poettering wrote:
> >
> > > hence my recommendation to derive the any uuid for purposes like this
> > >
Lennart Poettering wrote:
> BTW, iirc intel used to count installations through the http ping
> check in their captive portal detection. Fedora runs a similar service
> which is used by NM, no? maybe that's a nicer solution too: add a http
> header field to the ping check that each client sets to "
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 be
included
On Monday, January 7, 2019 4:29:02 PM EST Zbigniew Jędrzejewski-Szmek wrote:
> If the sd_id128_get_machine_app_specific/... mechanism is used, this
> could be added to previous releases in a dnf update. This is an additional
> advantage over having a indepdent uuid for this.
If we do go forward wi
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 this information.
If we are just using this UUID to count m
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 this
On Mon, Jan 7, 2019, 7:31 PM Matthew Miller
wrote:
> On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
> > > * The Fedora community cares about privacy and is adverse to tracking
> > > measures. We don't want to track; just count.
> > Uh, so what's the story there? i mean, if yo
On Mon, 7 Jan 2019 at 15:34, Lennart Poettering wrote:
>
> On Mo, 07.01.19 13:28, Matthew Miller (mat...@fedoraproject.org) wrote:
>
> > On Mon, Jan 07, 2019 at 06:24:14PM +0100, Lennart Poettering wrote:
> > > > * The Fedora community cares about privacy and is adverse to tracking
> > > > measure
On Mon, Jan 7, 2019 at 4:55 PM Bruno Wolff III wrote:
>
> 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 var
> "JF" == John Florian writes:
JF> I thought I'd start by consulting
JF> https://bodhi.fedoraproject.org/updates/?packages=sqlite to see what
JF> changed but much to my surprise the newest build I see there is
JF> sqlite-3.22.0-5.fc28! Huh? Where are the f29 builds?
First, note that Bodhi do
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 incrementing a counter of "the number of
> times people have tried
Ben Cotton wrote:
> systems, but a quick thing we can do is implement a per-system UUID
> (unique identifier) and count that instead of IP addresses.
Please no! This is an inherent privacy violation. I hate software doing this
and I always opt out of it. I find it especially worrying that Free So
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 increment
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 wind
On 07. 01. 19 21:11, Sérgio Basto wrote:
searching by pygtk2 we have 367 matches , it is all to be retired ?
No, Gwyn already took it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To u
On Monday, January 7, 2019 5:20:55 PM EST Bruno Wolff III wrote:
> On Mon, Jan 07, 2019 at 22:54:46 +0100, Tom Gundersen wrote:
>
> So this allows better tracking than if you just had to go by IP, time and
> other information in the requests.
Keep in mind that we do not want tracking, at all. Ju
On Mon, 7 Jan 2019, 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
...
pygtk2alexl, alt-gtk-de-sig, 0 weeks
ago
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 at
Jason L Tibbitts III writes:
>> "RH" == Robbie Harwood writes:
>
> RH> I really don't think that "it won't work and there'll be error
> RH> messages" is an "extremely optimistic description".
>
> But to be fair, MIT krb5 is not known for having great error output.
I've spent a nontrivial am
On 07. 01. 19 18:13, Vít Ondruch wrote:
Nice, so the script is broken and does not report the dependencies
correctly [1] and now js-jquery2 went unnoticed and get retired although
it is required by rubygem-jquery-rails, similarly to js-jquery1.
This is interesting.
1. js-jquery2 provides jque
On Mon, Jan 7, 2019 at 4:57 PM, Stuart D. Gathman
wrote:
retiring pygtk2 retires most of Fedora desktops and gui apps, from
Gnome-shell to cinnamon to openbox. ;-)
Hm, sounds like there is a bad dependency in the chain somewhere.
pygtk2 is very much obsolete and should be allowed to disappear
mcatanz...@gnome.org wrote:
> On Mon, Jan 7, 2019 at 4:57 PM, Stuart D. Gathman
> wrote:
>> retiring pygtk2 retires most of Fedora desktops and gui apps, from
>> Gnome-shell to cinnamon to openbox. ;-)
>
> Hm, sounds like there is a bad dependency in the chain somewhere.
> pygtk2 is very much obs
On 1/7/19 5:04 PM, Jason L Tibbitts III wrote:
>> "JF" == John Florian writes:
> JF> I thought I'd start by consulting
> JF> https://bodhi.fedoraproject.org/updates/?packages=sqlite to see what
> JF> changed but much to my surprise the newest build I see there is
> JF> sqlite-3.22.0-5.fc28! Hu
On Mon, Jan 07, 2019 at 04:36:38PM -0500, John Harris wrote:
> My suggestion was not because of some fear that the machine ID would be
> leaked, but rather my personal opinion that this UUID should not be derived
> in
> any way from the machine ID.
John, what's the concern there? I agree that
On Mon, Jan 07, 2019 at 02:27:39PM -0600, Bruno Wolff III wrote:
> Is this data only going to be sent to the metalink or do the mirrors
> actually used, get the data?
That's a good question.
> Is the data going to be sent along with requests to non-Fedora repos
> (e.g. rpmfusion)?
Also a good qu
On Mon, Jan 07, 2019 at 04:06:52PM -0600, Bruno Wolff III wrote:
> >I have to say that I actually disagree with this. It is possible that Fedora
> >Remixes could send the variant as being the name of their Remix. While my
> >Remix wouldn't do this (it is privacy oriented, and ensures only free
> >s
https://fedorapeople.org/groups/389ds/ci/nightly/2019/01/08/report-389-ds-base-1.4.0.20-20190108gitf574332.fc29.x86_64.html
___
389-devel mailing list -- 389-de...@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject
https://bugzilla.redhat.com/show_bug.cgi?id=1663848
Orion Poplawski changed:
What|Removed |Added
Status|NEW |CLOSED
Fixed In Version|
On Mon, Jan 07, 2019 at 11:09:48PM +0100, Kevin Kofler wrote:
> Please no! This is an inherent privacy violation. I hate software doing this
> and I always opt out of it. I find it especially worrying that Free Software
> is now doing this more and more often, this used to be something only
> pr
Dear all,
You are kindly invited to the meeting:
Modularity WG (weekly) on 2019-01-08 from 15:00:00 to 16:00:00 UTC
At fedora-meetin...@irc.freenode.net
The meeting will be about:
Meeting of the Modularity Working Group.
More information available at: [Modularity Working Group wiki
page](
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?
I detailed it further down my message: my concer
> "RH" == Robbie Harwood writes:
RH> I've spent a nontrivial amount of time working on improving that,
RH> but am always willing to process more bugs in the
RH> documentation/errors area.
I know, and I don't mean to denigrate any work that's been done in
making the MIT KRB stack better. It'
> > 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?
>
> I detailed it further down my message: my concern is that t
A few concerns/comments (inline):
> === The problem ===
>
> * A. Currently, we can only count Fedora OS use by observing IP
> addresses. This is subject to undercounting due to NAT — and to
> overcounting due to short DHCP leases and laptops moving between work
> or school and home or coffee shop
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
when
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 spoofing too many would probably be considered
> a denial
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 spo
A new Fedora Atomic Host update is available via an OSTree update:
Version: 29.20190107.0
Commit(x86_64): 822093aa47c985d24d5f3a40ad213d68f7734be3bff872c757d39315048691a4
Commit(aarch64):
998b38c152b6808d7fa277eddadf87e5b2f73d923793328cff7985e67fa401bd
Commit(ppc64le):
82d4e740198440c3f7fcab41a
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 u
93 matches
Mail list logo