Re: FESCo wants to know what you use i686 packages for

[Mauricio Tavares]

On Wed, Mar 16, 2022 at 9:54 AM David Cantrell  wrote:
>
> Hi,
>
> Our most recent FESCo meeting involved discussing the proposal to drop i686
> builds of jdk8,11,17 from Fedora 37 onward.  The topic quickly changed to the
> larger question of "what do people use i686 packages for?"
>
> Rather than guess, we wanted to ask the community what you use i686 packages
> for in Fedora.  There are no wrong answers here.  We are seeking information.
>
> Why?  Since the removal of the i686 kernel in Fedora, we want to reduce the
> number of i686 packages provided in the repo.  As time marches on, the ability
> to build a lot of things for i686 becomes unrealistic or even impossible.
> Remember it goes beyond providing builds...providing support, bug fixes, and
> security fixes for those packages too.  Maybe some things using i686 packages
> now can move to x86_64 packages.  We do not know yet, but a goal is to figure
> out what packages, if anything, can drop their i686 builds.
>
> NOTE: Nothing is changing now.  We are in an information gathering phase.
>   
>
> If you use i686 packages for something now, please respond to this thread.
>
  I use it because research on certain network controllers
requires it. But, I can move said research to Debian so it is not a
blocker to me.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Linux Plumbers Conference - Open Printing Micro Conference

[Mauricio Tavares]

On Tue, Sep 21, 2021 at 8:12 AM Björn Persson  wrote:
>
> Zdenek Dohnal wrote:
> > the schedule for the first no-driver was proposed
>
> What is a no-driver?
>
  I guess some kind of abstraction at the device level so the way
you talk to it is the same as any other device. In other words, the
translation layer a driver does is moved to the device.

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

Re: I think we should stop building i686 packages we're not shipping

[Mauricio Tavares]

On Wed, Sep 1, 2021 at 4:47 AM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Wednesday, 01 September 2021 at 10:01, Vitaly Zaitsev via devel wrote:
> > On 31/08/2021 18:53, Matthew Miller wrote:
> > > This is an off-shoot thought of the 32-bit ARM conversation. Right now, we
> > > build stuff like libreoffice for i686, but then (mostly) don't ship it.
> > > This seems like a waste of resources and time.
> >
> > +1. We should only build selected packages for multilib support (Steam,
> > Wine).
>
> That's not enough. As mentioned elsewhere in the thread, we need the
> whole build environment built for i686, including all BuildRequires:.
>
> Also, there are tons of old closed-source i686-only games that depend on
> i686 libraries other than Wine or Steam.
>
  If Fedora aims at running only on x86_64 and 32-bit ARM, this
may be the right time to plan the best way to clean it by purging
antiquated 32-bit ARM and i686 code from it. Old close-source i686
games can run in some emulation; they were designed to run on much
less powerful CPUs anyway.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Just say "No!" and do not document GRUB2 anymore!

[Mauricio Tavares]

On Thu, May 27, 2021 at 7:02 AM e  wrote:
>
> On Thu, 27 May 2021 12:54:31 +0200  astoundingly,   Vitaly Zaitsev via devel
>  wrote:
>
> > On 27.05.2021 12:30, Mauricio Tavares wrote:
> > > Support for other OS for those who like/need to dualboot?
> >
> > Yes. For example you can press "W" to start Windows directly.
> >
> > Also native UEFI Boot allows multiple bootloaders.
>
> But what has M$ ever done for us Linux people? Nothing!
>
  If that is how you feel, propose to remove Samba and
FAT*/vfat/whatever filesystem support off fedora and tell freeIPA to
stop trying to make it behave as an AD server.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Just say "No!" and do not document GRUB2 anymore!

[Mauricio Tavares]

On Thu, May 27, 2021 at 6:27 AM Vitaly Zaitsev via devel
 wrote:
>
> On 27.05.2021 12:13, Sérgio Basto wrote:
> > why systemd-boot is better ?
>
> 1. Not a bootloader.
> 2. Very simple and clean.
> 3. Starts Linux kernel directly with EFIStub without any bootloaders.
> 4. Can be used with XBOOTLDR[1] on any FS, supported by your hardware[2].
> 5. Has full BLS support.
>
> Links:
> [1]: https://systemd.io/BOOT_LOADER_SPECIFICATION/
> [2]: https://github.com/pbatard/efifs
>
  Support for other OS for those who like/need to dualboot?
  Cutting date for hardware that supports it?
> --
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Just say "No!" and do not document GRUB2 anymore!

[Mauricio Tavares]

On Thu, May 27, 2021 at 5:49 AM e  wrote:
>
> sounds unintuitive, but he just speaks truth to power:
>
> https://pagure.io/fedora-docs/quick-docs/issue/352#comment-734630
>
> "I think the GRUB stuff is so esoteric, so conditional and overly 
> complicated, that we shouldn't
> explain it. Explaining it will take a lot of resources, and then it has to be 
> maintained or it
> goes stale again. So when in doubt, just say no and don't document it"
>
> Then goes on to make a strong argument!
>
  If you do not like it, don't use it. Campaign your replacement
of choice and see if you can make it get adopted and grub2 retired.
Campaigning against it being documented is pushing to have it cancel
cultured. There is nobody putting a gun on the head of those
documenting it; it is open source maintained by volunteers.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Reducing noise on devel list

[Mauricio Tavares]

On Tue, Dec 15, 2020 at 12:18 PM Robbie Harwood  wrote:
>
> Vít Ondruch  writes:
>
> > I have setup filter ages ago and it moves such emails into subfolder. I
> > still think this is preferable to moving them into different ML.
>
> I would like to disagree with the idea that everyone needing to create
> their own filtration is preferable to putting them on a separate list.
>
  So giving people the option to decide what to do with their
emails is less preferable than having 4-5 people decide for every
single subscriber?

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

Re: Proposal: drop "Test installation media" from live media

[Mauricio Tavares]

On Fri, Dec 11, 2020 at 5:20 PM Matthew Miller  wrote:
>
> On Sat, Dec 12, 2020 at 12:15:07AM +0200, Nikolay Nikolov wrote:
> > there's even less reason to skip it. Which really begs the question,
> > why do we even assume the media test is only useful for DVD and not
> > for USB flash?
>
> I gave those reasons in my initial message? Have you experienced a
> specific case where bad USB media caused a corrupt install?
>
  If by corrupt install you mean the fedora install froze after
USB booted and before it told the install was successful, yes. Like
early this year (so I guess it is too far in the past to be relevant
to this discussion). Interestingly enough I then dd'ed ubuntu -- just
needed to test hardware so any distro with the latest kernel would do
-- in it because I thought it was a hardware incompatibility issue and
it worked well enough to finish my tests.

If you mean install was deemed successful but then it would not work, no.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: Proposal: drop "Test installation media" from live media

[Mauricio Tavares]

On Fri, Dec 11, 2020 at 1:08 PM Matthew Miller  wrote:
>
> Right now, when you start Fedora live media to install Workstation or KDE or
> etc., you get an ugly text prompt which defaults to doing a media test
> (although it's not actually even clear from the highlighting that that's the
> default).
>
> I think since burning spinning optical media is no longer the normal way to
> do this, we should drop this and just go straight to booting (unless of
> course a key is hit to stop things and enter boot parameters).
>
> In my experience with USB sticks (and i've probably made over 500 of 'em in
> the last few years), the most likely failure modes are like this:
>
> 1) Doesn't even write properly.
> 2) Doesn't boot after you created it.
> 3) Fails hard and it's definitely done
> 4) Random transient errors
>
> The test media option doesn't actually help with any of these except maybe
> making #3 happen slightly sooner. With #4, it actually means that in some
> cases you'd be fine just doing the install and the test fails.
>
> Let's just go ahead and get people started faster.
>
  I thought you could either bypass or cancel the installation media test.

> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Mauricio Tavares]

On Thu, Sep 10, 2020 at 7:38 AM Neal Gompa  wrote:
>
> On Thu, Sep 10, 2020 at 7:33 AM Richard Hughes  wrote:
> >
> > On Thu, 10 Sep 2020 at 10:17, Tom Hughes  wrote:
> > > > Speaking from personal experience, I've wasted days over the last
> > > > decade trying to debug a locally installed system service that was not
> > > > working where there were no messages in any of the logs (e.g. no AVCs)
> > > > -- and turning off selinux at runtime magically fixed the problem.
> > >
> > > Some selinux rules are marked to not generate AVCs...
> >
> > Why!? There's sometimes no log output anywhere obvious that a syscall
> > or something was blocked. It's the reason I turn off selinux on my
> > work development machine, and I've often wasted *hours* of my life on
> > code "doing something impossible" over the last decade until a neuron
> > at the back of my brain remembers "you've not yet turned off selinux"
> > and then when I "sudo setenforce 0" it works, and I can't actually
> > file a bug as there's no indication of what selinux actually blocked
> > or why.
> >
>
> Because Red Hat customers put the SELinux policy developers into
> no-win situations: they complain about AVC denials that don't actually
> significantly break anything in *their* app and often just disable
> SELinux in those scenarios. Red Hat wants customers to use it and not
> freak out all the time, so these kinds of things get added because it
> is very hard to come up with the right rules for all cases and there's
> not enough time to work on that.
>
> (I know for a fact that more than a few dontaudit rules were the
> result of those kinds of conversations, because I witnessed them)
>
  Stupid question: if the audit just reports selinux barked but it
did not block, why completely block the reporting? Because customers
were freaking out about the entries in the audit log itself?
___
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

[Mauricio Tavares]

On Fri, Sep 4, 2020 at 7:48 AM Tomasz Torcz  wrote:
>
> 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 think that has to do with service agreements between the
provider and its customers, and the expectation that if provider is
made aware of a violation of one of its customers, it will cooperate
with (say EU) . Otherwise, the provider would have to be scanning the
contents of every single of its customers at all the times, which then
can in itself become a GDPR violation.

Take google for example: as I type this reply it is highlighting what
it considers to be spelling and grammatical errors as I type. That
means it is reading everything I am typing right now and probably
storing it somewhere to (at very least) improve its algorithm, and
more. If I have a file in google drive, chances are it is being
scanned. This is fundamentally different than just hosting the data
and not interfering with customer besides ensuring said customer is
not hogging the resources.

> 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.
>
  Also the wording on GDPR's regulations is intentionally vague.
CCPA is but an American/Californian response to GDPR but not as aimed
at protecting the individual since

1. The CCPA applies to any business which does business in California
(including data brokers), that satisfies at least one of the
thresholds :
1.1 Has annual gross revenues in excess of $25 million;
1.2. Buys, receives, or sells the personal information of 50,000 or
more consumers or households; or
1.3. Earns more than half of its annual revenue from selling
consumers' personal information.
1.4. Provides an opt-OUT *right* for sales of personal information
versus opt-IN *necessity* for GDPR


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

[Mauricio Tavares]

On Sat, Jul 4, 2020 at 11:30 AM Lennart Poettering  wrote:
>
> On Mi, 01.07.20 22:10, Neal Gompa (ngomp...@gmail.com) wrote:
>
> > This could still work. But you really shouldn't accept butt-ugliness
> > from any user-facing technology, even sd-boot.
>
> Dude, maybe what is "butt-ugly" and what isn't is in the eye of the
> beholder, and maybe if you want to spend the day watching at your
> pretty boot loader then you have a somewhat exotic desire.
>
> sd-boot is really designed to stay out of the view as much as
> possible. It's UI (which was proposed by some GNOME designers back in
> the day, as mentioned) is supposed to never show except when it really
> has to. It's not a UI you spend time in.
>
> sd-boot is designed so that it passed as much information to the OS
> about its context, about boot menu items and such as possible, and it
> takes commands from the OS too. it does this, so that OS UIs (and not
> boot loader UIs) are the primary way to choose what to boot
> into. i.e. a pre-boot UI for selecting if you want to boot into
> Windows, MacOS, or some Linux version is always going to be terrible,

  So, sd-boot would only support some Linux OS as it relies on the OS UI?

> and being able to pick where to boot into from the desktop UI is a
> always a much better UI (with mouse, with touch, with pretty graphics)
> then the pre-boot UI could ever have.
>
> It's a substantially diffrent focus: Grub wants to be an OS itself,
> have fs drivers, have a UI, have modules, drivers what not. It's Grub
> in the center of everything, that is in control and decides what to
> do. sd-boot tries hard to not be all that, it has little UI, has a lot
> of automatism, little configuration, and a lot of integration, so that
> you drive it from the OS, and as little possible have to interface
> with its own UI as you can. If you want to reboot into Windows then
> you tell sd-boot so when shutting down, i.e. in the OS UI.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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.

[Mauricio Tavares]

On Tue, Jun 30, 2020 at 2:39 PM Tom Seewald  wrote:
>
> > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
> > it beg the question if now would not be the time to stop supporting
> > booting in legacy bios mode and move to uefi only supported boot which
> > has been available on any common intel based x86 platform since atleast
> > 2005.
> >
> > Now in 2017 Intel's technical marketing engineer Brian Richardson
> > revealed in a presentation that the company will require UEFI Class 3
> > and above as in it would remove legacy BIOS support from its client and
> > datacenter platforms by 2020 and one might expect AMD to follow Intel in
> > this regard.
> >
> > So Intel platforms produced this year presumably will be unable to run
> > 32-bit operating systems, unable to use related software (at least
> > natively), and unable to use older hardware, such as RAID HBAs (and
> > therefore older hard drives that are connected to those HBAs), network
> > cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
> > before 2012 – 2013) etc.
> >
> > This post is just to gather feed back why Fedora should still continue
> > to support legacy BIOS boot as opposed to stop supporting it and
> > potentially drop grub2 and use sd-boot instead.
> >
> > Share your thoughts and comments on how such move might affect you so
> > feedback can be collected for the future on why such a change might be
> > bad, how it might affect the distribution and scope of such change can
> > be determined for potential system wide proposal.
> >
> >
> > Regards
> >
> >   Jóhann B.
> >
> >
> > 1.
> > https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
>
> The primary areas of concern I have about Fedora dropping grub2 and BIOS boot 
> support are:
>
> 1. Users that are on systems that do not support UEFI, or that knowingly (or 
> unknowingly) use BIOS boot on UEFI-capable systems.
>
> These people are likely to form a lasting negative impression of Fedora, as 
> removing BIOS boot support would ostensibly mean that Fedora no longer runs 
> on their systems (at least as configured). I have heard that the UEFI 
> implementations on some (typically older) motherboards can be buggy, so many 
> users may have a legitimate reason to still use BIOS boot on boards that 
> advertise support for both.
>
> 2. How would dropping grub2 affect users that boot multiple operating systems?
>
> What manual steps, if any, would users need to take if they were previously 
> using grub2 to support booting multiple operating systems. Would this change 
> break existing multi-boot setups?

  What would happen if some of those multiple operating systems do
not support UEFI for whatever reason?
>
> 3. Virtual machines typically default to BIOS boot.
>
> It's my understanding that libvirt, Virtual Box, Hyper-V (gen1 VMs only?), 
> and many cloud providers default to using BIOS boot when creating virtual 
> machines. If Fedora no longer works *by default* with common virtualization 
> stacks I'd imagine many users will simply choose to no longer run or 
> recommend Fedora.

  I think this is a place to handhold user, not to tell, say,
libvirt it should drop BIOS boot altogether like others in this thread
suggested.

> 4. Support documentation for sd-boot
>
> Would this result in changes to how users access the boot menu, select a boot 
> entry, or edit the kernel command line, etc? These actions of course aren't 
> expected to be common but when they are needed it tends to be when a user is 
> already experiencing problems and is under stress. Therefore if there are 
> changes, hopefully these will be clearly documented to avoid confusion.
>
> 5. What does Fedora gain by dropping BIOS boot support?
>
> Perhaps it is obvious to others, but I think it is worth fully spelling out 
> what the expected benefits are. This would help everyone more clearly see the 
> trade-offs of this change.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: Make nano the default editor

[Mauricio Tavares]

I am reading this thread and seeing a lot of "this will make it easy
on end users" and "this will piss developers off." How many?  Who?
Without data to back those statements they are just examples of
hyperbole built upon personal beliefs.
___
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 F31 to F32

[Mauricio Tavares]

On Wed, Mar 4, 2020 at 10:25 AM Miroslav Suchý  wrote:
>
> Do you want to make Fedora 32 better? Please spend 1 minute of your time and 
> try to run:
>
>   # Run this only if you use default Fedora modules
>   # next time you run any DNF command default modules will be enabled again
>   sudo dnf module reset '*'
>
>   sudo dnf --releasever=32 --setopt=module_platform_id=platform:f32 \
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> distro-sync
>
> This command does not replace `dnf system-upgrade`, but it will reveal 
> potential problems. You may also run `dnf
> upgrade` before running this command.
>
>
> 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 actual upgrade.
>
> But very likely you get some dependency problem now. In that case, please 
> report it against the appropriate package. Or
> against fedora-obsolete-packages if that package should be removed in Fedora 
> 32. Please check existing reports first:
> https://red.ht/2kuBDPu
>
> Thank you
>
  I did not get any errors (stopped before letting it do the
update), but I would like to know why it does it want to downgrade two
packages:

[root@localhost ~]# sudo dnf module reset '*'
Last metadata expiration check: 1:35:23 ago on Wed 04 Mar 2020 09:09:41 AM EST.
Dependencies resolved.
Nothing to do.
Complete!
[root@localhost ~]#   sudo dnf --releasever=32 --setopt=module_platform_id=platf
orm:f32 \
> --enablerepo=updates-testing --enablerepo=updates-testing-modular \
> distro-sync
Fedora Modular 32 - x86_64  1.8 MB/s | 4.9 MB 00:02
Fedora Modular 32 - x86_64 - Updates599  B/s | 257  B 00:00
Fedora Modular 32 - x86_64 - Test Updates   350 kB/s | 472 kB 00:01
Fedora 32 - x86_64 - Test Updates   1.8 MB/s | 4.8 MB 00:02
Fedora 32 - x86_64 - Updates336  B/s | 257  B 00:00
Fedora 32 - x86_64  6.4 MB/s |  68 MB 00:10
Dependencies resolved.

 Package   Arch   Version Repository   Size

Installing:
 kernelx86_64 5.6.0-0.rc3.git0.1.fc32 fedora   18 k
 kernel-core   x86_64 5.6.0-0.rc3.git0.1.fc32 fedora   32 M
 kernel-modulesx86_64 5.6.0-0.rc3.git0.1.fc32 fedora   29 M
[...]
Removing:
 kernelx86_64 5.3.7-301.fc31  @anaconda 0
 kernel-core   x86_64 5.3.7-301.fc31  @anaconda67 M
 kernel-modulesx86_64 5.3.7-301.fc31  @anaconda28 M
Downgrading:
 bsdtarx86_64 3.4.0-2.fc32fedora   65 k
 libarchivex86_64 3.4.0-2.fc32fedora  388 k

Transaction Summary

Install 16 Packages
Upgrade463 Packages
Remove   3 Packages
Downgrade2 Packages

Total download size: 425 M
Is this ok [y/N]: n
Operation aborted.
[root@localhost ~]#

> --
> Miroslav Suchy, RHCA
> Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
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: FreeCAD required updates (PySide2 & Coin4)

[Mauricio Tavares]

Stupid question: does FreeCAD have nightly packages (like openscad)?
If so, how complicate would it be to run the coin4 version there for a
while so people can monkey with it and find issues? Then give some
time; if it seems to work happy, make it production.

Just my two pesos Russos.
___
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: Orphaned packages to be retired (~400 during this week)

[Mauricio Tavares]

On Mon, Sep 9, 2019 at 9:44 PM Adam Williamson
 wrote:
>
> On Tue, 2019-09-10 at 02:41 +0200, Kevin Kofler wrote:
> > Miro Hrončok wrote:
> > > openvswitch  aconole, chrisw, orphan, 0 weeks ago
> > >  tgraf, tredaell
> >
> > This one is a dependency of NetworkManager, so surely it should not go away.
> > (Or is the plan to drop support for it from NM?) So can either one of the
> > existing comaintainers or the NM team please pick this up before some script
> > retires the entire distro? :-)
>
> openQA also requires it, so I need it not to go away. I don't really
> want to maintain it as I'm certainly no kind of SDN expert, but if no-
> one else picks it up I probably will in the end.

  I too am also no SDN expert; in fact, I consider myself a
grasshopper. I also never been a maintainer. However, I am willing to
help in any way I can if someone can teach me the ropes.  Would that
make your life a bit easier?

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 31 System-Wide Change proposal: Disable Root Password Login in SSH

[Mauricio Tavares]

On Fri, May 17, 2019 at 8:24 AM Stephen Gallagher  wrote:
>
> On Thu, May 16, 2019 at 2:54 PM Ben Cotton  wrote:
> >
> > https://fedoraproject.org/wiki/Changes/DisableRootPasswordLoginInSshd
> >
> > == Summary ==
> > The upstream OpenSSH disabled password logins for root back in 2015.
> > The Fedora should follow to keep security expectation and avoid users
> > surprises with this configuration.
> >
> > == Owner ==
> > * Name: [[User:jjelen| Jakub Jelen]], OpenSSH maintainer
> > * Email: jje...@redhat.com
> >
> > == Detailed Description ==
> >
> > The OpenSSH server configuration contains a configuration option
> > `PermitRootLogin`, which controls whether the root user is allowed to
> > login using passwords or using public key authentication. The root
> > login is target of most of the random or targeted attack on Linux
> > systems and password is usually the weakest part. For that reason, the
> > upstream OpenSSH changed this option in 2015 to `prohibit-password`,
> > which still allows public-key authentication, but prevents the
> > password logins. Fedora was for many practical reasons keeping the old
> > configuration since then, but the difference is no longer bearable and
> > might confuse users expecting the root logins will not be enabled out
> > of the box.
> >
> > On the other hand, there is still a lot of infrastructure, installers
> > and test instances that simply might depend on this configuration and
> > therefore this change needs to go through the system-wide change so
> > everyone is onboard.
> >
> > == Benefit to Fedora ==
> >
> > This will provide more secure Fedora installations out of the box and
> > prevent inadvertently accessible root logins in the wild.
> >
>
> I'm not particularly *opposed* to this change in behavior, but in the
> Fedora Server case, SSH is the primary mechanism for gaining access to
> the system. If we disallow password logins for root, then many
> installs will be inaccessible and users will get... grumpy.
>
> There aren't really any major problems for interactive installs where
> the user has direct console access, so I'll disregard that case for
> the moment. For kickstart-based installs, I suppose users would
> normally know to put their SSH public keys in place, so that's also
> less of a concern.
>
> The problematic case I see is the remote VNC headless install. The
> installation is interactive, but there may not be a way to gain direct
> access to the installed system after that. We need to ensure that the
> resulting system is always accessible. Right now, the interactive
> installer would allow us (even encourage us) to set up that machine
> with only a root user and password, which after this Change would mean
> that the system is not reachable.
>
> I see some possible options here, all requiring Anaconda changes:

  What would be the fail-safe setting if any?

> 1) Provide a checkbox in the root user creation spoke (defaulting to
> "off") to enable root password logins over SSH. Ideally with notes
> about why it's recommended not to do this.

  Which could be shown in a popup "Do you really want to do this?"
 window of sorts.

> 2) Allow users to provide a public SSH key for the root user. Since
> this is generally not performed in an environment where the keys can
> be copy-pasted, we'd probably need to allow specifying a [tiny]URL for
> an authorized_keys file.

  Or pipe it using netcat/something.

> 3) Force Anaconda to require the creation of a non-root user that is a
> member of the `wheel` group, so that this user can be used to SSH in
> and administer the system. Essentially, remove the root user creation
> spoke as an option from the interactive install.

  That seems similar to the approach adopted by ubuntu and it has
worked. With that said, I do not see the difference between ssh'ing
using an user in the wheel group vs root as both can do the same. But
that is me. Being able to tell who sudo'ed, yes.

> 4) Force Cockpit to be installed and available on any system that
> doesn't select a non-root user at installation time. This will allow a
> password-based login and allows the root user to set up their SSH keys
> via the "Accounts" tab.
>
> I'm all for hearing what other options we may have here, but those are
> the simplest ones I can think of.
> ___
> 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
___
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: 

Re: No i686 build of grub2?

[Mauricio Tavares]

I think I read here (or in other mailing list) about an interest in
dropping 32bit altogether. But this might be just my imagination.

On Wed, Aug 23, 2017 at 8:27 AM, Bruno Wolff III  wrote:
> Currently grub2 isn't being built for i686 since somewhere between 2.02-8
> and 2.02-10.
> I looked through the change log (but not the git log yet) and didn't see
> anything mentioning this, which I would have expected if it was an
> intentional change.
> So is this a new permanent feature going forward or a temporary oops?
> (I still have one machine I use regularly, that only runs i686 and it will
> probably be a while before I can afford to replace it.)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: BTRFS dropped by RedHat

[Mauricio Tavares]

On Fri, Aug 4, 2017 at 11:48 AM, Neal Gompa  wrote:
>
> I'm not particularly pleased with their decision. I think the path
> they're going down is wrong, and they should really reconsider.
> However, I'm reading over their Stratis whitepaper before I formulate
> a response about it.
>
> I don't think they fully understand how the Stratis path cannot
> replace what Btrfs gives you, and the irony about this is that the
> Btrfs developers been working on fixing the major remaining issues
> with RAID this year and it looks like it'll be much better next year.
>
> All of my CentOS 7 servers (and my one RHEL 7 box) use Btrfs, because
> it's so much better than the alternatives.
>
  Better than ZFS?
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Urgent call for testing: OS X dual boot

[Mauricio Tavares]

How old can the OSX box be? I have in a box an old Mac mini (Dual core
and can only officially supported to 10.7) I have no issues to put to
service.

On Thu, Nov 10, 2016 at 11:05 AM, Adam Williamson
 wrote:
> Hi, folks! We've had an F25 blocker proposed for failure to install as
> a dual boot with OS X:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1393846
>
> is there anyone who has an OS X system they can run this kind of test
> on (i.e. one they don't mind getting messed up if something goes
> wrong)? We would like more testing data so we can figure out if this is
> a system-specific issue or if all OS X dual boot is broken.
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Fixing the "nobody" user?

[Mauricio Tavares]

On Mon, Jul 18, 2016 at 8:39 AM, Lennart Poettering
 wrote:
> Heya!
>
> I'd like to start a discussion regarding the "nobody" user on Fedora,
> and propose that we change its definition sooner or later. I am not
> proposing a feature according to the feature process for this yet, but
> my hope is that these discussions will lead to one eventually.
>
> Most distributions (in particular Debian/Ubuntu-based ones) map the
> user "nobody" to UID 65534. I think we should change Fedora to do the
> same. Background:
>
> On Linux two UIDs are special: that's UID 0 for root, which is the
> privileged user we all know. And then there's UID 65534
> (i.e. (uint16_t) -2), which is less well known. The Linux kernel calls
> it the "overflow" UID. It has four purposes:
>
> 1. The kernel maps UIDs > 65535 to it when when some subsystem/API/fs
>only supports 16bit UIDs, but a 32bit UID is passed to it.
>
> 2. it's used by the kernel's user namespacing as a the internal UID
>that external UIDs are mapped to that don't have any local mapping.
>
> 3. It's used by NFS for all user IDs that cannot be mapped locally if
>UID mapping is enabled.
>
> 4. One upon a time some system daemons chose to run as the "nobody"
>user, instead of a proper system user of their own. But this is
>universally frowned upon, and isn't done on any current systems
>afaics. In fact, to my knowledge Fedora even prohibits this
>explicitly in its policy (?).
>
> The uses 1-3 are relevant today, use 4 is clearly obsolete
> afaics. Uses 1-3 can be subsumed pretty nicely as "the UID something
> that cannot be mapped properly is mapped to".
>
> On Fedora, we currently have a "nobody" user that is defined to UID
> 99. It's defined unconditionally like this. To my knowledge there's no
> actual use of this user at all in Fedora however. The UID 65514
> carries no name by default on Fedora, but as soon as you install the
> NFS utils it gets mapped to the "nfsnobody" user name, misleadingly
> indicating that it would be used only by NFS even though it's a much
> more general concept. I figure the NFS guys adopted the name
> "nfsnobody" for this, simply because "nobody" was already taken by UID
> 99 on Fedora, unlike on other distributions.
>
> In the context of user namespacing the UID 65534 appears a lot more
> often as owner of various files. For example, if you turn on user
> namespacing in typical container managers you'll notice that a ton of
> files in /proc will then be owned by this user. Very confusingly, in a
> container that includes the NFS utils all those files actually show up
> as "nfsnobody"-owned now, even though there's no relation to NFS at all
> for them.
>
> I'd like to propose that we clean this up, and just make Fedora work
> like all other distributions. After all the reason of having this
> special UID in the first place is to sidestep mapping problems between
> different UID "realms". Hence I think it would be wise to at least
> make the name of this very special UID somewhat more stable and
> well-defined between distributions.
>
> I think this is of particular relevance as Debian/Ubuntu-based
> container images tend to be substantially more popular than
> Fedora-based ones, and hence I think we should try to unify at least
> the names and semantics of the two special UIDs all distros have, to
> minimize mapping problems and making user interaction in containers a
> bit more friendly.
>
> You might ask of course, why Fedora should change to adopt
> Debian's/Ubuntu's definition, instead of conversely making them adopt
> Fedora's definition? Well, that's simple: Debian's definition makes a
> lot more sense than Fedora's. And nothing we ship actually makes use
> of FEdora's definition afaics, and we currently carry a workaround
> called "nfsnobody" in some cases to avoid having to fix this properly.
>
> Another option would be to define an entirely new user name for 65534,
> for example "void" or so. But quite frankly, that sounds like a
> pointless bikeshedding excercise, and creates even more confusion,
> balkanization and political hassles if you'd try to convince other
> distros to adopt the same scheme too.
>
> Hence, let's go for "nobody == 65534" on Fedora too! And let's unify
> the various dsitributions a tiny bit more, on this specific aspect.
>
> How could a transition look like? I figure new installs should get
> "nobody" defined to 65534. Old installs should keep the old
> definitions in place instead. The NFS packages should be updated to
> not create the "nfsnobody" user if there's already another user mapped
> to 65534 (maybe it already does that?). Of course it's not pretty if
> old and new systems use different definitions for this user, but I
> think it's not too much of a real-life issue, as most code that refers
> to this group already does so by UID instead of name, simply because
> the name is not stable across distributions.
>
> Opinions?
>
  Not an opinion but some 

Re: Is systemd within a Docker container still recommended?

[Mauricio Tavares]

On Mon, Mar 2, 2015 at 9:42 AM, Lennart Poettering mzerq...@0pointer.de wrote:
 On Mon, 02.03.15 09:17, Daniel J Walsh (dwa...@redhat.com) wrote:


 On 03/01/2015 10:41 PM, Michael DePaulo wrote:
  Hi,
 
  I am developing a Dockerfile for X2Go. I intend to submit a PR to
  fedora-Dockerfiles within a week.
 
  https://github.com/mikedep333/Fedora-Dockerfiles/tree/add-x2go
 
  (X2Go was already added in F20)
  https://fedoraproject.org/wiki/Changes/X2Go
 
  Example Dockerfile with systemd:
  https://github.com/fedora-cloud/Fedora-Dockerfiles/blob/master/systemd/apache/Dockerfile
 
  However, I would like to know if the Fedora project still recommends
  that I use systemd, or if I should resort to using supervisord or a
  shell script.
 
  I merely need to start sshd and x2gocleansessions. Both have systemd
  unit files, but can be run via an init script too.
 
  When I do try systemd, I am experiencing known issues with cgroups and
  with mounting /run, unless I run a privileged container. It has been a
  while since there were any comments on the CLOSED NOTABUG bz on these
  issues.
  https://bugzilla.redhat.com/show_bug.cgi?id=1033604
 
  -Mike
 We are continuing to work on making running systemd within a container
 better.
 I am trying to get a /run on tmpfs patch to be acceptable upstream.  But
 we still
 have a problem with systemd requiring /sys/fs/cgroup to be mounted
 inside the container
 to run.  Which allows for an information leak.

 You'd have to get the kernel changed for that information leak to be
 fixed.

 That said, containers on Linux are not really about security, the
 whole thing has more holes than a swiss cheese. Maybe one day the
 security holes can be fixed, but as of now, it's simply not
 secure. And this information leak is certainly the least of your
 problems...

  What would then be the recommended solution if containers are insecure?

 Lennart

 --
 Lennart Poettering, Red Hat
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: an that is why we need a firewall - Re: When a yum update sets up an MTA ...

[Mauricio Tavares]

On Mon, Apr 21, 2014 at 3:42 AM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 21.04.2014 03:39, schrieb Lars Seipel:
 Nicely aligning with the current firewall thread I noticed that one of
 my machines was running the exim MTA for the last few days, dutifully
 listening on all interfaces

 and now it is *proven for sure* that disable the firewall
 by default is the most dumb thing a distribution can do

 drago01 will now say again that is a bug
 yes, in that case in *two* packages at the same time
 but hwat matters is the impact of a bug

 * smartmontools wanted sendmail instead MTA for sending sysmessages
 * sendmail obviously has a braindead default configuration listening on all 
 ports
 * sendmail service is obviously enabled at install time even if smartmontools
   only need /usr/sbin/sendmail

 all things i said that they are happening and will happen again and again
 while they get fixed here and there - again and again - that's life

 so you can run in circles and shout that is a bug which is
 true and while you are fix it it brings people in trouble
 or you have by default a security layer which hopefully does
 not open port 25 automated because you install sendmail

 the next problem: even if such a bug is fixed the affected users
 keep to be fucked because the updated smartmontools only require
 any MTA (which is correct) and so nothing will remove sendmail
 on that machines nor close port 25 after a update of smartmontools

  If all smartmontools need is to just send emails out, I would
suggest using something like ssmtp or msmtp.

 https://koji.fedoraproject.org/koji/buildinfo?buildID=511458
 * Thu Apr 17 2014 Michal Hlavinka mhlav...@redhat.com
  - 1:6.2-5 - require /usr/sbin/sendmail as MTA is not provided by all 
 packages (#1048618)
 * Tue Apr 15 2014 Michal Hlavinka mhlav...@redhat.com
  - 1:6.2-4 - use MTA instead of sendmail as a requirement (#1048614)
 * Thu Apr 10 2014 Michal Hlavinka mhlav...@redhat.com - 1:6.2-3
  - add mail requires (#1048614)


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

Creating local repo

[Mauricio Tavares]

Could anyone point me to info on creating a local repo? I want to learn the
entire process of creating a package but think it might be wiser to have a
controlled environment
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Self Introduction: Mauricio Tavares

[Mauricio Tavares]

  What can I say about me? First of all, my goals to be here are
not as life-changing as many of you. I want to learn how to build and
test fendora/redhat packages. And then help keep some packages I like
(I am a selfish bastard) alive and maybe even updated. Perhaps help
deal with whatever issues they have.

Experience? Hmmm, not that much. I did a small part on the push to
fork firehol into sanewall, which as opposite to the former is being
actively and agressively worked on. I also sprinkled some lies and
misinformation in the ubuntu server docs. I might be doing something
in rsyslog, but probably nothing good or uplifting. Programming, well
I am not that good at it. I am frustrated by the lack of line numbers
and gotos in C and python and think java is too lightweight and perl
is not convoluted enough. But, give me enough time and my favourite
stone club and I get a few things done here and there.

Lastly, I tend to ask stupid questions... lots of them.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Fedora Server PRD Draft and call for participation

[Mauricio Tavares]

On Tue, Jan 21, 2014 at 3:42 PM, Bill Nottingham nott...@redhat.com wrote:
 Stephen Gallagher (sgall...@redhat.com) said:
 The first deliverable that the Fedora Server Working Group was tasked
 with was the production of a Product Requirements Document. This
 document is intended to provide a high-level view of the goals and
 primary deliverables of the Fedora Server distribution. A great deal
 of discussion has gone on during the weekly Working Group meetings as
 well as on the mailing list.

 Admittedly late, but...

 Vision

 Fedora Server is the preferred [community] platform for system
 administrators and developers seeking to deploy applications and services
 that use the latest technology on a stable foundation with effective
 resource utilization.

 How does this differentiate from the market position of CentOS (community
 platform for deploying apps and services on a stable platform)? Do we care
 if it doesn't?

  I always thought that

Fedora:
o bleeding edge, where new stuff comes
o new programs/kernels/drivers
o Expect things might not be work or last
o Versions change as fast as in ubuntu, if not faster
o Trendsetter for RHES and CentOS

RHES:
o Takes stuff that can be used in servers that survived baptism of
fire in Fedora
o Long term FTW!
o Slow changes, more security and patches

CentOS:
o Very very close to RHES, but by design 6 months behind it
o Open support, open community like Fedora
o More server related like RHES

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

Re: Orphaned packages up for grabs

[Mauricio Tavares]

On Wed, Jan 15, 2014 at 8:54 PM, Casper fan...@fedoraproject.org wrote:
 Mauricio Tavares a écrit :
 On Tue, Jan 14, 2014 at 1:07 AM, Casper fan...@fedoraproject.org wrote:
  Kevin Fenzi a écrit :
  Greetings.
 
  The following packages have been orphaned due to their former
  maintainer removing themselves from the packager group:
 
  NetPIPE
 
  checkdns
  taken, co-maintainers welcome
 
   I might volunteer as a co-maintainer so I learn the ropes and
 act like I know what I am doing.
 Good to hear :)
 but your FAS account is not actually in the packager group, so you can't
 take co-maintainership for any package in the pkgdb.
 The first step to apply in this group is described here:

   https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

  Thank you for the link! And, sorry for taking so long to reply,
specially since only now I actually started reading it. So, let me
finish with that so I can then start asking stupid questions. ;)


 --
 Autorité de Certification: http://casperlefantom.net/root.pem
 Empreinte: 0975 864A 2036 0F94 A139  114A D32E 8EBE 30F2 2429

 Clef GPG ID: 83288189 @ hkp://keys.fedoraproject.org
 Empreinte: CC26 692F 5205 AC8F 7912  7783 D7A7 F4C5 8328 8189

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

Re: What to do about packaging beta, or rc as alternate installable

[Mauricio Tavares]

On Tue, Jan 21, 2014 at 8:58 PM, Christopher Meng cicku...@gmail.com wrote:
 Seriously, it's harmful to provide unstable packages to users.

  Still, it makes sense to have a place to beta test either the
package or the packaging (how to create a proper package?) itself.

 And I don't think Fedora has a long term support.


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

Re: Orphaned packages up for grabs

[Mauricio Tavares]

On Tue, Jan 14, 2014 at 1:07 AM, Casper fan...@fedoraproject.org wrote:
 Kevin Fenzi a écrit :
 Greetings.

 The following packages have been orphaned due to their former
 maintainer removing themselves from the packager group:

 NetPIPE

 checkdns
 taken, co-maintainers welcome

  I might volunteer as a co-maintainer so I learn the ropes and
act like I know what I am doing.

 pxe-kexec (epel5/6 only)

 Thanks,

 kevin



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


 --
 Autorité de Certification: http://casperlefantom.net/root.pem
 Empreinte: 0975 864A 2036 0F94 A139  114A D32E 8EBE 30F2 2429

 Clef GPG ID: 83288189 @ hkp://keys.fedoraproject.org
 Empreinte: CC26 692F 5205 AC8F 7912  7783 D7A7 F4C5 8328 8189

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

On the qemu-system-XXX packages

[Mauricio Tavares]

  It seems a lot of them were not created for EPEL 6 and 7 (see
https://apps.fedoraproject.org/packages/qemu-system-arm as an
example). I take that means the current maintainer is up to his nose
in projects. How can I be equal parts lazy ass and selfish SOB and
volunteer to be a co-maintainer to that family of packages?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct