Re: mingw sysroot paths (and generalizing them)

[David Michael]

On Fri, Apr 28, 2023 at 9:13 AM Daniel P. Berrangé  wrote:
> On Fri, Apr 28, 2023 at 01:41:05PM +0100, Richard W.M. Jones wrote:
> > On Fri, Apr 28, 2023 at 02:22:40PM +0200, Florian Weimer wrote:
> > > Looking at
> > >
> > >   Information for RPM mingw64-zlib-1.2.13-2.fc38.noarch.rpm
> > >   
> > >
> > > sysroot paths look like this:
> > >
> > >   /usr/x86_64-w64-mingw32/sys-root/mingw/bin/zlib1.dll
> > >   /usr/x86_64-w64-mingw32/sys-root/mingw/include/zconf.h
> > >   /usr/x86_64-w64-mingw32/sys-root/mingw/include/zlib.h
> > >   /usr/x86_64-w64-mingw32/sys-root/mingw/lib/libz.dll.a
> > >   /usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig/zlib.pc
> > >
> > > Is the /mingw/ part of the sysroot path, or is it within the sysroot?
> > > Would I use --sysroot=/usr/x86_64-w64-mingw32/sys-root or
> > > --sysroot=/usr/x86_64-w64-mingw32/sys-root/mingw to build against the
> > > sysroot?
> > >
> > > I assumed the latter, but now I wonder if /mingw in the sysroot is the
> > > analogue of /usr in GNU/Linux sysroots.
> >
> > FWIW:
> >
> > $ x86_64-w64-mingw32-gcc -print-sysroot
> > /usr/x86_64-w64-mingw32/sys-root
> >
> > which would indicate that you are correct that /mingw is somehow
> > "inside" the sysroot.
>
> Then on the Meson side we define
>
>   root = '/usr/i686-w64-mingw32/sys-root/mingw'
>
> in the /usr/share/mingw/toolchain-mingw32.meson spec, while with
> configure we invoke
>
>   configure \
> --host=i686-w64-mingw32 \
> --build=x86_64-redhat-linux-gnu \
> --target=i686-w64-mingw32 \
> --prefix=/usr/i686-w64-mingw32/sys-root/mingw \
> --exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw \
> --bindir=/usr/i686-w64-mingw32/sys-root/mingw/bin \
> --sbindir=/usr/i686-w64-mingw32/sys-root/mingw/sbin \
> --sysconfdir=/usr/i686-w64-mingw32/sys-root/mingw/etc \
> --datadir=/usr/i686-w64-mingw32/sys-root/mingw/share \
> --includedir=/usr/i686-w64-mingw32/sys-root/mingw/include \
> --libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib \
> --libexecdir=/usr/i686-w64-mingw32/sys-root/mingw/libexec \
> --localstatedir=/usr/i686-w64-mingw32/sys-root/mingw/var \
> --sharedstatedir=/usr/i686-w64-mingw32/sys-root/mingw/com \
> --mandir=/usr/i686-w64-mingw32/sys-root/mingw/share/man \
> --infodir=/usr/i686-w64-mingw32/sys-root/mingw/share/info \
>
> is there any difference between the notion of the 'sysroot' vs
> the install 'prefix' ?

There is at least one minor difference which I recently encountered
with musl packaging:  The gcc/cpp/ld --sysroot option rewrites paths
that include the configured /usr prefix, so e.g.

gcc --sysroot=/usr/x86_64-SYSROOT-linux-gnu -E -Wp,-v -xc /dev/null

shows that it will only search
/usr/x86_64-SYSROOT-linux-gnu/usr/include for headers.  It would be
nice if all new sysroots standardized on a prefix of $SYSROOT/usr
since it's useful for quickly building small things without needing a
build system, but it's a minor detail overall.

Thanks.

David
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Firecracker microVM manager

[David Michael]

On Sat, Apr 22, 2023 at 10:48 AM Matthew Miller
 wrote:
> On Sat, Apr 22, 2023 at 10:13:31AM -0400, David Michael wrote:
> > > Would it be possible to add a warning to this effect?  Without any form
> > > of sandboxing Firecracker is not suitable for production use.
> > Where would such a warning be placed?  The sandboxing is done by a
> > standalone program[0] which is not built in the package, so it should
> > be clear that it isn't available.
>
> Silly question: would it make any sense at all to use _podman_ as a
> replacement for firecracker's jailer?

That would certainly be convenient and support use cases like with
krun, but I'd need to do more research around producing a compatible
podman runtime.  I've seen a few container runtime integration
projects for Firecracker, some abandoned.  Maybe pursuing the Kata
runtime would be the best fit for Fedora since it's already packaged?
(Although I see Kata still wants Firecracker's jailer program, and I
don't know if it's optional or not.)

Thanks.

David
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Firecracker microVM manager

[David Michael]

On Fri, Apr 21, 2023 at 10:02 PM Demi Marie Obenour
 wrote:
> On 4/21/23 11:13, David Michael wrote:
> > Hi,
> >
> > Following up on this, Firecracker has been accepted and submitted to
> > Fedora.  Thanks to Fabio for all of the Rust reviews.
> >
> > F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-dca8124d3b
> > F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-edcbcf18e0
> >
> > Some quick comments on the TODO from the original e-mail:
> >
> > On Sat, Mar 4, 2023 at 12:40 PM David Michael  wrote:
> >>   - The musl package adds /usr paths for compatibility with the compiler 
> >> --sysroot option.
> >>   - The rust compiler adds musl target subpackages.
> >
> > Targeting musl was dropped after the initial discussion, so there is
> > no sandbox or seccomp filter in Fedora until that can be implemented
> > with dynamic linking glibc upstream.  I'll keep the Copr repo[0]
> > active for a while to provide musl builds.
>
> Would it be possible to add a warning to this effect?  Without any form
> of sandboxing Firecracker is not suitable for production use.

Where would such a warning be placed?  The sandboxing is done by a
standalone program[0] which is not built in the package, so it should
be clear that it isn't available.

> Does the
> sandboxed portion of Firecracker do anything that would require an NSS
> (name service switch) lookup, such as DNS or username resolution?

I don't think NSS lookups are an issue since the program takes
numerical UID/GID values as command-line arguments.  The main breaking
issue with the jailer is that it requires Firecracker to be a single
static binary[1] (which is the musl target's default output upstream).
Their documentation also says glibc isn't supported, but I haven't
tried making a static glibc binary to see what fails.  The seccomp
filter being unimplemented for glibc is a separate issue from the
jailer.

> If
> not, then I don’t see why musl (which Fedora already ships!) would be a
> problem.

There is no problem technically; the Copr repo[2] is building
Firecracker RPMs with musl.  Maintainers of both Rust and musl seemed
to be against it in Fedora.  From this thread:

On Sat, Mar 4, 2023 at 5:51 PM Neal Gompa  wrote:
> As the musl package maintainer, I don't particularly want Fedora
> packages depending on it unless they absolutely have to.
> [...]
> As in musl is statically linked into the binaries? Or the Rust code is
> statically linked. The former is not okay,

From the Firecracker package review:

On Fri, Apr 7, 2023 at 11:27 AM  wrote:
> 2. Building for the *-musl Rust targets is not going to be supported in Fedora

For what it's worth, Arch and openSUSE seem to be building with glibc
and so are in the same position with this package.  Without Rust's
musl target, the only path forward is to try to improve glibc support
upstream.

Thanks.

David

[0] https://github.com/firecracker-microvm/firecracker/blob/main/docs/jailer.md
[1] 
https://github.com/firecracker-microvm/firecracker/blob/v1.3.1/src/jailer/src/env.rs#L380
[2] https://copr.fedorainfracloud.org/coprs/dm0/Firecracker
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Firecracker microVM manager

[David Michael]

Hi,

Following up on this, Firecracker has been accepted and submitted to
Fedora.  Thanks to Fabio for all of the Rust reviews.

F37 https://bodhi.fedoraproject.org/updates/FEDORA-2023-dca8124d3b
F38 https://bodhi.fedoraproject.org/updates/FEDORA-2023-edcbcf18e0

Some quick comments on the TODO from the original e-mail:

On Sat, Mar 4, 2023 at 12:40 PM David Michael  wrote:
>   - The musl package adds /usr paths for compatibility with the compiler 
> --sysroot option.
>   - The rust compiler adds musl target subpackages.

Targeting musl was dropped after the initial discussion, so there is
no sandbox or seccomp filter in Fedora until that can be implemented
with dynamic linking glibc upstream.  I'll keep the Copr repo[0]
active for a while to provide musl builds.

>   - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be usable as 
> a guest.

I fixed this in rawhide during the 6.3 cycle, so it should eventually
trickle down into stable.

>   - About two dozen Rust crates must be added to Fedora (but a handful are 
> just new versions of existing packages).

All crate dependencies have been added to Fedora 37+.

If anyone would like to test the Bodhi updates, there are some example
commands to start a VM on the Copr repo.

Thanks.

David

[0] https://copr.fedorainfracloud.org/coprs/dm0/Firecracker
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Firecracker microVM manager

[David Michael]

On Sat, Mar 4, 2023 at 5:51 PM Neal Gompa  wrote:
> On Sat, Mar 4, 2023 at 12:41 PM David Michael  wrote:
> > Hi,
> >
> > Firecracker[0] is a minimal virtual machine manager (a la QEMU)
> > written in Rust that uses KVM to start Linux VMs extremely quickly and
> > securely.  It is used by AWS Lambda and Fargate among other things to
> > make VM startup time comparable to containers.  I've built it for
> > Fedora x86_64 and shared it in a Copr repository[1] which includes
> > some example commands for starting VMs.
> >
> > Making it build for Fedora required changes across a few components,
> > so I'm writing to ask if this is acceptable for inclusion in Fedora.
> > The Copr specs are all dumped in a Git repository[2] for readability.
> > Changes include:
> >
> >   - The musl package adds /usr paths for compatibility with the
> > compiler --sysroot option.
>
> As the musl package maintainer, I don't particularly want Fedora
> packages depending on it unless they absolutely have to. I originally
> maintained it in Copr, but brought it into Fedora for the Enarx folks.
> I still maintain that generally you don't want to use this unless you
> *really* know what you're doing and can deal with the consequences of
> using an alternative libc.

It sounds like there are enough issues with musl in Fedora that glibc
will have to be used.

> That said, the changes you make are not currently compatible with the
> packaging guidelines. Can't you just use --prefix /usr/
> instead?

It was for using --sysroot directly on gcc calls.

> >   - The rust compiler adds musl target subpackages.
>
> This will require discussion with the Fedora Rust SIG.
>
> >   - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be
> > usable as a guest.
>
> This will require talking to the kernel maintainers to add the flag.

Okay, I'll ask about getting this applied even if Firecracker is not
included in Fedora.  It still might be useful to use for a quick guest
kernel, and the option is just to support a command-line parameter[0],
so it shouldn't be disruptive.

[0] 
https://github.com/torvalds/linux/blob/v6.2/Documentation/admin-guide/kernel-parameters.txt#L6697

> >   - About two dozen Rust crates must be added to Fedora (but a handful
> > are just new versions of existing packages).
> >   - Unrelated, but in the Copr repo anyway: The musl package is fixed
> > to allow multilib installs, and Rust includes both 32- and 64-bit
> > targets.
> >
> > I used upstream-preferred settings when adding things, but they may be
> > in conflict with Fedora guidelines.  Here are some concerns:
> >
> >   - Firecracker can be built with Fedora's libc (glibc), but it is
> > officially unsupported upstream[3].  Functionality would be harmed by
> > not using musl, e.g. seccomp filters are not used.
>
> Why not drive this to be fixed upstream? Also, openSUSE builds
> Firecracker against glibc and I see the seccomp stuff is also produced
> and shipped[1]. I am not sure whether this means openSUSE's package is
> broken or something else.
>
> [1]: 
> https://code.opensuse.org/package/firecracker/blob/master/f/firecracker.spec

I can look into what they're doing more thoroughly later, but I would
assume they are just running with the empty seccomp filter.  I am
aware of two issues with glibc:  The jailer program allegedly does not
work with non-musl (although it builds) and is disabled upstream[1],
and there is no non-musl seccomp filter[2][3].

[1] https://github.com/firecracker-microvm/firecracker/pull/2125
[2] 
https://github.com/firecracker-microvm/firecracker/blob/v1.3.0/src/vmm/build.rs#L25
[3] 
https://github.com/firecracker-microvm/firecracker/tree/v1.3.0/resources/seccomp

> >   - Upstream Rust wants musl targets to be statically linked by
> > default[4].  It can be changed by patching (Gentoo does this) if
> > dynamic linking is still a priority with Rust binaries, but I haven't
> > tested that.
>
> As in musl is statically linked into the binaries? Or the Rust code is
> statically linked. The former is not okay, the latter is what we do
> already.

The former, the musl targets produce static binaries by default.

> >   - Firecracker uses two crates forked from crates.io, but they are
> > not vendored/bundled nor published to a registry.  I'm currently
> > manually bundling them as if they were vendored to avoid package name
> > conflicts since nothing else uses them, but I don't know the preferred
> > way to deal with those.
> >
>
> That's probably the right way to deal with it.
>
> > So does any of that sound like a showstopper for being included in
> > Fedora?  Is there any other interest in the pr

Firecracker microVM manager

[David Michael]

Hi,

Firecracker[0] is a minimal virtual machine manager (a la QEMU)
written in Rust that uses KVM to start Linux VMs extremely quickly and
securely.  It is used by AWS Lambda and Fargate among other things to
make VM startup time comparable to containers.  I've built it for
Fedora x86_64 and shared it in a Copr repository[1] which includes
some example commands for starting VMs.

Making it build for Fedora required changes across a few components,
so I'm writing to ask if this is acceptable for inclusion in Fedora.
The Copr specs are all dumped in a Git repository[2] for readability.
Changes include:

  - The musl package adds /usr paths for compatibility with the
compiler --sysroot option.
  - The rust compiler adds musl target subpackages.
  - The kernel must set CONFIG_VIRTIO_MMIO_CMDLINE_DEVICES=y to be
usable as a guest.
  - About two dozen Rust crates must be added to Fedora (but a handful
are just new versions of existing packages).
  - Unrelated, but in the Copr repo anyway: The musl package is fixed
to allow multilib installs, and Rust includes both 32- and 64-bit
targets.

I used upstream-preferred settings when adding things, but they may be
in conflict with Fedora guidelines.  Here are some concerns:

  - Firecracker can be built with Fedora's libc (glibc), but it is
officially unsupported upstream[3].  Functionality would be harmed by
not using musl, e.g. seccomp filters are not used.
  - Upstream Rust wants musl targets to be statically linked by
default[4].  It can be changed by patching (Gentoo does this) if
dynamic linking is still a priority with Rust binaries, but I haven't
tested that.
  - Firecracker uses two crates forked from crates.io, but they are
not vendored/bundled nor published to a registry.  I'm currently
manually bundling them as if they were vendored to avoid package name
conflicts since nothing else uses them, but I don't know the preferred
way to deal with those.

So does any of that sound like a showstopper for being included in
Fedora?  Is there any other interest in the project from the
community?

Thanks.

David

[0] https://firecracker-microvm.github.io/
[1] https://copr.fedorainfracloud.org/coprs/dm0/Firecracker
[2] https://github.com/dm0-/copr-firecracker
[3] 
https://github.com/firecracker-microvm/firecracker/blob/v1.3.0/tools/release.sh#L145
[4] 
https://github.com/rust-lang/rust/blob/1.67.1/compiler/rustc_target/src/spec/linux_musl_base.rs#L13
___
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, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: The future of legacy BIOS support in Fedora.

[David Michael]

On Wed, Jul 1, 2020 at 5:51 PM Neal Gompa  wrote:
> The core of it is that nobody cares. It comes up at least once or
> twice every development cycle in the Workstation Working Group
> meetings, but there's nothing we can do. Sometimes I'll get bullshit
> answers from people. Sometimes they'll just say stuff about security.
> Sometimes they'll say something about it being NVIDIA's problem.

Is there a bug filed for this that I can follow?  I didn't see one
from a quick search.

Personally, I use my own Secure Boot keys and sign the modules from
akmods with that.  It works fine with the cert in db since that gets
it loaded into the platform keyring.  I'd like to see the
extract-vmlinux and/or insert-sys-cert kernel programs learn how to
repack vmlinux back into an existing vmlinuz so that
CONFIG_SYSTEM_EXTRA_CERTIFICATE can be useful with UEFI, and I could
have a separate module signing key and Secure Boot key.

Thanks.

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

Comaintainer(s) wanted: erofs-utils

[David Michael]

Hi,

EROFS[1] is a relatively new read-only file system focused on
efficiency with optional compression, currently used by many Android
devices.

I've added the EROFS userspace utilities package[2] to Fedora, but I
think it would be good to have a comaintainer so the file system
support is not dependent on a single person.  There are no open tasks
for the package (unless you want to implement features upstream).  The
upstream code[3] doesn't have a lot of churn, and I will handle any
bugs and updates.  Also, Fedora's kernel support is only enabled in
5.5, so the package probably won't see much use for a couple months
until the releases' kernels are rebased.

If you're an interested Fedora packager, let me know your FAS ID, and
I'll add you to the repository.

Thanks.

David

[1] https://en.wikipedia.org/wiki/EROFS
[2] https://src.fedoraproject.org/rpms/erofs-utils
[3] https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Orphaning moby-engine (Docker)

[David Michael]

On Thu, Jul 11, 2019 at 5:22 PM Olivier Lemasle  wrote:
> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
> > I have orphaned moby-engine, the community Docker package in Fedora,
> > due to no longer working in a role where I can maintain it as part of
> > the job.  If anyone wants to take it, it is up to date in F30 and
> > rawhide branches (F29 was not updated for compatibility since it
> > doesn't enable SELinux), but there is an open issue that should be
> > addressed before pushing new updates:  Docker 18.09 and later
> > conflicts with runc and containerd since it dropped "docker-" prefixes
> > from its binaries.  I can describe some options and backstory if
> > needed, but I suppose you could address it however you want as the new
> > maintainer.
> >
>
> I'm open to maintaining this package. However, what was the reason
> "moby-engine" packaged its own version of runc and containerd, both
> packaged on their own in Fedora?

Each upstream Docker release targets a specific commit of each
component (containerd, proxy, runc, and tini) specified at:

https://github.com/docker/docker-ce/tree/v18.09.7/components/engine/hack/dockerfile/install

These specific commits are basically considered part of the release;
e.g. they are included in the Docker versions' release notes.  I'm not
aware of the initial decision to bundle the components in the Fedora
package since it was done that way from the beginning before I was a
maintainer (I'd assume it was due to previous Docker versions using
forks of the containerd and runc repos), but from experience
maintaining it for another distro, upstream would send user bug
reports back to you as the distro maintainer if there is any deviation
from what they're shipping.  It might end up being less maintenance
work by not unbundling the specified versions.

Also, when I started maintaining it for Fedora, it was explained to me
that moby-engine should follow upstream to provide an expected Docker
experience on Fedora CoreOS (since any specialized container needs
would be implemented in podman), but I don't think it is a priority
for that team anymore.  You can probably do whatever you think is best
at this point.

Thanks.

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

Re: Orphaning moby-engine (Docker)

[David Michael]

On Wed, Jul 3, 2019 at 5:15 PM Robert-André Mauchin  wrote:
> On Wednesday, 3 July 2019 19:56:47 CEST David Michael wrote:
> > I have orphaned moby-engine, the community Docker package in Fedora,
> > due to no longer working in a role where I can maintain it as part of
> > the job.  If anyone wants to take it, it is up to date in F30 and
> > rawhide branches (F29 was not updated for compatibility since it
> > doesn't enable SELinux), but there is an open issue that should be
> > addressed before pushing new updates:  Docker 18.09 and later
> > conflicts with runc and containerd since it dropped "docker-" prefixes
> > from its binaries.  I can describe some options and backstory if
> > needed, but I suppose you could address it however you want as the new
> > maintainer.
> >
> > Thanks.
> >
> > David
>
>
> Wasn't there a « Container team » taking care of those packages?

It was only me for about the last year, and still a single maintainer
before that.  Maybe you mean the packages named "docker" or
"docker-latest"?  They remained on years-old versions and have been
retired in rawhide for legal reasons, so now moby-engine is the only
Docker package in Fedora.  I think there is still an internal team
maintaining the old Docker packages for RHEL, but they have not been
involved with this.

Thanks.

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

Orphaning moby-engine (Docker)

[David Michael]

I have orphaned moby-engine, the community Docker package in Fedora,
due to no longer working in a role where I can maintain it as part of
the job.  If anyone wants to take it, it is up to date in F30 and
rawhide branches (F29 was not updated for compatibility since it
doesn't enable SELinux), but there is an open issue that should be
addressed before pushing new updates:  Docker 18.09 and later
conflicts with runc and containerd since it dropped "docker-" prefixes
from its binaries.  I can describe some options and backstory if
needed, but I suppose you could address it however you want as the new
maintainer.

Thanks.

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

Fedora Hurd Compilers

[David Michael]

Fedora developers:

It's GNU's 30th birthday today, so I thought I'd upload a relevant
side project of mine: a package to cross-compile a GNU (Hurd)
operating system using Fedora.

https://github.com/dm0-/gnuxc


No pre-compiled binaries are provided; everything is built from
(mostly) unpatched upstream sources.  There are two main components to
the build process.

First:  The Fedora development environment (sysroot and cross-tools)
is maintained in RPMs.  Bootstrap the environment with the
setup-sysroot.sh script.

Second:  There are make files to build the GNU system.  They are
called from the main GNUmakefile.  Most of these make rules can be
used on the running GNU system itself to rebuild packages natively.

The BUILD.md file documents the step-by-step procedure to create and
run a complete virtual operating system.


I began this project as a learning experience earlier in the year and
have been fiddling with it in my spare time since.  It's nowhere near
what I would consider finished, but it does create something usable
up to a graphical desktop environment.

It is uploaded for anyone interested to learn about cross-compiling or
building a free OS from source.  It is not intended to provide a
primary desktop OS, since there are still many problems to be
addressed.  (I'd recommend trying Debian Hurd instead, if a more
stable Hurd system is your goal.)


I'll try to remember to push my updates to the repo occasionally.
Feel free to clone it and do whatever you want to it.

Happy Hacking

dm0
-- 
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: on /etc/sysconfig

[David Michael]

Hi,

On Mon, Jul 18, 2011 at 4:42 PM, mike cloaked mike.cloa...@gmail.com wrote:
 what then out of interest is the replacement for a
 /etc/sysconfig/desktop file that defines which login manager should be
 the default (and which is not there by default)? Can KDM then be
 started when X starts and not GDM without the use of the above file?

I recently brought up this question on systemd-devel as I was
packaging a desktop environment with a display manager, and it sounded
like there would be a push to move away from prefdm itself in favor of
giving each display manager a service file.  I implemented this in the
package and switch between display managers with the following command
(with newdm being the selected one).

ln -fs /lib/systemd/system/newdm.service
/etc/systemd/system/display-manager.service

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

Re: on /etc/sysconfig

[David Michael]

Hi,

On Mon, Jul 18, 2011 at 5:16 PM, Bill Nottingham nott...@redhat.com wrote:
 Right, but that then causes 'last one wins' behavior among multiple DMs.

 I suppose we could use alternatives for this, as much as I dislike it.

I meant creating that symlink was the replacement for
/etc/sysconfig/desktop, the end-user configuration.

As for what packages do about their DM service files, I would agree
with letting alternatives manage a default
/lib/systemd/system/display-manager.service symlink, but leave the one
in /etc for the users to specify.

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

Re: on /etc/sysconfig

[David Michael]

Hi,

On Mon, Jul 18, 2011 at 5:32 PM, Kay Sievers kay.siev...@vrfy.org wrote:
 We should not let packages create config files in lib, lib is more for
 static content from rpms, not really for configuration. For the same
 reason, 'systemctl enable/disable' acts on /etc only.

I had imagined using alternatives would allow the symlink
/lib/systemd/system/display-manager.service to be provided by
systemd-units (as it is now), just pointed at /etc/alternatives
instead of prefdm.service.

 The link in etc would need to be managed by alternatives, but I'm not
 sure, if it's really necessary.

In order to do that, wouldn't an RPM have to own the service link in
/etc?  I was under the impression that packages weren't supposed to
own anything under /etc/systemd/system.

Regardless, I think I'm off-topic from the rest of the thread, so I
will leave these details alone for the time being.

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

Re: systemd and filesystems with noauto

[David Michael]

On Mon, Aug 23, 2010 at 11:51 AM, Lennart Poettering
mzerq...@0pointer.de wrote:
 i.e. auto → wait for this on boot; noauto → don't delay boot for this.

I may be wrong, but wasn't there already a bootwait and nobootwait
defined for this behavior?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: systemd and filesystems with noauto

[David Michael]

On Mon, Aug 23, 2010 at 12:32 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
 On Mon, 23.08.10 12:23, David Michael (fedora@gmail.com) wrote:

 On Mon, Aug 23, 2010 at 11:51 AM, Lennart Poettering
 mzerq...@0pointer.de wrote:
  i.e. auto → wait for this on boot; noauto → don't delay boot for this.

 I may be wrong, but wasn't there already a bootwait and nobootwait
 defined for this behavior?

 I see no such option documented anywhere?

Google responds to nobootwait with many Ubuntu forums etc. where
people are apparently using it, but I didn't see any official-looking
documentation.  Perhaps it's a Debian thing; I just remembered seeing
those fstab options somewhere.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: in f13 =~ no longer working in bash

[David Michael]

On Tue, Jun 8, 2010 at 8:14 AM, Farkas Levente lfar...@lfarkas.org wrote:
 hi,
 =~ no longer working in bash. just try this little line:
 -
 if [[ abc =~ abc.* ]]; then echo inside; else echo outside; fi
 -
 this give inside up to fedora-12, but it gives
 outside in fedora-13.
 imho it's a serious changes since all shell script will fail which use
 =~ :-(
 is there any reason for this? or any quick fixes?

Try removing the quotes from the regular expression, or at least the
asterisk.  Alternatively, you can use something like `grep -Eq abc.*
 abc` for extended regular expressions with the expected
quoted-token behavior.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: i386-class support changed in F-13?

[David Michael]

On Wed, Jun 2, 2010 at 2:39 AM, Peter Robinson pbrobin...@gmail.com wrote:
 It does work in F-12, the response for the lack of support in F-13 was
 'deal with it'. There is suppose to be a patch to emulate it in the
 kernel but apparently it won't go upstream until its a generic infra
 patch that can allow support of other emulated bits in other cpus in a
 generic way. So its possible it will come back, but I don't hold up
 hope of a quick resolution. Which leaves us in a big predicament as to
 how we're going to support the 1.5 million odd XO-1s out there moving
 forward.

  I believe this was the latest post of the NOPL emulation patch:
http://lkml.org/lkml/2010/3/1/430  This is not the general instruction
emulator mentioned, but a fix intended just for getting the Geode LX
classed as i686.

  I haven't used this patch myself yet; my Geode LX machine runs an
older Fedora, so it still works.  I suppose I'll need to try the patch
during the next upgrade until things are settled.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: i386-class support changed in F-13?

[David Michael]

Hi,

On Wed, Jun 2, 2010 at 11:42 AM, Richard W.M. Jones rjo...@redhat.com wrote:
 I wonder what the performance impact is.  NOPL appears to be a
 variable length NOP (no-op).  Obviously a very useful instruction for
 things like alignment, and gcc seems to stuff lots of them into the
 code:

  $ objdump -d /bin/ls | wc -l
  16867
  $ objdump -d /bin/ls | grep nopl | wc -l
  369

  369/16867 ~ 2%

 This is not a very fair comparison because we'd want to know how
 frequently NOPL is executed, but I hope it shows that these
 instructions are not infrequent.

  I recall checking this when F12 was declared to go i686 but retain
support for Geode LX CPUs.  NOPLs were common in x86_64, but seemed to
be very infrequent in 32-bit land (which is what would run on a Geode
anyway).

  To see if this is still the case, I downloaded and extracted F13's
32-bit coreutils, and no binary appears to contain a single NOPL.
(Though I get a similar result as your test with x86_64.)

objdump -d {,usr/}{,s}bin/* | grep -Fc nopl
0

 Having said that, AMD Geodes are sloww anyway ...

  I wouldn't exactly use it as a gaming rig, but a silent wireless
computer on 5W power can always be used for something.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel