Re: libvirt and systemd-resolved integration?

2020-10-06 Thread Tomasz Torcz
On Tue, Oct 06, 2020 at 10:04:19PM +0200, Juan Orti Alcaine wrote:
> Hello,
> 
> In the network bridges that libvirt creates there's a dnsmasq daemon to
> resolve the VM's IPs. Is there any way to signal systemd-resolved from
> libvirt to say that in the bridge interface there is a DNS server and a
> domain?

  Related, there is nss-mymachines:
  https://www.freedesktop.org/software/systemd/man/nss-mymachines.html

  It resolves IPs of instances registered with machined. Libvirt already
registers virtual machines with machined. But as I see, libvirt does not
provide IP addresses during registration.  Maybe this could be fixed?

-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
___
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 32/33 livedisks do not boot on M$ system(s)

2020-10-03 Thread Tomasz Torcz
On Sat, Oct 03, 2020 at 11:17:44AM +0200, Marius Schwarz wrote:
> Am 02.10.20 um 11:12 schrieb Petr Pisar:
> > On Thu, Oct 01, 2020 at 11:07:28AM -0700, Samuel Sieb wrote:
> >> On 10/1/20 5:52 AM, Marius Schwarz wrote:
> >>>> Is it possible to boot from the stick and then perform a grub-install
> >>>> with an old grub?
> >>>>
> >>> This attempt failed too:
> >>>
> >>> #  grub2-install /dev/sda
> >>> grub2-install: Fehler: /usr/lib/grub/x86_64-efi/modinfo.sh existiert
> >>> nicht. Bitte geben Sie --target oder --directory an.
> >>>
> >>> and that file seems not to be part of any package. There is only one for
> >>> "i386-pc".
> >> You can't (and must not!) use grub2-install on an EFI system.
> > Of course you have. How else would you get GRUB EFI executable onto the boot
> > partition and register it into boot environments?
> >
> > But the correct invocation for EFI systems is different. You just use
> > "grub2-install" without the disk device name.
> If you do not state the devicename, how does grub choose the correct
> drive? I don't want to overwrite the bootloader on the ssd.

  There is only one correct ESP partition in EFI system to install
bootloader to. You can read the code finding it at
https://github.com/rhboot/grub2/blob/master/util/grub-install.c#L1029


-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
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: Donate 1 minute of your time to test upgrades from F32 to F33

2020-10-02 Thread Tomasz Torcz
On Fri, Oct 02, 2020 at 09:50:19AM +0200, Miroslav Suchý wrote:
> But very likely you get some dependency problem now. In that case, please 
> report it against the appropriate package. 


Error: 
 Problem: problem with installed package mosquitto-1.6.10-1.fc32.x86_64
   - mosquitto-1.6.10-1.fc32.x86_64 does not belong to a distupgrade repository
   - nothing provides libwebsockets.so.16()(64bit) needed by 
mosquitto-1.6.12-1.fc33.x86_64
 
 Correct package to report against would be mosquitto or whatever
 provides libwebsockets?

-- 
Tomasz Torcz Morality must always be based on practicality.
to...@pipebreaker.pl — Baron Vladimir Harkonnen
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Tomasz Torcz
On Mon, Sep 28, 2020 at 10:05:09AM -0500, Michael Catanzaro wrote:
> [1] https://fedoraproject.org/wiki/Changes/systemd-resolved#Split_DNS

  This link second time… there's a lot of text, but no example of
configuration file for split dns.  Is it because end user cannot easily
configure split dns permanently?

-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

2020-09-28 Thread Tomasz Torcz
On Mon, Sep 28, 2020 at 07:57:13AM -0500, Ian Pilcher wrote:
> On 9/28/20 6:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Instructions were already posted by Vitaly, so I won't repeat that here.
> > I'll just note that the scriptlet in systemd.rpm looks for
> > 'Generated by NetworkManager' in /etc/resolv.conf as an indicator that
> > the file is autogenerated.
> 
> Which is a terrible idea, as has been previously mentioned.  It really
> only indicates that the file was once touched my NetworkManager, not
> that it is currently managed.
> 
> If often let Anaconda set up a new system witha  NetworkManager-managed
> DHCP and then convert to a legacy network scripts-managed static IP
> later.  This doesn't change the DNS server or domain, so I don't bother
> editing resolv.conf to remove this comment.  I'm relatively certain that
> this is a common pattern.

  Having read your email, I've checked my /etc/resolv.conf and _removed_
the NM comment.  Never bothered to touch the comment before, as I'm using
systemd-networkd for networking on the server. I would say that leaving
the comment is a common pattern.
  There's not much there actually, only search domain and 'nameserver ::1',
where dnsmasq listens, providing split-horizon for my network and pihole
blacklisting of advertisment networks.
  But yeah, there are no better ideas how to handle resolv.conf on upgrades.

-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-11 Thread Tomasz Torcz
On Fri, Sep 11, 2020 at 10:16:02AM +0200, Mikolaj Izdebski wrote:
> You get a side tag in Koji where you can have private build-only
> dependencies that are discarded (filtered) once they are no longer
> needed, after module build is done. For build-only packages most of
> security vulnerabilities are not exploitable easily, or at all,
> therefore are low-severity, which greatly limits maintenance work
> required to address them. For example, if upstream tests are ran on an
> obsolete, 12-years old version of Tomcat, I don't need to skip tests,
> but I can package old Tomcat and run the tests.

  Whoha! Let's step back for a minute and look at this example.
What are the reasons to run tests?  To make sure the package will run
correctly..
Why run tests on 12-years old version instead of on current one?
Probably because tests fail on current version?

  Will the end user run the package on obsolete Tomcat or on the current one?
Of course on the current one. The one on which tests fail.
Tests in this case are worthless, they are not testing the real
situation. Disabling tests is no worse than testing on obsolete version.
Relying on such tests is a disservice for the end user.

  The point of testing is to validate code in real situation. 
Crafting special, unrealistic environment (12 years old Tomcat) just to have
test pass is missing the point of tests.

-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
___
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: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-10 Thread Tomasz Torcz
On Thu, Sep 10, 2020 at 04:38:04PM +0200, Mikolaj Izdebski wrote:
> > >
> > > In modular Fedora that's (effectively) not true. Packages that only exist
> > > for the sake of building other packages (i.e. build-only dependencies) 
> > > can be
> > > retained in the Fedora build system and never left it. That means those
> > > packages are never made available to Fedora users and thus a service 
> > > level for
> > > them is significantly lower. E.g. no security fixes, not bug fixes, no
> > > integration, not tests, no API/ABI stability. The only requirement is that
> > > they can be built and used for building other packages.
> >
> >
> >   So, if user wants to locally rebuild the package, they won't be able to
> > do it? Because BuildRequired packages won't be available?
> 
> Modules can be built locally with "fedpkg module-build-local", which
> downloads required dependencies from Koji and installs them in mock
> chroot. These packages are not installed directly (outsides of chroot)
> on users systems.

  OK, cool, thanks for dispeling my doubts.

-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
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: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-10 Thread Tomasz Torcz
On Thu, Sep 10, 2020 at 04:03:46PM +0200, Petr Pisar wrote:
> In non-modular Fedora all packages that we have in Fedora build system (Koji)
> are tagged into Fedora repositories and made available to all users on their
> computers for any purpose. That implies that all packages in Fedora build 
> system
> must be fully supported including addressing all security issues.
> 
> In modular Fedora that's (effectively) not true. Packages that only exist
> for the sake of building other packages (i.e. build-only dependencies) can be
> retained in the Fedora build system and never left it. That means those
> packages are never made available to Fedora users and thus a service level for
> them is significantly lower. E.g. no security fixes, not bug fixes, no
> integration, not tests, no API/ABI stability. The only requirement is that
> they can be built and used for building other packages.


  So, if user wants to locally rebuild the package, they won't be able to
do it? Because BuildRequired packages won't be available?


-- 
Tomasz Torcz“Funeral in the morning, IDE hacking
to...@pipebreaker.pl in the afternoon and evening.” - Alan Cox
___
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: About the Future of Communishift

2020-09-04 Thread Tomasz Torcz
On Fri, Sep 04, 2020 at 02:08:02PM +0200, Pierre-Yves Chibon wrote:
> 
> >   I don't really expect an answer. From my experience, it's impossible
> > to get straight, yes/no, binary answer from lawyers.
> 
> Thus the slow process :(
> The goal of the email was to inform about the current situation as we saw the
> topic raised in a few places lately.

  Of course, thank Aoife for that information!  It is much better to
have news, even unfortunate ones, than to be kept in the dark.
  This update was appreciated.


-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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: About the Future of Communishift

2020-09-04 Thread Tomasz Torcz
On Fri, Sep 04, 2020 at 07:16:02AM -0400, Neal Gompa wrote:
> On Fri, Sep 4, 2020 at 7:10 AM clime  wrote:
> >
> > On Fri, 4 Sep 2020 at 12:59, clime  wrote:
> > >
> > > On Fri, 4 Sep 2020 at 12:48, Aoife Moloney  wrote:
> > > >
> > > > However, the General Data Protection Regulation (GDPR) [3] and the 
> > > > California
> > > > Consumer Privacy Act (CCPA) [4] basically makes the Fedora 
> > > > Infrastructure team
> > > > (and thus Red Hat) responsible for the content hosted by any services 
> > > > running in
> > > > our infrastructure. In other words, the Fedora Infrastructure team 
> > > > would be
> > > > responsible to answer all GDPR/CCPA related requests and requirements 
> > > > for any
> > > > and all services running in communishift (services that the team has 0 
> > > > knowledge
> > > > about, that's the whole goal of communishift).
> >
> 
> My read of this is that right now, there will be no way for the
> community to run applications in Fedora Infrastructure in a way that
> CPE can be divorced from it completely. That is because their goal of
> running only OpenShift and then not caring about what's inside is
> legally not possible.

 
  Hmm. But how, for example, cloud providers are able to provide
infrastructure without taking responsibility for what's hosted?
I don't think GCP is handling any GPDR/CCPA requests for clients' stuff…
  I don't really expect an answer. From my experience, it's impossible
to get straight, yes/no, binary answer from lawyers.

-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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: services impact on startup times

2020-09-03 Thread Tomasz Torcz
On Thu, Sep 03, 2020 at 11:25:59AM +0100, Peter Oliver wrote:
> On Wed, 2 Sep 2020, John M. Harris Jr wrote:
> 
> > What's meant is that people are still setting up scheduled tasks by running
> > `crontab -e` and similar.
> 
> I think most such users would quickly figure out they can `yum install 
> /usr/bin/crontab`, though.

  It's even more easy/obvious on Fedora:

% crontab -e 
zsh: crontab: command not found...
Install package 'cronie' to provide command 'crontab'? [N/y] 


-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
to...@pipebreaker.pl Your routes will be aggreggated. -- Alex Yuriev
___
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-review fails with "warning: line 16: Possible unexpanded macro in: Requires .."

2020-08-28 Thread Tomasz Torcz
On Fri, Aug 28, 2020 at 02:30:20PM -, Martin Gansser wrote:
> the macro "%{vdr_apiversion}" is included in the package vdr-devel
> 
> rpm -qf /usr/lib/rpm/macros.d/macros.vdr
> vdr-devel-2.4.4-1.fc32.x86_64

  There is no such version in Fedora (is this a local build)?
Latest in F32 is vdr-2.4.1-5.fc32, and the spec has BR >= 2.4.3.

  For Rawhide, you just built vdr-2.4.4-1.fc34 yesterday – it may not be
available in Rawhide compose yet.


-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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: docker.io/library/fedora:rawhide outdated vs registry.fp.org/fedora:rawhide

2020-08-19 Thread Tomasz Torcz
On Wed, Aug 19, 2020 at 01:01:00PM +0100, Daniel P. Berrangé wrote:
> I have a docker recipe that does not much more than:
> 
>   FROM fedora:rawhide
>   RUN dnf -y install ...blah...

 I'm not addressing the core of your email, but… using FROM fedora:rawhide
is not a good practice because of two reasons:
– it's not describing specific version. 'rawhide' is changing in time,
  so your containers are not reproductible - building twice can produce
  something different each time
- you do not specify full repository address, so you get whatever is
  default. As you noticed, in different environemnts you get different
  results.

In short, 'fedora:rawhide' is not enough to get specific image, the
result is quite random.

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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: Unannounced soname bump: libreport

2020-08-14 Thread Tomasz Torcz
On Fri, Aug 14, 2020 at 11:14:59AM -0400, Neal Gompa wrote:
> On Fri, Aug 14, 2020 at 11:12 AM Fabio Valentini  wrote:
> >
> > On Fri, Aug 14, 2020 at 5:01 PM Michael Schwendt  
> > wrote:
> > >
> > > On Fri, 14 Aug 2020 16:37:28 +0200, Fabio Valentini wrote:
> > >
> > > > > As a side note, the update now has arch specific BuildRequires, so 
> > > > > the SRPM
> > > > > cannot be rebuilt on anything but .
> > > > >
> > > > > https://koschei.fedoraproject.org/package/libreport?collection=f33
> > > >
> > > > Aaaw ... stuff like this makes me sad :(
> > >
> > > What makes me sad is the poorly maintained package %changelog. Instead of
> > > summing up changes to the RPM package, it sums up changes internal to
> > > libreport. It does not list any of the spec file changes.
> > >
> > > A massive commit to the package without any %changelog entry:
> > > https://src.fedoraproject.org/rpms/libreport/c/246d3174118e03cbb345f1d434f3fbe11864b015?branch=master
> >
> > True. This is bad :( This is also the commit that added %{?_isa} to
> > BuildRequires. WHYYY
> >
> > > And later the addition of a %changelog entry that doesn't cover any of the
> > > package changes.
> >
> > It's also for the wrong version (2.13-2 instead of 2.14-2) ... which
> > was fixed in the next commit, with another Release bump. :(
> 
> As far as I know, libreport is directly synced from the
> libreport.spec.in in the libreport git repo on GitHub:
> https://github.com/abrt/libreport/blob/master/libreport.spec.in

  So %{_isa} changes would be from this:
  
https://github.com/abrt/libreport/commit/729214f13b1c036e4f9299ddcd12e9219a6ab60a

> I am unsure if ABRT folks are even reviewing stuff going on in Dist-Git...

  What do you mean by that?

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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: Duplicate package was reviewed

2020-07-31 Thread Tomasz Torcz
On Fri, Jul 31, 2020 at 12:01:53PM +0200, Michael Schwendt wrote:
> libqmatrixclient vs libquotient
> 
> Absolutely no conflict whatsoever. Different SONAME, different file/folder
> names, different package names, different project name. Even if they came
> from the same project, the old compat- naming scheme would not have applied.

  What about bringing old, possibly unmaintained library into Fedora?
It may contain unfixed security bugs.  Not that I know of any, but it's
a possibility.

-- 
Tomasz Torcz Morality must always be based on practicality.
to...@pipebreaker.pl — Baron Vladimir Harkonnen
___
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: vim has lost it's damn mind

2020-07-28 Thread Tomasz Torcz
On Sat, Jul 25, 2020 at 08:21:53AM -0500, Richard Shaw wrote:
> After upgrading to Fedora 32 I've noticed when editing files, especially
> spec files that vim does some crazy jumps/indents that it didn't do before.
> 
> Right now I'm pressing i to insert a line before a Requires: and when I hit
> enter it jumps to the next line (fine) but with 4 indents and one space...
> WTF?
> 
> Anyone else seeing strange vim behavior?

  I've noticed overzealous indent while editing yaml files. I wanted
to provide example when it turned out vim also _unindents_. This is
quite jarring.

  Example: edit a yaml file, write
#v+
some: text
#v-

  Press ENTER, cursor goes to the next line, indented 2 space. Write more:
#v+
some: text
  write
#v-

  As soon as you put “:”, whole line gets _moved back_:
#v+
some: text
write: more
#v-

  Ugh.

-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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 33 System-Wide Change proposal: systemd-resolved

2020-07-28 Thread Tomasz Torcz
On Tue, Jul 28, 2020 at 06:45:06PM -0500, Michael Catanzaro wrote:
> On Tue, Jul 28, 2020 at 4:35 pm, John M. Harris Jr 
> wrote:
> > I haven't found any systems where that's the case, though my systems
> > have been
> > upgraded all along through from ~F24. Looking at my latest install,
> > which has
> > been upgraded from F30, /etc/resolv.conf is still just a file by
> > default.
> 
> Sorry I'm wrong, it's managed by NetworkManager but *not* as a symlink. It's
> just edited in-place.

  Hmm. There are different solutions in the wild:
$ exa -l /etc/resolv.conf
lrwxrwxrwx@ 35 root 28 wrz  2019 /etc/resolv.conf -> 
/var/run/NetworkManager/resolv.conf

This is Fedora 32, initially installed a decade or so ago, and upgraded.

-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-07-10 Thread Tomasz Torcz
On Fri, Jul 10, 2020 at 07:14:09PM +0200, Vitaly Zaitsev via devel wrote:
> On 26.06.2020 16:42, Ben Cotton wrote:
> > ** transparent compression: significantly reduces write amplification,
> > improves lifespan of storage hardware
> 
> What can you say about this? https://arxiv.org/pdf/1707.08514.pdf

  Also funny note: when compression was introduced in ZFS, circa 2007,
it was mainly promoted as _performance_ win, not a space saving measure.
This was still 5 years before NVMe, so all we had was SATA, SAS and FC
drives, yet the CPUs were already multi-core and multi-gigahertz.
Transfering uncompressed data was _slower_ than compressing/decompressing
and having to transfer less data.  For a bit higher CPU usage we got
noticeable bandwidth wins.
  The tradeoff is no longer there, as single drives reach 7GiB/s
transfer speed.

-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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: The future of legacy BIOS support in Fedora.

2020-07-06 Thread Tomasz Torcz
On Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote:
> The BIOS provides block device access at sector level, so the boot
> loader has little choice but implementing drivers for all kinds of
> stuff.  Or use fragile block lists like lilo did in the last century.
> 
> With UEFI much more functionality is provided by the firmware and there
> is little reason for a bootloader to have tons of drivers.  With the
> exception of filesystem drivers in case you want boot from something !=
> vfat.  But even that should ideally be implemented as uefi driver not as
> grub2 module.

 FWIW, there seem to be UEFI driver for btrfs, ZFS, XFS and others:
 https://efi.akeo.ie/


-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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


LWN: btrfs @ Facebook (Make btrfs the default file system for desktop variants)

2020-07-03 Thread Tomasz Torcz
 Hi,

  During 2020 Open Source Summit North America, Josef shared some
details about how btrfs excels in production at Facebook.  And where
the problems were.
  I cannot find the recording, but the write up is at Linux Weekly News:

  https://lwn.net/SubscriberLink/824855/e601d11e157e1b4a/

  I highly recomend it.  Also, consider subscribing to LWN – it's an
invaluable source of high quality writing.

 
-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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: Introduce Storage Instantiation Daemon - Fedora 33 System-Wide Change proposal

2020-07-01 Thread Tomasz Torcz
On Wed, Jul 01, 2020 at 08:03:11AM -0400, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 8:00 AM Peter Rajnoha  wrote:
> >
> > On 6/30/20 9:35 PM, Igor Raits wrote:
> > > On Tue, 2020-06-30 at 15:18 -0400, Ben Cotton wrote:
> > >> https://fedoraproject.org/wiki/Changes/SID
> > >
> > >> == Summary ==
> > >> Introduce Storage Instantiation Daemon (SID) that aims to provide a
> > >> central event-driven engine to write modules for identifying specific
> > >> Linux storage devices, their dependencies, collecting information and
> > >> state tracking while
> > >> being aware of device groups forming layers and layers forming whole
> > >> stacks or simply creating custom groups of enumerated devices. SID
> > >> will provide mechanisms to retrieve and query collected information
> > >> and a possibility to bind predefined or custom triggers with actions
> > >> for each group.
> > >
> >
> 
> I'll be honest, I don't get why this exists. Most folks expect this to
> be an aspect of UDisks, so why isn't it?

  Especially after http://storaged.org/ merge few years back.

-- 
Tomasz Torcz   “(…) today's high-end is tomorrow's embedded processor.”
to...@pipebreaker.pl  — Mitchell Blank on LKML
___
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: an "old-school *nix defaults" spin [was Re: Fedora 33 System-Wide Change proposal: swap on zram]

2020-06-30 Thread Tomasz Torcz
On Mon, Jun 29, 2020 at 06:29:09PM -0700, John M. Harris Jr wrote:
> On Monday, June 29, 2020 5:04:18 PM MST Rahul Sundaram wrote:
> > Hi
> > 
> > On Mon, Jun 29, 2020 at 4:40 PM Markus Larsson wrote:
> > > Thanks, I am well aware. That wasn't really the topic here.
> > 
> > If there is a repeated feeling that anyone has that a particular edition
> > isn't what they are looking for, figuring out how to make a different set
> > of choices is and perhaps forming a community around their preferences is
> > pertinent.  This isn't addressed just to you.   Having said that, what do
> > you consider is the topic?
> 
> The possibility of the start of the Grumpy Old Neckbeard Spin (actual name 
> TBD).

  Name it Fedora Devuan.

Nb. amount of negative stop-energy you demonstrate is huge. Could you
please try to be more productive and on-topic?

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-28 Thread Tomasz Torcz
On Sun, Jun 28, 2020 at 11:15:01AM -0600, Chris Murphy wrote:
> On Sun, Jun 28, 2020 at 12:39 AM Gabriel Ramirez  wrote:
> >
> > On 6/27/20 11:09 PM, Chris Murphy wrote:
> > > On Sat, Jun 27, 2020 at 9:25 PM Gabriel Ramirez  
> > > wrote:
> > >> On 6/27/20 9:06 PM, Chris Murphy wrote:
> > >>>
> > >>> Just a PSA: btrfs raid1 does not have a concept of automatic degraded
> > >>> mount in the face of a device failure. By default systemd will not
> > >>> even attempt to mount it if devices are missing. And it's not advised
> > >>> to use 'degraded' mount option in fstab. If you do need to mount
> > >>> degraded and later the missing device is found (?) you need to scrub
> > >>> to catch up the formerly missing device to the current state.
> > >>>
> > >> That seems a step back,
> > > Yes. You do gain self-healing and unambiguous scrubs, which apply only
> > > to the used portion of the drives. Three steps forward half step back?
> > > The priority would be to replace the failing/failed drive before a
> > > reboot. Yes, the use case where the drive dies on startup and
> > > unattended boot is needed is weaker.
> >
> > yeah, but coming from mdadm, I (will be)/(was) expecting the same or
> > better from a new filesystem, or documentation to resolve the situation
> > "shutdown, replace the disk, boot with another media etc..."
> >
> > because when the problem happens, googling sometimes fails too
> 
> Some distros have /usr/lib/udev/rules.d/64-btrfs.rules and others don't.
> 
> The behavior now, with that rule, udev waits for all btrfs devices to
> be present. And I think it's an indefinite wait. Is it a bug in the
> rule or is it a feature request? I don't know. But, I think at the
> least we'd want a timer to get to a dracut shell eventually.
> 
> At that shell, you can e.g.
> mount -o degraded /dev/vda1 /sysroot
> exit
> 
> And the startup will proceed normally the rest of the way and you can
> do a device replacement.
> 
> A better udev rule might be one that waits for all devices, and then
> if there are still missing devices at say 90s is able to add
> 'degraded' to the initial mount attempt. That might mostly fix this.
> But I don't know if sd-udev can conditionally add (insert) mount
> options or if it could learn to do so. There is still some very small
> window of risk for a "split brain" type problem - if different devices
> get mount degraded on subsequent boots - but fixing/hardening against
> that requires kernel work.

  Nb. this is how mdadm works - assembly starts a timer from udev rule.
If the timer passes but not all devices are present, the array is
started in degraded mode:
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/udev-md-raid-assembly.rules
https://git.kernel.org/pub/scm/utils/mdadm/mdadm.git/tree/systemd

  This is a bit hackish, as there is a hardcoded amount of seconds system
will wait for all devices.
  Also, this scheme was created by mdadm maintainer. He can be trusted
to be knowledgable enough about md. Btrfs assembly rules, on the other
hand, are maintained in systemd.  Systemd developers are not btrfs
experts, so they are cautious and quite conservative.
degraded-assembly-after-timeout should be shipped in btrfs-progs, and
maintained by people who are btrfs experts.


-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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: User experience issue on btrfs

2020-06-28 Thread Tomasz Torcz
On Sun, Jun 28, 2020 at 09:20:32AM -0500, Michael Catanzaro wrote:
> On Sun, Jun 28, 2020 at 4:11 pm, Fabio Valentini 
> wrote:
> > Maybe libvirt / gnome-boxes / virt-manager should do that by default if
> > it detects that the backing storage for an allocated VM image is on
> > btrfs (if it doesn't do that already)?
> 
> Yeah that's the plan: https://gitlab.gnome.org/GNOME/gnome-boxes/-/issues/88

  But disabling CoW (and checksumming, which is implied by nocow)
removes important reliability features from btrfs.  It's a trade off
which should be clear to the user.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Tomasz Torcz
On Sat, Jun 27, 2020 at 10:59:57AM +0200, Nicolas Mailhot via devel wrote:
> Le samedi 27 juin 2020 à 10:47 +0200, Igor Raits a écrit :
> > 
> > Do you run postgres, financial transactions and random blackouts on
> > your laptop / workstation? If so, isn't it just for testing purposes?
> 
> Wokstations are full of high-value personnal data, because home users
> do not have an IT organisation to back it up in a professional way.

  That's why hav my personal, valuable and irreplacable data (photos, contracts,
etc.) on btrfs raid1. I do backups regularly, but only btrfs is able to
catch and correct silent corruptions. Which do happen.
  Without btrfs, I could be happily backing up corrupted photos.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-27 Thread Tomasz Torcz
On Fri, Jun 26, 2020 at 05:49:03PM -0600, Chris Murphy wrote:
> 
> > For what it's worth, this is really needed, and overdue.  I have
> > repeatedly failed Fedora OS release upgrades on different machines by
> > running out of root fs space. I think the default / is around 50GB, and
> > it's too easy to fill: during OS update we need space for three copies
> > of each package: the old version, the downloaded new version, and the
> > space to install the new version.
> 
> 75G on new installs today but yes there are many folks still with a
> 50G root volume at /
> 
> And changing this to 80+G is sorta 'kick the can' but also as it turns
> out it doesn't really fix the problem that well and puts pressure on
> /home in cases where the laptop drive is kinda small. There are other
> valid ways to solve this single problem, e.g. a single plain ext4 or
> xfs volume. But both of those leave things on the table users benefit
> from.

  We cannot do anything for existing installs. It is up to owner to
juggle partitions.
  Also, with btrfs proposal we do not have to decide how to split space
between / and /home.  Boths are just a subvolumes and share all the
space.


-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-26 Thread Tomasz Torcz
On Fri, Jun 26, 2020 at 10:42:25AM -0400, Ben Cotton wrote:
>  Boot on Btrfs 
> 
> * Instead of a 1G ext4 boot, create a 1G Btrfs boot.
> * Advantage: Makes it possible to include in a snapshot and rollback
> regime. GRUB has stable support for Btrfs for 10+ years.

  GRUB2 btrfs support tend to lag a bit.  User would need to be careful
not to enable some btrfs features before GRUB2 supports them.

> * Scope: Contingent on bootloader and installer team review and
> approval. blivet should use mkfs.btrfs --mixed.

  When going with btrfs /boot, you can forego separate partition and
just make a /boot subvolume in main pool.

Advantage: fewer partitions.

Disadvantages: using encryption is harder. GRUB2 supports only LUKS1
encryption (AFAIK). Obviously, there is not plymouth integration, so the
password would have to be entered at least twice.
When not using encryption above is not a problem.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

2020-06-26 Thread Tomasz Torcz
On Fri, Jun 26, 2020 at 04:58:19PM +0200, Vitaly Zaitsev via devel wrote:
> On 26.06.2020 16:42, Ben Cotton wrote:
> > For laptop and workstation installs of Fedora, we want to provide file
> > system features to users in a transparent fashion. We want to add new
> > features, while reducing the amount of expertise needed to deal with
> > situations like [https://pagure.io/fedora-workstation/issue/152
> > running out of disk space.] Btrfs is well adapted to this role by
> > design philosophy, let's make it the default.
> 
> I'm strongly against this proposal. BTRFS is the most unstable file
> system I ever seen. It can break up even under an ideal conditions and
> lead to a complete data loss. There are lots of complaints and bug
> reports in Linux kernel bugzilla and Reddit.

  Anecdata…
  OTOH, I'm using btrfs on most of my machines. I had one data loss,
when RAM module went bad and caused corruption in bcache attached
to my btrfs /.  It was neither fault of bcache nor btrfs.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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 33 System-Wide Change proposal: Make nano the default editor

2020-06-26 Thread Tomasz Torcz
On Fri, Jun 26, 2020 at 12:27:39PM +0100, Jonathan Wakely wrote:
> On 26/06/20 10:19 +0200, Jan Kratochvil wrote:
> > On Fri, 26 Jun 2020 09:57:49 +0200, Samuel Sieb wrote:
> > > The dnf one works fine.
> > 
> > It does not as I have shown. Moreover it takes so much time to do dnf 
> > command
> > completion and one always has to ctrl-c it anyway. That is because dnf 
> > should
> > use cached results updated by cron and do not contact network during
> > interactive cache queries. If one really wants most fresh data there is
> > --refresh for that.
> 
> That sounds like a good idea, and could be filed as a bug against
> dnf. I'd prefer if it's optional though, because for me 'sudo dnf
> install foo' only takes seven seconds, not minutes, and
> that seems reasonable to me.


  Seven seconds sounds like a horrible user experience. I would lose
patience and start hitting ^C after around 3s.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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: Bodhi too eager to push updates to stable?

2020-06-26 Thread Tomasz Torcz
On Thu, Jun 25, 2020 at 11:21:57AM -0700, Adam Williamson wrote:
> On Thu, 2020-06-25 at 20:18 +0200, Tomasz Torcz wrote:
> > On Thu, Jun 25, 2020 at 06:10:23PM -, Artur Iwicki wrote:
> > > Isn't this how bodhi always worked? One week (two weeks for EPEL) and
> > > if doesn't get negative karma, it gets pushed - no matter if it's an
> > > enhancement, or a bugfix, or a security update.
> > 
> >   I don't think so. I remember my updates sitting in testing for weeks.
> > Not that I find it worrisome. If my package is so niche that no one tests
> > it, then no one will be impacted if the update is now or month later.
> 
> It hasn't "always" been like this, it was added I think two or three
> years back, in response to one of the periodic long arguments about
> whether the rules and defaults are too strict or not strict enough.

  Thanks for all the explanations, it's clear to me now.

  For the record, this feature was added a year ago:
  https://pagure.io/fesco/issue/2048
  https://github.com/fedora-infra/bodhi/pull/3090


-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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 33 System-Wide Change proposal: Make nano the default editor

2020-06-25 Thread Tomasz Torcz
On Thu, Jun 25, 2020 at 01:34:33PM -0600, Chris Murphy wrote:
> On Thu, Jun 25, 2020 at 12:50 PM Jan Kratochvil
>  wrote:
> >
> > On Thu, 25 Jun 2020 19:18:59 +0200, Ben Cotton wrote:
> > > In contrast, Nano offers the kind of graphical text editing experience
> > > that people are used to,
> >
> > This is another step trying to make Fedora end-user friendly while the only
> > effect is making it hostile to developers.
> 
> This is hyperbole. All of the working group members are developers and
> the change was approved +9 to -1. The idea the vast majority of the
> working group wants to make Fedora hostile to themselves is nonsense.

  They are not true Scotsmen^Wdevelopers.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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: Bodhi too eager to push updates to stable?

2020-06-25 Thread Tomasz Torcz
On Thu, Jun 25, 2020 at 06:10:23PM -, Artur Iwicki wrote:
> Isn't this how bodhi always worked? One week (two weeks for EPEL) and
> if doesn't get negative karma, it gets pushed - no matter if it's an
> enhancement, or a bugfix, or a security update.

  I don't think so. I remember my updates sitting in testing for weeks.
Not that I find it worrisome. If my package is so niche that no one tests
it, then no one will be impacted if the update is now or month later.

> When creating an update from the web panel, you can un-check the
> "Auto-request stable based on time?" box to disable this. When doing
> this from the command-line... hm, I don't see any field in the
> template that'd allow to change this. Time to file a feature request?

  I'm only using “fedpkg update” and there is no time based option in
template.

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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


Bodhi too eager to push updates to stable?

2020-06-25 Thread Tomasz Torcz
Hi,

  I'm really surprised by Bodhi behaviour with this update:
  https://bodhi.fedoraproject.org/updates/FEDORA-2020-6010469bfb
 (ladvd-1.1.2-7.fc32, Fix SELinux AVC denials)

  I've set Stable Karma to +3.  Update was pushed to testing,
gathered exactly zero reviews with +/- karma. After a week,
with 0 karma, update was pushed to stable.
  Should it work that way?

-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
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: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

2020-06-16 Thread Tomasz Torcz
On Tue, Jun 16, 2020 at 03:23:10PM +0200, Zdenek Dohnal wrote:
> And please don't try to reinstall plugin. It seems they haven't built a
> new one yet or they aren't planning to.
> 
> See http://www.openprinting.org/download/printdriver/auxfiles/HP/plugins/

  Here it is:
  https://developers.hp.com/hp-linux-imaging-and-printing/plugins


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: New HPLIP release 3.20.6 doesn't require plugin for printers whose needed plugin in the past

2020-06-16 Thread Tomasz Torcz
On Tue, Jun 16, 2020 at 03:01:22PM +0200, Zdenek Dohnal wrote:
> Hi all,
> 
> I'm HPLIP maintainer in Fedora and I would like to ask *the users which
> have HP printers which needed their HP plugin to test the scratch build*
> of new hplip.
> 
> HPLIP released a new version 3.20.6, where most models, which previously
> required HP plugin, were set to do not require plugin anymore.

  Is there a list of printers not requiring plugin anymore?
  Downloading this plugin was the most cumbersome.  In line with
Murphys's laws, I was noticing hplip was upgraded, and thus requiring
re-downloading plugin, when I had to print/scan something urgently.


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: systemctl status distccd

2020-06-16 Thread Tomasz Torcz
On Tue, Jun 16, 2020 at 01:59:48PM +0200, Michael J. Baars wrote:
> Hi,
> 
> Since it's awfully quiet on the initscripts-devel mailing list.

  But why this email?  The log you presented shows:

a) distccd not starting because of configuration error (configured to
listen on non-existing 192.168.0.2 address)

b) distccd service running (listening on different address)

  Do you mean that you configured distccd to start after
network-online.target and it did not start after .2 is available?
Well, first you need also Wants=network-online.target, second you need
something providing this target (like NetworkManager-wait-online.service).

  Anyway, this isall guesswork, why have you posted to -devel list?


> [root@tp02 ~]# systemctl status distccd
> ● distccd.service - Distccd A Distributed Compilation Server

> Jun 16 09:35:00 tp02.localdomain distccd[741]: (dcc_listen_by_addr) ERROR: 
> bind of 192.168.0.2:3632 failed: Cannot assign requested address
> 

> [root@tp02 mjbaars1977]# systemctl status distccd
> ● distccd.service - Distccd A Distributed Compilation Server
>  ├─ 945 /usr/bin/distccd --no-detach --daemon 
> --whitelist=/etc/distcc/clients.allow --jobs 4 --listen 192.168.0.3 --allow 
> 192.168.0.0/4


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: New protobuf blocked by old protobuf from module [f32]

2020-06-15 Thread Tomasz Torcz
On Mon, Jun 15, 2020 at 12:43:37PM +0200, Igor Raits wrote:
> >   - package protobuf-3.11.2-2.fc32.i686 is filtered out by modular
> > filtering
> >   - package protobuf-3.11.2-2.fc32.x86_64 is filtered out by modular
> > filtering
> > 
> > What is the right way to fix this ?  dnf module list shows me loads
> > of
> > modules, but I'm not seing how to determine which of them are enabled
> > vs
> > disabled, and more importantly which is providing this bogus outdated
> > protobuf ?
> 
> dnf module reset eclipse

  Could you please explain the steps how to arrive to this "magic"
invocation?

-- 
Tomasz Torcz “God, root, what's the difference?”
to...@pipebreaker.pl   “God is more forgiving.”
___
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: swap-on-ZRAM by default

2020-06-09 Thread Tomasz Torcz
On Tue, Jun 09, 2020 at 02:18:06PM -0700, Samuel Sieb wrote:
> On 6/9/20 1:57 PM, Dridi Boukelmoune wrote:
> > On Tue, Jun 9, 2020 at 5:43 PM Samuel Sieb  wrote:
> > > 
> > > On 6/9/20 6:49 AM, Dridi Boukelmoune wrote:
> > > > > Well, that's really the point. The one you're using is one of the (4? 
> > > > > 5?)
> > > > > other zram implementations. It seems a bit more straightforward than 
> > > > > the
> > > > > systemd one for sure.
> > > > 
> > > > The zram-generator is probably more straightforward (with literally
> > > > less layers of indirection) than what the zram package provides. I
> > > > would assume that a generator is also the more idiomatic (and
> > > > efficient) solution as far as systemd is concerned and I wouldn't mind
> > > > migrating to that if it looked feature-complete and had decent
> > > > documentation. There is no manual page[1], only a slightly confusing
> > > > README that hints at simplicity and incompleteness.
> > > 
> > > There's also an example conf file included that has a lot of explanation
> > > in it.
> > 
> > I'm aware, but the explanation doesn't tell me anything I couldn't
> > infer from the README.
> 
> Ok, but I don't understand what other documentation there could possibly be.
> There are only two options to configure and they're both well explained.

  That's the problem right here. There are more options.
compression-algorithm, max-zram-size. You need to read source to know
about them.
  Description of general mechanism is also lacking. The generator
creates a service: swap-create@.service, which calls modprobe and
mkswap. There is also a .swap unit created and enabled. Have you found
those details in documentation?

  And there's also this:
# /usr/lib/systemd/system-generators/zram-generator
This program requires 1 or 3 arguments

  Can you guess what the arguments are, without checking source?

  Documenting this is not much work, I guess couple of hours. It will
have to be done before shipping (if Change is accepted) but it's lacking
now.

-- 
Tomasz Torcz “God, root, what's the difference?”
to...@pipebreaker.pl   “God is more forgiving.”
___
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 33 System-Wide Change proposal: swap on zram

2020-06-08 Thread Tomasz Torcz
On Mon, Jun 08, 2020 at 10:58:12AM +0100, Richard W.M. Jones wrote:
> On Sun, Jun 07, 2020 at 05:25:15PM -0600, Chris Murphy wrote:
> > On Sun, Jun 7, 2020 at 2:48 PM David Kaufmann  wrote:
> > >
> > > On Sat, Jun 06, 2020 at 05:36:15PM -0600, Chris Murphy wrote:
> > > > To me this sounds like too much dependency on swap.
> > >
> > > That's not what I meant, I wanted to emphasize the different values of
> > > disk storage vs. RAM. As said in another email it doesn't matter at all
> > > if there is 0% or 90% of disk swap usage, while RAM usage can be quite
> > > essential. (This is in case swapped out stuff stays swapped out.)
> > 
> > Inactive pages that are evicted long term, is a workload that I think
> > would benefit from zswap instead. In that case you get the benefit of
> > the memory cache for recently used anonymous pages that would
> > otherwise result in "swap thrashing" and the "least recently used"
> > pages are moved to disk based swap.
> 
> Is this how it works?  Previously it was stated that once a page is
> swapped to a particular swap device, that's it.  It would be nice if a
> page which has been sitting in zram for a while could be swapped out
> to the slower / cheaper / larger disk.

  It seems possible:
  
https://www.kernel.org/doc/html/latest/admin-guide/blockdev/zram.html#writeback

-- 
Tomasz Torcz “God, root, what's the difference?”
to...@pipebreaker.pl   “God is more forgiving.”
___
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: Is there an official Fedora for WSL?

2020-06-07 Thread Tomasz Torcz
On Sat, Jun 06, 2020 at 07:15:57PM -0700, Gordon Messmer wrote:
> It's not click and run by any means, but it's feasible.
> 
> The bad news, though, is that current versions of rpm (and dnf) won't work
> under WSL if you're on a Windows version older than 2004, so you might be
> stuck with CentOS 7 if you're on an employer-managed laptop that is still
> running an older release of Windows (as I am, during the work day):
> https://github.com/Microsoft/WSL/issues/3939

  This bug manifests with BerkeleyDB. As we just moved off it,
and we are using SQLite for RPM database, current versions of
rpm and dnf should be fine.

-- 
Tomasz Torcz “God, root, what's the difference?”
to...@pipebreaker.pl   “God is more forgiving.”
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: [HEADS UP] F33 Boost 1.73.0 rebuilds starting in a side tag

2020-06-02 Thread Tomasz Torcz
On Tue, Jun 02, 2020 at 03:24:24PM +0100, Jonathan Wakely wrote:
> On 02/06/20 07:54 -0400, Kaleb Keithley wrote:
> > Is the rebuild in the side tag something that's still in progress?
> > 
> > I sent Jonathan an email asking, but didn't get a reply.
> 
> Sorry, I didn't see the mail until today.
> 
> https://fedoraproject.org/wiki/Changes/F33Boost173#Scope links to the
> ticket for the side tag, which is https://pagure.io/releng/issue/9474
> and that makes it clear the tag is still active.
> 
> 
> > I've built a new release of ceph (ceph-15.2.3) in the f33-boost side tag
> > but if this is something that's on hold I'll need to build it for f33.
> 
> Thanks.
> 
> ceph was not in my list, because it isn't returned by the first query
> shown at https://fedoraproject.org/wiki/Changes/F33Boost173#Dependencies
> 
> Does it actually depend on any libboost_*.so libraries, or just use
> the header-only libraries? If it only uses the header-only parts it
> doesn't necessarily need to be rebuilt (there won't be broken deps
> when the previous boost release gets replaced in the rawhide repo,
> although it's possible that other things that link to ceph or that
> ceph links to will have been rebuilt, which can cause problems).
> 
> Hmm, I do see this in ceph.spec:
> 
> BuildRequires:boost-devel
> BuildRequires:boost-random
> 
> But the repoquery doesn't say it needs them.

  Thats interesting, as boost is in RPM requires.
For example ceph-common-2:15.2.3-1.fc33.aarch64.rpm
(https://koji.fedoraproject.org/koji/rpminfo?rpmID=21717030) has:

libboost_context.so.1.73.0()(64bit)
libboost_program_options.so.1.73.0()(64bit)
libboost_thread.so.1.73.0()(64bit)



-- 
Tomasz Torcz  “If you try to upissue this patchset I shall be 
seeking
to...@pipebreaker.pl   an IP-routable hand grenade.”  — Andrew Morton (LKML)
___
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: F30 security update submitted for stable "marked obsolete" instead of being pushed

2020-05-27 Thread Tomasz Torcz
On Wed, May 27, 2020 at 09:39:47AM -0500, Richard Shaw wrote:
> > Yeah, I think that'd be better then simply dropping them, if it's
> > reasonably easy to implement. By releasing those updates we make
> > things a bit nicer for users who are staying on a
> > now-slightly-but-as-time-goes-on-more-and-more-so out-of-date release,
> > and we'd be conserving the work of our packagers. But if it would be a
> > major hassle for infra or releng, then meh.
> >
> 
> I think a phased approach would be (hopefully) easy to implement.
> 
> 1. Stop builds at 
> 2. Stop submitting updates on +1 week

 2½. Push to stable all updates with non-negative karma at +2 weeks?

> 3. Stop allowing pushes to stable on +2 weeks.


-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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: The price of FHS

2020-05-23 Thread Tomasz Torcz
On Sat, May 23, 2020 at 01:01:04PM +0200, Vít Ondruch wrote:
> It would be possible to install individual RPMs into paths such as:
> 
> ~~~
> 
> /pkgs/programA_version1
> /pkgs/libX_version1 contains
> 
> ~~~
> 
> but I wonder how would you imagine the glue above this structure to make
> the programA_version1 to use the libX_version1?

  No need to "imagine" anything. Nix works that way:
  https://lwn.net/Articles/337677/

  The answer lies in symlinks. 


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: [External] Re: Fedora+Lenovo

2020-05-01 Thread Tomasz Torcz
On Fri, May 01, 2020 at 03:10:39AM +, Mark Pearson wrote:
> Hi Tomasz,
> 
> > From: Tomasz Torcz 
> > Sent: Thursday, April 30, 2020 5:33 PM
> > 
> >   Hi, welcome among regular folks ;)
> > 
> >   I was wondering, will Lenovo work to make older models fully
> > supported, too?  I'm looking at fingeprint reader on my T480s…
> 
> 
> I'd have to check what device is on the T480s (I don't have one myself).
> We have support from Synaptics for their 'Prometheus' device - if you do 
> lsusb and confirm if its 06cb:00bd that will let you know.

  Unfortunately it's different model:
Bus 001 Device 007: ID 06cb:009a Synaptics, Inc. 


-- 
Tomasz TorczOnce you've read the dictionary,
to...@pipebreaker.plevery other book is just a remix.
___
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+Lenovo

2020-04-30 Thread Tomasz Torcz
On Thu, Apr 30, 2020 at 09:18:10PM +, Mark Pearson wrote:
> Hi all,
> 
> Adam Williamson suggested I stick a note in the mailing list saying
> “hi” - so I’ve achieved that and officially upgraded myself from
> lurker! He also suggested I take questions from the community - and
> I’m very happy to do that.  So - if there are any questions from
> Fedora developers on the Lenovo announcement let me know and I will
> answer them as best I can….if I don’t know the answer I’ll do the try
> to find out.

  Hi, welcome among regular folks ;)

  I was wondering, will Lenovo work to make older models fully
supported, too?  I'm looking at fingeprint reader on my T480s…


-- 
Tomasz TorczOnce you've read the dictionary,
to...@pipebreaker.plevery other book is just a remix.
___
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: f32-backgrounds look like crap

2020-04-17 Thread Tomasz Torcz
On Fri, Apr 17, 2020 at 04:47:54PM +0200, Christopher Engelhard wrote:
> On 17.04.20 16:07, Kamil Paral wrote:
> > Especially the one in Fedora 15 (GNOME edition) and 16 was outstanding.
> > Can we do more of those, please?
> 
> Not weighing in on the merits of the current art, but 16 is still my
> favourite default artwork of any distro, ever.

  Nooo, 26 was a real piece of art! ;)
  A refresher:
  https://fedoraproject.org/wiki/Wallpapers


-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
___
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 33 System-Wide Change proposal: systemd-resolved

2020-04-16 Thread Tomasz Torcz
On Thu, Apr 16, 2020 at 07:41:07AM -0700, John M. Harris Jr wrote:
> 
> Really, it may be best to go about this in the same way as Ubuntu, with nss-
> dns instead of nss-resolve.. Editing /etc/resolv.conf is still commonly done 
> on Fedora, especially on servers. In fact, I never knew that NetworkManager 
> would clobber that until this thread. If this isn't mean to wreck everyone's 
> systems, backwards compatibility is key.

 Relying on nss_dns causes bugs like
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320
(systemd-resolved appends 127.0.0.53 to resolv.conf alongside existing
entries).
 It still gets (angry) comments, years after it was filled.

-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
___
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: Urgently downgrade xorg-x11-drv-intel

2020-04-06 Thread Tomasz Torcz
On Mon, Apr 06, 2020 at 10:40:59AM -0400, Paul Dufresne via devel wrote:
> Le 20-04-06 à 10 h 04, Tomasz Torcz a écrit :
> > On Mon, Apr 06, 2020 at 09:27:58AM -0400, Alexei Podtelezhnikov wrote:
> >Are they? We stopped using intel driver around F26, we use
> > modesetting for Intel GPUs now.  The above is clearly non-default
> > configuratiob.
> 
> I am far from an expert on the subject, but I am pretty sure we did not stop
> using intel driver when we use kernel mode setting. We just ask for the
> kernel to do the change of video mode, but the intel driver still does the
> drawing on display.
> 
> Here on my i3-8100 computer, using as far as I know the graphics pipeline on
> the CPU itself ( Mesa Intel® UHD Graphics 630 (CFL GT2) ) I have:
> 
> [paul@localhost ~]$ lsmod | grep i915
> i915 2617344  18
> i2c_algo_bit   16384  1 i915
> cec    61440  1 i915
> drm_kms_helper    245760  1 i915
> drm   655360  7 drm_kms_helper,i915
> video  53248  2 asus_wmi,i915

  Yes, that's the kernel side part. But in userland,
we are NOT using xorg-x11-drv-intel for intel gen4 and up
(if I understand
https://src.fedoraproject.org/rpms/xorg-x11-server/blob/HEAD/f/06_use-intel-only-on-pre-gen4.diff
 
correctly). Gen4 was released in 2006:
https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Gen4

  Additionally, Xorg is also non-default, we use Wayland since some
  time.

  (of course I may be terribly confused by all of this, it would be good
  for someone familiar with out graphic stack to correct me).

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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: Urgently downgrade xorg-x11-drv-intel

2020-04-06 Thread Tomasz Torcz
On Mon, Apr 06, 2020 at 09:27:58AM -0400, Alexei Podtelezhnikov wrote:
> Hi All,
> 
> Please urgently downgrade xorg-x11-drv-intel before shipping Fedora 32 and
> spare users some pain. At least two very recent crash/segfault reports are
> fixed by downgrading to the fc31 version of xorg-x11-drv-intel.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1820815
> https://bugzilla.redhat.com/show_bug.cgi?id=1818972
> 
> Perhaps other very recent intel_drv.so crashes are also related but the
> maintainer is not responding.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1808767
> https://bugzilla.redhat.com/show_bug.cgi?id=1775929
> 
> These are showstopper candidates IMHO.

  Are they? We stopped using intel driver around F26, we use
modesetting for Intel GPUs now.  The above is clearly non-default
configuratiob.

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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: CPE Git Forge Decision

2020-03-31 Thread Tomasz Torcz
On Tue, Mar 31, 2020 at 11:34:35AM -0700, Adam Williamson wrote:
> On Tue, 2020-03-31 at 12:55 +0200, Tomasz Torcz wrote:
> > > 
> > > What really worries to me is that:
> > > * using GitLab as SaaS is being considered, and
> > > * for self-hosting, using the proprietary "enterprise" editions is not
> > >   excluded.
> > > 
> > > I think that using anything other than Free Software as the hosting 
> > > platform 
> > > for Fedora should be an absolute no go. In other words, self-hosted 
> > > GitLab 
> > > CE or Pagure, no other options.
> > 
> >   Being self-hosted is a nice goal, but not important enough.
> > There are parts of Fedora infrastructure which are not using Fedora,
> > but other distributions like RHEL.  We seem to have not problem in
> > using proprietary SAAS solutions for critical stuff.
> 
> What 'proprietary SAAS solutions' are we 'using for critical stuff'?

  GitLab Ultimate editon for managing source code of distribution.
We are not using it yet, but it looks very plausible that we will in the
future.


> Bruno explained the RHEL point. To his explanation I'd add, don't
> forget that EPEL is part of Fedora - in fact it's the most widely-used
> thing the Fedora project produces. And we use a lot of EPEL packages on
> the infra systems we (still) have running RHEL and/or CentOS. So this
> is also an important element of dogfooding.

  Personally I'd prefer people wanting to use Fedora packages just
to use Fedora distribution.


-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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: CPE Git Forge Decision

2020-03-31 Thread Tomasz Torcz
On Tue, Mar 31, 2020 at 12:42:18PM +0200, Kevin Kofler wrote:
> Leigh Griffin wrote:
> > Thank you for your patience while the CPE Team worked through an
> > incredible number of requirements from multiple stakeholder sources. On
> > Friday evening we announced on the Community Blog
> > <https://communityblog.fedoraproject.org/making-a-git-forge-decision/> our
> > decision to adopt Gitlab as our Git Forge and to retain pagure.io to
> > ultimately hand over to the Community to maintain. It wasn't an easy
> > decision by any stretch of the imagination and we hope that the compromise
> > that we are striking will help to allow Pagure flourish and to give a
> > choice of Forges for your usage. I'm happy to field any questions or
> > comments about this decision.
> 
> What really worries to me is that:
> * using GitLab as SaaS is being considered, and
> * for self-hosting, using the proprietary "enterprise" editions is not
>   excluded.
> 
> I think that using anything other than Free Software as the hosting platform 
> for Fedora should be an absolute no go. In other words, self-hosted GitLab 
> CE or Pagure, no other options.

  Being self-hosted is a nice goal, but not important enough.
There are parts of Fedora infrastructure which are not using Fedora,
but other distributions like RHEL.  We seem to have not problem in
using proprietary SAAS solutions for critical stuff.
  I truly envy Debian and their ability to dogfood, running their
infra on Debian. With minor exception: although they self-host GitLab,
it seems to be different than their distribution packages.


-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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 33 System-Wide Change proposal: Sqlite RpmDB

2020-03-26 Thread Tomasz Torcz
On Thu, Mar 26, 2020 at 02:08:57PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Mar 26, 2020 at 03:29:50PM +0200, Panu Matilainen wrote:
> > No, rpm doesn't use many Linux-specific calls and this is no
> > exception. In fact it doesn't use any of the *at() family calls
> > directly either.
> 
> But why?! It's not like rpm is massive on Windows Server... Isn't
> good support for Linux absolutely the most important thing?

  Well, RPM is a package manager on AIX.  IBM/Redhat may want
to keep AIX alive ;-)

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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: RFC: entering luks password on grub level for devices without keyboards

2020-03-16 Thread Tomasz Torcz
On Sun, Mar 15, 2020 at 11:12:43PM +0100, Marius Schwarz wrote:
> Am 15.03.20 um 13:32 schrieb Vitaly Zaitsev via devel:
> > On 14.03.2020 13:05, Marius Schwarz wrote:
> >> If you encrypt  the fedora ( or any ) installation with luks, as
> >> security of a mobile device indicates, you end up without the
> >> possibility to enter the password, when you do not have an in/external
> >> keyboard at hand.
> > You should use TPM 2.0 LUKS unlock instead of using passwords.
> >
> I  knew someone would bring this up:  TMP does not protect your drive,
> as you could boot with "init=/bin/bash 1" . 

   How do you do that WITHOUT KEYBOARD?  This thread is about very
 specific situation, please do not forget that when generalising.

-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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: libIDL missing on F32

2020-03-10 Thread Tomasz Torcz
On Tue, Mar 10, 2020 at 07:16:54PM +0100, Antonio Trande wrote:
> Hi all.
> 
> libIDL missing on F32. Please, fix it.

  It's been unretired, will become available soon:
  https://pagure.io/releng/issue/9305

-- 
Tomasz Torcz   “Never underestimate the bandwidth of a station
to...@pipebreaker.plwagon filled with backup tapes.”  — Jim Gray
___
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: Want to claim vault

2020-02-25 Thread Tomasz Torcz
On Mon, Feb 24, 2020 at 10:12:41PM +, Dave Dykstra wrote:
> I made a ticket (bug #1806737) for the maintainer of the existing vault
> package in Fedora to see if he'd be willing to give it up so it can be
> used for Hashicorp vault (https://vaultproject.io) and he decided to
> mark it EOL so I could claim it.

  We already have some HashiCorp software packages (dnf search hashicorp),
maybe you can reuse some ideas.

-- 
Tomasz TorczOnly gods can safely risk perfection,
to...@pipebreaker.pl it's a dangerous thing for a man.  — Alia
___
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: List of long term FTBFS packages to be retired in February

2020-01-15 Thread Tomasz Torcz
On Mon, Jan 06, 2020 at 11:44:31AM +, Peter Robinson wrote:
> 
> > Also said in the e-mail, if you think those packages need to be exempted 
> > from
> > the process, we can deal with that to, however there must be a valid 
> > reason. I
> > don't think "the maintainer didn't actually maintain their Fedora packages 
> > for
> > almost 2 years because they have real stuff to do" is a valid reason, yet 
> > other
> > FESCo members might disagree with that statement.
> 
> Well the FTB from people pushing builds would be directly due to the
> fact they're not on the ACL for the secure-boot, there is a handful of
> packages like that.
> 
> Well FESCo might agree that they want booting x86 images with
> secure-boot so ¯\_(ツ)_/¯

  We (Fedora) may want to have secure boot, yet we don't have maintainer
with enough spare time for it.  Let's be adults and forgo secure boot.

-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
___
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: lv2-sorcer is not installable

2020-01-03 Thread Tomasz Torcz
On Fri, Jan 03, 2020 at 08:36:45AM -0500, Code Zombie wrote:
> Hi
> 
> lv2-sorcer cannot be installed on Fedora 31. Seems like the libntk lib
> needed by the package is not provided by any packages. The full
> installation error is as follows:

  Looks like non-ntk library failed to build for last few releases:
  https://koji.fedoraproject.org/koji/packageinfo?packageID=16952

  It was removed from distribution (retired):
  https://bugzilla.redhat.com/show_bug.cgi?id=1675550

-- 
Tomasz Torcz Morality must always be based on practicality.
to...@pipebreaker.pl — Baron Vladimir Harkonnen
___
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: updates not getting pushed for the last several days

2019-12-31 Thread Tomasz Torcz
On Tue, Dec 31, 2019 at 10:52:58AM +0100, Julian Sikorski wrote:
> Hi list,
> 
> it appears that the updates have not been pushed for the last several days:
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-986a024b8e
> https://bodhi.fedoraproject.org/updates/FEDORA-2019-e98d4e55e6
> If I recall correctly, there have been changes made some time ago after
> which the updates should automatically get pushed every midnight. Is the
> lack of pushes a known problem?

  Yes, it is known.  It's noted on https://status.fedoraproject.org/
and in previous messages to this list (Message-ID:
).

-- 
Tomasz TorczTo co nierealne – tutaj jest normalne.
to...@pipebreaker.pl  Ziomale na życie mają tu patenty specjalne.
___
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 32 System-Wide Change proposal: Enable fstrim.timer by default

2019-12-20 Thread Tomasz Torcz
On Thu, Dec 19, 2019 at 11:59:54PM -0700, Chris Murphy wrote:
> > After the initial change of defaults, the fstrim.timer SHOULD NOT be
> > re-enabled on subsequent updates if a user (who like me prefers choosing
> > when to run fstrim on which filesystem) has disabled it.
> 
> It's an interesting question. I'm not sure what the upgrade policy is
> for vendor presets. Because there's a general expectation of getting
> new features upon upgrade, without having to do a clean install, I
> think this one should be enabled on upgrades. But I'm not sure how to
> make sure F32>F33 upgrade does not reenable if the user has disabled
> it; but still enable it with F31>F33 since Fedora supports upgrades
> that skip one release. So yeah, I need to figure that out.

  User can prevent reenabling by "systemd mask fstrim". But it need
to be concious action taken.  We can document it in Release Notes.


-- 
Tomasz Torcz   72->|   80->|
to...@pipebreaker.pl   72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 31: dnf upgrade suddenly enables modular streams for protobuf

2019-12-06 Thread Tomasz Torcz
On Fri, Dec 06, 2019 at 05:40:23PM +0100, Miro Hrončok wrote:
> On 06. 12. 19 17:36, Miro Hrončok wrote:
> > Today I've attempted to run "dnf upgrade".
> > 
> > It has the following in it:
> > 
> > Upgrading:
> > protobuf  x86_64  3.6.1-6.module_f31+6793+1c93c38e  updates-modular
> > 
> > However, protobuf was not mentioned in https://pagure.io/fesco/issue/2285
> 
> More to it, the modular protobuf disables Python support in:
> 
> https://src.fedoraproject.org/rpms/protobuf/c/69b7a51fd87239ebc71c3c2e27ec852a19b99e7b?branch=eclipse
> 
> My packages explicitly require protobuf for Python support. This is breaking 
> them.

  So this is going to break Ceph, too.

-- 
Tomasz Torcz  “If you try to upissue this patchset I shall be 
seeking
to...@pipebreaker.pl   an IP-routable hand grenade.”  — Andrew Morton (LKML)
___
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: I wrote a blog on why we moved Fedora 31 to cgroup V2

2019-11-11 Thread Tomasz Torcz
On Mon, Nov 11, 2019 at 10:06:40AM -0500, Daniel Walsh wrote:
> https://www.redhat.com/sysadmin/fedora-31-control-group-v2

  You write that snap does not run with v2, but linked bug
shows snapd was fixed 2 months ago:
https://bodhi.fedoraproject.org/updates/FEDORA-2019-bb0a25e48d2

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Encrypted DNS in Fedora

2019-11-09 Thread Tomasz Torcz
On Thu, Nov 07, 2019 at 06:18:46PM +0100, Nicolas Mailhot via devel wrote:
> > > 
> > > DoH has zero integration and manageability. “It’s not centralized”
> > > (but
> > > you have to set manually DoH settings in all apps *or* rely on a
> > > centralized Google DoH whitelist) is an utter joke.
> > 
> >   Setting in all apps? Excuse me?  You run your stub DoH resolver
> > on ::1 and put ::1 in resolv.conf. 
> 
> That won't be honored by DoH-enabled apps that refuse to honor system
> resolution.
> 
> That won't be honoured by all the other things on your network, unless
> you reparameter every and each one of them by hand (assuming they
> support DoH, or allow setting a DNS resolver manually in the first
> place)
> 
> That won't be honoured by the smartphone of your visitors, by their pet
> smart collar, etc, unless you spend 15 minutes figuring how to
> reconfigure them at the start of their visit, and reconfigure them back
> at the end. Don't bother giving them your wifi code.
> 
> So, no smart tv, no internet radio, no smart toaster, no resolved
> network path to your gaming console, no nothing for them. Back to the
> dark ages where nothing worked by default, networks were an enterprise-
> only thing, and ISPs felt entitled to charge multiples if you plugged
> more than one computer at the end of their cable.

  Here's a network management lesson for you:
- run DoH resolver* not on ::1, but on IP available on your LAN
- put above IP in DHCP and RA replies
- bam! every device you mentioned uses DoH to resolve

* I'm not aware of any packaged for Fedora, I'm using
  https://github.com/m13253/dns-over-https myself

> That's what your single-system “solution” actually means.
> 
> Using DoH today means, in practical terms, using Google-approved
> resolvers, and names Google know of (bye bye private networks) because
> that's the only common ground DoH apps agree on, and the only practical
> way to synchronize DoH naming results with the rest of the network
> world.

  You seem to have some Google-fixation.  I'll refrain from continuing
this thread, you seem to be arguing against protocol, instead of
reaching consensus on how to provide tools for it in Fedora.

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
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 32 System-Wide Change proposal: Build Python 3 to statically link with libpython3.8.a for better performance

2019-11-07 Thread Tomasz Torcz
On Thu, Nov 07, 2019 at 05:15:18PM +0100, Vít Ondruch wrote:
> This sounds like the whole system could be 25% faster if we link statically.

  Yeah, that's the advantage of static linking.  This brings us stuff
like statically linked distibutions - https://sta.li/faq/
  Generally advantages of dynamic libraries prevail over speed.

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Encrypted DNS in Fedora

2019-11-05 Thread Tomasz Torcz
On Tue, Nov 05, 2019 at 10:00:17PM +0100, Nicolas Mailhot via devel wrote:
> Le mardi 05 novembre 2019 à 19:45 +0100, Tomasz Torcz a écrit :
> > 
> > 
> >   I don't agree with centralisation.  You should run your own DoH
> > endpoint,
> > using Google's, Cloudflare's or Quad9's servers is a shortcut.
> 
> DoH has zero integration and manageability. “It’s not centralized” (but
> you have to set manually DoH settings in all apps *or* rely on a
> centralized Google DoH whitelist) is an utter joke.

  Setting in all apps? Excuse me?  You run your stub DoH resolver
on ::1 and put ::1 in resolv.conf. Done, you've got DoH set
system-wide, which I believe this thread is about.
  And you run resolving endpoint on your trusted server, or on some
micro-vm in Azure or somewhere else, or even on Fedora's Communishift.
Google does not even enter the picture.

 (cutting the rest as it's irrelevant)

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Encrypted DNS in Fedora

2019-11-05 Thread Tomasz Torcz
On Tue, Nov 05, 2019 at 03:07:53PM +0100, Marius Schwarz wrote:
> 
> I personally favor DoT as it would make use of the millions of dns
> server available on the net. DoH is too centralized to implement for now.
> 

  I don't agree with centralisation.  You should run your own DoH endpoint,
using Google's, Cloudflare's or Quad9's servers is a shortcut.

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Encrypted DNS in Fedora

2019-11-05 Thread Tomasz Torcz
On Tue, Nov 05, 2019 at 02:09:31PM +0100, Marius Schwarz wrote:
> DoH is IMHO a waste of resources and as Browsers implement it, useless
> at best, but mostly a centralization of control of users under a false
> protection umbrella.
> 
> Any modern Browser will do this sequence:
> 
> User enters URL
> Browser checks for domainnames
> Browser sends DNS request ( over which path doesn't matter )
> Opens connection to the target host
> 
> If ( HTTPS ) {
>     sends the domainname, he has found in the URL as SNI in plain! in
> his TLS request

  This is not true, SNI is encrypted:
  https://eff.org/pl/deeplinks/2018/09/esni-privacy-protecting-upgrade-https
-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Encrypted DNS in Fedora

2019-11-04 Thread Tomasz Torcz
On Mon, Nov 04, 2019 at 10:40:47AM -0600, Michael Cronenworth wrote:
> Hi,
> 
> Is there any project or team involved with improving encrypted DNS support
> in Fedora? Any movement in Red Hat corporate?
> 
> - Glibc team?
>     The /etc/resolv.conf file needs some love. AFAIK it still does not verify 
> DNSSEC.
> - Bind team?
>     Using 'stunnel' is not a real option.
> - DHCP(d & c) team?
>     Some sort of standard for applying DoT/DoH options to resolv.conf
> - NetworkManager team?
>     Same as above.
> 
> This last effort I know of was back in 2012[1] but it was limited to DNSSEC
> only. According to Arch's table[2] only two DNS applications have support
> for encrypted DNS.
> 
> IMHO, this should be our number one priority over modules, new spins, or
> whatever paint color the bike shed needs to be today. I would like to see
> DNS over TLS (DoT) with DTLS at the very least.

  We have getdns-stubby packaged for DoT and dnscrypt-proxy for DoH.
Anyone interested can have Do* enabled on his system.
systemd-resolved also supports DoT, although in insecure way:
https://github.com/systemd/systemd/issues/9397
We may be missing stuff like https://github.com/dimkr/nss-tls ,
but do we need it?

  I have DoH enabled system-wide on one of my installatioans for over
a year. We have required software packaged, so what exactly do you
propose?

-- 
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen
___
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: Issues with the retrace service?

2019-10-27 Thread Tomasz Torcz
On Sun, Oct 27, 2019 at 11:10:48AM +0100, Chris Murphy wrote:
> I filed this awhile ago, but didn't pursue getting it disabled on the
> Fedora side in the meantime. While I'm a fan of zstd, I think in hindsight
> I'd have recommended postponing rolling out that change until a retrace
> server solution was in place. I'd definitely say this should have been a
> listed liability of the change to use zstd.

   This is a fallout of us not “dogfooding”, but running our infrastructure
on some other distributions.

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
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: Switching Maven and Ant to OpenJDK 11

2019-10-26 Thread Tomasz Torcz
On Sat, Oct 26, 2019 at 02:23:33PM -0400, Nico Kadel-Garcia wrote:
> > >
> > >  Any reasons?  Defaulting to ancient software conflicts with our “First” 
> > > foundation.
> >
> > Simple reason - while Oracle decided to move Java to a faster, time
> > based release cycle the Java community essentially shrugged the
> > proverbial shoulders and ignored Oracle.
> >
> > Much of the Java ecosystem is still only supported on Java 8, and if
> > you go to adoptopenjdk.net the default choice remains Java 8.
> 

> I'm afraid that Oracle inherited a lot of Sun's practices on software
> versioning when they bought Java. The version naming scheme, numbering
> scheme, and the release schedule, are inconsistent, unpredictable, and
> cannot be relied on from Oracle's announcements,  Ergo, right now,
> Oracle is deprecating Java 8, and encouraging the current LTS, Java
> 11. Make no prodictions for the schedule or the next LTS release, this
> is *right now*.

  According to the table at https://en.wikipedia.org/wiki/Java_version_history
Java 11 is LTS, and the next LTS will be Java 17 in 2021. There are also
planned releases in between, with dates given.
  By the way, isn't Redhat main driving force behind Java 11 at the moment? 
What to make from
  
https://www.redhat.com/en/about/press-releases/leadership-openjdk-8-and-openjdk-11-transitions-red-hat
 ?

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
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: Switching Maven and Ant to OpenJDK 11

2019-10-26 Thread Tomasz Torcz
On Sat, Oct 26, 2019 at 03:53:28PM +0200, Jiri Vanek wrote:
> any package can switch to jdk11, but sysem jdk should be jdk8, at least for 
> some more time...

  Any reasons?  Defaulting to ancient software conflicts with our “First” 
foundation.

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
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: Bugzilla needinfo reminders

2019-10-25 Thread Tomasz Torcz
On Fri, Oct 25, 2019 at 09:30:39AM +0200, Kamil Dudka wrote:
> On Friday, October 25, 2019 9:11:39 AM CEST Tomasz Torcz wrote:
> > Hi,
> > 
> >   Few days ago (22nd Oct) I've started receiving daily reminders
> > about needinfo for over a year old bugs.  Which is strange, as those bugs
> > are closed.
> 
> Bugzilla sends you notifications because the needinfo flag is set on you.
> Why do not you simply clear the needinfo flag if it is not valid any more?

  I've done it now.

> >   The notification are not really true, also. For example, bug …460
> > below is listed as 66 days old.  I've filled it on 2018-07-09,
> > which makes it 473 days old.
> > 
> >   Can we revert whatever change was made to bugzilla on 21st Oct
> > in order to receive less nags?
> 
> I do not support this request.  I appreciate those notifications myself.
> 

  They make sense for current bugs. Not for the ones CLOSED for months.


-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
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


Bugzilla needinfo reminders

2019-10-25 Thread Tomasz Torcz
Hi,

  Few days ago (22nd Oct) I've started receiving daily reminders
about needinfo for over a year old bugs.  Which is strange, as those bugs
are closed.
  The notification are not really true, also. For example, bug …460
below is listed as 66 days old.  I've filled it on 2018-07-09,
which makes it 473 days old.

  Can we revert whatever change was made to bugzilla on 21st Oct
in order to receive less nags?


- Forwarded message from bugzi...@redhat.com -

Date: Fri, 25 Oct 2019 02:27:16 GMT
From: bugzi...@redhat.com
To: to...@pipebreaker.pl
Subject: [Red Hat Bugzilla] Your Outstanding Requests

The following is a list of bugs or attachments to bugs in which a user has been
waiting more than 3 days for a response from you. Please take
action on these requests as quickly as possible. (Note that some of these bugs
might already be closed, but a user is still waiting for your response.)

We'll remind you again tomorrow if these requests are still outstanding, or if
there are any new requests where users have been waiting more than 3
days for your response.

needinfo


  Bug 1599383: frequent errors with iwlwifi (389 days old)
https://bugzilla.redhat.com/show_bug.cgi?id=1599383
  
  Bug 1574460: Null pointer dereference in sha256_ssse3 module (66 days old)
https://bugzilla.redhat.com/show_bug.cgi?id=1574460
  
To see all your outstanding requests, visit:
https://bugzilla.redhat.com/request.cgi?action=queue=tomek%40pipebreaker.pl=type

- End forwarded message -

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
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 32 System-Wide Change proposal: Modules in Non-Modular Buildroot

2019-10-15 Thread Tomasz Torcz
On Tue, Oct 15, 2019 at 01:56:11PM -0400, Robbie Harwood wrote:
> Matthew Miller  writes:
> 
> > On Tue, Oct 15, 2019 at 12:36:15PM +0200, Miro Hrončok wrote:
> >>> As package maintainers we all make technical decisions which have
> >>> significant impact on our users every day - whether that's in the
> >>> choice of defaults, choice of build flags, or whatever.  Honestly
> >>> delivering as modules-vs-non-modules is a completely trivial issue
> >>> compared to most of the stuff I spend time on.  If "yum install X"
> >>> still works most people just don't care about the RPM/dnf/repo
> >>> mechanics behind that.
> >> 
> >> Except it works only half way. The installation works. Later,
> >> dependencies are broken. Upgrades are broken. "yum remove X" does not
> >> undo the action completely.
> >> 
> >> The main issue is: user just enabled a module without doing it
> >> explicitly. The user needs to know how to handle modules in order to
> >> recover.
> >
> > I never expect "yum remove X" to be the inverse of "yum install
> > X". DNF's magical leaf tracking makes it a bit more so, but not
> > exactly. So, I don't think we should make that a very high priority
> > concern (although if we can improve it, so much the better).
> 
> I don't think it's an unreasonable expectation, especially for those
> coming from APT land (Debian, Ubuntu) where `apt install foo` *is* the
> inverse operation of `apt remove foo`.

  It isn't, you need to supplement it with `apt autoremove` to get rid
of auto-installed dependencies.
  We have `dnf history undo X` to invert installation command.


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: Modularity and the system-upgrade path

2019-10-07 Thread Tomasz Torcz
On Mon, Oct 07, 2019 at 02:59:37PM -0400, Stephen Gallagher wrote:
> On Mon, Oct 7, 2019 at 2:56 PM Simo Sorce  wrote:
> >
> > I have to ask,
> > given containers are so popular and can deal with any dependency
> > without conflicting with system installed binaries, should we really
> > continue with this very complicated modular design ?
> >
> > Shouldn't we go back to have default packages and then defer to
> > "containers" for applications (and their dependencies) that need to
> > deviate from system defaults for any reason ?
> >
> 
> And where is the software for those containers coming from? Some

  From distribution repositories? Like it always did?

> container registry like Docker Hub? One of the main points of
> Modularity is to provide a trusted source of software to install into
> containers.

  We had this (FROM fedora:30…) before Modularity. Yes, there is a
problem when you run Fedora N with specific software version Y,
and you want to build container with software version Y-2, which
was shipped in Fedora N-4.  You would need to create container from
unsupported, unsecure version of Fedora N-4.  But you have no
guarantee that maintainer will provide software verson Y-2 built as
module on top of Fedora N.
  At the moment modularity broke most basic functionality – upgrade from
Fedora N to N+1.

-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML
___
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: kata containers: adding a docker runtime

2019-09-25 Thread Tomasz Torcz
On Wed, Sep 25, 2019 at 12:14:54PM +0200, Christophe de Dinechin wrote:
> Hi Lokesh,
> 
> 
> As you know, I have been working on bringing kata containers to Fedora.
> 
> Since this adds a new runtime, the docker.service file would need to be
> modified in order to be able to accommodate extra --add-runtime options.
> 
> What approach would you recommend?

  There's no Docker in Fedora anymore, so maybe don't bother?
 
-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 31 System-Wide Change proposal (late): No i686 Repositories

2019-09-09 Thread Tomasz Torcz
On Mon, Sep 09, 2019 at 03:36:45PM -, vvs vvs wrote:
> 
> What work should be done? Please, be more specific.

  Deja vu… please read https://pagure.io/fesco/issue/1737
(Proposal: i686 SIG needs to be functional by F27 release date or we
drop i686 kernel from F28) with all the links.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: translucent gnome top bar gone in F31?

2019-09-09 Thread Tomasz Torcz
On Mon, Sep 09, 2019 at 04:39:47AM -0700, John M. Harris Jr. wrote:
> > > 
> > > This is precisely the issue with GNOME entirely. It assumes the user
> > > shouldn't 
> > > have a choice, that some designers know best.
> > 
> > 
> > Yes, precisely *your* issue. I’d rather someone think for me as far as
> > defaults go and not give me a quest to set everything up just right
> > every time I install the DE.
> > 
> 
> Decisions such as this, inspired by the idea that *somebody* knows best, and 
> it just works for everyone, are precisely why I won't be able to deploy RHEL 
> 8 
> until KDE is available through EPEL or another repo. Heck, the only reason I 
> can even run RHEL 8 on my test box is because I manually compiled KDE for it.
> 
> This is incredibly common in GNOME, where people just make a decision and try 
> to enforce it on the users. Things everyone hates, like moving the mouse into 
> the top-left corner opening some weird menu, and the only way to disable it 
> being third party software. (Something I've had to provide a fix by default 
> for 
> on my RHEL 7 deployments, where some of my users prefer GNOME), and where 
> users request that I install gnome-tweak-tool for them so that they can make 
> basic preference changes which just aren't available otherwise.

  John,

  you personal opinions are not providing anything valuable in this
 thread.  This went offtopic too much, bordering on insults.
  Please keep our mailling list productive and civilised.


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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 Samba DC for what purpose it is released in Fedora ?

2019-09-02 Thread Tomasz Torcz
On Mon, Sep 02, 2019 at 05:14:35PM +0200, Dario Lesca wrote:
> a) For what purpose it's released Fedora Samba MIT-KERBEROS DC?

  This is for FreeIPA interoperability, described at
  https://www.freeipa.org/page/IPA_and_AD

  This is enabled because:
  1) FreeIPA is important part of Fedora deliverables
  2) Samba as DC is not.


-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: Join the new Minimization Team

2019-08-26 Thread Tomasz Torcz
On Mon, Aug 26, 2019 at 06:46:29PM -0700, John Harris wrote:
> On Monday, August 26, 2019 5:50:53 AM MST Christian Glombek wrote:
> > 
> > Wow, a model like _distroless_ is exactly what I think we need in and from
> > Fedora to enable making those minimal, purpose-built and service-specific
> > containers.
> > 
> > I was thinking of a concept that has rpm-ostree compose a set of packages
> > to a root dir, and put that in a container with Buildah.
> > Not sure how feasible it would be to add that functionality (as opposed to
> > simply using dnf for this), but I'm thinking it would be super neat to have
> > a coreos-assembler that also does container composes from an ostree
> > manifest, in the same way it assembles OS images in different formats for
> > different platforms.
> > 
> > I'd also like to link to Adam's super informational page here:
> > https://asamalik.fedorapeople.org/container-randomness/report-f31.html
> > It would be great if we could include infos about the package sets of our
> > ostree-based composes in there as well (FCOS, Silverblue and IoT). Also
> > note that our container scratch build size has gone up dramatically in F31
> > (I don't know why, yet).
> > 
> > cc'ing Ben Breard and Sanja Bonic for their general interest in the
> > Minimization effort.
> 
> That sort of container is exactly the kind of thing that *cannot be 
> maintained*. I say this as a sysadmin in a fairly large environment, that 
> container simply *would not get updated*. It'd sit until it either quit 
> working or somebody noticed it and removed it because it was a security risk, 
> full of vulnerabilities.

  John, if you do not want to use the containers, then don't do it.
There are people who like containers and are serious about them.  Being
serious means that one has automated pipeline that builds, tests and
deploys updated container, without engaging sysadmins.

  Your remarks do not move discussion forward.  The point is how to get
smallest viable container.  Your comments ignore decades of experience
of containerising workloads.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: systemd-243-rc2

2019-08-22 Thread Tomasz Torcz
On Thu, Aug 22, 2019 at 05:44:13PM -, zfnoc...@gmail.com wrote:
> > - BFQ is used as the default scheduler for disks, mmc cards, etc.
> Perhaps I am not seeing the right patch, but looking at what was posted on 
> github [1], doesn't this udev rule skip over eMMC and SD cards which appear 
> as "/dev/mmcblk#"?

  Yes, you're looking at the wrong patch. Setting BFQ is a downstream
decision:
  
https://src.fedoraproject.org/rpms/systemd/blob/d7b2d46533ca7c2a2b9092ff9ef0dae12cdb3ef2/f/464a73411c13596a130a7a8f0ac00ca728e5f69e.patch

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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: Join the new Minimization Team

2019-08-21 Thread Tomasz Torcz
On Tue, Aug 20, 2019 at 10:52:18PM -0700, John Harris wrote:
> 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.

  You do not update the container. You rebuild it, creating new image
with updated components, then you test out new image.
  Package manager is only needed during the build (in fact, it
is indispensable at this step) but not during runtime.

-- 
Tomasz   .. oo o.   oo o. .o   .o o. o. oo o.   ..
Torcz.. .o .o   .o .o oo   oo .o .. .. oo   oo
o.o.o.   .o .. o.   o. o. o.   o. o. oo .. ..   o.
___
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]

2019-08-19 Thread Tomasz Torcz
On Sat, Aug 17, 2019 at 05:24:18PM -0700, Joseph D. Wagner wrote:
> Sorry if this is the wrong place to post. I need to start somewhere.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1742953
> 
> Description of problem:
> The Plymouth LUKS password prompt will wait FOREVER for me to type in a
> password without powering down the monitor or blanking the screen. This
> leaves me vulnerable to screen burn-in if 1) there was an unexpected
> reboot like a crash, or 2) another OS (which shall remain nameless)
> rebooted after update, but the dual-boot started in Linux instead of
> the other OS.

  Actually, I don't think systemd touch the kernel default here.
See consoleblank= parameter
https://www.kernel.org/doc/html/v5.2/admin-guide/kernel-parameters.html
Some years ago it was set to be disabled by default, previously had some
other value.


-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
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 Module Mass Rebuild

2019-08-13 Thread Tomasz Torcz
On Mon, Aug 12, 2019 at 07:50:17AM -0400, Mohan Boddu wrote:
> Hi all,
> 
> Due to an issue with mbs authentication and then travel for FLOCK, we
> couldn't run mass rebuilds of modules last week (mass rebuilds of modules
> is run after mass rebuild of rpms are done). We are planning to try it
> today. Please look out for module builds that we will be submitting as part
> of mass rebuild and sorry for the delay.

  How does this interact with mass branching?

-- 
Tomasz TorczOnly gods can safely risk perfection,
xmpp: zdzich...@chrome.pl it's a dangerous thing for a man.  -- Alia
___
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: Rolling out Phase I of rawhide package gating

2019-07-31 Thread Tomasz Torcz
On Wed, Jul 31, 2019 at 03:15:32PM +0100, Richard W.M. Jones wrote:
> On Tue, Jul 30, 2019 at 11:11:34AM -0700, Kevin Fenzi wrote:
> > In this case it's koji.
> > 
> > For every package in the mass rebuild (f31-pending tag) robosign asks
> > koji "hey, is foobar-1.0.1-1.fc31 signed' ? koji checks... "yes, it is".
> > robosign: "great, then I ask you to write out the signed rpms now"
> > koji: "ok, writing them out to disk again"
> > 
> > it's mostly this last step thats slow. I am not sure if koji is just
> > seeing if they were written out and returning, or actually re-writing
> > them out. It seems like it might be the latter, which makes me suspect
> > koji could optimize this somewhat.
> 
> It's still taking a long time today to get builds through Koji and
> into Rawhide.  Is there a reason we need to sign builds in Rawhide?

  Because administrator of Fedora infrastructure run rawhide on laptops, and we
don't want them to be easily* hackable.

  * or maybe not easily, but easier than users of regular releases

-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML
___
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: Rolling out Phase I of rawhide package gating

2019-07-24 Thread Tomasz Torcz
On Wed, Jul 24, 2019 at 03:36:35PM +0200, Miro Hrončok wrote:
> On 24. 07. 19 14:32, Josh Boyer wrote:
> > On Wed, Jul 24, 2019 at 8:02 AM Miro Hrončok  wrote:
> > > 
> > > On 24. 07. 19 10:24, Tom Hughes wrote:
> > > > That said, having to go round adding a mega ugly config file
> > > > to every package that looks an awful lot like an internal braindump
> > > > from some system doesn't really inspire confidence, or make for an
> > > > easy way of opting in.
> > > 
> > > This. The gating.yaml file is terrible.
> > 
> > Do either of you have a better suggestion?
> 
> This looks quite better:
> https://pagure.io/fedora-ci/general/issue/52#comment-584489

  Pagure.io is not reachable since few days (traceroute end at
2605:bc80:f03:4::2 corv-car1-gw.nero.net) so it a bit hard
to discuss this proposal.


-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora 31 System-Wide Change proposal: Modify Fedora 31 to use CgroupsV2 by default

2019-07-03 Thread Tomasz Torcz
On Wed, Jul 03, 2019 at 04:23:24PM -0400, Ben Cotton wrote:
> * Other developers:
> We need to find other tools that have built the CGroupsV1 API into
> themselves and get them to support CGroupsV2.
> 
> Known packages:
> 
> - libvirt: The team is already working on this.
> 
> -  JVM:  Uses Cgroups file system to check for allocated memory for
> the JVM, will have to use and understand the CgroupV2 mechanism to
> discover these sessings.
> 
> - Snap package does not run with CGroupV2:
> https://bugzilla.redhat.com/show_bug.cgi?id=1438079
> 
> - Systemd will need to be modified to set the new default to cgroupv2

  What about Kubernetes?  Will it work?
  (Also upgrade would be nice, we ship 1.13 and latest is 1.15)


-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev
___
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: Upgrade to Fedora 30 consistently corrupts bcache storage - is there some kind of emergency brake possible during upgrade?

2019-05-12 Thread Tomasz Torcz
On Sun, May 12, 2019 at 01:09:40PM +0200, Rolf Fokkens wrote:
> Hi All,
> 
> There's this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1708315
> 
> Would have been better if I discovered it during Alpha or Beta, but
> unfortunately I didn't. Now we have the situation that any bcache user
> upgrading to Fedora30 involuntarily currupts his storage.
> 

  This is huge!  Accidentaly, after upgrade to F30 I experience
two or three I/O hangs with bcache, so I temporarily detached cache
device and (knock on wood) there are no problems (my rootfs is btrfs
raid10 over bcache devices).

  I suggest:
  1) getting this bug into F30 Common Bugs page, with hint that
  detaching cache device before upgrade could help.
  2) complement rhbz#1708315 with pointers to upstream report.


-- 
Tomasz TorczThere exists no separation between gods and men:
xmpp: zdzich...@chrome.pl   one blends softly casual into the other.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Docker and user namespaces on F30

2019-05-10 Thread Tomasz Torcz
On Mon, May 06, 2019 at 04:17:18PM +0200, Jun Aruga wrote:
> Podman 1.2 and Docker CE 18.09.5 on My Fedora 30 work for your use case.
> 
> $ docker --version
> Docker version 18.09.5, build e8ff056

  This is not what Fedora ships. We have (in F30)
  docker-1.13.1-67.git1185cfd or moby-engine-18.06.3-2.ce.gitd7080c1.

-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Upgrade to F30 gone wrong

2019-05-06 Thread Tomasz Torcz
On Mon, May 06, 2019 at 12:13:16PM -0600, Chris Murphy wrote:
> On Mon, May 6, 2019 at 8:47 AM Tomasz Torcz  wrote:
> >
> > % dnf --releasever=31 system-upgrade download
> > Before you continue ensure that your system is fully upgraded by running
> > "dnf --refresh upgrade". Do you want to continue [y/N]:
> >
> >   So this message should read “Ensure your system is different that
> >   we test for”?
> 
> No.
> 
> Different than release testing that occurred during the last final
> freeze, yes. But still tested, as QA, and many other Fedora users and
> testers, test the packages in updates-testing before those packages
> move to the updates repo.

  Ah, ok. “through-the-upgrades” meant “dnf system-upgrade”, no plain
“dnf upgrade”. Even criteria talks about fully upgraded system.
  I've misunderstood completely :(

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Upgrade to F30 gone wrong

2019-05-06 Thread Tomasz Torcz
On Mon, May 06, 2019 at 09:54:33AM -0400, Stephen John Smoogen wrote:
> On Mon, 6 May 2019 at 09:26, Roberto Ragusa  wrote:
> 
> > On 5/6/19 1:40 PM, Julen Landa Alustiza wrote:
> >
> > > We found this bug before releasing, but it is not a release blocking bug
> > (the upgrade criteria just cover clean n and n-1 upgrading to n+1 and this
> > bug just happens whith continously upgraded systems since fc21 or lower)
> >
> > Wait a moment, is n and n-1 defined to "installed from scratch n and n-1?".
> > Is this a precedent that n-installed is different than n-through-upgrades?
> >
> >
> As far as I know this has been the case from Red Hat Linux 6.1 and all
> Fedora's. It is nice if it works (which it generally does) but there are
> too many little things which make it impossible to catch even a fraction of
> the outliers.

% dnf --releasever=31 system-upgrade download
Before you continue ensure that your system is fully upgraded by running
"dnf --refresh upgrade". Do you want to continue [y/N]: 

  So this message should read “Ensure your system is different that
  we test for”?


-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: How to install a mountpoint directory from an rpm?

2019-04-30 Thread Tomasz Torcz
On Tue, Apr 30, 2019 at 05:29:17PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Apr 30, 2019 at 01:12:43PM -0400, Robert Marcano wrote:
> > On 4/30/19 11:45 AM, David Howells wrote:
> > >Hi,
> > >
> > >I need to install a directory (/afs) that will be a mountpoint that a 
> > >systemd
> > >service (also installed in the rpm) will mount upon.
> 
> Nope. New top-level directories are a big thing and need FPC approval:
> https://fedoraproject.org/w/index.php?title=Packaging:Guidelines=528452#Filesystem_Layout
> (I can't find the text in the new guidelines, but the new guidelines don't
> support searching, so finding anything is PITA, so I'll just assume that
> this is still valid...)
> 
> Regarding the FPC approval: I don't think it should be granted. There
> is no good reason to create a mount point like this under root. It should go
> somewhere under /run or /var.

  Yes. For example, for OWFS we mount at /run/owfs, which we create with
RuntimeDirectory=owfs in owfs.service.


-- 
Tomasz Torcz  ,,If you try to upissue this patchset I shall be 
seeking
xmpp: zdzich...@chrome.pl   an IP-routable hand grenade.'' -- Andrew Morton 
(LKML)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: grub2-editenv: error: environment block too small after kernel install

2019-04-24 Thread Tomasz Torcz
On Tue, Apr 23, 2019 at 06:19:14PM -0600, Chris Murphy wrote:
> On Tue, Apr 23, 2019 at 8:38 AM Richard Shaw  wrote:
> >
> > I made the mistake of editing my grubenv while converting my system from 
> > BIOS to UEFI.
> >
> > I have since manually used grub2-editenv successfully but I still get 
> > "grub2-editenv: error: environment block too small." on kernel upgrades. 
> > I've even tried manually re-padding the file with # to get to 1024 bytes.
> >
> > I have also filed and issue upstream that grub2-editenv is too fragile. It 
> > should be able to automatically re-pad the file to 1024 bytes.
> >
> > How do I "fix" this?
> 
> # ls -ls /boot/grub2
> total 4
> 4 lrwxrwxrwx. 1 root root 25 Apr 18 11:34 grubenv -> ../efi/EFI/fedora/grubenv
> 
> It's actually a symlink on both BIOS and UEFI. This file will be on
> the /boot volume (typically ext4) on BIOS systems, and it will be on
> the EFI System partition (FAT16 if anaconda creates it) on UEFI.

  This part is really counter-intuitive. Using “EFI” in path on BIOS
system made me waste some time when I was recovering my system after
f29→f30 system upgrade.
  (the problem turned out to be translation from grub2.cfg to BLS
  removing all important rd.luks.uuid= entries from kernel cmdline).

-- 
Tomasz Torcz   72->|   80->|
xmpp: zdzich...@chrome.pl  72->|   80->|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Autoconf help: missing X11 dependency

2019-04-11 Thread Tomasz Torcz
On Thu, Apr 11, 2019 at 02:11:14PM -, Lukas Zapletal wrote:
> Hello,
> 
> my package "workrave" won't build with Rawhide, configure script complains:
> 
> checking for X... no
> configure: error: X11 required on Unix platform
> 
> However it keeps complaining even when I add BuildRequires:
> libX11-devel. I don't understang which particular (sub)library it
> needs, generated configure is a bit unreadable (really!) and even
> debugging it with +x is not really helpful as it is a storm of tests.
> Any idea how to debug this? What X11 library am I missing? Any recent
> changes in the X11 libraries? This is a regression, it was working
> fine.

  Looking at
  
https://sourceforge.net/p/workrave/code/HEAD/tree/workrave/branches/branch_v1_9/configure.ac
  the check is fo Xmu header:
  AC_CHECK_HEADER("X11/Xmu/Xmu.h",,)

  which comes from libXmu-devel package. Although the configure.ac I've
found is from decade ago, something may have changed during the years.


-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Can't push to batched an Fedora 30 update?

2019-03-11 Thread Tomasz Torcz
On Mon, Mar 11, 2019 at 10:46:47AM -0400, Randy Barlow wrote:
> On Mon, 2019-03-11 at 10:35 -0400, Randy Barlow wrote:
> > On Mon, 2019-03-11 at 08:22 +, Richard W.M. Jones wrote:
> > > https://bodhi.fedoraproject.org/updates/FEDORA-2019-fd699ee2ea
> > > 
> > > "This update has reached 3 days in testing and can be pushed to
> > > stable
> > > now if the maintainer wishes"
> > > 
> > > Yes I'd like to, but there's no push to batched button!
> > 
> > I noticed this on one of my packages too today. I'm going to look
> > into
> > it now. My guess is that the front end was not updated with the
> > configuration change when Fedora 30 was added to Bodhi, but I am not
> > sure yet.
> 
> I have confirmed that the frontend has not been restarted since Fedora
> 30 was added, which would cause this problem. I've filed a freeze break
> request to get permission to rebuild the frontend containers with the
> config change:
> 
> https://lists.fedoraproject.org/archives/list/infrastruct...@lists.fedoraproject.org/thread/7X6B6BGFJ7SYZA243XOVPEJT7KVXRS24/

  Hmm, rebulding container on config change? Sounds fishy.
Have you tried putting production.ini into ConfigMap?

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: python-flake8 package not available in F30

2019-03-09 Thread Tomasz Torcz
On Sat, Mar 09, 2019 at 09:26:49AM -0500, Chris wrote:
> I have a slightly different packaging issue with the repository structure
> (similar state on both COPR an Koji).
> 
> In epel7, f28, and f29 i can use the line:
> BuildRequires: python-flake8
> 
> However this package is not available on f30 servers:
> Koji ref: https://koji.fedoraproject.org/koji/taskinfo?taskID=33329251

  This is available both in F30:
  https://koji.fedoraproject.org/koji/buildinfo?buildID=1217218

  and in Rawhide:
  https://koji.fedoraproject.org/koji/buildinfo?buildID=1217211

  Note that the name of a package is python3-flake8 – we are removing
python2 from Fedora.

> I realize f30 is in rawhide state right now, so i wasn't sure if this is
> the right forum for this question or if i should just wait?

  Rawhide is f31 at the moment. F30 is in beta freeze.

-- 
Tomasz Torcz   "Never underestimate the bandwidth of a station
xmpp: zdzich...@chrome.plwagon filled with backup tapes." -- Jim Gray
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Donate 1 minute of your time to test upgrades from F29 to F30

2019-03-02 Thread Tomasz Torcz
On Sat, Mar 02, 2019 at 08:03:21AM -0800, Adam Williamson wrote:
> On Sat, 2019-03-02 at 16:59 +0100, Tomasz Torcz wrote:
> > On Thu, Feb 28, 2019 at 10:22:51AM +0100, Miroslav Suchý wrote:
> > > Do you want to make Fedora 30 better? Please spend 1 minute of your time 
> > > and try to run:
> > > 
> > >   sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 
> > > --enablerepo=updates-testing distro-sync
> > > 
> > > If you get this prompt:
> > > 
> > >   ...
> > >   Total download size: XXX M
> > >   Is this ok [y/N]:
> > > 
> > > you can answer N and nothing happens, no need to test the real upgrade. 
> > > Upgrades will be fine for you.
> > > 
> > > But very likely you get some dependency problem now. In that case please 
> > > report it against appropriate package.
> > 
> >   15 problems… ceph, freeipa, sssd, mainly in conjuction with python2 
> > packages.
> > So core elements of distribution – I guess it is not worth to file bugs
> > for them, it could hardly be overlook during normal QA process.
> 
> No, please do file bugs if you have the time. 

  All right, then.


 Problem 1: package hamcrest-1.3-25.fc30.noarch requires hamcrest-core = 
1.3-25.fc30, but none of the providers can be installed
  - cannot install the best update candidate for package 
hamcrest-1.3-24.fc29.noarch
  - package hamcrest-core-1.3-25.fc30.noarch is excluded
 Problem 13: problem with installed package hamcrest-1.3-24.fc29.noarch
  - package hamcrest-1.3-25.fc30.noarch requires hamcrest-core = 1.3-25.fc30, 
but none of the providers can be installed
  - hamcrest-1.3-24.fc29.noarch does not belong to a distupgrade repository
  - package hamcrest-core-1.3-25.fc30.noarch is excluded
 

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

---

 Problem 2: package python-cephfs-1:12.2.11-1.fc29.x86_64 requires libcephfs2 = 
1:12.2.11-1.fc29, but none of the providers can be installed
  - libcephfs2-1:12.2.11-1.fc29.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package python-cephfs-1:12.2.11-1.fc29.x86_64
 
 Problem 3: package python-rados-1:12.2.11-1.fc29.x86_64 requires librados2 = 
1:12.2.11-1.fc29, but none of the providers can be installed
  - librados2-1:12.2.11-1.fc29.x86_64 does not belong to a distupgrade 
repository
  - problem with installed package python-rados-1:12.2.11-1.fc29.x86_64
 
 Problem 4: package python-rbd-1:12.2.11-1.fc29.x86_64 requires librbd1 = 
1:12.2.11-1.fc29, but none of the providers can be installed
  - librbd1-1:12.2.11-1.fc29.x86_64 does not belong to a distupgrade repository
  - problem with installed package python-rbd-1:12.2.11-1.fc29.x86_64
 
 Problem 5: package python-rgw-1:12.2.11-1.fc29.x86_64 requires librgw2 = 
1:12.2.11-1.fc29, but none of the providers can be installed
  - librgw2-1:12.2.11-1.fc29.x86_64 does not belong to a distupgrade repository
  - problem with installed package python-rgw-1:12.2.11-1.fc29.x86_64
P
roblem 14: package ceph-mgr-2:14.0.1-4.fc30.x86_64 requires python3-pecan, but 
none of the providers can be installed
  - package python3-pecan-1.3.2-6.fc30.noarch conflicts with python2-pecan < 
1.3.2-5 provided by python2-pecan-1.3.2-4.fc29.noarch
  - cannot install the best update candidate for package 
ceph-mgr-1:12.2.11-1.fc29.x86_64
  - problem with installed package python2-pecan-1.3.2-4.fc29.noarch

 Problem 15: package python-cephfs-1:12.2.11-1.fc29.x86_64 requires libcephfs2 
= 1:12.2.11-1.fc29, but none of the providers can be installed
  - cannot install both libcephfs2-2:14.0.1-4.fc30.x86_64 and 
libcephfs2-1:12.2.11-1.fc29.x86_64
  - package python-ceph-compat-1:12.2.11-1.fc29.x86_64 requires python-cephfs = 
1:12.2.11-1.fc29, but none of the providers can be installed
  - cannot install the best update candidate for package 
libcephfs2-1:12.2.11-1.fc29.x86_64
  - problem with installed package python-ceph-compat-1:12.2.11-1.fc29.x86_64

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

---

 Problem 6: package python2-ipaclient-4.7.2-1.1.fc29.noarch requires 
freeipa-client-common = 4.7.2-1.1.fc29, but none of the providers can be 
installed
  - freeipa-client-common-4.7.2-1.1.fc29.noarch does not belong to a 
distupgrade repository
  - problem with installed package python2-ipaclient-4.7.2-1.1.fc29.noarch
 Problem 7: package python2-ipalib-4.7.2-1.1.fc29.noarch requires 
freeipa-common = 4.7.2-1.1.fc29, but none of the providers can be installed
  - freeipa-common-4.7.2-1.1.fc29.noarch does not belong to a distupgrade 
repository
  - problem with installed package python2-ipalib-4.7.2-1.1.fc29.noarch
 Problem 8: package python2-libipa_hbac-2.0.0-5.fc29.x86_64 requires 
libipa_hbac = 2.0.0-5.fc29, but none of the providers can be installed
  - libipa_hbac-2.0.0-5.fc29.x86_64 does not 

Re: Donate 1 minute of your time to test upgrades from F29 to F30

2019-03-02 Thread Tomasz Torcz
On Thu, Feb 28, 2019 at 10:22:51AM +0100, Miroslav Suchý wrote:
> Do you want to make Fedora 30 better? Please spend 1 minute of your time and 
> try to run:
> 
>   sudo dnf --releasever=30 --setopt=module_platform_id=platform:f30 
> --enablerepo=updates-testing distro-sync
> 
> If you get this prompt:
> 
>   ...
>   Total download size: XXX M
>   Is this ok [y/N]:
> 
> you can answer N and nothing happens, no need to test the real upgrade. 
> Upgrades will be fine for you.
> 
> But very likely you get some dependency problem now. In that case please 
> report it against appropriate package.

  15 problems… ceph, freeipa, sssd, mainly in conjuction with python2 packages.
So core elements of distribution – I guess it is not worth to file bugs
for them, it could hardly be overlook during normal QA process.

-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Fedora Rawhide-20190211.n.0 compose check report

2019-02-11 Thread Tomasz Torcz
On Mon, Feb 11, 2019 at 08:56:30AM -0800, Adam Williamson wrote:
> On Mon, 2019-02-11 at 11:44 +, Fedora compose checker wrote:
> > Missing expected images:
> > 
> > Atomichost raw-xz x86_64
> > Atomichost qcow2 x86_64
> > 
> > Compose FAILS proposed Rawhide gating check!
> > 27 of 47 required tests failed, 17 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
> > 
> > Failed openQA tests: 82/132 (x86_64), 24/24 (i386), 1/2 (arm)
> 
> So, once again tests are failing because something looks different in
> the installer. The icons on the hub screens have changed for some
> reason, I'm assuming it's some kind of icon theme change. For e.g. the
> "Time & Date" clock icon now seems to be a sort of darkish grey rather
> than black, and the appearance of the "Installation Destination" icon
> has changed somewhat.

   Maybe Anaconda is affected by
   https://www.omgubuntu.co.uk/2018/07/gnome-icon-redesign ?

-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: Strange rawhide behaviour

2019-01-30 Thread Tomasz Torcz
On Wed, Jan 30, 2019 at 03:20:31PM +0100, Michal Schorm wrote:
> On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini  wrote:
> > Not necessarily. Builds are only pushed to repositories after a successful 
> > compose, but are available in koji only a few minutes after they were built.
> > That means that packages built locally or on COPR (which use the rawhide 
> > repository) get "older" versions than the koji builds that have access to 
> > new packages pre-compose.
> 
> All of those packages were built in Koji.
> I wasn't talking about any custom builds. (since custom builds can't
> be added anyhow to Koji, right?)
> 
> That means - it (the icu 63) was in the repository at the build time
> of the community-mysql, but wasn't later at install time.
> Wizardy? Untagged buiid?

  I saw exactly this on Monday. I submitted a build of owfs package,
which immediately failed with
  DEBUG util.py:490:  BUILDSTDERR:   - nothing provides gcc = 8.69 needed by 
annobin-8.69-2.fc30.x86_64

 Strange thing was, annobin-8.69-2.fc30.x86_64 has been built only _2 hours_
before my build.  How it got to be in buildroot – it's a mystery…

-- 
Tomasz Torcz   RIP is irrevelant. Spoofing is futile.
xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


Re: F30: Self-Contained Change proposal: Firefox Wayland By Default On Gnome

2019-01-25 Thread Tomasz Torcz
On Fri, Jan 25, 2019 at 09:43:32AM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Firefox_Wayland_By_Default_On_Gnome
> 
> == Summary ==
> Firefox is going to run natively on Gnome Wayland session and won't
> use XWayland/X11 Gtk+ backend. This change affects Gnome only and
> won't be enabled for other Wayland compositors (KDE Plasma, Sway).


   Why not others?

-- 
Tomasz TorczOnce you've read the dictionary,
xmpp: zdzich...@chrome.pl   every other book is just a remix.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org


  1   2   3   4   5   >