Vanilla builds guideline?
Hi,
for better automation of our static analysis tools we would like to have
some defined way how to get "as close to vanilla as possible" build from
Fedora srpms. Based on our statistics ~15% of packages are affected -
you can't simply build them without Fedora patches.
This can also be used for other purposes - if you want to rule out
influence of distro specific patches before reporting problem upstream
in the case that upstream sources are hard to compile/get running on
Fedora system. This could reduce false alarms to upstream lists.
In many cases it is not possible to simply disable all the patches -
some are required to get the rpm built but do not affect program
functionality. We have discussed that problem with rpm guy - to get a
way with the lowest possible impact on the package. As a solution, we
are proposing %{?_rawbuild} conditional.
Note: Some packages already use this %{?_rawbuild} anotation, some use %
global _with_vanilla 0 to give user a chance for vanilla build.
Change in the spec file is very simple - just for the patches required
for vanilla build this conditional should be added.
e.g. from the sudo spec file
%patch3 -p1 -b .m4path
->
%patch3 -p1 -b .m4path %{?_rawbuild}
After this change you can simply create a wrapper for rpmbuild, which
will apply only patches with the %{?_rawbuild} annotation. For more
complicated changes, _with_vanilla global is probably better option.
Our wrapper is available at
http://kdudka.fedorapeople.org/rpmbuild-rawbuild .
Is it possible to establish some common rule for Vanilla builds in
Packaging Guidelines? Any other ideas?
Thanks in advance for consideration!
(or pointing me to better place where to ask - I already tried
packag...@lists.fedoraproject.org , but with almost no response (only
suggestion of fedora-devel list :) ))
Greetings,
Ondrej Vasik
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UID_MIN & GID_MIN changed
On Wed, 2011-05-25 at 10:55 +0200, Peter Vrabec wrote: > Hi, > > On Tuesday, May 24, 2011 05:25:44 PM Toshio Kuratomi wrote: > > On Tue, May 24, 2011 at 1:59 AM, Peter Vrabec wrote: > > > Hi all, > > > > > > I'd like to inform you that I have changed UID_MIN & GID_MIN from 500 to > > > 1000 in upgraded shadow-utils. > > > > > > Where? > > > /etc/login.defs. > > > shadow-utils-4.1.4.3-1.fc16 > > > > > > I suppose UID/GID_MIN=1000 is more common(other distros, upstream). We > > > are not in situation that 500 IDs for system accounts ought to be enough > > > for anybody. Actually, it was not 500.It was 299 because range 0-200 is > > > for reserved IDs. There are 799 non reserved IDs for system accounts > > > available after this change. > > > > This change should be made as a Feature for F16 and needs some > > thought/coordination put behind it. There's several issues that I > > see: > > > > * AFAIK, we actually have not run into the 500 uid limit yet (although > > it is a bit low to be comfortable) > > * AFAIK, we've only allocated the range 0-100 for reserved IDs. > > * The 0-100 reserved IDs are actually the pain point that we need to > > deal with, not the dynamic system ids in the 101-499 range. > We use 0-200 for reserved IDs since > http://lists.fedoraproject.org/pipermail/devel/2009-April/028740.html Actually since July 2009 - there are no free uid/gid's left bellow 100. And yes, I'm giving static assignments only for system accounts which potentially can handle/own sensitive information or do communicate with other systems - so I rejected some requests for static ID's reservation. > > > * We don't know how many, if any IDs this actually gets us for the > > dynamic range because any site that has already filled the 500-1000 > > UID range won't gain any extra dynamic system account through this > > change. > > * This could potentially break sites that are currently using the > > 500-1000 UID range and rely on the order of allocation of UIDs for > > their users on new machines matching with the UIDs on old machines. > > (For instance, NFS UIDs on filesystems matching between a box > > installed with RHEL5 and a box that gets newly installed with F16). > > > > -Toshio > > I'm not against wider announcement. I'm just not sure what is the right way - > F16 Feature/Release Notes/ ? We can also annouce the 200 limit for > reserved IDs. ;) Probably makes sense :) ... even some ID sanity validator/checker might be good idea for this "feature". Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UID_MIN & GID_MIN changed
On Thu, 2011-05-26 at 09:27 +0200, Peter Vrabec wrote: > Hi, > > On Wednesday, May 25, 2011 08:07:32 PM Toshio Kuratomi wrote: > > On Wed, May 25, 2011 at 1:55 AM, Peter Vrabec wrote: > > > We can also annouce the 200 limit for reserved IDs. ;) > > > > We can't just make changes to this range. Especially not in the lower > > end of it. (and if we change the dynamic system account range to > > extend higher, we also can't use the 500-1000 range for that. > This change has already happened. If it was done without any harm, I consider > that a good job. :) Just a side note here... there are some third party packages /applications which used/use static id's between 100 and 200 ... especially between 101 and 106 it is quite easy to find "recommended" numbers for some apps. As Peter said, useradd assigns dynamic system id's from the top of the range, going down - so the conflicts with existing dynamic system accounts are really unlikely to happen there. Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: UID_MIN & GID_MIN changed
On Tue, 2011-05-31 at 11:47 -0700, Toshio Kuratomi wrote: > On Thu, May 26, 2011 at 09:27:21AM +0200, Peter Vrabec wrote: > > > > We can also annouce the 200 limit for reserved IDs. ;) > > > > > > We can't just make changes to this range. Especially not in the lower > > > end of it. (and if we change the dynamic system account range to > > > extend higher, we also can't use the 500-1000 range for that. > > This change has already happened. If it was done without any harm, I > > consider > > that a good job. :) > > > To be clear, this change has only happened in rawhide with your last commit > so it's a bit early to tell what harm there is. With the clarification that > the dynamic UID range has started allocating at the top instead of the > bottom in 2007, it makes a lot more sense that we can make this change. Are > you sure you only want to allocate 0-200, though? Remember that the static > assignments are our limited resource, perhaps you want to go higher than > that? I guess Peter was talking about this 0-200 static ID reservation threshold change - and it happened in Fedora 12 (setup-2.8.7-1.fc12) with no reported complaints or conflicts so far. Yes, static assignments are limited resource and it probably makes sense to increase it even a bit further , however - in ~2 years since the change of the threshold to 200, 15 static new uid's were assigned. So if the trend will continue, there is enough free id's for reservation for ~5-10 years - so the threshold at 200 seems to be enough atm (especially if the dynamically assigned system id's assignments are going from the highest limit down). Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Is F15 unbackuppable? (RemoveSETUID)
On Sun, 2011-06-05 at 13:50 +0200, Roberto Ragusa wrote:
> On 06/05/2011 12:32 PM, Ralf Ertzinger wrote:
> > Hi.
> >
> > On Sun, 05 Jun 2011 11:39:02 +0200, Roberto Ragusa wrote
> >
> >> - rsync -aFAILS!
> >
> > rsync supports -X (for xattr) and -A (for ACLs), both must be
> > given explicitly.
>
> Thanks, rsync -X actually works (and I wonder why -X is not included
> in -a, just as for cp).
>
> I see tar has --xattrs. With tar -c it works (the tar file contains the
> string with the value), but tar -x does not recreate the xattr.
>
> By using strace I see that rsync does
>
> open(".a.eWMgCy", O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 1
> fchmod(1, 0700) = 0
> close(1)= 0
> lstat64(".a.eWMgCy", {st_mode=S_IFREG|0700, st_size=0, ...}) = 0
> llistxattr(".a.eWMgCy", 0x82bb0c0, 1024) = 0
> lsetxattr(".a.eWMgCy", "security.capability", "\x01\x00\x00\x02\x00
> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 20, 0) = 0
> lsetxattr(".a.eWMgCy", "user.qqq", "www", 3, 0) = 0
> utimensat(AT_FDCWD, ".a.eWMgCy", {UTIME_NOW, {1307265135, 0}},
> AT_SYMLINK_NOFOLLOW) = 0
> chmod(".a.eWMgCy", 0755)= 0
> rename(".a.eWMgCy", "a")= 0
>
> while tar -x does
>
> mknod("a", 0700)= 0
> setxattr("a", "user.qqq", "www", 3, 0) = 0
> open("a", O_WRONLY|O_CREAT|O_LARGEFILE, 0700) = 4
> close(4)= 0
> utimensat(AT_FDCWD, "a", {{1307271119, 468295223}, {1307265135, 0}}, 0) = 0
> setxattr("a", "user.qqq", "www", 3, 0) = 0
> chown32("a", 0, 0) = 0
> chmod("a", 0755)= 0
>
> Why is tar not working? ("getcap a" prints nothing)
>
Simply because tar does not store all the extended attributes. Just
limited set of them. At the moment security.capability is not among
them. Feel free to report a bugzilla against rawhide tar...
You may also consider using star... where is the support for extended
attributes present for longer time (and upstream).
Greetings,
Ondrej Vasik
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, 2012-02-10 at 05:45 +0100, Ralf Corsepius wrote: > On 02/09/2012 11:06 PM, Jared K. Smith wrote: > >> - management, whom seems to be driven by a "must have at any price, no > >> point > >> of return ever" policy. > > > > I'm not sure who you're referring to as "management" here > Everybody involved to drawing strategic and tactical decisions related > to the Fedora distribution. > > My point is, I feel there is a lack of "monitoring", "reporting", and a > sense of "responsibility" of the different bodies involved and of people > who are able to draw "unpleasant decisions". > > To draw an arbitrary example from recent past: Ask yourself - What was > the shape of systemd in F15/F16? Has the situation been fixed in F17? > > Wrt. F17: usrmove - Independently from the fact that I consider it to be > an "idotic foolishness", ask yourself if it is a shape to be part of > F17? IMO, it's foreseeable it will not be ready, because there are too > many unknows attached to it. I now would expect those people having been > involved to stand up, show responsibility and revisit their decisions - > This obiviously doesn't happen. One additional item to this topic. I'm the Fedora filesystem package maintainer (and because it has it's upstream on the fedorahosted, you can say upstream...) and I was aware of the "usrmove" feature only from the discussions and feature pages. For quite a long time I waited for an email from Harald - with some "please include the changes into upstream git". The only mail I received from him was the mail on 24th of January - saying - do not build the package. Nothing more... Strange - when the first thing for Fedora maintainers should be "upstream first" and imho violation of Proven packager rules in some cases . For me it was kind of misusing proven packager - as e.g. in coreutils package he did following change: +%check +# FIXME: check failed!! +# make check (part of http://lists.fedoraproject.org/pipermail/scm-commits/2012-January/725967.html , quite easy to miss when reading the commit mail) without even informing me about that! I don't see disabling testsuite at buildtime as the necessary minimal change. Not saying anything that with the /bin/ provides the spec file looks really like a mess now. Given the fact that there is NO ultimate gain from the usrmove feature (ok, I understand all the arguments for the usrmove, but I don't see them that bright at the moment as Harald and fastboot guys - e.g. the compatibility of distro locations is not only in the locations of binaries and we have much more differences in Fedora) I really don't know why the REAL ACTIONS on this feature were started that late in F17 release cycle - several months after branching. Only 3 weeks after the start of usrmove git commits you now have even F18 git branch and F18 would have been MUCH better for it. In addition, for mock builds of F17+ packages with usrmove support on RHEL-6 systems you now need UNSUPPORTED rpm from Harald pages ( http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ ). I'm sure that reverting the changes at the moment would mean much more confusion and that there is the only option now - finish it. But I hope that FESCO will learn from this "feature" and will set the "deadlines" for distro-wide features with higher impact sooner - so there will be enough time to postpone them to Fedora X+1 in the case of immaturity. I think there is a difference between usrmove and e.g. GIMP2.8 feature (no offence to Gimp). Greetings, Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove?
On Fri, 2012-02-10 at 10:21 +0100, Harald Hoyer wrote: > Am 10.02.2012 08:36, schrieb Ondrej Vasik: > > Given the fact that there is NO ultimate gain from the usrmove feature > > (ok, I understand all the arguments for the usrmove, but I don't see > > them that bright at the moment as Harald and fastboot guys - e.g. the > > compatibility of distro locations is not only in the locations of > > binaries and we have much more differences in Fedora) > > That's your personal opinion.. I tend to differ. Please read > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge again. I already read that few times before and I understand all the things. I'm not against usrmove feature - as I see the benefits - but I'm not a big fan of it - as I see some of the negatives. It is really not that painless how it was presented at the beginning. But I'm against the style and timing how it was achieved. None of the arguments in the systemd page usrmove cases is "we need it now" and it can't wait for Fedora 18. All of them are personal opinions of you and systemd guys - and as I said, they are mostly valid. > > > > I really don't know why the REAL ACTIONS on this feature were started > > that late in F17 release cycle - several months after branching. > > Because politics took so long. So it should have been moved to F18... I still see it very unfortunate, but it reached that far that it could be only taken as a warning for future releases distro-wide "features". > > Only 3 > > weeks after the start of usrmove git commits you now have even F18 git > > branch and F18 would have been MUCH better for it. > > In addition, for mock builds of F17+ packages with usrmove support on > > RHEL-6 systems you now need UNSUPPORTED rpm from Harald pages > > ( http://people.redhat.com/harald/downloads/rpm/4.8.0-19.el6.0.usrmove.1/ ). > > and? It will get in RHEL-6.3 ... SUPPORTED! That's a self inflicted wound, > binding Fedora development to RHEL-6. And? When will the RHEL-6.3 start being supported? After or before the Fedora 17 release? That's a self inflicted wound, breaking Fedora-17+ package builders on non-Fedora systems. Try to think about third parties using RHEL-6 (or different supported rpmbased) mock builders for their third party packages and using Fedora for the rest of non-critical jobs. It is not only about RHEL... I'm quite sure there are such cases - and builds for Fedora-17 will be broken for them unless they will use unsupported patched rpm. Anyway, that's more for beer-meeting discussion next week ;). Greetings, Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Dear developers, > > Now that the /usrmove changes have landed in the F-17 branch, should > the ordering of directories in PATH be changed? /usr/bin should appear > before /bin and /usr/sbin before /sbin. > > Right now $(which a-binary) would report that all /usr/... binaries > are located in /bin and /sbin instead; while it is mostly just > cosmetic, some programs (e.g. pure-gen) use the heuristic of computing > their default installation prefix based on the location of another > binary, and get confused if that prefix is empty. > > Is this a reasonable change? I'll file a bug report if that's the case. /bin and /sbin paths were already removed in latest setup package - as you no longer need them... so no need for bugzilla and report... Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usrmove and path ordering
- Original Message - > On Tue, 2012-02-14 at 17:11 +0100, Ondrej Vasik wrote: > > On Tue, 2012-02-14 at 17:08 +0100, Michel Alexandre Salim wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > Dear developers, > > > > > > Now that the /usrmove changes have landed in the F-17 branch, > > > should > > > the ordering of directories in PATH be changed? /usr/bin should > > > appear > > > before /bin and /usr/sbin before /sbin. > > > > > > Right now $(which a-binary) would report that all /usr/... > > > binaries > > > are located in /bin and /sbin instead; while it is mostly just > > > cosmetic, some programs (e.g. pure-gen) use the heuristic of > > > computing > > > their default installation prefix based on the location of > > > another > > > binary, and get confused if that prefix is empty. > > > > > > Is this a reasonable change? I'll file a bug report if that's the > > > case. > > > > /bin and /sbin paths were already removed in latest setup package - > > as > > you no longer need them... so no need for bugzilla and report... > > I'm not sure, but I think bash has hardcoded PATH for /bin and > /usr/bin > as well. You are right, setup update fixed only /sbin locations... /bin has to be done on glibc and shells side. Sorry for confusion... Greetings, Ondrej Vasik -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: maintenance of "setup" and https://fedoraproject.org/wiki/Packaging:UsersAndGroups
On Fri, 2014-07-11 at 15:55 -0700, Colin Walters wrote: > Hi, > > I was looking at user/group stuff more as part of the other thread on > https://fedoraproject.org/wiki/Changes/SystemdSysusers - but let's > ignore that for a second. > > So on > https://fedoraproject.org/wiki/Packaging:UsersAndGroups#Soft_static_allocation > - I followed the link to the "uidgid" section, and noticed "Hey, we have > another uid/gid listing here". > > Scanning that list, I saw "polkituser"...which: > 1) Doesn't exist - the polkit package allocates a user named "polkit" > 2) Isn't used even if it did: polkit allocates a dynamic uid/gid. > > Now Mirek and I currently maintain polkit, and at least I was unaware of > the existence of this reservation. > > Basically, because this list isn't actually *used* by RPM at > installation time, it is prone to desynchronization with the actual code > in the spec files, and it happened in at least this case for polkit. For the history - https://bugzilla.redhat.com/show_bug.cgi?id=244950 and https://bugzilla.redhat.com/show_bug.cgi?id=480776 are the pointers. Static id was requested by former polkit maintainer - and reserved by Phil - long time ago. If the id was actually never in use or it is just rename of the former polkituser id, it is safe to use it now for polkit ... > I did a bit of archaeology in the git log through several whitespace > cleanups/reorganizations and then hit a wall on this commit: > https://git.fedorahosted.org/cgit/setup.git/commit/?id=08258e0f748c4f372fcbf1dd7947c132ee0b8a12 Good google query is more powerful than gitlog in some cases ;) . > > Hard to know what was going on at that time. > > Anyways at least nowadays there appears to be a relatively sane SOP for > this wrt filing a trac ticket or bug against setup, but it seems like we > have an opportunity now for some sort of static check to ensure that the > systemd-sysusers snippets shipped by packages actually match that of > setup. If you plan to use this 87 uid/gid for polkit, just let me know or file bugzilla against setup - otherwise, I can likely just remove the reservation from uidgid file. > > Also, we should audit now to see if there are other packages besides > polkit that are out of sync. There were such packages - I remember I notified maintainers of one or two packages in the past about different/wrong uid/gid/name used. However - afaik noone did full audit of id's - at least not recently - and I don't plan it in near future - too long todo list... Greetings, Ondrej -- 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: /media -> /run/media???
On Mon, 2014-08-04 at 18:13 +0200, Marcin Juszkiewicz wrote: > Can someone point me to discussion which ended in /media being symlink > to /run/media directory? > > I am now looking at Picasa rescanning 40GB of pictures just because > /media/storage/ dissapeared after upgrade of packages (which moved > /media/ to /media.rpmmoved/ one). This is pretty strange - so /media.rpmmoved was empty and without these 40GB of pictures? This directory was supposed to be created (with os.rename) for such cases when people had their own files/dirs in /media - for safety. > Should I create /my-own-directory-do-not-even-think-about-touching-it/ > and keep mountpoints of all hard drives there just to hope that it will > stay there for next year? Well, it would be better to use /usr/local or /opt for this - not creating another one toplevel directory for these do-not-ever-touch mounts. Greetings, Ondrej Vasik -- 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: /media -> /run/media???
On Wed, 2014-08-13 at 09:22 -0400, Nico Kadel-Garcia wrote: > > > On Aug 5, 2014, at 3:28, Ahmad Samir wrote: > > > >> On 04/08/14 19:13, Marcin Juszkiewicz wrote: > >> Can someone point me to discussion which ended in /media being symlink > >> to /run/media directory? > >> > >> I am now looking at Picasa rescanning 40GB of pictures just because > >> /media/storage/ dissapeared after upgrade of packages (which moved > >> /media/ to /media.rpmmoved/ one). > >> > > [..] > > > >> Should I create /my-own-directory-do-not-even-think-about-touching-it/ > >> and keep mountpoints of all hard drives there just to hope that it will > >> stay there for next year? > >> > > > > Personally that's what I did eventually; this way I don't have to worry > > about the defaults changing - again - for whatever reasons in the future. > > Fedora's recent tendency to override the published file system hierarchy > specs, at whim, and replace them with symlinks is problematic, unnecessary, > and is breaking things. In this case, /media is defined in the upstream specs > as the location for removable media. Not /run/media. Not > /whither/my/love/piñata/wanders/media. > > Changing stable behavior because you think your model is better than the > published spec is capricious and wastes time. In this case, in particular, it > breaks tools that report disk usage of removable media because the real > mountpoint just changed. > > So, please, please, stop re-arranging the file system. The /bin symlink is > bad enough, this one was pointless. Actually I'm going to revert the /media -> /run/media change. It is really not solving the issue it was trying to help with and in addition it might be fragile in some cases. Sorry for the noise. Regards, Ondrej -- 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: /media -> /run/media???
On Thu, 2014-08-14 at 06:17 -0400, Matthew Miller wrote: > On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote: > > Actually I'm going to revert the /media -> /run/media change. It is > > really not solving the issue it was trying to help with and in addition > > it might be fragile in some cases. Sorry for the noise. > > H... that should probablt be run through the change process... it needs > release notes at least! Well, the directory was not used by default at all for several releases - which was the reason for the initial idea about the symlink change - initially it was supposed to be "noone will notice" change - but although it can be such case for majority of the users, it doesn't bring the expected benefits - which is the primary reason for the revert. Regards, Ondrej -- 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: /media -> /run/media???
On Fri, 2014-08-15 at 08:07 -0400, Nico Kadel-Garcia wrote: > On Thu, Aug 14, 2014 at 11:49 AM, Michal Schmidt wrote: > > On 08/14/2014 12:17 PM, Matthew Miller wrote: > >> On Thu, Aug 14, 2014 at 10:06:11AM +0200, Ondrej Vasik wrote: > >>> Actually I'm going to revert the /media -> /run/media change. > > > > The above sentence is unfortunately ambiguous. > > > >>> It is really not solving the issue it was trying to help with and in > >>> addition it might be fragile in some cases. Sorry for the noise. > >> > >> H... that should probablt be run through the change process... it needs > >> release notes at least! > > > > No, I'm sure Ondřej only meant that he'd revert the replacement > > of the /media directory with a symlink to /run/media, which was in Rawhide > > for only two weeks or so. > > > > He does not intend to change the path where removable media get mounted. > > > > Michal > > Ondrey, I hope that you meant you'd revert the entire change. and put > removeable media mounting back in /media. I've still not seen a single > reason for the move, only a bugzilla about getting it tot work > correctly. Following the more recent File System hierarchy documents > and putting it in the documented /media makes much more sense. I just reverted the "two weeks in rawhide" symlink change already. /media is no longer symlink in Rawhide. Removeable media mount point is not under control of filesystem package (udisks2 mount them to /run/media/$USER/$Volname ). Based on Michal's suggestion, you can use UDISKS_FILESYSTEM_SHARED set to 1 to have removeable media mounted in /media instead of /run/media/$USER/ . Regards, Ondrej > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Attempting to contact two unresponsive maintainers - dajt and jpacner
On Wed, 2014-09-03 at 14:44 -0600, Kevin Fenzi wrote: > Greetings, we've been told that the email addresses for two package > maintainers are no longer valid. I'm starting the unresponsive > maintainer policy to find out if they are still interested in > maintaining their packages (and if so, have them update their email > addresses in FAS). If they're not interested in maintaining or we > can't locate them I'll have FESCo orphan the packages so that others > can take them over. > > If you have a way to contact any of these maintainers, please let them > know that we'd appreciate knowing what to do with their packages. > Thanks! > > Maintainers: > > * jpacner - former email address jpac...@redhat.com > https://admin.fedoraproject.org/pkgdb/packager/jpacner > Point of contact: 0 > Co-maintainer: 5 > Watched:0 Jan left Red Hat to continue with his university study. Feel free to remove him from packages where he is Co-maintainer - primary ownership was already transfered (or new comaintainer already asked for permission approval). Regards, Ondrej Vasik -- 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: man-db without cache update (no cron or systemd *.timer)
On Wed, 2014-10-15 at 18:01 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Oct 15, 2014 at 05:12:07PM +0200, Peter Schiffer wrote: > > On 10/15/2014 04:47 PM, Chris Adams wrote: > > >Once upon a time, Jan Chaloupka said: > > >>there has been a discussion about if we need cache for man-db for users > > >>which use man pages or update system only from time to time and thus > > >>don't need to update cache every day. man-db as it is now depends on > > >>systemd which brings another set of packages. The use case is "I just > > >>want to read man page. So I install man which on the other hand download > > >>another set of packages. I want to read man page and it downloads > > >>systemd.". > > > > > >On the majority of systems these days, is it really an issue to cache > > >man pages anymore? I mean, back when a long man page (thinking about > > >some of the perl documentation for example) could take a while to > > >render, it mattered. Now however, systems are much much faster, and we > > >expect GUI web browsers to render vastly more complicated content in a > > >fraction of a second. > > > > > >Maybe the time has come to just stop caching man pages at all, or at > > >least make that functionality optional (and non-default)? > > > > > > > Hello, > > > > I would add some noteworthy information: > > > > * the man-db cron/timer script is taking care of man DB containing > > only the man page title and short description i.e., the first NAME > > section of the man page. This DB is speeding up the searching in > > mentioned section with the man -k command. It is not used for > > displaying man pages or doing the full text search with man -K command > > and it is not required for normal usage of man command (man -k should > > also work without this DB). > > > > * Debian is updating this DB via deb hooks (or how it is called) > > during package installation/update and via daily cron script for man > > pages installed outside of package manager. > > > > * updating this DB is usually pretty quick, but creation can take some > > time.. > > > > * man pages cache, pre-formatted man pages stored on disk in plain > > text, called cat pages in man-db context, is not used in Fedora. > > I don't think that adding an additional subpackage to be manually > installed is worth the trouble. We should be making things simpler for > administrators, not require more manual involvement. From Peters' > description it seems it would be fine to simply ignore the timer and > not have the cache if systemd is not running for whatever reason. So > it would seem that ommitting systemd from the dependency list is the > answer. But omitting systemd from the dependency list is not possible, > because the dependency is necessary to order man-db after systemd in > case of a normal installation of both in one transaction. After things > calm down with F21, I'll return to the idea of splitting out > systemd-filesystem (name subject to change) to allow packages which Or we may even move unitdir into the basic filesystem package - if the unitdir is the only requirement - which is probably the case for most of the daemons. It would probably be better than systemd-filesystem subpackage. Ondrej > only need to enable a unit not to have a depenedency on full systemd > stack (see the thread "systemd dependencies" from August for recent > discussion). > > Zbyszek > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Attempting to contact three unresponsive maintainers
On Fri, 2014-03-28 at 10:11 -0700, Toshio Kuratomi wrote: > Greetings, we've been told that the email addresses for three package > maintainers are no longer valid. I'm starting the unresponsive maintainer > policy to find out if they are still interested in maintaining their > packages (and if so, have them update their email addresses in FAS). If > they're not interested in maintaining or we can't locate them I'll have > FESCo orphan the packages so that others can take them over. > > If you have a way to contact any of these maintainers, please let them know > that we'd appreciate knowing what to do with their packages. Thanks! > > Maintainers: > * llim -- Lawrence Lim -- former email address l...@redhat.com > - Bugzilla owner of redhat-lsb If you don't find any contact for llim, feel free to reassign redhat-lsb to me - I'm monitoring the bugzillas of redhat-lsb package anyway and I'm the owner in RHEL. We discussed with Lawrence transfer even in Fedora, but it never happened. Greetings, Ondrej Vasik -- 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: Attempting to contact unresponsive maintainer - jkoncick
On Mon, 2014-07-07 at 12:52 -0600, Kevin Fenzi wrote: > Greetings, we've been told that the email addresses > for this package maintainer is no longer valid. I'm starting the > unresponsive maintainer policy to find out if they are still interested > in maintaining their packages (and if so, have them update their email > addresses in FAS). If they're not interested in maintaining or we > can't locate them I'll have FESCo orphan the packages so that others > can take them over. > > If you have a way to contact this maintainer, please let them > know that we'd appreciate knowing what to do with their packages. > Thanks! > > * jkoncick - former email address: jkonc...@redhat.com > https://admin.fedoraproject.org/pkgdb/packager/jkoncick Yes, Jaromir left Red Hat recently and he will no longer maintain his packages. Feel free to remove his co-maintainer status and move the tcsh master branch either to me (ovasik) or praiskup . Thanks! Greetings, Ondrej Vasik > > If we don't hear anything in a week, we will be removing their acls and > will need to find new point of contacts, etc. > > Thanks, > > kevin > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: UsrMove, /etc/shells, and rpm interpreter requires
On Tue, 2012-07-10 at 10:30 -0700, Toshio Kuratomi wrote: > On Tue, Jul 10, 2012 at 06:12:45PM +0200, Harald Hoyer wrote: > > Am 10.07.2012 17:18, schrieb Orion Poplawski: > > > Shouldn't that be /usr/ as well. Will it cause problems if it doesn't > > > match > > > with the /etc/passwd entry? > > > > > > > > > > yes, /etc/shells might be a problem... I would suggest: > > > > install the $shell in /usr/bin/$shell, Provide: /bin/$shell in the spec > > file and > > add both paths in /etc/shell > > > > or we patch "chsh" and the like? > > > Adding both paths to /etc/shell sounds preferable to me. I can update the default /etc/shells shell paths to contain both paths in setup package, however, other shell packages are modifying it too, so it would be better to have some solution without need to involve dash, zsh, tcsh, ksh and maybe other shell maintainers and need them to update their packages because of the UsrMove changes. Any ideas? Greetings, Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/etc?
On Sun, 2013-08-04 at 18:51 -0400, Colin Walters wrote: > On Sun, 2013-08-04 at 13:16 +0200, Lennart Poettering wrote: > > I noticed this: > > > > $ rpm -qf /usr/etc > > filesystem-3.2-12.fc19.x86_64 > > A quick git annotate shows it originates from: > > http://pkgs.fedoraproject.org/cgit/filesystem.git/commit/?id=cd01d2d6d54f59ef8e177d0391bc734fba470ef4 > > With no comment as to why...just a copy/paste error? Probably not copy&paste but I don't think it was intentional. I'll remove this line from filesystem spec file, I had no intention to introduce /usr/etc (thanks for spotting this). Greetings, Ondrej -- 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: /usr/etc?
On Mon, 2013-08-05 at 12:53 +0200, Ondrej Vasik wrote: > On Sun, 2013-08-04 at 18:51 -0400, Colin Walters wrote: > > On Sun, 2013-08-04 at 13:16 +0200, Lennart Poettering wrote: > > > I noticed this: > > > > > > $ rpm -qf /usr/etc > > > filesystem-3.2-12.fc19.x86_64 > > > > A quick git annotate shows it originates from: > > > > http://pkgs.fedoraproject.org/cgit/filesystem.git/commit/?id=cd01d2d6d54f59ef8e177d0391bc734fba470ef4 > > > > With no comment as to why...just a copy/paste error? > > Probably not copy&paste but I don't think it was intentional. I'll > remove this line from filesystem spec file, I had no intention to > introduce /usr/etc (thanks for spotting this). Now I probably see why I did that - it was in the RPM_BUILD_ROOT from some reason and because of the capabilities change, I needed to explicitly mention all directories created in RPM_BUILD_ROOT. So this commit just exposed /usr/etc explicitly what was in the package payload since at least 2004 (I don't have older data). If noone knows why this directory should exist, I'll be more than happy to drop it... Ondrej -- 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: /usr/etc?
On Wed, 2013-08-07 at 11:35 -0400, Bill Nottingham wrote: > Ondrej Vasik (ova...@redhat.com) said: > > Now I probably see why I did that - it was in the RPM_BUILD_ROOT from > > some reason and because of the capabilities change, I needed to > > explicitly mention all directories created in RPM_BUILD_ROOT. So this > > commit just exposed /usr/etc explicitly what was in the package payload > > since at least 2004 (I don't have older data). If noone knows why this > > directory should exist, I'll be more than happy to drop it... > > Yeah, it's always been in there back to 1998, at least. It came from > FSSTND (the FHS precursor): > http://ibiblio.org/pub/linux/docs/fsstnd/old/fsstnd-1.2.txt > > ... > > 4.5 /usr/etc : Site-wide system configuration > > Storing configuration in /usr/etc for the software found in /usr/bin and > /usr/sbin is a problem. It makes the read-only mounting of /usr through > CD-ROM or NFS delivery very difficult at best. > > One possible solution that we considered was to completely eliminate > /usr/etc and specify that all configuration be stored in /etc. A > problem with this approach is that it does not properly anticipate the > possibility that many sites may want to have some configuration files > that are not machine-local. > > We eventually decided that /etc should be the only directory that is > actually referenced by programs (that is, everything should look for > configuration in /etc and not in /usr/etc). Any configuration files > that need to be site-wide and are not needed before /usr is mounted (or > in an emergency situation) should then be placed in /usr/etc. Then, > specific files (in /etc) on specific machines may or may not be > symbolically linked to appropriate configuration files located in > /usr/etc. This also means that /usr/etc is technically an optional > directory in the strictest sense, but we still recommend that all Linux > systems incorporate it. > > It is not recommended for /usr/etc to contain symbolic links that point > to files in /etc. This is unnecessary and interferes with local control > on machines that share a /usr directory. > ... > > It (and /usr/local/etc) were dropped in FHS 2.1 in 2001. So... nuke it? I already nuked /usr/etc yesterday - as FHS even disallows it (see http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY Rationale note). But I still see /usr/local/etc there - and mentioned as beneficial, so keeping it for now. Greetings, Ondrej -- 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: Wider feedback requested on two changes to our base/core defaults
On Wed, 2013-08-21 at 18:45 +, "Jóhann B. Guðmundsson" wrote: > Greetings all > > After sitting Dan's Walsh Secure Linux Containers talk at flock where he > mentioned him and Dan B. had successfully scaled application containers > to what 8000 instances or so and I noticing that his slide where a bit > dated due to the changes in croup I decided to have a look at the > current state in systemd to see what we needed to fix and properly > integrate those changes into Fedora and deliver good out of the box > container experience for our administrators and users as well as > document those changes ( early readers can jump here [1] just note this > page is a work in progress ). ... > I would like us to change our default to use long hostname instead as in > the fqdn or "container01.ackme.com" and would love any kind of feed back > in that regard ( why we should not default to that ). > > The downside of doing that ofcourse if you have like 6 level domain name > in your infrastructure like "i'm.a.really.long.domain.name.com" it might > become a bit of a nuance but administrators could always revert those > change to use short hostname instead if that was the case. I perfectly understand the reasons for the change and I think we should definitely change it at least on the login screen (I like the one additional line idea from Simo). In the terminal label, full hostname might make sense as well. But I don't like the idea for the command line PS1 change. Even if I don't have too long FQDN, it will extend my basic prompt from 23 to 38 (almost half of 80 chars) on 1 system I use most and to 20 to 43 on another one. This is imho too much (so if the final decision would be to change \h to \H, I'm going to change the default PS1 back on my machine anyway). Having hostname as separate line will make cut&paste of command sequence from terminal harder to read. I know that many users modify the basic PS1 anyway, but IMHO nothing blocks you from having modified PS1 in ~/.bashrc (or directly in /etc/skel/). > The other issue I would like to get some comments on is that we default > to setting an empty root password which will allow administrators to log > into containers as root and set the root password as well as removing > few line from spin kickstarts as well being beneficial to the arm > community. Maybe this could be solved by ssh key in .ssh subdir in /etc/skel and having containers copying these files for root/container users. This way you should be able to login without password via ssh from your machine, but still would be safe for the common usecases. Defaulting to empty root password is IMHO bad idea (-1 from me), we have to think about other ways how to achieve this. Greetings, Ondrej -- 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: Wider feedback requested on two changes to our base/core defaults
On Thu, 2013-08-22 at 08:21 -0500, Chris Adams wrote: > Once upon a time, "Jóhann B. Guðmundsson" said: > > You would just overwrite in in your own .bashrc if you have long > > hostname and they get in your way. > > > > Long hostnames are far more practical for administrators to use then > > short hostnames have ever been. > > That's your opinion; please don't state it as if it is an agreed-upon > fact. Mine differs; personal like/dislike is not a good reason to > change existing defaults. > > Some people have long domain names (and not just a lot of dotted > components, but long individual sections); taking up a bunch of space on > every prompt line just to re-print the same domain is a waste. However, > even with a short domain, it is just too much IMHO (and I worked for > several years for someone with just about as short of a domain name as > you can get). > > I find the Red Hat/Fedora default prompt too long already; IMHO: > > - The square brackets are useless wrapping; there's also a > character+space separator at the end of the prompt. I agree that opening square bracket is useless, but I want to have the directory and $/# character separated. This prompt is well established, however I agree that we can probably get one character less with something like foo@localhost lib>$ > - The "user@" is mostly useless; if you su/sudo to root, the character > at the end of the prompt changes from $ to #. The only time I would > be interested in seeing user@ is if I've su/sudo to a user (other than > root) that doesn't match the login user for this TTY; on Linux this > can be as easy as the following bit of bash: > > local user="" > if [ "$UID" != 0 -a ! -O /proc/self/fd/0 ]; then > user='\u@' > fi > PS1="$user"'\h \W\$ ' Good suggestion, I like it - and maybe it would make sense to change the default to this if wider audience will agree on that. Still I don't agree that this is useless - I usually have several terminals with ssh connection and they are differentiated in user (e.g. per tool I'm using on that machine). Having only hostname will make it harder for me (as the hostnames differ only in number). Most of the users probably don't have this scenario, so I'm a bit toward to +1 here. Greetings, Ondrej -- 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: [coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)
- Original Message - > 2013/5/17 Ondrej Vasik < ova...@fedoraproject.org > > > > commit ed5396d91e0032fa7cbfd6cb0bde3d7850aba790 > Author: Ondřej Vašík < ova...@redhat.com > > Date: Fri May 17 09:21:51 2013 +0200 > > require glibc-devel to prevent broken links in coreutils info manual > (#959697) > > I don't think having glibc-devel installed by default will make it. > Also you bugzilla number is wrong. (unrelated). Thanks, fixed the typo in changelog... Why do you think it will not make it work? Glibc info manuals are there, so the broken links should be prevented by this. Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)
- Original Message - > 2013/5/17 Ondrej Vasik < ova...@redhat.com > > - Original Message - > > 2013/5/17 Ondrej Vasik < ova...@fedoraproject.org > > > > > > > commit ed5396d91e0032fa7cbfd6cb0bde3d7850aba790 > > Author: Ondřej Vašík < ova...@redhat.com > > > Date: Fri May 17 09:21:51 2013 +0200 > > > > require glibc-devel to prevent broken links in coreutils info manual > > (#959697) > > > > I don't think having glibc-devel installed by default will make it. > > Also you bugzilla number is wrong. (unrelated). > > Thanks, fixed the typo in changelog... > Why do you think it will not make it work? Glibc info manuals are there, so > the broken links should be prevented by this. > The general idea of splitting packages is that you can install one that is > required and not another that is optional. > As coreutils is required by default, that's defeat the point to even have > this split made. Because both will be required. > > My understanding is that libc*.info should be moved to the main glibc instead > as most info file belong to the main package. > One that doesn't want to install the documentation can still install with rpm > nodocs That's what I suggested to glibc maintainers - to move it to glibc-common, so everything would be fine. They insist that this info is intended for developers, therefore I have two options - require glibc-devel (just ~1M, most of the other files are links or small files) or live with broken links (and WONTFIX that). You are right about nodocs, though. Greetings, Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)
> On Fri, May 17, 2013 at 04:25:43AM -0400, Ondrej Vasik wrote: > > > 2013/5/17 Ondrej Vasik < ova...@redhat.com > > > > > 2013/5/17 Ondrej Vasik < ova...@fedoraproject.org > > > > > > > > > > > > > commit ed5396d91e0032fa7cbfd6cb0bde3d7850aba790 > > > > Author: Ondřej Vašík < ova...@redhat.com > > > > > Date: Fri May 17 09:21:51 2013 +0200 > > > > > > > > require glibc-devel to prevent broken links in coreutils info manual > > > > (#959697) > > > > > > > > I don't think having glibc-devel installed by default will make it. > > > > Also you bugzilla number is wrong. (unrelated). > > > > > > Thanks, fixed the typo in changelog... > > > Why do you think it will not make it work? Glibc info manuals are there, > > > so > > > the broken links should be prevented by this. > > > The general idea of splitting packages is that you can install one that > > > is > > > required and not another that is optional. > > > As coreutils is required by default, that's defeat the point to even have > > > this split made. Because both will be required. > > > > > > My understanding is that libc*.info should be moved to the main glibc > > > instead > > > as most info file belong to the main package. > > > One that doesn't want to install the documentation can still install with > > > rpm > > > nodocs > > > > That's what I suggested to glibc maintainers - to move it to glibc-common, > > so everything would be fine. They insist that this info is intended for > > developers, therefore I have two options - require glibc-devel (just ~1M, > > most of the other files are links or small files) or live with broken > > links (and WONTFIX that). You are right about nodocs, though. > > Or better still, fix the coreutils user-targetted docs, to not refer to > glibc's developer-targetted docs. Coreutils docs could just include info > on how to set the TZ variable, instead of punting the task to glibc's > developer docs. Well, I don't think glibc info doc has only developer-targetted info - that's the issue - there are more things useful to regular experienced users (like regexps info, locales info). Duplicating nodes as downstream patch is no go for me - hard to maintain and unacceptable upstream. Broken links are better than that - and Require: glibc-devel is more temporary (and of course not perfect) solution until more sane approach will be possible. Greetings, Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)
> On Fri, May 17, 2013 at 06:22:09AM -0400, Ondrej Vasik wrote: > > > On Fri, May 17, 2013 at 04:25:43AM -0400, Ondrej Vasik wrote: > > > > > 2013/5/17 Ondrej Vasik < ova...@redhat.com > > > > > > > 2013/5/17 Ondrej Vasik < ova...@fedoraproject.org > > > > > > > > > > > > > > > > > > > commit ed5396d91e0032fa7cbfd6cb0bde3d7850aba790 > > > > > > Author: Ondřej Vašík < ova...@redhat.com > > > > > > > Date: Fri May 17 09:21:51 2013 +0200 > > > > > > > > > > > > require glibc-devel to prevent broken links in coreutils info > > > > > > manual > > > > > > (#959697) > > > > > > > > > > > > I don't think having glibc-devel installed by default will make it. > > > > > > Also you bugzilla number is wrong. (unrelated). > > > > > > > > > > Thanks, fixed the typo in changelog... > > > > > Why do you think it will not make it work? Glibc info manuals are > > > > > there, > > > > > so > > > > > the broken links should be prevented by this. > > > > > The general idea of splitting packages is that you can install one > > > > > that > > > > > is > > > > > required and not another that is optional. > > > > > As coreutils is required by default, that's defeat the point to even > > > > > have > > > > > this split made. Because both will be required. > > > > > > > > > > My understanding is that libc*.info should be moved to the main glibc > > > > > instead > > > > > as most info file belong to the main package. > > > > > One that doesn't want to install the documentation can still install > > > > > with > > > > > rpm > > > > > nodocs > > > > > > > > That's what I suggested to glibc maintainers - to move it to > > > > glibc-common, > > > > so everything would be fine. They insist that this info is intended for > > > > developers, therefore I have two options - require glibc-devel (just > > > > ~1M, > > > > most of the other files are links or small files) or live with broken > > > > links (and WONTFIX that). You are right about nodocs, though. > > > > > > Or better still, fix the coreutils user-targetted docs, to not refer to > > > glibc's developer-targetted docs. Coreutils docs could just include info > > > on how to set the TZ variable, instead of punting the task to glibc's > > > developer docs. > > > > Well, I don't think glibc info doc has only developer-targetted info - > > that's the issue - there are more things useful to regular experienced > > users (like regexps info, locales info). > > In that case, glibc maintainers need to re-consider their claim that it > is only material for developers & put it in glibc-common or a glibc-docs > package instead of the -devel package That's what the glibc maintainers proposed as longer term solution for their upstream todo list - split their info doc into strictly devel part and "general purpose" part. This may need some time, though (and even then, it will probably need some adoption, as it will probably be named differently, so links may break again)... Require glibc-devel in coreutils means + ~1M to default minimal installation size. Not much, but not good practice, I agree. I may go with coreutils-infodoc (or something like that) subpackage (keeping just basic manuals in main package and additional docs separately). This will bring back the "granularity" instead of hard dependency in the minimal install package. Any thoughts? Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [coreutils] require glibc-devel to prevent broken links in coreutils info manual (#959697)
> Am 17.05.2013 12:35, schrieb Ondrej Vasik: > >> In that case, glibc maintainers need to re-consider their claim that it > >> is only material for developers & put it in glibc-common or a glibc-docs > >> package instead of the -devel package > > > > That's what the glibc maintainers proposed as longer term solution for > > their upstream todo list - split their info doc into strictly devel part > > and "general purpose" part. This may need some time, though (and even > > then, it will probably need some adoption, as it will probably be named > > differently, so links may break again)... > > > > Require glibc-devel in coreutils means + ~1M to default minimal > > installation size. Not much, but not good practice, I agree. I may go with > > coreutils-infodoc (or something like that) subpackage (keeping just basic > > manuals in main package and additional docs separately). This will bring > > back the "granularity" instead of hard dependency in the minimal install > > package. Any thoughts? > > no, it pulls "glibc-headers" and "kernel-headers" too > which are in summary 5.9 MB and around 120 MB on our > virtual infrastructure Ah, sorry, forgot about this. Reverted and will wait for -docs or separate non-developer info subpackage. Ondrej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PSA: If you are C/C++ developer, use cppcheck
On Tue, 2013-12-17 at 13:17 -0500, Rahul Sundaram wrote: > Hi > > > On Tue, Dec 17, 2013 at 12:47 PM, Daniel P. Berrange wrote: > > The issues reported against libvirt all appear to be false > positives. > Not entirely surprising since we already have coverity run > against > libvirt code nightly. > > > Thanks for the quick response.Does Red Hat run it only for > packages in RHEL or it is run against all Fedora packages? If not, > would it be possible for Red Hat to do so and publish the results on a > regular basis? That might be a useful service. Nightly Coverity scans for whole Fedora wouldn't work - RHEL subset of packages is scanned bi-yearly - as the ~1500 C/C++ takes 21+ days to scan (150M lines of code). Whole Fedora would take ~3 months+ . Our RHEL maintainers are notified about the results and are encouraged to share the results with upstreams - many of them do. Publishing them is a bit tricky - I can of course publish them (we scan with cppcheck, enhanced gcc warnings, clang and coverity) - but the reports may contain some attack vectors - and for inactive packages, it would only show the doors to attackers. If you are community guy (maintainer/upstream) and you are interested in getting the result of the bi-yearly scans, just send me an email and list of packages you want to get the result (of course, as I said, we scan only RHEL set of packages). We work on open sourcing this scanning tool based on mock (covering the static analyzers) - so people can use it for their packages more easily. It could even be integrated into the infrastructure somehow, as there is no license limitation. For non RHEL packages, I would recommend to work with upstream to join http://scan2.coverity.com/ . In addition, very beneficial thing is to get DIFFERENCE between two scans - I would recommend codescan-diff ( https://git.fedorahosted.org/git/codescan-diff.git ) - it was originally designed for the internal Coverity scans, but now it has support for various static analyzers. Greetings, Ondrej Vasik -- 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: PSA: If you are C/C++ developer, use cppcheck
On Wed, 2013-12-18 at 09:12 +0100, Ondrej Vasik wrote: > On Tue, 2013-12-17 at 13:17 -0500, Rahul Sundaram wrote: > > Hi > > > > > > On Tue, Dec 17, 2013 at 12:47 PM, Daniel P. Berrange wrote: > > > > The issues reported against libvirt all appear to be false > > positives. > > Not entirely surprising since we already have coverity run > > against > > libvirt code nightly. > > > > > > Thanks for the quick response.Does Red Hat run it only for > > packages in RHEL or it is run against all Fedora packages? If not, > > would it be possible for Red Hat to do so and publish the results on a > > regular basis? That might be a useful service. > > Nightly Coverity scans for whole Fedora wouldn't work - RHEL subset of > packages is scanned bi-yearly - as the ~1500 C/C++ takes 21+ days to > scan (150M lines of code). Whole Fedora would take ~3 months+ . Our > RHEL maintainers are notified about the results and are encouraged to > share the results with upstreams - many of them do. ... > packages). We work on open sourcing this scanning tool based on mock > (covering the static analyzers) - so people can use it for their > packages more easily. It could even be integrated into the > infrastructure somehow, as there is no license limitation. I meant integrating without Coverity support, as we can't provide access to scanners outside of Red Hat. Still, covering extra gcc warning levels, cppcheck and clang together would be beneficial. As to opensourcing - I can't give any time estimate, but it shouldn't take more than few months - most of the necessary steps already done. Greetings, Ondrej -- 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: PSA: If you are C/C++ developer, use cppcheck
On Wed, 2013-12-18 at 10:37 -0500, Dave Jones wrote: > On Wed, Dec 18, 2013 at 09:12:06AM +0100, Ondrej Vasik wrote: > > > Publishing them is a bit tricky - I can of course publish them (we scan > > with cppcheck, enhanced gcc warnings, clang and coverity) - but the > > reports may contain some attack vectors - and for inactive packages, it > > would only show the doors to attackers. > > Then it's a good thing that attackers don't have any money and can't afford > to buy a checker license themselves. > > Hiding bugs doesn't make them go away, and pretending we have tools bad people > don't is a fallacy. Yes, many of them have, many of them use these tools, many of them have their own ones... I'm not trying to pretend that they don't have them - but why to lower the bar? Many teenagers experiment with computer viruses and cracking, and they obviously don't have the money but have plenty of time - which is the key when walking through the reports from large projects - it could be playground for such kiddies. With publishing the reports, you basically FORCE the upstream to work on it - and some upstreams are already busy enough with huge patch-review backlog. Average density of code defect is ~1k loc/defect, so you can easily find out that we have around 150k defects to analyze only in RHEL packages - aproximately 4x more in the C/C++ rest of Fedora. With ~5 minutes per defect... it is not for one or few persons. And analyzing security impact of some buffer overflows - this is not 5 minute job - so you don't know if the fix requires the CVE or not. I'm afraid it would only make the things screwed up. Giving some tool to make the analyzers use easier for everyone, that's IMHO the right way. Greetings, Ondrej Vasik -- 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: PSA: If you are C/C++ developer, use cppcheck
On Wed, 2013-12-18 at 16:47 +0100, Reindl Harald wrote: > Am 18.12.2013 16:37, schrieb Dave Jones: > > On Wed, Dec 18, 2013 at 09:12:06AM +0100, Ondrej Vasik wrote: > > > > > Publishing them is a bit tricky - I can of course publish them (we scan > > > with cppcheck, enhanced gcc warnings, clang and coverity) - but the > > > reports may contain some attack vectors - and for inactive packages, it > > > would only show the doors to attackers. > > > > Then it's a good thing that attackers don't have any money and can't afford > > to buy a checker license themselves. > > > > Hiding bugs doesn't make them go away, and pretending we have tools bad > > people > > don't is a fallacy. > > +1 > > and only if security problems are public makes enough pressure > for too many developers to care about them - and before someone > says "and they may still not care about them", well, than you > know which piece of software should be replaced next instead > other working pieces > > seucrity by obscurity is dumb, did never work and will never work Btw. you can check how it worked for the project where both RH and upstream were WILLING to work on the report and published it on wiki - net-snmp example is at http://www.net-snmp.org/wiki/index.php/5.7.1_Coverity_scan - even after 2 years, there are some groups unchecked (although the most critical ones were analyzed and fixed/commented in ~1 year). Greetings, Ondrej -- 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: PSA: If you are C/C++ developer, use cppcheck
On Wed, 2013-12-18 at 19:00 +0100, Reindl Harald wrote: > Am 18.12.2013 18:54, schrieb Ondrej Vasik: > > On Wed, 2013-12-18 at 16:47 +0100, Reindl Harald wrote: > >> Am 18.12.2013 16:37, schrieb Dave Jones: > >>> On Wed, Dec 18, 2013 at 09:12:06AM +0100, Ondrej Vasik wrote: > >>> > >>> > Publishing them is a bit tricky - I can of course publish them (we scan > >>> > with cppcheck, enhanced gcc warnings, clang and coverity) - but the > >>> > reports may contain some attack vectors - and for inactive packages, it > >>> > would only show the doors to attackers. > >>> > >>> Then it's a good thing that attackers don't have any money and can't > >>> afford > >>> to buy a checker license themselves. > >>> > >>> Hiding bugs doesn't make them go away, and pretending we have tools bad > >>> people > >>> don't is a fallacy. > >> > >> +1 > >> > >> and only if security problems are public makes enough pressure > >> for too many developers to care about them - and before someone > >> says "and they may still not care about them", well, than you > >> know which piece of software should be replaced next instead > >> other working pieces > >> > >> seucrity by obscurity is dumb, did never work and will never work > > > > Btw. you can check how it worked for the project where both RH and > > upstream were WILLING to work on the report and published it on wiki - > > net-snmp example is at > > http://www.net-snmp.org/wiki/index.php/5.7.1_Coverity_scan - even after > > 2 years, there are some groups unchecked (although the most critical > > ones were analyzed and fixed/commented in ~1 year) > > well, does *not* sound like upstream is *really* willing > otherwise it would have been fixed > > and yes i have worked with upstream-developers where the reaction > after a coverity scan was this while *one day* after i pointed > out that cobverity exists at all the first commit landed > > http://git.dbmail.eu/paul/dbmail/log/?qt=grep&q=coverity Ok, so we have some upstreams where noone will look for years, we have some upstreams, who can fix the report within one day, we have some upstreams where it will take several months or years. If you check the net-snmp, there was ~160 issues fixed based on this report - in your case, the difference is ~+200/-150 loc in ~1 month timeframe - this is probably doable if it doesn't involve design changes to fix some issues. I'm completely for sharing the output of the scans with upstreams - and many upstreams were contacted by Red Hat guys (many times with patches)- however having such report concentrated on one place is not a good idea. Btw. publishing security hole (as you suggested in one of your previous emails) is one of the worst things you can do. Private emails to upstream or some security distribution lists is much better idea in such cases (imagine a hole e.g. httpd/bind - and the maintainer on PTO/sick leave). Ondrej -- 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: retiring basesystem package
Hi Zbigniew, yes, basesystem is there just to ensure installation order and it could probably be achieved by that PR. There is one more benefit from the retirement - as there are occasionally bug reports (that should be filed against distribution) reported as basesystem issues (similarly to setup package being target for installation issues and filesystem package for issues with the partition layout). Retirement could reduce the confusion for people... Regards, Ondrej On Thu, Feb 6, 2025 at 1:19 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > Hi, > > I was looking at early system installation, and we have filesystem, > basesystem, and setup, all competing for the title of the early > filesystem setup… It seems that basesystem is the easiest to > eliminate: it has no files and no scriptlets. > > https://src.fedoraproject.org/rpms/filesystem/pull-request/20 adds > Provides+Obsolets: basesystem to filesystem. If that is merged, we can > retire basesystem. > > The change is simple, but maybe there's some tricky dependency somewhere, > so I'm putting fedora-devel in CC. > > Zbyszek > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
