Re: F35 Change: Third-party Software Mechanism (System-Wide Change proposal)

[Lars Seipel]

On Tue, Jun 29, 2021 at 04:24:58PM -0400, Ben Cotton wrote:

* We add a new page to GNOME Initial Setup that asks a single
question, *along the lines of*:
'''Enable Third Party Software repositories?''' 
☑ Access additional software from selected third party sources. Some
of this software is proprietary and therefore has restrictions on use,
sharing, and access to source code. 
[Find out 
more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_Repositories)
* If the user leaves the box checked, GNOME Initial setup runs
`fedora-third-party enable`.


Leaves the box checked? Either I'm misunderstanding or this contradicts
the remaining text which talks about "opt-in".
___
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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

[Lars Seipel]

On Thu, Apr 08, 2021 at 11:19:59AM -0400, Frank Ch. Eigler wrote:

Hey, it already is there in most tools, try it.

% export DEBUGINFOD_URLS=https://debuginfod.stg.fedoraproject.org/

and shortly all F32+ packages/versions/architectures will be debuggable
that way.


Really cool. Thanks for making it happen.
___
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: F35 Change proposal: Smaller Container Base Image (remove sssd-client, util-linux, shadow-utils) (Self-Contained Change)

[Lars Seipel]

On Thu, Apr 01, 2021 at 02:36:48PM -0400, Neal Gompa wrote:

Unless OpenShift and RKE recently changed so that containers can run
as root by default (as of yesterday, they didn't), this is solidly a
bad idea, since it makes it much more unintuitive to set up secure
containers conforming with the guidelines for these Kubernetes
platforms.


In my experience, containers trying to run stuff from shadow-utils in 
their entrypoint/startup scripts tend to be a reason for containers to 
*not* run on OpenShift/OKD without additional adjustments.


A related (and more common) issue are images that expect to run with a 
particular named user (or UID) determined during the build process 
(again, most likely created using shadow-utils).


I'm not familiar with Rancher but at least for OpenShift, I don't think 
the availability of shadow-utils is very useful. At run time, you can't 
use the shadow-utils at all and whatever you do with it during build 
time is unlikely to be helpful (and actively harmful more often than 
not) at run time when OpenShift assigns you an arbitrary UID.

___
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: F29 System Wide Change: Make BootLoaderSpec the default

[Lars Seipel]

On Fri, Jun 29, 2018 at 05:26:37PM -0400, Kyle Marek wrote:
> Kernel updates are different. You *have* to reboot in order to run the
> new kernel (except for security updates applied with kpatch) and a
> broken kernel has the potential to simply lock up without even launching
> /sbin/init, for example. In these situations, administrators have to
> manually reboot the machine. If this is the case, they can also pick the
> kernel they want to boot from the boot menu.
> 
> No amount of unattended failed-boot-check logic in the bootloader can
> run without user intervention when a broken kernel is still running/just
> sitting there.

Well, your sufficiently fancy update system could detect that the
machine is still not up again after $DURATION and use some hypervisor
API (if it's a VM) or the BMC (for metal) to kill and force-reboot it.

Theoretically, the boot loader might also program a watchdog device to
make something like the above possible on a single machine without all
the distributed systems coordination stuff.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/PLNKRHOPOQSQNCGW3N5RWBOWOBED3DJM/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Lars Seipel]

On Mon, Jun 25, 2018 at 03:17:53PM -0400, Kyle Marek wrote:
> On 06/25/2018 02:49 PM, Lennart Poettering wrote:
> > But it's useful for unattended systems in general, be it servers or
> > appliances: if a boot fails there generally should be a way to recover
> > the system through rebooting without manual interfering. Quite
> > frankly, it's quite surprising we haven't implemented anything like
> > that on Fedora/RHEL at all yet, as it's a major piece in making
> > unattended system updates less risky.
> 
> I'm still not a fan. I'm not convinced that an issue that is correctable
> by booting an old kernel could be caused by a system being left
> "unattended". Systems should never automatically reboot due to a kernel
> update, and kernel updates really should be given administrator
> attention simply *because* of the potential boot issues.

Why not? If the administrator can arrange for reliable automated updates
across machines (in a rolling fashion, stopping the process and
reverting to the previous version on update failures), why would she
want to baby-sit every single machine?

You probably don't want to do this if all you have is a single machine
but for fleets of mostly-interchangable servers (hosting VMs or
containers), doing it this way makes perfect sense *if* it is reliable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/KCRUEPF4BWDMOFD7A2QDFCBDI3BY6HEP/

Re: Frequently broken Rawhide/Branched composes

[Lars Seipel]

On Tue, Mar 06, 2018 at 04:47:49PM +0100, Pierre-Yves Chibon wrote:
> Sorry, just to be clear, what would have its own issues:
> - asking rawhide users to use distro-sync instead of update?
> - automatically have dnf detect it's running in rawhide and default to
>   distro-sync instead of update?

As distro-sync puts all packages back at the repo version, it can also
revert the installation of local rebuilds or bug fix builds
cherry-picked from Koji.

The latter has become pretty common for me in recent weeks, as the
persistent compose issues mean that packages may take a long time
to hit the repos.

Nothing that can't be worked around by judicious use of excludes, you
just have to be aware of it instead of blindly firing off a distro-sync.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Should we have a release manager for each release? (or, "who owns rawhide"?)

[Lars Seipel]

On Fri, Feb 16, 2018 at 12:14:39PM -0800, Adam Williamson wrote:
> On Fri, 2018-02-16 at 14:34 +0100, Vít Ondruch wrote:
> > I wish the compose process was more transparent. May be it is just me,
> > but I don't know where to start looking when I don't get the daily
> > compose report.
> 
> https://kojipkgs.fedoraproject.org/compose/
> 
> All composes initially happen there. Rawhide composes happen in the
> rawhide/ subdirectory. Branched happen in the branched/ subdirectory.
> Each compose directory contains logs. The usual process for debugging
> failed composes is to look at the pungi.global.log file, which usually
> indicates what the failed fatal task was, get the task ID or full task
> URL from that log, then go to Koji and look at the actual failed task
> and figure out what went wrong with it.

Thank you, Adam. That was super-helpful.

If I'm reading those correctly, all issues are due to live images,
container images or OSTree-related stuff. The composes seem to result
in perfectly fine netinstall images and they even appear to work.

Why do we block the whole Rawhide repo for weeks on that? If building
container images and OSTrees doesn't work in a reliable way, they
probably shouldn't be blocking repo composes. The failing spins
(Astronomy, PyClassroom, Mate, etc.) are already non-blocking, I
presume?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: make yum repo when we build things in koji

[Lars Seipel]

On Fri, Jan 19, 2018 at 10:53:30PM -0500, Dusty Mabe wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 
> 
> On 01/19/2018 10:39 PM, Reindl Harald wrote:
> > 
> > 
> > [harry@srv-rhsoft:~]$ cat /etc/yum.repos.d/koji.repo
> > [koji]
> > name=Koji Repo
> > baseurl=https://koji.fedoraproject.org/repos/f$releasever-build/latest/$basearch/
> > enabled=0
> > skip_if_unavailable=1
> > gpgcheck=0
> > sslverify=0
> 
> Thanks!
> I didn't know about this, but it's not exactly what I'm looking for because 
> that seems
> to includ everything that has been built. I'm looking more specifically for 
> just a repo
> with a particular rpm in it.

Use includepkgs in the repo definition?

> includepkgs Inverse of exclude, yum will exclude any package in the  repo.  
> that  doesn't  match  this
> list.  This  works  in  conjunction with exclude and doesn't override it, so 
> if you exclude=*.i386 and
> includepkgs=python* then only packages starting with python that do not have 
> an  i386  arch.  will  be
> seen by yum in this repo.

See yum.conf(5).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Shim update breaks booting (was: Fedora 27 compose report: 20170825.n.0 changes)

[Lars Seipel]

On Fri, Aug 25, 2017 at 08:24:59PM +, Fedora Branched Report wrote:
> Package:  shim-signed-13-0.2
> Old package:  shim-signed-0.8-10
> Summary:  First-stage UEFI bootloader
> RPMs: shim-aa64 shim-ia32 shim-x64
> Added RPMs:   shim-aa64 shim-ia32 shim-x64
> Dropped RPMs: shim
> Size: 2238688 bytes
> Size change:  1219336 bytes
> Changelog:
>   * Thu Mar 23 2017 Petr Šabata  - 0.8-9
>   - Re-enable dist tag for module builds
> 
>   * Tue Aug 22 2017 Peter Jones  - 13-0.1
>   - Initial (partially unsigned) build for multi-arch support on x64/ia32.
> 
>   * Thu Aug 24 2017 Peter Jones  - 13-0.2}
>   - Obsolete old shim builds.

The package no longer ships /boot/efi/EFI/fedora/shim.efi which is what
people's boot entries refer to. It's shimx64.efi now. This causes
failure to boot on EFI systems.

Which component, if any, is tasked with adjusting EFI boot entries in
such a case? Anyway, it doesn't happen, so some kind of warning (at
least to -devel and -test) would seem appropriate, ideally prior to the
new package reaching the mirrors.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Modularity and packagers [was Re: PkgDB and the ArbitraryBranching Change]

[Lars Seipel]

On Fri, Jun 09, 2017 at 08:50:58AM +0200, Adam Samalik wrote:
> RPMs... Well, if someone has an application on their server that doesn't
> run in a container, there are still RPMs on a traditional system. But would
> you install multiple versions stuff on that single system? Or would other
> things run in containers? And I'm just curious here, because I managed to
> use containers for basically everything I need. What about other people?
> 
> So, not everything will probably be installable as RPMs on the same system
> at the same time. But I see the world is going to containers, and I'm
> thinking if not being to install all RPMs next to each other on a single
> system is still a real problem. Thoughts?

I can totally see the appeal of containers when you have a uniform
cluster infrastructure that is shared by wildly different
deployments/users with wildly different requirements. That's what things
lke k8s do well.

OTOH, you pay for that nice flexibility with a huge increase in
complexity. Why would I want to put up with that if I'm not managing a
lot of deployments or, heck, when it's just my own development computer?

I may still do it for fun or because the benefits are really worth it in
a specific case, but designating it as the default (and maybe only) way
to work seems wrong[1]. Not when all that's actually required is a
different version of some library.

[1] Especially when considering that our industry as a whole has a very
hard time (euphemism!) producing systems that correctly deal with the
complexity that's already there.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: introducing fed-install: easy way to install packages from koji and other releases

[Lars Seipel]

On Wed, Aug 16, 2017 at 12:08:18PM +0200, Tomas Tomecek wrote:
> I thought that somebody had to write a tool for that. To my surprise, I
> haven't really found anything useful. So I wrote a simple tool to automate
> installation of packages from koji and other Fedora releases. The tool is
> just a wrapper on top of a single dnf call (usually just --enablerepo,
> --disablerepo magic):
> 
> https://github.com/TomasTomecek/fed-install

Pretty useful, especially considering the long time it takes lately for
builds (and thus bugfixes) to reach the rawhide repos. I have some
ad-hoc scripts for this myself but will take a closer look at
fed-install.

Thank you for publishing it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Lars Seipel]

On Tue, Jul 11, 2017 at 11:26:04PM -0500, mcatanz...@gnome.org wrote:
> But we have not been. Very few applications actually have SELinux profiles,
> and they are all maintained downstream rather than upstream. The volume of
> erroneous SELinux denials in Bugzilla is too high, and the response time for
> fixing them too slow. SELinux profiles work best when they are maintained
> upstream by application developers who are familiar with SELinux, not by
> SELinux developers who are unfamiliar with the application.

We do have the same issue with sandbox policies for Flatpak, no?  This
is the hard part of any sandboxing system and (judging from the current
docs) Flatpak hasn't tackled it yet.

A Flatpak app currently requires the following incantation to access the
host's dconf, so that it can behave like its users would expect:

> --filesystem=xdg-run/dconf
> --filesystem=~/.config/dconf:ro
> --talk-name=ca.desrt.dconf
> --env=DCONF_USER_CONFIG_DIR=.config/dconf

Now, while this specific dconf issue might get solved at some point,
dconf won't be enough for the vast majority of useful apps. All the crap
that lives in the various dot files in your home directory and elsewhere
on the system and that affects the behaviour of a program needs to be
made available to the app. Other things must not be, such as everything
containing secrets.

Some apps (e.g. virt-manager) need access to your ssh-agent socket but
you certainly don't want to make it available to every single app. This
is just a single instance of the general case of a program talking to
one of the numerous services that may run on the host.
programs depending on user configuration.

You want some environment variables passed through to the sandboxed app
(EDITOR or whatever) but not others (e.g. AWS_SECRET). How is the
Flatpak app even going to execute your favorite editor?

Someone is going to have to write all the policy for that. Otherwise,
the only apps that Flatpak will be able to handle properly are going to
be trivial mobile-style apps that don't interact with anything but their
developer's cloud services.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Lars Seipel]

On Thu, Nov 24, 2016 at 09:03:24AM -0600, Michael Catanzaro wrote:
> On Thu, 2016-11-24 at 10:02 +, Carlos Garnacho wrote:
> > Tracker-extract is not as exposed as Firefox, because the file needs
> > being in the local filesystem for starters. The web world is well
> > known for figuratively throwing 3rd party media content to your face,
> > even in otherwise trusted websites.
> 
> I think the concern here is that browsers allow websites to download
> files to your computer without any user interaction. Epiphany goes as
> far as to open them automatically. I've never previously considered
> that it's a security risk, […]

What does that mean, exactly? Does it pass the downloaded file to
xdg-open or equivalent? Just because you clicked on a link on some
website, no matter the file type and association involved? Seriously?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Lars Seipel]

On Tue, Oct 04, 2016 at 09:16:12AM -0600, Chris Murphy wrote:
> Over on Windows and macOS, there is no such thing as a non-destructive
> install media creation. It warns but obliterates the entire stick.
> They also don't have persistence. So I think you're on very solid
> ground calling both features edge cases, and as such probably not
> reasonable to block a release on if it weren't to work.

For these systems and most of their user base, installing the OS from
scratch already is an edge case. Most people use the preinstalled copy
that came with their machine. It wasn't that long ago that you couldn't
install them from an USB stick at all but had to use some kind of
optical disc. Long into the 2000's you had to use a freakin' floppy
drive to inject storage device drivers into the Windows install process.

Fedora is not in a position to impose such ridiculous demands on its
users and I, for one, wouldn't want to even if we could.

That's not to say we should block the release for persistence-enabled
live media. I don't think we should. It's just that the Windows or MacOS
install process isn't a very useful comparison for our needs. Fedora
has a far more diverse set of use-cases than any of these systems and
thus requires much more flexibility in its installation infrastructure.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Lars Seipel]

On Wed, Oct 05, 2016 at 03:26:10PM -0700, Japheth Cleaver wrote:
> I don't know what the dnf equivalent is, but isn't that precisely what the
> 'needs-restarting' command provided?

DNF has the tracer plugin for doing exactly that, including printing a
list of commands to restart the affected services, if possible, or
advising a manual restart of specific programs, the login session or the
whole system otherwise, depending on the package set.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Lars Seipel]

On Thu, Oct 06, 2016 at 08:20:34AM -0700, Adam Williamson wrote:
> On Thu, 2016-10-06 at 10:18 +0200, Kevin Kofler wrote:
> > rpm -Uvh --nodeps --nopostun \
> >   
> > http://$MIRROR/updates/testing/25/x86_64/s/systemd-udev-231-8.fc25.x86_64.rpm
> 
> Huh - that's handy, and I did not actually know --nopostun (something
> new every day, etc.). It does involve including instructions on how to
> find the package, though, which would inevitably go stale as it moves
> from u-t to stable. Still, thanks.

Use "dnf download" or yumdownloader to fetch the package?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Lars Seipel]

On Mon, Oct 03, 2016 at 12:49:07PM -0600, Chris Murphy wrote:
> Based on today's blocker review meeting discussion, and this email
> thread [1] I'd like to propose making only Fedora Media Writer the
> *officially supported* USB installation media creation tool, starting
> with Fedora 26.

Writing the image with dd/cat/cp/whatever is probably just going to work
(if LMC does) and is available anywhere you can put it an USB stick.

I'd like that to be supported, too, so that putting workarounds for
broken images into the writing program is not sufficient to go on with
the release.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: TPMs, measured boot and remote attestation in Fedora

[Lars Seipel]

On Sat, Apr 23, 2016 at 02:57:55PM +0200, Kevin Kofler wrote:
> Matthew Garrett wrote:
> > Remote attestation is a mechanism by which […]
> 
> How does the remote machine know that what is answering is a physical TPM 
> and not a software emulation? Does it need to have the individual TPM's 
> public key in advance?

If I understood it correctly, the TPM keys can be chained back to a
manufacturer key and likely some kind of CA. So while software emulation
is unfeasible without the ability to extract private keys from either
TPMs or their vendors, you should be able to buy any TPM, feed it with
exactly the values you want, and get yourself a signed attestation of
TPM state that has no relationship to what is actually running on your
computer. That works as long as the other side only verifies against
some generic vendor public key.

If you precisely know the key the signature should've been made with
(e.g. because you did the initial machine setup and then left it with
some colocation facility) you can verify it against the expected public
key directly. Used this way, remote attestation might actually be
useful.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: glibc in Fedora rawhide now split by langpacks.

[Lars Seipel]

On Fri, Feb 26, 2016 at 08:56:27AM -0500, Stephen Gallagher wrote:
> Yeah, I think the best approach would be to have all the langpacks offer a
> virtual Provides: glibc-langpack and have the main package Requires:
> glibc-langpack and Suggests: glibc-all-langpacks.

This would force the installation of at least one langpack, no?  The C,
POSIX and *C.UTF-8* locales are builtin, so for many systems it is very
reasonable to run without any language pack installed.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [INPUT REQUESTED] Fedora Policy on generated code

[Lars Seipel]

On Fri, Dec 18, 2015 at 02:13:54PM -0500, Stephen Gallagher wrote:
> 2) Do we require that whatever tools are necessary to generate this
> code is packaged in Fedora (with all the legal and policy requirements
> that this implies)? If we do not, do we require that the code used by
> upstream is free software?

It's the only way we're able to reliably modify and regenerate that code
and/or tell with any confidence what tools were used to build the
package we shipped. Being able to actually create modified versions of a
package is a pretty big thing, don't you think?

> 3) Do we require that building in Fedora always requires regeneration
> of this code from the original data?

This is likely necessary to ensure that our ability to rebuild doesn't
vanish over time.

I see no reason to treat this situation any different from other
compilation processes happening during the package build. Especially for
things like minified Javascript the answer really seems pretty obvious
to me: apply the same policy as you'd do for C sources compiled to
object code.

There may be reasonable exceptions, but I'd consider them pretty rare.
Even outside of the context of licensing, I think the concept of
"preferred form for modification" is a useful one here. That's what
should be in the SRPM and should be compilable by FOSS tools available
in Fedora. If upstream development regularly happens by hand-editing a
yacc-generated parser and no one touched the original grammar file in
years, then sure, it's probably best to ship the generated files.

The autoconf issue is ugly and affected packages probably get
grandfathered in, but we definitely shouldn't create more of those.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: [Fedora-packaging] Proposal to reduce anti-bundling requirements

[Lars Seipel]

On Thu, Sep 10, 2015 at 09:53:27AM -0400, Stephen Gallagher wrote:
> == Advantages to using shared libraries ==
>  * Security/Bugs - When a bug or security vulnerability is located in
> a library, it needs to be patched in only a single package in order to
> fix all applications using that library.
>  * Resources - A shared library only needs to be loaded into memory
> once, reducing the memory requirements of the system.

There's more to it. Not meaning shared libraries in particular, but
having a single "system copy" of a library. Whether these exist as
shared library, static library or source code doesn't matter as much.

A single library version that is used by all programs is a boon to the
transparency and simplicity of the system. It also makes it reasonably
straightforward for users to apply local patches and have the updated
library be used by all applications.

> == Advantages to bundling ==
>  * Increases the available pool of software that can be packaged
> substantially (many modern languages such as Ruby and Go are
> realistically only functional with allowable bundling)

Are you aware that there is work happening upstream to build Go packages
into shared libraries[0]? The explicit motivation of that work
(originating at Canonical) is to make maintenance of Go packages easier
for distributions. There's currently a single guy (Michael Hudson)
working on moving it forward. I wouldn't be surprised if he could do
with some help.

Also, I don't agree that Go code is only packagable with bundling. Sure,
the compiler emits static libraries but that doesn't mean you need to
bundle *source code* in different places. You can also ship the static
libraries (or better just the source code, as we already do) as a system
library for other packages to use.

The better Go libraries actually tend to strive for long-term (source)
compatibility. Or, if that doesn't work out, at least handle the
necessary transition thoughtfully. But yeah, as soon as you approach any
"web" stuff you might just run into the same Ruby crowd.

[0] technically, you can already build Go code into shared libraries but
you can only export a C API. Calling into Go code using a Go API is what
I meant above)
-- 
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: UTF-8 locale in rpm build

[Lars Seipel]

On Sun, May 10, 2015 at 09:02:31AM +0200, Matěj Cepl wrote:
 Which part f C.UTF-8 is not covered by en_US.UTF-8?

Let's see:

% export LC_COLLATE=C
% bash -c 'case b in [A-Z]) echo upper;; *) echo lower;; esac'
lower

Ok. Now en_US.UTF-8:

% export LC_COLLATE=en_US.UTF-8
% bash -c 'case b in [A-Z]) echo upper;; *) echo lower;; esac'
upper

Right. The collation rules for en_US.UTF-8 would likely break build and
test scripts in lots of packages.

Relevant bash bug:
http://savannah.gnu.org/support/index.php?108609
-- 
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: [Proposal] Ring-based Packaging Policies

[Lars Seipel]

On Thu, Feb 12, 2015 at 01:32:04PM -0500, Stephen Gallagher wrote:
 === Core Packages ===
 Any package that is provided on a release-blocking medium (which at
 present includes Fedora Atomic, Fedora Cloud, Fedora Server, Fedora
 Workstation, the KDE Spin and several ARM images) must comply exactly
 with the packaging guidelines as they are written today.
[...]
 === Ring Packages ===
 Any new package that is *not* going to be part of the install media set
 is required to pass a lighter review and is permitted to carry bundled
 libraries, with caveats to be listed below.

What would be the place for higher-quality packages that aren't on any
install media (and are also not required to create those)? I think a
broad collection of reviewed and guideline-conforming packages is a
useful thing to have. Just mixing them together in a single repo with
the lower-quality stuff would diminish their value in significant ways.
-- 
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: Entire process's environment attached to bugzillas by ABRT

[Lars Seipel]

On Sun, Nov 30, 2014 at 01:43:39PM +, Richard W.M. Jones wrote:
 How about having abrt just remove or scrub all variables that start
 with /^OS_/ ?  I know it's nasty to have application-specific
 treatment of environment variables like this, but the number of
 applications that pass auth information through environment variables
 is small.
 
 For Amazon EC2 you'd want to scrub /^AWS_/

There's also OpenNebula (^ONE_) and Vmware (^VI_) doing the same. Seems
to be pretty common with virt and cloud stuff. Apart from that I can't
think of anything else right now.
-- 
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: Enable tapping by default

[Lars Seipel]

On Tue, Nov 18, 2014 at 10:02:10PM +0100, Kevin Kofler wrote:
 do you right-click? So I don't expect this to be a common case, except maybe 
 in Apple's one-button land).

Apple also disables tap-to-click by default. So if it's true that users
expect that to be enabled those expectations must've been set somewhere
else.

Some more anecdata:
Personally, I don't like tap-to-click but know perfectly well how to
deal with it (by disabling all touchpad functionality in the firmware
and use a trackpoint, like all self-respecting people do). So as far as
I'm concerned, the default doesn't matter.

Some family members, though, mostly use their laptop with an external
mouse (i.e. not consciously using the touchpad at all). Until I showed
them that tap-to-click is a thing and can be disabled, they were
experiencing spurious quirks and had no idea what was causing them,
thinking they maybe hit a wrong key on the keyboard by accident or that
there's something wrong with their device or software setup. I think the
current Fedora default is the right thing to do.
-- 
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: Mozilla enabled ads in Firefox and they're active in Fedora

[Lars Seipel]

On Tue, Nov 18, 2014 at 11:15:33AM +0200, Nikos Roussos wrote:
  No, actually we don't. We promote websites because we honestly think
  they're useful, not because we're paid to do so.
 
 That's irrelevant. Paid or not, promoting websites through tiles or
 gnome-shell is the same form of advertisement.

I disagree. Think about it: imagine I told you as a friend how I was at
some pub yesterday and enthusiastically rave about how it was totally
awesome and that you should go there, too. Now, in the one case I told
you this because I'm honestly convinced that it would be fun for you to
go there and that you'd like it. In the other case I did it because the
owner paid me for it. Really no difference? I don't think so.
-- 
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: Mozilla enabled ads in Firefox and they're active in Fedora

[Lars Seipel]

On Mon, Nov 17, 2014 at 12:05:35PM +0200, Nikos Roussos wrote:
 True, as you also have to explicitly click a tile to send data to
 Mozilla.

Well, I don't think the act of hiding/closing an ad (by clicking on the
'x' attached to it) can be reasonably interpreted as informed consent.
Yet, it is explicitly listed among the tracked actions according to what
Darren Herman apparently told the advertiser community.

 No. We are talking about the tiles. I didn't see anyone suggesting we
 remove Google search. It's like the tiles feature crossed a line, which
 is far from truth.

I'm not sure about that. Besides the feature itself, there's also the
issue of the language used to explain it. Describing the placement of
advertisements as an enhancement to users, in my opinion, definitely
crosses the line to dishonesty and bullshitting of users.

Really, this stuff is communicated in a form of double-speak marketing
verbiage that I'm just not used to hear in communicating with open
source projects. Read the initial blog posts about it.

 I'm talking about the advertisement part. Some people seem to be
 bothered by this alone. Tiles feature indeed promotes some websites, but
 we already do that.

No, actually we don't. We promote websites because we honestly think
they're useful, not because we're paid to do so.

I don't think we should drop Firefox from the default installation. I
really like it, despite something at Mozilla going terribly wrong
lately. I do think this feature needs to be shipped as off by default,
though.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Mozilla enabled ads in Firefox and they're active in Fedora

[Lars Seipel]

So Mozilla has recently gone live with its advertisement tiles on the
New Tab page. Only newly created profiles get to see this stuff.

On a pristine F21 install using Gnome, when first launching Firefox,
users are presented with a number of tiles, depending on screen size.
One of those is a so-called sponsored tile chosen from a range of
available advertisements (e.g. for booking.com, there's also one for the
Snowden movie), apparently depending on geographical location.

When this feature got originally announced[1], there was a discussion
on -devel if this kind of stuff is really appropriate for Fedora.

Some time later Mozilla seemed to have canceled the feature, quoting
That’s not going to happen. That’s not who we are at Mozilla. as one
of the reasons[2].

Apparently, they (again) reconsidered, pushing the feature to nightlies
a few months ago. Well, it now hit the stable branch and, therefore,
Fedora.

This is how Mozilla pitches the feature to advertisers[3]:

 To support ad personalization, Mozilla created an internal data system
 that aggregates user information while stripping out personally
 identifiable information. Mozilla can track impressions, clicks, and the
 number of ads a user hides or pins. Its advertising partners are also
 privy to that data.

Personally, I don't think that showing advertisements on the free
software desktop is appropriate. Our users are supposed to be able to
fully trust our software. That's one of our most-often touted strenghts.
I don't think the ability to track impressions, clicks, and the number
of ads a user hides or pins is something that is compatible with that,
regardless of this data being tied to personally identifiable
information or not.

Firefox's behaviour is probably nothing extraordinary on the other
platforms Mozilla is targeting. Compared to the prevalent attitude of
proprietary vendors, especially on mobile, it doesn't sound that bad
anymore. I don't think that's a suitable scale for Fedora, though.

From a user perspective, it's not that hard to disable the feature. Upon
first seeing that page a tooltip is shown to hint at the possibility.
Users can choose between three modes, Enhanced, Classic and Blank.
Contrary to what is stated in the Mozilla kb[4], the only one that
actually disables the ads is Blank, which is equal to setting the new
tab page to about:blank.

What does the community think of it? Is it okay for our flagship
applications to carry ads and report tracking data?

[1]
https://blog.mozilla.org/advancingcontent/2014/02/11/publisher-transformation-with-users-at-the-center/
[2]
https://blog.mozilla.org/futurereleases/2014/05/09/new-tab-experiments/
[3]
http://www.adexchanger.com/online-advertising/mozilla-finally-releases-its-browser-ad-product-hints-at-programmatic-in-2015/
[4]
https://support.mozilla.org/de/kb/how-do-tiles-work-firefox#w_enhanced-tiles
-- 
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: blivet-gui announcement

[Lars Seipel]

On Fri, Sep 05, 2014 at 11:05:29AM +0200, Vratislav Podzimek wrote:
 Good news, everyone! We (me and CC'd Vojtech Trefny) would like to
 introduce you the next generation tool for storage management -- the
 **blivet-gui** tool [1]_.

Nice work! I really like the kickstart writing option.
-- 
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: Applications not visible in the software center

[Lars Seipel]

On Wed, Jul 16, 2014 at 05:14:11PM +0100, Richard Hughes wrote:
 I've uploaded an interactive page at
 http://alt.fedoraproject.org/pub/alt/screenshots/f21/failed.html

Thanks for posting that list. Quoting from there:

 Uses obsolete X11 toolkit

What are the conditions for something to be considered obsolete here?

Why is Seamonkey in that list? Does it refer to some old GTK+1 using
variant? Also some other applications that, though somewhat older, still
see active development. What is the reasoning behind blacklisting those?
-- 
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 ...

[Lars Seipel]

On Mon, Apr 21, 2014 at 06:58:56AM -0400, Mauricio Tavares wrote:
   If all smartmontools need is to just send emails out, I would
 suggest using something like ssmtp or msmtp.

/usr/sbin/sendmail is handled with alternatives and can be provided by
e.g. ssmtp. Smartmontools was changed for exactly this reason.
-- 
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: When a yum update sets up an MTA ...

[Lars Seipel]

On Sun, Apr 20, 2014 at 11:32:10PM -0400, Rahul Sundaram wrote:
 Exim getting installed isn't a bug but getting enabled by default is.  You
 should file it and similar issues in other packages if any as well

Filed #1089650.

Thanks,
Lars
-- 
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: F21 System Wide Change: Workstation: Disable firewall

[Lars Seipel]

On Thu, Apr 17, 2014 at 11:44:58PM +0200, Miloslav Trmač wrote:
 We don't, actually.  *Only* applications running in a session of a member
 of the wheel group would have that right, and those applications are pretty
 much root-equivalent anyway.  (Many GNOME users probably use such a setup,
 but it's not at all the only one possible.)

Ugh. This is implemented in PolicyKit? Where was this change
discussed/announced and when did it happen? Reinterpreting wheel group
membership to give user accounts mighty powers without requiring
re-authentication is a pretty major change and probably unexpected for
most users.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

When a yum update sets up an MTA ...

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

How did this happen? It turns out that smartmontools intermittently
required 'MTA' which (presumably due to its nice and short name) pulls
in exim when there's no MTA already installed. This dependency was
replaced (with a file dep on %{_sbindir}/sendmail) in
smartmontools-6.2-5.fc20.

Ok, that's how it got installed. But why does it get run? Is the
installation of exim tricking my system into believing it's Debian?

We do have the presets functionality[0] for this, I thought. And indeed,
a call to systemctl preset disables exim.service just like it's supposed
to do.

Looking at exim's spec file shows its %post is using the proper
systemd_post macro which honors presets. In %postun, though, there's a
direct call to systemctl enable, buried in the sysv conversion stuff. Is
it really supposed to be there? But this shouldn't get executed on
package install anyway, right?

Would be glad if someone who knows a bit more about the interaction of
RPM and systemd preset files could chime in and tell me where the bug
report should go.

Lars

[0] https://fedoraproject.org/wiki/Features/PackagePresets
-- 
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: When a yum update sets up an MTA ...

[Lars Seipel]

On Sun, Apr 20, 2014 at 06:44:53PM -0700, Andrew Lutomirski wrote:
 I think it's because upgrading installs a new package and uninstalls
 an old package.  Sounds like a bug in exim.

Yes, but there was no upgrade of exim. An update of smartmontools pulled
it in but exim itself got installed for the first time.

Lars
-- 
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: F21 System Wide Change: Workstation: Disable firewall

[Lars Seipel]

On Tue, Apr 15, 2014 at 08:14:01PM -0400, Christopher wrote:
  Perhaps shorten to:
 
  block
  public
  work
  home

 That is a much more intuitive default set.

Is it? What's supposed to be the difference between work and home?

Lars
-- 
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: advertisement in packaged software (e.g. Firefox)

[Lars Seipel]

On Thu, Feb 13, 2014 at 09:01:15PM +0200, Nikos Roussos wrote:
  The fact that the package is calling home (whether or not the location 
  of the IP is checked), is a form of tracking. Particularly since firefox 
  updates are being handled by Fedora and there is no need for our version 
  to be calling home to check for updates.
 
 *If* it calls home. If this is a predefined list bundled with firefox
 there is no reason to call home. 

The currently available bits of information suggest otherwise:

 What information will Mozilla provide sponsored content partners from
 the Directory Tiles?
 
 Mozilla is putting together just the basic metrics that marketers or
 content publishers might need to understand the value they are
 receiving.  As of now, our expectation is that we’ll be delivering the
 number of impressions (how many times a tile was shown) and
 interactions (how many interactions with a tile, i.e. clicks).

taken from:
https://blog.mozilla.org/advancingcontent/2014/02/13/more-details-on-directory-tiles/
-- 
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.next in 2014 -- Big Picture and Themes

[Lars Seipel]

On Thu, Jan 23, 2014 at 05:07:16PM -0500, Josh Boyer wrote:
 Also possibly correct.  However, that doesn't preclude the repos as we
 know them today from still existing, with still the same quality.

Server, desktop or embedded board, in today's Fedora it's all the same,
just with a different package set installed. People (not all, obviously)
consider this a good thing. I just have to put a minimal Fedora install
on some machine and then build it from there.

That's what Tom was getting at, I think. The discussions in the WGs so
far have hinted that it's not necessarily a reasonable expectation that
this will continue to be the case. An oft-cited reason was that RPMs
apparently can't provide the 'integration' that is somehow wanted.

I always considered it nice that there's only a single Fedora. I thought
that split products were mostly an artefact of commercial
differentiation and so Fedora users don't have to deal with you can't
use this filesystem unless you have the Ultra Enterprise Storage
Edition or stuff like that. ☺
-- 
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: Inter-WG coordination: Stable application runtimes

[Lars Seipel]

On Tue, Dec 17, 2013 at 08:53:57PM -0700, Chris Murphy wrote:
 If you like the idea of always reinventing the wheel seemingly for no good 
 reason, or just to use the latest flavored language of the day, then great.

Uhm. Exactly because I don't like my stuff breaking every three weeks I
choose libraries that live up to my expectation. This might involve
assessing the capability of an particular upstream to maintain their
stuff going into the future or just avoiding the latest flavored
language of the day.

This whole issue is for upstream projects to solve. It shouldn't be
papered over in Fedora. Want stable libraries? Cool, then let's go build
some. Help upstream projects to maintain stable releases and to design
their APIs with an attention to stability in the first place.

Many projects already get this. It might be appropriate for Fedora to
document which these are to help Fedora users make an informed choice.

But just freezing libraries at some random version essentially creates a
fork which has to be maintained inside Fedora. Who is going to develop
programs specifically for Fedora? Most developers are targeting the
broader GNU/Linux type of system. Now think about Fedora supporting libA
at version x while Debian froze it at version y and SUSE at z. What have
we won?

Really, this should be solved in upstream projects so you can expect a
stable library API across distribution boundaries. Doing it in Fedora is
not actually solving the problem.

Lars
-- 
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: ecryptfs alternatives

[Lars Seipel]

On Wed, Dec 18, 2013 at 05:02:47PM +0100, Michał Piotrowski wrote:
 Ecryptfs seems to be more user friendly for encrypting data on btrfs than
 using dm-crypt on each drive. For example - you have a btrfs that uses 3
 different hdd's - AFAIU you need to enter password for each hdd before
 mounting filesystem.

At least when set up through Anaconda that's not the case. You are asked
for the passphrase only once. I don't know what exactly it is Anaconda
is doing here but it's definitely nice. On most other distributions you
really do have to enter the passphrase multiple times, once for each
device listed in crypttab.
-- 
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: FTBFS if -Werror=format-security flag is used

[Lars Seipel]

On Wed, Dec 04, 2013 at 10:09:43PM +0100, devzero2000 wrote:
 Interesting, for me almost,  that many refs are from debian/ubuntu world.

Well, that's the convenience of being late to the party. The majority of
the work was already done by other distros and we can build upon that.
In other cases Fedora is first and the other distros have the ability to
rely on our painfully gathered experience. That's a good thing.
-- 
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: FTBFS if -Werror=format-security flag is used

[Lars Seipel]

On Wed, Dec 04, 2013 at 11:56:23PM +0100, Brendan Jones wrote:
 Patching is not a problem. Unnecessary is the question. Explain to
 me (not you in particular Rahul) how these printf's can possibly be
 exploited?

Uhm, I just took a look at the hydrogen source. The problem with it is
that it's not at all obvious that the f?printf calls can't lead to bad
things happening. This is not a case of GCC failing to account for some
trivial indirection. Fix it, please. Really, you should.

Lars
-- 
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: FTBFS if -Werror=format-security flag is used

[Lars Seipel]

On Wed, Dec 04, 2013 at 11:56:23PM +0100, Brendan Jones wrote:
 Patching is not a problem. Unnecessary is the question. Explain to
 me (not you in particular Rahul) how these printf's can possibly be
 exploited?

To expand on my earlier mail: the printf usage in hydrogen is definitely
horribly wrong. Basically all logging output is passed through these
calls and might contain data from all kinds of sources, be it file names
or various metadata.

Want to see it crash? Crank up the log level (-VInfo does it) and pick
save library from the menu. Enter some printf format specifiers (%s or
something) in the name or author field. 

Segmentation fault (core dumped)

Oops. Valgrind had this to say:

 Process terminating with default action of signal 11 (SIGSEGV)
  General Protection Fault
at 0x863508F: vfprintf (vfprintf.c:1635)
by 0x86F0600: __printf_chk (printf_chk.c:35)
by 0x584360: loggerThread_func(void*) (stdio2.h:104)
by 0x4E38F32: start_thread (pthread_create.c:309)
by 0x86E0EAC: clone (clone.S:111)

loggerThread_func? You'll find that in object.cpp. The crashing printf
call is on line 242. But you know that already, as Dhiru wrote it in the
bug report for your package.

I'm sure someone more determined than me might find all sorts of ways to
make use of these flaws that are not in the interest of hydrogen's
users.

Lars
-- 
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: Can we have better ssh fingerprint collision messages?

[Lars Seipel]

On Tue, Nov 12, 2013 at 01:24:16PM +0100, Reindl Harald wrote:
 Am 12.11.2013 13:21, schrieb Matthew Miller:
  Harald, I'm not seeing the behavior you see either -- if I replace a host
  key with another one in known_hosts, I get the correct man-in-the-middle
  message
 
 interesting, i can reproduce this as often i want in case
 i am doing it in the first one for the short hostname only
 and leave the entry with the FQ and IP-address untouched

Yeah, sure. That's the standard SSH behaviour. As far as it is concerned
those are different hosts. If one wants to change that OpenSSH upstream
would be the appropriate place to do that. I don't think such
modifications should be made in distribution packages. Especially not
without even trying to get upstream feedback on the issue.

Lars
-- 
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: Draft Product Description for Fedora Workstation

[Lars Seipel]

On Mon, Nov 04, 2013 at 11:36:42AM +, Bryn M. Reeves wrote:
 The kernel does not provide stable APIs. If you've ever tried to
 maintain a non-trivial module or patch to the kernel out-of-tree for any
 length of time you'll understand how much work is involved in just
 keeping it working. Gnome shell extensions are not so different.

True. They are also one of the least likely pieces of code I can imagine
running in some sort of isolated container. If we are talking
applications instead, the Linux syscall ABI is damn stable. Just as
there are userspace libraries that go to great lenghts to offer a stable
interface to their users.

If I, as an application developer, don't want my code to break every few
months I'd be well advised to pick my dependencies wisely and choose
libraries that offer me what I want (i.e. a stable interface) instead of
those that don't.  That's the proper solution. Not mindlessly bundling
everything together and expect others to keep it working somehow.

If we are missing stable libraries in parts of our stack that's a
problem to be fixed in upstream projects instead of being worked around
in the distribution.

So please don't let's pretend that containerizing apps with their
dependencies is anything more than a workaround, a stop-gap measure to
paper over other problems. And it does come with its costs, one of those
being tons of added complexity.

It's going the easy way instead of solving problems properly, upstream
in applications and libraries. Is it sensible in the context of Fedora
to do it anyhow? I don't know. I have my worries, though.

Lars
-- 
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: OpenH264 in Fedora

[Lars Seipel]

On Mon, Nov 04, 2013 at 11:28:21AM -0600, Bruno Wolff III wrote:
 The issue for RTC is that we could be using a royalty free codec,
 such as VP8 instead. Accepting the binary makes it more likely that
 h.264 will be made mandatory to implement, which means any company
 not wanting to implement VP8 can always point to h.264 being
 mandatory as an excuse not to support VP8.

And, apparently, that's all this announcement is about at this point.
There's no code, no blob, no license for the blob, nothing. Just a
decision to be made at the IETF slated for Thursday.

We'll never be able to ship this thing within Fedora. If H.264 gets made
MTI for WebRTC every Fedora user has to bear the hassle of somehow
downloading the blob from Cisco. The alternative VP8, however, works
right out-of-the-box on every Fedora system.

Proprietary vendors will no doubt integrate the needed codec directly
into their software and save their users the trouble. It would be a
major disadvantage for free software projects. Codified in an IETF
standard. That's pretty sad if you ask me.

Additional issues might turn up in terms of how the OpenH264 project
will deal with the addition of builds for other platforms and
architectures. I'm not only thinking Fedora here but also open source
projects trying to build embedded stuff or working on other free
operating systems. Having to speak the (yet unknown) OpenH264 API and
somehow convince the OpenH264 governance to build for your platform is
just bad. For all we know this might even be a gigantic mess of
unworkable C++ code. ;-)

Hey, we are implementing an internet standard here, why do we have to
ask anyone for permission?

Lars
-- 
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: Draft Product Description for Fedora Workstation

[Lars Seipel]

 And the application developer suddenly gains back control on how and
 when his app gets delivered to users.

And this is supposed to be a good thing? Looking at much much crap
distro packagers had to fix in the past I really can't think of it as
that.

You then basically need all that container stuff just so you can be a
little less scared at some application developer's broken attempts to
enhance your user experience by installing suid-root helpers or stuff
like that. 
-- 
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: OpenH264 in Fedora

[Lars Seipel]

On Mon, Nov 04, 2013 at 03:29:02PM -0600, Bruno Wolff III wrote:
 That's not what it says. That just says we won't package the binary.
 What isn't answered is limitations on the process for Firefox
 downloading it in Fedora. I really doubt firefox will be totally
 prevented from downloading the binary as a plugin.

And other packages wanting to play video or do WebRTC would start to do
the same thing? I really can't see that happening. If at all, it
probably would be a Firefox-only exception which I, personally, would
strongly opppose.
-- 
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: OpenH264 in Fedora

[Lars Seipel]

On Mon, Nov 04, 2013 at 01:51:48PM -0800, Gregory Maxwell wrote:
 On Mon, Nov 4, 2013 at 1:40 PM, Lars Seipel lars.sei...@gmail.com wrote:
  And other packages wanting to play video or do WebRTC would start to do
  the same thing? I really can't see that happening. If at all, it
  probably would be a Firefox-only exception which I, personally, would
  strongly opppose.
 
 No. Mozilla would not have agreed to ship something that was firefox
 only.  It may not be acceptable for many things, but not because it
 was firefox or webrtc only.

I know that and it's not what I wanted to say. It was meant in the
context of a possible exception (from Fedora rules) for the Fedora
Firefox package to grab the Cisco blob on startup. It's unlikely that
such behaviour (grabbing binaries from the internet) would be granted
(from Fesco) to every Fedora packages wanting to play video.

Sorry if that wasn't clear.

Lars
-- 
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: rubygem-passenger - FTBFS on f20 - need help

[Lars Seipel]

On Wed, Sep 18, 2013 at 03:29:19PM -0500, Troy Dawson wrote:
 With original src.rpm, i386 build [2] failed with the error
   error: reference to 'uint32_t' is ambiguous

Well, according to the build log 'uint32_t' is in fact ambigious. It is
declared once in stdint.h as
typedef unsigned int  uint32_t;
and then in ext/boost/cstdint.hpp as
typedef unsigned long   uint32_t;

The latter apparently being in the boost namespace. I'd bet the code in
question is not referring to those with their qualified names but just
imports the std namespace as well as the boost namespace, leading to
this conflict?

Lars
-- 
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: rubygem-passenger - FTBFS on f20 - need help

[Lars Seipel]

On Wed, Sep 18, 2013 at 11:22:26PM +0200, Lars Seipel wrote:
 The latter apparently being in the boost namespace. I'd bet the code in
 question is not referring to those with their qualified names but just
 imports the std namespace as well as the boost namespace, leading to
 this conflict?

Oh wait, you are including stdint.h, right? The C++ header is cstdint.
Try that. Including the C header might lead to all the stuff in the
header not being in the std namespace but in the global one.

Lars
-- 
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: rubygem-passenger - FTBFS on f20 - need help

[Lars Seipel]

On Wed, Sep 18, 2013 at 03:29:19PM -0500, Troy Dawson wrote:
 What is a good way to track down a solution to error: reference to
 'uint32_t' is ambiguous?

Sorry for the multiple mails but after looking at the source I think I
see the actual problem. So in e.g. ext/common/Utils/MessageIO.h we have:

#include boost/cstdint.hpp
...
using namespace std;
using namespace boost;
...
use uint32_t - error: reference to 'uint32_t' is ambiguous

The bundled boost cstdint header is including stdint.h on systems that
have it.  So ::uint32_t is provided by that. Additionally it emits
typedefs for the stdint types in the boost namespace with a declaration
conflicting with glibc's. As the passenger code is importing the boost
namespace 'uint32_t' could refer to ::uint32_t (from stdint.h included
through boost) or boost::uint32_t. That's what leads to the error.

Looking at our system boost cstdint.hpp it is doing something smarter.
Instead of coming up with its own uint32_t it's just referring to the
one from stdint.h (by means of a using ::uint32_t; declaration), so it
can't ever conflict.

After looking at the passenger-bundled boost header (instead of only
cpp's output) its intention seems to be the same but it's broken. Our
boost RPM carries a patch that fixes it. Ah, the joys of bundled
libraries.  ;-)

http://pkgs.fedoraproject.org/cgit/boost.git/tree/boost-1.54.0-__GLIBC_HAVE_LONG_LONG.patch

You could apply that patch to the bundled boost copy to fix the issue.
Another way would be to just delete the bundled ext/boost/cstdint.hpp
file in %prep and let it pick up the system cstdint.hpp. You'd obviously
have to buildrequire: boost-devel for that.

Hope that helps,
Lars
-- 
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: Rawhide tree now includes install images

[Lars Seipel]

On Fri, Sep 06, 2013 at 11:24:38AM +0200, poma wrote:
 You've probably missed something in the title, so the correct one should be:
 Rawhide tree now includes broken install images
 Now, if someone is doing it just to fill the tree, for the sake of
 formality, thanks but no thanks.

Why don't you find out what's broken then instead of ranting on the
list?

Lars
-- 
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: BlueZ Status in Fedora.

[Lars Seipel]

On Sun, Aug 18, 2013 at 09:48:46PM -0700, Richard Vickery wrote:
 Instead of shipping it, is there a problem with giving it to those on
 the developer list and letting us iron out the kinks?

Sure, that's what already happens. If you want to help, this thread
contains a multitude of pointers where to start.

Lars
-- 
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: BlueZ Status in Fedora.

[Lars Seipel]

On Wed, Aug 14, 2013 at 08:37:19PM -0700, Dan Mashal wrote:
 Otherwise we are looking at possibly reforking gnome-bluetooth at this
 point in time.

Reforking? And then wait until the bitrot sets in again? ;-)

Can't you just use gnome-bluetooth proper and resurrect the panel icon
stuff like Kalev proposed?

Lars
-- 
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: Obsoleting ConsoleKit once and for all

[Lars Seipel]

On Tue, Jul 30, 2013 at 04:28:55PM +0200, Christoph Wickert wrote:
 thunar and pcmanfm are file managers and require ConsoleKit for handling
 removable storage.

Are you sure you aren't confusing this with something? HAL maybe? 
-- 
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: Obsoleting ConsoleKit once and for all

[Lars Seipel]

On Sun, Jul 28, 2013 at 01:24:55PM +0200, Christoph Wickert wrote:
 Others are not. I am pretty sure ConsoleKit is still needed by LXDM and
 slim as they don't support systemd-logind and by pcmamfm and thunar for
 handling permissions of removable devices.

Slim doesn't require ConsoleKit anymore and works fine with logind.
-- 
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: Summary of accepted Fedora 20 Changes - week 30

[Lars Seipel]

On Sat, Jul 27, 2013 at 12:55:58PM +0200, drago01 wrote:
 Which excludes you from the type of user I was talking about.

I have no data to back this up but I'd guess that the vast majority of
Fedora's userbase _are_ technical users. It's certainly a noble goal to
make Fedora more accesible to non-technical users.

The thing is: is it acceptable that, in the process of reaching that
goal, we end up alienating (a part of) the more technical userbase (who
are much more likely contributors)?
-- 
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: RFC: Proposal for a more agile Fedora.next (draft of my Flock talk)

[Lars Seipel]

On Fri, Jul 26, 2013 at 03:30:19PM -0400, Subhendu Ghosh wrote:
 The app provider should fix their version of libxml

The problem is: they don't. Walk up to some random Windows machine and
look how many vulnerable copies of zlib (or some other popular library)
you can find. Aside from maybe Google and Mozilla almost no one gets
this right.

And security issues is just one problem of the bundled library
approach...
-- 
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: Rawhide tree now includes install images

[Lars Seipel]

On Tue, Jul 16, 2013 at 10:41:22AM -0600, Kevin Fenzi wrote:
 After consulting with various teams, release engineering has re-enabled
 rawhide composes to create install images again.

Hmm, it was disabled again? Nothing there in the last few rawhide
composes (0718 was the last one with install images built, they seem
broken though).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide tree now includes install images

[Lars Seipel]

On Thu, Jul 25, 2013 at 03:37:34PM -0600, Kevin Fenzi wrote:
 Hopefully fixed for tomorrow. 

Nice, thanks to you and Dennis.

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

Re: Fedora as an crowd founded project an additional funding source to our sponsor

[Lars Seipel]

On Wed, Jul 24, 2013 at 07:35:42AM -0400, Stephen Gallagher wrote:
 Fedora is hemorrhaging users to other distributions (and to
 closed-source platforms).

Do we actually know that this is the case?

The statistics wiki page does show a drop of total repository
connections around Fedora 15 but slowly recovering since then (assuming
F18 numbers are WIP). Doesn't seem *that* bad overall.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Sendmail

[Lars Seipel]

On Fri, Jul 19, 2013 at 11:37:23PM +0300, Oron Peled wrote:
  * We should add the local inbox to the default configuration of all
MUA's that can handle it (kmail, evolution, etc.)

That'd be really nice.

  * When Anaconda (or would it be first boot? I lost tracking...) is
setting the first user, add it to /etc/aliases as a mail alias to root.

It's Anaconda or initial-setup these days. Or gnome-initial-setup for
Gnome. :-)

 IMO, removing sendmail from the *minimal* install is good idea, but
 we should have an MTA for the default install with local delivery.

Agreed.

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

Re: F20 System Wide Change: No Default Syslog

[Lars Seipel]

On Wed, Jul 17, 2013 at 04:23:54PM -0500, Billy Crook wrote:
 What about a special filesystem mounted at /var/log or filesystem trickery
 therein that presents contents similar to what everyone expects, backed out
 of journalctl and its storage then?

It's probably straightforward to write a FUSE filesystem that grabs the
needed information from journalctl when read. Mount it somewhere under
/run and set up /var/log/messages as a symlink to the corresponding
file.

But I don't see the point. Just install rsyslog. It's not going away any
time soon.

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

Re: F20 System Wide Change: No Default Syslog

[Lars Seipel]

On Wed, Jul 17, 2013 at 12:31:56PM -0400, Steve Clark wrote:
 What about scripts that use /usr/bin/logger? Do messages generated by this 
 utility
 end up in the journal? Or php scripts, or programs using syslog(3).

Yes, everything using standard syslog facilities ends up in the journal.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Lars Seipel]

On Mon, Jul 15, 2013 at 11:28:48PM +0200, Lennart Poettering wrote:
 But this is a really different discussion anyway. I know some people
 hate auto-paging, but I am pretty sure more people learned to love it
 since it was introduced by git. I love auto-paging for sure.

The difference between git's autopaging and journalctl is that with git
log the most recent commits come first while log files have the most
likely interesting stuff at the end. There's journalctl -e and
journalctl -r (as well as the more specific query options, of course)
so it should just take some time to get used to it.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F20 System Wide Change: No Default Syslog

[Lars Seipel]

On Mon, Jul 15, 2013 at 02:46:27PM -0600, Eric Smith wrote:
 I don't actually care whether there's a binary journal or not, but far
 more of us have real usecases for /var/log/messages, so we shouldn't
 give up that being available by default.

If you use bash or ksh you could just replace /var/log/messages with
(journalctl) in your command line and stuff should just work (when
reading). Other shells can probably do the same. It obviously depends on
journalctl being able to run.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Packaging Go libraries for Fedora

[Lars Seipel]

On Mon, Jul 01, 2013 at 02:39:11PM +0100, Richard W.M. Jones wrote:
 Now as far as I can tell, we can just ignore the $GOPATH stuff, and
 instead drop files into the right places in %_libdir/golang.  It works
 in my single, limited experiment, but I've no idea if this is the
 Right Thing to do.

One issue with this approach is that $GOROOT (i.e. %_libdir/golang)
always takes precedence over $GOPATH. Users would be unable to use
another version of a library that is already installed through RPM.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fatal PCIe error 928 on KVM GPU Passthrough

[Lars Seipel]

On Wed, Jun 19, 2013 at 04:42:30PM +0200, Mario Ceresa wrote:
 does anybody know if it is currently possible to do GPU passthrough in kvm?

You might want to ask that on the Fedora virt list[1] or on upstream
libvirt's users list[2]. The chances for getting good answers should be
much higher there.

[1] https://admin.fedoraproject.org/mailman/listinfo/virt
[2] http://libvirt.org/contact.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Software Management call for RFEs

[Lars Seipel]

On Sat, May 25, 2013 at 09:34:32AM -0400, Nico Kadel-Garcia wrote:
 I think this can be addressed by moving the metadata updates to a
 different function, and calling it *separately* only as needed. The
 Debian apt tool does this quite effectively.

You can kind of simulate that by forcing yum to run from cache only. Use
the -C flag for that.

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

Re: F19 DVD over size - what to drop?

[Lars Seipel]

On Sat, May 04, 2013 at 01:03:11AM -0500, Chris Adams wrote:
 However, unless your installer image is signed, checking RPM signatures
 in anaconda is pointless (which is why the feature you mentioned is
 based on Secure Boot).  If someone was going to the trouble of changing
 the RPM signatures, they could also change the public keys included in
 anaconda.

Hmm.

- the checksums for netinstall images are signed with a Fedora key
- the corresponding public key is made available through https
- therefore the integrity of installer images can be verified

Obtaining an SSL certificate for fedoraproject.org shouldn't be much
easier than getting your code signed to run under Secure Boot. Not
checking RPM signatures seems to be the weakest link here.

What am i missing?

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

Re: Keeping old versions of packages

[Lars Seipel]

On Tuesday 09 April 2013 16:02:14 Richard Hughes wrote:
 now for F18 are really not important at all. Spec file fixups, new
 versions without bugfixes, updated artwork; that can all wait until a
 certain point in the month.

Security-critical updates are already tagged as such, aren't they? So users 
are already able to defer installing non-critical updates to a point in time 
where it's convenient for them. There's even a yum plugin for that.

Maybe the existing tools could be enhanced but changing stuff on the repo side? 
I'm not so sure...

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

Re: Red Hat QXL GPU Driver for Windows 7?

[Lars Seipel]

On Tuesday 08 January 2013 10:36:18 Jeffrey Ollie wrote:
 http://fedoraproject.org/wiki/Features/QXLKMSSupport

No, this feature has nothing to do with Windows. You can get Windows guest 
drivers including a RH-signed QXL driver from here:

http://alt.fedoraproject.org/pub/alt/virtio-win/latest/images/bin/

You can also build from source but then you have to sign them with some 
developer test certificate or something in order to get them loaded on x86-64 
WNT guests.

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

Re: [Bug 872826] f18 anaconda - no option to install bootloader to a partition

[Lars Seipel]

On Monday 03 December 2012 14:58:05 Reindl Harald wrote:
 that is also the reason why /boot has to start on 2048
 while over decades it was not needed

You really want your partitions to be nicely aligned when using SSDs or 
similar.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Rawhide boot problems

[Lars Seipel]

On Monday 10 September 2012 15:14:26 Adam Williamson wrote:
 I don't think that's true, actually. There certainly are devs who take
 advantage of the model.

Exactly. Think glibc as another example. Back then when the glibc people did 
their development work on Branched it was generally viewed as too disruptive. 
So the current development branch is only in Rawhide. F18 has the 2.16 release 
instead which matured in Rawhide since right after F17 was branched off.

Of course, there's nothing in Lennart's proposal which would prevent that way 
of work. But still, the early branching model does have its advantages.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: use of undeclared identifier '__ATOMIC_ACQ_REL' when building llvm-3.1 on Fedora 17

[Lars Seipel]

On Saturday 01 September 2012 15:06:40 Ilyes Gouta wrote:

 and this is with gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC).

This doesn't look like you're building with GCC. Do you have an older version 
of clang somewhere in your path? IIRC llvm's configure script prefers to choose 
clang when it's there. Clang then chokes on the libstdc++ headers.

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

Re: DHCPv6 *still* broken for F17 alpha

[Lars Seipel]

On Wednesday 14 March 2012 13:36:06 Dan Williams wrote:
 Whether we care enough about this regression (if you want to call it
 that) versus enabling default IPv6 connectivity I don't know, I tend to
 think we suck up the regression.

Please do. The current behaviour of tearing down working IPv6 connections is 
just painful IMHO.

 Next up, since AFAIK fdxx:: is a non-routable private network (like 10/8
 right?) should NM say that we're only connected to a site-local network
 here?

That's probably the best thing to do, in both cases, IPv4 and IPv6. What NM 
definitely should not do is say that the connection failed while it's perfectly 
connected to a local network where there is just no link to the internet.

Thanks,
Lars
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /etc/default in Fedora

[Lars Seipel]

On Monday 05 March 2012 21:20:12 Michał Piotrowski wrote:
 Why /etc/default dir is used instead of /etc/sysconfig? To be honest -
 it's not really user friendly from long time RH Linux user POV.

It's what upstream uses. See
http://www.gnu.org/software/grub/manual/grub.html#Simple-configuration

Changing it would invalidate upstream documentation for Fedora users.

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

Re: Unity For Fedora (As in OpenSUSE or Arch)

[Lars Seipel]

On Wednesday 25 January 2012 19:05:37 Manuel Escudero wrote:
 And also I've been told this desktop is available for
 ArchLinux now as well... As for this facts I was wondering
 how feasible is to port Unity to Fedora as well

The last I heard from the Arch packaging efforts was that Unity won't be an 
officially supported package until it no longer depends on non-upstream patches 
to GTK+ and friends. 

The same seems to be true for OpenSuse:
 Since we're replacing some of the core components of openSUSE (ex: GTK+,
 gnome-session) the priority is important.
(pasted from your link)

I don't think I'm going out on a limb if I say that this doesn't look like 
Unity will hit Fedora repos anytime soon. You may look at 
repos.fedorapeople.org, though.

As far as I remember Adam Williamson once looked at the feasibility of 
packaging Unity for Fedora. Don't know what was the result, though. Maybe he 
can elaborate on that.

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

updating xcb-util to 0.3.8 in rawhide?

[Lars Seipel]

Hi there,

is it possible to update rawhide's xcb-util to the current version which was 
released earlier this year?

SONAMES changed so dependent packages will need (at least) a rebuild. 
Apparently, when it was released there was some confusion regarding the 
splitting of some parts into a seperate repo and the merging of -atom, -aux 
and -event into a single library (libxcb-util). A clarifying mail can be found 
here:

http://lists.freedesktop.org/pipermail/xorg/2011-May/053079.html

It would be very nice to get this in in time for F17. As far as I see Mandriva 
is packaging it in Cooker. Debian and Ubuntu are also shipping it.

Michal (Nowak), as you're the maintainer, is there any specific reason it 
wasn't updated yet? Are there any issues with xcb-util 0.3.8 (or its 
dependants) that prevent the new release from going into Fedora until they are 
solved? Or is it just that there wasn't enough time yet?

Thank you.
Lars
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Will we finally get firefox 6.0.1???

[Lars Seipel]

On Friday, September 02, 2011 12:47:06 AM Joshua C. wrote:

 Not exactly. The source code was synced to the mirrors on August 30th,
 so it's more than 3 days...

Like Harald said, the issue is already fixed in Fedora (since August 31th). 
Aside from distrusting a certain CA there were no further changes in Firefox 
6.0.1 AFAIK.

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

Re: GPT in Fedora 16

[Lars Seipel]

On Friday, August 26, 2011 04:58:22 PM Al Dunsmuir wrote:
 On systems where 32-bit is XP is running, one by definition is running
 with  a  disk  of 2 TB or less. Fedora installation must by default do
 the right thing. We need to agree on what that happens to be.

On systems with legacy operating systems installed Fedora does not touch the 
partition table at all. On all other systems GPT is the way to go I'd say...

 On  a  related topic, why in heaven's name is Fedora not including the
 simple  grub  setup commands that are familiar to Ubuntu users? Making
 folks  remember  a long form instead of providing a few helper scripts
 seems short-sighted at best, and arrogant/NIH at worst.

Are those commands included in the upstream Grub 2 tarball? In this case you 
should file a bug to get them included in the Fedora package I think. If not, 
you have a perfect example why people should improve software by working 
upstream.

btw, I just installed F16 on an EFI machine and got Grub Legacy. Are there any 
major problems with Grub 2's EFI support?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Default services enabled

[Lars Seipel]

On Wednesday, August 24, 2011 11:52:23 AM Jesse Keating wrote:

 That would require your nagios (or other monitoring) system to be running
 systemd, which may not be the case for quite a while :)

Why? When used to access remote machines systemctl shouldn't require running 
systemd locally.

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

Re: Default services enabled

[Lars Seipel]

On Sat, 2011-08-20 at 00:13 +0200, Reindl Harald wrote:
 
 if you can give a warning you can also stop the socket
 this is what the user expects and if your software-design
 is not able to act logically it is broken

Stopping the service but leaving the possibility for later socket
activation is a valid use case. Warning about that because it also could
be a mistake is a nice service and sufficient.

 service restart htt
 
 you can type TAb the whole day and will get no auto-completion

Of course not. This is wrong syntax.

systemctl restart htttab

should do what you're trying to accomplish. If you insist on using the
service wrapper script, the appropriate syntax would be:

service htttab restart

It does fine in both cases.

 yes it is a improvent to get htis after the boot but if you restart a server
 you nromally watch the boot and have no reason to login as long you see
 nothing red - this was broken by the usability-pifall how systemd boots

I'm pretty certain that failures are colored red. Are you sure you got
your facts right?

Lars

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

Re: Java 7 for Fedora 16

[Lars Seipel]

On Monday 01 August 2011 13:49:38 Andrew Haley wrote:

 That's not a Java 7 change, it's a new VM bug.  The real cause is that
 optimizations used in an older VM are enabled by default.  I still think
 we'll have to ship 6 and 7 in parallel.

As far as I know there are fixes for these bugs in OpenJDK, though. It's just 
that Oracle won't deliver them in their distribution of Java before update 2.

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

Re: critpath approval process seems rather broken

[Lars Seipel]

On Monday 11 April 2011 13:58:21 Tomasz Torcz wrote:

   So people with cellphone as only internet connectivity option will
 be unable unable to download fixed packages?

Nope. They just have to enter their connection settings manually. Instructions 
were provided by their ISP, probably along with some crappy Windows software. 
Besides, there are numerous other offline places to find that information 
(flyers, 
recent cell phones, etc.). It's really no big deal.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

[Lars Seipel]

On Wednesday 23 February 2011 15:07:55 Peter Jones wrote:

 1) can btrfs do encrypted volumes?

Not yet.  Although this was a planned feature at some point, according to 
Josef, nobody has done it yet.

If you want to stack it on top of dm-crypt there are caveats as well.

From btrfs-wiki:
btrfs volumes on top of dm-crypt block devices (and possibly LVM) require
 write-caching to be turned off on the underlying HDD. Failing to do so, in
 the event of a power failure, may result in corruption not yet handled by
 btrfs code. (2.6.33)

Is this still prevailing as of 2.6.38?

While it may work if you're lucky (at least it did for me since F13) it can 
also munch your data. That's what happened to me last night in F15 (didn't 
lose any data though as such stuff was somewhat expected). Btrfs root partition 
(no LVM) on a dm-crypt volume on Intel 32 GB solid state drive.

After an unclean shutdown I was no longer able to mount the filesystem and 
therefore start the system. I even managed to crash a live system when trying 
to mount the decrypted luks volume containing the btrfs.

As I didn't have much time I just dd'ed an image to a spare disk and 
reinstalled. If there is any debugging value in this, I can make it available 
as long as I can be sure all data could be stripped from it (btrfs-image does 
exactly this, right?).

Be aware that the crash-on-shutdown didn't happen with an official Fedora 
kernel. Due to the update embargo on F15 I built an updated Kernel checked out 
with fedpkg.

If btrfs should become the default filesystem for Fedora (which I strongly 
support) a nice and clean solution for encrypted filesystems has to be found. 
Falling back to ext4  lvm when the encryption checkbox gets ticked is just 
plain ugly. Not supporting encrypted disks at all would be even worse.

Any ideas?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: HEADS UP: KDE/Qt update intentions in Fedora 13 (RFC)

[Lars Seipel]

On Sunday 24 October 2010 20:24:30 Kalev Lember wrote:
 KDE is pretty much self contained, whereas a Qt upgrade affects a much
 larger number of packages. I don't think updating Qt to a new major
 version in a stable Fedora release is a good idea; it just causes too
 much churn.

Nokia managed to upgrade Qt to 4.7 in their Maemo distribution and it got 
pushed to all devices without causing any problems so far. Their standards for 
avoiding churn are pretty high and their update scheme is extremely 
conservative for stable releases. Nevertheless they updated Qt. But they have 
a pretty good reason for doing that (aligning with future versions of MeeGo 
and Symbian). So what does a F13 user gain from an upgrade? Is it worth the 
risks?

F13 isn't what bleeding-edge users are likely to run in the future. Those can 
easily upgrade to F14 and enjoy the latest stuff. So it's not like they are 
forced to run a periodical broken rawhide with no security support if they 
want recent software. I like the idea of Fn getting major updates whereas Fn-1 
(that's what F13 is very soon) only gets those updates which are needed for 
fixing bugs and security issues.

So if the open issues regarding QtWebkit can be solved I agree that leaving Qt 
at 4.6.x is just fine.  If not there ain't much choice as it is pretty much 
guaranteed that Webkit will have security issues which are mandatory to fix. If 
upstream only supports 4.7 and backporting isn't an option (which seems to be 
the case according to jreznik) Qt 4.6 has to go unless some other solution can 
be implemented before F13 goes EOL. ;)

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

Re: Ubuntu 10.10's installer looks rather nice

[Lars Seipel]

On Tuesday 12 October 2010 21:28:24 Evan Dandrea wrote:

 You absolutely can automate it, using the same preseeding mechanism found
 in debian-installer. 

Thanks for the info. Didn't know Debian preseeding can be used with the Ubuntu 
live installer as well. That boosts usability to another level when installing 
on more than one computer is desired and other techniques aren't feasible.

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

Re: Ubuntu 10.10's installer looks rather nice

[Lars Seipel]

On Tuesday 12 October 2010 15:56:02 Dennis Jacobfeuerborn wrote:
 Now we are really talking semantics. The point is that users should not be
 confronted with choices they don't really need to make or they don't
 understand.

I disagree. How should a user know about some nice feature if its whole 
existence is hidden from his eyes? Yeah, he should read the documentation but 
aren't we talking about improving usability right now? Imagine some random 
user does his installs the hard way for years and now discovers (someone tells 
him oder he learns about it by chance by searching the documentation for an 
unrelated problem) that Anaconda has the capabilities to make his life easier.

He goes like: Woow cool, this is the stuff I've been searching for years. I 
don't have to waste my precious time anymore by setting all of this up by 
hand. Anaconda now takes care of it. Didn't thought those Anaconda developers 
are that genious. But why on earth didn't they tell me before their software 
was capable of doing that? Do they actually like watching people suffer? 
Seriously, you guys suck!

Hiding features doesn't have to be beneficial to usability. It can be harmful, 
too.

 As long as most of these defaults and menus are not displayed initially
 that would probably be fine.
 The problem here is that every time you present the user with data dumps
 (e.g. lists of defaults) or menus you create a cognitive hurdle where the
 user wonders what he's supposed to do or gets worried that he breaks
 something. Minimizing that is really key to creating a streamlined
 installation interface.

There are other ways to prevent confusion and worries about potential 
brokenness. If there are sane defaults and it is clearly communicated to the 
user that using those is the recommended way and gives him the best results in 
most cases, I don't see a problem. If users can trust in those defaults being 
sane and that by not touching them they get a good default configuration, they 
aren't helpless as they know what to do. However, if they wish to change 
something in future attempts they already know where they have to look. 

 new installed system. The user doesn't care at all about partitions,
 LVM or mountpoints.

I think you are strongly limiting the definition of what an user can be. So who 
is an user of Anaconda? For me, that is all those people using Anaconda. There 
is some guy from your neighborhood installing Fedora to surf the internet. 
There is some developer installing Fedora to work on the latest and greatest 
software in the GNU/Linux/X/freedesktop.org stack. There are designers using 
Anaconda to install the free software they need to create your favorite 
layout. There are also sysadmins deploying Fedora/RHEL/CentOS to many 
computers in their company, a public school or at your ISP's datacenter. So 
when you restrict Anaconda's userbase to just one kind of user, the whole 
assumption on which you build your enhancements to usability is wrong and will 
lead to software which sucks in usability as soon as you want to do something 
that you didn't consider basic enough to show it to users.

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

Re: Ubuntu 10.10's installer looks rather nice

[Lars Seipel]

On Monday 11 October 2010 12:41:13 Richard W.M. Jones wrote:
 This is in contrast to anaconda (certainly from the live CD install)
 which seems to be a usability no-go area.
 
 Thoughts?  Can we switch to their installer?
 
 Rich.

It may be nice usability-wise but it lacks support for LVM2, LUKS disk 
encryption and practically everything more advanced. It can't be automated 
using some equivalent to kickstart and it fails at all the stuff Anaconda 
subsumes unter advanced storage devices. You can't even do the install from 
some remote place without setting anything up by hand. Ubuntu users requiring 
more than these very basic features have to go for the Debian text mode 
installer Ubuntu ships on their alternate media. 

Striving for usability and pleasantness for the untechnical users certainly is 
a good thing. It gets problematic when you choose to make things technically 
inferior just to please those kind of users.

So I don't think it's a good idea to switch to this, even if it was trivially 
possible to use with Fedora. But there's nothing preventing us to take the 
ubiquity features we enjoy most and enable Anaconda to do something similar.

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