Re: Intention to retire mlocate
On Fri, May 17, 2024 at 6:14 PM Michal Sekletar wrote: > Hi everyone, > > We have had a plocate as a drop-in replacement for mlocate for quite a > while now. My intention is to retire the mlocate package next week in order > to prevent duplication and so that we can focus only on plocate > going forward. > mlocate is now retired in Rawhide. https://src.fedoraproject.org/rpms/mlocate/c/7277dd5f59db126d1046a6aa5c4077a597dc?branch=rawhide > > Have a nice weekend, > Michal > -- ___ 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
Intention to retire mlocate
Hi everyone, We have had a plocate as a drop-in replacement for mlocate for quite a while now. My intention is to retire the mlocate package next week in order to prevent duplication and so that we can focus only on plocate going forward. Have a nice weekend, Michal -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: plocate?
On Tue, May 4, 2021 at 1:25 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > > I agree. Plocate/mlocate is useful technology, but it's not important > enough to justify maintaining two or three different implementations. > If we can make plocate cover all bases, and it's faster, I'd just make > it *the* implementation. Let's get the agreement of mlocate maintainer > first though. Michal, wdyt? > > Hi everyone, I agree that we should transition to the newer (faster and well maintained) implementation and in the long run we should have only one locate implementation in the distribution. However, I think we should have some transition period (e.g. two Fedora release cycles), during which both packages will be present. Introducing alternatives scaffolding seems like an overkill for something that is going away in a year, hence plain Conflits: tag would be enough. As for maintenance, I think that having an older (mlocate) package available for a year or so while we iron out potential compat issues or bugs shouldn't add too much work. Zbigniew, please take plocate through the review process and once it is included in the distro I am willing to take up (co)maintenance of the package. Cheers, Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Orphaned packages looking for new maintainers
On Mon, Mar 8, 2021 at 3:28 PM Gwyn Ciesla via devel wrote: > > > > > avahi msekleta, orphan 0 weeks ago > > I'd like someone more familiar with this to take it, but if no one steps up, > I will I took it. Btw, I am maintaining avahi in RHEL. Cheers, Michal > > -G___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: [HEADS-UP] libevent 2.1.12 with a soname bump is coming to Rawhide
On Tue, Sep 15, 2020 at 11:17 AM Ondřej Lysoněk wrote: > > Initial set: > - avahi - needs to be bootstrapped > - packages that I haven't been able to rebuild: > - community-mysql, libreswan, perl-Event-Lib, sems > - other: addrwatch, ccnet, coturn, groonga, ladvd, libasr, > libverto, links, lldpd, memcached, mpris-scrobbler, nbd-runner, > nfs-utils, nsd, ntp, ocproxy, opensmtpd, pgbouncer, php-pecl-event, > php-pecl-http, pmix, remctl, scanssh, seafile, sslsplit, > sstp-client, suricata, tmate, tmux, trickle, unbound, uwsgi, zabbix > > After avahi is rebuilt, we can rebuild: > 389-ds-base, fragments, fstrm, icecat, libcouchbase, lua-event, > netatalk, qt5-qtwebengine, thrift, tor, transmission > Hi everyone, I've just rebuilt avahi in the bootstrap configuration and final rebuilt with bootstrap mode turned off is in progress. https://koji.fedoraproject.org/koji/buildinfo?buildID=1613864 https://koji.fedoraproject.org/koji/taskinfo?taskID=51958298 Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: starting services in fedora
On Tue, Apr 17, 2018 at 10:52 AM, Petr Pisar wrote: > You mean systemctl can talk to a systemd via > /var/run/dbus/system_bus_socket. Ok. IIRC, systemctl detects that it is running in chrooted environment (i.e. system isn't "live") by looking at inode number of /. If the number that systemctl sees (/proc//root) and one that PID 1 see are different than systemctl assumes it is chrooted and refuses to serve service start requests. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [ACTION NEEDED] Missing BuildRequires: gcc/gcc-c++
On Sun, Mar 4, 2018 at 4:09 AM, Jerry James wrote: > On Sun, Feb 18, 2018 at 10:09 AM, Igor Gnatenko > wrote: >> If you fixed package(s), found false positive, found missing packages in list >> or anything else -- please let me know. > Fixed: avahi, bird, biosdevname, mlocate Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [Fedora-packaging] Package naming question
On Tue, Dec 5, 2017 at 1:07 PM, Tomasz Torcz wrote: > We have solved this years ago. man alternatives alternatives is a terrible solution if you ask me. Symlink hackery in /etc/alternatives is awful and I these days with Fedora kernel supporting mount namespaces we could do better. But it certainly works nonetheless. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: tcp_wrappers deprecation
On Tue, Aug 15, 2017 at 1:58 PM, Jakub Jelen wrote: > > So can we discuss it now once more without the affiliation to systemd? > The fact is that we still do not have any other replacement except > firewalls. But do we need one? > IIRC, in the past discussion there was quite a lot of people arguing that we actually need one. I personally don't think we as a distribution need a drop-in replacement. However, what we possibly need, is a migration path for already deployed systems using tcp_wrappers. Just dropping tcp_wrappers and potentially leaving deployed services completely open would very irresponsible. Also we should consider an impact this change will have on our downstreams focusing on enterprise use-cases (CentOS, RHEL). I recon that "splash damage" potentially caused by this change will be bigger there than in Fedora itself. Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Exploded source tree
On Tue, Jun 6, 2017 at 7:14 AM, Vít Ondruch wrote: > So what would be your workflow here? You would start update of the > package by "fedpkg upload" to upload the new tarball and let dist-git to > explode it? And what would be next? My ideal workflow would be to use pagure (repo with exploded source) just like I use github/gitlab/bitbucket these days. Hence if I am owner I commit directly or perhaps I file pull-request against the package source. Then once commit is merged, package maintainer tells koji to build the package. Note that Koji *has* support to build directly from git repo referenced in your spec. We just don't use this feature in Fedora, because up until pagure came along there was no suitable code hosting/collaboration platform available to Fedora package maintainers. > > I thought that the exploded tree would be more passive, i.e. it would > mirror just the basic tarball, possibly each Koji build would result in > some release branch containing also the applied patches, but it seems > you want to use it more actively Not only more actively, I would like to use it almost exclusively. In my opinion move into this direction would be hands down the best change for package maintainers in years. Also I personally think such possibility is also necessary if Fedora wants to attract new contributors in era of Github. Because let's be honest, plain dist-git (spec+patches) is just terrible experience compared to what people are used to upstream. Just my 0.02... Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora 26 Mass Branching
On Wed, Mar 1, 2017 at 10:26 AM, Jens-Ulrik Petersen wrote: > f27 builds in Koji are getting tagged with .fc26 currently, so I > suggest holding off on rawhide builds for now that you also want to > push to f26 until this is fixed. > I just hit this issue. Is there any ETA when this is going to be fixed? > Jens > > On Wed, Mar 1, 2017 at 4:25 PM, Mohan Boddu wrote: >> Hi All, >> >> Fedora 26 has now been branched, please be sure to do a git pull >> --rebase to pick up the new branch, as an additional reminder >> rawhide/f27 has been completely isolated from previous releases, so >> this means that anything you do for f26 you also have to do in the >> master branch and do a build there. There will be a Fedora 26 compose >> ASAP and it'll appear >> http://dl.fedoraproject.org/pub/fedora/linux/development/26/ once >> complete. Please be sure to check it out. Bodhi is currently not >> active for Fedora 26, it will be enabled in a weeks time when we hit >> Alpha change freeze point in the Fedora 26 schedule[1]. >> >> Mohan Boddu. >> >> [1] https://fedoraproject.org/wiki/Releases/26/Schedule >> ___ >> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org >> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org > > > > -- > Jens Petersen > Associate Manager > i18n Software Engineering > Customer Platform, CEE > Osaka, Japan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
User instances of systemd and SELinux
Hi all, Most of you are probably aware that systemd except running as PID 1 also runs inside user sessions. This allow users to define their own "user services" and start up various scripts and background processes right after logging in. In default targeted policy PID 1 runs with init_t SELinux label and --user instances of systemd are not confined by SELinux, i.e. running with unconfined_t. During Flock I got asked whether we can change that and run systemd --user instances in some confined domain. Fixing this on systemd side should be trivial, i.e. we would have to add SELinuxContext= option with appropriate value to /usr/lib/systemd/system/user@.service (unit file used for spawning user instances of systemd). I am writing this email with a hope that we can discuss if above proposal even makes sense (what are possible gains from system security perspective) and if yes what is appropriate SELinux label to use (I guess we would need new one and define policy for it). Michal -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: no systemd in containers: Requires -> Recommends
On Thu, Dec 17, 2015 at 4:18 PM, Lennart Poettering wrote: > On Thu, 17.12.15 11:28, Michal Sekletar (msekl...@redhat.com) wrote: > >> On Thu, Dec 17, 2015 at 10:43 AM, Harald Hoyer wrote: >> > The downside is: >> > - if systemd is installed afterwards, the %post scripts do not trigger >> > - packages, which need systemd-tmpfiles or systemd-sysusers could not be >> > converted >> >> IIRC, some time ago there was a proposal to split systemd-tmpfiles, >> systemd-sysusers and other utilities to separate sub-package called >> systemd-tools. We should probably revisit this idea. > > Why? Do you have any technical reasons? Reason to have those tools separate was to satisfy dependencies of rpm macros in various packages w/o a need to install systemd package. Michal -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: no systemd in containers: Requires -> Recommends
On Thu, Dec 17, 2015 at 10:43 AM, Harald Hoyer wrote: > The downside is: > - if systemd is installed afterwards, the %post scripts do not trigger > - packages, which need systemd-tmpfiles or systemd-sysusers could not be > converted IIRC, some time ago there was a proposal to split systemd-tmpfiles, systemd-sysusers and other utilities to separate sub-package called systemd-tools. We should probably revisit this idea. Michal -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Base] Base Design WG agenda meeting 29st June 2015 14:15 UTC on #fedora-meeting-2
On 06/26/2015 11:33 AM, Harald Hoyer wrote: - Optionally accept new members +1 for lnykryn being accepted as a WG member I can't attend meeting today because I will be traveling. Michal -- 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: [Base] Base Design WG agenda meeting 27 February 2015 15:00 UTC on #fedora-meeting
On Thu, Feb 26, 2015 at 01:02:59PM +0100, Harald Hoyer wrote: > Agenda: > - Interview candidates for new memberships > - Optionally accept new members > - Vote for new chairman of the Base Design WG to replace Phil Knirsch > - Open Floor > > Please add items by replying to this mail. Unfortunately I can't attend meeting today. Of course I am +1 on Harald being new chairman of the group. Michal > -- > 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: Status of weak dependencies support in Fedora 21+
On Mon, Nov 10, 2014 at 10:45:05AM +0100, Jan Zelený wrote: > However, what I'm not sure about is whether it's already possible to build > weak-deps enhanced rpms in Fedora, has someone tested that? I've heard it's > possible in COPR but I'm not sure about koji. I tested this and building weak-deps enhanced package in Koji worked for me as expected, maybe by pure luck though. Michal > > > > I have a real-world example where I'd like to mark a dependency as > > > Suggests instead of Requires and want to know if dnf is ready to > > > process it? > > > > I played with Recommends in one case and it actually worked as expected. > > Even package uninstalls and updates honored the dependency semantics as > > expected. However I think it is because libsolv's logic and not some > > explicit handling in dnf. > > Yeah, that's the sweet part. There needs to be some level of support in the > layers above but ultimately libsolv is the key part when it comes to weak > deps. > > [1] http://devconf.cz/ > > Thanks > Jan -- 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: Status of weak dependencies support in Fedora 21+
On Sat, Nov 08, 2014 at 09:54:35PM +0400, Peter Lemenkov wrote: > Hello All! > RPM shipped with Fedora 21+ has support for weak dependencies. What's > the current status of that feature? Is it ok to start using them > (building RPM with Recommends/Suggests tags)? I don't think it is ok to start using them for now. We don't have any packaging guidelines on their usage. > > I have a real-world example where I'd like to mark a dependency as > Suggests instead of Requires and want to know if dnf is ready to > process it? I played with Recommends in one case and it actually worked as expected. Even package uninstalls and updates honored the dependency semantics as expected. However I think it is because libsolv's logic and not some explicit handling in dnf. Michal > > -- > With best regards, Peter Lemenkov. > -- > 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: [Base] Potential cancel of Base Design WG agenda meeting 19 September 2014 15:00 UTC on #fedora-meeting
On Fri, Sep 19, 2014 at 02:58:00PM +0200, Phil Knirsch wrote: > Hi everyone. Hey Phil, > > As i'm not feeling well at all i won't be able to make it to our > regular meeting today. With Harald and vpavlin both on vacation I am up for canceling today's meeting for good. Regards, Michal > > So if any of you want to do run it feel free to do so, but i won't > be able to attend. And sorry for the late notice. > > Thanks & regards, Phil > > -- > Philipp Knirsch | Tel.: +49-711-96437-470 > Manager Core Services| Fax.: +49-711-96437-111 > Red Hat GmbH | Email: Phil Knirsch > Wankelstrasse 5 | Web: http://www.redhat.com/ > D-70563 Stuttgart, Germany > -- > 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: fakesystemd package breaking builds
On Wed, Aug 27, 2014 at 11:01:45PM -0400, Rahul Sundaram wrote: > Hi > > > On Wed, Aug 27, 2014 at 10:05 PM, Simo Sorce wrote: > > > > > I think you are readying way to much into a perfectly normal word that > > means: "hey we are discussing stuff related to your project, would you > > mind joining this sessions so we can have better understanding ?" > > > > That's possible. The essential problem however is seemingly systemd > related package and additional components are being introduced apparently > without systemd developers being aware of that. That suggests that there > is a communication problem irrespective of the words used We were discussing this issue on systemd hackfest during Flock in person. Hence as for fakesystemd I don't think there was anything done behind anybodies back. On the other hand, I acknowledge that there maybe doubts and concerns about overall implementation. > > Rahul Michal > -- > 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: systemd dependencies
On Tue, Aug 26, 2014 at 12:59:23PM +0200, Vít Ondruch wrote:
> Dne 26.8.2014 11:06, Michal Sekletar napsal(a):
> > On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
> >> Hi,
> > Hi Vít,
> >
> >> Recently I have noticed that systemd package dependency is creeping into
> >> some packages where it is not necessary. subversion [1] or rsync [2] are
> >> good examples. Please consider moving daemon parts into independent
> >> subpackages. When I install rsync/subversion, I am typically interested
> >> just in client side.
> > At some point in time (F16 IIRC) we had systemd-units package which
> > contained
> > /etc/rpm/macros.systemd file. Packagers which followed our guidelines used
> > for
> > example %{unitdir} macro in %files. Hence they added systemd-units to
> > BuildRequires.
> >
> > These days systemd-units no longer exists, macro file moved to systemd rpm
> > and
> > systemd-units is a provided by systemd rpm.
>
> Thank you for insightful explanation.
>
> Nevertheless, if you are using some macro, it is just build time
> dependency. I believe that the issue might be due to %{unitdir} folder
> ownership. And I see two solutions:
Yes it is build time dependency only.
>
> 1) Packages which ships unit files should consider to put them into sub
> package called either -daemon or -server. And this applies especially to
> packages such as man (forgot to mention this one previously), rsync or
> subversion. I don't typically use their server features or con jobs or
> whatever.
I think we can't make this a general rule. There are packages which has to ship
unit files in a main package and I'd argue that we have quite a lot of those.
Note
that it is rather gut feeling not a fact I researched or measured in any
way. In any case having *recomendation* in guidelines doesn't hurt, thus such
split should be left at the curtesy of the individual maintainers.
But then again, I am not against such change in packages where it makes
sense.
>
> 2) sytemd should consider to provide -filesystem package, which would
> limit the dependency to single small package (but this might be return
> to the -units subpackage days? Not sure).
That may improve a situation, but we have to commit to not going down the same
road in the future as we did with systemd-units. However I don't have all the
context why systemd-units was merged into systemd back then.
>
> Their combination might be the best solution.
>
> Vít
Michal
> --
> 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: systemd dependencies
On Tue, Aug 26, 2014 at 09:32:26AM +0200, Vít Ondruch wrote:
> Hi,
Hi Vít,
>
> Recently I have noticed that systemd package dependency is creeping into
> some packages where it is not necessary. subversion [1] or rsync [2] are
> good examples. Please consider moving daemon parts into independent
> subpackages. When I install rsync/subversion, I am typically interested
> just in client side.
At some point in time (F16 IIRC) we had systemd-units package which contained
/etc/rpm/macros.systemd file. Packagers which followed our guidelines used for
example %{unitdir} macro in %files. Hence they added systemd-units to
BuildRequires.
These days systemd-units no longer exists, macro file moved to systemd rpm and
systemd-units is a provided by systemd rpm. Therefore systemd proper creeping
into buildroots.
>
> Just to be clear, systemd-libs is in minimal build root already, so I am
> not complaining about systemd-libs package, but about systemd package.
>
>
> Thanks,
>
>
> Vít
Michal
>
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1133786
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1123813
> --
> 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: [Base] The Base Design WG is looking for a new committee member!
On Thu, Jul 10, 2014 at 11:00:12AM +0200, Phil Knirsch wrote: > Ups, seems i'm living in the future already. :) > > Meeting is of course on Friday, not Thursday, so hope to see you > there tomorrow! Sure, will be there. > > Thanks & regards, Phil Michal > > On 07/09/2014 05:23 PM, Phil Knirsch wrote: > >That sounds great Michal. If you could join us tomorrow at our meeting > >at 15:00 UTC on #fedora-meeting that would be excellent. > > > >Thank you for your interest and see you tomorrow! > > > >Regards, Phil > > > > > >On 07/08/2014 02:31 PM, Michal Sekletar wrote: > >>On Fri, Jun 27, 2014 at 06:13:01PM +0200, Phil Knirsch wrote: > >>>Hi everyone. > >> > >>Hello everyone, > >> > >>> > >>>As Bill Nottingham has decided to resign from the committee we now > >>>have a free seat that we'd like to fill with another person. > >>> > >>>In order to fill this seat i'm therefore reaching out here to Fedora > >>>development to offer allow any applicant from the community to get > >>>in touch with us and let us know you're interested, why you're > >>>interested, why you think you'd be a good fit and maybe even the > >>>things you'd like to drive or accomplish in the Base Design WG. > >> > >>I am interested in becoming a member of Base Design WG. I'd like help > >>with > >>accomplishing goals of Base WG and make sure that we provide minimal > >>but solid > >>foundation for others to build upon. > >> > >>I believe my previous experience makes me a good fit for this position : > >> * Red Hat employee since 2011, now member of "Plumbers" group > >> * maintainer and contributor to various networking related projects > >> * systemd maintainer in RHEL > >> > >>I'd like to help with integration of upstream changes in key > >>components to the > >>distribution and making sure they are not disruptive. Another area > >>where I'd > >>like to contribute are container use cases of Fedora Base. Ensuring we > >>provide > >>minimal, but easily extensible platform for sand-boxed/containerized > >>apps. > >> > >>> > >>>For more background on what the Base WG does, here our Fedora wiki: > >>> > >>>https://fedoraproject.org/wiki/Base > >>> > >>>In order to contact us you can either reply directly to me or join > >>>us during our regular meetings each Friday at 15:00 UTC on > >>>#fedora-meeting. > >>> > >>>I strongly suspect next weeks meeting will be canceled due to the US > >>>holiday, but after that we'll be doing weekly meetings again. > >>> > >>>Looking forward to see you there! > >>> > >>>Thanks & regards, Phil > >>> > >>>-- > >>>Philipp Knirsch | Tel.: +49-711-96437-470 > >>>Manager Core Services| Fax.: +49-711-96437-111 > >>>Red Hat GmbH | Email: Phil Knirsch > >>>Wankelstrasse 5 | Web: http://www.redhat.com/ > >>>D-70563 Stuttgart, Germany > >>>-- > >>>devel mailing list > >>>devel@lists.fedoraproject.org > >>>https://admin.fedoraproject.org/mailman/listinfo/devel > >>>Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > >> > >>Michal > >> > > > > > > > -- > Philipp Knirsch | Tel.: +49-711-96437-470 > Manager Core Services| Fax.: +49-711-96437-111 > Red Hat GmbH | Email: Phil Knirsch > Wankelstrasse 5 | Web: http://www.redhat.com/ > D-70563 Stuttgart, Germany > -- > 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: [ACTION REQUIRED][FINAL NOTICE] Retiring packages for Fedora 21 v4
On Tue, Jul 01, 2014 at 07:55:42PM +0200, Till Maas wrote: > netatalk orphan, fkocina I'd like take this one. Michal -- 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: [Base] The Base Design WG is looking for a new committee member!
On Fri, Jun 27, 2014 at 06:13:01PM +0200, Phil Knirsch wrote: > Hi everyone. Hello everyone, > > As Bill Nottingham has decided to resign from the committee we now > have a free seat that we'd like to fill with another person. > > In order to fill this seat i'm therefore reaching out here to Fedora > development to offer allow any applicant from the community to get > in touch with us and let us know you're interested, why you're > interested, why you think you'd be a good fit and maybe even the > things you'd like to drive or accomplish in the Base Design WG. I am interested in becoming a member of Base Design WG. I'd like help with accomplishing goals of Base WG and make sure that we provide minimal but solid foundation for others to build upon. I believe my previous experience makes me a good fit for this position : * Red Hat employee since 2011, now member of "Plumbers" group * maintainer and contributor to various networking related projects * systemd maintainer in RHEL I'd like to help with integration of upstream changes in key components to the distribution and making sure they are not disruptive. Another area where I'd like to contribute are container use cases of Fedora Base. Ensuring we provide minimal, but easily extensible platform for sand-boxed/containerized apps. > > For more background on what the Base WG does, here our Fedora wiki: > > https://fedoraproject.org/wiki/Base > > In order to contact us you can either reply directly to me or join > us during our regular meetings each Friday at 15:00 UTC on > #fedora-meeting. > > I strongly suspect next weeks meeting will be canceled due to the US > holiday, but after that we'll be doing weekly meetings again. > > Looking forward to see you there! > > Thanks & regards, Phil > > -- > Philipp Knirsch | Tel.: +49-711-96437-470 > Manager Core Services| Fax.: +49-711-96437-111 > Red Hat GmbH | Email: Phil Knirsch > Wankelstrasse 5 | Web: http://www.redhat.com/ > D-70563 Stuttgart, Germany > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[HEADS-UP] Removing ospfapi and client from quagga
Heya, Because of the recent events, we've decided to disable ospfapi and ospfclient in quagga. It has been decided to disable those features in all supported Fedora releases. I am not aware of any consumers of APIs in question within Fedora. However some 3rd-party software might be affected. Please note that for the time being, if you decide to recompile srpm and continue to use those features you are potentially vulnerable. Please speak up if you are package maintainer and your package depends on those APIs. Hopefully nobody cares for those awkward "features", if that is the case I plan to submit builds on 2013-07-25 and release updates accordingly. Thanks, Michal Sekletar References: [1] https://bugzilla.redhat.com/show_bug.cgi?id=981126 [2] https://bugzilla.redhat.com/show_bug.cgi?id=984532 [3] http://lists.quagga.net/pipermail/quagga-dev/2013-July/010651.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Hi, On Mar 19, 2013, at 13:54, Reindl Harald wrote: > > > Am 19.03.2013 13:42, schrieb Michal Sekletar: >> On Mon, 2013-03-18 at 11:27 -0500, Rex Dieter wrote: >>> Reindl Harald wrote: >>> >>>> Am 16.03.2013 19:26, schrieb Rex Dieter: >>>>> Lukáš Nykrýn wrote: >>>>> >>>>>> After usr move packages should not install files to /sbin. >>>>> >>>>> That's not necessarily true. Do our packaging guidelines actually say >>>>> that anywhere? >>>> >>>> but WHY are they not saying it clearly? >> >> Yes, they are saying it very clearly (see [1]) > > ok, so anything which refers to /bin and /sbin is a bug > after the UsrMove exactly as i felt > > wow, there are lot of bugs over the distribution > I haven't said that. My point was to address the question about guidelines. > http://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout > In addition, Fedora packages MUST NOT place files or directories in the /bin, > /sbin, /lib or /lib64 directories. > Instead, the /usr/bin, /usr/sbin, /usr/lib, and /usr/lib64 directories must > be used. Packages must assume that > /bin, /sbin, /lib, and /lib64 are symbolic links to the /usr/bin, /usr/sbin, > /usr/lib, and /usr/lib64 directories, > respectively > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
Hi Rex, On Tue, 2013-03-19 at 07:57 -0500, Rex Dieter wrote: > Michal Sekletar wrote: > > > On Mon, 2013-03-18 at 11:27 -0500, Rex Dieter wrote: > >> Reindl Harald wrote: > >> > >> > Am 16.03.2013 19:26, schrieb Rex Dieter: > >> >> Lukáš Nykrýn wrote: > >> >> > >> >>> After usr move packages should not install files to /sbin. > >> >> > >> >> That's not necessarily true. Do our packaging guidelines actually say > >> >> that anywhere? > >> > > >> > but WHY are they not saying it clearly? > >> > > > > Yes, they are saying it very clearly (see [1]). > > Sigh, indeed. > > "In addition, Fedora packages MUST NOT place files or directories in the > /bin, /sbin, /lib or /lib64 directories. Instead, the /usr/bin, /usr/sbin, > /usr/lib, and /usr/lib64 directories must be used. Packages must assume that > /bin, /sbin, /lib, and /lib64 are symbolic links to the /usr/bin, /usr/sbin, > /usr/lib, and /usr/lib64 directories, respectively." > > IMHO, this needs amending to say: > In addition, *new* Fedora packages MUST NOT ... I would argue that this is not what should be done. Packagers should fix their packages instead of relying on the old behavior which in now basically compat only thing. Although, I don't believe it is going to happen any time soon. It is very clear to me, that there is so much opposition against UsrMove and unwillingness to fix packages. Since former is not going to happen, I would say that change as you have proposed might make sense. > > and add language to recommend taking special considering modifications of > existing packages, especially those that other packages depend upon. > > -- rex > Cheers, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Packages requires /sbin/service.
On Mon, 2013-03-18 at 11:27 -0500, Rex Dieter wrote: > Reindl Harald wrote: > > > Am 16.03.2013 19:26, schrieb Rex Dieter: > >> Lukáš Nykrýn wrote: > >> > >>> After usr move packages should not install files to /sbin. > >> > >> That's not necessarily true. Do our packaging guidelines actually say > >> that anywhere? > > > > but WHY are they not saying it clearly? > Yes, they are saying it very clearly (see [1]). > Because blindly doing it breaks stuff (as evidenced by this thread). I believe it is not blinded to follows packaging guidelines. > > I was asking a mostly rhetorical question. There's some good reasons the > guidelines don't say it (yet). :) Same as above. > > -- rex > > Michal [1] http://fedoraproject.org/wiki/Packaging:Guidelines#Filesystem_Layout -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
