Re: my EPEL-6 packages up for takers
Hello... On Sat, 2010-05-01 at 16:51 +0200, Patrice Dumas wrote: > Hello, > > I won't, at least for now, maintain the packages I maintain in EPEL-5 in > EPEL-6. I have added a nobranch file in all of them. If you want to take up > the package, you can. It is still unclear to me how to practically ensure > that you become the EPEL-6 branch owner, instead of me, though. Hopefully > this will be sorted out. > I'll try to take as many as I can. It happens that I will have lots of free time over the next month or so. Most of the hard part has already been done, so it should not be too hard except where is noted below. I'm already testing EPEL builds on RHEL6 internally. I'll sync with you off list tomorrow or Monday if that is OK with you Patrice. > If you want to maintain the EL-5 (or even EL-4) branch too, don't > hesitate, the less package I maintain the better I am. > maybe. > I think that wdm should not be maintained in EL-6 anyway, since upstream > is dead and there is no ConsoleKit integration. > > For the dap-* packages it maybe worth waiting for a stabilisation of > the ABI, and maybe integration with bes and packaging of olfs to have a > working hyrax server before branching. My guess is that there are no > users of these packages anyway. Also maybe the opendap implementantion > in netcdf itself could be used instead of libdap/libnc-dap. > > The list is: > acpitool > asa > bibexport > BibTool > bitmap > boolstuff > cernlib > cernlib-g77 > cppunit > dap-freeform_handler > dap-hdf4_handler > dap-netcdf_handler > dap-server > docbook2X > elektra > esmtp > flasm > g2clib > gnochm > gpicview > grads > halevt > html2ps > kchmviewer > libdap > libdockapp > libesmtp > libnc-dap > libsx > ooo2txt > pam_ssh > perl-Algorithm-CurveFit > perl-Cache > perl-Feed-Find > perl-File-BaseDir > perl-File-DesktopEntry > perl-File-MimeInfo > perl-File-NFSLock > perl-Heap > perl-HTML-FormatText-WithLinks > perl-LWP-Authen-Wsse > perl-Math-MatrixReal > perl-Math-Symbolic > perl-Module-Signature > perl-Parse-Yapp > perl-Statistics-Descriptive > perl-Test-Distribution > perl-Text-CHM > perl-Text-Unidecode > pmount > ps2eps > python-chm > tetex-elsevier > tetex-tex4ht > uread > wdm > wmacpi > wmix > xbae > xchm > xdialog > > -- Christopher McCrory "The guy that keeps the servers running" chris...@pricegrabber.com http://www.pricegrabber.com Let's face it, there's no Hollow Earth, no robots, and no 'mute rays.' And even if there were, waxed paper is no defense. I tried it. Only tinfoil works. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Hadoop javadoc problem (FTBFS)
Regarding https://bugzilla.redhat.com/show_bug.cgi?id=1239555 Hadoop seems to have a problem due to javadocs. It seems to be affecting rawhide, and maybe earlier versions, but I haven't verified. Aside from patching the upstream javadoc bug, is there a way to get the build to proceed in a way that's more tolerant to javadoc problems? It's currently blocking my package. (https://bugzilla.redhat.com/show_bug.cgi?id=1239361) There also seems to be some jersey dependency issue in F22... maybe that was fixed in rawhide, but still broken in F22? Does anybody know what changed recently regarding jersey, so I can fix my stuff? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- 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: dnf doesn't check for rpmdb lock?
On Thu, Jul 16, 2015 at 1:42 PM, Przemek Klosowski wrote: > On 07/16/2015 01:19 PM, Eric Griffith wrote: > > I tried to do an install and an update on two different terminals on my > machine yesterday. The second one didn't yell about an rpmdb lock but it did > say that it was waiting on a process. So unless it broke from an update last > night / this morning then idk > > On Jul 16, 2015 11:20 AM, "Richard Shaw" wrote: >> >> I remember frequently (to my dismay) getting messages from yum saying that >> another process had a lock on the RPM database. >> >> Due to a recent rash of issues with the akmods package I have been >> investigating why the kmods are not getting installed. >> >> Out of curiosity I tried running two dnf update instances in two different >> terminals and I did not get the message, in fact it acted like nothing was >> wrong! >> > > > So I just did 'dnf update' from two different terminals on the same system > and allowed the first one to proceed. While it was updating, I kept running > 'dnf update' in the other terminal, terminating it by not giving it an OK to > proceed. > > The second 'dnf update' was running, reporting decreasing number of > upgrades needed, as expected. I don't know what would happen if I allowed > the second one to proceed---would they mess up the package database? would > two upgrades collide writing to the same packaged files? > I believe I tried this (accidentally) the other day, and the second one just quit with an error message about another process. In yum, it would keep retrying, but dnf just seems to give up on the first collision. -- 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: Packaging with hidden strings
On Thu, Jul 30, 2015 at 8:49 PM, Kevin Kofler wrote: > Jiří Konečný wrote: >> I have a theoretical question. Is it possible to a create package to >> Fedora which is using oauth2 authentication and that means there are >> app_id and secret_code strings generated by api provider? These strings >> are used in the program but can't be shipped in the code because >> everyone could then use these codes to look as this application. > > Unfortunately, the concept of an application key is fundamentally > incompatible with Free Software. Several Free Software projects just ship > the app key(s) they use in their source code, and usually get away with it. > I guess that for some popular APIs, there are even projects just using some > other Free Software project's app key, but that's of course bad form. > > Kevin Kofler > I didn't read the question as being about app keys. It sounds to me more like the question was about how to package an app which could be easily configured with a user's private authentication credentials. For instance, a client-app for an internet service that requires authentication. Did I misread the original question? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- 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: Rawhide plans
On Thu, Aug 20, 2015 at 10:19 AM, Ralf Corsepius wrote: > On 08/20/2015 03:13 PM, Eric Griffith wrote: >> >> If you have a bad experience that experience stays >> with you. Maybe you can get over it, maybe you can't. But a name does >> have history. > > > I guess, you guys are not aware that other names related to RH/CentOS/Fedora > also have "ambivalent" and "polarizing" connotations? > > Actually, I believe "rawhide" is the least one to worry about, because it > doesn't have any connotation to many people, because most users don't even > know what rawhide is. I agree with this. Often when I hear people make disparaging remarks about Fedora, using terms like "unstable", or "bleeding-edge", or "unreliable", and I ask them to elaborate, they almost always end up describing "rawhide", but use the name "Fedora". They don't know what "rawhide" is, but any negative connotations they've acquired, they've attributed to "Fedora", not to "rawhide". Granted, this is due to misunderstanding, but it leads me to agree that the name "rawhide" isn't important. -- 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: Proposal to reduce anti-bundling requirements
Wouldn't the provides line needs a full path, otherwise, it could conflict? I'm generally against this proposal. One of the reasons I like using a distribution like Fedora is for dependency convergence. And I prefer exceptions to be rare and carefully deliberated. That said, where I think this could really help as a blanket policy change is when it applies to bundled resources for web apps, like JavaScript libraries. Those are often very hard to split out from the upstream build, the web apps tend to rely on specific versions unique to that app, and linking to a system-provided version tends to require drastic changes to upstream code to change its resource-loading mechanisms. [Apologies for top posting; on mobile] On Thu, Sep 10, 2015, 09:53 Stephen Gallagher wrote: > I assume that subject line got your attention. > > I know this is a long-standing debate and that this thread is likely > to turn into an incomprehensible flamewar filled with the same tired > arguments, but I'm going to make a proposal and then attempt to > respond to many of those known arguments up-front (in the hopes that > we can try to keep the conversation on-track). Please keep the > conversation on devel@lists.fedoraproject.org . I CCed packaging@ to > make them aware of this discussion. > > > > Right now, we have a policy that essentially forbids source code from > being bundled into a package. In technical terms, this means > essentially that the packaging policies mandate that any code that > appears more than once in the repository must be turned into a shared > library and dynamically linked into any package that requires it. Any > package that wants an exception to this must petition the Fedora > Packaging Committee and get an explicit exemption from this policy. > This process is heavyweight and sometimes inconsistent in how the > decision is made. > > I would like to propose that the no-bundled-libraries policy be > amended as follows: "Any package that has an existing mechanism to > link against a shared system library and functions correctly when > doing so must link against that library and not bundle it internally. > Any package whose upstream releases cannot link against a shared > system library (or are incompatible with the version in Fedora) may > bundle that library (without requiring a special exemption) but MUST > add Provides: bundled() = in the spec file for each > known bundled library.(This will allow us to track down the bundling > when we need to). Package maintainers should continue attempt to > engage upstream to support linking against shared system libraries > wherever possible, due to the advantages it provides the package > maintainer." > > > > The reason for this proposal is relatively simple: we know the > advantages to unbundling, particularly with security and resource- > usage. However, the world's developer community largely *does not > care*. We fought the good fight, we tried to bring people around to > seeing our reasoning and we failed. > > > The point of software is to provide a service to an end-user. Users > don't run software because it has good packaging policies, they run > software because it meets a need that they have. If they can't get > that software from Fedora, they *will* get it from another source (or > use a different OS that doesn't get in their way). I'll take a moment > to remind people that two of Fedora's Four Foundations are "Features" > and "First". We want Fedora to be the most feature-complete > distribution available and we want to get there before anyone else > does. I would say that holding to our no-bundling policy actively > defeats our efforts on that score. > > > > Let me describe some of the advantages to bundling and to unbundling > (as noted so we can hopefully skip some of the hotter parts of the > flamewar). As I noted above, anything that is capable of unbundling > should remain unbundled for its advantages. But things that are not > currently capable (or can't be due to forwards/backwards compatibility > issues, etc.) really shouldn't be forced to attempt it. > > > == Advantages to using shared libraries == > * Security/Bugs - When a bug or security vulnerability is located in > a library, it needs to be patched in only a single package in order to > fix all applications using that library. > * Resources - A shared library only needs to be loaded into memory > once, reducing the memory requirements of the system. > > == Advantages to bundling == > * Guarantees that the application is running with the same set of > code that upstream tested. (Fewer Fedora-specific bugs means less > burden on the maintainer) > * Simplifies packaging of updates. (Fedora maintainer does not need > to keep tabs on unbundling patches to keep in sync for new versions) > * Increases the available pool of software that can be packaged > substantially (many modern languages such as Ruby and Go are > realistically only functional with allowable bundling) > * Did I men
Re: Removing packages that have broken dependencies in F23 tree
I don't really understand what's going on with the netbeans-platform package, or why accumulo would be affected. Upstream accumulo doesn't have any dependencies on netbeans. Before I try to dive in and figure out what's breaking, does anybody have any insight into what's going on with this, and what it's providing that is breaking so many java packages? On Thu, Sep 24, 2015 at 10:37 AM Kalev Lember wrote: > Hi all, > > In less than three weeks we will be entering the F23 Final Freeze. At > that point, Fedora release engineering retires any packages that still > have broken dependencies in the F23 tree. > > Based on today's Branched report [1], we still have a number of unfixed > packages with broken dependencies (package maintainers BCC'd to this > email). Anything not fixed by 2015-10-12 from the list below is going to > be automatically retired: > >Package (co)maintainers > > apache-scoutgoldmann > aws landgraf > hawaii-shelllkundrak, plfiorini > hbase rrati, coolsvap, moceap > licqcicku, fcami, tieugene, yaneti > mariadb-galera rohara, hhorak > moon-buggy robert > netbeans-platform omajid, dbhole > nodejs-grunt-contrib-copy ralph > nodejs-grunt-saucelabs ralph, piotrp > nodejs-proxy-agent ralph, piotrp > oat gwei3 > oozie rrati, coolsvap, moceap > openstack-heat-gbp rkukura > openstack-neutron-gbp rkukura > openstack-swift zaitcev, apevec, derekh, hguemar, itamarjp, > jsteffan, ke4qqq, mmagr, russellb > perl-B-Hooks-OP-Check-EntersubForCV psabata, iarnell, perl-sig > perl-Data-Alias pghmcfc, iarnell, perl-sig, psabata > perl-Data-Dump-Streamer psabata, iarnell, perl-sig > perl-Devel-BeginLiftpsabata, iarnell, perl-sig > perl-Devel-FindRef orphan, perl-sig > perl-Method-Signatures psabata, iarnell, perl-sig > perl-POE-API-Peek psabata, jplesnik, mmaslano, perl-sig, ppisar > polymakejjames, rmattes > puresalimma, cicku > pyjigdo kanarip, jsteffan > python-Fionachurchyard, group::python-sig > python-django-horizon-gbp rkukura > python-fiat fab > python-gbpclientrkukura > rakudo-star gerd > spark willb > tritonuslimb, bsjones > vdr-livemartinkg > vfrnav sailer > > I've excluded dpm-contrib-admintools, gnatcoll, publican, pvs-sbcl, > trustedqsl from the list above; they all have pending fixes and just > need to go through updates-testing in Bodhi to go to stable. > > > Impacted dependant packages that would get retired together with the > packages above: > > Depending on: apache-scout (2) > wildfly (maintained by: goldmann) > wildfly-8.1.0-3.fc22.src requires apache-scout = > 1.2.6-11.fc21 > > eclipse-jbosstools (maintained by: galileo, goldmann, > group::eclipse-sig) > eclipse-jbosstools-4.2.2-1.fc22.src requires wildfly = > 8.1.0-3.fc22 > eclipse-jbosstools-as-4.2.2-1.fc22.noarch requires wildfly > = 8.1.0-3.fc22 > > > Depending on: hbase (2) > pig (maintained by: pmackinn, coolsvap, java-sig, moceap) > pig-0.13.0-1.fc21.noarch requires hbase = 0.98.3-4.fc22 > pig-0.13.0-1.fc21.src requires hbase = 0.98.3-4.fc22 > > hive (maintained by: pmackinn, coolsvap, java-sig, moceap) > hive-0.12.0-5.fc22.src requires pig = 0.13.0-1.fc21 > > > Depending on: netbeans-platform (33) > sqljet (maintained by: olea, filiperosset) > sqljet-1.1.10-4.fc23.src requires netbeans-platform = > 1:7.0.1-11.fc22 > sqljet-browser-1.1.10-4.fc23.noarch requires > netbeans-platform = 1:7.0.1-11.fc22 > > OmegaT (maintained by: olea, mtasaka) > OmegaT-2.6.3-2.fc22.i686 requires sqljet = 1.1.10-4.fc23 > OmegaT-2.6.3-2.fc22.src requires sqljet = 1.1.10-4.fc23 > > svnkit (maintained by: olea, akurtakov, dbhole, jfilak) > svnkit-1.8.5-3.fc23.noarch requires sqljet = 1.1.10-4.fc23 > svnkit-1.8.5-3.fc23.src requires sqljet = 1.1.10-4.fc23 > > mimepull (maintained by: goldmann, gil) > mimepull-1.9.5-2.fc23.src requires > mvn(org.tmatesoft.svnkit:svnkit) = 1.8.5 > > netbeans-svnclientadapter (maintained by: omajid) > netbeans-svnclientadapter-7.3.1-0.4.1.8.22.fc23.src > requires svnkit = 1.8.5-3.fc23, svnkit-javahl = 1.8.5-3.fc23 > > glassfish-jaxws (maintained by: gil, java-sig) > glassfish-jaxws-2.2.10-2.fc23.noarch requires > mvn(org.jvnet.mimepull:mimepull) = 1.9.5 > glassfish-jaxws-2.2.10-2.fc23.src requires > mvn(org.jvnet.mimepull:mimepull) = 1.9.5 > > glassfish-saaj (maintaine
FESCo #1263 question (optional javadocs)
Regarding https://fedorahosted.org/fesco/ticket/1263 Does this policy change affect updates to older releases still receiving updates? Or only F21 and later? -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- 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: FESCo #1263 question (optional javadocs)
As a hypothetical, I was mainly concerned about backporting a new F21 java
package as a F20 update to make it available to users still on that
version, and whether that would require javadocs. Just in case, I've added
a "%if 0%{fedora} < 21" condition for javadocs, and the appropriate
Obsoletes line when the condition fails (>=20), but that's more to maintain
in the specfile, and it'd be much simpler to just not declare any
subpackaging for javadocs.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Aug 20, 2014 at 8:29 AM, Miloslav Trmač wrote:
> Hello,
>
> Regarding https://fedorahosted.org/fesco/ticket/1263
>
> Does this policy change affect updates to older releases still receiving
> updates? Or only F21 and later?
>
> It has been approved as a F21 Change, so it should affect only F≥21.
> Technically, the packaging guideline change is somewhat independent from
> the Change process; I’d argue that updates to existing F≤20 packages should
> not remove functionality, though.
> Mirek
>
> --
> 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: Future changes in the new package and new branch processes
On Mon, Sep 8, 2014 at 5:31 AM, Tomas Tomecek wrote: > Quoting Pierre-Yves Chibon (2014-09-05 17:08:39) > > New procedure > > = > > > > * packager opens a review-request on bugzilla > > * reviewer sets the fedora-review flag to ? > > * reviewer does the review > > * reviewer sets the fedora-review flag to + > > * packager goes to pkgdb2 to request new package and specifies: > >- package name > >- package summary > > How about taking this from specfile? (and therefore provide a tool for > maintaining specfiles & srpms for reviews) > > It'd be great if the fedpkg tool could do some of this. For example, fedpkg could create git repos locally, from a template and a few questions, for new packages, which could be pushed somewhere for review (usually GitHub, I'd imagine). It could even create the review bug automatically, as well as assist in the review process for the reviewer (setting the correct flags). Once approved and the package is created in pkgdb, git could be adjusted automatically from a clone of this original repo created by the fedpkg tool. This puts some burden on the reviewer to review not only the package, but also the use of the packaging process: ensure that the user created the git repo correctly. But, that might not be a bad thing. I was struck by how "manual" the new package process was, and how "automated" everything is later. It's a big gap that could be closed with more tools on the "prepare for review" side of things. > >- package branches > >- link to review on bugzilla > > => requests added to the scm admin queue > > * cvsadmin checks the review (check reviewer is a packager¹) > > * cvsadmin approves the creation of the package in pkgdb > > => package creation broadcasted on fedmsg > > * git adjusted automatically > > Tomas > Overall, I like the proposal, but I think it could be made simpler on new packagers (and reviewers) with better tooling (which I suppose could be considered out of scope for this proposal, but something to consider in future). -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- 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: 'Branch freeze policy' and 'Change deadline' naming change proposal
On Wed, Sep 24, 2014 at 3:41 PM, Adam Williamson wrote: > Hi, folks! > > I'm currently like two months behind on devel@ - apologies if I've > missed anything relevant. > > A discussion in #anaconda this morning made it clear that folks have > trouble following our full release cycle, and particularly the various > kinds of 'freeze' that exist. > > So, there is a page named "Branch freeze policy": > > https://fedoraproject.org/wiki/Branch_Freeze_Policy > > which is marked as deprecated, and hasn't been linked to in the wiki > Releases/XX/Schedule pages since F18. However, I can't for the life of > me see any way in which it is in fact inaccurate, and it doesn't seem to > have been replaced with anything. So far as I can see it still > accurately describes the process we follow. > > AFAICS, the "Branch freeze" kicks in at the point we enable Bodhi on the > Branched tree, which is usually a couple of weeks after forking it from > Rawhide. For instance, on the F21 schedule - > https://fedoraproject.org/wiki/Releases/21/Schedule - "Branch Fedora 21 > from Rawhide" is listed on 2014-07-08. The first 'Fedora 21 > updates-testing' email I have is dated 2014-08-28, so I'd say the > schedule should have had an extra row, "Branch Freeze", dated > 2014-08-28. (The period between branching and enabling Bodhi was > unusually long for F21). > > The name "Branch freeze" seems unfortunate to me, however, as it's not > really a freeze, it's more of a light cooling. I'd suggest we remove the > 'deprecation' notice, update any details on the page which are no longer > correct if anyone can see any, and rename it. Ideas: > > That page only describes policy, it doesn't really connect policy to actions one could take, or offer any explanation about what is actually "frozen", and is very confusing. What can a package owner do in git? What shouldn't they do? What about in Bodhi? (For instance, I have a trivial update to a package sitting in F21 updates-testing, because I'm not sure if moving it to stable would violate the freeze policy, but perhaps the git commit it was built from was already an accidental violation of the freeze policy?) > > Branch stabilization > Branch update policy enforcement > > anyone got anything better? > > So, the second part of the process which is apparently causing trouble > is the "Change Deadlines". These, again, seem to be something of a > misnomer, because the Change Deadlines are the *actual* freezes. The > problem is exacerbated by the renaming of 'Features' to 'Changes'. If > you look again at the F21 schedule you'll see that it lists "Change > Proposals Submission Deadline", "Changes Freeze", some "milestone Change > Deadlines", and "Accepted Changes 100% Complete" - but those items are > referring to two entirely *different* things when they use the word > "Change". This is clearly unfortunate. > > Again, I'd recommend a renaming here. If we call the "Branch freeze" > something else then we can simply call those points the "Alpha Freeze", > "Beta Freeze" and "Final Freeze", which are the terms used informally in > any case, and would line up with the "freeze exception policy" which > determines what stuff can break those freezes. > > Along with the renaming I'd like to work over the documentation a bit so > all the relevant pages link up and sing from the same hymn sheet, but I > can actually do that right now, orthogonal to the renaming, without > really needing any review, so I'll just go do it. (I'll post a reply > explaining what I did in a bit). > > Thanks folks! > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net > http://www.happyassassin.net > > -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- 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: Changing release time (was Re: Major wiki revisions:)
On Fri, Sep 26, 2014 at 12:39 PM, Adam Williamson < adamw...@fedoraproject.org> wrote: > On Fri, 2014-09-26 at 12:37 -0400, Jaroslav Reznik wrote: > > > And as we're already changing bits during release I'd like to change > release > > time to use UTC instead of ET. We talked a lot about it but actually - > never > > committed to it. To make the life easier for US folks, 15:00 UTC (we have > > 14:00 and 15:UTC mapped to 10 AM ET) should be the time. Talking to > Robyduck > > trying to figure out time difference each time is sometimes flustrating, > > specially as the summer time changes are out of sync. And previously we > had > > Robyn in the gang with another different timezone without summer time :). > > I wouldn't mind, the only issue is that it means the time would be > different with and without summer time (in timezones that have it, > obviously). At least then everyone can use date -u ... > That's already the case for people in countries whose daylight savings transitions aren't aligned with those for EST/EDT in the US. I don't think too many people would be upset if they have to wait until 11AM to download a release when 6 months prior they could get it at 10AM, especially since deadline changes (when they unfortunately, but inevitably occur) tend to happen on the order of weeks, and mirroring isn't a sub-1hr. activity either (or downloading, for many people, for that matter). UTC is much less confusing, and I'm a big fan. +1 15:00 UTC seems reasonable, but I have no preference. -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- 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: Orphaned Packages in rawhide (2015-04-20)
On Tue, Apr 21, 2015 at 5:45 AM, Mat Booth wrote: > > On 20 April 2015 at 19:00, wrote: [snip] >>Package (co)maintainers Status Change >> == >> erlang-jsx orphan, erlang-sig, peter6 weeks ago [snip] >> >> The following packages require above mentioned packages: >> Depending on: erlang-jsx (28), status change: 2015-03-04 (6 weeks ago) >> thrift (maintained by: willb) >> erlang-thrift-0.9.1-13.fc22.3.i686 requires erlang-jsx = >> 1.4.2-4.fc22 >> >> accumulo (maintained by: ctubbsii, mizdebsk) >> accumulo-1.6.1-2.fc22.src requires libthrift-java = >> 0.9.1-13.fc22.3 [snip] > > Is anyone from erlang-sig willing to adopt erlang-jsx? > > If not, can it be patched out of thrift maybe by dropping the -erlang > subpackage? +1 for dropping the subpackage. It's not needed by my package (accumulo), anyway, and it seems like the most prudent solution to get things working again. > > Although I am not directly affected as a java-sig person it does concern me > that some random erlang package is affecting so many java packages. I agree. -- 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: erlang-jsx about to be retired (Re: Orphaned Packages in rawhide (2015-04-20))
On Tue, Apr 21, 2015 at 12:04 AM, Will Benton wrote: > Dan, > > I've had some trouble updating Thrift to a newer upstream version but have > been planning to spin an updated release without Erlang support in the > meantime and will ping you when it's ready. Thanks! [snip] FWIW, thrift has had really bad problems with regressions and API stability issues which has affected Accumulo (and Cassandra, and I'm sure others, too) in the past, so I'd be really wary about moving accumulo to use 0.9.2 until there's upstream support for it. (The switch from thrift 0.9.0 to 0.9.1 was *very* painful, as was the initial switch to 0.9.0..., causing massive reimplementation of thrift-provided libraries to be embedded in downstream projects[1][2][3]). Would you consider keeping thrift 0.9.1 available for longer (dropping erlang, as necessary, of course), rather than switch to a newer upstream version? What degree of confidence do you have that 0.9.2 (the current upstream version) doesn't break thrift 0.9.1-based projects? [1]: http://bit.ly/1IBSsrW [2]: https://issues.apache.org/jira/browse/ACCUMULO-1691 [3]: https://issues.apache.org/jira/browse/ACCUMULO-2950 -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Apr 21, 2015 at 12:04 AM, Will Benton wrote: > Dan, > > I've had some trouble updating Thrift to a newer upstream version but have > been planning to spin an updated release without Erlang support in the > meantime and will ping you when it's ready. Thanks! > > > best, > wb > > - Original Message - >> From: "Dan Callaghan" >> To: "devel" >> Cc: "Will Benton" >> Sent: Monday, April 20, 2015 7:18:01 PM >> Subject: erlang-jsx about to be retired (Re: Orphaned Packages in rawhide >> (2015-04-20)) >> >> Dear Erlang folks, >> >> (I'm not subscribed to the list so please cc me in replies.) >> >> I maintain python-txamqp which has a transitive dependency on erlang-jsx >> via thrift. The erlang-jsx package was orphaned about 6 weeks ago which >> means it, along with a chain of dependent packages, will be retired >> soon. See the orphaned packages notice quoted below. >> >> Could someone interested in Erlang please take erlang-jsx? >> >> Alternatively Will as maintainer of thrift, could you drop the >> erlang-thrift subpackage so that thrift doesn't get retired? >> >> Excerpts from opensource's message of 2015-04-21 04:00 +10:00: >> > The following packages are orphaned and will be retired when they >> > are orphaned for six weeks, unless someone adopts them. If you know for >> > sure >> > that the package should be retired, please do so now with a proper reason: >> > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life >> > >> > Note: If you received this mail directly you (co)maintain one of the >> > affected >> > packages or a package that depends on one. Please adopt the affected >> > package or >> > retire your depending package to avoid broken dependencies, otherwise your >> > package will be retired when the affected package gets retired. >> > >> >Package (co)maintainers Status Change >> > == >> > erlang-jsx orphan, erlang-sig, peter6 weeks ago >> > gnome-schedule orphan, sundaram 4 weeks ago >> > identicurse orphan, smilner 5 weeks ago >> > jackrabbit orphan 6 weeks ago >> > libgtkhotkeyorphan, sundaram 4 weeks ago >> > mercury orphan 6 weeks ago >> > naimorphan, lmacken 4 weeks ago >> > netactview orphan 3 weeks ago >> > obexftp orphan, itamarjp 1 weeks ago >> > perl-File-SearchPathorphan, georgiou, perl-sig 0 weeks ago >> > perl-Term-Clui orphan, georgiou, perl-sig 0 weeks ago >> > porkorphan, lmacken 4 weeks ago >> > python-sockjs-tornado orphan, gholms 4 weeks ago >> > python-sqlalchemy0.5orphan 2 weeks ago >> > python-sqlamp orphan 2 weeks ago >> > python-xkit orphan, sundaram 4 weeks ago >> > xlhtml orphan, sundaram 4 weeks ago >
Re: Packagers with no corresponding valid bugzilla accounts
Why aren't the packager accounts linked to their FAS account alias? fa...@fedoraproject.org ? I've been annoyed by FAS-linked services trying to use my forwarding address for my account id rather than my FAS user id. My forwarding address is subject to change, but the FAS email alias is static. On Sun, Jun 14, 2020, 15:03 Pierre-Yves Chibon wrote: > On Sun, Jun 14, 2020 at 07:09:57PM +0200, Felix Schwarz wrote: > > > > Am 13.06.20 um 22:10 schrieb Pierre-Yves Chibon: > > > bpereto > > > > Benjamin was a previous maintainer of borgbackup. After the Python 3.9 > rebuild > > I noticed that a new ticket was still assigned to him [1]. If I > understood > > your email correctly this is because there is no corresponding bugzilla > account? > > > > Any idea how to fix this? There was a non-responsive maintainer process a > > while ago and I did not hear from him ever since. > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1838161#c1 > > [2] https://pagure.io/fesco/issue/2242 > > I've just checked the logs of the sync script and that is correct. > Benjamin's > lack of valid bugzilla account lead to a failure in the sync script to > update > borgbackup. > > Since Benjamin is considered MIA, I will remove his account from the > watchers of > borgbackup and that should fix the sync. > > > > @certbot-sig > > > > What can we do here? I'm a member of the sig but I don't know if it has > an > > email address. > > Each group has normally a mailing list associated with them in FAS, this > is the > email that is synced to bugzilla (which is why we recommend the mailing > list be > private as it will be CC'ed to bugzilla reports, including private ones). > So in this case, it looks like no one created the bugzilla account for the > mailing list linked to the group. > > > Pierre > ___ > 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 > ___ 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: Packagers with no corresponding valid bugzilla accounts
On Tue, Jun 16, 2020 at 11:10 AM Pierre-Yves Chibon wrote: > > On Tue, Jun 16, 2020 at 11:05:00AM -0400, Christopher wrote: > >Why aren't the packager accounts linked to their FAS account alias? > >[1]fa...@fedoraproject.org ? I've been annoyed by FAS-linked services > >trying to use my forwarding address for my account id rather than my FAS > >user id. My forwarding address is subject to change, but the FAS email > >alias is static. > > Because they are two different systems and you do not need an account in one > to > have an account in the other? > We do not create account on bugzilla for the alias @fp.o automatically (and I > think it's a good thing). The original post says "If you are a packager... you must have a bugzilla account...". But now, you are saying that they are separate and you do not need one when you have the other. These two statements are in conflict. Either the bugzilla account is required for packagers, in which case my suggestion to use the packager's FAS email alias should suffice (in theory, at least), or it isn't, in which case, your original post that "...packagers...must have a bugzilla account..." is incorrect. You said that the required bugzilla account must be "...associated with the email address you have set in FAS." All I'm suggesting is that this is unnecessary if they are packagers, since all packagers already have a FAS email alias that can be used for this requirement. ___ 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
[EPEL] rpmconf question for EPEL7 on Amazon Linux 2
Hi, I know Fedora doesn't directly support Amazon Linux, but I was wondering if the package maintainer for rpmconf on EPEL was aware that the latest version doesn't work on Amazon Linux 2, which recently updated to python-3.7, whereas rpmconf has a direct dependency on python(abi)=3.6. If it's possible to use '>=3.6' instead, and the package maintainer is willing to update it so it works with python 3.7 on Amazon Linux 2, that would be great for my use case. Regards, Christopher ___ 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: [EPEL] rpmconf question for EPEL7 on Amazon Linux 2
On Wed, Jul 1, 2020 at 4:52 AM Nico Kadel-Garcia wrote: > > On Tue, Jun 30, 2020 at 2:18 PM Christopher > wrote: > > > > Hi, > > > > I know Fedora doesn't directly support Amazon Linux, but I was > > wondering if the package maintainer for rpmconf on EPEL was aware that > > the latest version doesn't work on Amazon Linux 2, which recently > > updated to python-3.7, whereas rpmconf has a direct dependency on > > python(abi)=3.6. If it's possible to use '>=3.6' instead, and the > > package maintainer is willing to update it so it works with python 3.7 > > on Amazon Linux 2, that would be great for my use case. > > You need to talk to Amazon. They have their own EPEL repository, > inconsistently forked from EPEL and enabled with the > "amazon-linux-extras" command, along with a variety of other > not-really-yum-repo-managed tools like mock and ansible. It's > problematic.. And don't let that incomplete EPEL channel get mixed > with the official EPEL repository in your configurations. Yeah, I noticed the same problem for rpmconf in both EPEL lines. Somehow, I don't think this is a problem Amazon is likely to prioritize. I'd probably be better off rebuilding rpmconf from source for my instance (using a modified EPEL SRPM). > > The time spent hunting for workarounds might be better spent migrating > to RHEL or CentOS, which is likely to be more compatible with Fedora > packages backported through EPEL. The decision to leapfrog to python > 3.7 was problematic, since it also puts them ahead of RHEL 8 and > CentOS 8's releases of python 3.6 and complicates EPEL support > profoundly. I would *love* to be using CentOS, but this is for an "Amazon Workspaces" instance, which only supports Amazon Linux 2 or Windows, because of the driver support needed for the PCoIP features inherent to the service. There are tons of other problems with Amazon Linux, too, such as the complete lack of USB support in the kernel... which makes forwarding USB devices over PCoIP (which is a supported feature) a completely useless feature. These problems don't exist in CentOS... but I'm stuck with the shitty Amazon instance I'm forced to use in my environment for now. Thanks for the suggestions. ___ 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: F21 System Wide Change: Java 8
I also would like to see 1.7.0 stick around for awhile. Not necessarily as the default, but at least available in the repos. As it stands, it's difficult to use a modern Fedora on projects that are still developing against JDK 1.6. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Mar 25, 2014 at 4:05 PM, Aleksandar Kurtakov wrote: > Please keep java 1.7.0 around for some time. It would make moving easier if > we have to jump back for a build or two. > > Alexander Kurtakov > Red Hat Eclipse team > > - Original Message - >> From: "Omair Majid" >> To: "Development discussions related to Fedora" >> >> Sent: Tuesday, March 25, 2014 9:07:39 PM >> Subject: Re: F21 System Wide Change: Java 8 >> >> * Mikolaj Izdebski [2014-03-24 11:55]: >> > That's exactly the problem. We need to use a modified version of >> > java-1.8.0-openjdk with extra provides and adjusted priorities for >> > alternatives. >> >> I have started a new java-1.8.0-openjdk build that should fix this: >> http://koji.fedoraproject.org/koji/buildinfo?buildID=506921 >> >> > Blocking java-1.7.0-oepnjdk may also be required. This >> > makes it impossible to scratch-build Java packages using f21-build >> > target in current state. >> >> Is there anything I can/should do here? Shall I file a rel-eng ticket to >> block java-1.7.0-openjdk? Would it be worth waiting a little while to >> ensure that there are no show-stopper bugs in java-1.8.0-openjdk? >> >> Thanks, >> Omair >> >> -- >> PGP Key: 66484681 (http://pgp.mit.edu/) >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >> -- >> 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 -- 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: F21 System Wide Change: Java 8
On Wed, Mar 26, 2014 at 9:31 AM, Deepak Bhole wrote: > * Christopher [2014-03-25 19:59]: >> I also would like to see 1.7.0 stick around for awhile. Not >> necessarily as the default, but at least available in the repos. As it >> stands, it's difficult to use a modern Fedora on projects that are >> still developing against JDK 1.6. >> > > Unfortunately, OpenJDK7 will be EOLd in April 2015[1], which is within > the support time-frame of the F21. This is one the reasons why we would > like to be able to switch over to OpenJDK8 asap for F21. > > 1: http://www.oracle.com/technetwork/java/eol-135779.html I don't see how Oracle tentatively dropping long-term public support for 7 means that Fedora needs can no longer provide OpenJDK7 in its repos (not as default, of course), with or without additional updates, for developers who want to use a modern Fedora, but need to develop for applications/hardware that requires strict 7 compatibility. The alternative is Fedora fans will be forced to use an older version of Fedora, use a different Linux distro, or find some hackish workaround (yum --releasever=20 ...; which is problematic, because every version 8 update will obsolete 7, just like 7 currently does with 6 packages), or download untrusted 3rd party packages. It seems to me that support in Fedora would be pretty easy: just make sure it doesn't cause a packaging conflict and recommend the newer JDK8. Maybe call it -compat? But, I defer to the experts on Fedora packaging/support policies and decisions. I'm just a user, and don't know all the implications for trying to include it. I just think it'd be nice to keep around. > Deepak > >> -- >> Christopher L Tubbs II >> http://gravatar.com/ctubbsii >> >> >> On Tue, Mar 25, 2014 at 4:05 PM, Aleksandar Kurtakov >> wrote: >> > Please keep java 1.7.0 around for some time. It would make moving easier >> > if we have to jump back for a build or two. >> > >> > Alexander Kurtakov >> > Red Hat Eclipse team >> > >> > - Original Message - >> >> From: "Omair Majid" >> >> To: "Development discussions related to Fedora" >> >> >> >> Sent: Tuesday, March 25, 2014 9:07:39 PM >> >> Subject: Re: F21 System Wide Change: Java 8 >> >> >> >> * Mikolaj Izdebski [2014-03-24 11:55]: >> >> > That's exactly the problem. We need to use a modified version of >> >> > java-1.8.0-openjdk with extra provides and adjusted priorities for >> >> > alternatives. >> >> >> >> I have started a new java-1.8.0-openjdk build that should fix this: >> >> http://koji.fedoraproject.org/koji/buildinfo?buildID=506921 >> >> >> >> > Blocking java-1.7.0-oepnjdk may also be required. This >> >> > makes it impossible to scratch-build Java packages using f21-build >> >> > target in current state. >> >> >> >> Is there anything I can/should do here? Shall I file a rel-eng ticket to >> >> block java-1.7.0-openjdk? Would it be worth waiting a little while to >> >> ensure that there are no show-stopper bugs in java-1.8.0-openjdk? >> >> >> >> Thanks, >> >> Omair >> >> >> >> -- >> >> PGP Key: 66484681 (http://pgp.mit.edu/) >> >> Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 >> >> -- >> >> 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 >> -- >> 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 -- 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: F21 System Wide Change: Workstation: Disable firewall
Whoa, the fact that the Firewall is on by default in Fedora (along with SELinux) is one of the reasons I choose Fedora over alternatives. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Apr 15, 2014 at 5:01 AM, Jaroslav Reznik wrote: > = Proposed System Wide Change: Workstation: Disable firewall = > https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall > > Change owner(s): Matthias Clasen > > The firewalld service will not be enabled by default in the workstation > product. > > == Detailed Description == > The current level of integration into the desktop and applications does not > justify enabling the firewalld service by default. Additionally, the set of > zones that we currently expose is excessive and not user-friendly. Therefore, > we will disable the firewall service while we are working on a more user- > friendly way to deal with network-related privacy issues. > > It will of course still be possible to enable the firewall manually. > > == Scope == > * Proposal owners/Other developers: Add a Workstation-specific service > configuration (preset ?) to the firewalld package that disables firewalld for > the Workstation product > * Release engineering: No action required > * Policies and guidelines: No action required > ___ > devel-announce mailing list > devel-annou...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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: F21 System Wide Change: Workstation: Disable firewall
On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski wrote: > On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald wrote: >> >> Am 15.04.2014 16:28, schrieb Christian Schaller: >> >>> There was a long thread about this on the desktop mailing list, and I was >>> not in the 'disable the firewall' camp in that discussion, but nobody in >>> that thread or here have articulated how the firewall exactly enhance >>> security >>> in the situation where we at the same time need to allow each user to have >>> any >>> port they desire opened for traffic to make sure things like DLNA or >>> Chromecast >>> works. >> >> that is pretty easy - defaults have to be closed anything and the user >> have to make a choice for, otherwise if there are cirtical security >> updates after a release you have *exactly* the same as WinXP SP2 > > WinXP SP2 needed a firewall because MS didn't want to close ports 139 > and 445 for real. So instead they hacked it up with a firewall. This > meant that, if you had the firewall blocking those ports, you were > okay, but if they were open (e.g. because you were at home), you were > screwed. > > This is *not* a good thing. > > Can someone explain what threat is effectively mitigated by a firewall > on a workstation machine? Here are some bad answers: > > - Being pwned via MS's notoriously insecure SMB stack? Not actually > a problem for Fedora. > > - WebRTC, VOIP, etc. issues? These use NAT traversal techniques that > are specifically designed to prevent your firewall from operating as > intended. > > - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible > for these things to be off until specifically requested? Who actually > uses a so-called "zone" UI correctly to configure them? How about > having an API where things like DLNA can simply not run until you're > connected to your home network? > > Also, having a firewall on exposes you to a huge attack surface in > iptables, and it doesn't protect against attacks targeting the > kernel's IP stack. > > I'm all for "secure by default", but I'm not at all convinced that > current desktop firewalls add any real security. Ideally, users would have complete knowledge of the behavior of every piece of software in their system that utilizes the network, in which case, they could very easily get by without a firewall. However, that is not a reasonable expectation. A firewall protects users with incomplete knowledge of their software. Example: user installs software X... but oops, they didn't realize it was going to listen on port Y but that's okay, because no firewall rule has been enabled to allow traffic on port Y, so the user is secure. Even worse: user installs software X, but which has no network features so the user feels safe, but oops, it depends on system service Y, which does open network ports, was previously disabled, but is now turned on by software X. Firewalls protect against this sort of incomplete user knowledge. What if software Y only enables the network periodically, to perform some maintenance function? Even a pedantic user checking netstat isn't necessarily going to notice network services listening on ports periodically. Then, of course, there's separation of responsibilities. A network admin at a company might care about firewall configuration, but permits actual workstation user might just run/install whatever software they like. I'm a bit surprised that a case must be made to demonstrate that firewalls provide real security, in 2014, but hopefully these examples provide some demonstration that they do add real security. (Note, I realize that in each of these cases, a firewall could be turned on after the fact. These examples are to show the value of firewalls, which is being questioned, not the value of having them turned on by default. That's a different argument.) > > --Andy > -- > 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: F21 System Wide Change: Workstation: Disable firewall
I think you and I disagree that "b" is broken. In my mind "b" (listening w/firewall closed) is precisely what the firewall is designed to do... act as a failsafe in the event of an unexpected application listening when a user doesn't really know or want it to. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, Apr 15, 2014 at 12:13 PM, Andrew Lutomirski wrote: > On Tue, Apr 15, 2014 at 9:04 AM, Christopher wrote: >> On Tue, Apr 15, 2014 at 11:40 AM, Andrew Lutomirski wrote: >>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald >>> wrote: >>>> >>>> Am 15.04.2014 16:28, schrieb Christian Schaller: >>>> >>>>> There was a long thread about this on the desktop mailing list, and I was >>>>> not in the 'disable the firewall' camp in that discussion, but nobody in >>>>> that thread or here have articulated how the firewall exactly enhance >>>>> security >>>>> in the situation where we at the same time need to allow each user to >>>>> have any >>>>> port they desire opened for traffic to make sure things like DLNA or >>>>> Chromecast >>>>> works. >>>> >>>> that is pretty easy - defaults have to be closed anything and the user >>>> have to make a choice for, otherwise if there are cirtical security >>>> updates after a release you have *exactly* the same as WinXP SP2 >>> >>> WinXP SP2 needed a firewall because MS didn't want to close ports 139 >>> and 445 for real. So instead they hacked it up with a firewall. This >>> meant that, if you had the firewall blocking those ports, you were >>> okay, but if they were open (e.g. because you were at home), you were >>> screwed. >>> >>> This is *not* a good thing. >>> >>> Can someone explain what threat is effectively mitigated by a firewall >>> on a workstation machine? Here are some bad answers: >>> >>> - Being pwned via MS's notoriously insecure SMB stack? Not actually >>> a problem for Fedora. >>> >>> - WebRTC, VOIP, etc. issues? These use NAT traversal techniques that >>> are specifically designed to prevent your firewall from operating as >>> intended. >>> >>> - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible >>> for these things to be off until specifically requested? Who actually >>> uses a so-called "zone" UI correctly to configure them? How about >>> having an API where things like DLNA can simply not run until you're >>> connected to your home network? >>> >>> Also, having a firewall on exposes you to a huge attack surface in >>> iptables, and it doesn't protect against attacks targeting the >>> kernel's IP stack. >>> >>> I'm all for "secure by default", but I'm not at all convinced that >>> current desktop firewalls add any real security. >> >> Ideally, users would have complete knowledge of the behavior of every >> piece of software in their system that utilizes the network, in which >> case, they could very easily get by without a firewall. However, that >> is not a reasonable expectation. A firewall protects users with >> incomplete knowledge of their software. >> >> Example: user installs software X... but oops, they didn't realize it >> was going to listen on port Y but that's okay, because no firewall >> rule has been enabled to allow traffic on port Y, so the user is >> secure. >> > > This sounds like a problem that should be separately fixed. Even in > the current state of affairs, either software X doesn't support > firewalld, in which case we have the problem that caused this change > request in the first place, or it does support firewalld, in which > case it's unlikely that there will be a benefit. > >> Even worse: user installs software X, but which has no network >> features so the user feels safe, but oops, it depends on system >> service Y, which does open network ports, was previously disabled, but >> is now turned on by software X. Firewalls protect against this sort of >> incomplete user knowledge. What if software Y only enables the network >> periodically, to perform some maintenance function? Even a pedantic >> user checking netstat isn't necessarily going to notice network >> services listening on ports periodically. > > Arguably this should also be fixed by cleaning up all those network services. > >
Re: F21 System Wide Change: Workstation: Disable firewall
On Tue, Apr 15, 2014 at 7:11 PM, William Brown wrote: > On Tue, 2014-04-15 at 13:49 -0700, Matthias Clasen wrote: >> On Tue, 2014-04-15 at 20:41 +0200, Thomas Woerner wrote: >> >> > > >> > > What you need is clearly different "zones" that the user can configure >> > > and associate to networks, with the default being that you trust nothing >> > > and everything is firewalled when you roam a new network. >> > > >> > We have that already with zones in firewalld. >> >> Kindof. If I open the network panel and find the 'Firewall zone' combo, >> I am presented with a choice of: >> Default >> block >> dmz >> drop >> external >> home >> internal >> public >> trusted >> work >> >> This list is far too long, and none of it is translated or even properly >> capitalized. And there is no indication at all why one would choose any >> zone over any other, and what consequences it has. > > Agreed > > Perhaps shorten to: > > block > public > work > home That is a much more intuitive default set. > > The other network zone names really seem targeted at servers. Maybe each > zone needs an attr that states if it's a workstation zone or not to > determine if it joins this list? > >> >> So, what you have currently is a raw bit of infrastructure that is >> directly exposed to the end user, without any design or integration. >> > > > > Additionally, the command line syntax to manage firewalld is obscene. > (maybe slightly off topic ...) > > firewall-cmd --zone=foo --add-port=12345/tcp --permanent > > It doesn't autocomplete in bash either (zsh at least prefills the -- and > gives you some options, but it's not great) > > At least for the "power" user on a workstation, fixing this syntax to at > the minimum remove all the -- would be great. Follow that by nm-cli > style short hand, and I would be a happy person. You could do: > > firewalld-cmd z=foo a-p=12345/tcp perm > > > > Because this syntax is "hard" I think that it even excludes power users > from wanting to make their firewall work on their system. > >> >> >> I don't think we want a 'firewall' UI anyway; the firewall is not >> something most users can or should understand and make decisions of. > > Never take decisions away from users. > > The OSX style firewall works well when enabled. It blocks all by > default, then when an application wants a listening port, the user is > prompted to allow or deny it. I think this is a good model. > >> >> What I envision is that we will notify the user when we connect to a new >> network, with a message along the lines of: >> >> You have connected to an new network. If this is a public network, you >> may want to stop sharing your Music and disable Remote Logins. >> [Turn off sharing] [Continue sharing] [Sharing Preferences...] >> >> And we will remember this for when you later reconnect to the same >> network. > > Why not set the firewall zone when you join the network? And the above > prompts alter that currently active zone? > > >> I've filed a bug for this: >> https://bugzilla.gnome.org/show_bug.cgi?id=727580 >> >> >> Matthias >> > > > > -- > 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: F21 System Wide Change: Workstation: Disable firewall
On Wed, Apr 16, 2014 at 6:55 PM, Lars Seipel wrote: > On Tue, Apr 15, 2014 at 08:14:01PM -0400, Christopher wrote: >> > Perhaps shorten to: >> > >> > block >> > public >> > work >> > home >> >> That is a much more intuitive default set. > > Is it? What's supposed to be the difference between work and home? Whatever they are now, perhaps? What I mean by more intuitive set, is that I understand how to map these to my daily life activities, and the various networks I connect to, much more so than I would the overabundance of zones that exist today. I do not mean that I understand which services will be exposed by default for a particular zone (but I don't know that today, with the multitude of options, either...). I hope that's clear what I meant. > > Lars -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction: Christopher Tubbs
Hi, My name is Christopher Tubbs. I'm a long-time user of Fedora and Linux, and a big fan of free (as in speech) software. I love bigdata and scientific computing, and consider myself a seasoned Java developer and Maven user. I'm currently working on Apache Accumulo as my first package for Fedora (https://fedoraproject.org/wiki/Changes/ApacheAccumulo). I'm also an upstream developer for Accumulo project, which helps, because there's a lot of patches I need to make to get it to build with the dependency versions available in Fedora. I'm not yet in the package maintainers group, but my FAS account is ctubbsii and I'm seeking a mentor (preferably one familiar with the Hadoop ecosystem and Java packaging) to help me get all the kinks worked out of my package. I'm still very new to the whole packaging environment in Fedora, and trying to get a handle on understanding all the infrastructure at Fedora needed to get things done. I definitely need a mentor to help me understand the packaging process and tools in the Fedora infrastructure (cgit, bugzilla, koji, etc.). My draft packaging is not yet done, but in progress here: https://github.com/ctubbsii/accumulo-fedora (temporary) -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- 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: Self Introduction: Christopher Tubbs
Thanks. I still have a bit of work to do before its ready for review... mainly right now, it's missing control scripts and systemd (units?). I'm hoping to have it ready for review soon. -- Christopher L Tubbs II http://gravatar.com/ctubbsii On Tue, May 20, 2014 at 4:00 AM, Mikolaj Izdebski wrote: > On 05/19/2014 07:51 PM, Christopher wrote: >> Hi, >> >> My name is Christopher Tubbs. I'm a long-time user of Fedora and >> Linux, and a big fan of free (as in speech) software. I love bigdata >> and scientific computing, and consider myself a seasoned Java >> developer and Maven user. > > Welcome! > >> I'm currently working on Apache Accumulo as my first package for >> Fedora (https://fedoraproject.org/wiki/Changes/ApacheAccumulo). I'm >> also an upstream developer for Accumulo project, which helps, because >> there's a lot of patches I need to make to get it to build with the >> dependency versions available in Fedora. >> >> I'm not yet in the package maintainers group, but my FAS account is >> ctubbsii and I'm seeking a mentor (preferably one familiar with the >> Hadoop ecosystem and Java packaging) to help me get all the kinks >> worked out of my package. I'm still very new to the whole packaging >> environment in Fedora, and trying to get a handle on understanding all >> the infrastructure at Fedora needed to get things done. I definitely >> need a mentor to help me understand the packaging process and tools in >> the Fedora infrastructure (cgit, bugzilla, koji, etc.). > > If you need help feel free to ask on IRC (#fedora-java or > #fedora-bigdata) or ping me directly. (I am usually the one people come > to with Maven-related packaging questions.) > > For formal sponsorship into packager group just submit a rewiew request. > I can sponsor you if no one else does. > >> My draft packaging is not yet done, but in progress here: >> https://github.com/ctubbsii/accumulo-fedora (temporary) > > I had a quick look at the package and it looks good. There are some > things that could be improved, but it's more a matter of style and best > practices rather than correctness. > > -- > Mikolaj Izdebski > Software Engineer, Red Hat > IRC: mizdebsk > -- > 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: JNI packaging guidelines for optional native sub-package
On Wed, Jun 4, 2014 at 5:15 PM, Christopher wrote:
> Hello all,
>
> I'm working on packaging a jar which includes a java-only
> implementation, and optionally loads [System.load()] if configured to
> do so and the shared library is available.
>
> The actual (arch-dependent) shared library is provided in a separate
> sub-package (because it's optional). This means that technically, the
> jar can be noarch. Therefore, it makes much more sense to use the
> System.loadLibrary() call rather than enforce arch-dependent paths.
>
> The JNI packaging guidelines seem to written with the assumption that
> the package which includes the JNI jar also includes the .so, but
> that's not the case here, since the .so is optional and provided in a
> separate arch-dependent sub-package.
>
> What is the right packaging procedure here? I'm inclined to think that
> using System.loadLibrary() is appropriate in these circumstances, and
> that the jar should be placed in the normal %{_javadir}/%{name} rather
> than the %{_jnidir} area, since it's technically noarch, and the JNI
> features are optional.
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
Adding devel@ to this question about packaging, since no response in 2 days
from java-devel@
--
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: Looking for co-maintainers: zookeeper, bookkeeper, curator
I'm currently a co-maintainer on ZooKeeper. I know there's some bugs that I've overlooked these last few months. I intend to try to address some of them this week, but having another, esp. an upstream maintainer involved, would be nice. On Wed, Oct 14, 2015 at 10:36 AM Raúl Gutiérrez Segalés wrote: > > On Oct 14, 2015 7:27 AM, "Haïkel" wrote: > > > > 2015-10-14 16:21 GMT+02:00 Raúl Gutiérrez Segalés : > > > > > > On Oct 14, 2015 7:14 AM, "Tim St. Clair" wrote: > > >> > > >> I intend to orphan, and I simply don't have the bandwidth to maintain > > >> these packages. > > >> > > > > > > I am a ZooKeeper committer so I'd be happy to take over these (haven't > > > officially maintained any packages though). > > > > > > -rgs > > > > > > > If you're an upstream maintainer, I can sponsor you through the > > comaintainership process and help you > > with topics related to RPM packaging and Fedora guidelines. > > > > Perfect - there's a ZooKeeper release in a month or so, so timing is good. > Thanks! > > -rgs > > > H. > > > > >> > > >> -- > > >> Cheers, > > >> Timothy St. Clair > > >> tstcl...@redhat.com > > >> > > >> -- > > >> 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 > > -- > > 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 -- 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: Recommended way of proposing changes in someone else Fedora packages configuration
To support this, I try to keep a mirror in GitHub for my packages... But it's hard to stay in sync sometimes and nobody really knows it's there. It'd be nice if this were supported directly, perhaps by automatically mirroring all packages in GitHub, like the ASF does, and emailing maintainers when activity occurs. On Sun, Oct 18, 2015, 09:36 Marcin Zajączkowski wrote: > Hi, > > I would like to propose a minor (yet important) change in one of the > Fedora packages configuration (a SPEC file and/or a patch). Is it > possible to create (something like) a pull request which could be > reviewed by the maintainer in some convenient way (*) and optionally > merged? Or the only way is to create a patch and put it into a Buzilla > ticket? > > > (*) - a given package repo could be forked and published to GitHub with > a change in a separate branch. The new repo could be added locally by a > maintainer (as a new remote Git repository) and that new branch could be > merge into master and pushed to Fedora repository. Nevertheless it > requires some knowledge about Git and a few manual Git commands to execute) > > > Marcin > -- > 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: Recommended way of proposing changes in someone else Fedora packages configuration
On Mon, Oct 19, 2015 at 9:42 AM Jared K. Smith wrote: > On Sun, Oct 18, 2015 at 3:37 PM, Marcin Zajączkowski wrote: > >> I like the idea with mirroring Fedora Git to GitHub. Read only mirror >> just to be a dedicated place for that kind of contributions (via pull >> requests). >> > > While I like the idea of making it easier for people to submit patches, > I'm not sure setting up a read-only GitHub mirror is the answer. > > In my day job, I happen to maintain a huge GitHub mirror of a large open > source code repository where the upstream has not yet moved to Git. > Unfortunately, what happens is that people submit pull requests against the > read-only mirror, but the upstream maintainers rarely if ever look at the > pull requests. We end up closing most of the pull requests with a message > that says "Contact upstream directly and try to get your patches to them." > > The ASF uses a pubsub bot to notify project's devel mailing lists when a PR is issued against the read-only mirrors on GitHub. This email contains instructions on how to add a second remote and perform the pull request manually. It also explains how to force the PR to be closed without write access to the mirror (with a commit message that says something like "this closes #X", where X is the PR number, which gets processed when the mirror is next sync'd). In this way, it opens up the community to a wider audience by enabling contributors to use tools they are comfortable with, but in a way that doesn't technically add a dependency on GitHub. Fedora could do something similar by automatically opening a BZ issue, in the same way upstream monitoring opens up new BZs. I know this would be really useful, because before I submitted my first package to Fedora, I had a slightly difficult time figuring out how to contribute, or even check out and view a project's git repository (doing an anonymous clone with fedpkg wasn't obvious). > I also think it would be non-trivial to map Fedora users to GitHub > accounts, or to keep said information in sync. > > This would be non-trivial... but it's also completely unnecessary. The mirrors can/should be read-only while the Fedora repos remain authoritative, with maintainer write-access. The ASF does allow committers to affiliate with the ASF org in GitHub (where the read-only mirrors exist) by voluntarily adding their GitHub usernames to a database, but this doesn't get them any special access to the mirrors... it's just for flair, to show off their membership on their GitHub profile. As far as I'm concerned, this is a completely unnecessary thing to do. Perhaps at some point, we could do this by offering a voluntary field for GitHub username, but it's certainly not essential to using GitHub to enable pull-requests. Of course, Fedora doesn't have to do it the way the ASF did, but I think there's value in looking at what they've done, because there's value in exposing Fedora's packages to a large (and growing) community of GitHub. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
fedora-packages out of sync with bugzilla
Has anybody else noticed that the fedora-packages bug listing (linked from pkgdb) seems out of sync with bugzilla? For example, https://apps.fedoraproject.org/packages/zookeeper/bugs shows bugs which have been closed as being still open, and the counts are incorrect. Is this a known issue? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: fedora-packages out of sync with bugzilla
On Tue, Oct 20, 2015 at 2:01 PM Ralph Bean wrote: > On Tue, Oct 20, 2015 at 10:41:45AM -0600, Kevin Fenzi wrote: > > We are planning a re-work/re-write of the application entirely, but > > it's not happened yet. ;( > > Small correction, we started on it at the end of last week! > > https://github.com/fedora-infra/fedora-packages/pulse/weekly > > We'll put out a small bugfix release soon with some simple changes > (mostly to make sure that we have the release/deployment cycle > down-pat) and then we'll get into some of the more structural changes > in the coming weeks. > > Thanks. It looks like it's mostly in sync now. I just wanted to make sure it wasn't a new issue, or that it wasn't something just affecting me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Bodhi updates not pushed?
On https://bugzilla.redhat.com/show_bug.cgi?id=1272694 it was brought to my attention that my updates for the zookeeper package weren't pushed to the f22 and f21 updates-testing repos, though I do see the one in the f23 repo. Did I do something wrong? Where can I go to check or fix the problem? -- 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: Bodhi updates not pushed?
On Mon, Oct 26, 2015, 04:46 Peter Robinson wrote: On Sun, Oct 25, 2015 at 5:52 PM, Christopher wrote: > On https <https://bugzilla.redhat.com/show_bug.cgi?id=1272694>:// <https://bugzilla.redhat.com/show_bug.cgi?id=1272694>bugzilla.redhat.com <https://bugzilla.redhat.com/show_bug.cgi?id=1272694>/show_ <https://bugzilla.redhat.com/show_bug.cgi?id=1272694>bug.cgi <https://bugzilla.redhat.com/show_bug.cgi?id=1272694>?id=1272694 <https://bugzilla.redhat.com/show_bug.cgi?id=1272694> it was brought to my > attention that my updates for the zookeeper package weren't pushed to the > f22 and f21 updates-testing repos, though I do see the one in the f23 repo. > > Did I do something wrong? Where can I go to check or fix the problem? No, you didn't, it looks like the updates push went awry, should hopefully be headed out shortly. Peter Thanks. All appears well now. -- 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: Orphaned Packages in rawhide (2015-11-02)
On Mon, Nov 2, 2015 at 3:48 AM wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for > sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > ... > Package(co)maintainers Status Change > ... > log4cxx orphan, mjakubicek, mtasaka 4 weeks ago > ... > Depending on: log4cxx (5), status change: 2015-09-30 (4 weeks ago) > ... > zookeeper (maintained by: tstclair, ctubbsii, etuttle, java-sig, > skottler) > zookeeper-3.4.6-12.fc24.src requires log4cxx-devel = > 0.10.0-19.fc23 ... I'm dropping log4cxx from BuildRequires for zookeeper. I'm not sure it was ever needed, anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Unexpected NIC naming f23 firewall implications
I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1. Is this something that was expected? It certainly surprised me. In addition to the mediatomb configuration needing to be changed, I also noticed a more serious issue here: the firewalld zone associated with em1 did not get ported to eno1 during the upgrade. That could have serious unexpected implications for security. In my case, it wasn't that serious, because my default zone was more locked down than the one I had for that NIC, but I can imagine scenarios where it could be a problem. For the most part, the upgrade experience was great, but I thought I'd mention this particular issue for consideration/discussion, because I wasn't aware of the naming change in advance, and it could have serious consequences for function and security. -- 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: Unexpected NIC naming f23 firewall implications
On Sat, Nov 7, 2015, 12:28 Christopher wrote: I recently updated my desktop to f23, and it went smoothly, for the most part. However, it broke my mediatomb server because the NIC changed from em1 to eno1. Is this something that was expected? It certainly surprised me. In addition to the mediatomb configuration needing to be changed, I also noticed a more serious issue here: the firewalld zone associated with em1 did not get ported to eno1 during the upgrade. That could have serious unexpected implications for security. In my case, it wasn't that serious, because my default zone was more locked down than the one I had for that NIC, but I can imagine scenarios where it could be a problem. For the most part, the upgrade experience was great, but I thought I'd mention this particular issue for consideration/discussion, because I wasn't aware of the naming change in advance, and it could have serious consequences for function and security. This is also a good reason why the default firewalld zone should be very restrictive. -- 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: Unexpected NIC naming f23 firewall implications
On Sun, Nov 8, 2015, 14:29 Richard W.M. Jones wrote: On Sat, Nov 07, 2015 at 05:28:54PM +, Christopher wrote: > I recently updated my desktop to f23, and it went smoothly, for the most > part. However, it broke my mediatomb server because the NIC changed from > em1 to eno1. > > Is this something that was expected? It certainly surprised me. It happened to a bunch of servers when I updated them from F22 to F23. Their NICs changed from p6p1 -> enp3s0. It was annoying because I had to boot each one with a display and keyboard and change the network configuration by hand. "predictable, stable network interface names" https <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> :// <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> wiki.freedesktop.org <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> /www/Software/ <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> systemd <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> / <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> PredictableNetworkInterfaceNames <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> / <https://wiki.freedesktop.org/www/Software/systemd/PredictableNetworkInterfaceNames/> Rich. It's a good policy and a good idea, but I thought it had already been done with the em1 naming. I guess i misunderstood when it'd be implemented. -- 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: Unexpected NIC naming f23 firewall implications
On Tue, Nov 10, 2015 at 9:21 AM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > On Tue, Nov 10, 2015 at 07:06:51AM +0100, Tomasz Torcz wrote: > > On Mon, Nov 09, 2015 at 08:50:55PM +, Richard W.M. Jones wrote: > > > > em* and p?p? come from biosdevname, which should not be used and is > deprecated. > > > > > > I'm merely observing what happened when I updated a bunch of servers > > > from F22 to F23. I didn't intentionally install nor uninstall > biosdevname > > > at any point. > And this is the crux of the problem: for some reason biosdevname > stopped working for you. This was not intentional and should not > happen. Is biosdevname it still installed? Can you file a bug > against systemd and attach output of 'sudo udevadm test > /sys/class/net/eno1' > (or whatever the name the device has in the end)? > > > But you should have. Biosdevname what deprecated 3 years ago (with > Fedora 19 > > or 20*), you should have migrated your rules to udev's naming scheme and > > remove biosdevname. > That's true, but not really relevant. We neither removed biosdevname nor > announced that is not supported anymore, and if it suddenly stopped working > we need to figure out why. > > Well, I still have biosdevname-0.6.2-1.fc23.x86_64 installed on the desktop machine I mentioned was upgraded in the original post, where the NIC was changed from em1 to eno1 on the upgrade. https://bugzilla.redhat.com/show_bug.cgi?id=1280037 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Ivy packaging for EPEL7
What's the best way to deal with resolving ivy dependencies in EPEL7? I'm trying to package zookeeper for EPEL7, and am running into problems. I see there's ivy-local for F21 and later, which comes with xmvn 2, but it looks like EL7/EPEL7 is mostly a F19-era package set. Are there any plans to bump xmvn to 2 for EPEL7, or to provide ivy-local another way? Or is there another option? I'm really more familiar with maven builds than ivy, so this is somewhat of a struggle. Any advice would be appreciated. -- 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: Ivy packaging for EPEL7
On Mon, Nov 16, 2015 at 11:26 AM Christopher wrote: > What's the best way to deal with resolving ivy dependencies in EPEL7? I'm > trying to package zookeeper for EPEL7, and am running into problems. > > I see there's ivy-local for F21 and later, which comes with xmvn 2, but it > looks like EL7/EPEL7 is mostly a F19-era package set. > > Are there any plans to bump xmvn to 2 for EPEL7, or to provide ivy-local > another way? Or is there another option? I'm really more familiar with > maven builds than ivy, so this is somewhat of a struggle. > > Any advice would be appreciated. > Bump. Anybody familiar with packaging ivy builds for EPEL7 at all? -- 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: Dealing with the "my packages" problem
On Thu, Nov 19, 2015 at 9:44 AM, Orion Poplawski wrote: > On 11/18/2015 02:49 PM, Adam Williamson wrote: >> >> Just as a general note on this thread: if you're a packager and you >> have a genuine reason why people should be careful about touching your >> package, or follow some specific process when doing so, or there's >> something that people might think they should change but they >> shouldn't, there is already a pretty effective way of dealing with >> this: >> >> ** PUT A COMMENT IN THE SPEC FILE ** >> >> this is extremely easy to do, and extremely difficult for anyone who >> touches it to claim they didn't see. > > > I like this and think it covers this issue pretty well. Coupled with a much > needed "get over it - it's not *your* package" attitude shift. > +1, also good git commit logs are helpful in addition to inline comments. I also think it'd be easier to suggest changes to maintainers if we had a good pull request system (I know it's been suggested before... possibly by using mirrors on GitHub) to deal with the occasional one-off drive-by fix. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
LibreOffice packaging is a messy dependency graph
What's the deal with libreoffice packages being a dependency for so many system library packages? I try to `sudo dnf remove libreoffice\*` and it grabs a bunch of surprising packages with it, including some fonts and system libraries. Granted, I don't think I need any of these things, so it's probably safe to uninstall them, but it is surprising that so many packages depend on libreoffice packages. I'd normally expect the dependencies to be the other way around (libreoffice-* depending on system libraries some basic fonts, while other fonts are independent or have only optional dependencies on LibreOffice). I don't need or want an offline office suite (it's huge, and takes up bandwidth during updates). I don't mind uninstalling it after a fresh install, but it is surprising how much goes with it. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Upstream DNF?
Where is the upstream DNF issue tracker? I see the project on GitHub: https://github.com/rpm-software-management/dnf However, there doesn't appear to be a corresponding issue tracker, or point of contact to request access to edit Wiki pages (which are locked down), etc. In fact, there appears to be only 3 public members of the upstream community. Is this not the canonical location for upstream DNF? If not, does anybody know where it is? If it is, I'm a bit concerned about its insular nature. Apologies if this has been brought up before... I don't recall anything recent; also, not interested in ranting/raving about DNF... I've deliberately avoided those kinds of threads in the past. I'm just trying to find (and subsequently engage with) the correct upstream community. Thanks. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Let's Encrypt for F23?
I see a couple of the Let's Encrypt dependencies (like python-acme) are working their way in to rawhide, but not yet in F23. I also don't yet see a 'letsencrypt' package. Since it's now in "Public Beta"[1], having it available soon might be very useful for F23 users. Does anybody have any plans to work on making the tools (and their dependencies) available as an update to F23? If so, I'd be willing to help test and/or review. [1]: https://letsencrypt.org/2015/12/03/entering-public-beta.html -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Devel archives site is awesome, but...
The devel mailing list archives has an awesome interface, but unfortunately, it only seems to work with the devel@ list, not any of the others (like java-devel@). Any plans to extend that functionality to improve all the mailing list archives? -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Easier %config management?
Which components/packages are best candidates for adding a feature which would make it easier for users to track changes from the default %config %files on the system? I've found this to be a deficiency, requiring users to do configuration management independently of the installer tools on a system, and I think the situation could be improved by adding functionality to the installation tooling to track these changes better. For example, I can see which %config files have changed with `rpm -V`, but I can't see what the changes actually are unless I do `dnf download $myrpm`, extract it, and diff them. Alternatively, I could rename the configuration file, and do a `dnf reinstall $myrpm` to replace the original, and then diff them. Both of these methods are clunky, wasteful, and not without side-effects. rpmconf is nice, because it helps me easily compare configuration files whose user-changes and maintainer-changes conflict... but that's not quite the same thing. Here's some things I was thinking: rpm could track more than hashes of config files, and instead track the full file. This could be optional, as it uses more disk space, but disk space is cheap these days, and config files are relatively small. This would avoid having to re-download the rpm, and would make it easier to see what has been modified on their system. So, some users may find that a worthwhile trade-off. Alternatively, dnf could also add an '--update-configs' option to the 'reinstall' command, to force the creation of rpmorig/rpmnew files for reinstall (currently these only get created during updates, as far as I understand it). This won't avoid the re-download, but might be an easier solution, and wouldn't require the extra disk space (after the rpm is reinstalled). This option would enable the existing rpmconf to do its job. rpmconf might also need modification to support tracking configuration management more fully, rather than just for updates. I'm sure there's other components/solutions (in general, I find `git init /etc/` to be quite convenient, but it's a messy hack). Any thoughts? Is this an area which can be improved easily? Are there existing solutions within Fedora? Something we could bring in? Specific upstream packages we can target for feature requests? -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Easier %config management?
On Sun, Dec 13, 2015 at 2:50 PM Reindl Harald wrote: > > Am 13.12.2015 um 05:58 schrieb Christopher: > > rpm could track more than hashes of config files, and instead track the > > full file. This could be optional, as it uses more disk space, but disk > > space is cheap these days, and config files are relatively small. This > > would avoid having to re-download the rpm, and would make it easier to > > see what has been modified on their system. So, some users may find that > > a worthwhile trade-off > > first: disk space is *not* cheap these days * > second: etckeeper exists > third: no need to re-invent the wheel > > I meant that it's cheaper than it ever has been, and that the marginal costs of adding a 100MB or so is very small compared to the overall size of the disk. Certainly, it wouldn't be appropriate for all cases, but I feel confident saying that the average user isn't going to notice, in terms of disk utilization or costs, if the size of /etc doubles. Honestly, I didn't think that would be a contentious premise, and it's not exactly the main point of what I was trying to say. I did point out that it would be worthwhile only for "some users". Didn't know about etckeeper. Suggestions like that are exactly why I raised the question. I'm not suggesting the wheel be reinvented. I'm trying to figure out whether there exists an appropriate wheel to use, and if not, what materials should we build one out of. After looking into it, I think etckeeper might be a bit overkill (for my use case, at least). While etckeeper hooks the update system to track changes between updates, I'm more interested in knowing the answer to the question "what is the difference between the current package maintainer's version, and the current version on my system?", at any point in time. In other words, "what has the user modified?". Currently, the only time that is easily answered is when an *.rpmnew file exists, because that's when I have a copy of the package maintainer's unmodified version to compare with. However, I'd like to be able to ask this of any system, at any time. I'm not sure a VCS really helps all that much. 99% of all users don't care and the yone who cares using a VCS for /etc > like "etckeeper" while i never ever would use that directly on > production servers but on a admin-server pull from the infrastrcuture > and fire etckepper there - works like a charme for many year > > You're right, and I agree that most users don't care. This makes it hard to support/troubleshoot user's systems, when they've changed from the working defaults. I'm sure there's other use cases (I've seen some interesting ones in this thread), but my primary interest is having baked-in configuration management, when users don't do it themselves. If users were good at configuration management, they'd keep a record of everything they change, and this wouldn't be an issue. I'm more concerned about asking the system the question about what the user has edited, precisely because I want to support users who aren't good at configuration management, and don't keep track of what they've changed from the defaults. That's hard to do in Fedora... there isn't even really a way to easily "reset Fedora to defaults" using yum/dnf/rpm, because there isn't an easy way to retrieve the defaults. That's essentially the core of this problem: how to easily retrieve the (current) defaults. > * > disk space maybe cheap for some fire-and-forget machines, but not on > enterprise storage hosting hundrets of instances > <http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org> -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Easier %config management?
On Sun, Dec 13, 2015 at 3:39 PM Reindl Harald wrote: > > > Am 13.12.2015 um 21:22 schrieb Andrew Lutomirski: > > For the few cases that can't or won't comply, then having rpm > > (optionally?) make the originals available would be fantastic for > > system management > > how many copies would you like to store in the rpm database and how to > access them in a useful manner > > For my purposes, exactly 1 copy would be needed: the one contained in the currently installed packages, before any user modifications. > define "originals" > > For me, I'd want the up-to-date one from the current version of the installed packages, not the initial state... just the up-to-date state as determined by the package maintainer. My main interest is finding what the user changed, to make it different from the packager's defaults. when the system was installed versus current state? > worthless - most of my Fedora setups are from 2008 > > the current and the previous version? > well, you need to handle cases where a config file is unchanged but the > package is updated, that's the majority of all updates > > > honestly: > that all violates the unix principles one tool for one task and there > are tools available for config file management many years, people > interested just need to use them, "etckeeper" is integrated in dnf/yum > and makes a versioned "snapshot" of /etc before and after updates are > applied > > For me, I just want to know what the user changed. (like how `rpm -V` shows that a file has been modified from the package version with an md5 check... but I want to know the content of those modifications). I'm not sure what the best tool for this task is, but I'm pretty sure etckeeper isn't it. rpm is already doing similar functionality, but not tracking the full files, only the md5 hashes. yum/dnf is also doing similar functionality when it creates *.rpmnew files, but only when the packager's version is updated... essentially I'd want *.rpmnew to be created every time (and left on the system, never being deleted) so it can be compared with the user version. I'm not sure I agree that UNIX principles are to have one tool for one task. It is common for there to be many tools capable of achieving the same task. I think the principle is to have one task for each tool and to do that task well (in other words, tools shouldn't be bloated, but they can certainly have alternatives). But, that's not even what we're talking about here. At least, it's not what I'm talking about. What I'm talking about is: 1) trying to find the best tool for the task if it exists, 2) determining if a tool must be created, and 2) figuring out if features must be added to the underlying package management system to support those tools. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Easier %config management?
On Mon, Dec 14, 2015 at 11:22 AM Reindl Harald wrote: > > > Am 14.12.2015 um 17:01 schrieb Christopher: > > On Sun, Dec 13, 2015 at 3:39 PM Reindl Harald > For me, I'd want the up-to-date one from the current version of the > > installed packages, not the initial state... just the up-to-date state > > as determined by the package maintainer. My main interest is finding > > what the user changed, to make it different from the packager's defaults. > > > > when the system was installed versus current state? > > worthless - most of my Fedora setups are from 2008 > > > > the current and the previous version? > > well, you need to handle cases where a config file is unchanged but > the > > package is updated, that's the majority of all updates > > > > For me, I just want to know what the user changed > > what you propose can't work for that because you only compare the > *current users* version with the *current package* version > > Yes, that's all I want. > that is a naive approach > > Yes, but the naive approach satisfies my use case. Others may have more needs, but this is all I need. As an SA, I don't need to track the full history of the packages (at least, not on every user's machine), and there's easier ways to get that anyway (look in cgit and/or upstream VCS). I just need to periodically check in on what the user has tampered with (for example, when they come to me for assistance when something is broken), or to periodically back up or audit their changes. > i modified my "httpd.conf" based on Apache 2.2 years ago, as Fedora > swicthed to Apache 2.4 your approach would have compared a customized > Apache 2.2 version with a Fedora 2.4 version > > But, that's precisely what I want to do I want to know which fields in the current configuration could possibly have introduced a breakage I see... or which changes I need to make from a clean installation to get a user back to the state they wanted. > the same happens to anything which has large changes over time > > the moment when config formats are changing is the one where it starts > to become interesting and at that moment is completly wortless to > compare different generations of a config file without the full history > > I would disagree that it's completely worthless, but I agree that it's more difficult. But, this is where I go to the docs anyway: "K1 did F in version V1, but K2 does F in version V2". I would never migrate configs based on history; I do it based on the docs. > what you *really* would need to compare at *that moment* is your changes > years ago based on the dist-version of the config file at the same moment > > No, I don't... not for my use case. I want to know what differences are to either fix a problem a user is having (when a default config works), or to back up those differences so I can reinstall a clean system and get a user back to the state they had before. > that's nothing you can or should try to cover with rpm - try to solve > this with 1 or 2 limited copies would fail after dist-upgrades as i have > already said > > I agree... I don't think rpm should do all that. But, again, that's not what I need, nor what I'm suggesting rpm be able to do. compare two versions is worthless, you need at least three to *get a > context* > > * previous dist version - CAUTION > * your current version > * now to install/installed dist-version > > which previous dist-version owul dbe helpful depends, the most > interesting one is that from where user changes derived and to answer > that question you need more data than one copy because form the first > change on the *users version* will always differ, but from which distro > state did that happen > > <http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org> -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Easier %config management?
On Tue, Dec 15, 2015 at 12:37 AM J. Randall Owens < jrowens.fed...@ghiapet.net> wrote: > On 12/14/2015 02:47 PM, Christopher wrote: > > On Mon, Dec 14, 2015 at 11:22 AM Reindl Harald > <mailto:h.rei...@thelounge.net>> wrote: > > > > i modified my "httpd.conf" based on Apache 2.2 years ago, as Fedora > > swicthed to Apache 2.4 your approach would have compared a customized > > Apache 2.2 version with a Fedora 2.4 version > > > > > > But, that's precisely what I want to do I want to know which fields > > in the current configuration could possibly have introduced a breakage I > > see... or which changes I need to make from a clean installation to get > > a user back to the state they wanted. > > > > But in order to do the former, you'd best compare the new default to the > old default, to see what had changed in the default. (E.g. distro 2.2 to > distro 2.4) To do the latter, you'd compare the old default (distro 2.2) > to your modified version (altered 2.2), to see what you'd changed > locally. And yet, you seem to be proposing comparing the new default to > the old default (distro 2.4 to altered 2.2), which gets you neither? (Or > both, really, but uselessly mashed together so you don't know which is > which.) Am I missing something? > > I'm less interested in what the user intended to change in an older version than the full difference between the current default (presumably working) configs and the current files (which would include any user modifications AND any old defaults carried forward). The current system breakage could be the result of user edits, or a carry-forward of an older config. I don't care which is the case... I just want to see the differences to troubleshoot the problem... I just want to fix the system as it exists today... not question user edit decisions which occurred years ago. Certainly, a full history, tracking all user edits, and all system updates, would be useful to some. It's just more than what I personally need, and seems a bit outside the scope of the existing installer tools (as previously stated with the suggestion to use etckeeper). For now, I think I'm going to write a script to parse the output of `rpm -V` and then `dnf download` all the packages corresponding to changed configs, then extract each rpm's %config files, to compare with those on the system. It's messy, but it'll work, and in the absence of rpm storing the full configs or being able to instruct rpm/dnf to reset configs back to the defaults (after backing up), there doesn't seem to be an existing solution that will give me the same result. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Easier %config management?
That blog seems to describe supporting a stateless use case, not for
advocating that all systems should be stateless. In any case, the factory
reset use case they describe is similar to some of my own.
On Mon, Dec 21, 2015, 23:32 Nico Kadel-Garcia wrote:
> On Thu, Dec 17, 2015 at 3:55 AM, Harald Hoyer wrote:
> > On 16.12.2015 03:32, Colin Walters wrote:
> >> On Tue, Dec 15, 2015, at 06:43 PM, Japheth Cleaver wrote:
> >>>
> >>> Perhaps RPM (or yum/dnf, via plugin) could write a duplicate copy of
> all
> >>> config files into a tree somewhere? (E.g., /usr/lib/config/ or
> >>> /usr/share/config/?)
> >>
> >> I mentioned this above, but might as well repeat since it was missed;
> OSTree
> >> (as used by the existing Fedora Atomic Host) does this by default today
> in
> >> /usr/etc, so if one was adapting this change to the client-side system
> assembly
> >> tools like yum/dnf, I'd say it would make sense to follow the precedent.
> >>
> >>
> >
> > I already experimented with /usr/share/factory/{etc,var} , but /usr/etc
> sounds
> > fine to me, too.
>
> /usr/etc is expressly forbidden in the verison 3 of the File Hierarchy
> System published at
> http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf. "/etc" files
> go in "/etc", and *maybe* /usr/local/etc depending on whether the
> package is local to the speicific host.
>
> Also pay attention to systemd encroaching on /etc/ The long term plan
> of at least one of the core systemd deveopers is to replace locally
> modifiable "/etc" with systemd program management, in order to make
> Linux "stateless". There's a description of the approach at
> http://0pointer.net/blog/projects/stateless.html.
>
> > Additionally I would like to have that in the rpm package itsself, not
> with
> > some plugin on installation, because "rpm -qf" should output to which
> package
> > the file in /usr/etc belongs. Also the %config(noreplace) attribute has
> to be
> > removed from the pristine config files.
> >
> > Attached is a quick hack to rpm I have done for experimenting with that
> feature.
> >
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
> --
> devel mailing list
> devel@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
>
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: is there a reason for starting zookeeper.service in background?
On Mon, Jan 11, 2016 at 11:41 AM Lennart Poettering wrote: > On Mon, 11.01.16 18:30, Muayyad AlSadi (als...@gmail.com) wrote: > > > quoted from systemd.serivce manual page > > > > >> it is recommended to also use the PIDFile= option, so that systemd can > > identify the main process of the daemon. > > > > my point is that having a child double forked does not mean Zookeeper TCP > > port is ready which is as bad as simple which is also does not indicate > > when it's ready > > Well, then Zookeeper is simply broken. > > Classic UNIX daemons double fork, and only exit in the parent after > the main daemon process (i.e. the "parent"'s grandchild) informed it > that start-up is now complete, and that most importantly pretty much > means two things: > > A) The communication channels are established > B) The PID file is now written > > That the parent process hangs around until the main daemon did these > two jobs is essential on SysV, so that shell processing can work, as > the parent returning is the trigger for invoking the next shell > script line, which then is supposed to rely on the daemon being up. > > systemd makes the same assumptions on SysV here, even though no shell > scriping is involved. If Zookeper doesn't get this right it's borked > on SysV the same way as on systemd, and really should get fixed. > > See daemon(7) on some docs how a classic UNIX daemon is supposed to > start up. > > Lennart Hi, I'm a co-maintainer for ZooKeeper, and I'd like to help get this right, if possible. More importantly, I'm interested in setting a precedent for Java system services in systemd. So, forgive my ignorance, but what exactly is the generally recommended way of launching Java-based applications as system services in systemd? Is there a good model to follow? A Java service that gets this right? Also, as I understand it, Java processes don't really fork in any way that's useful here. The JVM has it's own internal threading model. So, what's the best way for them to play nice with systemd? Should they all be simple? Or should they all be launched by a shell script which implements the double-forking paradigm? If the latter, wouldn't that add a lot of complication that systemd is designed to eliminate with the simplicity of writing units? -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Embedding javascript in binary
On Wed, Jan 20, 2016 at 12:34 PM Sander Hoentjen wrote: [snip] > > https://fedoraproject.org/wiki/Packaging:JavaScript > Yeah I read that, but is says "Please note that this section really only > applies to JavaScript libraries intended for use on the web." so I am > not sure that applies to my case. > It also doesn't thoroughly cover these use cases: 1. how to handle customized embedded forks of a JavaScript library in upstream, 2. how to deal with JavaScript resources which upstream Java packages embed in their WARs (should the maintainer have to rewrite significant portions of upstream code to make these resources available from another location in the filesystem?), 3. applications which require the same shared JavaScript resources but with slightly different flags set in the source (to control style, or behavior), 4. how to package a single upstream project which many projects use which contains a combination of images, styles, JavaScript, and other resources, in a well-known hierarchical structure (like Bootstrap) -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Embedding javascript in binary
On Thu, Jan 21, 2016 at 2:03 PM Sander Hoentjen wrote: > On 01/21/2016 12:29 AM, Christopher wrote: > > On Wed, Jan 20, 2016 at 12:34 PM Sander Hoentjen > <mailto:san...@hoentjen.eu>> wrote: > > [snip] > > > > > https://fedoraproject.org/wiki/Packaging:JavaScript > > Yeah I read that, but is says "Please note that this section > > really only > > applies to JavaScript libraries intended for use on the web." so I am > > not sure that applies to my case. > > > > > > It also doesn't thoroughly cover these use cases: > > > > 1. how to handle customized embedded forks of a JavaScript library in > > upstream, > > > > 2. how to deal with JavaScript resources which upstream Java packages > > embed in their WARs (should the maintainer have to rewrite significant > > portions of upstream code to make these resources available from > > another location in the filesystem?), > > > > 3. applications which require the same shared JavaScript resources but > > with slightly different flags set in the source (to control style, or > > behavior), > > > > 4. how to package a single upstream project which many projects use > > which contains a combination of images, styles, JavaScript, and other > > resources, in a well-known hierarchical structure (like Bootstrap) > So do you have any ideas regarding these issues? > Would it be ok for my case if upstream provides both minified and src js? > How could I check if the minified one is indeed gotten from the src js? > Or do I always have to re-minify js? > Is included jquery okay or do I have to use the jquery that is already > packaged? > > Unfortunately, no. I don't have answers for how to deal with these cases. However, I do think that minification should always be done as part of the build, and any upstream minified source should not be used at all, as it's not free and open source software. As for jQuery, js-jquery and the older js-jquery1 are already packaged in Fedora. Hopefully you can figure out how to make your package use those instead of embed its own. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Gnome keyring security in Fedora
I've been thinking about Gnome keyring a lot lately, and I have concerns about security, and I don't know if this is a Gnome keyring problem, or a problem affecting Fedora specifically. In short, it doesn't look like Gnome keyring has the ability to notify a user interactively when a password is read from an unlocked keyring (or to dynamically unlock it with a master passphrase upon request). Is this correct? If so, it puts it behind NSS features that Firefox and other apps use to store passwords and other credentials. However, if it's just something specific which isn't packaged for Fedora, or isn't installed by default, that would be very good to know. In the past, seahorse-plugins provided a gpg-agent with a tool for configuring cache preferences. It looks like seahorse-plugins is no longer packaged for Fedora, and gpg2 integrates with seahorse/gnome keyring differently (I don't know how). At least for GPG passphrases, this provided some UI to notify the user upon programmatic access to the cached credentials, and provided an notification icon whenever the cache was non-empty. It also provided a customizable timer for the cache. Although they didn't help for non-GPG credentials, these features of seahorse-plugins provided important (essential, I would say) security for a GPG credential cache (and, I would argue, essential for any private credential store). However, these appear to have been lost in Fedora, making Fedora less secure. Does anybody know about this? Do these features have replacements which I'm not aware of? If so, why aren't they installed in Fedora by default? Is this downgrade in security a Fedora problem, or is it a Gnome problem, or a seahorse problem? Are there alternatives? NSS seems to be getting some of this right, but doesn't have good integration with Gnome/Seahorse/GPG. Thoughts? -- Christopher -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Gnome keyring security in Fedora
On Thu, Jan 21, 2016 at 3:38 PM Christopher wrote: > I've been thinking about Gnome keyring a lot lately, and I have concerns > about security, and I don't know if this is a Gnome keyring problem, or a > problem affecting Fedora specifically. > > In short, it doesn't look like Gnome keyring has the ability to notify a > user interactively when a password is read from an unlocked keyring (or to > dynamically unlock it with a master passphrase upon request). Is this > correct? If so, it puts it behind NSS features that Firefox and other apps > use to store passwords and other credentials. However, if it's just > something specific which isn't packaged for Fedora, or isn't installed by > default, that would be very good to know. > > In the past, seahorse-plugins provided a gpg-agent with a tool for > configuring cache preferences. It looks like seahorse-plugins is no longer > packaged for Fedora, and gpg2 integrates with seahorse/gnome keyring > differently (I don't know how). At least for GPG passphrases, this provided > some UI to notify the user upon programmatic access to the cached > credentials, and provided an notification icon whenever the cache was > non-empty. It also provided a customizable timer for the cache. > > Although they didn't help for non-GPG credentials, these features of > seahorse-plugins provided important (essential, I would say) security for a > GPG credential cache (and, I would argue, essential for any private > credential store). However, these appear to have been lost in Fedora, > making Fedora less secure. Does anybody know about this? Do these features > have replacements which I'm not aware of? If so, why aren't they installed > in Fedora by default? > > Is this downgrade in security a Fedora problem, or is it a Gnome problem, > or a seahorse problem? Are there alternatives? NSS seems to be getting some > of this right, but doesn't have good integration with Gnome/Seahorse/GPG. > > Thoughts? > > To be honest, I thought there'd be more interest in this topic by now, considering Gnome Keyring stores so many things now in the Logon keyring by default: Bugzilla credentials for ABRT, Chrome sync'd passwords, Firefox site passwords, GPG private keys, gpg-agent passphrases, SSH private key passphrases, etc. And these can be accessed without any user notification or interaction by any process run by the user by making simple Gnome library calls, unless the user explicitly locks it between uses as a manual process, and even then it won't keep out a persistent script which grabs what it wants during an open window when the keyring is unlocked (it doesn't appear there's an atomic "unlock for this key only, then relock" option). I can't be the only one interested in finding out how to secure these things in Fedora. -- Christopher -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Gnome keyring security in Fedora
On Thu, Jan 28, 2016 at 2:06 PM Kevin Fenzi wrote: > On Thu, 28 Jan 2016 18:43:09 + > Christopher wrote: > > ...snip... > > > I can't be the only one interested in finding out how to secure these > > things in Fedora. > > No, but it could be no one who knows is on this list or has seen your > post. > > Perhaps try reposting to > https://mail.gnome.org/archives/gnome-keyring-list/ > > and if you find out more let us know back here? :) > > Will do. I was thinking some of the answers might be Fedora-specific, but I'll discuss over there first. Thanks. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Gnome keyring security in Fedora
On Thu, Jan 28, 2016 at 2:37 PM Michael Catanzaro wrote: > On Thu, 2016-01-28 at 18:43 +0000, Christopher wrote: > > I can't be the only one interested in finding out how to secure these > > things in Fedora. > > Any application running as your user can read anything from your > keyring (provided it is unlocked). This is not problematic because we > don't have any application sandboxing yet, so apps can read all your > personal files and do whatever they want with them. They're trusted by > definition. Who cares if they can get your passwords too? > > We should care. Passwords and other credentials are used beyond the local machine, to authenticate to remote resources and remote entities. I care much more about an app using my GPG code signing key to sign something and distribute it on the Internet, or that it can log in to my bank account with my password, than I do about an app completely screwing up my home directory (to include wiping any encrypted credentials in my config files). Corrupting local drives/configuration, and getting access to unencrypted private credentials are two very different security threats, which must be treated differently. Just because some threats would still exist, doesn't mean we shouldn't attempt to mitigate those we know about. The previous seahorse-plugins GPG caching was a good example... it provided a notification when a key was cached, allowed you to set an expiration time for the cache, and optionally required you to approve each cache access. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: F25 Self Contained Change: NSS enforces the system-wide crypto policy
It's my understanding that there's been some recent work to move openjdk to certain NSS security providers (for EC, for example). But, I think you already answered my (poorly worded) question. Thanks. On Mon, May 23, 2016, 04:01 Nikos Mavrogiannopoulos wrote: > The impact in what sense? Note that openjdk will also conform to the > system wide policy. > > regards, > Nikos > > On Fri, 2016-05-20 at 15:24 +, Christopher wrote: > > What is the impact on openjdk crypto providers? > > > > On Fri, May 20, 2016, 05:49 Jan Kurik wrote: > > > = Proposed Self Contained Change: NSS enforces the system-wide > > > crypto policy = > > > https://fedoraproject.org/wiki/Changes/NSSCryptoPolicies > > > > > > Change owner(s): > > > * Nikos Mavrogiannopoulos > > > > > > As it is now, the System-wide crypto policy in F24 is only enforced > > > by > > > the OpenSSL and GnuTLS TLS libraries. To harmonize crypto in > > > Fedora, > > > NSS is enhanced to respect the settings of the system-wide crypto > > > policy as well. > > > > > > == Detailed Description == > > > As it is now, the System-wide crypto policy in F24 is only enforced > > > by > > > the OpenSSL and GnuTLS TLS libraries. To harmonize crypto in > > > Fedora, > > > NSS is enhanced to respect the settings of the system-wide crypto > > > policy as well. > > > After that change the administrator should be assured that any > > > application that uses NSS will follow a policy that adheres to the > > > configured profile. > > > > > > > > > == Scope == > > > * Proposal owners: > > > The change requires modifying the NSS library to read a policy > > > generated by the crypto-policy package. > > > > > > * Other developers: > > > There are no required actions by other developers. The change > > > requires > > > only targeted changes to NSS. > > > > > > * Release engineering: > > > No actions required. > > > > > > * Policies and guidelines: > > > - The packaging guidelines for crypto policies need to be modified > > > to > > > include NSS in the list of libraries supporting the policies. > > > - The text "(note that adherence to the system-wide policies is > > > work > > > in progress for NSS libraries)" must be removed > > > - The text "Currently the policies are restricted to applications > > > using GnuTLS and OpenSSL" must be changed to include NSS. > > > > > > * Trademark approval: > > > N/A (not needed for this Change) > > > -- > > > Jan Kuřík > > > Platform & Fedora Program Manager > > > Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic > > > -- > > > devel mailing list > > > devel@lists.fedoraproject.org > > > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraprojec > > > t.org > > > > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject. > > org > -- > Nikos Mavrogiannopoulos, PhD, > Crypto Tech. Lead, > Security Technologies, > Red Hat, Inc. > > > > > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: systemd 230 change - KillUserProcesses defaults to yes
On Fri, May 27, 2016 at 9:58 AM Lennart Poettering wrote: > On Fri, 27.05.16 08:09, Chris Adams (li...@cmadams.net) wrote: > > > Once upon a time, Zbigniew Jędrzejewski-Szmek said: > > > Also note that running jobs in a systemd service has advantages on the > > > server: better accounting, more transparency, logs are easier to read. > > > The (old) default of allowing left-over session processes to live on > > > seems especially bad on a server with multiple users. > > > > Starting a one-off task under screen and detaching is an age-old server > > management process. Breaking that is not acceptable IMHO. > > And it is still supported. > > In my view it was actually quite strange of UNIX that it by default > let arbitrary user code stay around unrestricted after logout. It has > been discussed for ages now among many OS people, that this should > possible but certainly not be the default, but nobody dared so far to > flip the switch to turn it from a default to an option. Not cleaning > up user sessions after logout is not only ugly and somewhat hackish > but also a security problem. > > [snip] Apologies for a metaphor, but... Imagine a map of a terrain, and a transparent plastic overlay containing landmarks. Most of the time, people find it valuable to view the map with the overlay laid on top of it. But, sometimes it's useful to remove the overlay and look at the natural terrain. It would be a mistake to think that the only perspective is the one with the overlay on top... and it would be a big mistake to glue the overlay down so that particular perspective is effectively enforced. The "login" concept here seems to me nothing more than a conceptual overlay of what's going on underneath (running user processes). Sure, it's a convenient way of describing a particular experience with a computer. But, it's not the only way to describe that experience. One could also describe it as a a graph of arbitrary processes. It seems to me that what's happening is that systemd is now enforcing this "login session" perspective... metaphorically speaking, gluing the transparent overlay onto the map (but don't worry! they also provide a special adhesive remover!). This makes it that much harder for people to make use of what's underneath without viewing it through the overlay... which, as it turns out, is a *very* common thing to do (screen, tmux, nohup, etc.). Whether or not this as default is a good thing in the long run, I don't know. I can see pros and cons (ease of cleanup / unexpected behavior for a big group of folks). However, I am concerned that it seems the conceptual perspective of a "login" is now being enforced within the internals. I think it's a mistake to think that the internals *must* match our human experience/understanding from the outside (the experience of a "login" session/environment), and this change appears to be stepping in that direction. Perhaps one intermediate compromise is to, instead of requiring the use of system-run, users should be able to have a whitelist of processes (like screen, tmux, etc.) which are not killed as "cleanup". (Clearly, "screen" is intentionally long-running, and should never be treated as "leftovers" from a login session. I'm sure there are others which would fall under this scenario too.) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Bugzilla email address sync
I recently updated my FAS account email forwarding address. Then, I got an email with the title "Please fix your bugzilla.redhat.com account" This email was notifying me that my bugzilla.redhat.com account email address did not match my FAS forwarding address. I'd really rather not broadcast my forwarding address on bugzilla more than necessary. I'm subscribed to the mailing lists under my @fedoraproject.org address (recently changed via Postorius). Will setting my bugzilla email address to the @fedoraproject.org make everything happy again, or must the bugzilla address really be the same as my forwarding address? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bugzilla email address sync
On Wed, Jun 1, 2016 at 5:56 PM Kevin Fenzi wrote: > On Wed, 01 Jun 2016 21:51:27 + > Christopher wrote: > > > I recently updated my FAS account email forwarding address. > > > > Then, I got an email with the title "Please fix your > > bugzilla.redhat.com account" > > > > This email was notifying me that my bugzilla.redhat.com account email > > address did not match my FAS forwarding address. > > > > I'd really rather not broadcast my forwarding address on bugzilla > > more than necessary. I'm subscribed to the mailing lists under my > > @fedoraproject.org address (recently changed via Postorius). > > > > Will setting my bugzilla email address to the @fedoraproject.org make > > everything happy again, or must the bugzilla address really be the > > same as my forwarding address? > > Normally it must be the same as the address you have in fas. > > This is so that our scripts can grant you special groups and such if > you are a packager or in QA, etc. > > However we can add an exception if you want to use your > fedoraproject.org alias instead there. Just open a fedora > infrastructure ticket and we can get it sorted out. > > Thanks. I opened: https://fedorahosted.org/fedora-infrastructure/ticket/5333 to address the issue more broadly (I figure this would be useful to others, and not just me). -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Bugzilla email address sync
On Thu, Jun 2, 2016 at 3:44 AM Pierre-Yves Chibon wrote: > On Wed, Jun 01, 2016 at 04:37:26PM -0600, Kevin Fenzi wrote: > > On Wed, 01 Jun 2016 22:30:14 + > > Christopher wrote: > > > > > Thanks. I opened: > > > https://fedorahosted.org/fedora-infrastructure/ticket/5333 to address > > > the issue more broadly (I figure this would be useful to others, and > > > not just me). > > > > I don't think there's a more broad solution that will currently > > work. ;) > > In the future FAS3 will have a distinct bugzilla_email field allowing > anyone to > use an email for their bugzilla account and a different one for their @fp.o > alias. > > > That sounds neat. What's the timeline for FAS3? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Hadoop?
So, it would seem at some point, without me noticing (certainly my fault, for not paying attention enough), the Hadoop packages got orphaned and/or retired? in Fedora. This is a big problem for me, because the main package I work on is dependent upon Hadoop. What's the state of Hadoop in Fedora these days? Are there packaging problems? Not enough support from upstream Apache community? Missing dependencies in Fedora? Not enough time to work on it? No interest from users? Whatever the issue is... I'd like to help wherever I can... I'd like to keep this stuff going. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Hadoop?
On Thu, Jun 2, 2016 at 5:21 PM Chris Murphy wrote: > On Thu, Jun 2, 2016 at 3:03 PM, Christopher > wrote: > > So, it would seem at some point, without me noticing (certainly my fault, > > for not paying attention enough), the Hadoop packages got orphaned and/or > > retired? in Fedora. > > > > This is a big problem for me, because the main package I work on is > > dependent upon Hadoop. > > > > What's the state of Hadoop in Fedora these days? Are there packaging > > problems? Not enough support from upstream Apache community? Missing > > dependencies in Fedora? Not enough time to work on it? No interest from > > users? > > > Looks like packages it depended on were orphaned, almost a year ago (?) > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BTYJNZV5LKLJYS2QZDSVX3CRECNLERTV/ > > Forgive me, but I have a really hard time parsing those massive reports (especially when they appear in an active list like this). But, it looks like that was due to erlang-jsx being orphaned, which affected libthrift-java, which affected accumulo and a bunch of others. It looks like erlang-jsx was picked back up, and in any case, I'm pretty sure it was an optional dependency of libthrift-java, so it could have been fixed by the thrift developer (by dropping erlang support) even if erlang-jsx was dropped. So, I don't think that report a year ago caused the situation we're in today. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Hadoop?
On Thu, Jun 2, 2016 at 5:33 PM gil wrote: > > > Il 02/06/2016 23:20, Chris Murphy ha scritto: > > On Thu, Jun 2, 2016 at 3:03 PM, Christopher > wrote: > >> So, it would seem at some point, without me noticing (certainly my > fault, > >> for not paying attention enough), the Hadoop packages got orphaned > and/or > >> retired? in Fedora. > >> > >> This is a big problem for me, because the main package I work on is > >> dependent upon Hadoop. > >> > >> What's the state of Hadoop in Fedora these days? Are there packaging > >> problems? Not enough support from upstream Apache community? Missing > >> dependencies in Fedora? Not enough time to work on it? No interest from > >> users? > > > > Looks like packages it depended on were orphaned, almost a year ago (?) > > > > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BTYJNZV5LKLJYS2QZDSVX3CRECNLERTV/ > > > no, cause of nc6 motivation: "2016-05-31: Retired orphaned package, > because it was orphaned > more than six weeks." > .g > > Ugh. Wish I had noticed. Is there a quick way to get it unretired? It's still an essential dependency of some packages which are not retired, or even orphaned. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Hadoop?
On Fri, Jun 3, 2016 at 1:35 AM Till Maas wrote: > On Fri, Jun 03, 2016 at 02:25:19AM +0000, Christopher wrote: > > > Ugh. Wish I had noticed. Is there a quick way to get it unretired? It's > > still an essential dependency of some packages which are not retired, or > > even orphaned. > > I tried to assign nc6 and hadoop to you but pkgdb seems to be not > properly working right now. If it does not work or if you need > additional packages, please file a ticket at the releng trac and > specify which packages you need for which branches. Packages can be > unretired for two weeks after their retirement without any re-review. > > Kind regards > Till > I also tried to unretire in pkgdb, but it resulted in an error. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Hadoop?
On Fri, Jun 3, 2016 at 7:38 AM gil wrote: > > > Il 03/06/2016 13:20, Christopher ha scritto: > > I also tried to unretire in pkgdb, but it resulted in an error. > have you open a rel-eng ticket as suggested before? > regards > .g > -- > devel mailing list > devel@lists.fedoraproject.org > https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > Ugh, I never see your email's because they always go to Spam. I've never opened a rel-eng ticket before. Is that on Trac as well? And, do you know of a previous similar situation I could use as a template? I'm bad at requesting things with the right degree of explanation. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Hadoop?
On Fri, Jun 3, 2016 at 4:33 PM Christopher wrote: > On Fri, Jun 3, 2016 at 7:38 AM gil wrote: > >> >> >> Il 03/06/2016 13:20, Christopher ha scritto: >> > I also tried to unretire in pkgdb, but it resulted in an error. >> have you open a rel-eng ticket as suggested before? >> regards >> .g >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >> > > Ugh, I never see your email's because they always go to Spam. > > I've never opened a rel-eng ticket before. Is that on Trac as well? And, > do you know of a previous similar situation I could use as a template? I'm > bad at requesting things with the right degree of explanation. > Disregard. I see your other email, also found in spam folder :( -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Netcat
So, I'm trying to understand what's going on with netcat. If anybody can enlighten me, I'd appreciate it. Here's what I've found so far: It looks like rpms/nc was retired due to being orphaned for too long. It looks like the same thing (almost) happened to rpms/nc6. I think netcat is too important a tool to leave out of Fedora, and I'm willing to maintain it. I took ownership of nc6, because it was a dependency of hadoop. However, it looks like it was an unnecessary Requires that could just be removed. I checked upstream and nc6 looks like it was discontinued because nc now supports IPv6 (according to nc6 docs). I haven't yet been able to confirm whether the command lines are compatible, though, and Fedora packages/users could simply switch over to using nc if they were previously using nc6. The last information I found about nc on this mailing list is that nc was obsoleted by nmap-ncat. Can anybody tell me if this is accurate? Am I just giving myself a headache for no reason? Should nc and nc6 simply be dropped entirely? Thanks. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
i686 failures
I'm trying to revive rpms/hadoop, but am running into some failures[1] on i686 in koji that I cannot reproduce locally in x86_64. The thing is... I don't really have any good 32-bit environment to test this locally. Hadoop isn't really suitable for 32-bit architectures (IMO) and I doubt it's a well-tested upstream arch. Any suggestions for how I should proceed? Is it really necessary that *all* packages support i686 arch, even when it doesn't make sense for the application's users? [1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=14521689 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: i686 failures
On Thu, Jun 16, 2016 at 7:40 PM Mat Booth wrote: > On 16 June 2016 at 20:16, Christopher wrote: > >> I'm trying to revive rpms/hadoop, but am running into some failures[1] on >> i686 in koji that I cannot reproduce locally in x86_64. The thing is... I >> don't really have any good 32-bit environment to test this locally. Hadoop >> isn't really suitable for 32-bit architectures (IMO) and I doubt it's a >> well-tested upstream arch. >> >> Any suggestions for how I should proceed? Is it really necessary that >> *all* packages support i686 arch, even when it doesn't make sense for the >> application's users? >> >> [1]: http://koji.fedoraproject.org/koji/taskinfo?taskID=14521689 >> >> -- >> devel mailing list >> devel@lists.fedoraproject.org >> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org >> >> > > Actually nothing to do with arch, all arches would fail, it just failed on > i686 first and koji cancelled the others ;-) > > The maven-jar-plugin was updated to new version in Fedora, which has this > new behaviour, but the error message should be self-explanatory: "You have > to use a classifier to attach supplemental artifacts to the project instead > of replacing them." It is due to the jar:jar goal being executed twice for > the same artifact for some reason. Try eliminating the second invocation > from the pom file of the broken module. > > Yeah, I saw that error message and behavior, but I thought I might be able to rule out the possibility that it was a simple maven problem, since it built perfectly fine locally in mock. I figured it might be a problem with maven executing different tasks under different arch's, but didn't have a way to easily test a 32-bit arch locally to reproduce. I'll try playing with fedpkg mock-config to see if I can do a mock build with i686 arch locally. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Netcat
On Fri, Jun 17, 2016 at 9:20 AM Nico Kadel-Garcia wrote: > On Thu, Jun 16, 2016 at 3:31 PM, Stephen John Smoogen > wrote: > > On 16 June 2016 at 14:23, Xose Vazquez Perez > wrote: > >> Christopher wrote: > >> > >>> So, I'm trying to understand what's going on with netcat. If anybody > can > >>> enlighten me, I'd appreciate it. Here's what I've found so far: > >> > >> Original netcat is obsolete, try socat or nmap-ncat. > > > > I don't think this was the original netcat but had been replaced by > > the openbsd version a long time ago. > > Yes. I believe you are right. It looks like nc was the openbsd version, and nc6 was a fork of that? In either case, it seems they aren't needed, due to nmap-ncat. > Want me to ask the netcat author? i'll probably see him on Saturday. > > I admit that I find the simplicity of netcat's user interface to be > much more graceful than socat's feature filled but excess complexity. > I agree, but it looks like both nc and nc6 are more directly replaced by nmap-ncat. Presumably it adopts at least some of the simplicity of the prior incarnations of netcat. My conclusion: nc and nc6 should be retired. One thing I noticed was that nc and nc6 are listed in comps (security-lab group), but I'm not sure the packages even exist in f24. I guess that'll have to be fixed for a proper retirement (instead of the orphan->6weeks->retire path they went through). -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: i686 failures
On Thu, Jun 16, 2016 at 4:45 PM gil wrote: > > > Il 16/06/2016 22:32, Dan Horák ha scritto: > > On Thu, 16 Jun 2016 19:16:38 +0000 > Christopher wrote: > > > I'm trying to revive rpms/hadoop, but am running into some failures > [1] on i686 in koji that I cannot reproduce locally in x86_64. The > thing is... I don't really have any good 32-bit environment to test > this locally. Hadoop isn't really suitable for 32-bit architectures > (IMO) and I doubt it's a well-tested upstream arch. > > Any suggestions for how I should proceed? Is it really necessary that > *all* packages support i686 arch, even when it doesn't make sense for > the application's users? > > how i wrote before is a problem related to newer maven-jar-plugin release > if you run also for x64 build should fails > > add this instruction: > %pom_xpath_inject > "pom:plugin[pom:artifactId='maven-jar-plugin']/pom:executions" " > > default-jar > skip > " [PATH OF THE POM FILE WHERE HAPPEN THE FAILURE] > > Thanks! This makes sense. I still don't understand why it didn't fail for me locally (x86_64), but this should fix it regardless. (Note to self: add rule to Gmail so I don't have to keep fishing gil's email out of spam folder.) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
(retire nc6) never retired a package before
Hi all, I've never retired a package before, so I'm trying to figure out my way through it for nc6. Background: * nc was properly obsoleted by nmap-ncat, and retired (though, it hasn't been removed from comps entirely) * nc6 should also be obsoleted by nmap-ncat with nc, but it never was. Instead it was just orphaned, so I took it (before I fully understood the situation). What I'm wondering is: Which branch should I retire this in, and work with nmap packager to add an Obsoletes line for nc6? Just master/rawhide? Or all branches? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: (retire nc6) never retired a package before
On Mon, Jun 20, 2016 at 5:02 PM Peter Robinson wrote: > > I've never retired a package before, so I'm trying to figure out my way > > through it for nc6. > > > > Background: > > > > * nc was properly obsoleted by nmap-ncat, and retired (though, it > hasn't > > been removed from comps entirely) > > * nc6 should also be obsoleted by nmap-ncat with nc, but it never was. > > Instead it was just orphaned, so I took it (before I fully understood the > > situation). > > > > What I'm wondering is: > > > > Which branch should I retire this in, and work with nmap packager to add > an > > Obsoletes line for nc6? Just master/rawhide? Or all branches? > > So you should add Provides, not just obsoletes to ensure a clean > upgrade between releases. Also ensure that any packages have their > dependencies to require the replacement, this just looks to be hadoop > and qt-virt-manager. > > Thanks. I'll file a bug with nmap to add Provides/Obsoletes, since I'm not a maintainer on that. I'm working on hadoop, and qt-virt-manager looks like they've already addressed it. > On branches, once a release is out you can't block a package, you can > push updates to other packages that obsolete/provide it so it's > replaced but because the f24 (as an example) is locked it'll always be > there, so you should just retire it in rawhide (master in the fedpkg > checkout) with a "fedpkg retire 'retirement message details'". > > Okay, cool. I've retired the package in rawhide, then. Still need to submit pull request to update comps. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Unsorted comps
So, I'm trying to follow the retire instructions to retire nc6 and update comps, and I noticed a discrepancy between the instructions for updating the comps, and the actual state of the comps files. Running the xsltproc command at https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups always results in a different/re-sorted/de-duplicated version of the comps file. Every version of the file I've checked (f19+) is plagued with duplicates and out-of-order entries. Is this normal? Should somebody just go in and do a quick cleanup of all the files, or is there a reason they are being preserved in a state which doesn't match the instructions on the wiki? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
fedora-packager installs yum
Installing fedora-packager pulls in yum as a dependency. Is this expected on a system built around dnf and without yum already installed? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Looking for a proven packager
On Thu, Jun 30, 2016 at 4:35 AM Peter Robinson wrote: > On Thu, Jun 30, 2016 at 9:30 AM, Igor Gnatenko > wrote: > > First thing you should do is to send your patch upstream. If upstream > > will say "it's good patch", I will help you to get it in Fedora before > > upstream will release new version. Unfortunately it's not possible in > > other way. > > In the hadoop case it might not be valid to do that as the version in > Fedora is quite out of date compared to upstream. > > Fedora's version may be out of date, but I suspect that this particular part of Hadoop's code is not fast moving, and would still be relevant to even their latest versions. At the very least, it's worth an attempt to contact them upstream first. I do have an interest in updating Fedora's packaged version of Hadoop, and if the patch is good, it'd be nice to have it in upstream so we don't have to keep it around when we move to the newer version. So, even if they aren't willing to support the patch for our version, if they're willing to support it in any of their latest supported versions, I'd be fine keeping the backported patch until we upgrade. As I said in the BZ, I just don't have the expertise to evaluate the patch myself to know if it's good or if it's going to cause problems. A +1 from upstream, a proven packager, or the secondary arch team, would be sufficient for me. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: wiki editing changes
On Sat, Jul 16, 2016, 15:47 Kevin Fenzi wrote: > In order to prevent these spam wiki edits entirely, we have changed the > wiki to require a user to have both signed the FPCA and be in at least > one additional group (CLA+1). This may require some workflow changes > for a few groups such as Fedora Ambassadors. New contributors without > any group membership will need a path to membership without wiki edits. > Would it make sense to create an extra group for wiki editors so vetted people can make documentation improvements without extra involvement? > -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Did something change with ssh-agent in F24?
Previously in F23, an ssh-agent was running when I started a gnome session. I believe (perhaps incorrectly) that this was being provided by gnome-keyring-daemon. Now, it appears that one isn't running. When I type "ssh-add -L", I get the message: "Could not open a connection to your authentication agent." Is this an expected change in behavior with F24, or is it a bug which I should file? (Note, there are a few bugs for F23 open about ssh-agent and gnome-keyring, but they appear to be unrelated, and I had no problems in F23). If it is a bug, what can I do to troubleshoot for when I file a bugzilla? An interim solution is to launch ssh-agent, but it's somewhat less convenient. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Did something change with ssh-agent in F24?
On Wed, Jul 20, 2016 at 6:24 AM Jakub Jelen wrote: > On 07/20/2016 12:44 AM, Christopher wrote: > > Previously in F23, an ssh-agent was running when I started a gnome > > session. I believe (perhaps incorrectly) that this was being provided > > by gnome-keyring-daemon. > It was not ssh-keygen, but gnome-keyring: > > jjelen2082 0.0 0.0 609108 8052 ?Sl Jul19 0:00 > /usr/bin/gnome-keyring-daemon --daemonize --login > > Just checked my friends F24 and it is running there. It should be > started by the > > /etc/xdg/autostart/gnome-keyring-ssh.desktop > > Check that you have the file in place, the gnome-keyring installed. > > Weird. It's working now. It was odd, because gnome-keyring-daemon was running at the time, and the gpg-agent it provides was also working, but the ssh-agent part was not. But now, they're both working. So... I don't know what happened. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: GPG2 as default /usr/bin/gpg
On Thu, Jul 21, 2016 at 8:31 PM Brian C. Lane wrote: > On Thu, Jul 21, 2016 at 07:57:47PM -0000, Christopher Tubbs wrote: > > This is still causing me headaches. GPG2 switched away from the > secring.gpg file, and now I have multiple tools using different files for > storing my credentials. And, depending on which command I use (sometimes I > slip and use gpg instead of gpg2), I import stuff to the wrong keyring, and > I can't find it later. > > > > That, combined with the fact that the gpg command doesn't use > gnome-keyring-daemon's gpg-agent without some extra ENV setup, and the git > bug from earlier in the thread, this is getting pretty annoying. > > > > Users can't uninstall gnupg and only use gnupg2, either, because > important stuffs depend on it, like anaconda, initial-setup, libblockdev-*, > monkeysphere, hplip, volume_key-libs (no idea why those last two should, > but they do). > > > > Being able to use alternatives without messing with package files which > are likely to get clobbered on update, would be nice, at the very least. > > > > But really, I think it's time to transition, since there's no technical > reason why one should be using gnupg1 these days. > > > > We could transition in this way: > > > > 1. Have packages depend on gnupg2 instead. > > 2. Rename gnupg to gnupg1 > > 3. Make gnupg a meta-package which depends on gnupg2 and sets up > alternatives. > > 4. Make gpg1 lower priority in alternatives than gpg2 for /usr/bin/gpg > > 5. Don't install gnupg by default. > > I don't see the point. Switching because you accidentally type the wrong > thing isn't a valid reason. > > That wasn't the only reason given. The other reasons include: * It doesn't provide anything that gpg2 doesn't already provide * It doesn't properly integrate with gnome-keyring-daemon or the default behavior of gpg-agent to use the "standard socket" out of the box, creating a bad user experience * It introduces unnecessary inconsistencies in where keys are stored, again creating a bad user experience when trying to execute commands to display stored keys * There isn't a good mechanism provided for switching between the two, and one cannot uninstall gpg without removing some important things which depend on it > Upstream still ships and supports gpg, people (like me, the gpg > maintainer) still use it instead of gpg2 for various things. Until > upstream stops shipping it, or renames it, it should continue to be > called gpg. > > I don't see a problem with continuing to ship it, but because of the bad user experience with lack of using the "standard socket" and the inconsistency in where it stores keys, it probably shouldn't be the default. > If you want gpg2, type gpg2. Problem solved and everyone is happy :) > > Not everyone. See above thread... I'm not the only one who thought we should move, and others cited precedents for packaging gpg2 as gpg from other downstream maintainers. I'm not arguing for complete removal... I'm just arguing for a change in the default, and a packaging strategy which takes advantage of the alternatives system, to give users a better way to choose, for a better overall out-of-the-box user experience. Essentially, gpg2 obsoletes gpg upstream... even if upstream continues to support it. So, why not move? Given the bad user experience, it seems to me that the argument for keeping it as is should be somewhat more than sticking with the status quo. Can you please explain why my proposal isn't a good compromise which addresses the problems above, and still provides folks the option to use gpg1? Is there a technical reason? Thanks. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Orphaned packages seeking new point of contact
On Fri, Jul 29, 2016 at 1:23 PM Kevin Fenzi wrote: > > js-jquery1 (el5) > js-jquery1 (el6) > js-jquery1 (epel7) > js-jquery1 (f23) > js-jquery1 (f24) > js-jquery1 (f25) > js-jquery1 (master) > js-jquery (el5) > js-jquery (el6) > js-jquery (epel7) > js-jquery (f23) > js-jquery (f24) > js-jquery (f25) > js-jquery (master) > > I've taken these because I'll need them as dependencies. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Please Mark bz#1164414 for EPEL7
Can somebody please reopen and appropriately mark the following bug for EPEL7, so it doesn't get auto-closed on new Fedora releases? Thanks. https://bugzilla.redhat.com/show_bug.cgi?id=1164414 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Please bump bz#1017603 to F24
Can somebody please re-open and bump https://bugzilla.redhat.com/show_bug.cgi?id=1017603 to F24. The bug was auto-closed because it was marked for F22. I've taken the package for newer Fedora versions, but cannot update bugs marked for older Fedora versions which were auto-closed, because I don't have permission. (Permission can't even be granted for F22, because it's EOL, so I can't ask an admin on the older branches.) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please bump bz#1017603 to F24
On Fri, Aug 19, 2016 at 2:31 PM Kevin Fenzi wrote: > On Fri, 19 Aug 2016 18:25:49 + > Christopher wrote: > > > Can somebody please re-open and bump > > https://bugzilla.redhat.com/show_bug.cgi?id=1017603 to F24. The bug > > was auto-closed because it was marked for F22. I've taken the package > > for newer Fedora versions, but cannot update bugs marked for older > > Fedora versions which were auto-closed, because I don't have > > permission. (Permission can't even be granted for F22, because it's > > EOL, so I can't ask an admin on the older branches.) > > Done, but any packager should be able to change the status and version, > so not sure why it wouldn't let you. > > Thanks. Interesting... it still won't give me the drop-down box to be able to change it. It's weird, because I can change https://bugzilla.redhat.com/show_bug.cgi?id=1308662 I had assumed it was because of the lack of admin on the older branch, but if all packagers should be able to do this, then I'm not sure why it doesn't work for me. Another one I can't bump is https://bugzilla.redhat.com/show_bug.cgi?id=1289919 but I'm not a maintainer or reporter on that one, so I expected that. Is the rule perhaps something like "assignee OR reporter"? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please Mark bz#1164414 for EPEL7
On Fri, Aug 19, 2016 at 7:41 PM Chris Murphy wrote: > On Fri, Aug 19, 2016 at 5:37 PM, Dominik 'Rathann' Mierzejewski > wrote: > > On Saturday, 20 August 2016 at 01:30, Chris Murphy wrote: > >> On Fri, Aug 19, 2016 at 12:18 PM, Christopher > >> wrote: > >> > Can somebody please reopen and appropriately mark the following bug > for > >> > EPEL7, so it doesn't get auto-closed on new Fedora releases? Thanks. > >> > > >> > https://bugzilla.redhat.com/show_bug.cgi?id=1164414 > >> > >> When product is changed to Fedora EPEL, there is no gnome-desktop > >> component option. Only gnome-desktop-sharp. There's also gnome-common. > > > > As mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=1164414#c2 , > > gnome-desktop exists in RHEL7/CentOS7 as gnome-desktop3. The report is > > invalid and should be closed as such. > > Ahh OK, so notabug? Invalid is not an option. > > Ah, my mistake. I was under the impression that it was missing, because related to gnome-python2-desktop ( https://bugzilla.redhat.com/show_bug.cgi?id=1177390) which contains gnome-python2-gnomekeyring. Maybe gnome-python2-desktop can be built with gnome-desktop3? Not sure I understand GNOME packaging interdependencies yet, but I miss my old python keyring library. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please Mark bz#1164414 for EPEL7
On Sat, Aug 20, 2016 at 8:16 AM Michael Catanzaro wrote: > On Sat, 2016-08-20 at 02:07 +0000, Christopher wrote: > > Ah, my mistake. I was under the impression that it was missing, > > because > > related to gnome-python2-desktop ( > > https://bugzilla.redhat.com/show_bug.cgi?id=1177390) which > > contains gnome-python2-gnomekeyring. Maybe gnome-python2-desktop can > > be > > built with gnome-desktop3? Not sure I understand GNOME packaging > > interdependencies yet, but I miss my old python keyring library. > > Hi, > > I'd never heard of it before now, but I looked into it briefly out of > curiosity. Turns out gnome-python2-desktop (called gnome-python-desktop > upstream) contains old-style manual Python bindings to various old > GNOME 2 stuff. These have all been obsoleted for a very long time by > PyGObject; the upstream git repo was archived five years ago. It's > totally unrelated to gnome-desktop3 (called gnome-desktop upstream), > which is an important GNOME module that just happens to have a > confusingly-similar name. > > gnome-python2-gnomekeyring in particular contains old bindings for the > gnome-keyring library, which is also long deprecated. The modern way to > access the keyring is to use libsecret via PyGObject: > > https://lazka.github.io/pgi-docs/#Secret-1 > > Michael > > libsecret won't work. It's a higher level abstraction and I need to look at the GnomeKeyring attributes directly. You can do this with the old gnome-python2-gnomekeyring library, but the new GnomeKeyring (python-gobject/python3-gobject) returns a GLib.Array object for the attribute list, and I can't figure out any way to inspect the attributes from that in python (and it looks like I'm not the only one[1]). [1]: http://stackoverflow.com/a/25642221/196405 -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bash style guide on Fedora?
On Mon, Aug 22, 2016 at 10:01 AM Jun Aruga wrote: > Hi, > > We can see several bash (= sh on Fedora) script files under /etc such as > /etc/init.d/functions > /etc/profile > > Anyone could you tell me whether there is a common style guideline (coding > standards) to write the shell script on Feodra? > > Thanks, > Jun Aruga > > I'm not familiar with one, but I'd recommend using shellcheck on them to detect potential issues. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: bash style guide on Fedora?
On Mon, Aug 22, 2016 at 11:17 AM Dominique Martinet < dominique.marti...@cea.fr> wrote: > Jun Aruga wrote on Mon, Aug 22, 2016 at 10:36:48AM -0400: > > shellcheck? you mean "sh -n something.sh"? Yes, I will do it too :) > > He does mean shellcheck[1]. > > It's nice; doesn't do style check (e.g. trailing spaces or whatsnot) > but catches quite a lot of errors. > > > [1] https://www.shellcheck.net/ > Yes, this is the shellcheck[1] I meant, but it's also just packaged for Fedora: $ sudo dnf install ShellCheck $ shellcheck myscript.sh -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please bump bz#1017603 to F24
On Tue, Aug 23, 2016 at 2:26 AM Mikolaj Izdebski wrote: > On 08/19/2016 09:51 PM, Christopher wrote: > > Interesting... it still won't give me the drop-down box to be able to > > change it. > > It's weird, because I can change > > https://bugzilla.redhat.com/show_bug.cgi?id=1308662 > > I had assumed it was because of the lack of admin on the older branch, > but > > if all packagers should be able to do this, then I'm not sure why it > > doesn't work for me. Another one I can't bump is > > https://bugzilla.redhat.com/show_bug.cgi?id=1289919 but I'm not a > > maintainer or reporter on that one, so I expected that. > > > > Is the rule perhaps something like "assignee OR reporter"? > > AFAIK, any member of "fedorabugs" FAS group (including you) should be > able to edit any Fedora bug (unless it's a private bug). > > Maybe it's a web browser glitch? You can try command-line interface. > > Nope. Not just a UI glitch. Command-line doesn't work either: $ bugzilla --ensure-logged-in modify --version=25 1308662 # works $ bugzilla --ensure-logged-in modify --version=25 1017603 # fails Server error: -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please bump bz#1017603 to F24
On Wed, Aug 24, 2016 at 7:40 PM Kevin Fenzi wrote: > On Wed, 24 Aug 2016 22:06:15 + > Christopher wrote: > > > On Tue, Aug 23, 2016 at 2:26 AM Mikolaj Izdebski > > wrote: > > > > > On 08/19/2016 09:51 PM, Christopher wrote: > > > > Interesting... it still won't give me the drop-down box to be > > > > able to change it. > > > > It's weird, because I can change > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1308662 > > > > I had assumed it was because of the lack of admin on the older > > > > branch, > > > but > > > > if all packagers should be able to do this, then I'm not sure why > > > > it doesn't work for me. Another one I can't bump is > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1289919 but I'm not a > > > > maintainer or reporter on that one, so I expected that. > > > > > > > > Is the rule perhaps something like "assignee OR reporter"? > > > > > > AFAIK, any member of "fedorabugs" FAS group (including you) should > > > be able to edit any Fedora bug (unless it's a private bug). > > > > > > Maybe it's a web browser glitch? You can try command-line interface. > > > > > > > > Nope. Not just a UI glitch. Command-line doesn't work either: > > > > $ bugzilla --ensure-logged-in modify --version=25 1308662 # works > > $ bugzilla --ensure-logged-in modify --version=25 1017603 # fails > > > > Server error: > 24 to 25, but only the assignee or reporter of the bug, or a user > > with the required permissions may change that field.'> > > There was something odd with your bugzilla account, it wasn't in the > correct groups and I am not sure why. > > However, I added them to your account, so it should work now. Can you > try again and confirm it's working? > Works perfectly now. I didn't expect it to be one of those "just me" problems. I just assumed that's how it was supposed to work. Thanks for following up and fixing. :) -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: OCB blockcipher mode - is it allowed?
On Sat, Aug 27, 2016 at 6:16 PM Igor Gnatenko wrote: > Hi, > > I have some questions about OCB[0] and it's usage in Fedora. > > I wanted to package pycryptodome[1] and found that they implement OCB > in their code. From my POV (completely without any legal knowledge) it > seems that it's not completely free[2] as it's not allowed for > military use. It seems to be allowed without any restrictions only for > OpenSSL. > > What do you think? Looks like now we have mosh[3] packaged and it > includes OCB (so if it's not acceptable, it most probably should be > removed). > > > [0] http://web.cs.ucdavis.edu/~rogaway/ocb/ > [1] https://pycryptodome.readthedocs.io/en/latest/ > [2] http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm > [3] https://mosh.org > -- > -Igor Gnatenko > > I'm not a lawyer, but it seems to me that OCB is available to be implemented under 4 different license options: 1. Any open source software licensed under an approved license by OSI or public domain. 2. General license for non-military use. 3. OpenSSL-specific use. 4. Special license from the patent owner. Only option 2 has the non-military restriction, and anything in Fedora would almost certainly fall under 1 or 3. So, I can't imagine there'd be a problem using the OCB patent in Fedora software. I'm actually not even sure why option 3 even exists, since it seems to be a subset of option 1. Regardless, it doesn't look like the non-military restriction of option 2 would apply if option 1 is used. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Please Mark bz#1164414 for EPEL7
On Sun, Aug 21, 2016 at 1:49 AM Christopher wrote: > On Sat, Aug 20, 2016 at 8:16 AM Michael Catanzaro > wrote: > >> On Sat, 2016-08-20 at 02:07 +0000, Christopher wrote: >> > Ah, my mistake. I was under the impression that it was missing, >> > because >> > related to gnome-python2-desktop ( >> > https://bugzilla.redhat.com/show_bug.cgi?id=1177390) which >> > contains gnome-python2-gnomekeyring. Maybe gnome-python2-desktop can >> > be >> > built with gnome-desktop3? Not sure I understand GNOME packaging >> > interdependencies yet, but I miss my old python keyring library. >> >> Hi, >> >> I'd never heard of it before now, but I looked into it briefly out of >> curiosity. Turns out gnome-python2-desktop (called gnome-python-desktop >> upstream) contains old-style manual Python bindings to various old >> GNOME 2 stuff. These have all been obsoleted for a very long time by >> PyGObject; the upstream git repo was archived five years ago. It's >> totally unrelated to gnome-desktop3 (called gnome-desktop upstream), >> which is an important GNOME module that just happens to have a >> confusingly-similar name. >> >> gnome-python2-gnomekeyring in particular contains old bindings for the >> gnome-keyring library, which is also long deprecated. The modern way to >> access the keyring is to use libsecret via PyGObject: >> >> https://lazka.github.io/pgi-docs/#Secret-1 >> >> Michael >> >> > > > libsecret won't work. It's a higher level abstraction and I need to look > at the GnomeKeyring attributes directly. You can do this with the old > gnome-python2-gnomekeyring library, but the new GnomeKeyring > (python-gobject/python3-gobject) returns a GLib.Array object for the > attribute list, and I can't figure out any way to inspect the attributes > from that in python (and it looks like I'm not the only one[1]). > > [1]: http://stackoverflow.com/a/25642221/196405 > > I don't suppose anybody here knows how to read the GArray in python to get the attributes list for a keyring item in GnomeKeyring? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Mozilla enabled ads in Firefox and they're active in Fedora
On Sat, Nov 15, 2014 at 9:34 AM, Rejy M Cyriac wrote: > On 11/15/2014 07:43 PM, Reindl Harald wrote: > > > > Am 15.11.2014 um 15:06 schrieb Kevin Kofler: > >> Lars Seipel wrote: > >>> What does the community think of it? Is it okay for our flagship > >>> applications to carry ads and report tracking data? > >> > >> No! > >> > >> IMHO, we should consider dropping Firefox from Fedora entirely, in > >> favor of > >> Epiphany for Workstation and Midori for the Spins (except the KDE Spin > >> which > >> already ships Konqueror as the browser) > > > > NO! > > > > * i don't see that crap at all > > * even if i could disable it (or maybe have it in about:config) > > * i want to use Firefox for thousand reasons > > > > it's *not* freedom to remove Firefox > > freedom would be make it not default but still offer it > > > > > > > +1 > > Disabling the ADs feature from firefox, if that is possible, would be > the right move for Fedora. > > We also could lobby mozilla to re-consider this decision. > > +1 > -- > Regards, > > Rejy M Cyriac (rmc) > -- > 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: Mozilla enabled ads in Firefox and they're active in Fedora
On Sat, Nov 15, 2014 at 5:41 PM, Johannes Lips wrote: > > > On Sat, Nov 15, 2014 at 6:56 PM, Christopher > wrote: > >> On Sat, Nov 15, 2014 at 9:34 AM, Rejy M Cyriac >> wrote: >> >>> On 11/15/2014 07:43 PM, Reindl Harald wrote: >>> > >>> > Am 15.11.2014 um 15:06 schrieb Kevin Kofler: >>> >> Lars Seipel wrote: >>> >>> What does the community think of it? Is it okay for our flagship >>> >>> applications to carry ads and report tracking data? >>> >> >>> >> No! >>> >> >>> >> IMHO, we should consider dropping Firefox from Fedora entirely, in >>> >> favor of >>> >> Epiphany for Workstation and Midori for the Spins (except the KDE Spin >>> >> which >>> >> already ships Konqueror as the browser) >>> > >>> > NO! >>> > >>> > * i don't see that crap at all >>> > * even if i could disable it (or maybe have it in about:config) >>> > * i want to use Firefox for thousand reasons >>> > >>> > it's *not* freedom to remove Firefox >>> > freedom would be make it not default but still offer it >>> > >>> > >>> > >>> +1 >>> >>> Disabling the ADs feature from firefox, if that is possible, would be >>> the right move for Fedora. >>> >>> We also could lobby mozilla to re-consider this decision. >>> >>> >> I don't really understand the issue at all. We also don't have any > problems offering google or any other search engine with our default > configuration in firefox. But if a truly open-source foundation implements > something to generate some revenue, which will most probably help the > development of open source software, it suddenly becomes a big deal? > > I think the main difference is that it collects personal data and gives that information to for-profit companies, as a default configuration, without a user first "opting in" to that sort of data sharing. It is supposedly sanitized of user-identifying information, but a user should be given the option of deciding whether that sanitization is sufficient for them. Yes, Mozilla is "open source", but that's not the same as "free software" in every sense of the word, and people are wanting more from their free software, such as better control over their personal data, and the idea of privacy is working its way into some definitions of "free". I don't necessarily see any reason to lobby Mozilla to change their decision... I think it's fine for them to do what they are doing. They might be welcome to a suggestion to include an installer/download option to give their direct download users some better controls over this feature (if they haven't done so already). But for Fedora, I think it makes sense to disable it by default, and if that is done, I don't see any issue. If Mozilla had a "first use" setup option to control this feature, then I would even say that it's not needed for Fedora to even bother doing anything. So, maybe that's something that could be brought up with Mozilla (if it doesn't already exist). > > >> +1 >> >> >>> -- >>> Regards, >>> >>> Rejy M Cyriac (rmc) >>> -- >>> 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 >> > > > -- > 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: Mozilla enabled ads in Firefox and they're active in Fedora
On Sun, Nov 16, 2014 at 6:46 AM, Mustafa Muhammad < mustafaa.alhamda...@gmail.com> wrote: > On Sat, Nov 15, 2014 at 4:25 PM, Lars Seipel > wrote: > > So Mozilla has recently gone live with its advertisement tiles on the > > "New Tab" page. Only newly created profiles get to see this stuff. > > > > On a pristine F21 install using Gnome, when first launching Firefox, > > users are presented with a number of tiles, depending on screen size. > > One of those is a so-called "sponsored" tile chosen from a range of > > available advertisements (e.g. for booking.com, there's also one for the > > Snowden movie), apparently depending on geographical location. > > > > When this "feature" got originally announced[1], there was a discussion > > on -devel if this kind of stuff is really appropriate for Fedora. > > > > Some time later Mozilla seemed to have canceled the feature, quoting > > "That’s not going to happen. That’s not who we are at Mozilla." as one > > of the reasons[2]. > > > > Apparently, they (again) reconsidered, pushing the feature to nightlies > > a few months ago. Well, it now hit the stable branch and, therefore, > > Fedora. > > > > This is how Mozilla pitches the feature to advertisers[3]: > > > >> To support ad personalization, Mozilla created an internal data system > >> that aggregates user information while stripping out personally > >> identifiable information. Mozilla can track impressions, clicks, and the > >> number of ads a user hides or pins. Its advertising partners are also > >> privy to that data. > > > > Personally, I don't think that showing advertisements on the free > > software desktop is appropriate. Our users are supposed to be able to > > fully trust our software. That's one of our most-often touted strenghts. > > I don't think the ability to "track impressions, clicks, and the number > > of ads a user hides or pins" is something that is compatible with that, > > regardless of this data being tied to "personally identifiable > > information" or not. > > > > Firefox's behaviour is probably nothing extraordinary on the other > > platforms Mozilla is targeting. Compared to the prevalent attitude of > > proprietary vendors, especially on mobile, it doesn't sound that bad > > anymore. I don't think that's a suitable scale for Fedora, though. > > > > From a user perspective, it's not that hard to disable the feature. Upon > > first seeing that page a tooltip is shown to hint at the possibility. > > Users can choose between three modes, "Enhanced", "Classic" and "Blank". > > Contrary to what is stated in the Mozilla kb[4], the only one that > > actually disables the ads is "Blank", which is equal to setting the new > > tab page to about:blank. > > > > What does the community think of it? Is it okay for our flagship > > applications to carry ads and report tracking data? > > > > [1] > > > https://blog.mozilla.org/advancingcontent/2014/02/11/publisher-transformation-with-users-at-the-center/ > > [2] > > https://blog.mozilla.org/futurereleases/2014/05/09/new-tab-experiments/ > > [3] > > > http://www.adexchanger.com/online-advertising/mozilla-finally-releases-its-browser-ad-product-hints-at-programmatic-in-2015/ > > [4] > > > https://support.mozilla.org/de/kb/how-do-tiles-work-firefox#w_enhanced-tiles > > -- > > devel mailing list > > devel@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/devel > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > The "ads" are not intrusive, they don't collect personally > identifiable data, and can be disabled with a selection from a button > on the start page! > See: > > http://www.pcworld.com/article/2848017/how-to-get-rid-of-firefoxs-new-ads-on-the-new-tab-page.html > > I think the best way is to ship Firefox as is, if somebody doesn't > want to help the open source project generating some revenue using > these ads, he can disable them. > > The framing of the concerns expressed here as people not wanting to contribute back and help an open source project with revenue (through this mechanism or otherwise), does not reflect the concerns raised. The concerns raised are that the default configuration is an "opt-out" vs. "opt-in" model of Firefox issuing network calls back to Mozilla's servers, and Fedora's user base expects "opt-in" for these sorts of things. It's not about not being willing to help the project out... it's about not being able to vet that method of helping out prior to it taking place. > When you use Google search engine in any browser, it is collecting > more data than this feature in Firefox. > > This doesn't seem relevant to this discussion, unless Fedora browsers are automatically, and without the user's explicit knowledge or permission, navigating to Google's search engine, which (AFAICT) they are not. > If you want to disable them, disable them in the default configuration > we ship, nothing more is needed. > +1, disabling it by default in Fedora's packaging seems to make the most
