Re: Join the new Minimization Team

[John Harris]

On Tuesday, July 30, 2019 9:05:31 AM MST Christian Glombek wrote:
> I would be especially interested in minimizing container images.
> I'd like to e.g. see purpose-built containers without an actual package
> manager inside. You just have the container, mount the config, and go.
> We're also trying to minimize Fedora CoreOS[1], so this is definitely a
> topic of overall interest!
> 
> [1] https://github.com/coreos/fedora-coreos-tracker/issues/186
> 
> Christian Glombek
> 
> Associate Software Engineer
> 
> Red Hat GmbH 
>  3.4191433,17z/data=!3m1!4b1!4m5!3m4!1s0x47a84e30d99f7f43:0xe6059fb480bfd85c!
> 8m2!3d52.5058176!4d13.421332>
> 
> cglom...@redhat.com 
> 
> 
> 
> Red Hat GmbH, http://www.de.redhat.com/, Sitz: Grasbrunn,
> Handelsregister: Amtsgericht München, HRB 153243,
> Geschäftsführer: Charles Cachera, Michael O'Neill, Tom Savage, Eric Shander
> 
> On Tue, Jul 30, 2019 at 5:24 PM Neal Gompa  wrote:
> > On Tue, Jul 30, 2019 at 10:58 AM Adam Samalik  wrote:
> > > Hi everyone!
> > > 
> > > I'm starting a Minimization Objective [1] focusing on minimising the
> > 
> > installation size of some of the popular apps, runtimes, and other pieces
> > of software in Fedora.
> > 
> > > And there is a new Minimization Team [2] forming. Members of the team
> > 
> > will consult and work with Fedora maintainers, develop tooling and
> > services, generate reports showing the status of the Fedora ecosystem and
> > a
> > comparison with other ecosystems, etc. The goal is to build an environment
> > where it's easy for our maintainers to keep things small over time, it's
> > not just a one-off effort. Please see the Action Plan [3] for more
> > details.
> > 
> > > Want to become a member? Let me know!
> > > 
> > > Cheers!
> > > Adam
> > > 
> > > [1] https://docs.fedoraproject.org/en-US/minimization/
> > > [2] https://docs.fedoraproject.org/en-US/minimization/team/
> > > [3] https://docs.fedoraproject.org/en-US/minimization/action-plan/
> > 
> > I'm interested, but not just for minimization for the sake of it. We
> > need to be thoughtful about how we are changing the dependency tree.
> > 
> > 
> > 
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!

Having a container without a package manager sounds like the worst possible 
thing to add to an already poorly implemented solution. In reality, 
containers, regardless of what they're running, should be treated as what they 
are, GNU/Linux installs. Each one should be self sufficient from the host 
system, so that they can be properly updated using a package manager.

Each container should, realistically, be a self contained system.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Better interactivity in low-memory situations

[John Harris]

On Sunday, August 18, 2019 4:33:47 AM MST Gordan Bobic wrote:
> On Sun, Aug 11, 2019 at 10:36 AM  wrote:
> > This seems like a distraction from the real goal here, which is to
> > ensure Fedora remains responsive under heavy memory pressure,
> 
> I think this is an overwhelmingly important point, and as somebody
> regularly working with ARM machines with tiny amounts of RAM, it is of
> considerable interest to me.
> I typically use CentOS because stability is important to me, but most
> worthwhile things filter to there, so I hope what I'm about to say is not
> _too_ deprecated.
> 
> 1) Compile options
> From what I can tell from rpm macro options, default on C7 seems to be -O2.
> -Os seems to help in most cases.
> Adding -ffunction-sections -fdata-sections to defaults can help
> considerably in producing smaller binaries, and is not the default.
> Linking with -Wl,--gc-sections helps a lot and is not the default
> Extensive stripping seems to already be the default (--strip-unneeded,
> removal of .comment and .note sections)
> 
> 2) Runtime condiguration
> Default stack size is 8192 (ulimit -s). This unnecessarily eats a
> considerably amount of memory. I have yet to see anything that actually
> experiences problems with 1M.
> 
> 3) zram
> This was mentioned earlier in the thread, and on most of my systems, memory
> constrained or otherwise, unless I have an overwhelming reason not to, I
> run with zram swap equal in size to RAM with lz4 compression and
> vm.swappiness=100. I typically see compression ratios between 2:1 and 3:1
> in zram, so on a system with, say, 10GB of RAM, it would provide 10GB of
> very fast swap at a cost of 3-5GB of RAM. This seems like a favourable
> trade off, especially on systems with extremely constrained RAM (e.g. ARM
> devices with 512MB of RAM).
> 
> I'm sure there is more that can be done, but this seems like a good start
> as far as the cost / benefit is concerned.

Python, Lua and a few other common programs can have issues with a stack size 
of 1MiB.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Projects in Copr @ discussion.f.o

[John Harris]

On Friday, August 16, 2019 8:07:17 AM MST Tristan Cacqueray wrote:
> On Fri, Aug 16, 2019 at 13:31 Miroslav Suchý wrote:
> > Hi,
> > 
> > I want to soon enable embedded discussion on Copr projects pages. I 
created:
> >   https://discussion.fedoraproject.org/c/projects-in-copr
> > 
> > There is one downside thou - if you enabled
> > 
> >   Preferences -> Emails -> Enable mailing list mode
> > 
> > (which BTW discouraged by Discourse devels) then you are likely receiving
> > a lots of emails about creating new topics in this category.
> > 
> > There are two solutions available:
> >  1) turn off Mailing list mode (or create mail filter) or
> >  2) go to
> >  
> > https://discussion.fedoraproject.org/c/projects-in-copr
> > 
> > in upper right corner, click on the circle and select "Muted"
> 
> This also appears in the "New" link on the discuss top menu.
> Could the projecs-in-copr be muted by default?
> 
> Thanks,
> -Tristan

Preferably, muted by default and disabled for the Email gateway, if not 
disabled outright.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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

Fedora-31-20190820.n.4 compose check report

[Fedora compose checker]

No missing expected images.

Failed openQA tests: 72/152 (x86_64), 1/2 (arm)

ID: 433654  Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/433654
ID: 433655  Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/433655
ID: 433656  Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/433656
ID: 433658  Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/433658
ID: 433664  Test: x86_64 Server-dvd-iso support_server
URL: https://openqa.fedoraproject.org/tests/433664
ID: 433667  Test: x86_64 Server-dvd-iso install_repository_nfs_variation
URL: https://openqa.fedoraproject.org/tests/433667
ID: 433668  Test: x86_64 Server-dvd-iso install_repository_nfs_graphical
URL: https://openqa.fedoraproject.org/tests/433668
ID: 433669  Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation
URL: https://openqa.fedoraproject.org/tests/433669
ID: 433670  Test: x86_64 Server-dvd-iso install_repository_hd_variation
URL: https://openqa.fedoraproject.org/tests/433670
ID: 433684  Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/433684
ID: 433688  Test: x86_64 Everything-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/433688
ID: 433689  Test: x86_64 Everything-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/433689
ID: 433690  Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/433690
ID: 433692  Test: x86_64 Workstation-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/433692
ID: 433705  Test: x86_64 KDE-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/433705
ID: 433707  Test: x86_64 KDE-live-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/433707
ID: 433708  Test: x86_64 KDE-live-iso install_no_user
URL: https://openqa.fedoraproject.org/tests/433708
ID: 433721  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/433721
ID: 433723  Test: x86_64 Silverblue-dvd_ostree-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/433723
ID: 433725  Test: x86_64 Silverblue-dvd_ostree-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/433725
ID: 433733  Test: x86_64 universal install_package_set_minimal
URL: https://openqa.fedoraproject.org/tests/433733
ID: 433736  Test: x86_64 universal install_repository_http_variation
URL: https://openqa.fedoraproject.org/tests/433736
ID: 433737  Test: x86_64 universal install_repository_http_graphical
URL: https://openqa.fedoraproject.org/tests/433737
ID: 433738  Test: x86_64 universal install_mirrorlist_graphical
URL: https://openqa.fedoraproject.org/tests/433738
ID: 433739  Test: x86_64 universal install_delete_pata
URL: https://openqa.fedoraproject.org/tests/433739
ID: 433740  Test: x86_64 universal install_delete_pata@uefi
URL: https://openqa.fedoraproject.org/tests/433740
ID: 433741  Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/433741
ID: 433742  Test: x86_64 universal install_sata@uefi
URL: https://openqa.fedoraproject.org/tests/433742
ID: 433744  Test: x86_64 universal install_scsi_updates_img
URL: https://openqa.fedoraproject.org/tests/433744
ID: 433745  Test: x86_64 universal install_multi
URL: https://openqa.fedoraproject.org/tests/433745
ID: 433746  Test: x86_64 universal install_multi@uefi
URL: https://openqa.fedoraproject.org/tests/433746
ID: 433747  Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/433747
ID: 433748  Test: x86_64 universal install_simple_free_space
URL: https://openqa.fedoraproject.org/tests/433748
ID: 433749  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/433749
ID: 433750  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/433750
ID: 433751  Test: x86_64 universal install_delete_partial
URL: https://openqa.fedoraproject.org/tests/433751
ID: 433752  Test: x86_64 universal install_btrfs
URL: https://openqa.fedoraproject.org/tests/433752
ID: 433753  Test: x86_64 universal install_ext3
URL: https://openqa.fedoraproject.org/tests/433753
ID: 433754  Test: x86_64 universal install_xfs
URL: https://openqa.fedoraproject.org/tests/433754
ID: 433755  Test: x86_64 universal install_lvmthin
URL: https://openqa.fedoraproject.org/tests/433755
ID: 433756  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/433756
ID: 433757  Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/433757
ID: 433758  Test: x86_64 universal install_blivet_ext3
URL: h

a f31 branched compose is syncing...

[Kevin Fenzi]

Finally.

Sorry for the long delay in this, but it kept hitting problem after
problem. ;(

It is syncing now, and expect it to sync out past the master mirror
tonight.

kevin



signature.asc
Description: OpenPGP digital 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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Tuesday, August 20, 2019 8:19:24 PM MST Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 9:16 PM John Harris  wrote:
> 
> >
> >
> > On Tuesday, August 20, 2019 7:45:15 PM MST Chris Murphy wrote:
> > 
> > > On Tue, Aug 20, 2019 at 6:38 PM Solomon Peachy 
> > > wrote:
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > > On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> > > >
> > > >
> > > >
> > > > > Why wouldn't it be appropriate for a system running on battery
> > > > > power?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I've personally had this happen to me several times, where (far more
> > > > improtantly than the battery) a laptop tucked into a confined sleeve
> > > > got
> > > > inadvertantly powered on and essentially baked itself while sitting
> > > > at
> > > > that password prompt.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > So, yes, powering off is a completely sensible thing to do.
> > >
> > >
> > >
> > >
> > > This is an interesting example. It's such a significant liability
> > > (home fires and airplane fires are particularly bad), I wonder if
> > > manufacturers have heat and lid sensors feeding back to the firmware
> > > to force a poweroff in such a situation. And perhaps they do and no
> > > one is willing to test it (for all I know it's a temperature range
> > > that can cause hardware damage). From the limited examples so far,
> > > clearly manufacturers cannot trust that the operating system will
> > > ensure proper behavior, for any number of reasons. Or maybe they
> > > design the case to "reasonably" contain the smoldering left overs of
> > > what was your laptop.
> >
> >
> >
> > There is no significant fire risk from this. It's just not good for the
> > laptop. There's not exactly a temperature range that can cause damage,
> > but
> > there is a nominal range for each individual chip, and a nominal range for
> > the
 entire system based on that. Anything over isn't guaranteed to do
> > damage, but will definitely degrade performance, and anything
> > significantly outside of that range, in either extreme, could do
> > permanent damage.
> 
> 
> And this nice response is a very strong argument against the current
> behavior, and can't be construed as supportive of it.
> 
> 
> -- 
> Chris Murphy
> ___
> 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

It simply negates your claim, nothing more.

We're not considering fire risks here. Once a system reaches the upper, and 
sometimes lower, extreme of that system's rated range (which will be different 
per system, and not something we can throw in the OS), the EC, the PMC, the MC 
or similar system will shut down the system on most consumer hardware, unless 
the user has explicitly disabled it, which isn't possible without flashing 
your own firmware on many systems.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Tuesday, August 20, 2019 7:59:44 PM MST Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 8:37 PM John Harris  wrote:
> 
> >
> >
> > On Tuesday, August 20, 2019 7:35:05 PM MST Chris Murphy wrote:
> > 
> > > On Tue, Aug 20, 2019 at 5:35 PM John Harris 
> > > wrote:
> > >
> > >
> > >
> > > >
> > > >
> > > >
> > > > I think we can all agree that shutting the system down is not the
> > > > appropriate
> >  
> >  behavior, right?
> >  
> > >
> > >
> > >
> > > I do not agree at all, even a little bit.
> > >
> > >
> > >
> > > --
> > > Chris Murphy
> >
> >
> >
> > Okay, why?
> 
> 
> I've already explained why upthread. I put it in the category of
> 'unintentionally absurd behaviors' and this being planet Earth, it's a
> very long list. 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.
> 
> And just to be extra clear, I am referring primarily to laptops. But
> the current behavior is specious, as default, even for a desktop. For
> servers, sure you may very well have a use case for a reboot, and it
> might take an hour for someone to get there with a keyboard, although
> that too is a little bit specious. I'd expect the more difficult a
> server is to access, the more effort would be put into having it
> equipped with a TPM or a hardware key for this purpose.
> 
> -- 
> Chris Murphy

I'm sorry, but I don't see a list anywhere. Could you provide me with the 
Message-Id?

In laptops, I would agree that we should add a cutoff before the battery is 
drained, as certain battery chemistries cannot be fully utilized if they 
frequently fall below a certain level, lithium-Ion in particular.

For a laptop, 3 minutes may be a sane option. Definitely not for a workstation 
or server. I personally don't like that on laptops either, as the laptop could 
have been remotely rebooted, and seeing that would be the nod somebody needs 
to see to go enter the key and get it booted, or what have you. I would 
personally disable it on my systems, for example, and I would recommend 
against setting it as the default because it is much different from current 
behavior.

Why would this behavior be in any way desirable on a desktop system? A TPM or 
other hardware key storage does not solve the same problem as asking for a key 
to be entered to decrypt.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Chris Murphy]

On Tue, Aug 20, 2019 at 9:16 PM John Harris  wrote:
>
> On Tuesday, August 20, 2019 7:45:15 PM MST Chris Murphy wrote:
> > On Tue, Aug 20, 2019 at 6:38 PM Solomon Peachy  wrote:
> >
> > >
> > >
> > > On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> > >
> > > > Why wouldn't it be appropriate for a system running on battery power?
> > >
> > >
> > >
> > > I've personally had this happen to me several times, where (far more
> > > improtantly than the battery) a laptop tucked into a confined sleeve got
> > > inadvertantly powered on and essentially baked itself while sitting at
> > > that password prompt.
> > >
> > >
> > >
> > > So, yes, powering off is a completely sensible thing to do.
> >
> >
> > This is an interesting example. It's such a significant liability
> > (home fires and airplane fires are particularly bad), I wonder if
> > manufacturers have heat and lid sensors feeding back to the firmware
> > to force a poweroff in such a situation. And perhaps they do and no
> > one is willing to test it (for all I know it's a temperature range
> > that can cause hardware damage). From the limited examples so far,
> > clearly manufacturers cannot trust that the operating system will
> > ensure proper behavior, for any number of reasons. Or maybe they
> > design the case to "reasonably" contain the smoldering left overs of
> > what was your laptop.
>
> There is no significant fire risk from this. It's just not good for the
> laptop. There's not exactly a temperature range that can cause damage, but
> there is a nominal range for each individual chip, and a nominal range for the
> entire system based on that. Anything over isn't guaranteed to do damage, but
> will definitely degrade performance, and anything significantly outside of
> that range, in either extreme, could do permanent damage.

And this nice response is a very strong argument against the current
behavior, and can't be construed as supportive of it.


-- 
Chris Murphy
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Tuesday, August 20, 2019 7:45:15 PM MST Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 6:38 PM Solomon Peachy  wrote:
> 
> >
> >
> > On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> > 
> > > Why wouldn't it be appropriate for a system running on battery power?
> >
> >
> >
> > I've personally had this happen to me several times, where (far more
> > improtantly than the battery) a laptop tucked into a confined sleeve got
> > inadvertantly powered on and essentially baked itself while sitting at
> > that password prompt.
> >
> >
> >
> > So, yes, powering off is a completely sensible thing to do.
> 
> 
> This is an interesting example. It's such a significant liability
> (home fires and airplane fires are particularly bad), I wonder if
> manufacturers have heat and lid sensors feeding back to the firmware
> to force a poweroff in such a situation. And perhaps they do and no
> one is willing to test it (for all I know it's a temperature range
> that can cause hardware damage). From the limited examples so far,
> clearly manufacturers cannot trust that the operating system will
> ensure proper behavior, for any number of reasons. Or maybe they
> design the case to "reasonably" contain the smoldering left overs of
> what was your laptop.

There is no significant fire risk from this. It's just not good for the 
laptop. There's not exactly a temperature range that can cause damage, but 
there is a nominal range for each individual chip, and a nominal range for the 
entire system based on that. Anything over isn't guaranteed to do damage, but 
will definitely degrade performance, and anything significantly outside of 
that range, in either extreme, could do permanent damage.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Chris Murphy]

On Tue, Aug 20, 2019 at 8:37 PM John Harris  wrote:
>
> On Tuesday, August 20, 2019 7:35:05 PM MST Chris Murphy wrote:
> > On Tue, Aug 20, 2019 at 5:35 PM John Harris  wrote:
> >
> > >
> > >
> > > I think we can all agree that shutting the system down is not the
> > > appropriate
>  behavior, right?
> >
> >
> > I do not agree at all, even a little bit.
> >
> > --
> > Chris Murphy
>
> Okay, why?

I've already explained why upthread. I put it in the category of
'unintentionally absurd behaviors' and this being planet Earth, it's a
very long list. 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.

And just to be extra clear, I am referring primarily to laptops. But
the current behavior is specious, as default, even for a desktop. For
servers, sure you may very well have a use case for a reboot, and it
might take an hour for someone to get there with a keyboard, although
that too is a little bit specious. I'd expect the more difficult a
server is to access, the more effort would be put into having it
equipped with a TPM or a hardware key for this purpose.

-- 
Chris Murphy
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Chris Murphy]

On Tue, Aug 20, 2019 at 6:38 PM Solomon Peachy  wrote:
>
> On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> > Why wouldn't it be appropriate for a system running on battery power?
>
> I've personally had this happen to me several times, where (far more
> improtantly than the battery) a laptop tucked into a confined sleeve got
> inadvertantly powered on and essentially baked itself while sitting at
> that password prompt.
>
> So, yes, powering off is a completely sensible thing to do.

This is an interesting example. It's such a significant liability
(home fires and airplane fires are particularly bad), I wonder if
manufacturers have heat and lid sensors feeding back to the firmware
to force a poweroff in such a situation. And perhaps they do and no
one is willing to test it (for all I know it's a temperature range
that can cause hardware damage). From the limited examples so far,
clearly manufacturers cannot trust that the operating system will
ensure proper behavior, for any number of reasons. Or maybe they
design the case to "reasonably" contain the smoldering left overs of
what was your laptop.


-- 
Chris Murphy
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Tuesday, August 20, 2019 5:34:03 PM MST Alexander Ploumistos wrote:
> On Wed, Aug 21, 2019 at 2:43 AM John Harris  wrote:
> 
> >
> >
> > On Tuesday, August 20, 2019 2:35:03 AM MST Christophe de Dinechin wrote:
> > […]
> > 
> > > On macOS, when full disk encryption is active, there is a different
> > > boot-time login screen. The process is described here:
> > > https://support.apple.com/en-us/HT204837
> > >
> > >
> > >
> > > I've just checked, and the machine shuts down after a short while
> > > (about 3 minutes) when on battery power. Did not try on main power, but
> > > I doubt it's different. After one minute, a message shows up asking if
> > > you have trouble with your password and giving instructions.
> >
> >
> >
> >
> > I think we can all agree that shutting the system down is not the
> > appropriate behavior, right?
> 
> 
> Why wouldn't it be appropriate for a system running on battery power?

For a system running on battery, it'd be okay to throw in power down at ~30% 
or whatever user configurable percentage, in my opinion. If such a thing were 
to be implemented, I'd suggest defaulting to 30% on battery powered systems, 
and, in that one instance, it'd probably be okay to change it to that from the 
default behavior.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Tuesday, August 20, 2019 7:35:05 PM MST Chris Murphy wrote:
> On Tue, Aug 20, 2019 at 5:35 PM John Harris  wrote:
> 
> >
> >
> > I think we can all agree that shutting the system down is not the
> > appropriate
 behavior, right?
> 
> 
> I do not agree at all, even a little bit.
> 
> -- 
> Chris Murphy

Okay, why?

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Chris Murphy]

On Tue, Aug 20, 2019 at 5:35 PM John Harris  wrote:
>
> I think we can all agree that shutting the system down is not the appropriate
> behavior, right?

I do not agree at all, even a little bit.

-- 
Chris Murphy
___
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: Rebase option suddenly missing from src.fo.o PRs?

[Neal Gompa]

On Tue, Aug 20, 2019 at 9:46 PM Fabio Valentini  wrote:
>
> On Tue, Aug 20, 2019 at 11:16 AM Miro Hrončok  wrote:
> >
> > I've recently noticed that src.fo.o PRs no longer let me click "Rebase" 
> > under
> > the "Merge" button.
> >
> > Am I the only one impacted?
> >
> > Is that deliberate or some bug worth reporting?
>
> FWIW, the "Merge" button from the "merge popup" is also gone for me.
> I assume this is a regression from updating pagure from 5.5 to 5.7
> that happened a few days ago.
>

The issue is known and a fix is pending:
https://pagure.io/pagure/pull-request/4575

Once the PR is validated and merged, I will backport it to the pagure
package in Fedora and EPEL, which will let us roll out the fix to
production shortly thereafter.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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: gsl soname bump

[Jerry James]

I am happy to see a gsl update, but ...

On Tue, Aug 20, 2019 at 1:48 PM Susi Lehtola
 wrote:
> Triggering rebuilds of the following affected packages
...
> python-cvxopt

You didn't build this into the python 3.8 side tag, so now it is going
to have to be built again.  Any other python-using packages on this
list are in the same situation.  It would have been helpful to have
the week to plan that the updates policy requires:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/

Please do that next time.  Thanks,
-- 
Jerry James
http://www.jamezone.org/
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Solomon Peachy]

On Wed, Aug 21, 2019 at 03:34:03AM +0300, Alexander Ploumistos wrote:
> Why wouldn't it be appropriate for a system running on battery power?

I've personally had this happen to me several times, where (far more 
improtantly than the battery) a laptop tucked into a confined sleeve got 
inadvertantly powered on and essentially baked itself while sitting at 
that password prompt.

So, yes, powering off is a completely sensible thing to do.

 - Solomon
-- 
Solomon Peachy pizza at shaftnet dot org
High Springs, FL  ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum videtur.


signature.asc
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Alexander Ploumistos]

On Wed, Aug 21, 2019 at 2:43 AM John Harris  wrote:
>
> On Tuesday, August 20, 2019 2:35:03 AM MST Christophe de Dinechin wrote:
> […]
> > On macOS, when full disk encryption is active, there is a different
> > boot-time login screen. The process is described here:
> > https://support.apple.com/en-us/HT204837
> >
> > I've just checked, and the machine shuts down after a short while
> > (about 3 minutes) when on battery power. Did not try on main power, but
> > I doubt it's different. After one minute, a message shows up asking if
> > you have trouble with your password and giving instructions.
>
>
> I think we can all agree that shutting the system down is not the appropriate
> behavior, right?

Why wouldn't it be appropriate for a system running on battery power?
___
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: gsl soname bump

[Alexander Ploumistos]

On Tue, Aug 20, 2019 at 10:48 PM Susi Lehtola
 wrote:
> Triggering rebuilds of the following affected packages
> […]
> scidavis

Thank you!
___
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: Annoying Copr related emails

[John Harris]

On Tuesday, August 20, 2019 8:49:20 AM MST Miroslav Suchý wrote:
> Dne 20. 08. 19 v 15:38 John Harris napsal(a):
> 
> >  What's the plan for this? How is linking it to Discourse useful?
> 
> 
> People can discuss about Projects in Copr directly embedded on Copr pages.
> See example in staging:
> https://copr-fe-dev.cloud.fedoraproject.org/coprs/msuchy/jhlkjhlkhjlk/ 
> -- 
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> 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

I saw that, but what's the plan for that? What's its intended use case, and 
how is linking it to *Discourse* useful?

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Tuesday, August 20, 2019 2:35:03 AM MST Christophe de Dinechin wrote:
> Samuel Sieb writes:
> 
> 
> > On 8/20/19 1:17 AM, Benjamin Kircher wrote:
> > 
> >>> On 20. Aug 2019, at 04:15, Chris Murphy 
> >>> wrote:
> >>>
> >>>
> >>>
> >>> I'm not certain it matters, but I'm curious how Windows and macOS deal
> >>> with this same scenario. I'd be surprised if they just wait forever,
> >>> in particular if power is disconnected on laptop.
> >>
> >>
> >>
> >>
> >> As for macOS, it will shut down the machine after a minute or two
> >> (haven’t measured) if you do not enter your passphrase.
>
> >
> >
> > Do you mean for disk encryption or user login?  I've never seen disk
> > encryption on a Mac.
> 
> 
> On macOS, when full disk encryption is active, there is a different
> boot-time login screen. The process is described here:
> https://support.apple.com/en-us/HT204837
> 
> I've just checked, and the machine shuts down after a short while
> (about 3 minutes) when on battery power. Did not try on main power, but
> I doubt it's different. After one minute, a message shows up asking if
> you have trouble with your password and giving instructions.
> 
> 
> > ___
> > 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.o
> > rg
> 
> 
> --
> Cheers,
> Christophe de Dinechin (IRC c3d)

I think we can all agree that shutting the system down is not the appropriate 
behavior, right?

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Tuesday, August 20, 2019 7:54:40 AM MST Przemek Klosowski wrote:
> On 8/20/19 4:31 AM, Samuel Sieb wrote:
> >> At my work, most of the windows laptops have full disk encryption so
> >> I asked a coworker for some info.  She started her laptop on battery
> >> and let it sit at the encryption password prompt for about 30 minutes
> >> and nothing happened.  She also told me that she has seen other
> >> laptops at the office that were probably auto rebooted on Friday and
> >> were still waiting at the prompt on Monday.
> > 
> > I should point out that I think this is the Mcafee disk encryption,
> > not bitlocker, so that might be different.
> 
> It's exactly as you imply---McAfee waits for a typed password, whereas
> bitlocker typically uses TPM and so it proceeds to Windows user login,
> which times out and goes to sleep.

When BitLocker is used, and is configured properly, it simply shows a prompt 
forever. By "configured properly", I mean simply configured to use a password.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Tuesday, August 20, 2019 8:31:27 AM MST Przemek Klosowski via devel wrote:
> On 8/20/19 10:32 AM, John Harris wrote:
> 
> > On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote:
> > 
> >> the right thing to do  is to suspend on inactivity in all cases.
> > 
> > I don't think it's fair for one person to decide what the "right thing to
> > do" is. This kind of thinking is what leads to things like GNOME's awful
> > defaults.>
> >
> 
> I was just answering someone who said that this never happens and is not 
> important. I didn't mean to sound like I am deciding anything---as you 
> say, demanding changes is only valid when one provides patches to 
> implement them. In this case they may be tricky: Windows didn't 
> implement them either, until recently. BTW, do you disagree on this 
> specific issue, or just make a general point that people should not pass 
> judgment on what's right or not?

Considering an environment that I support would require this to be disabled 
(always show the prompt, while it's up), I would generally be against this 
change if it is not implemented as an option. Additionally, as this is being 
implement counter to the default behavior for the last decade, I would suggest 
that it be disabled by default, with an option for users to enable it if they 
would like.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Review swaps

[Ankur Sinha]

On Fri, Jul 26, 2019 19:27:31 +0200, Robert-André Mauchin wrote:
> Hello,
> 
> I'd like some help to review a handful of Golang packages:

Missed this e-mail. Sorry Robert! I'm happy to help with Golang reviews
too.  Are there any more reviews pending?

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
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

Trivial review swap: taskopen

[Ankur Sinha]

Hello,

Would anyone like to swap trivial reviews? I have "taskopen" here ready
for a full review:

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

taskopen- Script for taking notes and open urls with taskwarrior.

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
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: gsl soname bump

[Susi Lehtola]

On 8/20/19 9:57 PM, Jerry James wrote:

On Tue, Aug 20, 2019 at 12:12 PM Susi Lehtola
 wrote:

GSL 2.6 has just been released, and it comes with an soname bump. All
dependent packages will need to be rebuilt in rawhide.


Are you doing the rebuilds?  If so, when?


Triggering rebuilds of the following affected packages

3Depict
astrometry
asymptote
bogofilter
calligra
cocoalib
dieharder
enblend
espresso
freefem++
gambas3
gdl
getdp
giac
gipfel
gnuradio
guvcview
igt-gpu-tools
inkscape
krita
kst
kstars
LabPlot
libindi
luminance-hdr
mathgl
milia
mmseq
moose
morse2txt
mp
ncl
nco
nest
nip2
ocaml-gsl
octave-gsl
opengrm-ngram
orpie
orsa
perl-PDL
pfstools
player
pspp
pygsl
python-cvxopt
qgis
R-gsl
root
sagemath
scidavis
siril
step
vfrnav
xaos
--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
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: Better interactivity in low-memory situations

[Chris Murphy]

On Tue, Aug 20, 2019 at 2:15 AM Lennart Poettering  wrote:
>
> On Mo, 19.08.19 13:58, Chris Murphy (li...@colorremedies.com) wrote:
>
> > I'm skeptical as well. But to further explore this:
> >
> > 1. Does the kernel know better than to write a hibernation image (all
> > or part) to a /dev/zram device? e.g. a system with: 8GiB RAM, 8GiB
> > swap on ZRAM, 8GiB swap partition. We can use swap priority to use the
> > ZRAM device first, and conventional swap partition second. If the
> > user, today, were to hibernate, what happens?
>
> Usespace takes care of this. It tells the kernel which swap device to
> hibernate to and it nowadays understands that zswap is not a
> candidate, and picks the largest swap with the highes prio these days:

For what it's worth, swap on /dev/zram is a totally different thing than zswap.

/dev/zram is just a compressed RAM disk. You can configure a size, but
it only consumes memory as it actually gets used, dynamic allocation.
This can be used for swap standalone, no conventional disk based swap
partition is needed. But if there is one, and it's set to a lower
priority than swap on /dev/zram, then it has the effect of spilling
over (but spill over is uncompressed).

zswap basically always compresses all of swap, with a predefined size
memory pool "cache", and requires a conventional disk based swap
partition as the spill over. Spill over is also compressed.

They superficially sound very similar but the strategies are different
on the details. I've been using both strategies (separately), but have
the most experience with zswap even though above I was referring to
swap on a ZRAM device. I know, so many Z's.  But gist is, I can't
really discern any differences from a user point of view.

Zwap uses just a few kernel parameters to set it up. Whereas with swap
on zram, it requires a service unit file to setup the block device,
mkswap, and then swapon.

The swap on ZRAM thing is further complicated by multiple
implementations, and the preferred systemd zram-generator is
apparently broken.
https://github.com/systemd/zram-generator/issues/4

IoT folks are using swap on ZRAM now, via the Fedora zram package
(systemd unit file to set everything up). Anaconda folks have their
own built-in swap on ZRAM setup that runs on low memory systems when
anaconda is launched. This happens on both Fedora netinstalls and
LiveOS. And it makes sense for those use cases where a disk based swap
partition doesn't exist, and maybe shouldn't.

Whereas for servers and workstations, zswap is well suited, as they're
perhaps more likely to have a conventional swap partition and have use
cases where spillover is likely.

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/vm/zswap.rst?h=v5.1.12
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/vm/z3fold.rst

And

https://www.mjmwired.net/kernel/Documentation/blockdev/zram.txt

So why not zswap? Well, kernel documentation shows it as being
experimental still, but upstream considers it stable enough for
production use using zbud allocator now, and z3fold allocator by the
end of the summer they think.
https://bugzilla.kernel.org/show_bug.cgi?id=204563#c6

*shrug*


-- 
Chris Murphy
___
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: gsl soname bump

[Jerry James]

On Tue, Aug 20, 2019 at 12:12 PM Susi Lehtola
 wrote:
> GSL 2.6 has just been released, and it comes with an soname bump. All
> dependent packages will need to be rebuilt in rawhide.

Are you doing the rebuilds?  If so, when?
-- 
Jerry James
http://www.jamezone.org/
___
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: What does this koji error mean?

[Jason L Tibbitts III]

> "C" == Christopher   writes:

C> BuildError: package thrift is
C> blocked for tag f32-updates-candidate
C> (https://koji.fedoraproject.org/koji/taskinfo?taskID=37187038)

It means that thrift has been blocked in koji.  The usual reason for
this is that the package has been retired, and the block is what
actually removes the last-build version of package from the
distribution.

Looking in git I see that the package was retired 12 days ago
(https://src.fedoraproject.org/rpms/thrift/c/3f15a694dbea566c94faff611bfcb8c87572c552?branch=master),
and a revert was committed twelve hours ago. A ticket to unretire it was
also filed (https://pagure.io/releng/issue/8634) but that doesn't seem
to have been processed yet.

ἐπιθυμία:~❯ koji list-pkgs --show-blocked --tag f32|grep thrift
thrift  f32  releng 
 [BLOCKED]

 - J<
___
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

What does this koji error mean?

[Christopher]

What does this koji error mean?

BuildError: package thrift is blocked for tag f32-updates-candidate
(https://koji.fedoraproject.org/koji/taskinfo?taskID=37187038)
___
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

gsl soname bump

[Susi Lehtola]

Hi,


GSL 2.6 has just been released, and it comes with an soname bump. All 
dependent packages will need to be rebuilt in rawhide.

--
Susi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
___
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

Fedora Atomic Host Two Week Release Announcement: 29.20190820.0

[noreply]

A new Fedora Atomic Host update is available via an OSTree update:

Version: 29.20190820.0
Commit(x86_64): 94e8720e9b309db27ccdb39ee053eafe738bfc58b86e34deab193e748f906fae
Commit(aarch64): 
9587aa49cc734d9184754f3aaa4e37025e2103616f3c392578cbe246e3d39fa8
Commit(ppc64le): 
c6ae3bf8805a8db2197ce52f810680a4d2c1914226a2053d37fab711d984e158


We are releasing images from multiple architectures but please note
that x86_64 architecture is the only one that undergoes automated
testing at this time.

Existing systems can be upgraded in place via e.g. `atomic host upgrade`.

Corresponding image media for new installations can be downloaded from:

https://getfedora.org/en/atomic/download/

Alternatively, image artifacts can be found at the following links:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190820.0.aarch64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190820.0.aarch64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-ostree-aarch64-29-20190820.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190820.0.ppc64le.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190820.0.ppc64le.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-ostree-ppc64le-29-20190820.0.iso
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190820.0.x86_64.qcow2
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190820.0.x86_64.raw.xz
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190820.0.x86_64.vagrant-libvirt.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/x86_64/images/Fedora-AtomicHost-Vagrant-29-20190820.0.x86_64.vagrant-virtualbox.box
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-ostree-x86_64-29-20190820.0.iso

Respective signed CHECKSUM files can be found here:
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/aarch64/images/Fedora-AtomicHost-29-20190820.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/aarch64/iso/Fedora-AtomicHost-29-20190820.0-aarch64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/ppc64le/images/Fedora-AtomicHost-29-20190820.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/ppc64le/iso/Fedora-AtomicHost-29-20190820.0-ppc64le-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/x86_64/images/Fedora-AtomicHost-29-20190820.0-x86_64-CHECKSUM
https://alt.fedoraproject.org/pub/alt/atomic/stable/Fedora-29-updates-20190820.0/AtomicHost/x86_64/iso/Fedora-AtomicHost-29-20190820.0-x86_64-CHECKSUM

For direct download, the "latest" targets are always available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest
https://getfedora.org/atomic_raw_x86_64_latest
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest
https://getfedora.org/atomic_dvd_ostree_x86_64_latest

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest
https://getfedora.org/atomic_raw_aarch64_latest
https://getfedora.org/atomic_dvd_ostree_aarch64_latest

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest
https://getfedora.org/atomic_raw_ppc64le_latest
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest

Filename fetching URLs are available here:
x86_64:
https://getfedora.org/atomic_qcow2_x86_64_latest_filename
https://getfedora.org/atomic_raw_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_libvirt_x86_64_latest_filename
https://getfedora.org/atomic_vagrant_virtualbox_x86_64_latest_filename
https://getfedora.org/atomic_dvd_ostree_x86_64_latest_filename

aarch64:
https://getfedora.org/atomic_qcow2_aarch64_latest_filename
https://getfedora.org/atomic_raw_aarch64_latest_filename
https://getfedora.org/atomic_dvd_ostree_aarch64_latest_filename

ppc64le:
https://getfedora.org/atomic_qcow2_ppc64le_latest_filename
https://getfedora.org/atomic_raw_ppc64le_latest_filename
https://getfedora.org/atomic_dvd_ostree_ppc64le_latest_filenam

Re: [HEADS-UP]: Mercurial with Python3 on rawhide?

[Neal Becker]

I agree that subpackages for py2 and py3 seems best, but I'll have to
see if mercurial can be parallel installed without too much effort.
I don't expect to have time to work on this for the next 2 weeks.

On Sun, Aug 18, 2019 at 9:16 PM Mads Kiilerich  wrote:
>
> You are giving many good reasons why we need Mercurial packages for
> Python 2 and Python 3, side by side.
>
> That will make it possible for other packages to jump to Python 3. Your
> package will no longer be blocking, and it doesn't have to be your concern.
>
> It will also put the Mercurial package in the good position where it has
> done all the work of transitioning, and the python2 part will be
> entirely optional, only kept alive for benefit of other packages that
> still depend on it.
>
> I am working upstream with tortoisehg. While late, I don't expect any
> problems. The current blocker for Fedora packaging of tortoisehg is the
> lack of Python 3 Mercurial, and the biggest risk is that the Python 2
> Mercurial package goes away before I had time to transition the
> tortoisehg package to depend on Python 3 Mercurial.
>
> /Mads
>
>
>
> On 8/16/19 3:53 PM, Neal Becker wrote:
> > I think tortoisehg is not ported to python3
> >
> > On Wed, Aug 14, 2019 at 1:39 PM Neal Becker  wrote:
> >> I just tested hg-5.1.0 with the latest git version of hg-evolve on
> >> python3 and at least some basic things seem to be working.  One
> >> problem:
> >> hg
> >> *** failed to import extension hggit: No module named 'compat'
> >>
> >> That's with the latest pip version of hg-git (0.8.12).
> >>
> >> hg-git is a supported fedora package, so I think we need this to work.
> >>
> >> On Tue, Aug 13, 2019 at 9:35 AM Petr Stodulka  wrote:
> >>>
> >>>
> >>> On 12. 08. 19 22:36, Miro Hrončok wrote:
>  On 12. 08. 19 20:37, Petr Stodulka wrote:
> > Can you explain better what do you mean by that? I am little lost
> > here.
>  Sure. The idea was:
> 
>  1) When Fedora 31 is branched (scheduled for tomorrow [1]), push the 
>  switch to rawhide (Fedora 32)
> 
>  2) See what happens, collect feedback.
> 
>  3) Soon before F31 Beta Freeze (scheduled for 2019-08-29 [1]) decide 
>  whether this is worth pushing to F31 (probably not)
> 
>  4) Soon before F32 mass Python 2 removal flag day (scheduled for mid 
>  November [2]), decide whether to revert and request and exception or not
> 
>  [1] https://fedoraproject.org/wiki/Releases/31/Schedule
>  [2] 
>  https://fedoraproject.org/wiki/Changes/RetirePython2#Detailed_Description
> 
> >>> Thanks Miro for explanation. That sounds asi the best idea now probably. 
> >>> From that point, I will not create new subpackages for Py2 / Py3 and I 
> >>> will just do the switch tomorrow.
> >>>
> >>> @mercurial-maintainers: if anyone have something against or better 
> >>> solution, answer here guys, otherwise I will do the rebase.
> >>> Just FYI, I will be kinda offline between 2019-08-15 - 2019-08-25 because 
> >>> of PTO. So in case of troubles, I will not be able to do anything during 
> >>> that time. From that point, I could postpone the rebase if needed, but I 
> >>> hope that someone else will be able to help around instead of me in case 
> >>> of troubles.
> >>>
> >>> --
> >>> Petr Stodulka
> >>> OS & Application Modernization
> >>> IRC nicks: pstodulk, skytak
> >>> Software Engineer
> >>> Red Hat Czech s.r.o.
> >>
> >>
> >> --
> >> Those who don't understand recursion are doomed to repeat it
> >
> >
>


-- 
Those who don't understand recursion are doomed to repeat it
___
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: unable to branch to epel8

[Kevin Fenzi]

On 8/20/19 8:50 AM, Dave Love wrote:
> Kevin Fenzi  writes:
> 
>> Hum. I see you have a lot of custom rules. Sadly the interface for doing
>> rules is confusing and over detailed. Would you be willing to do the
>> reset on them, then slowly re-add the filtering out of ones you don't
>> want? I think something in your rules is negating each ruleset and
>> making it not send anything.
> 
> To follow up on this, after reset the rules I am now at least getting a
> lot more (including stuff from CentOS??).  I wonder why that worked now
> when it didn't before...  Anyhow, thanks for getting me to try again,
> despite the quote about insanity attributed to Einstein.

Glad it's working at least somewhat for you now.

The CentOS messages are likely from centos-ci... Fedora uses the CentOS
CI setup to run tests on packages. :)

kevin




signature.asc
Description: OpenPGP digital 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: Getting .fc32 packages while trying to follow F31 branch ?

[Kevin Fenzi]

On 8/20/19 8:19 AM, Leigh Scott wrote:
>> On 8/19/19 3:31 PM, David Jeremias Vásquez Sicay wrote:
> 
>> Please stand by.
> 
> Is the beta freeze going to be delayed because of this? 

Good question. Can be brought up at the next fesco meeting if there's
folks that want more time...

kevin




signature.asc
Description: OpenPGP digital 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-gpg-keys not updated yet again

[Kevin Fenzi]

On 8/20/19 7:37 AM, Petr Mensik wrote:
> Hi!
> 
> I could not find a safe way to upgrade also this time. I found update
> F32 [1], but not corresponding F31 just adding new key. I am missing
> update similar to [2], just for F31 that once was Rawhide. It should be
> version 31-0.5
> 
> I found and reopened one old bug [3]. I do not think this is just second
> time.

Yes, it is that version, but there is not any compose that it exists in
yet.

> On 8/19/19 11:32 PM, Kevin Fenzi wrote:
>> So, a few things to note:
>>
>> * fedora-repos was updated for rawhide, however, unfortunately, It had
>> two extra spaces on the first line... "  " which made gpg consider it
>> invalid. This is likely the cause of any breakage with rawhide (mock,
>> containers, copr, etc). This has been fixed in the newest fedora-repos
>> package for f32/rawhide.
>>
>> * There is no f31 repo because we have not yet had a fedora 31 branched
>> compose finish. So, mirrormanager is pointing people to rawhide. This is
>> likely the cause of all problems related to f31.
> I think this is a major point. I could not find update with
> fedora-repos-31-0.5 signed. Instead, there is 32-0.1 served both by f31
> updates and rawhide repo. I think there must be first updated GPG keys
> N, which increases just minor version, not a major one. Major version
> should be increased only after branching. Unless I am mistaken, rawhide
> served me 32-0.1 signed by key contained inside. Okay, I had rawhide
> repo enabled. But even
> $ dnf --repo=updates --releasever=31 upgrade fedora-gpg-keys
> did not offer different version. What was worse, both were signed by the
> same F32 key.

yes, because both f31 and f32 are currently pointing to f32 (rawhide).

If we had a f31 compose you would not have hit this. You would update to
the new f31 version and from there you could upgrade to f32 or stay on f31.

kevin



signature.asc
Description: OpenPGP digital 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: Getting .fc32 packages while trying to follow F31 branch ?

[Kevin Fenzi]

On 8/19/19 1:26 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Aug 19, 2019 at 10:23:49PM +0200, Adrian Reber wrote:
>> On Mon, Aug 19, 2019 at 01:18:09PM -0700, Kevin Fenzi wrote:
>>> On 8/19/19 1:13 PM, Adrian Reber wrote:
 On Mon, Aug 19, 2019 at 11:59:49AM -, Leigh Scott wrote:
>> There is no f31 repo yet 
>> https://dl.fedoraproject.org/pub/fedora/linux/development/ so
>> perhaps mirror-manager is redirecting f31 to rawhide.
>
> It is mirror manager doing the redirection to rawhide.
>
> https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch

 For convenience there are repository redirects from n+1 to rawhide. I
 had to remove them manually and in a few hours mirrormanager should
 point to the correct repositories. If not, please open a ticket.
>>>
>>> Except there is not a correct repository to point to.
>>>
>>> Until we have a f31 compose...we can't point to that f31 compose. ;)
>>
>> Ah, so I was too fast removing the redirects. I have added them back, so
>> that 31 still points to rawhide.
> 
> That's not good either. People who want to follow branched
> (and many people do, esp. from the QA teams), will get packages from F32
> which they shouldn't.
> 
> I think broken links are prefereable to getting redirected to the wrong
> place.

Yeah, probibly so. :(

I think next branching we should look at perhaps disabling rawhide
composes until branched completes. Thats kind of a big hammer, but it
would avoid some of the pain.

kevin




signature.asc
Description: OpenPGP digital 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: Cannot build with mock for rawhide on Fedora 30

[Kevin Fenzi]

On 8/19/19 5:17 AM, Pavel Raiskup wrote:
> Hello Iñaki,
> 
> On Monday, August 19, 2019 1:29:31 PM CEST Iñaki Ucar wrote:
>> On Mon, 19 Aug 2019 at 13:03, Pavel Raiskup  wrote:
>>>
>>> On Saturday, August 17, 2019 1:07:04 PM CEST Iñaki Ucar wrote:
 The same happens in Copr.
>>>
>>> Copr is fixed now, builders have installed mock-core-configs and
>>> distribution-gpg-keys from updates-testing:
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-4724515cbd
>>> https://bodhi.fedoraproject.org/updates/FEDORA-2019-4644c0ee93
>>
>> Great, thanks. But as Zbigniew said in another thread [1], it would be
>> great to anticipate gpg key distribution in the future, to avoid this
>> problem every 6 months.
> 
> I concur with Zbigniew that we should have F33 keys in advance (see the
> different thread) to not repeat this situation for the third time.

I don't think that would help any of the issues in this thread at least.
Unless I am missing some...

>> Also, the projects marked to automatically follow Fedora branching haven't
>> branched yet. How long does it take?
> 
> The process has not been initiated yet in copr (no F31 at this moment).
> 
> Seems like builds in F31 chroot are signed by F32 keys (or the F31 chroot
> is effectively F32 chroot, I haven't had a time to check this).

Right. Mirrormanager is pointing both f31 and f32 at rawhide (f32).

> So this (mock -r fedora-31-x86_64) should be sorted out first before we
> enable F31 in copr.

Which will be sorted out once we have a fedora 31 compose.

kevin




signature.asc
Description: OpenPGP digital 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

Making a saved search public on Bugzilla

[Ankur Sinha]

Hello,

Would anyone know how to make a saved search public on Bugzilla? I.e.,
not require one to log in to view the bug list?

We have a saved search for NeuroFedora bugs and would like to make it
public if at all possible:

https://bugzilla.redhat.com/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=NeuroFedora%20bugs

I guess one possible way is to just use the whole search query:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&email1=neuro-sig%40lists.fedoraproject.org&emailassigned_to1=1&emailcc1=1&emaildocs_contact1=1&emaillongdesc1=1&emailqa_contact1=1&emailreporter1=1&emailtype1=substring&query_format=advanced

-- 
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | 
https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London


signature.asc
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: unable to branch to epel8

[Dave Love]

Kevin Fenzi  writes:

> Hum. I see you have a lot of custom rules. Sadly the interface for doing
> rules is confusing and over detailed. Would you be willing to do the
> reset on them, then slowly re-add the filtering out of ones you don't
> want? I think something in your rules is negating each ruleset and
> making it not send anything.

To follow up on this, after reset the rules I am now at least getting a
lot more (including stuff from CentOS??).  I wonder why that worked now
when it didn't before...  Anyhow, thanks for getting me to try again,
despite the quote about insanity attributed to Einstein.
___
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: Annoying Copr related emails

[Miroslav Suchý]

Dne 20. 08. 19 v 15:38 John Harris napsal(a):
>  What's the plan for this? How is linking it to Discourse useful?

People can discuss about Projects in Copr directly embedded on Copr pages. See 
example in staging:
https://copr-fe-dev.cloud.fedoraproject.org/coprs/msuchy/jhlkjhlkhjlk/

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Przemek Klosowski via devel]

On 8/20/19 10:32 AM, John Harris wrote:

On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote:

the right thing to do  is to suspend on inactivity in all cases.

I don't think it's fair for one person to decide what the "right thing to do"
is. This kind of thinking is what leads to things like GNOME's awful defaults.

I was just answering someone who said that this never happens and is not 
important. I didn't mean to sound like I am deciding anything---as you 
say, demanding changes is only valid when one provides patches to 
implement them. In this case they may be tricky: Windows didn't 
implement them either, until recently. BTW, do you disagree on this 
specific issue, or just make a general point that people should not pass 
judgment on what's right or not?

___
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: Getting .fc32 packages while trying to follow F31 branch ?

[Leigh Scott]

> On 8/19/19 3:31 PM, David Jeremias Vásquez Sicay wrote:

> Please stand by.

Is the beta freeze going to be delayed because of this? 
___
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

[Fedocal] Reminder meeting : Minimization Team Meeting

[asamalik]

Dear all,

You are kindly invited to the meeting:
   Minimization Team Meeting on 2019-08-21 from 15:00:00 to 16:00:00 GMT
   At fedora-meetin...@irc.freenode.net

The meeting will be about:
Meeting of the Fedora Minimization Team



Source: https://apps.fedoraproject.org/calendar/meeting/9598/

___
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: Annoying Copr related emails

[Florian Weimer]

* John Harris:

> I seem to have missed your responses there, likely due to the delays in the 
> email gateway.

I think the email gateway is restricted to 100 messages per day:



So it's possible that you never actually received the response by email.

Thanks,
Flor
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Przemek Klosowski]

On 8/20/19 4:31 AM, Samuel Sieb wrote:
At my work, most of the windows laptops have full disk encryption so 
I asked a coworker for some info.  She started her laptop on battery 
and let it sit at the encryption password prompt for about 30 minutes 
and nothing happened.  She also told me that she has seen other 
laptops at the office that were probably auto rebooted on Friday and 
were still waiting at the prompt on Monday.


I should point out that I think this is the Mcafee disk encryption, 
not bitlocker, so that might be different. 


It's exactly as you imply---McAfee waits for a typed password, whereas 
bitlocker typically uses TPM and so it proceeds to Windows user login, 
which times out and goes to sleep.


___
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: Getting .fc32 packages while trying to follow F31 branch ?

[Petr Mensik]

Hi Adrian,

I think this redirection is cause of breakage on rawhide machines. I
think we must be able to first serve separate repositories. Only then it
can proceed to increase of version in new rawhide.

My point is, n+1 has to be always signed by old key served in fedora and
updates repositories for that version. If next branching from rawhide
should be smooth:

1. new key has to exist in advance
2. n+1 has to keep old key that previous rawhide started with. No
package in fedora or updates or updates-testing repos should contain
package signed by n+2 key. n+2 key (and rawhide) can be used for signing
only after they are separate and n+1 repo is ready. Until that, only n+1
key must be used.

What are use cases when redirects are used? Would it make more sense to
redirect it opposite way, until rawhide is ready?

Hope it makes sense.

Regards,
Petr

On 8/19/19 10:13 PM, Adrian Reber wrote:
> On Mon, Aug 19, 2019 at 11:59:49AM -, Leigh Scott wrote:
>>> There is no f31 repo yet 
>>> https://dl.fedoraproject.org/pub/fedora/linux/development/ so
>>> perhaps mirror-manager is redirecting f31 to rawhide.
>>
>> It is mirror manager doing the redirection to rawhide.
>>
>> https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
> 
> For convenience there are repository redirects from n+1 to rawhide. I
> had to remove them manually and in a few hours mirrormanager should
> point to the correct repositories. If not, please open a ticket.
> 
>   Adrian
> ___
> 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
> 

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973
___
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-gpg-keys not updated yet again

[Petr Mensik]

Hi!

I could not find a safe way to upgrade also this time. I found update
F32 [1], but not corresponding F31 just adding new key. I am missing
update similar to [2], just for F31 that once was Rawhide. It should be
version 31-0.5

I found and reopened one old bug [3]. I do not think this is just second
time.

On 8/19/19 11:32 PM, Kevin Fenzi wrote:
> So, a few things to note:
> 
> * fedora-repos was updated for rawhide, however, unfortunately, It had
> two extra spaces on the first line... "  " which made gpg consider it
> invalid. This is likely the cause of any breakage with rawhide (mock,
> containers, copr, etc). This has been fixed in the newest fedora-repos
> package for f32/rawhide.
> 
> * There is no f31 repo because we have not yet had a fedora 31 branched
> compose finish. So, mirrormanager is pointing people to rawhide. This is
> likely the cause of all problems related to f31.
I think this is a major point. I could not find update with
fedora-repos-31-0.5 signed. Instead, there is 32-0.1 served both by f31
updates and rawhide repo. I think there must be first updated GPG keys
N, which increases just minor version, not a major one. Major version
should be increased only after branching. Unless I am mistaken, rawhide
served me 32-0.1 signed by key contained inside. Okay, I had rawhide
repo enabled. But even
$ dnf --repo=updates --releasever=31 upgrade fedora-gpg-keys
did not offer different version. What was worse, both were signed by the
same F32 key.

> 
> * Finally, updates are queued for f29/30/31 to add the f32 key. This
> shouldn't really be that big a deal unless you are running one of those
> and want to update to rawhide, or is there other cases here?
> 
> I think the first 2 items are the ones causing problems, and the third
> is not so urgent as them. Sure, we can add it to the schedule and do it
> in advance, but the other things are the things to really avoid next time.
> 
> kevin
> 
> 
> 
> ___
> 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
> 

1. https://bodhi.fedoraproject.org/updates/FEDORA-2019-12c2cfd23a
2. https://bodhi.fedoraproject.org/updates/FEDORA-2019-7ac161b9d7
3. https://bugzilla.redhat.com/show_bug.cgi?id=1489628

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973



signature.asc
Description: OpenPGP digital 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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Monday, August 19, 2019 2:56:58 PM MST Przemek Klosowski wrote:
> the right thing to do  is to suspend on inactivity 
> in all cases.

I don't think it's fair for one person to decide what the "right thing to do" 
is. This kind of thinking is what leads to things like GNOME's awful defaults.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[John Harris]

On Monday, August 19, 2019 3:42:10 AM MST Artur Iwicki wrote:
> The fact whether we're in the OS or not, whether it's a bootloader or a
> pre-init script or whatever is irrelevant from the end-user perspective.
> The end-user sees that the system will wait the password endlessly and I
> agree with Joseph that it's not good behaviour.
 
> 
> >Do you have OLED monitor? Generic LCD/LED monitors does not suffer from
> >this issue. I never shut down my monitor for years and it works fine.
> The monitor damage is not the issue here; it's just a possible side effect
> of the issue. As Chris mentioned earlier - consider a battery-powered
> system, which will just wait for the password until the battery discharges
> completely. This behaviour simply isn't sensible, in my opinion, and -
> forgive the phrase - smells of "works for us, so why bother?" thinking.

I'm sorry if this comes off as a bit rude, but "works for us, so why bother" 
is an absolutely fine response, unless you're getting paid to implement said 
feature request.

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: calibre updated for python3

[Gwyn Ciesla via devel]

OIC. Thank you. :)


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, August 20, 2019 9:00 AM, Zbigniew Jędrzejewski-Szmek 
 wrote:

> On Tue, Aug 20, 2019 at 01:52:06PM +, Gwyn Ciesla wrote:
> 

> > This was on both f31 and f32.
> 

> Oh, OK. I misunderstood.
> python-soupsieve and python-bs4 were built yesterday, and
> calibre and python-html5-parser just today. I guess they will
> be available in the next compose. I think that for F31 there is some
> problem and there was no successful compose yet.
> 

> Zbyszek



signature.asc
Description: OpenPGP digital 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: calibre updated for python3

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 20, 2019 at 01:52:06PM +, Gwyn Ciesla wrote:
> This was on both f31 and f32.
Oh, OK. I misunderstood.
python-soupsieve and python-bs4 were built yesterday, and
calibre and python-html5-parser just today. I guess they will
be available in the next compose. I think that for F31 there is some
problem and there was no successful compose yet.

Zbyszek
___
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: Rebase option suddenly missing from src.fo.o PRs?

[Fabio Valentini]

On Tue, Aug 20, 2019, 12:57 Julen Landa Alustiza 
wrote:

> AFAIK, here are two different things,
>
>
> On one hand, since 5.6 you must check the allow rebase checklist button to
> allow the project owner to rebase your fork branch from where the PR is
> created. This property had been set to False on the migration from 5.5 to
> 5.7.4, so the previously existing PRs will not allow the owner to rebase
> PR. This is a feature. More background on
> https://pagure.io/pagure/c/e180e7ed38a944f087063a31c51ba6ac12bb715c?branch=master
>
> On the other hand, there is a regression around the merge button
> showing|hiding logic. This part is a bug.
>
Ah, thanks for clarifying. Also I can't even merge PRs via the API, since
one can't create API tokens that have the necessary ACL for merging pull
requests ... merging stuff locally should work, but it's annoying that the
UI is broken.

Fabio

19/8/20 11:26(e)an, Fabio Valentini igorleak idatzi zuen:
>
> On Tue, Aug 20, 2019 at 11:16 AM Miro Hrončok  
>  wrote:
>
> I've recently noticed that src.fo.o PRs no longer let me click "Rebase" under
> the "Merge" button.
>
> Am I the only one impacted?
>
> Is that deliberate or some bug worth reporting?
>
> FWIW, the "Merge" button from the "merge popup" is also gone for me.
> I assume this is a regression from updating pagure from 5.5 to 5.7
> that happened a few days ago.
>
> Fabio
>
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
>
> ___
> 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
>
> --
> Julen Landa Alustiza
> ___
> 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
>
___
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: calibre updated for python3

[Gwyn Ciesla via devel]

This was on both f31 and f32.


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, August 20, 2019 8:47 AM, Zbigniew Jędrzejewski-Szmek 
 wrote:

> On Tue, Aug 20, 2019 at 01:10:23PM +, Gwyn Ciesla via devel wrote:
> 

> > I can't install on f30 due to qt requirements, which is fine, but I can't 
> > install the BuildRequires either.
> > No matching package to install: 'python3dist(html5-parser) >= 0.4.8'
> > No matching package to install: 'python3dist(soupsieve)'
> 

> Yep, this will be rawhide/branched only for now.
> I don't want to push the soupsieve and bs4 into stable releases
> yet, because it seems that they are somewhat buggy. (And soupsieve
> requires newer bs4, etc.).
> 

> Zbyszek



signature.asc
Description: OpenPGP digital 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: calibre updated for python3

[Zbigniew Jędrzejewski-Szmek]

On Tue, Aug 20, 2019 at 01:10:23PM +, Gwyn Ciesla via devel wrote:
> I can't install on f30 due to qt requirements, which is fine, but I can't 
> install the BuildRequires either.
> 
> No matching package to install: 'python3dist(html5-parser) >= 0.4.8'
> No matching package to install: 'python3dist(soupsieve)'

Yep, this will be rawhide/branched only for now.
I don't want to push the soupsieve and bs4 into stable releases
yet, because it seems that they are somewhat buggy. (And soupsieve
requires newer bs4, etc.).

Zbyszek
___
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: Annoying Copr related emails

[John Harris]

On Monday, August 19, 2019 11:59:19 PM MST Miroslav Suchý wrote:
> Dne 20. 08. 19 v 6:20 John Harris napsal(a):
> 
> > Recently, I have noticed that there are at least 20 messages per day just
> > from  people viewing Copr repos being created on the "edora Discourse
> > email gateway. Has anyone else noticed these? Can we get this disabled,
> > so it stops spamming that mailing list with those useless emails?
> 
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> message/RAUFHZGRK4G7R6XL4MH6S5GMH57NLYCB/
 
> I already asked (via Fedora admin) for two RFE to easy the situation, but it
> will take some time. In the mean time, you have to resolve it via one of
> those mentioned approaches.
> 
> -- 
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys

I seem to have missed your responses there, likely due to the delays in the 
email gateway. For now, I'm just deleting everything that goes through 
projects-in-copr.discussion.fedoraproject.org. Still, why is this enabled to 
begin with? What's the plan for this? How is linking it to Discourse useful?

-- 
John M. Harris, Jr. 
Splentity
https://splentity.com/

___
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: calibre updated for python3

[Gwyn Ciesla via devel]

I can't install on f30 due to qt requirements, which is fine, but I can't 
install the BuildRequires either.

No matching package to install: 'python3dist(html5-parser) >= 0.4.8'
No matching package to install: 'python3dist(soupsieve)'


-- 
Gwyn Ciesla
she/her/hers
 
in your fear, seek only peace 
in your fear, seek only love
-d. bowie

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday, August 20, 2019 7:36 AM, Zbigniew Jędrzejewski-Szmek 
 wrote:

> Hi,
> 

> calibre in F31+ has been updated to the latest version (straight from
> git master actually, because of the many python3 fixes that haven't
> made it out into a release yet), and switched to run on python3.
> Upstream still considers py3 support still experimental, but some
> python2 dependencies were retired in Fedora, which forced calibre to
> switch too.
> 

> Please give it a spin and report any bugs.
> 

> Zbyszek
> 

> 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



signature.asc
Description: OpenPGP digital 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: recode-3.7.1 in Fedora 32 will change a soname

[Petr Pisar]

On 2019-08-16, Petr Pisar  wrote:
> I'm preparing an upgrade of "recode" pacakge from 3.6 to 3.7.1 version.
>
> Because it changes an ABI and a license (from (GPLv2+) to (GPLv3+ and
> LGPLv3+ and BSD and OFSFDL); the library itself from LGPLv2+ to
> LGPLv3+)), the upgrade will be performed in Rawhide only.
>
> Following packages will need to be rebuilt (and I will perform the
> rebuild):
>
> fortune-mod
> php
> python-bibtex
>
> Once upstream determines the new soname, I will commence.
>
Finished.

-- Petr
___
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

calibre updated for python3

[Zbigniew Jędrzejewski-Szmek]

Hi,

calibre in F31+ has been updated to the latest version (straight from
git master actually, because of the many python3 fixes that haven't
made it out into a release yet), and switched to run on python3.
Upstream still considers py3 support still experimental, but some
python2 dependencies were retired in Fedora, which forced calibre to
switch too.

Please give it a spin and report any bugs.

Zbyszek
___
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

Fedora-Rawhide-20190820.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
2 of 45 required tests failed, 2 results missing
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below
Unsatisfied gating requirements that could not be mapped to openQA tests:
FAILED: compose.cloud.all
MISSING: fedora.Workstation-boot-iso.x86_64.64bit - compose.install_default
MISSING: fedora.Workstation-boot-iso.x86_64.uefi - compose.install_default

Failed openQA tests: 27/150 (x86_64), 1/2 (arm)

New failures (same test not failed in Fedora-Rawhide-20190819.n.4):

ID: 433498  Test: x86_64 Server-boot-iso install_default **GATING**
URL: https://openqa.fedoraproject.org/tests/433498
ID: 433609  Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/433609
ID: 433622  Test: x86_64 universal install_multi_empty
URL: https://openqa.fedoraproject.org/tests/433622
ID: 433628  Test: x86_64 universal install_updates_img_local
URL: https://openqa.fedoraproject.org/tests/433628

Old failures (same test failed in Fedora-Rawhide-20190819.n.4):

ID: 433524  Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/433524
ID: 433548  Test: x86_64 Workstation-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/433548
ID: 433554  Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/433554
ID: 433559  Test: x86_64 KDE-live-iso desktop_update_graphical
URL: https://openqa.fedoraproject.org/tests/433559
ID: 433564  Test: x86_64 KDE-live-iso release_identification
URL: https://openqa.fedoraproject.org/tests/433564
ID: 433565  Test: arm Minimal-raw_xz-raw.xz 
install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/433565
ID: 433573  Test: x86_64 Silverblue-dvd_ostree-iso release_identification
URL: https://openqa.fedoraproject.org/tests/433573
ID: 433578  Test: x86_64 universal upgrade_2_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/433578
ID: 433579  Test: x86_64 universal upgrade_2_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/433579
ID: 433580  Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/433580
ID: 433581  Test: x86_64 universal upgrade_2_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/433581
ID: 433594  Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/433594
ID: 433599  Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/433599
ID: 433604  Test: x86_64 universal install_no_swap
URL: https://openqa.fedoraproject.org/tests/433604
ID: 433606  Test: x86_64 universal upgrade_kde_64bit
URL: https://openqa.fedoraproject.org/tests/433606
ID: 433607  Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/433607
ID: 433611  Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/433611
ID: 433623  Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/433623
ID: 433627  Test: x86_64 universal upgrade_desktop_encrypted_64bit
URL: https://openqa.fedoraproject.org/tests/433627
ID: 433631  Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/433631
ID: 433639  Test: x86_64 universal install_no_swap@uefi
URL: https://openqa.fedoraproject.org/tests/433639
ID: 433640  Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/433640
ID: 433646  Test: x86_64 universal upgrade_minimal_64bit
URL: https://openqa.fedoraproject.org/tests/433646
ID: 433648  Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/433648

Passed openQA tests: 122/150 (x86_64)

Skipped non-gating openQA tests: 1 of 152

Installed system changes in test x86_64 Server-dvd-iso install_default_upload: 
Used mem changed from 194 MiB to 171 MiB
System load changed from 0.18 to 0.06
Previous test data: https://openqa.fedoraproject.org/tests/433212#downloads
Current test data: https://openqa.fedoraproject.org/tests/433500#downloads

Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: 
Used mem changed from 196 MiB to 172 MiB
Previous test data: https://openqa.fedoraproject.org/tests/433216#downloads
Current test data: https://openqa.fedoraproject.org/tests/433504#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
System load changed from 1.11 to 0.44
Average CPU usage changed from 30.87619048 to 13.55238095
Previous test data: https://openqa.fedoraproject.org/tests/433411#downloads
Current test data: https://openqa.fedoraproject.org/tests/433534#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
Used

Fedora rawhide compose report: 20190820.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20190819.n.4
NEW: Fedora-Rawhide-20190820.n.0

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  1
Dropped packages:10
Upgraded packages:   23
Downgraded packages: 1

Size of added packages:  131.92 KiB
Size of dropped packages:249.83 MiB
Size of upgraded packages:   2.61 GiB
Size of downgraded packages: 28.93 KiB

Size change of upgraded packages:   64.20 MiB
Size change of downgraded packages: -141 B

= ADDED IMAGES =

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: python-soupsieve-1.9.2-1.fc32
Summary: CSS selector library
RPMs:python2-soupsieve python3-soupsieve
Size:131.92 KiB


= DROPPED PACKAGES =
Package: dsymbol-20181014gitec28618-9.fc31
Summary: Symbol lookup support for libdparse
RPMs:dsymbol dsymbol-devel dsymbol-geany-tags
Size:1.67 MiB

Package: dustmite-1-44.20150515git3498068.fc31
Summary: Minimizes D source code for debugging
RPMs:dustmite
Size:1.03 MiB

Package: earth-and-moon-backgrounds-0.2-15.fc31
Summary: Earth-and-moon desktop backgrounds
RPMs:earth-and-moon-backgrounds earth-and-moon-backgrounds-common 
earth-and-moon-backgrounds-dual earth-and-moon-backgrounds-kdm 
earth-and-moon-backgrounds-single
Size:218.72 MiB

Package: golang-github-nats-io-gnatsd-2.0.0-1.rc8.fc31.1
Summary: High-Performance server for NATS, the cloud native messaging system
RPMs:compat-golang-github-nats-io-server-devel golang-github-nats-io-gnatsd 
golang-github-nats-io-gnatsd-devel
Size:20.81 MiB

Package: libdparse-0.9.9-8.fc31
Summary: Library for lexing and parsing D source code
RPMs:libdparse libdparse-devel libdparse-geany-tags
Size:4.01 MiB

Package: msgpack-d-1.0.0-0.7.beta.7.fc31
Summary: MessagePack for D is a pure D implementation of MessagePack
RPMs:msgpack-d msgpack-d-devel msgpack-d-geany-tags
Size:1012.85 KiB

Package: python-gdata-2.0.18-14.fc31
Summary: A Python module for accessing online Google services
RPMs:python2-gdata
Size:953.12 KiB

Package: rubygem-binding_of_caller-0.8.0-2.fc31
Summary: Retrieve the binding of a method's caller
RPMs:rubygem-binding_of_caller rubygem-binding_of_caller-doc
Size:261.26 KiB

Package: rubygem-jquery-datatables-rails-3.4.0-2.fc31
Summary: jQuery datatables for rails
RPMs:rubygem-jquery-datatables-rails rubygem-jquery-datatables-rails-doc
Size:665.88 KiB

Package: stdx-allocator-2.77.2-8.fc31
Summary: High-level interface for allocators for D
RPMs:stdx-allocator stdx-allocator-devel stdx-allocator-geany-tags
Size:771.80 KiB


= UPGRADED PACKAGES =
Package:  ast-8.7.2-1.fc32
Old package:  ast-8.7.1-2.fc31
Summary:  A Library for Handling World Coordinate Systems in Astronomy
RPMs: ast ast-devel ast-doc
Size: 37.65 MiB
Size change:  28.25 KiB
Changelog:
  * Mon Aug 19 2019 Orion Poplawski  8.7.2-1
  - Update to 8.7.2


Package:  blender-1:2.80-7.fc32
Old package:  blender-1:2.80-5.fc32
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-fonts blender-rpm-macros
Size: 186.72 MiB
Size change:  1.91 MiB
Changelog:
  * Mon Aug 19 2019 Miro Hron??ok  - 1:2.80-6
  - Rebuilt for Python 3.8

  * Mon Aug 19 2019 Simone Caronni  - 1:2.80-7
  - Enable OpenVDB.


Package:  buildah-1.11.0-0.26.dev.gitc1a2d4f.fc32
Old package:  buildah-1.11.0-0.24.dev.gitc2c52ba.fc32
Summary:  A command line tool used for creating OCI Images
RPMs: buildah
Size: 37.07 MiB
Size change:  -59.33 KiB
Changelog:
  * Mon Aug 19 2019 Lokesh Mandvekar (Bot)  - 
1.11.0-0.25.dev.git51415ec
  - autobuilt 51415ec

  * Mon Aug 19 2019 Lokesh Mandvekar (Bot)  - 
1.11.0-0.26.dev.gitc1a2d4f
  - autobuilt c1a2d4f


Package:  canl-java-2.6.0-3.fc32
Old package:  canl-java-2.6.0-2.fc31
Summary:  EMI Common Authentication library - bindings for Java
RPMs: canl-java canl-java-javadoc
Size: 593.93 KiB
Size change:  -367 B
Changelog:
  * Mon Aug 19 2019 Mattias Ellert  - 2.6.0-3
  - Remove maven-javadoc-plugin configuration


Package:  fedora-obsolete-packages-32-2
Old package:  fedora-obsolete-packages-32-1
Summary:  A package to obsolete retired packages
RPMs: fedora-obsolete-packages
Size: 33.93 KiB
Size change:  252 B
Changelog:
  * Mon Aug 19 2019 Kalev Lember  - 32-2
  - Obsolete python2-libselinux and python2-libsemanage


Package:  gnome-maps-3.33.91-1.fc31
Old package:  gnome-maps-3.33.90-1.fc31
Summary:  Map application for GNOME
RPMs: gnome-maps
Size: 3.80 MiB
Size change:  4.64 KiB
Changelog:
  * Mon Aug 19 2019 Kalev Lember  - 3.33.91-1
  - Update to 3.33.91


Package:  gnome-shell-extension-topicons-plus-22-4.fc32.20190417.76759a5
Old package:  gnome-shell-extension-topicons-plus-22-3.fc31.20190417.76759a5
Summary:  Move all legacy tray icons to the top panel
RPMs: gnome-shell-extension-topicons-plus

Re: No matching package to install: 'libnbd-devel >= 0.9.6'

[Richard W.M. Jones]

Filed as:
https://pagure.io/releng/issue/8656

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
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: Rebase option suddenly missing from src.fo.o PRs?

[Julen Landa Alustiza]

AFAIK, here are two different things,


On one hand, since 5.6 you must check the allow rebase checklist button
to allow the project owner to rebase your fork branch from where the PR
is created. This property had been set to False on the migration from
5.5 to 5.7.4, so the previously existing PRs will not allow the owner to
rebase PR. This is a feature. More background on
https://pagure.io/pagure/c/e180e7ed38a944f087063a31c51ba6ac12bb715c?branch=master

On the other hand, there is a regression around the merge button
showing|hiding logic. This part is a bug.

19/8/20 11:26(e)an, Fabio Valentini igorleak idatzi zuen:
> On Tue, Aug 20, 2019 at 11:16 AM Miro Hrončok  wrote:
>> I've recently noticed that src.fo.o PRs no longer let me click "Rebase" under
>> the "Merge" button.
>>
>> Am I the only one impacted?
>>
>> Is that deliberate or some bug worth reporting?
> FWIW, the "Merge" button from the "merge popup" is also gone for me.
> I assume this is a regression from updating pagure from 5.5 to 5.7
> that happened a few days ago.
>
> Fabio
>
>> --
>> Miro Hrončok
>> --
>> Phone: +420777974800
>> IRC: mhroncok
>> ___
>> 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
> ___
> 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
-- 
Julen Landa Alustiza
___
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: Self Introduction: Muneendra

[Muneendra Kumar M via devel]

Hi Mathew,

My package is approved.

I need a sponsor any help here would be great.

Below are the details.



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



Regards,

Muneendra.



-Original Message-
From: Muneendra Kumar M [mailto:muneendra.ku...@broadcom.com]
Sent: Friday, August 2, 2019 9:27 PM
To: 'Matthew Miller' 
Cc: 'Development discussions related to Fedora' <
devel@lists.fedoraproject.org>
Subject: RE: Self Introduction: Muneendra



Hi Mathew,

I don't have sponsor.

I need a sponsor any help here would be great.



Regards,

Muneendra.





-Original Message-

From: Matthew Miller [mailto:mat...@fedoraproject.org
]

Sent: Friday, August 2, 2019 9:25 PM

To: Muneendra Kumar M 

Cc: Development discussions related to Fedora 

Subject: Re: Self Introduction: Muneendra



On Fri, Aug 02, 2019 at 09:18:35PM +0530, Muneendra Kumar M wrote:

> Hi Mathew,

>

> Thanks for providing the info.

> One quick question.

> Robert-Andre has given some review(feedaback) on my spec.

> Once I update the changes do I need to reply in the comments or is

> there any other procedure.

> If there is any link to the same if so could you please point me the same.

> This info  would help me a lot.





Sure -- the process is documented here:
https://fedoraproject.org/wiki/Package_Review_Process



Do you have a sponsor into the packaging group? You'll need that as well.



--

Matthew Miller



Fedora Project Leader
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Christophe de Dinechin]

Samuel Sieb writes:

> On 8/20/19 1:17 AM, Benjamin Kircher wrote:
>>> On 20. Aug 2019, at 04:15, Chris Murphy  wrote:
>>>
>>> I'm not certain it matters, but I'm curious how Windows and macOS deal
>>> with this same scenario. I'd be surprised if they just wait forever,
>>> in particular if power is disconnected on laptop.
>>
>>
>> As for macOS, it will shut down the machine after a minute or two (haven’t 
>> measured) if you do not enter your passphrase.
>
> Do you mean for disk encryption or user login?  I've never seen disk
> encryption on a Mac.

On macOS, when full disk encryption is active, there is a different
boot-time login screen. The process is described here:
https://support.apple.com/en-us/HT204837

I've just checked, and the machine shuts down after a short while
(about 3 minutes) when on battery power. Did not try on main power, but
I doubt it's different. After one minute, a message shows up asking if
you have trouble with your password and giving instructions.

> ___
> 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


--
Cheers,
Christophe de Dinechin (IRC c3d)
___
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: Rebase option suddenly missing from src.fo.o PRs?

[Fabio Valentini]

On Tue, Aug 20, 2019 at 11:16 AM Miro Hrončok  wrote:
>
> I've recently noticed that src.fo.o PRs no longer let me click "Rebase" under
> the "Merge" button.
>
> Am I the only one impacted?
>
> Is that deliberate or some bug worth reporting?

FWIW, the "Merge" button from the "merge popup" is also gone for me.
I assume this is a regression from updating pagure from 5.5 to 5.7
that happened a few days ago.

Fabio

> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> 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
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Benjamin Kircher]

> On 20. Aug 2019, at 10:20, Samuel Sieb  wrote:
> 
>>> On 20. Aug 2019, at 04:15, Chris Murphy  wrote:
>>> 
>>> I'm not certain it matters, but I'm curious how Windows and macOS deal
>>> with this same scenario. I'd be surprised if they just wait forever,
>>> in particular if power is disconnected on laptop.
>> As for macOS, it will shut down the machine after a minute or two (haven’t 
>> measured) if you do not enter your passphrase.
> 
> Do you mean for disk encryption or user login?  I've never seen disk 
> encryption on a Mac.

With disk encryption turned on. (They call it FileVault.)

BK
___
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

Rebase option suddenly missing from src.fo.o PRs?

[Miro Hrončok]

I've recently noticed that src.fo.o PRs no longer let me click "Rebase" under 
the "Merge" button.


Am I the only one impacted?

Is that deliberate or some bug worth reporting?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Samuel Sieb]

On 8/19/19 8:46 PM, Samuel Sieb wrote:

On 8/19/19 7:15 PM, Chris Murphy wrote:

I'm not certain it matters, but I'm curious how Windows and macOS deal
with this same scenario. I'd be surprised if they just wait forever,
in particular if power is disconnected on laptop.


At my work, most of the windows laptops have full disk encryption so I 
asked a coworker for some info.  She started her laptop on battery and 
let it sit at the encryption password prompt for about 30 minutes and 
nothing happened.  She also told me that she has seen other laptops at 
the office that were probably auto rebooted on Friday and were still 
waiting at the prompt on Monday.


I should point out that I think this is the Mcafee disk encryption, not 
bitlocker, so that might be different.

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Samuel Sieb]

On 8/20/19 1:17 AM, Benjamin Kircher wrote:

On 20. Aug 2019, at 04:15, Chris Murphy  wrote:

I'm not certain it matters, but I'm curious how Windows and macOS deal
with this same scenario. I'd be surprised if they just wait forever,
in particular if power is disconnected on laptop.



As for macOS, it will shut down the machine after a minute or two (haven’t 
measured) if you do not enter your passphrase.


Do you mean for disk encryption or user login?  I've never seen disk 
encryption on a Mac.

___
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: Bug 1742953 - No Screensaver/Powerdown after Inactivity at LUKS Password Prompt [FutureFeature]

[Benjamin Kircher]

> On 20. Aug 2019, at 04:15, Chris Murphy  wrote:
> 
> I'm not certain it matters, but I'm curious how Windows and macOS deal
> with this same scenario. I'd be surprised if they just wait forever,
> in particular if power is disconnected on laptop.


As for macOS, it will shut down the machine after a minute or two (haven’t 
measured) if you do not enter your passphrase.

BK
___
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: Better interactivity in low-memory situations

[Lennart Poettering]

On Mo, 19.08.19 13:58, Chris Murphy (li...@colorremedies.com) wrote:

> I'm skeptical as well. But to further explore this:
>
> 1. Does the kernel know better than to write a hibernation image (all
> or part) to a /dev/zram device? e.g. a system with: 8GiB RAM, 8GiB
> swap on ZRAM, 8GiB swap partition. We can use swap priority to use the
> ZRAM device first, and conventional swap partition second. If the
> user, today, were to hibernate, what happens?

Usespace takes care of this. It tells the kernel which swap device to
hibernate to and it nowadays understands that zswap is not a
candidate, and picks the largest swap with the highes prio these days:

https://github.com/systemd/systemd/blob/master/src/shared/sleep-config.c#L189

> 2. Are you suggesting it would be possible to build support for
> multiple swaps and have them dynamically enabled/disabled? e.g. the
> same system as above, but the 8GiB swap on disk is actually made
> across two partitions. i.e. a 2GiB partition and 6GiB partition.
> Normal operation would call for swapon for /dev/zram *and* the small
> on-disk swap. Only for hibernation would swapon happen for the larger
> on-disk swap partition (the 2GiB one always stays on).

Yes, that's what I was suggesting.

> That's... interesting. It sounds potentially complicated. I can't
> estimate if it could be fragile.

Yeah. It's an idea. No sure it's a good one though.

> Let's consider something else: Hibernation is subject to kernel
> lockdown policy on UEFI Secure Boot enabled computers. What percentage
> of Fedora users these days are likely subject to this lockdown? Are we
> able to effectively support hibernation? On the one hand, Fedora does
> not block on hibernation bugs (kernel or firmware), thus not
> supported. But tacitly hibernation is supported because a bunch of
> users pushed an effort with Anaconda folks to make sure the swap
> device is set with "resume=" boot parameter with out of the box
> installations.

We probably should look into supporting hibernation to encrypted swap
with a key tied to the TPM. That way hibernation should be fully safe.

> Another complicating issue: the Workstation working group has an issue
> to explore better protecting user data by encrypting /home by default.
> Of course, user data absolutely can and does leak into swap. Therefore
> I think we're obligated to consider encrypting swap too. And if swap
> is encrypted, how does resume from hibernation work? I guess
> kernel+initramfs load, and plymouth asks for passphrase which unlocks
> encrypted swap, and the kernel knows to resume from that device-mapper
> device?

I am pretty sure swap encryption really should be tied to the TPM. In
fact, it's one of the very few cases where tying things to the TPM
exclusively really makes sense.

So far noone prepared convincing patches to do this though. If anyone
wants to look into this, I'd be happy to review a patch for
systemd-cryptsetup for example.

Lennart

--
Lennart Poettering, Berlin
___
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: Annoying Copr related emails

[Miroslav Suchý]

Dne 20. 08. 19 v 6:20 John Harris napsal(a):
> Recently, I have noticed that there are at least 20 messages per day just 
> from 
> people viewing Copr repos being created on the "edora Discourse email 
> gateway. 
> Has anyone else noticed these? Can we get this disabled, so it stops spamming 
> that mailing list with those useless emails?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RAUFHZGRK4G7R6XL4MH6S5GMH57NLYCB/

I already asked (via Fedora admin) for two RFE to easy the situation, but it 
will take some time. In the mean time, you
have to resolve it via one of those mentioned approaches.

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
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