Re: CI projects in Copr

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.

Re: CI projects in Copr

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

Re: Please provide "Minimal CD" of Fedora

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

Re: nfs-utils-2.1.1 Changes Everything!

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

Re: cross-compiler support?

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:

Re: F26 System Wide Change: Enable coredumpctl by default

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

Re: Recommended upgrade procedure for >1 release upgrades

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

Re: Fedora on Macs, removing the release criterion

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 >

Re: DNF and PackageKit background data usage

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

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

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

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

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?

Re: systemd 230 change - KillUserProcesses defaults to yes

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

Re: systemd 230 change - KillUserProcesses defaults to yes

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

Re: systemd 230 change - KillUserProcesses defaults to yes

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

Re: systemd 230 change - KillUserProcesses defaults to yes

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 >

Re: systemd 230 change - KillUserProcesses defaults to yes

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

Re: HEADS UP: systemd package split

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

Re: no systemd in containers: Requires -> Recommends

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

Re: F24 System Wide Change: Default Local DNS Resolver

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

Re: DNF could improve messages about package auto-removal

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

Re: F24 System Wide Change: Default Local DNS Resolver

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

Re: Texlive packaging

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.

Re: F22 System Wide Change: Harden all packages with position-independent code

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

Re: Remove gcc, gcc-c++ and make from minimal build root

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

Re: F22 System Wide Change: Set sshd(8) PermitRootLogin=no

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:

Re: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break

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

Re: 5tFTW: Fedora 21, 22, and 19, firewall discussion, and holiday break

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

Re: Workstation Product defaults to wide-open firewall

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

Re: Workstation Product defaults to wide-open firewall

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

Re: Workstation Product defaults to wide-open firewall

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

Re: Abotu setting 'PermitRootLogin=no' in sshd_config

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

Re: Enable tapping by default

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

Re: No more deltarpms by default

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

Re: No more deltarpms by default

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

Re: No more deltarpms by default

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

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

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

Re: RFC: what to do with ums when the X server is not suid root ?

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

Re: fedora release name problem

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

Re: Improving the Fedora boot experience

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

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.

Re: Proposed F19 Feature: systemd features

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

Re: Proposed F19 Feature: systemd features

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

Re: Proposed F19 Feature: Fedora Upgrade - using yum

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

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

Re: Proposed F19 Feature: Syslinux Option

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

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

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.

Re: [FYI] Motif finally opened under LGPL

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

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

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,

Re: Stop the git abuse

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

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

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

Re: Proposed F18 feature: MiniDebugInfo

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

Re: Proposed F18 feature: MiniDebugInfo

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

Re: Proposed F18 feature: MiniDebugInfo

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

Re: ARM as a primary architecture

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

Re: ARM as a primary architecture

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

Re: Issues with yum

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Ubuntu 10.10's installer looks rather nice

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

Re: Ubuntu 10.10's installer looks rather nice

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

Re: Putting cross compilers into Fedora

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

Re: Putting cross compilers into Fedora

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

Re: Putting cross compilers into Fedora

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,

Re: suggestion: rescue boot extension

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

Re: LD Changes To Implicit DSO Linking Update

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

Re: LD Changes To Implicit DSO Linking Update

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

<    1   2