Re: CI projects in Copr

[Gerd Hoffmann]

  Hi,

> Right, this is cool. The problem is that the upstream repo would need
> to be configured to provide a public message that something has been
> changed
> in it (i.e. new release) so the question is how to do this part.

Ah, right, setting up a webhook needs access to the upstream repo too.

Add support for polling then?  Possibly at large intervals only to cap
the resources spent on this?  Maybe once per day, so one could do
nightly builds with this?

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CI projects in Copr

[Gerd Hoffmann]

  Hi,

> It's easier on implementation. That's the main reason. I generally
> believe that 
> what's easier on implementation is better.

It's maybe easier on the copr side, but not for the copr users ...

If you can modify the upstream project (either because you are
upstream, or in case upstream is willing to accept patches for copr
support) you can just use tito and be done with it.

If you can't modify upstream it starts to become difficult ...

So, what would be really helpful, especially for CI with the option to
build and test every upstream commit, would be support for *two* git
repos.  One git repo where the spec-file and other build-related stuff
lives (distgit like).  One git repo where the unmodified upstream
source lives.  Updates on either repo triggers a build.  The build runs
"git archive" on the upstream repo to generate the tarball and tweaks
the specfile (Source and Release tags probably) before kicking off mock
for the actual build.

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Please provide "Minimal CD" of Fedora

[Gerd Hoffmann]

On So, 2017-02-19 at 16:30 +, Fa Be wrote:
> Excuse me, I mean the network traffic. I have a internet service with
> only 4GB per month, and I must use it carefully due to various needs.
> Minimal CD is the excellent option for people like me, Net Install is
> not good enough, because it need to internet and huge data for every
> install, but Minimal CD is similar to the Live DVD option, it can
> installed without limit on the number and does not need to internt.

FYI: I'm running a big squid cache, and everything (yum, mock, ...) is
configured to (a) use a fixed mirror and (b) use the squid as proxy.
That nicely avoids downloading the same packages over my slow internet
link again and again.  Works not only for fresh installs (use
inst.proxy=$uri), but for updates too.

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: nfs-utils-2.1.1 Changes Everything!

[Gerd Hoffmann]

  Hi,

> > A hard break for Fedora 26 or 27 still makes me wonder why there's no
> > migration tool or script, rather than expect people with possibly
> > complex setups to have to redo configuration by hand? 
> Yes.. this is the problem.. How does one migrate from one configuration
> model to another... smoothly...

Package /etc/nfs.conf as ghost, then in post-install:

 (1) If /etc/nfs.conf exists, don't touch it.
 (2) Otherwise, if /etc/syconfig/nfs exists, generate /etc/nfs.conf
 using the sysconfig settings
 (3) Otherwise copy default config from /usr/share/doc

> easily... In theory... There is talk about moving /etc/nfsmout.conf and
> /etc/idmount.conf into /etc/nfs.conf...

You might want to wait until this happened, that'll surely simplify the
transition.

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cross-compiler support?

[Gerd Hoffmann]

On Di, 2016-12-20 at 09:28 +, David Howells wrote:
> Igor Gnatenko  wrote:
> 
> > > Well there is gcc-arm-linux-gnu for example but that's for kernels per
> > > description
> > Didn't see it before... But looks like it doesn't work either:
> > /usr/bin/arm-linux-gnu-ld: cannot find crt1.o: No such file or directory
> > /usr/bin/arm-linux-gnu-ld: cannot find crti.o: No such file or directory
> > /usr/bin/arm-linux-gnu-ld: cannot find -lc
> > /usr/bin/arm-linux-gnu-ld: cannot find crtn.o: No such file or directory
> 
> Yeah - it's intended for building kernels (though it can build anything that
> provides its own userspace).

FYI: they also work great for building qemu firmware.

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable coredumpctl by default

[Gerd Hoffmann]

  Hi,

> We have two technologies: ABRT and coredumpctl. Each of them have
> different purpose and none of them 100 % fit
> everybody. So instead of discussing which one should be installed by
> default, we can sit together (ABRT and systemd
> teams) and integrate it together? So users can get benefits of both
> services.

Hmm, isn't this as easy as abrt being able to find and analyze coredumps
written by coredumpctl (in addition to the coredumps written by the abrt
dumper)?

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Recommended upgrade procedure for >1 release upgrades

[Gerd Hoffmann]

On Sa, 2016-11-19 at 08:56 +0100, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I think I've proposed at least once that we make Obsoletes: for retired
> > packages mandatory. My last proposal currently seems to be assigned to
> > tibbs.
> 
> IMHO, forcefully removing packages that still work is a major disservice to 
> our users and should never be done.

That is a non-trivial effort though.  We would have to put the major
shared library version into package names, simliar to debian.

So, when the soname is bumped upstream a new lib${pkg}${new-soname}
package shows up.  The old package lib${pkg}${old-soname} package can
continue to linger around, and obsoleted packages depending on it
continue to work and also don't block lib${pkg} updates because the
update can be installed parallel.

Of course this approach has its downsides too, like the more complex
maintainance, lib*${old-soname} packages piling up over time, and
probably more I'm not aware of ...

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora on Macs, removing the release criterion

[Gerd Hoffmann]

  Hi,

> > Apples and oranges. There's no installer on ARM. There's no need to wipe
> > all your data on a desktop system that you have one unit of.
> 
> Yes, there is, we support anaconda just like on all the other arches.
> It's not as widely used as people like to just consume the disk images
> but it is supported and tested across a wide range of boards. We're
> even working on adding CI to do this across a lot of boards on a
> nightly basis.

Yea, but it is still apples and oranges IMO.

On a arm board you can swap the sdcard in seconds.  Then run tests
(images / anaconda / whatever).  Then put back in the original sdcard
and things continue to work just fine like they did before you ran the
tests.  Try that with a macbook.

Also buying a separate device for testing purposes is much less of a
problem with arm boards as the costs for that are an order of magnitude
lower compared to a mac ...

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Gerd Hoffmann]

  Hi,

> > The metalinks already provide checksums and timestamps for the
> > metadata. So instead of dumbly going out and re-downloading the entire
> > metadata at hardcoded intervals, couldn't we rather just check if the
> > 'latest' metadata (according to the metalink) has changed since the
> > last time we ran, or something along those lines, and only actually
> > download the metadata if so? Wouldn't that save us a lot of wasted
> > metadata downloads?
> 
> I suppose that's what is supposed to happen. And of course, now that I 
> try to reproduce it, that is exactly what happens.
> 
> I know I've seen it redownload the main repo occasionally but perhaps 
> its just been bugs since fixed. Or then the main repo actually changed. 
> But perhaps having bugs is the more likely explanation...

dnf seems to reload the complete metadata if you touch the repo file.
I see this happening after running fedrepos (to configure mirror and
proxy) on fresh installs.  Not that it bothers me much in that specific
case as it re-downloads the metadata from local squid cache.  But just
re-downloading repomd.xml surely should have been enough.

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...

[Gerd Hoffmann]

  Hi,

> > ... and have a fixed grub2.cfg which basically has the command to parse
> > the syslinux config file?
> >
> 
> OK so there are a few things:
> 
> 1. The information needed to present boot options, the "menu entries",
> are a separate thing from the bootloader specific configuration file
> and file format. And yet all the bootloaders out there conflate these
> two things, and make the problem of cross compatibility more
> difficult.

Yep.  You see some fallout from that on arm for example, with uboot
printing "don't understand $this, skipping line" style messages when
parsing extlinux.conf.

> 3. The result is bootloader specific configuration files becomes
> static, non-changing and don't need to contain boot entries (although
> it's not disallowed). And individual boot menu drop in scripts are how
> new boot entries are added. The bootloader then merges them together.

And that would make the grub2.cfg mess alot less painful.

> 4. An issue with using syslinux's format, as well as the original
> bootloader spec format, and a major source of disagreement, is the
> assumption that the kernel and initrd are on the same file system as
> the bootloader and its configuration file.

Dropping that assumption makes the boot loaders alot more complex
though.  Suddenly you can't rely on the firmware any more for file
access, need to understand partition schemes and filesystems, ...

> This is necessary to avoid putting the kernel and initrd on the EFI
> System partition, and causing a lot of installation grief with how to
> deal with dual boot support.

Hmm, not sure why you want avoid that, as I understand it the idea of
the efi system partition is that everything needed to boot is there (for
all operating systems in case of dual/multi-boot).  So why don't use it
that way?

It isn't that simple on !EFI systems though.

> Anyway, regardless of what format you want to base things on, it
> probably should be a superset of the menu entry functions, including a
> way to specify volumes by device designation, LVM, or volume UUID, or
> now your format isn't actually compatible with GRUB on UEFI as well as
> a bunch of less common scenarios.

Well, the bootloaderspec menu *entries* should not need that, just place
them next to kernel + initrd and have a pointer to the directory (plus
optional volume in case you place them outside the efi system partition,
or on !EFI systems) to scan into the bootloader config file.

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...

[Gerd Hoffmann]

  Hi,

> > Adam, the only other distro that has serious alternate architecture support,
> > AFAIK, is Debian. How do they handle grub2 + non-x86? Likewise, the
> > alternate architectures that we support, how do we handle their bootloaders?
> > Are they grub-based? Ext/Syslinux based? Grub-legacy?
> 
> Nothing in Fedora uses GRUB legacy.
> 
> ARM is using Das U-Boot. I'm not sure if grubby is involved here or not.
> 
> Fedora uses isolinux, extlinux, grub2, yaboot (power7 and older), and
> zipl (s390). If the last two are gone or going away then it's syslinux
> (and variants), grub2, and uboot.

Hmm, uboot can use extlinux-style config files, and I recently noticed
grub2 has a command to parse syslinux config files too.  Have not tried
to use that though.

So possibly we can settle on syslinux syntax for bootloader config
long-term ...

> > I agree with Kevin that grub2 is nonintuitive.

... and have a fixed grub2.cfg which basically has the command to parse
the syslinux config file?

cheers,
  Gerd
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Gerd Hoffmann]

  Hi,

> In all of these cases you really want to make sure that whatever the
> user did ends – really ends – by the time he logs out.

Sure, there are valid use cases for that.  The admin will probably also
turn off lingering then, right?

So, what is problem with simply allowing screen + tmux continue to run
in case lingering is enabled, by simply letting the usual SIGHUP logic
do it's job for processes which have a controlling terminal?

cheers,
  Gerd

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

Re: systemd 230 change - KillUserProcesses defaults to yes

[Gerd Hoffmann]

On Do, 2016-06-02 at 10:07 -0400, Matthias Clasen wrote:
> On Thu, 2016-06-02 at 10:02 -0400, Paul Wouters wrote:
> > 
> > People aren't agreeing with you. So making it a default seems like a
> > bad
> > idea. People do seem to agree on "obviously broken windoing apps"
> > that
> > are left lingering. Why can't we just let those get killed?
> > 
> 
> You are misinformed. This is not about 'obviously broken' windowing
> apps. Applications that have X or wayland connections get killed
> reliably when the session ends, because that connection is going away.

No.

It's sort-of default behavior, a bit simliar to how terminal apps get
zapped by SIGHUP when the terminal closes.  But it isn't enforced at
all, apps can keep running when the X or wayland connection goes away,
either just a short moment (firefox saving open tabs to disk, then exit)
or even longer in case they are running some kind of batch job which
they can finish without user interaction.  Or they keep on trying to
read from the closed connection due to some stupid bug ...

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Gerd Hoffmann]

  Hi,

> As mentioned, this isn't just about screen, tmux, and nohup (or if
> there's any other programs used in a similar context). *Any* command
> run with a trailing & is commonly expected to survive logout, usually
> from remote shells.

No.  They get SIGHUP when you logout, and the default action for SIGHUP
is to exit.

So if programs want survive logout for whatever reason they have to
change the SIGHUP action to either a signal handler or set it to ignore.

And IMO systemd should continue to allow programs to stay around that
way in case lingering is enabled for the user.

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Gerd Hoffmann]

On Di, 2016-05-31 at 11:56 +0200, Lennart Poettering wrote:
> On Tue, 31.05.16 11:31, Gerd Hoffmann (kra...@redhat.com) wrote:
> 
> > IMO systemd should allow to specify the KillUserProcesses policy
> > separately for processes with/without controlling terminal.  So you
> > could ask systemd to zap any gnome process going wild on logout without
> > breaking screen and tmux.
> 
> Again, as mentioned before: key here is that permitting user processes
> to stick around after all sessions of the user ended needs to be a
> privilieged concept.

Sure.

> It should not be allowed for user code to stick
> around after logout, unless this is explicitly permitted by the admin,

Having a switch for that so the admin can permit or deny this is fine.
Having it default to "deny" is rude IMO.

Traditionally this has worked and there are some very reasonable use
cases for this.  logouts are not always intentional.  If some internet
hickup breaks your ssh connection you are logged out too, and the usual
way to avoid your remote session being killed by that event is running
your stuff in screen.

> Hence, whether a process reacts to SIGHUP or SIGTERM or not is not
> suitable at all as indication on whether to permit them to stay around
> or not, because that's something that is exclusively up to the
> processes themselves, and requires no privileges at all to make use of.

Its still useful as indication whenever the user wants the processes
stay around or not.  So systemd should IMO use it for a more
fine-grained control over the kill behavior.

Maybe turn KillUserProcesses into a tristate: Yes/WithoutTerminal/No.

Maybe make it depend on the "linger" option to avoid a new config
switch.  From a security point of view that makes sense, if the admin
allows users to enable lingering for themself they are able to leave
processes running after logout anyway, so systemd could also allow that
using the traditional unix way via SIGHUP handler.

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: systemd 230 change - KillUserProcesses defaults to yes

[Gerd Hoffmann]

On Fr, 2016-05-27 at 15:29 +0100, Tom Hughes wrote:
> On 27/05/16 15:25, Chris Adams wrote:
> > Once upon a time, Lennart Poettering  said:
> >> I am pretty sure we should consider it our duty as Fedora developers
> >> to improve the Linux platform, and I am pretty sure that properly
> >> cleaning up processes on logout is a step towards that, not against
> >> it.
> >
> > When you "clean up" by killing things that are designed to run after
> > logout, you are being over-zealous.  It is incumbent upon you to fix
> > your cleanup methods to handle this case, not the thousands of users
> > to change their process to avoid your broken methods.
> 
> But that's effectively calling for the impossible - if there has 
> historically been no way for things to announce that they are expected 
> to remain after exit then there's no way to magically identify them now.

Wrong.

There is a way, and it's called SIGHUP.  Processes get that signal if
your controlling terminal is gone, which typically happens for
background processes on logout.  Default action for the signal is to
terminate the process.  So if you run "tail -f $somelog &", forget about
it, then logout (or close the xterm) the SIGHUP will kill it.

But it's also possible for programs to ignore and/or handle SIGHUP.
Simplest case is the "nohup" utility which basically sets the SIGHUP
action to ignore then goes execute whatever you specified on the command
line.  IIRC vim catches SIGHUP to save the current buffer somewhere
before exiting so your unsaved work isn't lost.  And of course tools
like screen and tmux don't exit but simply detach from terminal on
SIGHUP.

There is nothing simliar for gui processes (which typically don't have a
controlling tty) though.  But having gui processes continue when your
display server is gone looks pretty pointless to me, except for
save-state-then-exit style actions (like firefox does so it can offer to
restore tabs next time you start it).

IMO systemd should allow to specify the KillUserProcesses policy
separately for processes with/without controlling terminal.  So you
could ask systemd to zap any gnome process going wild on logout without
breaking screen and tmux.

While being on it:  I also think a logging option would be useful.  If a
(gui) process doesn't exit by itself on logout but needs to be killed
this indicates a bug and you might want to know about it.

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: HEADS UP: systemd package split

[Gerd Hoffmann]

On Mo, 2016-03-07 at 15:56 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Mon, Mar 07, 2016 at 09:21:38AM -0500, Daniel J Walsh wrote:
> > Does this mean we can install systemd into a base container without
> > systemd-udev?
> > And without systemd-container?
> Yep. That's more or less the point of the change.

Plans to split out more?

console setup comes to mind.  was mentioned on the list recently that
this is quite big because it pulls in keymaps as dependency.  And it's
also something you don't need in a container.

Maybe also network (networkd/resolved) given that fedora uses
networkmanager by default.  Probably hasn't a big effect on the main
package size though.

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: no systemd in containers: Requires -> Recommends

[Gerd Hoffmann]

  Hi,

> It doesn't help that there doesn't seem to be a way to use systemd's
> own container technologies to do these things in a more lightweight,
> yet compatible fashion. nspawn currently only does OS style
> containers, where you have another PID 1 inside.

Hmm?

I have a fedora 23 container on my rhel workstation, mostly for
testbuilds.

I can of course do a full-blown boot (then login, install/update
things, ...).

I can also run stuff directly in the container just fine, i.e.
"systemd-nspawn -D $root --bind /home make -C $HOME/src/$project".

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Gerd Hoffmann]

  Hi,

> Start moving away from
> split DNS because that's going to be very hard to support.

Seriously?  How do you suggest to handle DNS for my 192.168.2.0/24 home
network then?  Making the forward zone for home.kraxel.org public would
at least work, although I fail to see the point in having public dns
records for private networks.  Registering the reverse zone is never
ever going to work though ...

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: DNF could improve messages about package auto-removal

[Gerd Hoffmann]

  Hi,

> One would hope (assume?) that there's something to keep dnf from
> thinking I no longer need Firefox, or emacs, or some other big package
> just because nothing else depends on it any more.

That seems to be in place at least for kernel and dnf.  Recently I've
tried to uninstall some small package, then dnf errored out and
complained that this transaction would remove dnf + kernel and that it
can't do that.

Apparently autoremove gone wild, thinking I don't need the whole system
any more.  I just did 'rpm -e $package' instead then ...

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: F24 System Wide Change: Default Local DNS Resolver

[Gerd Hoffmann]

  Hi,

> Quite frankly: a setup like this one isn't just very typical for home
> router networks, but also in many companies, where ".lan" or
> ".companyname" or something like that is frequently established in the
> internal network. And you will make Fedora incompatible with all these
> networks by default.

Even if you don't grab some random name it still is a problem.  /me runs
home.kraxel.org zone for my home network (and, yes, kraxel.org is mine).
That zone isn't visible outsize my home network, if you try to resolve
that by walking down from the root zone you wouldn't find it, you have
to use the local dns server propagated by dhcp.

I actually have unbound running on my workstation (rhel-7.2), and it
doesn't work out-of-the-box.  Had to drop a file with stub zones
into /etc/unbound/local.d to get things going.

> I am pretty sure there are solutions possible that are simple and safe
> enough to fix these problems. For example, after doing a proof of
> non-existance on a top-level domain, permit it anyway, but only
> those. That way, people won't be able to add in extra RRs below
> microsoft.com, but they could define additional top-level domains such
> as .box without this creating problems.

That doesn't solve $internalsubdomain.$company.com ...

cheers,
  Gerd
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Texlive packaging

[Gerd Hoffmann]

  Hi,

 If FPC would be open to bulk-approving machine-generated individual
 spec files (given, say, they're provably all following the template,
 which would be reviewed), and rel-eng has some way of bulk-adding the
 necessary branches and builds, that really seems like a step forward to
 me.

Makes sense to me, not only for texlive, stuff like perl pkgs from cpan
have pretty standard way to be built too.  Having scripts which can
generate (and update) spec files -- according to latest packaging
guidelines -- for certain classes of packages would be very useful.

cheers,
  Gerd


-- 
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: F22 System Wide Change: Harden all packages with position-independent code

[Gerd Hoffmann]

  Hi,

  Would that make it impossible to run fedora on sse-only i686 CPUs?
 
 Yes, but test coverage for those CPUs is already rather poor, so I don't 
 expect them to work anymore.

See other replies, people are running such machines.

Given x86_64 exists for many years and even embedded (see aarch64) is
moving to 64bit these days i386 clearly is for old legacy hardware.  If
you need performance you don't run a i386 machine.

So, why bother raising the bar for i386 by requiring more cpu features?
It doesn't help anyone.

cheers,
  Gerd


-- 
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: Remove gcc, gcc-c++ and make from minimal build root

[Gerd Hoffmann]

  Hi,

 I don't think the original question was all that great.  If we were to
 script the change to add the BRs, it would take time but it would
 mostly be a one-time cost.  Reducing buildroot time creation, network
 bandwidth, and storage savings is a reduction over each new buildroot
 instance creation over a long period of time.

IMO it isn't that clear there is a significant win due to the caching
mock is doing.  mock creates the minimal buildroot every once in a
while, then keeps reusing it for builds.  So, with a hot cache the build
goes like this:

  (1) unpack cached minimal buildroot
  (2) rpm install build deps
  (3) do the build

Taking gcc out of the minimal buildroot is an obvious win for packages
not using gcc.  But for packages using gcc it just moves gcc
installation from step (1) to step (2), and I expect this will slow down
the builds due to unpacking the cached buildroot being faster than doing
an rpm install.

So effectively we are going to trade faster non-gcc builds for slower
gcc builds.  Which still might be a net win at the end, but just from
looking at the proposal it isn't obvious whenever it actually is or not.

cheers,
  Gerd


-- 
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: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

[Gerd Hoffmann]

  Hi,

 Often not the case in small business or third party hosted  
 environments.  Without remote ssh, box is unmanageable.
 
 Even if you want to do key-based authentication rather than password,  
 you still need to use password initially to get the key onto the  
 remote box.

Just curious:  Is it possible to configure sshd to disallow passwd
auth in case it finds a valid (correct permissions etc.)
$HOME/.ssh/authorized_keys ?

cheers,
  Gerd


-- 
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: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break

[Gerd Hoffmann]

On Do, 2014-12-18 at 10:43 -0500, Bastien Nocera wrote:
 
 - Original Message -
  Hi,
  
On the other hand, if you install something and it starts listening and
you didn’t know that,
   
   If you install something from Fedora and it does that, then it's a bug in
   the
   application.
  
  No.  It's you solving your problem with gnome-user-share and declaring
  the fallout somebody elses problem so you can safely ignore it.
 
 It's in the packaging guidelines that server applications shouldn't 
 auto-start.
 It's not like I'm making this up...

(a) Bugs happen.
(b) There are third party repos.
(c) I might want use+enable the server apps and still have them
reachable in trusted networks only.

   I want the guests vnc
   display be reachable in my home networks and not reachable in
   public networks.  Doing it with the firewall works.
 
 You found a use for the firewall that's still running.

Yea, right.

And exactly that's why I think firewall setup should be alot simpler
than it is now.  Less zones, better names for them, ability to set them
per network without digging deep into the network config tool.

Problem is gnome takes the opposite direction:  Hide the firewall.

   (2) Heck, even the gnome-user-share UI shows that.  Pick Remote
   Login, notice that you can NOT select networks for sharing.
 
 This isn't gnome-user-share. It's the sharing panel in the control-center. 
 And it's
 not there because I wasn't sure whether changing the status quo for this was
 1) necessary 2) how to implement it without breaking the setup for 
 administrators if
 the user can choose to enable/disable the SSH server themselves.

I'd suggest to simply use the firewall.  Do you seriously consider to
automatically start/stop ssh as the machine switches networks?  What if
the machine has two active network interfaces with different trust
levels.

 I don't see how keeping the status quo for one (system-wide) service 
 necessarily
  invalidates the design decisions done for all the other (user-wide) services.

I've picked just one example.  There are alot more system wide services
which are facing the very same problem.  mdns  cups are typical for
desktops.  Developer workstations might run a git server, also all sorts
of server services (http, sql, gluster, ...) for testing purposes.  The
qemu example goes into that category too.

  Yes, I know why you can't pick networks for ssh.  But this IMO clearly
  shows that the just don't listen on untrusted networks as distro-wide
  policy isn't going to fly.
 
 I'll implement that if it's all it takes for you to admit that, yes, it's 
 actually
 going to fly.

Yes, I'd like to see a reasonable approach for system services.  IMHO
that approach is use the firewall, but you don't wanna go that route.

So, what else can be done when the user switches networks?

(a) start/stop services.  Has the disadvantage that they stop listening
on the loopback device too, and for some (qemu for example) it isn't
a reasonable thing to do.
(b) reconfigure services.  Have fun implementing that for all the server
services fedora has.
(c) teach all those services to listen on dbus  reconfigure themselves.
Have fun implementing that for all the server services fedora has.
(d) run those services in a sandbox, reconfigure the sandbox.  Yea,
might work (don't know enough about sandboxes to say for sure).
(e) something else?

cheers,
  Gerd


-- 
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: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break

[Gerd Hoffmann]

  Hi,

  On the other hand, if you install something and it starts listening and
  you didn’t know that,
 
 If you install something from Fedora and it does that, then it's a bug in the
 application.

No.  It's you solving your problem with gnome-user-share and declaring
the fallout somebody elses problem so you can safely ignore it.

  You can also change the per-network zone. Unfortunately currently wired
  networks are all considered as one per interface, but wireless networks
  are distinguished individually. This can be done in a number of ways,
  but the easiest is to run the network configuration tool (in GNOME
  control center — press the overview key and start typing “network”),
  select the wifi network in question, press the little gear icon next to
  it, go down to Identity (?!), and choose the appropriate firewall zone.
  (Again, there’s a long list — go back to the firewall config tool to see
  exactly what they all do.)
 
 Thank you for pointing out the main reason why the zones can't ever be
 a user-facing concept ;)

The fact that the current GUI (and zone naming) sucks big time doesn't
imply that the underlying concept is unusable.  The big advantage of
using firewall zones is that it works outside the gnome universe too.

 (1) Pulling the qemu/kvm vnc server example again, which you decided to
 not respond to last time I mentioned it.  I want the guests vnc
 display be reachable in my home networks and not reachable in
 public networks.  Doing it with the firewall works.

 (2) Heck, even the gnome-user-share UI shows that.  Pick Remote
 Login, notice that you can NOT select networks for sharing.

Yes, I know why you can't pick networks for ssh.  But this IMO clearly
shows that the just don't listen on untrusted networks as distro-wide
policy isn't going to fly.

cheers,
  Gerd


-- 
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: Workstation Product defaults to wide-open firewall

[Gerd Hoffmann]

  Hi,

  I also thought that the whole points of having Zones etc, was so that
  we could pick a different zone per network connection,

/me too.

  so if I'm in the office or at home I can say use this zone, if I'm
  at a coffee shop I can pick a different one etc.
  
  Or was this consider too much UI for the normal user? Surely
  OSX has something to copy from, since they seem to define what
  a normal user expects.
 
 OSX has a firewall integration that I would rank as awful. It's not
 any better than what we had in Fedora 20 (blocking firewall and a tool
 to open up ports).

Have a look at Windows then.  Each time you hook a windows machine to a
new network it asks what network this is.  Used to be public, home,
work.  Recently they simplified that and kicked the home / work
separation, so it's only public / non-public now.  With some explanation
along the lines of use public for hotspots, use home for your private
network where you want share stuff.

Why we can't have something like this?  And if you don't want a popup
asking, have something in the NetworkManager applet menu, where people
can easily find the switch without having to search for it?  A [x]
allow sharing checkbox?  A firewall zone selector?

Side Note: For the latter we need to cleanup the zones though.  There
   are *way* to many to choose from, and the names suck big
   time.  WTF is a Fedora$product zone?  And wasn't that
   discussed before on this list?  Why do we *still* have this
   mess?

IMO there is simply no way around asking the user.  Make sharing stuff
easy (so you can watch your dnla-exported photo/video collection at your
smart tv) is a reasonable request.  But enabling that by allowing
everybody fetch your private photo collection via dnla while you are
surfing @ starbucks is a non-starter.

cheers,
  Gerd

PS: Seems windows can even identify different wired networks.  I've
switched my router recently, and windows re-asked what network
I'm on.  Probably they remember the mac address of the default
gateway or something 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: Workstation Product defaults to wide-open firewall

[Gerd Hoffmann]

On Di, 2014-12-09 at 08:16 -0500, Bastien Nocera wrote:
 
 - Original Message -
  On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote:
   Why we can't have something like this?  And if you don't want a popup
   asking, have something in the NetworkManager applet menu, where people
   can easily find the switch without having to search for it?  A [x]
   allow sharing checkbox?  A firewall zone selector?
  
  We can — we just need someone to design and write it.
 
 A design for something that we don't want to implement. This was one of the
 options when implementing the feature, one that we didn't pursue. We chose
 instead to use user intent as a way to do this.
 
 If you start sharing something on a network, then we consider it safe to 
 share.
 If you connect to a public unencrypted Wi-Fi, you won't have the option to. If
 you connect to an encrypted Wi-Fi where sharing your holiday photos isn't 
 acceptable
 then it won't, because you didn't ask it to in the first place.

That assumes all applications behave that way.  Which simply isn't true,
there is a world outside gnome.  You apparently choose to ignore that,
which is a bad idea IMO.

cheers,
  Gerd


-- 
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: Workstation Product defaults to wide-open firewall

[Gerd Hoffmann]

  Hi,

  Side Note: For the latter we need to cleanup the zones though.  There
 are *way* to many to choose from, and the names suck big
 time.  WTF is a Fedora$product zone?  And wasn't that
 discussed before on this list?  Why do we *still* have this
 mess?
 
 This isn't a side note, IMO. It was one of the major reasons why we chose
 not to expose users to the concept of zones.

IMO it would have been better to fix the zones instead.  The concept is
good, we just have too many with of them, with bad names.  We basically
need one for public networks (Hotspots etc) and one for Home/Work, with
good names and sensible defaults.  Maybe also allow all and block all
(including outgoing traffic) zones, but thats it.

The internal, external, dmz, ... zones sound like they are
intended for machines running as router.  They should either be moved to
a subpackage (so they are not installed by default), or dropped
altogether.  Or maybe tagged as expert zones, so they are hidden by
default in the UI.

 In addition to the names being
 obscure in firewalld (there's a bug filed about that), they also are obscure
 in Windows.

 What configuration difference is there between home and work, and how do you
 explain them without going deeper into technical details?

Microsoft figured this too, so as I've already mentioned this home/work
is gone now (win8 fully updated).

  IMO there is simply no way around asking the user.
 
 Instead of asking the user, we're getting the user to tell us they want to 
 share
 things. This avoids unnecessary nagging.

Problem is this doesn't work for apps outside the gnome universe.  For
example I can ask libvirt to make the qemu vnc server listen on any
interface, if I want access the guest screen from another machine.

With firewall zones I can easily get the behavior I want: guest screen
is reachable in my home network, but not in the coffee shop.

  Make sharing stuff
  easy (so you can watch your dnla-exported photo/video collection at your
  smart tv) is a reasonable request.  But enabling that by allowing
  everybody fetch your private photo collection via dnla while you are
  surfing @ starbucks is a non-starter.
 
 This isn't what was implemented. DLNA share will be turned off by default on
 new networks. In fact, we won't allow any unencrypted services to run when
 on unencrypted Wi-Fi.

The gnome dnla server might do this.  There are other dnla servers, and
other apps opening network ports, which don't follow this policy.

cheers,
  Gerd


-- 
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: Abotu setting 'PermitRootLogin=no' in sshd_config

[Gerd Hoffmann]

On Fr, 2014-11-21 at 09:11 +0100, Florian Weimer wrote:
 On 11/21/2014 09:04 AM, P J P wrote:
  My point is that once we address this (most likely through some
  configuration generation during VM setup), we can also switch
  PermitRootLogin on.
 
 You mean off? Or that we disable it by default and enable it while 
  setting up a new VM?
 
 The latter.  We have to install authorized_keys inside the VM anyway, so 
 we can touch sshd_config, too.

There is PermitRootLogin without-password too ...

cheers.
  Gerd


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

[Gerd Hoffmann]

  Hi,

  Even if you know that this weird feature exists, it will take you
  hours to disable it, since while you are trying to find your way through
  setting and control panels you will get tons and tons of random clicks
  that open random windows that needs to be closed and change random
  settings that you need to reset. And while you try to do this you get
  even more random clicks that open new windows and change other stuff.
 
 This has pretty much nothing to do with reality. So please write sane
 mails when you ask for sanity ;)

It may be a bit exaggerated, but I had exactly this problem multiple
times already:  Touchpad tap sensitivity is *way* to high and trying to
move the pointer causes unintentional clicks all over the place, even
after figuring it is very sensitive and being extra careful because of
that.

Dunno whenever that is due to crappy hardware or crappy software or
crappy default configuration.  Usually I grab a usb mouse, turn off
tapping, be happy.  Saw this not only Linux, but Windows too.  Also
there are touchpads which work fine.  Which makes me suspect it is just
crappy hardware.

cheers,
  Gerd


-- 
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: No more deltarpms by default

[Gerd Hoffmann]

  Hi,

   3) People who have a lot of hosts and high bandwidth, high speed
 local deployment requirements can, and do, set up an internal Fedora
 mirror with much lower bandwidth costs.

Maybe mirrormanager can give a hint in case it directs yum/dnf to a
onsite mirror?

cheers,
  Gerd


-- 
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: No more deltarpms by default

[Gerd Hoffmann]

On Fr, 2014-10-17 at 11:49 +, Andre Robatino wrote:
 Roberto Ragusa mail at robertoragusa.it writes:
 
  Are compressed rpms completely impossible to diff efficiently by rsync?
 
 In a word, yes. They're already compressed, so it's unlikely there would be
 any matching blocks between old and new rpms for rsync to take advantage of.

Years ago I saw rsync being patched for this (done by suse IIRC).

Basic trick is to teach rsync to unpack/repack rpms, thereby effectively
rsyning the files within the rpm, which works *alot* better than using
the compressed rpm payload.

Obvious downside is that it is very cpu consuming, which likely is a
showstopper at least for public mirrors (and I guess it never went
upstream for that reason).

cheers,
  Gerd


-- 
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: No more deltarpms by default

[Gerd Hoffmann]

  Hi,

  It would be nice to see if we can find ways to improve the performance
  of the deltarpm reconstruction instead. Much of the time is spent on
  compression/decompression tasks which *should* be massively parallel
 
 s/massively parallel/not done at all/ ... but we had this discussion
 each time this comes up. There is no point in compressing something
 just to uncompress it a few minutes later.

IIRC the problem is that the _compressed_ rpm is signed, so things go
compress - check sig - uncompress and you can't cut the compress
+uncompress without also cutting the signature check :(

cheers,
  Gerd


-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Gerd Hoffmann]

  Hi,

 So maybe a solution would be to write a libwrap2 instead ?

Don't think this is the solution.  Part of the problem is that some of
the functionality is just obsolete in todays world.  Trusting IDENT and
DNS for access control maybe made sense in the 90ies.  It certainly
doesn't today, and IMO lennart is correct in classifying this as
security theater.

 So offer something with equivalent functionality (and config file
 syntax compatibility), with a nice modern clean API and then systemd
 and others can be moved over to that 1 by 1, and once we've no more
 users left we can kill of the old beast ?

I'd say moving the functionality which still makes sense (ip range based
checks) to the firewall is more useful.  Guess it shouldn't be that hard
to write a utility translating /etc/hosts.{allow,deny} into iptables
rules, or add support for that to firewalld.

Does tcpwrap support ipv6 btw?

cheers,
  Gerd

-- 
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: what to do with ums when the X server is not suid root ?

[Gerd Hoffmann]

On Mo, 2014-01-20 at 15:58 +, Richard W.M. Jones wrote:
 On Mon, Jan 20, 2014 at 02:18:22PM +, Matthew Garrett wrote:
   We can probably kill -cirrus.
 
 qemu?  (I know that people should be using QXL, but cirrus is still
 the default in plain qemu, and IMHO simpler and more secure.)

qemu is covered pretty well.  There are cirrus + qxl kms drivers for
quite some time already.  kms driver for '-vga std' is in -next and will
probably land in 3.14.  Only missing is vmware, where the qemu emulation
is to old or to buggy or both for the needs of the vmgfx kms driver.

cheers,
  Gerd


-- 
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 release name problem

[Gerd Hoffmann]

On 03/19/13 01:56, Adam Williamson wrote:
 This bug just *smells* like one of those which will pop up again and
 again and again causing carnage wherever it shows up.

Shouldn't be worse than F18 where we slipped how many weeks?  Or was it
even months in the end?

cheers,
  Gerd

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

Re: Improving the Fedora boot experience

[Gerd Hoffmann]

  Hi,

 Keep in mind that the not show the menu by default plan depends on
 the bootspec changes, and that will include a gui tool which will
 allow users to select things like show the menu (and then it won't have
 a timeout so be easier to get to), or even to directly select the
 kernel to boot next time.
 
 Any gui tool requires a successful boot
 
 Successful means kernel ok, systemd ok, selinux ok, x/wayland ok, gdm ok,
 gnome-shell ok
 (replace with other de equivalents)
 
 There are so many parts there where we *fail* the user regularly I don't
 see how can anyone reasonably propose to build any safety net over them.
 
 For example, how are you going to deal with gfx drivers that break after a
 kernel update? The system thinks all is fine, even though the display
 necessary for any gui is garbage.

Well.  lilo (anyone remembers?) had a cool feature to address that, and
for grub1 patches where floating around to implement something simliar.

You could do lilo -R $kernel $args.  Then lilo boots the specified
kernel (with args if specified) *once*.  So you can boot a new kernel
*without* changing the default kernel.  Or boot the kernel with
additional args without changing the default args.

Pretty neat for kernel hacking.  When your kernel fails to boot -- just
hit reset (or power-cycle the machine remotely) and the system comes up
with the known-good default kernel.

Likewise useful for kernel updates.  Install new kernel, *not* make it
the default (yet), ask lilo to boot it once, reboot, and when the system
came up fine you can make the new kernel the default.

cheers,
  Gerd

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Gerd Hoffmann]

 You have two possibilities:
 
 1. Show sessions before selecting/entering the user:
Means basically including something like 'default session' or
'previous session' 
 2. Show sessions after selecting/entering the user:
Means you can show the actual session that will be chosen.
 
 There are tradeoffs between both of them, GDM chose #2,

Well, that is only one half of the story.  gdm actually moved from #1 to
#2 (IIRC with the gnome2-gnome3 switch), making people wonder why the
desktop selection disappeared ...

Took me a while to figure this (and other user-specific settings like
language) just shows up after picking the user, especially as this is
just a small change at the bottom of the screen while you are focusing
to the center where you just typed the password and where gdm now asks
for the password.

cheers,
  Gerd

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

Re: Proposed F19 Feature: systemd features

[Gerd Hoffmann]

On 01/30/13 01:08, Kay Sievers wrote:
 On Tue, Jan 29, 2013 at 11:13 PM, Bill Nottingham nott...@redhat.com wrote:
 Kay Sievers (k...@vrfy.org) said:
 Realistically, it's new textual files, replacing old textual files, which
 are then compiled into a binary file. I'm not sure why there's the
 intermediate step of a second textual format, but there is.

 Because the original text file is a hack and a format specific to the
 PCI/USB IDs, and makes no sense at all for a generic hwdb.

 pci:v0010*
  ID_VENDOR_FROM_DATABASE=Allied Telesis, Inc

 It's not like that's that much more of a generic format. :)
 
 It is entirely generic. It can carry arbitrary numbers of freely named
 key/value pairs basically unlimited in their size. Is extensible, uses
 flexible and extensible string matches like modaliases for kernel
 modules. Nothing you would find in the PCI/USB IDs hack.
 
 So what do you criticize here?

Still looks pointless.

You convert the old-format into new-format, then compile new-format into
the database.  It's not obvious why you don't go straight from
old-format to the database.  hwdata package updates would directly show
up in the database then, without having to touch systemd.

cheers,
  Gerd

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

Re: Proposed F19 Feature: systemd features

[Gerd Hoffmann]

On 01/30/13 11:55, Kay Sievers wrote:
  Hi,

 Still looks pointless.

 You convert the old-format into new-format, then compile new-format into
 the database.  It's not obvious why you don't go straight from
 old-format to the database.  hwdata package updates would directly show
 up in the database then, without having to touch systemd.
 
 It's as pointless as shipping a parser for a foreign and irrelevant
 format in the hwdb code.

You need the parser anyway, for converting the old format into the new,
don't you?

 And it is as pointless as adding weird code and ./configure stuff
 again to udev to find these files in the place of the month, where
 some distro poeple decided again where to put it, and every distro in
 a different place, with different names or file types.

That is a bit nasty indeed.

 And it is as pointless as inventing magic rules in the hwdb to
 overwrite the old files with possibly new data shipped in the new
 format.

You could use import $format $file syntax in the new format, then
plumb a file with a single import line instead of the converted file
into the directory.  You get the same ordering then.

cheers,
  Gerd

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

Re: Proposed F19 Feature: Fedora Upgrade - using yum

[Gerd Hoffmann]

  Hi,

 If a fedup upgrade can go offline for a lengthy, but uncertain, amount
 of time, then the lack of feedback is worrying.  You can't hold your
 breath for 25 minutes, you don't know when to conclude that you have a
 serious problem that will require help from the data center staff, and
 you don't have any idea where the process went off-track.

I actually like fedup, and I guess I'll go stop using yum for upgrades
if I can use fedup instead.

I've seen anaconda upgrades (be it dvd-based or via preupgrade) blow up
multiple times and settled on using yum instead.

But fedup is different.  Even though it is still quite young I actually
trust it to get things right.  It fetches all packages, then does a
transaction check and if that fails it says so and allows you to fixup
stuff before actually kicking the upgrade.  Remove orphaned packages
causing dep issues, cleanup disk so filesystems have enough free space
to run the transaction, whatever is needed.

That is very simliar to how you handle issues when upgrading using yum.

Once everything is settled and fedup says reboot to upgrade you can be
pretty sure that it will work fine.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Gerd Hoffmann]

On 01/28/13 10:07, Aleksandar Kurtakov wrote:
 - Original Message -
 On 01/27/2013 02:53 PM, Jaroslav Reznik wrote:
 = Features/Cinnamon as Default Desktop = 
 https://fedoraproject.org/wiki/Features/Cinnamon_as_Default_Desktop

 We should be moving away from having a default rather then switching
 it.
 
 Yeah, I didn't know that people still feel like there is default - If
 one goes to http://fedoraproject.org/get-fedora there is Desktops:
 KDE, Xfce, GNOME, and others. Does it mean that KDE is the default
 as we listed it first :)?

Yes, we have a default desktop.

It is the one you get when you hit the the big download now button on
the get-fedora page.

It is the one where the live iso is named Desktop instead of Gnome.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Gerd Hoffmann]

  Hi,

 My entirely personal take on this is that I don't really care that much,
 but I don't see a convincing case for the change. My personal opinion is
 that a lot of the 'GNOME sucks and everyone's switching to Cinnamon /
 MATE!' stuff in the press is inaccurate; whenever I see actual people
 using Fedora, they seem to be using GNOME 3. For e.g., at FUDCon NA, I
 saw a large majority of GNOME 3 systems, a few KDE systems, and I think
 less than 5 people running Cinnamon or MATE. And one of those was the
 MATE maintainer. :) But if somehow this change went through, I wouldn't
 mind.

Reminds me a bit how the KDE 4 launch went.  KDE 4.0 was horrible.  It
took a few minor releases to shake out usability+stability issues (and
also adapt 3rd party apps to the new major release).  Now-days people
are happy with KDE 4 and attempts to keep KDE 3 alive are pretty much
dead.  But IIRC it took quite some time until the KDE 4 bashing stopped.

GMOME 3 seems to run simliar.  3.0 was pretty bad, and users rightfully
complained.  Now, a few minor releases later, the most annoying stuff is
fixed and people seem[1] to be mostly happy with it.  With the ongoing
finetuning I expect the motivation to keep the alternatives alive will
go away.  I predict MATE will disappear first.  Cinnamon probably has
higher chances to stay alive for a while, but lets see where things are
in 2-3 years ...

cheers,
  Gerd

[1] /me uses KDE most of the time.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F19 Feature: Syslinux Option

[Gerd Hoffmann]

  Hi,

 Is there perhaps a consensus what the long-term future will look like?
  In particular, is it impossible/plausible/probable that most
 architectures will move to EFI, and if so, will virtualization also
 move to EFI eventually?

virtualization will support EFI, but certainly not require it.  Note
that one important use case of virtualization is to run old software ...

 That would mean syslinux is not a long-term
 option.

EFI support for syslinux is in development already, so long-term it will
be there.

  Or is the future in this area uncertain enough that there is
 a benefit in having more options readily available?

Well, a sane config format is reason enough, isn't it?

cheers,
  Gerd

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

Re: Fedora Windows Spice/Virtio KVM drivers and tools (was Re: Red Hat QXL GPU Driver for Windows 7?)

[Gerd Hoffmann]

On 01/09/13 16:39, Simone Caronni wrote:
 6) Yan Vugenfirer's repository
 - Contains only source, and is public.
 - Does not match with Fedora or RHEL provided drivers.
 - Contains only the Virtio drivers, no Spice Agent or QXL driver.
 
 https://github.com/YanVugenfirer/kvm-guest-drivers-windows/commits/master

spice git repos are here: http://cgit.freedesktop.org/spice/

spice libraries, spice server, spice client, guest agent, guest drivers,
everything.  Well, except the xorg qxl driver, that one is here:

http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/

Spice Guest Tools are built from these repos as far I know.

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

Re: [FYI] Motif finally opened under LGPL

[Gerd Hoffmann]

On 10/25/12 14:14, Matthew Miller wrote:
 On Thu, Oct 25, 2012 at 10:44:13AM +0200, Ralf Corsepius wrote:
 Time to move Motif from unpronounceable 3rd party repo into Fedora
 and to consider rebuilding all lesstif-linked packages against it ;)
 
 Are there any particular drawbacks to lesstif at this point?

It's been a few years I looked at this, but the lesstif implementation
was incomlete/buggy and some apps didn't run properly with lesstif but
did with openmotif.

cheers,
  Gerd


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

Re: Replacing grubby with grub2-mkconfig in kernel install process

[Gerd Hoffmann]

  Hi,

 Which is one of a number of reasons why I then suggested that instead of
 replacing grubby entirely, we could simply patch grubby to call
 grub2-mkconfig if the bootloader is grub2. That would accomplish everything
 I wanted to achieve (compliance with /etc/grub.d and /etc/default/grub,
 which means consistent boot menus), but not break environments where
 another bootloader like grub-legacy, or simply legacy grub-style
 configuration, is needed.

+1

Having two completely different ways (grubby fiddling with it directly
vs. grub2-mkconfig) to update the grub2 configuration sucks big time
IMHO.  It's inconsistent once both tools touched the config.  It also
asks for trouble, for example if there are any grub2-mkconfig changes
which generate config files grubby can't parse correctly.  With grub2
config essentially being a script language this can easily happen I suspect.

Just have grubby call grub2-mkconfig to update grub2.conf and be done
with it.

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

Re: Stop the git abuse

[Gerd Hoffmann]

On 05/21/12 10:23, Ralf Corsepius wrote:
 On 05/21/2012 09:56 AM, Jaroslav Reznik wrote:
 - Original Message -
 On Fri, May 18, 2012 at 07:07:56PM +0200, Remi Collet wrote:
 And definitvely, for me, (and probably only for me), git is really
 not a good tool for spec maintenance.

 Not duplicating the changelog would help.  There's little reason to
 have a changelog in git which is then manually copied into
 %changelog.

 +1, for me - GIT is the authority for change logs, not SPEC...
 
 -1 changelogs are manually written documents and source files.
 A database's (git), temporary meta information is irrelvant.

Temporary?  git commit messages disappearing is news to me ...

One could generate %changelog from the git commit log to avoid the
duplication.  Needs quite some through though.  For starters you
probably don't want 'git commit -m fix build' show up in %changelog.

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

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

[Gerd Hoffmann]

On 05/10/12 17:00, Adam Jackson wrote:
 On Thu, 2012-05-10 at 09:16 +0200, Kevin Kofler wrote:
 Adam Jackson wrote:
 Even if all of your objections are true, and who knows, they might be:
 we already do provide alternatives.  The Live media is not the only
 install media.

 The other alternatives are either already DVDs or netinstall CDs which 
 require a fast Internet connection (which people who don't even have a DVD 
 drive are unlikely to have).
 
 So the set of people we'd be inconveniencing is exactly the set of
 people with no bandwidth and the inability to boot from anything larger
 than a CD.
 
 Do we think that's a statistically significant number of people, or are
 we just arguing?

I suspect the number is pretty small if non-zero at all.

Fedora raises the hardware requirements now and then.  The minimum cpu
required for i386 was changed a few versions back.  Likewise very old
gfx cards tend to not be supported very well (see the guy running F11
for that reason).  You need a not too small amout of memory to run the
livecd and the anaconda installer.  I guess it is pretty hard to find
hardware which runs f18 well and can not boot from dvd or usb ...

Also, can the netinst.iso install from local media too?  A usb key for
example?  So you can use netinst.iso @ CD and install-dvd @ usbkey to
install if your box can boot from cd only ...

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

Re: Proposed F18 feature: MiniDebugInfo

[Gerd Hoffmann]

On 05/11/12 00:36, Kevin Kofler wrote:
 Adam Jackson wrote:
 Therefore I have difficulty evaluating just how much impact this would
 be.  Do you have a link to the recipe for building such an image?  I
 suspect the incremental cost of each additional desktop environment
 would be successively lower, but without data...
 
 The DVD is composed by glueing together the independent live images plus a 
 boot menu, so no, the cost will not be lower for each additional desktop 
 environment, the size is exactly the sum of the sizes of all the CD ISOs 
 (plus a negligible overhead).

Sounds more useful to me to just have a single live image which has
multiple desktop environments included, so you don't have the common
bits multiple times at the dvd ...

cheers,
  Gerd

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

Re: Proposed F18 feature: MiniDebugInfo

[Gerd Hoffmann]

On 05/09/12 08:23, Jan Kratochvil wrote:
 On Tue, 08 May 2012 15:03:28 +0200, Alexander Larsson wrote:
 Take this post for instance:

 https://plus.google.com/110933625728671692704/posts/iFXggK7Q8KJ
 +
 On Tue, 08 May 2012 15:10:28 +0200, Gerd Hoffmann wrote:
 Wrong.  From /me you don't get abrt reports at all, because abrt simply
 is a pain with a slow internet link due to the tons of data it wants
 transmit.  Also it doesn't say what it is going to do (download ?? MB
 debuginfo / upload ?? MB core).  And there is no progress bar.  Ok,
 might have changed meanwhile, its a while back I tried last.
 
 Great, these were the first useful posts in this thread.
 
 Therefore IIUC the problem is ABRT is not good enough.

There is room for improvements indeed.  It is one but not the only problem.

   Because ABRT has not yet met its expectations we should provide at
   least this temporary solution before ABRT gets fixed.

No.  There will always be cases where the current[1] abrt model fails:

Local trace generation requires downloading lots of debuginfo.  Might
not work / work badly because:
  (1) you are offline.
  (2) your internet link is slow.
  (3) you are on 3G and don't want to pay the volume.
  (4) you don't have the disk space to store debuginfo.

Server-based trace generation requires uploading a potentially large
core file (which probably can be reduced using mozilla-like minidumps).
 Bandwidth requirements aside there are still issues with that:
  (1) works only when online.
  (2) you might not want upload to the fedora server for privacy
  or company policy reasons.
  (3) private / company-wide retrace server needs extra effort (both
  hardware and work time), you can't count on it being available.

cheers,
  Gerd

[1] I expect abrt support minidebuginfo traces too once the feature
is there.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

[Gerd Hoffmann]

On 05/08/12 13:08, Miloslav Trmač wrote:
 On Mon, May 7, 2012 at 11:36 PM, Lennart Poettering
 mzerq...@0pointer.de wrote:
 On Mon, 07.05.12 23:02, Jan Kratochvil (jan.kratoch...@redhat.com) wrote:
 On Mon, 07 May 2012 22:16:02 +0200, Lennart Poettering wrote:
 I mean, just think of this: you have a pool of workstations to
 administer. It's all the same machines, with the same prepared OS
 image. You want to know about the backtraces as admin. Now, since the OS
 images are all the same some errors will happen across all the machines
 at the same time. Now, with your logic this would either result in all
 of them downloading a couple of GB of debuginfo for glibc and stuff like
 that, or all of them bombarding the retrace server, if they can.
 
 No, someone administering a pool of machines would also want to
 collect the crash information centrally instead of running tools
 manually on every machine in the pool

Who talks about running stuff manually?  I'd expect we'll have some
service (abrt?) doing it automagically and send the trace to syslog, so
the userspace traces end up in the logs like the kernel oopses do today.

 - and it turns out ABRT was from
 the start designed to support such data collection; all core files can
 be configured to end up at a single analysis machine.

The minidebuginfo traces can easily go a central logserver too.

 My take:
 
 1) Developers of the software in question: Bluntly, the ~1-100 users
 in the whole world shouldn't matter in our discussion - if they are
 even running the RPM, they can and probably will install complete
 debuginfo, enable logging and do other non-default things to make
 their job easier; The Fedora defaults don't matter that much for them,
 and the mini debuginfo is not that useful either.

Depends.  My internet link isn't exactly fast.  For stuff I'm working on
I have the debuginfo packages locally mirrored / installed.  For other
stuff I havn't and it can easily take hours to fetch it.  Having at
least a basic trace without delay has its value.  Often this is enougth
to track it down.

Or when debugging your own program (with full debuginfo) it is useful to
have at least the symbols of the libraries used in the trace too.

 2) Non-programming end-users.  _This_ is the case that we need to get
 right by default.In many cases, a developer is lucky if the end
 user ever sends any crash report, they often don't respond to
 follow-up questions, and the problem does not have to be reproducible
 at all.  From such users we definitely want as full crash information
 as possible (IOW, including the variable contents information) because
 there won't be a second change to get it.  The mini debuginfo is
 therefore irrelevant, we need to steer users to the retrace server (or
 to attaching full core files to reports, which has much worse privacy
 impact).

Wrong.  From /me you don't get abrt reports at all, because abrt simply
is a pain with a slow internet link due to the tons of data it wants
transmit.  Also it doesn't say what it is going to do (download ?? MB
debuginfo / upload ?? MB core).  And there is no progress bar.  Ok,
might have changed meanwhile, its a while back I tried last.

 Can we agree on the above, at least  that 1) and 2) are not noticeably
 improved by mini debuginfo,

No.

 BTW, the feature suggests mini debuginfo would be useful for userspace
 tracing - AFAIK such uses, e.g. systemtap, use the variable location
 information very extensively, and would thus not benefit from mini
 debuginfo.

How about 'perf top -p $pid'?

cheers,
  Gerd

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

Re: ARM as a primary architecture

[Gerd Hoffmann]

  Hi,

 they use a rather scary looking pile of development boards with very
 poor I/O.
 
 Buy a trimslice and run it with iSCSI.  It's a very clean package, and
 I can get 80 MB/sec to my file server's disks.  That is neither
 scary nor poor I/O.
 
 http://www.delorie.com/arm/trimslice/iscsi.html

Running the thing on iscsi is a good idea, given that local storage is
linked up via usb while gb ethernet is hooked up via pcie.

Any particular reason why you boot the thing via tftp?  I'd expect just
having /boot on the sd card (which you need for boot anyway) is easier,
especially when it comes to kernel updates.

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

Re: ARM as a primary architecture

[Gerd Hoffmann]

On 03/26/12 11:00, Peter Robinson wrote:
 On Mon, Mar 26, 2012 at 9:41 AM, Gerd Hoffmann kra...@redhat.com wrote:
  Hi,

 they use a rather scary looking pile of development boards with very
 poor I/O.

 Buy a trimslice and run it with iSCSI.  It's a very clean package, and
 I can get 80 MB/sec to my file server's disks.  That is neither
 scary nor poor I/O.

 http://www.delorie.com/arm/trimslice/iscsi.html

 Running the thing on iscsi is a good idea, given that local storage is
 linked up via usb while gb ethernet is hooked up via pcie.

 Any particular reason why you boot the thing via tftp?  I'd expect just
 having /boot on the sd card (which you need for boot anyway) is easier,
 especially when it comes to kernel updates.
 
 Everything needed to boot goes into the initrd now days so you don't
 even need the SD card.

Check the URL above.  The setup described there uses a sdcard with a
u-boot script, which kicks off the tftp boot.

I don't see the point in using tftp, you can place kernel+initrd
directly at the sdcard if you have one anyway.

Another possible way would be to boot directly from iscsi like you can
do on x86 with an sanboot-enabled iPXE rom.  I have no idea whenever
u-boot can handle that though.

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

Re: Issues with yum

[Gerd Hoffmann]

  Hi,

 2) yum is currently downloading repository information separately for
 each user.
 It can use the same downloaded repository information for all users.

 Wrong, information are cached in /var/lib/yum.

When you run yum as user it doesn't use the cache though.  It creates
its own cache somewhere in /var/tmp.  It ignores the cachedir option too.

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

Re: [Test-Announce] Announcing the release of Fedora 16.

[Gerd Hoffmann]

On 11/15/11 18:23, Andre Robatino wrote:
 Gerd Hoffmann wrote:
 
 For developers like me which have a F16 repo for mock builds anyway it
 is quite useful though.  A large fraction of the stuff in Packages/ is
 on my disk already, and with a jigdo I could save quite a bit on
 bandwidth and download time over my not-exactly-fast internet link ...
 
 Rsync should save almost exactly the same amount of bandwidth, since due
 to the way its algorithm works it will avoid downloading unchanged
 packages and download changed packages in full, just like jigdo. In
 addition you don't have to download a jigdo template file.

Hmm?  How will rsync compose me a .iso out of a bunch of rpms?

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

Re: [Test-Announce] Announcing the release of Fedora 16.

[Gerd Hoffmann]

On 11/15/11 19:03, Genes MailLists wrote:
 
 
   Its easy enough to build an iso using mock/pungi which will take
 advantage of all your local packages ... I really don't know that jigdo
 added anything to that - in fact using pungi you always get a fully
 updated build without waiting for a jigdo list.

jigdo gives you the very same dvd image you can download.  There are
cases where this is important, for example when trying to reproduce bugs
from other people, or when running kvm guest installs with autotest.

cheers,
  Gerd

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

Re: [Test-Announce] Announcing the release of Fedora 16.

[Gerd Hoffmann]

On 11/16/11 11:31, Mathieu Bridon wrote:
 On Wed, 2011-11-16 at 10:33 +0100, Gerd Hoffmann wrote:
 On 11/15/11 19:03, Genes MailLists wrote:


   Its easy enough to build an iso using mock/pungi which will take
 advantage of all your local packages ... I really don't know that jigdo
 added anything to that - in fact using pungi you always get a fully
 updated build without waiting for a jigdo list.

 jigdo gives you the very same dvd image you can download.
 
 Pungi should do the same, if you use only the release repo and the
 kickstart from the spin-kickstarts package.

Havn't tried, but I doubt it.  Usually there always is some timestamp
which is different so the md5 of the iso file doesn't match and kvm
autotest complains about the iso being the wrong one ...

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

Re: [Test-Announce] Announcing the release of Fedora 16.

[Gerd Hoffmann]

On 11/15/11 00:38, Adam Williamson wrote:
 On Tue, 2011-11-08 at 17:48 +0100, Gerd Hoffmann wrote:
 Hi,

 Fedora 16 is not science fiction. It is here right now:
 http://get.fedoraproject.org

 Hmm, no jigdo downloads any more?
 
 Releng say they dropped jigdo due to overwhelming indifference (the
 download numbers for the jigdo images were tiny).

Yea, most users don't care probably.  Also note that the download page
never explained what these files are good for, so if you don't know what
it is you probably just skip over it.

For developers like me which have a F16 repo for mock builds anyway it
is quite useful though.  A large fraction of the stuff in Packages/ is
on my disk already, and with a jigdo I could save quite a bit on
bandwidth and download time over my not-exactly-fast internet link ...

Given the size of the jigdo files small download numbers are not a good
reason to stop that service IMHO.  Its not like we are saving tons of
mirror bandwidth ...

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

Re: [Test-Announce] Announcing the release of Fedora 16.

[Gerd Hoffmann]

  Hi,

 Fedora 16 is not science fiction. It is here right now:
 http://get.fedoraproject.org

Hmm, no jigdo downloads any more?

cheers,
  Gerd

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

Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30

[Gerd Hoffmann]

On 10/12/11 19:53, Adam Williamson wrote:
 On Wed, 2011-10-12 at 13:45 -0400, Simo Sorce wrote:

 I have no problem with changing the password, but leave my ssh keys
 alone, unless there is a real reason to ask people to change them.

 Reading between the lines of recent attacks, it seems likely that
 private keys compromised in some of the attacks were used to perform
 others. (No-one's come out and officially said this yet but it seems
 pretty obvious from the subtext of some of the reports; I'm thinking
 kernel.org / linux.com, for e.g.) It doesn't seem at all unlikely that
 some people may have used the same identities on some of the other
 compromised systems as they are using on FAS, and hence it seems pretty
 reasonable to require this change.

I don't think so.

People which have found their system compromised most likely already 
have replaced all the ssh keys - fine.

People which have not been compromised can continue to use the old keys 
without problems.

For people which are compromised but didn't notice (and thus still 
running a compromised system) the key change buys not much as the new 
keys likely will be compromised too.

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

Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30

[Gerd Hoffmann]

   Hi,

 Sure, ssh keys are much harder to compromise than passwords, but
 _assuming a compromise has happened_ the consequences of using a single
 key for everything are just as bad as using a single password for
 everything.

One ssh key per project doesn't make sense at all to me.  They all would 
be on my laptop, and in case it gets compromised the attacker can easily 
snatch all the keys.

One ssh key per machine makes alot more sense.  For outgoing ssh 
connections from -- say -- shell.fedoraproject.org I wouldn't just copy 
my private key from my laptop but generate a new one, then add it to 
authorized_keys where needed.

That does (a) limit the access to the machines really needed instead of 
allowing ssh to every machine I'm ssh'ing to from my laptop and
(b) doesn't compromise the keys used on my laptop in case 
shell.fedoraproject.org is hacked.

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

Re: Subject: IMPORTANT: Mandatory password and ssh key change by 2011-11-30

[Gerd Hoffmann]

   Hi,

 What can we do there? We can't separate out those with good practices
 and those without.

For starters block ssh keys found @ fedorapeople.org ?

cheers,
   Gerd

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

Re: Ubuntu 10.10's installer looks rather nice

[Gerd Hoffmann]

On 10/12/10 18:39, Jos Vos wrote:
 On Tue, Oct 12, 2010 at 09:30:45AM -0700, Adam Williamson wrote:

 2) it creates a confusing decision point for *everyone*: how do you know
 if you need the 'advanced' options? You can't really know without
 looking at them, so you have to look at them to decide if you need them,
 so essentially we're presenting the advanced options to everyone...

 100% agreed.  You do not know in advance what options will not be shown
 in non-advanced mode (e.g. custom filesystem layout, MBR at a different
 partition, etc.).  As a CLI expert I'm considering myself all but a GUI
 expert, but I never understood how people can guess the corect answer
 to this kind of undefined questions (like do you want basic or advanced
 install mode?).

advanced install mode is a non-started as discussed elsewhere in this 
thread.  It must be more fine-grained, i.e. each installation step 
(where it make sense) should offer some button to see the advanced options.

And it probably shouldn't be labeled Advanced ... but say what kind of 
advanced stuff is hidden there, i.e. the advanced storage button 
should be labeled Add SAN storage ... because this is what it actually 
is about.  Now you can figure whenever you need that or not without 
klicking and looking, see?

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

Re: Ubuntu 10.10's installer looks rather nice

[Gerd Hoffmann]

On 10/11/10 19:31, Bruno Wolff III wrote:
 On Mon, Oct 11, 2010 at 11:41:13 +0100,
Richard W.M. Jonesrjo...@redhat.com  wrote:

 Some of the things it does which are IMHO better:

   - starts disk formatting / copying / installing in parallel
 with asking user questions

 I think that is a misfeature. I don't want anything irreversible to be done
 until I say go.

I always liked the way suse does the install.  It comes up with a 
*single* overview screen showing *everything* it suggests to do 
(partitioning, packages to install, some basic settings, ...).  Then you 
can go and change stuff if you want, and after changing settings it goes 
back to the overview screen, showing what it would do now after applying 
your changes. This way you are not bothered with lots of interactive 
questions but still have the option to change everything as you like if 
you want.  When you are happy with everything you say 'go!' and it goes. 
It doesn't touch your hard disk before.

Anaconda goes though everything step-by-step instead, asking one 
question after another, doing some work inbetween (partitining), asking 
more questions (packages to install) ...

Dunno how hard it would be to change anaconda to have such an overview 
screen.  Maybe it isn't *that* hard after all as we have kickstart.  So 
for a interactive install anaconda could collect all info from the user, 
compile a kickstart file from that, then feed the install machinery with 
the just-generated kickstart file.

Anaconda can try to figure reasonable defaults.  Using geoip. By 
inspecting the hardware.  Have 'klick here to change' buttons to change 
things, which can probably handled by the existing screens for timezone 
/ keyboard / ... selection.  Maybe even reading stuff from a kickstart 
file and present it in the overview, so you could stick your favorite 
non-default settings there.

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

Re: Ubuntu 10.10's installer looks rather nice

[Gerd Hoffmann]

   Hi,

 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.

We don't have to make things inferior to improve usability.  To stick 
with the advanved storage example:  IMHO the selection screen between 
basic and advanced storage is confusing and superfluous.  First it 
should probably be named local storage and SAN storage.  Second 
anaconda can default to local storage if a local disk is present (option 
to add SAN storage needs to be there of course).  If no local disk is 
present it can go straight to SAN setup.  One screen and one mouse click 
less for most of the users.

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

Re: Putting cross compilers into Fedora

[Gerd Hoffmann]

   Hi,

 - A cross compiler alone is not worth it, you need a whole zoo of
 further cross-target packages to make it usable.
 Without massive changes to the infrastructure, this would add a
 significant amount of packages to the distro.

Depends on what you wanna do with it.  For linux kernel cross builds as 
asked for in the mail starting this thread just gcc+binutils will do 
fine.  For cross-compiling userspace bits too you'll indeed need alot 
more stuff ...

cheers,
   Gerd

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

Re: Putting cross compilers into Fedora

[Gerd Hoffmann]

 b) To equippe the rpm/yum/mock etc. infrastructure with a mechanism to
 pull-in foreign binaries into a sys-root (E.g. to install Fedora
 *.ppc.rpm rpms into /usr/ppc-redhat/sys-root). So far, such mechanism
 doesn't exist.

 No need for that eithr.  They can figure out

 rpm2cpio package | cpio -i -

Isn't that easy, you'll have to do a bunch of fixups after doing so to 
have things actually work.  Also automagic fetching of packages 
(including dependencies) would be nice.  Upgrading them even nicer.

Creating a script (or yum plugin?) doing all that is probably *much* 
less work than creating tons of extra packages for userspace cross builds.

cheers,
   Gerd

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

Re: Putting cross compilers into Fedora

[Gerd Hoffmann]

On 09/01/10 16:46, Andrew Haley wrote:
 rpm2cpio package | cpio -i -

 Isn't that easy, you'll have to do a bunch of fixups after doing so to
 have things actually work.

 Usually not.  Nine times out of ten, (probably 99 out of 100) all you
 need for cross-devel is the headers and the libraries, and they'll be
 in the right place after unpacking.  The package doesn't have to work
 in that situation, it just has to be possible to build against it.

You havn't tried that, have you?

Last time I did I had to (a) move stuff from $sysroot/usr/... to 
$sysroot/ to have compiler and linker find it.  Also fixup paths in the 
linker scripts (try 'cat /usr/lib64/libc.so').  Nothing really hard but 
needs to be done.

 Also automagic fetching of packages (including dependencies) would
 be nice.  Upgrading them even nicer.

 Lots of things sould be nice.  It's not an argument for not providing
 cross-compilers.

It isn't mean to be one.

 Creating a script (or yum plugin?) doing all that is probably *much*
 less work than creating tons of extra packages for userspace cross builds.

 Which we really shouldn't do.   All this is irrelavant, and we're
 getting away from the core issue, which is about providing cross
 compilers.

If we go add cross-compilers it would be quite useful to also have an 
easy ways to cross-build userspace stuff so we are not limited to kernel 
cross builds ...

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

Re: suggestion: rescue boot extension

[Gerd Hoffmann]

On 06/02/10 22:33, Jon Masters wrote:
 A recovery initramfs could be used. It could just basically be the
 rescue mode anaconda bits in one image shoved in place to start.

That would be a good idea anyway:  Zap the two-stage rescue system 
loading.  Just have a kernel + initramfs.  That would make booting a 
rescue system easier as the (todays) small initramfs doesn't need some 
way to grap the second stage from somewhere.

Having a rescue system in /boot would be trivial then: just copy kernel 
+ rescue.initramfs from the install.iso to /boot and add a grub menu 
entry - done.

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

Re: LD Changes To Implicit DSO Linking Update

[Gerd Hoffmann]

On 02/09/10 09:06, Richard Hughes wrote:
 On 8 February 2010 22:46, Kevin Koflerkevin.kof...@chello.at  wrote:
 As a result, you'll be causing dozens of FTBFS bugs just before the feature
 freeze. I think this is entirely the wrong time in the release cycle to do
 such a change, if it is done at all.

 I've been fixing upstream projects for weeks to build with
 --no-as-needed. The list of projects that fail to build should be much
 smaller now, especially for GNOME and Freedesktop stuff.

Well.  Even pretty fundamental GNOME stuff like gtk2-devel is still 
broken.  Look here:

[r...@localhost ~]# pkg-config --libs gtk+-2.0
-pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 
-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype 
-lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0

-lX11 is missing (at least, maybe more).  Any gtk app using pkg-config 
to figure which libraries are required fails to build now.

I've seen a simliar issue with libpng (-lz missing) and I suspect tons 
of other *.pc files are broken too.

cheers,
   Gerd

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

Re: LD Changes To Implicit DSO Linking Update

[Gerd Hoffmann]

On 02/16/10 16:06, Jakub Jelinek wrote:
 On Tue, Feb 16, 2010 at 03:57:52PM +0100, Gerd Hoffmann wrote:
 Well.  Even pretty fundamental GNOME stuff like gtk2-devel is still
 broken.  Look here:

 [r...@localhost ~]# pkg-config --libs gtk+-2.0
 -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
 -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0

 -lX11 is missing (at least, maybe more).  Any gtk app using pkg-config
 to figure which libraries are required fails to build now.

 Only if the library you are compiling actually uses any libX11 APIs.
 If it only uses APIs from the named libraries, it will link fine.

Sure?  For the libpng case I have a build failure which looks like this 
isn't the case (bug 565047):

quote
/usr/bin/ld: /usr/lib/gcc/i686-redhat-linux/4.4.3/../../../libpng12.so: 
undefined reference to symbol 'crc32'
/usr/bin/ld: note: 'crc32' is defined in DSO /lib/libz.so.1 so try 
adding it to the linker command line
/quote

Which made me think -lz is needed on the command line even if zlib is 
used only indirectly via libpng (and likewise that -lX11 should be there 
for gtk2 because gtk2 needs it).

cheers,
   Gerd

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