Re: Fedora's GPG key in DNS(SEC)

[Jan Pokorný]

On 3/10/21 1:32 PM, Petr Menšík wrote:

I think Björn's point is valid note. Because DNSSEC is used to verify
email of used key, but fedora.repo does not contain any hint about how
email in GPG key should look like. Also does not contain fingerprint of
such key. It would be nice to include email of included GPG key in repo
file itself. If actual email in GPG did not match, dnf would refuse such
key unless explicitly requested by user.

What if we added to repos:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch
gpgkeyid=mailto:fedora-$releasever-prim...@fedoraproject.org

This way dnf could map DNSSEC validated email to repository. It would be
user-verifiable, when he or she would add a new repository downloaded
from any site. 

Excuse me if I am overthinking this, but "from any site" is that detail
wherein the proverbial devil is, I think.

I'd say you would want DNF to a priori realize that the domain part from
said "gpgkeyid=" indeed (partially) matches the domain you obtained this
very repo file from (prior to redirections[*]) be it either in the form
of "dnf install .rpm" or hypothetical "--repofromrepopath"
counterpart of "--repofrompath" command (since baseurl= can generally
differ from where you obtain the repo from, but the same logic could
be applied when that's not the case).

In turn, that would restrict the location from where you can obtain
the repo file smoothly without alerts to only the domain(s) stricly
bound to the domain used in the address within gpgkeyid= (creating
thus a concept of authoritative repo file source).  That would
apply on the surfacing URL only[*].

Otherwise, I think someone could be tricked to start from installing
https://rpmfusion-mirror.seams-leg.it/rpmfusion-free-release.noarch.rpm
and crafted gpgkeyid= in the installed repo would not exactly help.

Of course, applies only to cases of entirely foreign by then
repositories, like RPM Fusion (use case: visit its web [DNS
must have been trusted already], follow the instructions here,
be spared from a fraudulent mirror right from the start).

For Fedora (Linux) incremental versions, there should really be
some kind of a seamless "rolling trust" mechanism as discussed
in other part of the above message.

[*] feels like a compromise of redirect chain would still be captured
with the whole mechanism, but I might have missed something/a lot

--
Jan (poki)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Firefox crashes at Rawhide

[Jan Pokorný]

On 03/12/19 13:29 +0100, Martin Stransky wrote:
> Just FYI, Firefox is recently crashing on Rawhide due to two independent
> issues as rawhide gets all builds automatically:
> 
> 1) PGO mis-compilation/Firefox bug
> (https://bugzilla.redhat.com/show_bug.cgi?id=1779082). Please use 'npgo'
> builds from koji.
> 
> 2) glibc update (https://bugzilla.mozilla.org/show_bug.cgi?id=1600574#c8)
> You can disable e10s as a workaround (set MOZ_FORCE_DISABLE_E10S=1 or
> browser.tabs.remote.autostart at about:config)

Thanks for the heads-up, for me, I seem to have been forced to
downgrade down to glibc-2.30.9000-20.fc32 so as to fix 2) reliably
("env MOZ_FORCE_DISABLE_E10S=1 firefox" made the actual content
to render, but led to a crash upon tab being closed or so).

-- 
Jan (Poki)


pgpQj96EOOAwx.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Encrypted DNS in Fedora

[Jan Pokorný]

On 04/11/19 10:40 -0600, Michael Cronenworth wrote:
> IMHO, this should be our number one priority over modules, new
> spins, or whatever paint color the bike shed needs to be today.
> I would like to see DNS over TLS (DoT) with DTLS at the very least.

I may be wrong, but it seems to me the usual plaintext by default
system wide policies regarding name resolution is what drives some
famous applications to bypass system altogether, perhaps overboard
from other perspectives (e.g. in steep contrast with crypto limits
unification, whereby not abiding the system policies is deemed bad
practice): https://bugzilla.redhat.com/show_bug.cgi?id=1751410

-- 
Jan (Poki)


pgpaYpxSjWwhm.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: HEADS-UP: Asciidoctor 2.0.10

[Jan Pokorný]

On 29/09/19 16:24 -0400, Todd Zullinger wrote:
> I wrote:
>> I'm planning to push asciidoctor-2.0.10 to rawhide in the
>> next few days.
> 
> This has now been built and should show up in the next
> rawhide compose.

Tried rebuilding booth to see if there will be any differences in the
generated man pages (utilizing asciidoctor), and my observations are:

* no angle brackets around what looks like a hyperlink

* sanitized e-mail address rendering (previously, they'd be doubled
  when already enclosed in angle brackets)

So far so good, except for:

* broken "verbatim code lacking explicit literal block markup" rendering

"visual" (as in actually viewing the man page) diff:

-   ticket="manual-ticket"
-   [...]
-   mode = manual
-   [...]
+   ticket="manual-ticket" [...] mode = manual [...]

I rather account this to a broken source file (there are still some
pre-existing bits, such as spurious underlining, that are to be cleaned
up regardless of the Asciidoctor version); this is to resolve that:

https://github.com/ClusterLabs/booth/pull/78

>> This is a major bump from our current 1.5.8, but upstream
>> has worked hard to fix regressions found since the initial
>> 2.0.0 release back in March.
>> 
>> The 2.0.0 release notes can be found at:
>> 
>> https://github.com/asciidoctor/asciidoctor/releases/tag/v2.0.0
>> 
>> The subsequent minor release are covered at:
>> 
>> https://github.com/asciidoctor/asciidoctor/releases

-- 
Jan (Poki)


pgp19S7rFLiEm.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Laptop powerdown when early boot incl. bootloader phase stuck (Was: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt)

[Jan Pokorný]

On 20/08/19 20:59 -0600, Chris Murphy wrote:
> There is no good reason for the current behavior, in particular on a
> laptop. And it's fail danger, not fail safe. The very simple work
> around for the computer shutting off in 3 minutes of inactivity and
> you don't like that? Power it back on and enter your passphrase.
> Shockingly easy and obvious. Unless of course you're stuck somewhere
> and in fact want to use your laptop as a heating pad.

Just that the particular corner case is not perceived in isolation,
there are other early-boot-stuck situations that would make sense
to deal with in the same fashion even if the sources are completely
different (predictability is more important from user's POV, IMHO).

One such other situation is having the bootloader (grub2) failed and
hence be stuck in 'press a key to continue' or just staying in the
selection menu without any timeout ticking for whatever reason.
That's directly comparable to the LUKS prompt without any attention
for a prolonged time.

With grub2, situation is actually worse, since without having any
means to control CPU throttling (which is already present by the
time one is to enter LUKS password), laptop will indeed become
said "heating pad" after a bit (one could for instance enter the
grub prompt if it's deemed a feature for some).

-- 
Poki


pgpfidGgFp6BI.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Set skip_if_unavailable default to false

[Jan Pokorný]

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'll, sooner
or later and whether you want or not, receive non-free (in a sense)
binaries over the native Firefox channel (guidelines yada yada yada)
anyway: https://bugzilla.redhat.com/show_bug.cgi?id=1648024

-- 
Jan (Poki)


pgpOTt9t1nXkd.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: kronosnet - PRs and package maintenance

[Jan Pokorný]

On 25/04/19 10:53 +0100, Phil Wyett wrote:
> I tried make contact directly a couple of weeks ago via email,
> with no luck.
> 
> I currently have a number of Pull Requests (PR) against the package
> and further updates to do if allowed.
> 
> I am not sure if the package is going to be orphaned or the
> maintainer(s) just do not have the necessary time to dedicate to the
> package. I am happy help and if you wish a co-maintainer for the
> package, please let me know, as I would be happy to assist.

To be noted that even the package review process (rhbz#1507103)
received some background punches in the pursuit of the inclusion
(the package wasn't alright when I was the reviewer), which may be
indicative of the lack of competencies later on, perhaps something
that the process, when carried on properly, aims to underpin from
the start.

Wish you luck, Phil, with obtaining the maintainership/admin for
that component if you want to afford the package a proper care
(and thanks for that).

-- 
Jan (Poki)


pgpd9baYtmGB9.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: More than 10% of all Fedora spec files are not POSIX sh compliant

[Jan Pokorný]

On 22/03/19 19:17 +0100, Dridi Boukelmoune wrote:
> On Fri, Mar 22, 2019 at 6:04 PM Japheth Cleaver  
> wrote:
>> IMO the situation that we're in now ("Assume you're running in
>> bash, but called as -/bin/sh") is a worst-of-both-worlds middle
>> ground, somewhat akin to mandating webpages be written in IE Quirks
>> Mode for all time. It's neither pedantically correct, nor flexible
>> for users and downstreams. And the resolution from all of this last
>> time remains lacking in the guarantees that an independent spec
>> should have:
> 
> The result is what we call bashisms where people put /bin/sh in their
> shebangs but don't realize they are using GNU extensions, and that
> goes for "standard" programs like awk too where people are not aware
> of the differences regarding what's on their machine and what POSIX
> mandates.

Good point, and that's something capable of making upstream
maintenance cumbersome at times (sed is a common pet peeve),
but that's an order of magnitude more demanding level when it
comes to portability, and with Fedora settled firmly just around
GNU approaches and extensions, there's hardly a pressing need for
the spec files to come anywhere close (but if so, the restrictions
should not be limited to shell interpreter alone as remarked,
since POSIX compliance is a wider topic).

> So with both a default non-POSIX-compliant shell (by default, I'm
> aware) and non-POSIX-compliant options to the basic commands it takes
> more effort to write portable shell.
> 
> To be clear, bash is my favorite shell and the one I use, but I'd
> prefer that running it as sh or /bin/sh would be enough to enter
> POSIX mode.

-- 
Jan (Poki)


pgpvqAxMo6aKZ.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: sway SIG

[Jan Pokorný]

On 18/03/19 16:22 +0100, Till Hofmann wrote:
> there's been a rising number of people interested in sway, the
> i3-compatible Wayland compositor. At the same time, with the recent sway
> 1.0 release, the packaging work is also increasing, as more and more
> components are split into separate projects.
> 
> For this reason, we thought about creating a sway SIG. The goal of the
> SIG is simple: package all components of sway and make sure that Fedora
> provides a good user experience with sway. Creating a SIG would allow us
> to coordinate better and also take care of the packages as a team (with
> easier ACLs without proven packager status etc).
> 
> There's been ongoing discussions on BZ [1] with some people showing
> interest in a SIG. The main purpose of this email is to see who else
> would be interested in contributing to sway. If we can find enough
> people, I'd continue with the SIG, as outlined in [2].

Thanks for opening this and count me in, please :)

-- 
Poki


pgp9Hh5wSpwzJ.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating Rawhide vs GPG keys

[Jan Pokorný]

On 11/03/19 18:05 +0100, Jan Pokorný wrote:
> On 11/03/19 15:01 +0100, Jan Pokorný wrote:
>> On 11/03/19 12:31 +0100, Vít Ondruch wrote:
>>> Can somebody please enlighten me, how to update Rawhide after branching
>>> and not using --nogpgcheck?
>> 
>> Good question; have observed this over several (if not all since
>> to-be-f26 based Rawhide) jumps like that, and always have solved this
>> inconvenience by hand and moved on.
>> 
>> GPG signatures related must-do consequence of branching for those
>> using mock with the branched + Rawhide targets is also to update
>> mock-core-configs, which is currently also not very straightforward
>> and could perhaps be handled more gracefully:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1686869
> 
> Actually, fedora:rawhide container from Docker Hub (in CI scenario
> here) is affected with this problem as well (cannot update with the
> new-key-signed f30/f31 packages because of this, making the CI
> procedure fail[*]).
> 
> Should not at least the "official container images" follow the
> branching point automatically and promptly to prevent GPG signature
> imposed disruptions ASAP?

Not sure if this is thanks to the images indeed being
periodically updated (image's sha256 changed from
1c2065c021750bfa8b1530d2cce08dffda03f0fbe5fba4f21b29fc8e909954a9 to
eff97b05aaa6ef5b3444fc95cc8b340266ea63474dca3f557f07ccfd70f1fee1
between failed vs. successful run), but everything is back to normal
now, and this symptom of the failed "dnf update" with fedora:rawhide
went away, too:

> Importing GPG key 0xCFC659B9:
>  Userid : "Fedora (30) "
>  Fingerprint: F1D8 EC98 F241 AAF2 0DF6 9420 EF3C 111F CFC6 59B9
>  From   : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-30-x86_64
> Key imported successfully
> Import of key(s) didn't help, wrong key(s)?

All in all, Would be preferred if this was glitch-free all the time.

> [*] https://gitlab.com/poki/pacemaker/-/jobs/175445117

-- 
Jan (Poki)


pgpMMOTMv0mzp.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating Rawhide vs GPG keys

[Jan Pokorný]

On 11/03/19 15:01 +0100, Jan Pokorný wrote:
> On 11/03/19 12:31 +0100, Vít Ondruch wrote:
>> Can somebody please enlighten me, how to update Rawhide after branching
>> and not using --nogpgcheck?
> 
> Good question; have observed this over several (if not all since
> to-be-f26 based Rawhide) jumps like that, and always have solved this
> inconvenience by hand and moved on.
> 
> GPG signatures related must-do consequence of branching for those
> using mock with the branched + Rawhide targets is also to update
> mock-core-configs, which is currently also not very straightforward
> and could perhaps be handled more gracefully:
> https://bugzilla.redhat.com/show_bug.cgi?id=1686869

Actually, fedora:rawhide container from Docker Hub (in CI scenario
here) is affected with this problem as well (cannot update with the
new-key-signed f30/f31 packages because of this, making the CI
procedure fail[*]).

Should not at least the "official container images" follow the
branching point automatically and promptly to prevent GPG signature
imposed disruptions ASAP?

[*] https://gitlab.com/poki/pacemaker/-/jobs/175445117

-- 
Jan (Poki)


pgp0147O15hL1.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating Rawhide vs GPG keys

[Jan Pokorný]

On 11/03/19 12:31 +0100, Vít Ondruch wrote:
> Can somebody please enlighten me, how to update Rawhide after branching
> and not using --nogpgcheck?

Good question; have observed this over several (if not all since
to-be-f26 based Rawhide) jumps like that, and always have solved this
inconvenience by hand and moved on.

GPG signatures related must-do consequence of branching for those
using mock with the branched + Rawhide targets is also to update
mock-core-configs, which is currently also not very straightforward
and could perhaps be handled more gracefully:
https://bugzilla.redhat.com/show_bug.cgi?id=1686869

-- 
Jan (Poki)


pgpgHuotr0lUS.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jan Pokorný]

On 16/11/18 22:07 +, Jonathan Dieter wrote:
> The core idea behind zchunk is that a file is split into independently
> compressed chunks and the checksum of each compressed chunk is stored
> in the zchunk header.  When downloading a new version of the file, you
> download the zchunk header first, check which chunks you already have,
> and then download the rest.

Just one more thought I reliazed in hindsight, there are ways to cut down
the installed files in RPM ecosystem, currently with a request to omit
documentation (%doc tagged files, see --nodocs/--excludedocs).

Indeed, that's a sort of files you can usually omit without hesitation
in containers/VMs.  Perhaps there are some more bits that are de facto
optional without losing anything from the functionality.

So with clever separation, such bits wouldn't even need to be downloaded
when they will not eventually make it to the disk.  That might make
things like customizing a base container image tiny bit more swift,
e.g. in CI/CD context without many connectivity guarantees (up to
mirrors anyway).  But might not be worth it if the trade-off
is already predictably suboptimal in other aspects.

-- 
Nazdar,
Jan (Poki)


pgpQWWXgj7NQp.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/nssswitch.conf is supposed to be a symlink now?

[Jan Pokorný]

On 28/11/18 11:48 -0400, Robert Marcano wrote:
> There is another thing I found wrong. The backed up nsswitch.conf has these
> lines appended (ckey and incomplete aliases line) after the real end of the
> original file (aliases: files):
> 
>   aliases:files
>   ckey:  files
> 
>   aliases:fil
> 
> I can repeat this bad backup indefinitely:
> 
> 1) check current nsswitch has no such lines
> 2) run authselect select --force ...
> 3) backup at /usr/lib/authselect/backup//nsswitch has the
> appended lines

Have observed a similar corruption (with explicitly named backup, but
it's likely of no significance) yesterday with Rawhide, but at that time
it was least of my problems (see dbus-broker [vs. systemd-nspawn] in
a slightly older thread, nsswitch.conf/pam was actually a false start
based on some messages in journal I thought might be related).

Buffer handling bug?

-- 
Nazdar,
Jan (Poki)


pgpMMLna8l8VT.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Last dbus upgrade issues

[Jan Pokorný]

On 26/11/18 20:58 +0100, Jan Pokorný wrote:
> On 26/11/18 15:12 +0100, Tom Gundersen wrote:
>> On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko 
>> wrote:
>> 
>>> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
>>> zbys...@in.waw.pl> wrote:
>>> 
>>>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
>>>>> After last dbus upgrade gdm found that is not able to start.
> 
> [...] 
> 
>> Thanks for the report, and sorry for the inconvenience. There was indeed a
>> bug in the dbus-broker spec file, which we now fixed with version 16-7
>> (should land in rawhide any minute).
> 
> Thanks for sparing others if not early adopters (nicely demonstrated
> like even mere-text-mode-friendly available tooling is dependent on
> this single central point these days, NetworkManager/nmtui, even
> dhclient complained about DBus, luckily it worked regardless).
> 
> Anyway, I've hit another new incompatibility, preventing me to, e.g.,
> run mock: https://bugzilla.redhat.com/show_bug.cgi?id=1653421
> Workaround is to switch back to dbus-daemon.service.

This must have been something intermittent, perhaps a fallout from me
trying to deal with a "difficulties to do anything once rebooted after
installing -6 build" as detailed by others in this thread, bug closed.

-- 
Nazdar,
Jan (Poki)


pgpCXBNEbf9Pg.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Last dbus upgrade issues

[Jan Pokorný]

Hello ,

On 26/11/18 15:12 +0100, Tom Gundersen wrote:
> On Sun, Nov 25, 2018 at 11:36 AM Tomasz Kłoczko 
> wrote:
> 
>> On Sun, 25 Nov 2018 at 11:19, Zbigniew Jędrzejewski-Szmek <
>> zbys...@in.waw.pl> wrote:
>> 
>>> On Sun, Nov 25, 2018 at 02:36:31AM +0100, Tomasz Kłoczko wrote:
 After last dbus upgrade gdm found that is not able to start.

[...] 

> Thanks for the report, and sorry for the inconvenience. There was indeed a
> bug in the dbus-broker spec file, which we now fixed with version 16-7
> (should land in rawhide any minute).

Thanks for sparing others if not early adopters (nicely demonstrated
like even mere-text-mode-friendly available tooling is dependent on
this single central point these days, NetworkManager/nmtui, even
dhclient complained about DBus, luckily it worked regardless).

Anyway, I've hit another new incompatibility, preventing me to, e.g.,
run mock: https://bugzilla.redhat.com/show_bug.cgi?id=1653421
Workaround is to switch back to dbus-daemon.service.

-- 
Nazdar,
Jan (Poki)


pgpw4_pEtklQO.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Jan Pokorný]

On 19/11/18 13:13 +0100, Nicolas Mailhot wrote:
> Le 2018-11-19 12:28, Martin Kolman a écrit :
> 
>> Many people might think RAM would not be an issue in 2018, but in
>> practice there are
>> and likely always will be memory constrained installation targets,
>> such as massive deployments
>> of "small" VMs or the IoT use cases mentioned above.
> 
> Sure, that’s the artificial small vm case
> 
> The average old/limited hardware is limited in memory, cpu and storage.
> Therefore if you have one factor to sacrifice it's cpu time because you can
> always let the CPU run a little longer, but a limited system won't magically
> grow more memory or more storage.
> 
> Storage would not be such a problem is dnf was smart enough to auto
> partition big upgrades in lots of small partial upgrades, before downloading
> gigs of data that do not fit on disk.

https://bugzilla.redhat.com/show_bug.cgi?id=1609824

Also, not familiar with zchunk way of doing things, but couldn't
rpm-integrity-verified installed files be mapped back to "chunks"
to further aleviate space concerns for the machine receiving
updates in some cases?

-- 
Jan (Poki)


pgpYjB_2HuJHu.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora's OpenH264 repo issue

[Jan Pokorný]

Not sure where to report this for the Fedora side, but there seems to
be some synchronization issue regarding the built artifacts hosted at
http://ciscobinary.openh264.org, since older packages can be obtained
just fine:
https://github.com/cisco/openh264/issues/3037#issuecomment-436932562

-- 
Jan (Poki)


pgp1jxaanH_Ek.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Enabling powerline theme system wide by default

[Jan Pokorný]

On 01/11/18 09:53 +0100, Nicolas Mailhot wrote:
> Le mercredi 31 octobre 2018 à 17:13 -0700, Luya Tshimbalanga a écrit :
>> It will be nice to enable powerline theme by default system and user
>> wide. Simple reason is refresh the look of terminal while also
>> providing
>> useful information especially for git branch. Since powerline does not
>> impact the performance, it will be great to set for Fedora 30
> 
> If someone wants to do this the font powerline uses should be fixed to
> used correct unicode point values (and PUA when it include things not
> standardised by unicode).
> 
> Otherwise powerline display is just broken on many terminals

+1 if this would naturally solve "unable to calculate font width
for 'PowerlineSymbols'" problem with rxvt-unicode.

-- 
Nazdar,
Jan (Poki)


pgpGUBFSxIf0T.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Nonresponsive maintainer: Björn Esser (besser82)

[Jan Pokorný]

On 01/11/18 08:30 +0100, Miro Hrončok wrote:
> On 01. 11. 18 7:48, Jan Pokorný wrote:
>> I'd be interested in (co)maintenance of one of his packages,
>> tried contacting him over email (less than a day ago), then
>> realized I could check this ML.
> 
> Claim the package in https://pagure.io/releng/issues
> 
> Link https://pagure.io/fesco/issue/1971

Thanks for the pointers, applied: https://pagure.io/releng/issue/7901

-- 
Jan (Poki)


pgpInx6_0_2n9.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Nonresponsive maintainer: Björn Esser (besser82)

[Jan Pokorný]

On 27/08/18 08:41 +0200, Matthias Runge wrote:
> On Fri, Aug 17, 2018 at 03:48:12PM +0200, Bob Mauchin wrote:
>> On Fri, Aug 17, 2018, 12:53 Leigh Scott 
>> wrote:
>> 
>>> Besser82 hasn't answered  any of my emails for months.
>>> 
>> 
>> I saw him back in May for a couple of reviews, maybe he's in holidays.
>> 
> 
> I briefly contacted Björn, and he promised to get back here.

Any signs of his activity, yet?

I'd be interested in (co)maintenance of one of his packages,
tried contacting him over email (less than a day ago), then 
realized I could check this ML.

-- 
Jan (Poki)


pgprFqIZRBLio.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: raise fileno limit to make Steam Proton / Wine+esync work well in Fedora

[Jan Pokorný]

On 08/10/18 18:28 -0500, Zebediah Figura wrote:
> On 08/10/18 16:43, John Reiser wrote:
>> On 10/8/18 2026 UTC, Zebediah Figura wrote:
>>> On 08/10/18 2000 UTC, John Reiser wrote:
 Allowing 1M open files per unprivileged process is too many.
 
 Megabytes of RAM are precious.  A hard limit of 1M open files per
 process
 allows each process to eat at least 256MB (1M * sizeof(struct file)
 [linux/fs.h]) of RAM.  If a single user is allowed 1000 processes,
 then that's 256GB of RAM, which is a Denial-of-Service attack.
 
 Yes, 4096 open files is not enough.  Raise it to 65536.
 
>>> 
>>> Correct me if I'm wrong, but wouldn't this be capped by the
>>> system-wide limit (i.e. it would hit ENFILE) before presenting
>>> a problem?
>> 
>> That means that a different DoS can happen even sooner,
>> at (ENFILE / 1M) processes.  No other process could open() a file.

The surface is substantially more colourful, e.g., executables may
not be launched anymore (i.e., effectively similar to denials based
on /proc/sys/kernel/pid_max), for failures to load shared libraries when
it gets thus far at all.

> Sure, but in order to prevent that you'd almost always need to *lower*
> NOFILE. I don't know what kind of policies Fedora (or any other
> distribution) has regarding this kind of attack mitigation, but it
> seems dubious to me that this is worth doing.

Yes, it feels somewhat uneasy that unprivileged users/processes are
given, in pristine configuration, a free permit to consume order (or
two) of magnitude more resources from globally shared domain than
what the globally imposed limits are, possibly impacting privileged
entities.  Right now, not to talk about increasing one of these limits
globally, which would be hence preferrably limited just to Workstation
edition, and for the rest the question of possibly lowering these
limits for nonprivileged use cases would deserve some attention, IMHO.

-- 
Jan (Poki)


pgpSKtZlensmV.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: /etc/profile.d/lang.sh -- still needed?

[Jan Pokorný]

On 14/05/18 17:19 +0200, David Kaspar [Dee'Kej] wrote:
> does anybody know if the files /etc/profile.d/lang.{csh,sh}
> are still used these days, and what for?
> Do we still need them in Fedora?
> Should they be installed by default these days?
> 
> Any info is appreciated! :)

Frankly, had no idea about that file but apparently it's needed (or
something to that effect) so as to have non-ascii characters rendered
correctly in the terminal-within-WM settings (sway + urxvt256c-ml).
I am not sure what the cause was, could be just missing
LANG=en_US.UTF-8 in the environment -- no idea what's the
intended authoritative "automagic" source for that otherwise.
Or does it mean one shouldn't trust the distribution for
this common convenience anymore?

Please be more considerate even to Rawhide package consumers next time
around and coordinate file migrations between packages properly.
I can see that these files were moved to setup package, but alas,
that hasn't been rebuilt yet.  Perhaps versioned dependency or even
path-based one would be justified in this case to prevent unexpected
regressions.

-- 
Poki


pgpyas6nvH69Q.pgp
Description: PGP signature
___
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.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/YRYWSUCNRO3C2CYZW5FJFAW3ZQ7NEMJ4/

Re: Sliming down kernel and provide more as modules

[Jan Pokorný]

On 09/04/18 13:38 +0100, Peter Robinson wrote:
> On 09/04/18 13:01 +0100, Tomasz Kłoczko wrote:
>> 8) If someone is using Linux working in VM or headless HW ..
> 
> Actually a lot of VMs have mice mapped by default.
> 
>> -CONFIG_INPUT_MOUSEDEV=y
>> +CONFIG_INPUT_MOUSEDEV=m
>> 
>> -CONFIG_MOUSE_PS2=y
>> +CONFIG_MOUSE_PS2=m

Just a side note, it looks like having psmouse available as a module
and hence loadable dynamically (triggering some reinitizalition)
might have saved some reboots with rare bug with trackpoint not
working upon start (the bug might be a bit conflated, in my case
the trackpoint never started working again on its own, but I haven't
run into it for the past two months):
https://bugzilla.redhat.com/show_bug.cgi?id=1432481#c14

I haven't tested that, but that could be something beneficial about
providing modules instead in some cases.

-- 
Jan (Poki)


pgpCKyR12pQpo.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Binutils version 2.29.1

[Jan Pokorný]

On 09/01/18 16:16 +0100, Tomasz Torcz ️ wrote:
> On Tue, Jan 09, 2018 at 12:11:31PM +0100, Jan Kurik wrote:
>> = System Wide Change: Binutils version 2.29.1 =
>> https://fedoraproject.org/wiki/Changes/BINUTILS2291
>> 
>> Change owner(s):
>> * Nick Clifton 
>> 
>> Rebase the binutils package from version 2.29 to version 2.29.1. This
>> will bring in the bug-fixes from the 2.29.1 point release, but not add
>> any new features.
>> 
> 
>> Change the source parameter in the binutils.spec rpm and adjust the
>> local patches to take account of the bugs that are now already fixed.
> 
>   I'm a bit perplexed by this change.  It looks like minor version
>  update, in such case it need no to be announced so widely.
>   On the other hand, you are changing the source.  According to the
>  guidelines, changing source requires re-review.
>   So why this is a system-wide change?

I think I have something to add here as if no other package, libqb was
quite affected with the former change of binutils 2.28 -> 2.29 coming
to Fedora 27:
  https://bugzilla.redhat.com/show_bug.cgi?id=1478089
+ binutils bug:
  https://bugzilla.redhat.com/show_bug.cgi?id=1477354
(TL;DR eventually, libqb adopted measures to overcome changed
visibility of some symbols, binutils didn't go back in its behaviour)

In parallel, there was a separate discussion directly with upstream:
  https://lists.gnu.org/archive/html/bug-binutils/2017-08/msg00195.html
which resulted in
  
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f399679112df997c1416f7993eaac0f5fd76c144
that is part of 2.29.1 and which actually forced an existing prototype
of the libqb fix to be refined once more because, suddenly, some new
configure-time checks were to loose to detect the necessity to apply
said measures (while they were working fine with 2.29 alone).

So I can attest this change has a merit (compare with unannounced 2.29
change that hit libqb hard), even though it's not expected the number
of packages relying on some rather obscure linker features (that are
hence not under constant coverage) will be notable.  But keep in mind
that a single broken package can spoil some other, dependent packages,
as was the case with libqb.

Thanks for playing it considerately now, Nick.

-- 
Jan (Poki)


pgpQVdHIQl60o.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SO-NAME BUMP] libjson-c.so.3 comes to Rawhide

[Jan Pokorný]

On 13/12/17 12:05 +0100, Ondrej Kozina wrote:
> On 12/12/2017 06:41 PM, Jan Pokorný wrote:
>> On 11/12/17 01:05 +0100, Björn 'besser82' Esser wrote:
>>> I'll update json-c to v0.13 for Rawhide.  This will bump libjson-c so-
>>> name from 2 to 3 and will remove some deprecated stuff from its API.
>> 
>> https://src.fedoraproject.org/rpms/sway/c/bc85e0dfab91ae77c09250dbf54b8b7e48d43229
> 
> Wow! What an example of proven packager rights abuse. It didn't
> build because the maintainer had an explicit requirement specified?
> Nah, let's drop it.
> 
> Seriously, stop this nonsense already! We all know it's Rawhide and
> occasional breakage is tolerated

If I understand it correctly, this is actually what happened here
in the first place -- json-c got released broken in version 0.13
under the circumstances exercised by sway, as Björn investigated
and subsequently fixed (thanks) -- see the referred bug.
Case solved, IMHO.

> but since it seems to be a new kind of standard (according to
> various topics on fedora-devel recently) maybe the proven packager
> concept is not so flawless after all.

Either way, more (or any at all) automated tests on both functionality
provider and consumer sides would definitely help.

-- 
Jan (Poki)


pgpLMyO5GuQNE.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [SO-NAME BUMP] libjson-c.so.3 comes to Rawhide

[Jan Pokorný]

On 11/12/17 01:05 +0100, Björn 'besser82' Esser wrote:
> I'll update json-c to v0.13 for Rawhide.  This will bump libjson-c so-
> name from 2 to 3 and will remove some deprecated stuff from its API.

Looks like json-c is not that compatible between 0.12 and 0.13 to
rush with changes like this:

https://src.fedoraproject.org/rpms/sway/c/bc85e0dfab91ae77c09250dbf54b8b7e48d43229

that counter the intentional decision of upstream:

https://github.com/swaywm/sway/pull/1438

leading to:

https://bugzilla.redhat.com/show_bug.cgi?id=1525020

> I'll bump and rebuild all affected packages in the same run and add
> patches for the new API, if needed.

The above change was not an instance of patching to support the new API.

-- 
Jan (Poki)


pgp6i2VD71Jyu.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Reduce Initial Setup Redundancy

[Jan Pokorný]

On 04/12/17 16:09 +0100, Jan Kurik wrote:
> === Language and Keyboard Layout ===
> 
> Although we do not propose it at this time, language and keyboard
> layout selection should be presented to the user *before* entering the
> live session, as it is currently too difficult for users to change
> these settings unless they are already familiar with Fedora, and --
> unless you speak English and use a US keyboard -- these settings must
> be changed for the live session to be usable. Both Anaconda and
> gnome-initial-setup are too late for configuring these settings. (An
> exception would be for netinstalls of Fedora Workstation, where
> Anaconda is the best place for this configuration.) In the meantime,
> until we have a way to prompt users for these settings earlier than
> Anaconda

Not directly related to F28 change, but when there's anything to be
done about the language/keyboard layout selection, it'd be desirable
to make the initial selection easily revertable at least from the
subsequent installation step to prevent the need to reboot needlessly
(IIRC the same usability issue was present with Redmond's OS in the
past, making it even more nasty in install-from-harddisk scenarios):

https://bugzilla.redhat.com/show_bug.cgi?id=1410599

> these panels should be removed from gnome-initial-setup, because
> Anaconda is clearly a better place than gnome-initial-setup for this
> configuration. (This would affect gnome-initial-setup when creating
> the first user account. Additional user accounts created later would
> still receive these panels in gnome-initial-setup.)

-- 
Jan (Poki)


pgpi8fb7u4HEf.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages looking for new maintainers

[Jan Pokorný]

Hello Ville,

On 23/10/17 22:24 +0300, Ville Skyttä wrote:
> The following packages are looking for new maintainers, ping me if
> you're able to help out.
> 
> 1) No co-maintainers at the moment:
> 
> [...]
> - jing-trang

still somewhat interested in that package, would help to keep it in
Fedora if that's not awfully a lot of work.

-- 
Jan (Poki), jpokorny in FAS


pgpD57CSk2Ze9.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Updates not getting pushed to stable

[Jan Pokorný]

On 07/06/17 23:36 +0100, Peter Robinson wrote:
> On Wed, Jun 7, 2017 at 11:22 PM, Sandro Mani  wrote:
>> I've got a couple of updates which are stuck waiting to get pushed to
>> stable:
>> 
>> https://bodhi.fedoraproject.org/updates/FEDORA-2017-e46ec0bbe8
>> https://bodhi.fedoraproject.org/updates/FEDORA-2017-19c1569283
>> https://bodhi.fedoraproject.org/updates/FEDORA-2017-192daab41c
>> 
>> The last two I tried unpushing and repushing to see whether it would unlock
>> them, so far that does not seem to be the case.
>> 
>> Looks like they are isolated cases, various updates before and after that
>> have been successfully pushed to stable.
>> 
>> Anyone with a magic wand to get those updates to stable or ideas what's
>> wrong? :)
> 
> We're still in freeze for beta, they all look to be F-26 updates.

Related Bodhi RFE: Bodhi should inform about freeze
https://github.com/fedora-infra/bodhi/issues/1038

-- 
Jan (Poki)


pgpTDohlHllOk.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Reminder: GitHub etc. auto-generated archives are not stable in time

[Jan Pokorný]

On 25/05/17 00:28 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, May 24, 2017 at 05:22:43PM +0200, Jan Pokorný wrote:
>> On 24/05/17 09:58 -0500, Jorge Gallegos wrote:
>>> On Wed, May 24, 2017 at 04:19:05PM +0200, Jan Pokorný wrote:
>>>> today, I've accidentally attested there are no stability guarantees
>>>> with the on-demand archives from common git hosting sites when preparing
>>>> a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec"
>>>> of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the
>>> 
>>> Are you pointing to a _tag_ (or as github likes to call them: release) ?
>>> As far as I know tags can be re-created, isn't that what is happening
>>> here?
>> 
>> Nope, the point is that nothing has changed in the codebase or, for
>> that matter, tags.  It must have been GitHub that changed how its
>> equivalent of "git archive" behaves.
>> 
>>>> hashes, which (surprisingly to me) didn't match (they were at any similar
>>>> test in the past).  Then I looked at the adiff output:
>>>> 
>>>>> diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac 
>>>>> Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac
>>>>> --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 
>>>>> 00:55:15.0 +0200
>>>>> +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 
>>>>> 00:55:15.0 +0200
>>>>> @@ -1159,7 +1159,7 @@
>>>>>  AC_PATH_PROGS(GIT, git false)
>>>>>  AC_MSG_CHECKING(build version)
>>>>>  
>>>>> -BUILD_VERSION=0459f40
>>>>> +BUILD_VERSION=0459f40958
>>>>>  if test  != ":%h$"; then
>>>>> AC_MSG_RESULT(archive hash: )
>>>>  
>>>> for configure.ac that indeed has export-subst git attribute set
>>>> and the change itself arises from "$Format:%h$" substitution.
>>>> This likely means GitHub was internally updated to use equivalent
>>>> of git 2.11 feature of abbreviation length autoscaling within
>>>> last 14 days.
>>> 
>>> This is the other bit that makes me think it was actually the
>>> maintainers hand that moved this, I don't believe github does anything
>>> special to the code once it's stored there. There is no way for github
>>> to alter code afaik?
>> 
>> Once more, see "git help archive", ATTRIBUTES section, export-subst
>> in particular.  That exactly stands for the varying part, which is
>> implementation-specific, and GH implementation has apparently changed,
>> leading to changed contents of numerous archives to be downloaded from
>> that very point.
> 
> Well, the title of your mail implies that *any* archive changed.

Of course, any such archives can change bitwise in between two
arbitrary moments, simply because some variable in the archiving
process can change (is even file list linearization assuredly
stable?).  I've left that, obvious for some, aspect aside in the email
body, because a changed content is what seems to be entirely new,
at least to me.  It means that also alternative checksuming approaches
(zcat archive | sha512sum) are disqualified from the attempts to
deal with such instabilities.

> What changed in fact is an archive with %h subst. But %h is
> inherently unstable: when commits are added to the archive, git will
> extend the generated abbreviation length to maintain uniqueness.

This is how the original git implementation was changed recently,
but it doesn't mean any implementation has to behave that way,
and who knows what these proprietary services use.

> I think the error here is in relying on stability %h substitution
> over time.

I'd say more broadly that the error is to rely on stability of
auto-generated archives as such.  In that light, Colin's git-evtag
project looks appealing for upstreams that do not provide their own
stable tarballs.

-- 
Jan (Poki)


pgpoSA1SkwrC9.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Reminder: GitHub etc. auto-generated archives are not stable in time

[Jan Pokorný]

On 24/05/17 09:58 -0500, Jorge Gallegos wrote:
> On Wed, May 24, 2017 at 04:19:05PM +0200, Jan Pokorný wrote:
>> today, I've accidentally attested there are no stability guarantees
>> with the on-demand archives from common git hosting sites when preparing
>> a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec"
>> of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the
> 
> Are you pointing to a _tag_ (or as github likes to call them: release) ?
> As far as I know tags can be re-created, isn't that what is happening
> here?

Nope, the point is that nothing has changed in the codebase or, for
that matter, tags.  It must have been GitHub that changed how its
equivalent of "git archive" behaves.

>> hashes, which (surprisingly to me) didn't match (they were at any similar
>> test in the past).  Then I looked at the adiff output:
>> 
>>> diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac 
>>> Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac
>>> --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 
>>> 00:55:15.0 +0200
>>> +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 
>>> 00:55:15.0 +0200
>>> @@ -1159,7 +1159,7 @@
>>>  AC_PATH_PROGS(GIT, git false)
>>>  AC_MSG_CHECKING(build version)
>>>  
>>> -BUILD_VERSION=0459f40
>>> +BUILD_VERSION=0459f40958
>>>  if test  != ":%h$"; then
>>> AC_MSG_RESULT(archive hash: )
>>  
>> for configure.ac that indeed has export-subst git attribute set
>> and the change itself arises from "$Format:%h$" substitution.
>> This likely means GitHub was internally updated to use equivalent
>> of git 2.11 feature of abbreviation length autoscaling within
>> last 14 days.
> 
> This is the other bit that makes me think it was actually the
> maintainers hand that moved this, I don't believe github does anything
> special to the code once it's stored there. There is no way for github
> to alter code afaik?

Once more, see "git help archive", ATTRIBUTES section, export-subst
in particular.  That exactly stands for the varying part, which is
implementation-specific, and GH implementation has apparently changed,
leading to changed contents of numerous archives to be downloaded from
that very point.

Is/will the pagure.io be immune to this sort of retroactive changes
once/if such tarball extraction is implemented
(see https://pagure.io/pagure/issue/861)?

> This would suggest to me the maintainer:
> 
> a) Modified the code (either via script or otherwise)
> b) Deleted the tag (and thus, the github "release")
> c) Submitted a new tag (and created a new gh release)
> 
> Of course if the .spec is pointing to an archive url pointing to a git
> SHA my theory is busted.
> 
>> 
>> Hope this will be useful for some (e.g. fedora-review tool
>> has a check to redownload and diff sources against SRPM content,
>> IIRC).

-- 
Poki


pgpViqBMQZtt2.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reminder: GitHub etc. auto-generated archives are not stable in time

[Jan Pokorný]

Hello,

today, I've accidentally attested there are no stability guarantees
with the on-demand archives from common git hosting sites when preparing
a new pacemaker update, redownloading "spectool -s 0 pacemaker.spec"
of the original (-0.1.rc1, from 2 weeks ago) spec and comparing the
hashes, which (surprisingly to me) didn't match (they were at any similar
test in the past).  Then I looked at the adiff output:

> diff -ru Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac 
> Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac
> --- Unpack-2241/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 
> 00:55:15.0 +0200
> +++ Unpack-6255/pacemaker-Pacemaker-1.1.17-rc1/configure.ac2017-05-09 
> 00:55:15.0 +0200
> @@ -1159,7 +1159,7 @@
>  AC_PATH_PROGS(GIT, git false)
>  AC_MSG_CHECKING(build version)
>  
> -BUILD_VERSION=0459f40
> +BUILD_VERSION=0459f40958
>  if test  != ":%h$"; then
> AC_MSG_RESULT(archive hash: )
 
for configure.ac that indeed has export-subst git attribute set
and the change itself arises from "$Format:%h$" substitution.
This likely means GitHub was internally updated to use equivalent
of git 2.11 feature of abbreviation length autoscaling within
last 14 days.

Hope this will be useful for some (e.g. fedora-review tool
has a check to redownload and diff sources against SRPM content,
IIRC).

-- 
Jan (Poki)


pgpbt4dJlktUK.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Summary/Minutes from today's FESCo Meeting (2017-02-10)

[Jan Pokorný]

On 11/02/17 02:08 +0100, Kevin Kofler wrote:
> Justin Forbes wrote:
>>   * AGREED: Allow the update, encourage everyone to work through the
>> process better next time (7,0,0)  (jforbes, 16:51:10)
> 
> The context:
> https://pagure.io/fesco/issue/1675
> #1675 Libglvnd update breaking F25
> is missing there.

Thanks for balancing the informational depth of the message out
(I sincerely hope it wasn't a case opportunistic obscurity).

> This is essentially giving the GNOME developers a blanket license to violate 
> all Fedora policies, they can just go ahead with their policy violation, 
> with only an "encouragement" to, you know, actually follow policies next 
> time, maybe, if they're nice. And that even unanimously.
> 
> I expected better from FESCo!

-- 
Jan (Poki)


pgp6ltILnBqRp.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: The glvnd + mesa update for F25

[Jan Pokorný]

On 06/02/17 15:13 -0500, Christian Schaller wrote:
> There has been a lot of discussions for the last few years about glvnd on
> the mesa-devel list and at XDC. This is not Fedora specific technology, but 
> a change in how Mesa will work everywhere and thus there has not been a lot
> of discussions about it here on Fedora-devel. But that is true for most stuff,
> we do not discuss major new kernel features here that much either as one 
> example.

I don't think that's a fair point.  If there was an artificial
intermediate level put in front of libc that would only be to
solve issues with some hardware component, and it would be forcibly
implanted into Fedora unnecessarily for all audience, then it would
be comparable.

But even then, I doubt it would happen without questioning such
aspects.

Forcing glvnd for all is Fedora specific, as far as I can tell.

-- Jan

> Christian
> 
> 
> 
> - Original Message -
>> From: "Jan Pokorný" <jpoko...@redhat.com>
>> To: devel@lists.fedoraproject.org
>> Sent: Monday, February 6, 2017 2:32:35 PM
>> Subject: Re: The glvnd + mesa update for F25
>> 
>> On 06/02/17 05:06 +0100, Kevin Kofler wrote:
>>> Hans de Goede wrote:
>>>> libglvnd is a solution for this it is a vendor neutral
>>>> implementation of libGL.so.1 which acts as a dispatcher
>>>> to one or more glvnd enabled libGL implementations
>>>> installed on the systems.
>>> 
>>> By doing so, it decreases performance for all the users of the Mesa
>>> drivers by adding an unnecessary layer of indirection. I do not see
>>> performance being addressed at all in any of your communication, did
>>> you even try to measure the impact of the added indirection layer?
>> 
>> These are the thoughts that crossed my mind as well, I'll admit.
>> 
>> Do we have any sort of measurements or at least the related theoretical
>> backgrounds, such as "indirection will impose a small slowdown, but
>> only at the very initial phase of execution till all the necessary
>> symbols are resolved, no effect since then"?  Is it in fact worse?
>> 
>> The fact there was no serious discussion about the change is rather
>> unsettling, IMHO.
>> 
>> --
>> Jan (Poki)
>> 
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

-- 
Jan (Poki)


pgpy5oOrjk9r3.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: The glvnd + mesa update for F25

[Jan Pokorný]

On 06/02/17 05:06 +0100, Kevin Kofler wrote:
> Hans de Goede wrote:
>> libglvnd is a solution for this it is a vendor neutral
>> implementation of libGL.so.1 which acts as a dispatcher
>> to one or more glvnd enabled libGL implementations
>> installed on the systems.
> 
> By doing so, it decreases performance for all the users of the Mesa
> drivers by adding an unnecessary layer of indirection. I do not see
> performance being addressed at all in any of your communication, did
> you even try to measure the impact of the added indirection layer?

These are the thoughts that crossed my mind as well, I'll admit.

Do we have any sort of measurements or at least the related theoretical
backgrounds, such as "indirection will impose a small slowdown, but
only at the very initial phase of execution till all the necessary
symbols are resolved, no effect since then"?  Is it in fact worse?

The fact there was no serious discussion about the change is rather
unsettling, IMHO.

-- 
Jan (Poki)


pgp96nygzZ6sr.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Jan Pokorný]

On 30/01/17 14:44 +0100, Jan Pokorný wrote:
> On 30/01/17 00:53 +0100, Kevin Kofler wrote:
>> This is the result of 4 very poor decisions, by different people/groups:
>> 
>> 1. the decision to enable libglvnd in an update to a stable release. IMHO,
>>such a change is totally unsuitable for a stable release update and
>>should have been done in Rawhide only.
> 
> Big +1 as you can see in my posts:
> https://bodhi.fedoraproject.org/updates/libglvnd-0.2.999-7.gitdc16f8c.fc25#comment-552926
> https://bugzilla.redhat.com/show_bug.cgi?id=1413579#c14
> and on.
> 
> TL;DR:
> Another Fedora package (sway and possibly more) gets broken in return.

No longer the case for sway, thanks to Hans' fix of wlc, merged upstream:
https://github.com/Cloudef/wlc/pull/233
and coming to Fedora along the same update.

-- 
Jan (Poki)


pgpUrmoxXzOZp.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 25 Koji buildroots broken…

[Jan Pokorný]

On 30/01/17 00:53 +0100, Kevin Kofler wrote:
> This is the result of 4 very poor decisions, by different people/groups:
> 
> 1. the decision to enable libglvnd in an update to a stable release. IMHO,
>such a change is totally unsuitable for a stable release update and
>should have been done in Rawhide only.

Big +1 as you can see in my posts:
https://bodhi.fedoraproject.org/updates/libglvnd-0.2.999-7.gitdc16f8c.fc25#comment-552926
https://bugzilla.redhat.com/show_bug.cgi?id=1413579#c14
and on.

TL;DR:
Another Fedora package (sway and possibly more) gets broken in return.

-- 
Jan (Poki)


pgpCemr1c0_HP.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: drop obsolete static uid/gid allocations

[Jan Pokorný]

On 15/01/17 00:13 +, Zbigniew Jędrzejewski-Szmek wrote:
> == No need for static allocation, afaict
> games, man, slocate, squid, named, postgres, mysql, nscd,
> rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp,
> tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd,
> imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci

ricci+luci can be garbage-collected as not needed since around Fedora 18
anyway.

-- 
Jan (Poki)


pgpKCDQpJBotf.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Autogenerating Koschei groups's contents

[Jan Pokorný]

On 23/05/16 10:22 +0200, Michael Šimáček wrote:
> few people who have groups defined in Koschei have asked whether they could
> automate maintentance of the package list with something like repoquery
> rule

Are you talking about "Global groups" or "Your groups" kind of groups?
Or are these the same?

-- 
Jan (Poki)


pgpl2KAr2V1y9.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: python F23 update testing needed

[Jan Pokorný]

On 07/04/16 09:41 -0600, Kevin Fenzi wrote:
> On Thu, 7 Apr 2016 15:28:37 +0200
> Jan Pokorný <jpoko...@redhat.com> wrote:
> 
> ...snip...
> 
>> Does bodhi allow to specify several builds as a means of an atomic
>> (non-racy) override?   Should I file a RFE for that if not?
> 
> Seems to already be filed: 
> 
> https://github.com/fedora-infra/bodhi/issues/777

Thanks for the reference.

-- 
Jan (Poki)


pgpxO8Sbi_NzW.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: python F23 update testing needed

[Jan Pokorný]

On 02/04/16 13:58 +0200, Jan Pokorný wrote:
> On 02/04/16 12:26 +0200, Jan Pokorný wrote:
>> On 31/03/16 21:28 -0600, Orion Poplawski wrote:
>>> I've just submitted
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-dcddcc1f06
>>> 
>>> This update does two things:
>>> 
>>> - Updates python to version 2.7.11
>>> - Splits out the python macros into separate packages
>>> 
>>> It would be helpful if packagers would try building python packages with
>>> these packages installed.
>> 
>> This might be the cause of a recent failure to build Pacemaker while
>> other Fedoras (24 + 25) were OK:
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=13522053
>> 
>> See
>> https://kojipkgs.fedoraproject.org//work/tasks/2053/13522053/mock_output.log
>> 
>>> Package python-macros is obsoleted by python-rpm-macros, but
>>> obsoleting package does not provide for requirements
> 
> Subsequent build succeeded, though:
> http://koji.fedoraproject.org/koji/buildinfo?buildID=750257
> 
> So it must have been an intermittent issue.
> Can this be prevented next time a basic build dependency
> is restructured?  Or would it require additional support
> in the build infra?

I tried to investigate this a little bit.

6 days ago, at around the point the build failed, several overrides
for the build root have been requested:

python-rpm-macros-3-7.fc23:
https://bodhi.fedoraproject.org/overrides/python-rpm-macros-3-7.fc23
redhat-rpm-config-36-1.fc23.1:
https://bodhi.fedoraproject.org/overrides/redhat-rpm-config-36-1.fc23.1
python-2.7.11-2.fc23:
https://bodhi.fedoraproject.org/overrides/python-2.7.11-2.fc23

All but the last, expired on 2016-04-01, appear active at the moment.
The last one was superseded with python-2.7.11-3.fc23:
https://bodhi.fedoraproject.org/overrides/python-2.7.11-3.fc23,
which is also active right now.

But clearly, at the moment of the linked build that failed,
python-rpm-macros and redhat-rpm-config were overridden whereas
python-macros-2.7.10-8.fc23+ wasn't.  It looks to me I hit a racy
window in which python-2.7.11-2.fc23 override hasn't yet been
applied.

And later, at the moment of the linked build that succeeded,
no such override was active.

I would conclude, please be more careful about management of
overrides to prevent this kind of mess-ups.

Does bodhi allow to specify several builds as a means of an atomic
(non-racy) override?   Should I file a RFE for that if not?

-- 
Jan (Poki)


pgp9WjS3qqL4r.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: python F23 update testing needed

[Jan Pokorný]

On 02/04/16 12:26 +0200, Jan Pokorný wrote:
> On 31/03/16 21:28 -0600, Orion Poplawski wrote:
>> I've just submitted
>> https://bodhi.fedoraproject.org/updates/FEDORA-2016-dcddcc1f06
>> 
>> This update does two things:
>> 
>> - Updates python to version 2.7.11
>> - Splits out the python macros into separate packages
>> 
>> It would be helpful if packagers would try building python packages with
>> these packages installed.
> 
> This might be the cause of a recent failure to build Pacemaker while
> other Fedoras (24 + 25) were OK:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13522053
> 
> See
> https://kojipkgs.fedoraproject.org//work/tasks/2053/13522053/mock_output.log
> 
>> Package python-macros is obsoleted by python-rpm-macros, but
>> obsoleting package does not provide for requirements

Subsequent build succeeded, though:
http://koji.fedoraproject.org/koji/buildinfo?buildID=750257

So it must have been an intermittent issue.
Can this be prevented next time a basic build dependency
is restructured?  Or would it require additional support
in the build infra?

-- 
Jan (Poki)


pgpfbcZ3cn_AX.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: python F23 update testing needed

[Jan Pokorný]

On 31/03/16 21:28 -0600, Orion Poplawski wrote:
> I've just submitted
> https://bodhi.fedoraproject.org/updates/FEDORA-2016-dcddcc1f06
> 
> This update does two things:
> 
> - Updates python to version 2.7.11
> - Splits out the python macros into separate packages
> 
> It would be helpful if packagers would try building python packages with
> these packages installed.

This might be the cause of a recent failure to build Pacemaker while
other Fedoras (24 + 25) were OK:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13522053

See
https://kojipkgs.fedoraproject.org//work/tasks/2053/13522053/mock_output.log

> Package python-macros is obsoleted by python-rpm-macros, but
> obsoleting package does not provide for requirements

-- 
Jan (Poki)


pgp2GwQsheEvM.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: nss_myhostname as default in Fedora

[Jan Pokorný]

On 25/01/16 19:43 -0800, Andrew Lutomirski wrote:
> I think that the "gateway" override should not be conflated with
> always letting the gethostname(2) return value resolve.
> 
> I also think that the whole gethostname(2) mechanism is terminally
> screwed up.  We abuse the hostname for multiple purposes:
> 
> 1. It shows up in the default bash prompt.
> 2. It gets sent to remote DHCP servers.  I think this is a mistake on
> desktop machines.
> 3. Some programs seem to thing that gethostbyname(gethostname())
> should return some reasonable concept of "my ip address" despite the
> general nonexistence of such a concept.
> 
> I'll propose a strawman:
> 
>  - gethostname(2) always returns "localhost".
> 
>  - "localhost" always resolves to 127.0.0.1 or ::1

attempt on settle this one down: http://tools.ietf.org/html/rfc6761
(also filed https://bugzilla.redhat.com/show_bug.cgi?id=975856)

>  - bash learns to use some intelligent value derived from whatever
> hostnamectl would return
> 
>  - the default DHCP clients send a client identifier that's a function
> only of the MAC address used to send the query
> 
>  - Whatever systemd magic special-cases "localhost" as "trust what
> DHCP says" goes away.
> 
> and that's it.

-- 
Jan (Poki)


pgpNrBMeOIERp.pgp
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Slight change to the review process for new contributors

[Jan Pokorný]

On 18/11/15 15:55 -0600, Jason L Tibbitts III wrote:
> After FESCo approval of https://fedorahosted.org/fesco/ticket/1499 I
> have modified the review process document:
>   https://fedoraproject.org/wiki/Package_Review_Process
> to indicate that any packager is welcome to complete the initial package
> review(s) for a new contributor.  Contributors still need to find a
> sponsor as normal, and the FE-NEEDSPONSOR ticket should still be blocked
> as before.

There seem to be more places asking for adjustment, e.g.:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Get_Sponsored

with a box currently stating:

> Review and approval for the first package for new packagers must be
> done by registered sponsors. Subsequent reviews can be done by any
> package maintainer. Informal reviews can always be done by anyone
> interested.

-- 
Jan (Poki)


pgpQRugAfdE31.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No emails about bodhi updates

[Jan Pokorný]

On 26/10/15 17:36 +, Richard W.M. Jones wrote:
> Seems like I'm no longer getting emails about significant bodhi
> events, particularly when a package has spent  days in testing and
> can be pushed to stable.
> 
> Example update that I never got email about:
> 
>   https://bodhi.fedoraproject.org/updates/FEDORA-2015-072d89c28d
> 
> I've checked my email pretty carefully, and believe I should have got
> an email on 2015-10-11, but didn't.
> 
> Is something wrong / is there something I have to do to reenable these?

https://lists.fedoraproject.org/pipermail/devel/2015-October/215378.html
(?)

-- 
Jan (Poki)


pgpISdyKTFbfF.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Mouse focus stealing bug

[Jan Pokorný]

On 31/08/13 09:36 +1000, Peter Hutterer wrote:
 On Fri, Aug 30, 2013 at 01:19:54PM +0200, Maros Zatko wrote:
 Hello dear Fedora comunity,
 
 I've hit very weird bug which happen to get very urgent now.
 Something (very likely GTK{2,3} but not sure at all) is stealing my
 mouse focus so that I cannot click anymore. Symptoms are in range
 from being able to click once or several times AFTER switching
 desktop (tag), to being able to click only with left button (with
 right being totally unresponsive) to not being able to click at all
 anymore until I kill Xorg.
 
 Killing Xorg was *the fix* -- for you to understand, after reboot I
 *had* to kill Xorg session three times, with spawning some GTK app
 in between runs so that I hit the issue and Xorg restart had the
 right effect.  What happens now is that Xorg restart are NOT
 helping any more, i.e.  after that it works for about 5 minutes
 and then it get progressively more and more wrong until I cannot
 click any more.
 
 My nowadays combo is Xmonad with nm-applet and some other basics
 plus firefox, xchat, pidgin and some gnome-terminals (and couple of
 other random stuff). To hit the issue is enough to spawn xchat and
 firefox in a clean session.
 
 I've been hitting the very same issue before when I was using
 Awesome WM, but I thought it was its issue so I've picked xmonad
 but after some time the same issues returned.
 
 So, dear Fedora community, I beg you for help. I have no idea how
 can I fix this, nor how can I debug it. Any help would be really
 welcome.

Started to occur to me from time to time as well (LXDE@F18, inputs come
through synergy).

Last time, I think it started in connection with Firefox, and
fortunately it stopped with exiting Firefox.  In the meantime,
the treatment was to either switch to another virtual desktop
(and I am not sure if I used to right-click anything here) and
back, or to right-click bottom panel.

 sounds like a stuck grab. that can be a bug in the server or the
 application, but it's notoriously difficult to debug.
 
 grabs are triggered by keyboard shortcuts, popup/dropdown menus and by
 simple button presses (i.e. drag and drop usually triggers a grab). 
 
 generally if grab is stuck, the client with the grab still receives events,
 so you may be able to narrow it down by clicking and hoping that _something_
 responds to the click. that is the client with the grab then.

Yep, it looked like intended client was overriden, at least for
the part of the observed behavior.

 You'll have to figure out a reproducible test case because there are so many
 factors at play and the code is so convoluted that debugging this otherwise
 is almost impossible.

Unfortunately.  And backtracking which update introduced this issue would
be unrealistically time consuming provided that the reproducer seems
to be quite random.  So my hope is it will go away the same way it
arrived.

-- 
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F20 release name election?

[Jan Pokorný]

On 23/08/13 17:49 -0400, Konstantin Ryabitsev wrote:
 Or how about None. It even fits with the lineage -- just like the
 Schrodinger's cat, it's neither False nor True. It's None.
 
 That would be a worthy tribute to the pythonista and the release-name hater.

+1

-- 
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Orphaning Blueman

[Jan Pokorný]

On 01/08/13 12:52 -0500, Juan Rodriguez wrote:
 I've recently been approached about one of the packages I maintain,
 Blueman, an alternative Bluetooth Manager.
 
 At the time I packaged it, it was actively being developed, however
 development has stopped for over a year [1]. The project's domain expired
 too. [2]
 
 The package has been continuously piling up bugs. Some of which I can fix
 (Packaging) but most of which I can't (Actual crashes).
 
 Given that both the KDE Bluetooth Manager and the Gnome Bluetooth Manager
 both work wonderfully, I'm orphaning the package.

The only catch is that gnome-bluetooth needs plenty of burden (from my
LXDE user perspective) such as accountsservice, gnome-settings-daemon,
gnome-online-accounts, etc.

It's harder and harder to escape from these monoliths despite not using
vast majority of their functionality while the rest can only be good
to provide new attack vectors.

Well, Blueman will be missed then, I am not seeing myself jumping into
its maintenance.

 [1] https://code.launchpad.net/~chihchun/blueman/blueman-lp1087890
 [2] http://blueman-project.org/

-- 
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Default libkrb5 ccache location

[Jan Pokorný]

On 26/07/13 14:58 -0400, Colin Walters wrote:
 On Fri, 2013-07-26 at 13:57 -0400, Stephen Gallagher wrote:
 One kind of nontrivial approach, but at least worth thinking about, is
 changing cron to keep a zygote process around (with a session) for users
 with active cron jobs.
 
 Futhermore if this zygote is terminated, then no cron jobs for the user
 will be run.
 
 A nice advantage of this is is say you have an abusive user and do
 killall -u baduser - they can't escape this by scheduling cron jobs.

Good (side)note;  just recently I've noticed there is no single
step solution to prevent selected user from cron without removing
this user or disabling cron altogether or perhaps applying some SELinux
magic (plus there are possibly more related issues like bypassing
cron.{allow,deny} through another user, but haven't checked it).

-- 
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Multirelease effort: Moving to Python 3

[Jan Pokorný]

On 23/07/13 03:16 -0400, Bohuslav Kabrda wrote:
 - Original Message -
 On 19/07/13 02:41 -0400, Bohuslav Kabrda wrote:
 - Original Message -
 On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
 FAQ:
 Q: Why do we need to switch to Python 3?
 A: Because Python 2 is old, slower, less pythonic, doesn't get any more
 functionality and it won't be that long before the official upstream
 support ends [1]
 
 Although I agree with the need to switch to python3, I don't think the
 first
 three reasons are very compelling arguments (they're only half-truths) --
 we
 should concentrate on the last reason and also on features that python3
 has that pyhton2 doesn't.  Chained exceptions are a pretty nice thing, for
 instance.
 
 
 So first three reason:
 - Python 2 is old - how is that a half-truth?
 - Slower - yes, in the beginning, Python 3 was significantly slower
 because of nonoptimal code after the rewrite from Python 3. But with
 Python 3.3 for instance, you get tons of speed improvements -
 decimal module for instance got a significant boost. Brett Cannon
 had a nice presentation about speed benchmarking [1]. Yes, Python 3
 is slower in some areas, but mostly it's faster.
 
 Mind to share some grounds for this claim?  My negligible experience
 told me the contrary, but perhaps timeit module is a bad indicator.
 
 
 There is the presentation that I referenced in the email that you
 reacted to (referenced by [1]).

Saw the presentation before actually replying -- it doesn't show
any evidence Python 3.3 would be noticably faster.  And my micro
tests unfortunately fell into the slower category as nicely
demonstrated in the graphs there.

 You can also have a look at pystone benchmark results (a quick googling
 around gave me e.g.
 http://www.levigross.com/post/2340736877/pystone-benchmark-on-2-6-2-7-3-2)

This is more than two years old.  The score reliability of this benchmark
is also questionable (not speaking about order of magnitude difference as
with PyPy).

 Otherwise yes, let's get gently beyond 3000.

-- 
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Multirelease effort: Moving to Python 3

[Jan Pokorný]

On 19/07/13 02:41 -0400, Bohuslav Kabrda wrote:
 - Original Message -
 On Thu, Jul 18, 2013 at 11:24:22AM -0400, Bohuslav Kabrda wrote:
 FAQ:
 Q: Why do we need to switch to Python 3?
 A: Because Python 2 is old, slower, less pythonic, doesn't get any more
 functionality and it won't be that long before the official upstream
 support ends [1]
 
 Although I agree with the need to switch to python3, I don't think the first
 three reasons are very compelling arguments (they're only half-truths) -- we
 should concentrate on the last reason and also on features that python3
 has that pyhton2 doesn't.  Chained exceptions are a pretty nice thing, for
 instance.
 
 
 So first three reason:
 - Python 2 is old - how is that a half-truth?
 - Slower - yes, in the beginning, Python 3 was significantly slower
 because of nonoptimal code after the rewrite from Python 3. But with
 Python 3.3 for instance, you get tons of speed improvements -
 decimal module for instance got a significant boost. Brett Cannon
 had a nice presentation about speed benchmarking [1]. Yes, Python 3
 is slower in some areas, but mostly it's faster.

Mind to share some grounds for this claim?  My negligible experience
told me the contrary, but perhaps timeit module is a bad indicator.

Otherwise yes, let's get gently beyond 3000.

-- 
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of Hardened Packages

[Jan Pokorný]

On 15/04/13 10:10 -0400, Steve Grubb wrote:
 I would say there is a place for SE Linux even if we compiled everything with 
 all because FORTIFY_SOURCE coverage is not absolute. For example, about a 
 month ago i ran the following test:
 
 procs=`ls /proc | grep '^[0-9]' | sort -n`
 for p in $procs
 do
   res=`cat /proc/$p/maps 2/dev/null |  awk '$2 ~ wx { print $2 }'`
   if [ x$res != x ] ; then
   cat /proc/$p/cmdline | awk '{ printf %-35s\t, $1 }'
   printf %s\n $p
   fi
 done
 
 
 What this does is display the programs with Writable and Executable memory. 
 All Fedora desktops except Mate have WX memory. (I checked KDE, Gnome, 
 Cinnamon, and Mate.)

FWIW, LXDE seems to be fine as well (if polkitd and firefox are not counted
in).

-- 
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel