Re: RFC: retiring yum

[Pete Travis]

On Sep 1, 2017 4:54 PM, "Kai Bojens"  wrote:

On Friday, 1 September 2017 21:30:44 CEST Matthew Miller wrote:

> RPM specfile changelogs are often of interest to systems
> administrators.

Agreed. Before I update a huge number of hosts I'd like to check the
changelogs for any possible trouble. This is the the main thing I miss in
dnf
right now.


+1, as a system administrator I often use repoquery or the yum plugin to
get changelogs.  This is especially useful when demonstrating that a
particular CVE has been mitigated in a given envr.  Utility that enables
compliance is very valuable for my use case.

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

Re: OpenVPN, OpenSSL and Fedora 26+

[Pete Travis]

On Apr 27, 2017 3:13 PM, "David Sommerseth"  wrote:

On 27/04/17 01:20, Dominik 'Rathann' Mierzejewski wrote:
> On Wednesday, 26 April 2017 at 21:18, David Sommerseth wrote:
>> On 26/04/17 17:08, Lee Howard wrote:
>>> On 04/25/2017 01:39 PM, David Sommerseth wrote:
 This is actually just a very late heads-up about challenges with
OpenVPN
 in Fedora 26.

 Fedora is moving towards OpenSSL v1.1, which is in my opinion a sane
and
 good step forward.  Unfortunately, that gives OpenVPN a real challenge.
 The OpenSSL v1.1 support is not completed.  Patches have been sent to
 the upstream devel mailing list for review, but only half of them have
 been processed and applied so far.

 So, to be able to provide OpenVPN in Fedora 26 it was decided to switch
 to mbed TLS instead of OpenSSL (which OpenVPN also supports).  That
have
 revealed several issues:
>
> Thanks a lot for the write-up, David. Can you make sure this ends up
> in the release notes?

Sure ... I've never done that before, any pointers to how I can make
that happen?


--
kind regards,

David Sommerseth


File a PR or issue at https://pagure.io/release-notes and I'll follow up on
it.  An issue would be best at the moment, there's a bit of prep work to do
for the F26 branch.

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

Re: future of official optical media support in Fedora

[Pete Travis]

On Dec 15, 2016 08:09, "Matthew Miller"  wrote:

On Thu, Dec 15, 2016 at 07:31:29AM -0500, Neal Gompa wrote:
> > This is interesting. Does IPMI also allow you boot from a "remote
> > USB device"?
> Not any of the servers I've worked with. Only remote DVD boot. I've
> never heard of anyone being able to do remote USB or disk device, as I
> think the ability to write over the network is considered not
> desirable...

IBM Bladecenters can mount USB images remotely — although that's just a
disk image file, same as you can do with an .ISO. No physical media
involved in either case.


--
Matthew Miller

Fedora Project Leader



All the DRAC/iLO/BMC systems I play with these days mount a remote ISO and
present it as optical media. The feature is basically only used for
emergencies where regular networking won't do, like when I want the normal
network environment for the process and don't want to bother the network
folks to change routing and vlans in realtime.

Definitely an edge case, but I'm fairly sure that an image that won't boot
from physical optical media also will not boot this way.  It would be more
important for RHEL users than Fedora users, I assume.

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

Re: upstream dev. asks suggestions about howto make packagers work easier (bundled libraries, etc.)

[Pete Travis]

On Nov 20, 2016 1:49 AM, "Germano Massullo" 
wrote:
>
> We often deal with upstream developers that bundle libraries in their
> code, so to make a package we have to debundle them, etc.
> This time, an upstream dev. asked me what he could do to make easier
> the work of packagers.
> In this case the software is python-netjsongraph [1] that bundles
> javascript-d3 library and that is being reviewd at [2]
>
> I think it would be nice to make a discussion even for non Python
> packages, so we can elaborate a sort of vademecum that a packager
> could show to upstreams when there is a collaboration between them.
>
> Have a nice day
>
>
> [1]: https://github.com/interop-dev/django-netjsongraph
> [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1369213

For Python packages, my biggest complaint is when versioned dependencies
are explicitly declared without due diligence.  Rough example: Upstream
foobar developer gets foo-24.2 from pip, sets foo == 24.2 in their
requirements.  Fedora currently packages foo-21.8; foo usage doesn't change
for 18.0 < foo < 34.0 .  Add in 1-12 other dependencies, and I'm doing a
lot more manual work when updating foobar because upstream's declared
requirements simply are not useful in a distribution packaging context.

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

Re: /sbin/nologin in /etc/shells

[Pete Travis]

On Sep 30, 2016 05:17, "Toby Goodwin"  wrote:
>
> As a member of the "remove nologin from /etc/shells" faction, I have 2
> technical reasons for my position. I don't think either of these points
> have been addressed by the "leave it in" faction.
>
> 1. Certain programs use pam_shells to check access, but without requiring
> that the shell is able to run commands. So far I've found vsftpd and
> proftpd, and I'd expect all ftp daemons to follow suit. With nologin in
> /etc/shells, these programs will grant access to nologin users. I find
this
> behaviour "surprising". In general it's better for security features to
> default to the least permissive setting.
>

I suspect a lot of admins rely on this behavior to configure users that
have FTP access, but not shell access.  FTP does not provide a shell
session.   Aside, please stop using legacy FTP, sftp via sshd does the job
securely and the distinction is more or less transparent to the user.

> 2. It's often been said...shoot yourself in the foot,
> but I can't think of anything else a normal user can do that's quite as
> simple and drastic as "chsh -s /sbin/nologin".
>
> I have been trying to be sympathetic to the arguments from the other side,
> but so far have not seen any that hold water.
>
> 1. As originally proposed [1], the change of adding nologin to /etc/shells
> was to allow it to be set with chsh. But in modern Fedora root is allowed
> to do so anyway, and I don't think it's a bug that normal users cannot
> permanently lock themselves out in this way.
>
> 2. Can anyone provide further detail on the "Shell variable pre-load
> attack" mentioned in that original ticket? It's surely far too old to be
> the "Shellshock" bug.
>
> 3. Stephen J Smoogen raised the issue of government / bank audit rules
[2].
> I was nearly swayed by this argument: it's outside my area of expertise,
> and in general I'd be supportive of changes to help those that have to go
> through such processes. But the actual page he linked to [3] quite clearly
> allows nologin to be omitted from /etc/shells.
>

Admins and auditors will expect the options for user shells to be listed in
/etc/shells.  /sbin/nologin is a valid option for a user's default shell.
I don't see the problem here.

> How can we take this forwards? Who would have the authority to take a
> decision on the issue?
>

Almost certainly FESCo.  Impact to dependent software aside, compliance
audits tend to be tedious and rote verification of a checklist, and the
list does often address /etc/shells.  IMO disruption of those expectations
does warrant a Change proposal.

> [1] https://bugzilla.redhat.com/show_bug.cgi?id=53963#c0
> [2]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SR76Q2ZTGQDJREEMC2AE53JC4PQZISLQ/
> [3]
https://www.stigviewer.com/stig/vmware_esxi_v5/2013-01-15/finding/GEN002140-ESXI5-46
>
> Toby.
> ___
>

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

Re: Re-review to unretire package: python-nikola

[Pete Travis]

On Jul 6, 2016 9:59 AM, "Igor Gnatenko"  wrote:
>
> On Wed, Jul 6, 2016 at 2:13 PM, José Abílio  wrote:
> > Hi,
> Hi,
> > I have submitted python-nikola to unretire the package for
rawhide since
> > it is available in the other branches.
> Link to review request?
> >
> > A review swap is welcome.
> >
> > Regards,
> > --
> > José Abílio
> > --
>
>
>
> --
> -Igor Gnatenko
> --

Hey Jose, I saw your other mail about this but procrastinated responding.
Thanks for resurrecting the package, I will take the review unless Igor
gets there first.

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

Re: Preparing a new release of Fedora Developer Portal - asking for feedback

[Pete Travis]

This might also be interesting for Docs people.

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

Re: 3D printing SIG

[Pete Travis]

On Mar 17, 2016 11:14 AM, "Miro Hrončok"  wrote:
>
> On 17.3.2016 16:08, Miro Hrončok wrote:
>>
>> Hi Fedorains,
>>
>> I was thinking about creating a 3D printing SIG in Fedora. Would anyone
>> be interested in that?
>>
>> Miro
>
>
> I've created a wiki page here:
>
> https://fedoraproject.org/wiki/SIGs/3DPrinting
>
> Feel free to add yourselves and improve the page in any way.
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
>
> --
>

I've been gathering parts for some time, and would definitely be interested
in the results from a SIG, thanks Miro!  Probably not much time to
contribute beyond documentation I'm already doing, but that could be
improved with some guidance.

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

Re: F24 Self Contained Change: Let's Encrypt client now in Fedora

[Pete Travis]

On Feb 10, 2016 6:29 AM, "Josh Boyer"  wrote:
>
> On Tue, Feb 9, 2016 at 11:32 AM, Jared K. Smith
>  wrote:
> >
> > On Mon, Feb 8, 2016 at 10:55 PM, Neal Gompa  wrote:
> >>
> >> And aren't we supposed to *not* do stuff like this
> >> anymore?
> >
> >
> >
> > If I had to guess, I'd say that this was proposed as an F24 change to
help
> > it get publicity in the release notes, etc.
>
> Changes are not used for that purpose.  It is expressly the reason we
> decided to stop calling them Features.  Changes focus on the technical
> content and impact for communication with Fedora developers.  There's
> nothing in this one that other developers really need to know about on
> a project wide scale.
>
> If someone wants to market something, they should be working with the
> docs and marketing teams directly.
>
> josh
> --

FWIW, to get attention for a new package in the release notes process, you
can simply set the review ticket's fedora_requires_release_notes flag to ?.

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

Re: Attempting to contact unresponsive maintainers - lnovich ooprala and vjancik

[Pete Travis]

On Feb 14, 2016 2:07 PM, "Kevin Fenzi"  wrote:
>
> On Sun, 14 Feb 2016 09:59:18 +
> "Richard W.M. Jones"  wrote:
>
> > On Thu, Feb 04, 2016 at 10:06:58PM +, Richard W.M. Jones wrote:
> > > On Thu, Feb 04, 2016 at 01:34:28PM -0700, Kevin Fenzi wrote:
> > > > Greetings, we've been told that the email addresses
> > > > for these package maintainers are no longer valid.  I'm starting
> > > > the unresponsive maintainer policy to find out if they are still
> > > > interested in maintaining their packages (and if so, have them
> > > > update their email addresses in FAS).  If they're not interested
> > > > in maintaining or we can't locate them I'll have FESCo orphan the
> > > > packages so that others can take them over.
> > > >
> > > > If you have a way to contact these maintainers, please let them
> > > > know that we'd appreciate knowing what to do with their packages.
> > > > Thanks!
> > > >
> > > > lnovich:
> > > >
> > > > default_assignee
> > > >  - virtualization-administration-guide (Fedora Documentation)
> > > >  - virtualization-deployment-and-administrative-guide (Fedora
> > > >Documentation)
> > >
> > > I forwarded this message to Laura's new address.  Will follow up if
> > > I get a response.
> >
> > Laura says she has no time to work on Fedora packaging.  The packages
> > can be orphaned.  I'll see if I can get our new documentation manager
> > to pick them up.
>
> ok. Note that these are docs, not packages... I can ask Fedora Docs
> folks too if there's someone else who might want to own them.
>
> kevin

I've changed the default assignee for Laura's components over to the Docs
list, the group will take responsibility for now.

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

Re: Urgent F23 testing request: logout bugs

[Pete Travis]

On Oct 21, 2015 11:13 AM, "Adam Williamson" 
wrote:
>
> Hi folks!
>
> So we're building 23 Final RC2 now, but we have a couple of outstanding
> proposed blocker bugs, and we could use some more data to evaluate
> them.
>
> The way to test is really simple:
>
> * Install F23 Final TC11 Workstation or KDE live[1]
> * Create a user and log in
> * Log out a bunch of times. Just keep logging in and out.
>
> Ideally try this both in a VM and on a real system, if you have a spare
> system to test on.
>
> There are two bugs that you might hit:
>
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1272737
> 2. https://bugzilla.redhat.com/show_bug.cgi?id=1273247
>
> With the first one, the system gets stuck at a black screen after
> logging out. You won't be able to switch to a TTY or anything, but if
> you have another system, you'll find that ssh'ing in still works. So
> far it seems this bug *only* affects Workstation (we believe it
> involves Wayland, and Workstation has GDM-on-Wayland). It seems easy to
> reproduce in a KVM, harder to reproduce on a real system, but some
> testers have reproduced it on a real system after several attempts.
> We're particularly interested in whether you hit it on a real system,
> and if so, how often.
>
> With the second bug, assuming you don't hit the first bug, the cursor
> disappears on the login screen, possibly after you click somewhere
> (e.g. the password text entry box). Roshi says he sees something like
> this on Workstation but not KDE, kparal says he sees it on KDE but not
> Workstation, and I can't reproduce it on either. This one is probably
> only reproducible in a KVM, but of course let us know if you manage to
> trigger it on a real system!
>
> If you could report back to the list what configuration you tested on,
> and whether and how often you managed to reproduce either bug, that
> would be a great help. For virtual machine testing, please let us know:
>
> * What virtualization system you used (KVM/virt-manager is preferred)
> * For a KVM:
>   ** Whether your VM has a virtual 'tablet' input device (one
>  is often created by default, so check in virt-manager)
>   ** What video adapter and viewer you're using (e.g. qxl/SPICE or
>  std/VNC)
>   ** What OS and release is running on the host system
>   ** The graphics adapter and driver being used on the host system
>
> Thanks!
>
> [1] Downloads:
>
https://dl.fedoraproject.org/pub/alt/stage/23_TC11/Workstation/i386/iso/Fedora-Live-Workstation-i686-23-TC11.iso
>
https://dl.fedoraproject.org/pub/alt/stage/23_TC11/Workstation/x86_64/iso/Fedora-Live-Workstation-x86_64-23-TC11.iso
>
https://dl.fedoraproject.org/pub/alt/stage/23_TC11/Live/i386/Fedora-Live-KDE-i686-23-TC11.iso
>
https://dl.fedoraproject.org/pub/alt/stage/23_TC11/Live/x86_64/Fedora-Live-KDE-x86_64-23-TC11.iso
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
>
> --

I have a laptop with missing mouse cursor issues on various DEs, and have
considered issues logging out of GNOME routine for quite some time... will
follow up later on today after reviewing the bugs' applicability.

--Pete
-- 
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 of PlayOnLinux

[Pete Travis]

On 10/15/2015 12:55 AM, drago01 wrote:
> On Wed, Oct 14, 2015 at 5:46 PM, Bastien Nocera  wrote:
>>
>> - Original Message -
>>> Dne 14.10.2015 v 16:50 Bastien Nocera napsal(a):
 If the application cannot work without downloading anything, or being
 supplied
 third-party (sometimes proprietary) applications, then it's closer to an
 emulator than a front-end that's generally useful.
>>> The guidelines speaks about *dependencies*.
>>> https://fedoraproject.org/wiki/Packaging:Guidelines#Packages_which_are_not_useful_without_external_bits
>>>
>>> I think that the idea behind this wording was "runtime dependencies". To 
>>> deny
>>> application which can not even run without
>>> those proprietary deps.
>>> PlayOnLinux is mainly for games, but you can run any Windows program using
>>> that. Even Gimp or Firefox (I could not
>>> remember program which does not have native linux version and is free).
>>> So it may not be useful for you, but it can be useful for somebody else.
>>>
>>> For me PlayOnLinux is much closer to virt-manager.
>>>
 And emulators aren't allowed in Fedora.
>>> What?
>>> You mean like Wine, all those terminal emulators, QEMU, atari++, hercules,
>>> fuse-emulator and lots of others?
>> The ones listed here:
>> https://fedoraproject.org/wiki/Licensing:SoftwareTypes?rd=Licensing/SoftwareTypes
> Wel the reason is not "because they are emulators" but "If it requires
> ROMs (or image files in any format) of copyrighted or patented
> material to be useful (and the owners of those copyrights and patents
> have not given their express written permission), then it's not
> permitted. " ... so "emulators aren't allowed is not what the
> guidelines say" (the wording is a bit odd though).
>
> As for PlayOnLinux its nothing more than a WINE frontend. So there
> shouldn't be anything wrong with packing it. You can use it it run
> free / freeware windows apps or windows apps (games) that you actually
> bought and therefore you do not violate anyone's copyright by using
> them.

My understanding - which is welcome to correction - is that the WINE
community, and presumably therefore utilities like PlayOnLinux, rely on
using specific versions of wine, often with specific patch sets, for
each application  or game.  Many of these patches never make it upstream
because they are not applicable in the broader sense.   That's rather
complicated stuff, and PlayOnLinux solves the problem by defining those
versions and patches and bundling them up for the user.

The greater feasibility question IMO is whether it is even possible for
PlayOnLinux to be effective when using system wine, and if not, whether
the package can be built in a guidelines-compliant way when it bundles
and patches this way.  Jirka, have you put together a spec yet, as a
proof of concept?

-- Pete
-- 
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: ansible in Fedora 23+ (python3)

[Pete Travis]

On 10/14/2015 07:47 AM, Matthew Miller wrote:
> On Tue, Oct 13, 2015 at 08:57:57PM -0700, Adam Williamson wrote:
>> Beyond that, though, why not just have your ansible play ensure its own
>> deps are installed? If you're dealing with docker, make sure the
>> package you need is installed before you run any docker steps...
> So, in other words, it seems acceptible to make this a documentation
> problem? We should at least definitely make sure to have that
> documentation.
>

I haven't poked at this yet, but can add it to the release notes.  Can
someone confirm that at least the dnf module works out of the box?

-- Pete
-- 
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 available for new point of contact

[Pete Travis]

On Sep 10, 2015 4:24 AM, "Mathieu Bridon"  wrote:
>
> On Thu, 2015-09-10 at 11:16 +0200, Matěj Cepl wrote:
> > On 2015-09-09, 19:37 GMT, Kevin Fenzi wrote:
> > > pytz
> > > python-dateutil
> >
> > I see these two as too important to let them fall, so I am
> > taking them. However, I would really really like to have some
> > co-maintainers, because I don’t feel like I really understand
> > the matter.
>
> Give acls to the python-sig group?
>
>
> --
> Mathieu
> --
>

Please do.  There was expressed interest in this when we did the 1.x -> 2.x
rollover last release; I meant to dig up references for a reply but the
conversation for ahead.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Release Notes: Wiki Freeze Looming

[Pete Travis]

Hello Fedora packagers,

During each release cycle, the Fedora Release Notes are drafted on the
wiki[0].  This public draft space allows contributors to easily share
info on their work for the upcoming release.  Later in the release
cycle, these wiki pages are frozen and converted into Docbook XML for
publishing to docs.fp.o.

The wiki freeze will happen next Tuesday, September 8th.  Please take
some time to note anything you think might be significant or different
for Fedora users.  There will be writers doing the conversion, so don't
stress about the prose - getting us started is a big help.

If you'd like to propose content for after the freeze, reach out to
d...@lists.fedoraproject.org or #fedora-docs.

-- Pete Travis
   Fedora Docs Project Lead

[0] https://fedoraproject.org/wiki/Category:Documentation_beats
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

create-tx-configuration retirement

[Pete Travis]

I am re-retiring create-tx-configuration.  I kept it around after Sparks
retired it in case we needed it for the transition away from transifex, and
that's done, and we didn't.

-- Pete
-- 
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: Sponsors - who does (not) work on FE-NEEDSPONSOR tickets

[Pete Travis]

On Aug 17, 2015 10:07 AM, Marcin Haba marcin.h...@bacula.pl wrote:

 Hello,

*snip*

 I am not going to continue this discussion because as I wrote in
 previous mail, it was only feedback from my side. It is not my intention
 to gain something by this feedback. It is just feedback to potential
 consideration if it is useful.

 Thanks.

 Best regards.
 Marcin Haba

This is the misunderstanding.  Your feedback is welcome and helpful, that's
how the Fedora community operates.  Someone might debate with you, but that
is how ideas change and grow.

If you are sharing your experience, and sharing your progress, you *should*
expect to gain something from it.  The theme of the thread is about
improving that experience for you, the prospective packager.  I encourage
you to start a new, public thread detailing your progress and goals.

(And I apologize if you've already done that.  Part of the problem is that
activity on both sides is not easily discoverable, so you might have to
help sponsors discover your efforts.  That's not begging for special
attention, only participating in the process.)

--Pete
-- 
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: Validity of i686 as a release blocker

[Pete Travis]

On Aug 4, 2015 9:40 AM, Paul W. Frields sticks...@gmail.com wrote:

 On Tue, Aug 04, 2015 at 09:47:27AM -0400, Josh Boyer wrote:
 [...snip...]
  Perhaps it is time that we evaluate where i686 stands in Fedora more
  closely.  For a starting suggestion, I would recommend that we do not
  treat it as a release blocking architecture.  This is not the same as
  demotion to secondary architecture status.  That has broader
  implications in both buildsys and ecosystem.  My suggestion is
  narrowly focused so that builds still proceed as today, but if there
  is something broken for i686 it does not block the release of whatever
  milestone we are pursuing.
 
  (To be clear, I would support a move to secondary arch status for
  i686, but I am not suggesting it at this time.)

 So to put a finer point on this, our shipping i686 images depends on a
 broader community effort beyond the kernel maintainers in the Fedora
 Engineering team.  That needs to precisely not mean more heroics on
 the part of e.g. QE, rel-eng, etc.  I have no idea what the pushback
 on this issue is, but I'm sure this thread will tell us.  But given
 that Fedora is supposed to encourage such community effort, it would
 be good to see what people are willing to do to build it.

  Making i686 non-release blocking would actually match reality.  None
  of the Fedora Editions appear at all concerned with i686.  Cloud is
  demoting[3] i686 from its offering.  Workstation has been fairly
  ambivalent about it and recommends x86_64.  Server does the same.
  Given the lack of focus on it, and the fact that the broader community
  is not testing the development releases for i686, I believe this would
  be a good first step.

 Ambivalent is probably understated here.  It's hard to imagine
 people securing i686 hardware these days to run a Workstation
 experience, after all.

  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1247382
  [2]
https://lists.fedoraproject.org/pipermail/devel/2015-February/208368.html
  [3] https://fedorahosted.org/cloud/ticket/106

 --
 Paul W. Frieldshttp://paul.frields.org/
   gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
   http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
 The open source story continues to grow: http://opensource.com
 --


Perhaps the best approach, from a community perspective, would be to
promote a spin to Edition status and recommend *that* for i686 or low
resource desktop use cases.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Test-Announce] Fedora 23 Release Notes are Open!

[Pete Travis]

Hello Fedora,

The Fedora 22 release cycle is in full swing, and beats have been opened
for the F22 Releasae Notes.  Over the coming weeks, the release notes
for the next version of Fedora will be assembled by Docs team writers,
packageers, developers, and community members of all forms.

Yeah, that's a pretty broad group.  You can help - not a figurative,
abstract you, but you, reader, can personally contribute to this fine
periodical publication.  Not a technical writer?  That's OK!  The most
difficult part is the initial prep and research, and that's where we can
use you the most.  Here are some examples of ways you could contribute:

- You maintain a package, and are able to update it to the next major
version for F23.  The new version has some long-awaited features added
that users would enjoy.  To signal the Docs team to write a bit about
these changes, you open the release monitoring bugzilla ticket and check
the fedora_requires_release_note flag.  We can take it from there, but
please be available for follow up questions!

- You subscribe to a mailing list (one? who is this guy?) and a
discussion reveals some notable change in a component of Fedora. While
mailing lists are discoverable, the archives aren't one's first stop, so
you forward the thread to a dedicated mailing list,
relnotes-cont...@lists.fedoraproject.org.  Like all Fedora's lists,
you must subscribe to send - but don't worry, we'll watch the approval
queue.

- As a contributor to Fedora QA, you are were one of the earliest
adopters of Fedora 23 as a daily driver.  While testing packages and
generally going about your business, you find that something has
changed; the syntax or location of a config file, perhaps, or maybe the
user experience of your favorite media player.  Drop a note into the
wiki at https://fedoraproject.org/wiki/Category:Documentation_beats and
some writers will come along to write the prose and share it with the world.

- You're an active member of a SIG.  There are some exciting changes and
additions to the packages supported by your SIG.  It could be a new
skychart from Astronomy, or a new mapping client from GIS, or new
applications and features on the XFCE spin.  You drop in to #fedora-docs
on Freenode to hash it out with the Docs team (there's almost always
someone there, but you might have to wait a bit for the first reply.)

I'm getting long-winded now, but there's one point I want to stress.
Note that none of these options said anything like Write comprehensive,
gramatically correct documentation in American English that is ready for
publication.   If you want to participate to that degree, great!  If
not, don't be dissuaded.  It's a huge help to have leads and requests
thrown into the funnel, there are writers waiting to take it the rest of
the way.
-- 
-- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org



signature.asc
Description: OpenPGP digital signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-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: F23 Self Contained Change: Netizen Spin

[Pete Travis]

On May 18, 2015 7:34 AM, Jan Kurik jku...@redhat.com wrote:

 I am sorry for the wrong subject of my previous post. This is a Self
Contained Change, not a System Wide.

 Regards,
 Jan

 - Original Message -
  From: Jan Kurik jku...@redhat.com
  To: devel-annou...@lists.fedoraproject.org
  Sent: Monday, May 18, 2015 2:26:55 PM
  Subject: F23 System Wide Change: Netizen Spin
 
  = Proposed Self Contained Change: Netizen Spin =
  https://fedoraproject.org/wiki/Changes/Netizen_Spin
 
  Change owner(s):  Corey Leong cleong at fedoraproject dot org
 
  A Fedora Spin for promoting and supporting internet citizenship and
citizen
  engagement.
 
  == Detailed Description ==
  Fedora Netizen is an open source operating system for enabling internet
  citizens to engage with online services and communities. The goal for
  Netizen is to pattern the operating system's features after Maslow's
  Hierarchy of Needs which was published in his 1943 paper, A Theory of
Human
  Motivation. As a professor of pyschology, Abraham Maslow theorized that
  individuals attempt to experience five stages of needs starting with
  physiological, safety, social, esteem, and then ending with
  self-actualization. Beginning with the first level of physiological
needs,
  individuals' motivational needs ascend upwards to higher levels of
needs in
  order, however, only after establishing lower levels of needs first
before
  ascending to the next level.
 
  The philosophy for Netizen closely relates to Maslow's Hierarchy of
Needs by
  establishing three primary software package levels in a hierarchical
model.
  The first and lowest software package level addresses the need for
Netizen
  Privacy in the areas of personal privacy, informational privacy, and
  communication privacy. After Netizen Privacy, the second software
package
  level addresses the need for Netizen Security in the areas of data
security,
  local security, and network security. After Netizen Security, the third
  software package level addresses the need for Netizen Engagement in the
  areas of publishing, education, and social engagement.
 
  Future Netizen software package levels will address analytics,
awareness,
  design, develop, and others.
 
  == Scope ==
  A Netizen theme is the final requirement to be developed per marketing
  department support of a look and feel in order to replace the current
  default theme. This is an isolated change.
  * Other developers: N/A (not a System Wide Change)
  * Release engineering: Add spin to spin-kickstarts, ensure spin has been
  tested, and release with rest of spins
  * Policies and guidelines: N/A (not a System Wide Change)
 
  --
  Jan Kuřík
 ___

A spin is a big effort with many interoperating packages and coordination
with other teams (primarily releng, but you should also seek guidance from
QA).  It qualifies as a System Wide Change.

--Pete
-- 
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 replacing yum and dnf-yum

[Pete Travis]

On Apr 13, 2015 5:07 AM, Radek Holy rh...@redhat.com wrote:


 

 From: Pete Travis li...@petetravis.com
 To: Development discussions related to Fedora 
devel@lists.fedoraproject.org
 Sent: Friday, April 10, 2015 5:31:08 PM
 Subject: Re: dnf replacing yum and dnf-yum



 On Apr 10, 2015 4:39 AM, Radek Holy rh...@redhat.com wrote:
 

 
  Hm, I think that it depends on the use case. AFAIK, distro-sync is
mostly used to upgrade Fedora (an unsupported approach AFAIK) and to
replace some testing/3rd-party versions of package with the official
ones. (BTW, I'd appreciate if anyone will share their use case) While in
the first case, I think that the upgrade's behaviour is preferred, in the
other case, the install's behaviour is better IMO. (Which dangerously
indicates that the --skip-broken switch is a good solution :( )
 
  Anyway, file an RFE (if it isn't filed already) please. We can
track/discuss it there.
 
  Thank you in advance
  --
  Radek Holý
 

 (lots of trimming, and skipping an RFE, as this just pertains to the
distro-sync use case question)

 distro-sync is useful for getting to a sane state after temporarily
enabling some repo that interacts with the primary ones.  This can happen
with third party repos, but we can consider an entirely in-house situation:

 The user finds a bug in widget-2.5.7 and reports it.  A fix for widget
is shipped and the user is asked to test via `dnf update widget
--enablerepo updates-testing`.  The transaction pulls in many requires from
updates-testing (although at this point, I realize dnf may not be upgrading
the requires in this transaction if they are not versioned).  The new
widget is tested, life goes on.

 Later, the user wants to install or update some package whizbang that
shares requires with widget.  That package has versioned requires on
packages from the updates repo, but some of the installed packages are from
updates-testing and don't provide what whizbang needs.

 Something like `dnf --allowerasing install whizbang` might be the
appropriate and precise tool to get through that transaction.  `dnf
distro-sync` is the less precise, big-hammer tool for the user that doesn't
know or care to track down the intricacies of widget and whizbang
dependencies.   They ran some command from a bug report a while ago and
moved on, and now they run distro-sync to return their system to a
known-good state and move on.

 This sort of thing is most common during the prerelease cycle, when
users will have updates-testing on then off, and there are freezes, and
branching, and lots of activity that might leave early adopters in an
unsane state.

 And yeah, it is very useful for upgrades.  Even when ran after a proper
fedup upgrade.

 --Pete


 Yeah, that's basically what I meant by 'replace some testing versions of
package with the official ones'. Anyway, thank you for elaborating on it.
I'll definitely make a test case from it.

 I'd like to let those doing the actions described above know that there
is also a not very well known command dnf repository-packages repoid
remove-or-distro-sync which is specifically designed for switching from
packages installed from testing/3rd-party repositories
 --
 Radek Holý
 Associate Software Engineer
 Software Management Team
 Red Hat Czech

 --

Nice! That's repoid as the stable/updates repo, not the
testing/3rd-party/problem repo, right? I'll add this to my dnf writeup.

--Pete
-- 
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: askbot-setup command not found

[Pete Travis]

On Mar 23, 2015 7:20 AM, Pete Travis li...@petetravis.com wrote:


 On Mar 23, 2015 3:58 AM, Kalpani Anuradha anuradha...@cse.mrt.ac.lk
wrote:
 
  Thank you Suchakra, Corey Sheldon and Ankur Sinha for the support. And
after viewing the AskFedora Redesign Plan my interest to contribute towards
this project further increased.
 
  As initial work to get involved in the GSoC project AskFedora UX/UI 
Functionality, I'm trying to install Askbot and get familiarized with its
code.
 
  I refered the project documentation at
http://askbot.org/doc/install.html in installing Askbot and followed the
steps of installation by cloning the code from the development repository.
 
  But after the following appears,
 
  *
 
  Thanks for installing Askbot.
  To start deploying type: askbot-setup
 
  *
 
  when typed the askbot-setup command, I get an error saying the command
was not found. I searched the internet and found that some others also have
had the same problem but I could not find any proper solution.
 
  Can someone please help me with this? ( I have Python version 2.6
installed in my machine )
 
  Thank you
  Anuradha Welivita
 
  --

 What version of askbot and Fedora are you using? `rpm -q askbot` will
help, share the output.

Oops, sorry, I see you are working from upstream git.  Perhaps askbot-setup
is present but not in your user's $PATH ?

--Pete
-- 
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: askbot-setup command not found

[Pete Travis]

On Mar 23, 2015 3:58 AM, Kalpani Anuradha anuradha...@cse.mrt.ac.lk
wrote:

 Thank you Suchakra, Corey Sheldon and Ankur Sinha for the support. And
after viewing the AskFedora Redesign Plan my interest to contribute towards
this project further increased.

 As initial work to get involved in the GSoC project AskFedora UX/UI 
Functionality, I'm trying to install Askbot and get familiarized with its
code.

 I refered the project documentation at http://askbot.org/doc/install.html
in installing Askbot and followed the steps of installation by cloning the
code from the development repository.

 But after the following appears,

 *

 Thanks for installing Askbot.
 To start deploying type: askbot-setup

 *

 when typed the askbot-setup command, I get an error saying the command
was not found. I searched the internet and found that some others also have
had the same problem but I could not find any proper solution.

 Can someone please help me with this? ( I have Python version 2.6
installed in my machine )

 Thank you
 Anuradha Welivita

 --

What version of askbot and Fedora are you using? `rpm -q askbot` will help,
share the output.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 Self Contained Change: Disabled Repositories Support

[Pete Travis]

On Mar 17, 2015 5:18 AM, Jan Zelený jzel...@redhat.com wrote:

 On 16. 3. 2015 at 15:52:10, Jaroslav Reznik wrote:
  = Proposed Self Contained Change: Disabled Repositories Support =
  https://fedoraproject.org/wiki/Changes/DisabledRepoSupport
 
  Change owner(s): Richard Hughes rhughes at redhat dot com
 
  The Software tool and PackageKit now support disabled repositories to
help
  users locate software in additional repositories which are not meant to
be
  enabled by default.
 
  * This Change is announced after the Change Submission Deadline as an
  exception to the process. May not be approved for proposed Fedora
release. *
 
  == Detailed Description ==
  This feature aims to reduce the technical hurdles for users and
developers
  to locate software packaged for a distribution, but which needs to be
  clearly identified as not officially included (or possibly sanctioned)
by
  that distribution.
 
  When Software (via PackageKit) queries a repo definition that contains
the
  line enabled_metadata=1, even if the repo is disabled, it will download
  repodata. This feature allows a user to locate software in response to a
  search. If the user wants to install the software, she receives a dialog
  with information that the repo must be enabled to satisfy the request,
and
  if relevant, information about the nature of the software (for
instance, if
  it is non- libre).
 
  N.B. This feature does not currently operate in Fedora, since no such
repo
  definitions are currently shipped. However, the feature could be used by
  remixers, and in the future in Fedora in the event of a policy change.
 
  == Scope ==
  * Proposal owners: Include enhancements in gnome-software/PackageKit
(done)
  * Other developers: N/A (not a System Wide Change)
  * Release engineering: N/A (not a System Wide Change)
  ** Note: For this feature to be used in Fedora requires an additional *-
  release-extra package to ship disabled repo definition
  * Policies and guidelines: N/A (not a System Wide Change)
  ** Note: For this feature to be used in Fedora requires clearer approval
  from FESCo and the Council

 I wonder, are there any implications for dnf in terms of being consistent
with
 the new behavior of Gnome Software? I realize that people using dnf have
more
 options than people using Gnome Software (--enablerepo for instance) but
this
 sounds like the beginning of the end of disabled repositories.

 Personally, I don't like the semantics of these semi-disabled repos. It
beats
 the purpose of disabling the repos in the first place, doesn't it? I mean
I
 don't get why user would specify enabled_metadata=1 when he can achieve
almost
 the same result with disabled=0 (the only difference I can see is one
 additional popup dialog). Or is there something I'm missing?

 Thanks
 Jan
 --

As I understand it, the intent is to provide the user with the experience
of third party software being included in Fedora, while still complying
with the third party repository policy and communicating to the user that
it comes from somewhere else.

As I understand it, the council stance is that each repo must be a
self-contained piece of software, and each individual repo must have
explicit council approval to be included,  with a mandate for furthering
Fedora's mission and an expectation of permissive licensing.  In that
context, I guess I'm ok with the compromise.

jreznik, what about cycling these approvals through the Change process, but
instead of going to Fesco, the tickets go to the council?  That would allow
a sufficient amount of community scrutiny and signal, IMO.  The Change
template would only need to be modified slightly, probably not more than
current interpretations do.

--Pete
-- 
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: Is there a process for requesting packaging?

[Pete Travis]

On Mar 7, 2015 6:15 AM, Kevin Fenzi ke...@scrye.com wrote:

 On Sat, 07 Mar 2015 10:53:27 +0100
 fed...@activityworkshop.net wrote:

  Hi list,
 
  I'm an upstream developer and I'm unfamiliar with the Fedora
  processes, so my apologies if I'm asking obvious questions or asking
  in the wrong place!

 Not at all. This is a fine place. ;)

  I've seen lots of pages about how to become a Fedora packager, and
  the processes for reviewing packages, but I haven't yet found
  anything suggesting how I could go about _requesting_ whether an
  already experienced Fedora packager might like to adopt another
  package.  Is there such a thing, or is the only option that I dive
  into learning how to do it myself?

 There is a generic 'wishlist':
 https://fedoraproject.org/wiki/Package_maintainers_wishlist

 But as you can see from looking at it, its kind of a big dumping ground
 of anything anyone anytime thought might be nice to have packaged. ;)

  To be specific, I would be interested in submitting the GPL2 java
  application GpsPrune for inclusion.  It's already in Debian, so
  maybe that's a good starting point.  And there are unofficial rpms in
  OpenSuse, which may also be helpful.  There are only a small number
  of dependencies, most of which are optional, and I would be more than
  happy to help from my side to tweak things if necessary.
 
  I believe that if there were packagers who had already created
  packages for java applications, and were willing to take on another
  one, it would take orders of magnitude less effort than if I were to
  try to do it myself and ask for it to be reviewed.  Is there a way to
  submit a request for packaging?

 I'd suggest mailing the Fedora Java sig:
 https://lists.fedoraproject.org/mailman/listinfo/java-devel

 You may also get some interest here in further replies. ;)

 Hope that helps,

 kevin


 --

The GIS SIG might be interested in this too.  There's no dedicated mailing
list that I'm aware of, but http://fedoraproject.org/wiki/GIS will lead you
to #fedora-gis and a list of names, at least.

--Pete
-- 
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: Why sysrq is limited to only sync command on official fedora kernel?

[Pete Travis]

On Feb 25, 2015 1:50 PM, Reindl Harald h.rei...@thelounge.net wrote:



 Am 25.02.2015 um 21:38 schrieb Zdenek Kabelac:

 Dne 25.2.2015 v 18:44 Reindl Harald napsal(a):


 Am 25.02.2015 um 18:37 schrieb Paul Wouters:

 On Wed, 25 Feb 2015, Lennart Poettering wrote:

 Hmm? Syncing is allowed to my knowledge. C-a-d and gdm allow a clean
 reboot/poweroff. But sysrq does an abnormal reboot/poweroff, which we
 cannot allow. Similar, remounting read-only is also security senstive,
 which we cannot allow.

 Without being logged in there's very little you can do on a host right
 now, and sysrq should not open up more there by default.


 You must have forgotten your university days

 The alternative to not being able to sync-umount-boot using sysrq is to
 flip the switch. I'd rather have them use sysrq.

 I said it when they closed X ctrl-alt-backspace and I'll say it now.
 When you are on console with the power plug, preventing these actions
 is stupid


 when you are on a machine where you have pysical only keyboard and
 mouse it is
 not - not every PC stands in front of your face - think about kiosk
 mode and
 so on...


 When I read such answers - I always wonder myself - how many kiosk ever
 run Fedora...

 It's such a bad idea to optimize Fedora for one-in-milion users and
 those 999.999 has to suffer instead of require 1 guy to configure more
 secure version


 you can be sure that the need for sysrq is the one-in-milion users just
because i am a *heavy user* with a lot of setups and used it 4 times in the
past 12 years while restricted it to kernel.sysrq = 20 long before the
systemd change

 it's such a bad idea to *not* optimize out-of-the box for security

 the ones which don't care can disable it, most won't care, nor have a
need nor do they even know about a lot of things - this users are also not
in the position to fix bad security defaults because they have no idea
about it


 --


The only time I've needed sysrq reboots in recent memory was while running
rawhide and knowingly venturing into uncharted territory.  If I'm not the
only one, would it make sense to include appropriate sysctl snippets in
fedora-release-rawhide ?

--Pete
-- 
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: Packages

[Pete Travis]

On 02/26/2015 11:06 AM, Rahul Sundaram wrote:
 Hi

 I would like to give away as many packages as I can to others who are
interested.  My current job keeps me pretty busy and I have been hanging
on to them in hopes of finding the elusive free time that I don't get
much of anymore.  So if you to be a comaintainer or want to take over
anything that I am the point of contact, feel free to drop a request in
pkgdb and send me a note off list as well.   Thanks for those who have
stepped in from time to time.

 The list of packages is at

 https://admin.fedoraproject.org/pkgdb/packager/sundaram/

 Rahul


I'll take python-dateutil15, and see it through to retirement once the
last of the dependencies are gone.

I see you've already retired askbot - any sign from upstream that
they'll support a newer django within a reasonable timeframe?

-- 
-- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org

-- 
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: Why sysrq is limited to only sync command on official fedora kernel?

[Pete Travis]

On Feb 26, 2015 9:01 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
wrote:

 On Thu, Feb 26, 2015 at 08:51:46AM -0700, Pete Travis wrote:
  The only time I've needed sysrq reboots in recent memory was while
running
  rawhide and knowingly venturing into uncharted territory.  If I'm not
the
  only one, would it make sense to include appropriate sysctl snippets in
  fedora-release-rawhide ?
 We could ship /etc/sysctl.d/sysrq-enable.conf.disabled (name up for
discussion),
 and interested users could enable it by renaming the file. Maybe even
better
 to provide it the same in all versions.

 Zbyszek
 --


All versions might be overkill, but I don't see the harm in the added
convenience, either.  What's the next step?

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 Self Contained Change: LXQt

[Pete Travis]

On Feb 24, 2015 2:57 AM, Jaroslav Reznik jrez...@redhat.com wrote:

 = Proposed Self Contained Change: LXQt =
 https://fedoraproject.org/wiki/Changes/LXQt

 Change owner(s):  Helio Chissini de Castro heliocas...@fedoraproject.org
,
 Christoph Wickert cwick...@fedoraproject.org

 Package the LXQt desktop Environment for Fedora.

 * This Change is announced after the Change Submission Deadline as an
 exception to the process. May not be approved for proposed Fedora
release. *

 == Detailed Description ==
 LXQt [1] is the Qt port and the upcoming version of LXDE [2], the
Lightweight
 Desktop Environment. It is the product of the merge between the LXDE-Qt
and
 the Razor-qt projects: A lightweight, modular, blazing-fast and
user-friendly
 desktop environment.

 == Scope ==
 * Proposal owners: LXQt packages already approved and in the system.
 * Other developers: N/A (not a System Wide Change)
 * Release engineering: N/A (not a System Wide Change)
 * Policies and guidelines: N/A (not a System Wide Change)

 [1] http://lxqt.org/
 [2] https://fedoraproject.org/wiki/LXDE
 ___

Is there an intent to produce an lxqt spin, or is this simply a publicity
change for the existing packages?  What's new here?

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Pete Travis]

On Feb 24, 2015 8:32 AM, Mikolaj Izdebski mizde...@redhat.com wrote:

 On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
  I would much rather live without any legacy jdk, and if so then
without any
  rules. But not setting
  them will bring chaos for majority of users.
 
  I have a question: Is there anybody that stepped in to maintain the
legacy jdk?
  If there is nobody to maintain it trying to come up with this
guidelines now would be pointless.
  In short I think that such guidelines would better be created *only*
when there are interested parties, jointly with them and the process is
played a bit by some copr repo or similar. Purely theoretical work is not
needed.

 I fully agree with Alex here.

 I would add that if someone really wants to maintain older JDK in Fedora
 then it should up to *them* to come up with a solution that will work
 and satisfy expectations of JKD maintainers and Java SIG. Maintaining
 package is more than clicking unorphan in pkgdb.

 --
 Mikolaj Izdebski
 Software Engineer, Red Hat
 IRC: mizdebsk
 --


If some third party supplies 'java' as the $legacy jdk, and the user
installs a Fedora package built on $current jdk, which provider will win,
and what packages will break?

If the user uses alternatives to set the jdk (that applies here, right?)
any applications that need one version or the other could break?

I understand these are relatively ignorant questions, but if the aim is to
provide a path for someone to maintain older JDKs it seems better to offer
them guidelines and best practices instead of you'd better be competent
enough to figure it out.  They might not think of all the potential
conflicts.

--Pete
-- 
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: Changes in the f22 workstation

[Pete Travis]

On Feb 20, 2015 2:09 PM, Matthias Clasen mcla...@redhat.com wrote:

 I wanted to give a heads-up to the wider audience about a number of
 workstation changes that are landing in the f22 branch (and rawhide)
 this week, in time for the alpha freeze next week:

 - The message tray at the bottom is gone, notifications are now shown
 at the top, and can be reviewed in the calendar popup (
 https://fedoraproject.org/wiki/Changes/GnomeShell_NewNotifications)

 - The gnome-shell theme has been refreshed

 - The login screen is using Wayland (
 https://fedoraproject.org/wiki/Changes/Login_Screen_Over_Wayland)

 - Codec installation has been integrated in gnome-software (currently
 this is hooked up in totem)

 - Nautilus has received a number of improvements (
 https://fedoraproject.org/wiki/Changes/Nautilus_Improvements)

 Please let us know if you see any fallout from these changes.


 Thanks! Matthias

 --

I'm nervous about GDM on Wayland; Wayland has never worked well on my
systems.  Can you talk about fallback strategies a bit?  Can GDM detect
when Wayland isn't working well enough to be usable, and cleanly fall
back?   That's probably a big ask, though; presumably this can be set one
way or another by the user?

--Pete
-- 
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: amending the new package process

[Pete Travis]

On 01/22/2015 07:15 PM, Haïkel wrote:
 2015-01-21 11:49 GMT+01:00 Nikos Mavrogiannopoulos n...@redhat.com:

 Step 6: ... If the proposed package is not reviewed for 2 months, the
 package must be reviewed by the submitter, and a git module with the
 master branch will be approved.


 I share your concern about the pending list but self-review is not
acceptable.
 Just licensing review itself would be a blocker to your proposal.

 But if we were to have a staging repository as suggested by Josh and
Jaroslav,
  it could be something that we could consider.


 What saddens me is that we have plenty of packagers and sponsors and only
 a very small fraction does review.
 We should find a way to encourage people doing review even *INFORMAL*
 ones.
 Good informal reviews is the best way to get sponsored, and helps
decreasing
 the pile (as a sponsor, I approve a positive and good quality informal
 review by my mentees).


 Besides, some submitters do not try hard enough to find reviewers:
 * some reviews do not provide usable links to spec and srpm breaking
usage of
 semi-automated reviewing tool. The more information you give to the
reviewer,
 the more likely it will get reviewed fast.
 * reviews swapping: 376 pending reviews but how many swapping requests
 on this list ?
 * Just go asking your fellow packagers on irc/mail or SIG if there's one.
 though I keep telling that I'm more than willing to do python reviews
 (for free, no swapping!),
 very little people ping me.

 If everyone does an effort, it will be less of a problem.

 H.


 PS: please no badges for reviewing, it would probably help getting
 more reviewers
 at the expense of quality. Reviews quality is also another problem.

I think the last bullet point here is the important part.  I understand
the disposition for a technical solution, but someone that just drops
their package in  - even after two months - isn't really getting a sense
of community out of the experience.  The process as-is, while it can be
frustrating for all the reasons described, encourages new contributors
to get acquainted with their fellow packagers and their sponsors.

I'm not suggesting a de facto you must be sociable to be a Fedora
Packager, but the process does reinforce that you're not alone when you
get stuck, and you're not so isolated that nobody cares if you make a
mistake.  The informal reviews, irc chats, and list mails don't just
garner experience; they help develop a sense of participation, and that
leads to greater contributor retention.

Maybe some list or other communication channel that's more clearly for
packaging issues - I'm told devel@ can be intimidating - would help, but
I'm not really suggesting anything specific.  Everyone in the thread
here, and probably far more, have answered inane questions from me at
one time or another :P  Sometimes more process and more guides can help,
and sometimes you just need to bounce your understanding of the subject
off someone to clear up misconceptions and gain a little confidence. 
That part isn't broken, but maybe new packagers don't know it.

-- 
-- Pete

PS: Haïkel, if you're passing out python reviews...

-- 
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: python-dateutil update

[Pete Travis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/08/2014 09:47 AM, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Dec 08, 2014 at 09:10:59AM -0700, Pete Travis wrote:
 On Dec 8, 2014 8:51 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl
 wrote:

 On Sun, Dec 07, 2014 at 04:45:12PM -0700, Pete Travis wrote:
 python-dateutil is old[0].  Fedora is carrying version 1.5, and
upstream
 is up to 2.3 .  If you're receiving this mail directly, you are a
 maintainer of  a package that depends on python-dateutil, and we need
 your help.
 It seems that calibre is fine with the new version. I wanted to update
 pyton-dateutil to check if calibre works, and it seems that I
 installed python-dateutil-2.3 with pip --user couple of months ago and
 calibre didn't seem to mind. There's some dateutil usage in the
installer,
 which I didn't test but which we probably don't care about.
 https://github.com/dateutil/dateutil/blob/master/NEWS also doesn't seem
 scary.

 So I think it's fine it python-dateutil is updated as a calibre dep.

 Zbyszek

 Great, thanks for responding.   I'm a *light* calibre user, but I'd be
 happy to help test with a newer dateutil when it becomes available if
 that's the direction you are going.
 You can just install the python-dateutil-2.* package and test away ;)

 Looking at the list and your annoucement mail again, I wonder if it
 might be better to bump python-dateutil to 2.2 again as soon as the
 updated python-dateutil15 is available, and simply modify packages
 which either explicitly depend on dateutil  2 or exhibit problems to
 depend on python-dateutil15. Proven packagers can do that trivially if
 necessary. Otherwise this could drag on for months.

 fedocal and python-django-tastypie are the only packages which
 explicitly require python-dateutil  2. If you wish, I can volunteer
 file bugs to change the dependency for F21 and rawhide for those two
 packages and do it myself after a week if the maintainers don't
 respond or are fine with the change (got to use those provenpackager
 privs for something :)).

 Zbyszek

Okay, I finally have things in motion here python-dateutil15 in
rawhide is usable as described and an update for F21 will be available
soon. Provenpackage at will :)

- -- 
- -- Pete
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUvCcGAAoJEL1wZM0+jj2ZqPIH/i5SSAHgnNOWhAqK8A8jEN/7
2Q2cwirG25CjWCu6doLX5W7Y+/jBHFaEB90WfS0HtiZEiJI6WQc8g+uz46Piyro2
NsXdQMNn7Em62apcHj3qJFYTinUVhYYR/eamYo09pEo7JPoXEhGAc0UW3i1QkTCv
OM8x0j/lk6Dcj/xFJq0prdYDZqcQtQQsjX5A+LIWuYBaDF/yUpEhWcWa4Y9I5RaZ
AQiuYaxxXVEdmVwHM/frSffn66qTP9zW/rypIYxQXEZiEXyApOKm8whN8C9a5q+M
Shr5IDyNiDvELwLXUCncqMKFN43DP9YfqPiI8RG7c2nIf7hl8sZCeldlwPPPI5c=
=1ujy
-END PGP SIGNATURE-

-- 
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: Deleting f20-gnome-3-12 copr

[Pete Travis]

On Jan 7, 2015 6:00 AM, Richard Hughes hughsi...@gmail.com wrote:

 I'm planning to delete
 https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this
 week. The original description always had This COPR will be updated
 until Fedora 21 has been released or until the entropy death of the
 universe, whichever happens first. so I don't altogether feel too
 guilty about abandoning it. Does anyone have any objections or wants
 to volunteer to take it over before I delete the repo?

 Richard
 --

While recognizing the massive maintenance burden of this COPR, I suspect
the majority of objections will come from the enthusiast end user type -
you know, the ones that are so eager to try the new thing they read about
that they blow right past the description.  This COPR received a lot of
publicity; fedoramagazine articles, social media, blog posts, etc.

Can you work in similar signal for end users?  Besides the online content,
I think even an integrated warning from within the GNOME session would be
cool.  I could show you a dozen examples from ask.fp.o where users
encounter a 404, your repo has gone away and they do not understand it.

/backseatdriver

--Pete
-- 
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: Deleting f20-gnome-3-12 copr

[Pete Travis]

On Jan 7, 2015 7:23 AM, drago01 drag...@gmail.com wrote:

 On Wed, Jan 7, 2015 at 3:13 PM, Pete Travis li...@petetravis.com wrote:
 
  On Jan 7, 2015 6:00 AM, Richard Hughes hughsi...@gmail.com wrote:
 
  I'm planning to delete
  https://copr.fedoraproject.org/coprs/rhughes/f20-gnome-3-12/ this
  week. The original description always had This COPR will be updated
  until Fedora 21 has been released or until the entropy death of the
  universe, whichever happens first. so I don't altogether feel too
  guilty about abandoning it. Does anyone have any objections or wants
  to volunteer to take it over before I delete the repo?
 
  Richard
  --
 
  While recognizing the massive maintenance burden of this COPR, I
suspect the
  majority of objections will come from the enthusiast end user type - you
  know, the ones that are so eager to try the new thing they read about
that
  they blow right past the description.

 Well one might think that those kind of users have updated to F21 to
 get the new shiny stuff anyway.
 --

The kind of users that are always driving for the latest shiny thing, yes.
The users that read about some shiny thing on the internet, were
interested, and plowed through the instructions without really
understanding the implications, no.  I'm just suggesting a little courtesy
and further instruction for the latter.

In any case, there *will* be some perplexed folks out there when it gets
turned off.  I can share links when I see them if you like :)

--Pete
-- 
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: Other download options

[Pete Travis]

On Dec 10, 2014 10:47 AM, Mike Pinkerton pseli...@mindspring.com wrote:


 On 10 Dec 2014, at 11:52, Jerry James wrote:

 On Wed, Dec 10, 2014 at 6:27 AM, Maros Zatko mza...@redhat.com wrote:

 Yes, there is netinstall in the Server variant, I suppose it's not the
same as
 Workstation one and (as a user) I'm getting pretty confused now :)


 I'm getting kind of confused myself.  I want to grab an image to throw
 onto an old machine for my kids to use.  I just want a desktop with a
 web browser and a mail client.  Workstation isn't suitable; they
 aren't developers (yet).  Server and Cloud are definitely right out.
 I don't want a Live CD; I want to actually install.  (In the past,
 installing from a Live CD left one with different defaults than an
 install from DVD, so I've learned to avoid the Live CD.  Perhaps that
 reflex is now wrong.)  I guess I could go with one of the spins, but I
 don't see a GNOME spin anywhere.  Is there really no DVD image for a
 generic GNOME desktop install?  Maybe I should make Kevin happy and
 get the KDE spin. :-)

 Actually, the KDE, Xfce, LXDE, and Mate spins all seem likely to fit
 my use case, but I'm very surprised that there isn't a GNOME
 equivalent.  Or is there?  If there is, I can't tell from the
 information on getfedora.org.  What are we recommending for people who
 want to install a generic access the Internet type of environment
 for non-techies?  None of the products obviously address that
 audience.


 This issue has been addressed tangentially in the marathon Workstation
defaults to wide-open firewall thread.

 As best I can tell from Matthew Miller's responses there, Fedora has
abandoned that portion of its previous user base that was using Fedora as a
general, secure by default, Gnome desktop OS.  Those users are no longer
supported by any Fedora product.

 I also am trying to figure out how I can use Fedora going forward to
support general desktop requirements for SMB office workers, creative types
and others who have heretofore been using Fedora as a general, secure by
default, Gnome desktop OS.  The only ideas I have come up with so far are:

 •  Install Fedora 20, update it, then fedup to nonproduct variant of
Fedora 21; or

 •  Use the server net install to install a minimal system as a
nonproduct variant of Fedora 21, and then install a long list of packages
needed to convert it into a general desktop OS.

 I have not yet tested and don't know how practical either of those ideas
is.

 My users are accustomed to Gnome, so I prefer not to change to one of the
alternative desktop environment spins if there is an easy way forward with
Gnome.

 --
 Mike Pinkerton


I have a lot of tools.  Mechanics tools, woodworking tools, electronics
tools, plumbing tools, whatever.  I don't drive over to the nearest
hardware store and buy whatever they have on the shelf that fits the
general description of saw or torque wrench or multimeter.  I do some
research, find quality products, and usually end up with something targeted
towards professionals or contractors or whatever.  I'm not going to
compromise my standards because I encounter a product that isn't marketed
for occasional semi-skilled use.

Friends and family (at least, those that don't think the same way) end up
borrowing my tools, even when they already have a saw or nailer or
whatever.  The tools they end up with just aren't as good.  Often, their
grabbed-off-the-shelf tools break more easily and sooner, while mine
operate reliably through hard use.  The experience is just more pleasant,
the user more productive, the quality of the end product noticeably better.

An OS is also a tool.  You don't have to be a professional developer to
enjoy the benefits of a product targeted for professional developers.  You
don't have to choose your experience based on the target audience of some
marketing copy.  If the product works for you, and works well, use it.
(Obligatory aside - if you are a professional developer, and you prefer an
alternative DE, Fedora works for you too :)

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Pete Travis]

On Dec 9, 2014 10:54 AM, Stephen John Smoogen smo...@gmail.com wrote:



 On 9 December 2014 at 10:46, Alec Leamas leamas.a...@gmail.com wrote:

 On 09/12/14 18:39, Stephen John Smoogen wrote:



 On 9 December 2014 at 10:27, Chris Murphy li...@colorremedies.com


 [cut]

 OS X's firewall is disabled by default. Where's the outcry?


 It was a long time ago and it basically caused it to have extra
 configurations before it could be 'ok'd' for various corporate and
 government sites. Not something Fedora Workstation is aiming at.


 Hm... has anyone a feeling about how such entities would react to the
current firewall defaults (open for user ports)?  Do we care?


 Same way, and we do not care for this release. Later releases can be
dealt with when they come about.

 In the end, this is a tempest in a teapot. The release is out and it is
done. I don't like it, but my yelling and screaming and spitting in an
autistic rage did not fix it so its time to move on so that is what I am
going to do.

 --
 Stephen J Smoogen.


 --

This discussion would resolve quickly if we had video proof of your antics,
smooge :)

But seriously, there's an implication in this thread that there will be
work happening to give stuff a path to ask for an open port.  Where can we
follow along with that effort? Starting with, say, how I might change
`nikola runserver` or `django-admin runserver` to ask for the port, and
ending with the resulting UI that asks me for approval?

If we want actual progress, it doesn't happen because of controversial
compromises, or mailing list flamewars, or even GNOME-specific UI responses
to dbus signals.  We're all here talking about it - let's talk about what
would be ideal, and start pointing at the code to make it work.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Pete Travis]

On Dec 9, 2014 11:33 AM, Chuck Anderson c...@wpi.edu wrote:

 On Tue, Dec 09, 2014 at 11:16:54AM -0700, Pete Travis wrote:
  But seriously, there's an implication in this thread that there will be
  work happening to give stuff a path to ask for an open port.  Where can
we
  follow along with that effort? Starting with, say, how I might change
  `nikola runserver` or `django-admin runserver` to ask for the port, and
  ending with the resulting UI that asks me for approval?

 The functionality for a program to ask for an open port already
 exists.  It is called bind(2).
 --

I should have said ask firewalld for a port to be opened - sorry, I
thought that would come from the context.

Are you saying bind() should be talking to firewalld, via some approval
agent?  how do we make that happen?

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Pete Travis]

On Dec 9, 2014 12:06 PM, Chuck Anderson c...@wpi.edu wrote:

 On Tue, Dec 09, 2014 at 11:52:01AM -0700, Pete Travis wrote:
  On Dec 9, 2014 11:33 AM, Chuck Anderson c...@wpi.edu wrote:
  I should have said ask firewalld for a port to be opened - sorry, I
  thought that would come from the context.
 
  Are you saying bind() should be talking to firewalld, via some approval
  agent?  how do we make that happen?

 My point was that a firewall is superfluous if a program can just ask
 firewalld to poke a hole in the firewall for it automatically, because
 a program can already ask the system to open a listening port for it
 using bind(2) (and listen(2) and accept(2)) when no firewall is
 present.

 It means that in a world where automatic-hole-punching exists, the
 only use of a firewall on the host is maybe to limit the SCOPE of such
 communication, not whether such communication is allowed at all or
 not.  This is where firewall zones come in.

Okay, one more thing on the ideal requirements list:  firewalld must not
blindly approve all requests, there must be some approval mechanism.  What
would that look like?

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Pete Travis]

On Dec 9, 2014 11:54 AM, Brian Wheeler bdwhe...@indiana.edu wrote:

 On 12/09/2014 01:45 PM, Bastien Nocera wrote:


 - Original Message -

 Richard Hughes wrote:

 So do I! I'm a developer, which spin do I use so that the firewall
 doesn't get in my way? We can't develop a *product* based around what
 you specifically want, not me, nor anyone else on this list.

 If you're a developer, surely you know what a port is and can make a few
 clicks in firewall-config or system-config-firewall to open it! A
 developer who can't even figure that out is a HORRIBLE developer!

 Still waiting for that answer about the rygel use case. You'll see how
 much of a HORRIBLE setup this can be...


 How, exactly, is a home media solution a key requirement for the
Developer oriented firewall touted by the release notes?

 This is the problem I've got with this feature.  It has nothing to do
with developers and everything to do with making a gnome feature work
without having to click a I really want to open everything because I'm on
a trusted network box.



This is one sentence fragment based on my impression of the Workstation
working group's intent to use this feature to create their ideal
development environment.  I recall dev servers being cited as use cases as
well.  If the only problem you have with the firewall config is the way it
is described in the RNs, I'm tempted to change it just to end the stop
energy put into what *could be* a productive discussion.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Pete Travis]

On Dec 9, 2014 12:38 PM, Chuck Anderson c...@wpi.edu wrote:

 On Tue, Dec 09, 2014 at 12:09:23PM -0700, Pete Travis wrote:
  On Dec 9, 2014 12:06 PM, Chuck Anderson c...@wpi.edu wrote:
  
   On Tue, Dec 09, 2014 at 11:52:01AM -0700, Pete Travis wrote:
On Dec 9, 2014 11:33 AM, Chuck Anderson c...@wpi.edu wrote:
I should have said ask firewalld for a port to be opened - sorry,
I
thought that would come from the context.
   
Are you saying bind() should be talking to firewalld, via some
approval
agent?  how do we make that happen?
  
   My point was that a firewall is superfluous if a program can just ask
   firewalld to poke a hole in the firewall for it automatically, because
   a program can already ask the system to open a listening port for it
   using bind(2) (and listen(2) and accept(2)) when no firewall is
   present.
  
   It means that in a world where automatic-hole-punching exists, the
   only use of a firewall on the host is maybe to limit the SCOPE of such
   communication, not whether such communication is allowed at all or
   not.  This is where firewall zones come in.
 
  Okay, one more thing on the ideal requirements list:  firewalld must not
  blindly approve all requests, there must be some approval mechanism.
What
  would that look like?

 You either have a pre-approved policy of what is allowed and what is
 not similar to how SELinux policy, PolicyKit rules, and the existing
 firewall rule mechanisms work, you ask the user on each request,
 similar to how some Windows firewalls work, or you ask the user when
 they connect to a network which zone to associate that network with,
 and use a pre-approved policy for each zone.  Zones can be Home,
 Public, Work, etc.  Windows does this as well.


Hmm... a whitelist of things that are allowed to ask for firewall
accommodation doesn't help me develop new applications at all.  And you're
jumping to a really high level UI thing and just sort of hand waving over
the mechanism needed to make it all work.  Assigning different networks to
zones is a different problem compared to a program asking for a port.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Pete Travis]

On Dec 9, 2014 12:55 PM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 09.12.2014 um 20:51 schrieb Pete Travis:

 Hmm... a whitelist of things that are allowed to ask for firewall
 accommodation doesn't help me develop new applications at all.  And
 you're jumping to a really high level UI thing and just sort of hand
 waving over the mechanism needed to make it all work.  Assigning
 different networks to zones is a different problem compared to a program
 asking for a port.


 don't get me wrong but if it is too much asked for you to open a firewall
port i don't want to have your network-aware new application on my machines
or any machine working in networks i am responsible for

 a prerequisite for develop network applications is understanding of
network basics and if your application don't use networking you are not
affected


 --


Lets say I do have an understanding of network basics, just for the sake of
argument.  I share my application with you.  The application is intended to
listen on the network, you know this and want the application for that
purpose.  You run the application, it tries to listen to a network port.
Magick, prayers, and the ghost of Charles Babbage - or maybe some
hypothetical dbus service- does *something* to find out if you really
wanted that.  You did.  Neither one of us is is made incompetent by the
convenience.

Here's the thing: firewalld will let this happen.  at here is a dbus
interface.  Thomas has proven more than willing to accommodate RFEs. Nobody
is asking for changes that would solve the problem of frustrated users or
developers encountering firewall restrictions.  The GNOME folks don't want
the UX compromise of rote-clicked dialogs.  Nobody else is suggesting an
alternative implementation that actually *improves* the Fedora experience.
Ideas get more traction than complaints.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Workstation Product defaults to wide-open firewall

[Pete Travis]

On Dec 9, 2014 1:31 PM, Reindl Harald h.rei...@thelounge.net wrote:



 Am 09.12.2014 um 21:25 schrieb Pete Travis:

 Lets say I do have an understanding of network basics, just for the sake
 of argument.  I share my application with you.  The application is
 intended to listen on the network, you know this and want the
 application for that purpose.  You run the application, it tries to
 listen to a network port.  Magick, prayers, and the ghost of Charles
 Babbage - or maybe some hypothetical dbus service- does *something* to
 find out if you really wanted that.  You did.  Neither one of us is is
 made incompetent by the convenience.


 i did not say that nor is anything i said in that thread meant abusive

Of course not.  I didn't feel insulted at all.  My point is that me as the
hypothetical dev, you as the hypothetical tester, and the general public as
a hypothetical user base would *all* have a better life if some
hypothetical solution existed for my app to ask the firewall for something
and for the user to approve it.


 Here's the thing: firewalld will let this happen.  at here is a dbus
 interface.  Thomas has proven more than willing to accommodate RFEs.
 Nobody is asking for changes that would solve the problem of frustrated
 users or developers encountering firewall restrictions.  The GNOME folks
 don't want the UX compromise of rote-clicked dialogs.  Nobody else is
 suggesting an alternative implementation that actually *improves* the
 Fedora experience.  Ideas get more traction than complaints


 that's true

 *but* if i do not have a idea to make things really better with all
side-effects i hestitate to change the current behavior until i have a good
idea

 the opposite happened with the change of this topic


Right, I think we're on the same page now.  If there's some consensus about
a desired behavior, interested parties can start working on it.  There's
two sides with an all-or-nothing position here, innovation does not come
from that.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

python-dateutil update

[Pete Travis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

python-dateutil is old[0].  Fedora is carrying version 1.5, and upstream
is up to 2.3 .  If you're receiving this mail directly, you are a
maintainer of  a package that depends on python-dateutil, and we need
your help.

There are some changes that might cause breakage for you if the package
was updated.  Luckily, there is a python-dateutil15 package that could
continue to provide the same code. The maintainer of python-dateutil15
has agreed to carry the one patch that makes it different from
python-dateutil.

After this update to python-dateutil15, maintainers of dependent
packages[1] can simply submit an update with the new requires for
business as usual.  python-dateutil can then be updated to the current
version, and packages needing *that* can move forward.

I intend to file a bug against python-dateutil15 for the patch, a
tracking bug that's blocked by tickets filed against individual affected
packages and dependent on the python-dateutil15 change, and the tracking
bug will block the cited python-dateutil ticket.  It should be
relatively easy to see when each step is complete, and a relatively
painless change for the maintainers involved.  Please reply here with
any concerns about this process that might not have occurred to me.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1126521
[1] https://immanetize.fedorapeople.org/python-dateutil.requires

- -- 
- -- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUhOZ4AAoJEL1wZM0+jj2Z4jUH/A7d3onPkvwUNKUo5uCDXBJb
WIXOKtCZbK3LrBK7VSUk7px4cfOjcFumRCs+ZSXSq4URIRd8pxCFbcXWTpfk1fq3
uoxeZDXiK9Ab9P+2ksPDlPODuDxjoj77Pa79YNnoxUTL2tvdz2YcrlIqOrgJa2+h
uopMO8BF9qE6t8KXfhiGkP2w/EF6rfqrUaL0F7xvVzyDfkA/akS0LPcRyfQ0fOi6
Tbfr9Qoj54dpJWLjlBXky0RLodMXl2oFOnotdhmqAF9RRIbotYG03NXH9CeQn3SU
wdQm/RdXgQQyoTbghwq8k0yGWsPrhm4AyeC++XTKUtBFZwEEGxVj+2kAnpvJ24Q=
=7BTl
-END PGP SIGNATURE-

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

[Pete Travis]

On 11/21/2014 11:22 PM, M. Edward (Ed) Borasky wrote:
 I think the Fedora policy requires more of a commitment from
 maintainers than I can offer. In any event, I know RStudio Server can
 be built from source on Fedora and that it works but it needs a lot of
 detailed attention to turn it into something that will make it into a
 release. It has a few dependencies - gwt, for one - that aren't in
 Fedora so their source needs to be packaged in the source RPM.

 There's also the question of upstream - they have a build process that
 makes usable binaries for openSUSE and Fedora but only support the
 server on Debian, Ubuntu, RHEL and CentOS. I did get them to fix some
 issues when their run-time dependencies messed up a Fedora R upgrade,
 but I don't know if they'd actively participate in a distro packaging
 effort. They'd need to be asked.

 All that said, this is a good time to start such a project, since
 Fedora 21 is about two weeks away from release. I have a COPR project
 opened but haven't put anything in it yet -
 https://copr.fedoraproject.org/coprs/znmeb/rstudio/

 On Fri, Nov 21, 2014 at 8:38 PM, Suchakra sucha...@fedoraproject.org
 mailto:sucha...@fedoraproject.org wrote:

 Hi,

  What do you say, Ed?  If I get the package review done, will you
 help with
  bugs and maintenance?
 
  --Pete

 I am using RStudio actively on Fedora using the rpm they provide.
 Though it works just about satisfactorily for me standalone,  it would
 really be nice to have it in our repos. I can help in testing/bugs and
 occasional maintenance.

 --
 Suchakra
 --
 devel mailing list
 devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct




 -- 
 Twitter: http://twitter.com/znmeb; Computational Journalism on a Stick
 http://j.mp/CompJournoStickOverview

 Remember, if you're traveling to Bactria, Hump Day is Tuesday and
 Thursday.


I just glanced at their github repo.. wow. 
https://github.com/rstudio/rstudio/releases - it looks like they are
tagging a 'release' every time they touch the code.  There's also a lot
of bundling; probably not an insurmountable amount, but it won't be an
easy one to package.

As for upstream suppport... well, the bundling is indicative of how
they'd probably feel about keeping up with our dependency churn.  It
isn't uncommon for upstreams to not actively participate in the
packaging process, but if they're taking the stance where 'we only
support the latest release (ha!) with these specific versions of deps'
it would be a nightmare. Detailed attention is right :)

Anyway, I'll keep an eye on this thread and if there's enough interest,
I'll happily participate in the packaging.  Still definitely more than I
want to take on alone - but it does look like an interesting challenge.

-- 
-- Pete

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

[Pete Travis]

On Nov 21, 2014 12:48 PM, M. Edward (Ed) Borasky zn...@znmeb.net wrote:

 The two I want most are RStudio (desktop and server) and R Commander.
RStudio does exist in RPM form but the packages are made via 'cmake' rather
than by Fedora's process, and the server's using the old school /etc/init.d
rather than systemd. R Commander's much easier - you just have to package
it's dependencies and deploy its desktop file.

 When I get the time to work on a long-term project I may take a shot at
RStudio in COPR. OpenSUSE Build Service has source RPMs for RStudio but
they're many revisions old and seem to be unmaintained.


I don't have a personal interest in RStudio, but I do support users that
rave about it.  While not entirely enthusiastic about taking on packages
when I don't have much experience using the software, it wouldn't be so bad
to get things rolling with a comaintainer that does have that experience.
Bonus, its one more thing to check off my We can't use Linux because
list.

What do you say, Ed?  If I get the package review done, will you help with
bugs and maintenance?

--Pete
-- 
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 branched (2014-11-20)

[Pete Travis]

On Nov 20, 2014 2:25 PM, opensou...@till.name 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

 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)maintainersStatus Change
 ===
...
 create-tx-configuration   orphan, sparks  5 weeks ago
...

Taking this one; I used it just recently and don't want to be surprised if
I need it again.

--Pete
-- 
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: Removing packages that have broken dependencies in F21 tree

[Pete Travis]

On Nov 13, 2014 8:02 AM, Kalev Lember kalevlem...@gmail.com wrote:

 On 11/13/2014 03:33 PM, Richard W.M. Jones wrote:

 On Thu, Nov 13, 2014 at 03:20:03PM +0200, Kalev Lember wrote:

 transifex


 Huh??  If this is the package I'm thinking of, it's pretty important
 to many other packages.


 It depends on python-django14 that was removed a while back and nobody
seems to have ported it to a newer django version:

 [transifex]
 transifex-1.2.1-12.fc21.noarch requires python-django14


 --
 Kalev

 --

transifex-client is probably seeing a lot more use ( at least on my desk :)

It still seems openly active at
https://github.com/transifex/transifex-client .  I doubt they will change
that - it's mostly just pycurl talking to an API, no secret sauce, and tx
really does advocate open souce even if they struggled with making it
commercially viable.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: No more deltarpms by default

[Pete Travis]

On Oct 18, 2014 5:00 PM, Nico Kadel-Garcia nka...@gmail.com wrote:

 On Thu, Oct 16, 2014 at 11:40 PM, Gerald B. Cox gb...@bzb.us wrote:
  My comment was not meant to be argumentative, but rather
tongue-in-cheek.
  However, I do believe when changing a default, it isn't about what is
  convenient for me.  It's about what is best for the entire community and
  what are the real world ramifications.  I'm not buying the let's
change the
  default because high bandwidth is pervasive argument.
 
  I'll go out on a limb here and suggest:
 
  1.  Most people who can afford to pay the monthly recurring cost for a
high
  speed bandwidth connection have multi-core machines.
  2.  People who are running Fedora on multiple machines possess the
skill set
  to easily change the default and turn Presto off if they wish.

 You left out some but related issues.

   3) People who have a lot of hosts and high bandwidth, high speed
 local deployment requirements can, and do, set up an internal Fedora
 mirror with much lower bandwidth costs. This reduces the tangible
 benefits of deltarpms significantly. This is combined with my direct
 observation that working from plain rpms is much faster and more
 reliable. Re-assembly from deltarpms is computationally expensive and
 thus expensive for large numbers of yum clients. It sounds like a
 great idea at first glance, but it profoundly and unpredicatably
 increases the disk space and bandwidth needed for mirrors themselves
 at a relatively small benefit in download bandwidth. The great example
 of difficult to delta RPM's sems to be libreoffice. Between the
 compressed and distinct binaries for the war files, and the deltarpm
 process itself, they save very little bandwidth for many of the
 builkies projects.

   4) The much, much larger source of wasted bandwidth and resources is
 the yum repodata. That's 50 Meg, every time the repodata expires or is
 updated, even if there are no actual RPM updates. And for systems that
 need frequent updates and refreshes to ensure the latest packages,
 it's consumed *every single time* you flush the metadata.

  What about the repositories and mirrors?  Do they all have unlimited,
cheap
  bandwidth?

 No one does. But in my direct observation, deltarpms are a
 theoretically clever attempt to solve the wrong problem, an attempt
 that requires massive *extra* diskspace and resources for the mirror
 sites that doesn't address the more consistent and demonstrable
 problem.

 There are environments where bandwidth limits are so great that even
 the bare RPM downloads are vulnerable to interruption, and the
 marginal improvement of the deltarpm would be noticeable. But I've not
 seen such an environment in roughly 10 years, and it was usually to
 some bad network hardware or local misconfiguration.
 --

Network operators will experience a real, tangible cost increase from
turning off deltarpms.  End users with metered bandwidth - off the cuff,
I'd guess hundreds of thousands of current users and billions of
prospective users - will experience a real financial impact from the 'loss'
of this feature.

Now, I realize everyone can turn this on, and everyone can turn it off.
Changing the default option doesn't take away the feature.  Those with
metered connections will probably, eventually, discover they can turn
deltarpms on.  After the first bill arrives, or the second.  These are
likely to be people with limited financial resources, using computers that
you couldn't pay me to work on these days.  We're keeping the entire 32bit
architecture alive for them; in contrast to that, the infrastructure burden
of deltarpms is slight.  Even so, we continue to welcome this demographic
to use and participate in Fedora.

Faster update transactions are good, but anyone that's concerned about the
*financial impact* of consuming extra CPU  cycles ( as in Nico's case #3)
is very likely to be employing a competent administrator (like Nico) that
should know how and why to flip the switch.  Nobody wants to take this
option away, and I doubt it  would even be possible.

--Pete
-- 
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: Samba as AD DC

[Pete Travis]

On Sep 7, 2014 11:58 AM, Simo Sorce s...@redhat.com wrote:

 On Sun, 2014-09-07 at 01:12 -0300, Sergio Belkin wrote:
  Hi,
 
  Is (Samba) Fedora 20 still not capable of being Active Directory Domain
  Controller?
 
  I mean is that page current:
  http://fedoraproject.org/wiki/Features/Samba4#Current_status ?
 
  Thanks in advance!

 It is current, and Samba in F20 will never have the AD bits.
 Maybe F22, or perhaps even F21, the work to replace Heimdal with MIT is
 proceeding well enough.

 Simo.

 --
 Simo Sorce * Red Hat, Inc * New York

 --

Is there a broadly scoped tracking bug for this effort, Simo?

--Pete
-- 
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: Add Gparted into Live's

[Pete Travis]

On Aug 8, 2014 4:03 PM, Hedayat Vatankhah hedayat@gmail.com wrote:
 GParted provides a number of essential features users might need, some of
which are not provided even by any command line tools in Fedora
repositories: resizing and moving partitions/filesystems. And something
like resizing FAT partitions is what I have not seen in any other tools in
Fedora repositories except kde-partitionmanager. Anaconda provides resizing
facility, but not move. Also, I'm not sure if Anaconda can resize FAT
partitions.
...

I think there is rarely a case where moving partitions is a good idea.
I've seen two situations where it would be useful:
- on an MBR drive, the user deliberately created four primary partitions in
a way that left a bunch of unallocated space unusable without rearranging
things
* supplying gparted by default is going to enable this kind of misadventure
- the user has deliberately created a small partition in the middle of the
drive but wants to use that space in another filesystem
* again, self-inflicted
* combining scattered partitions into a volume group is arguably safer

The other reason - anecdotally more common - is that the user simply likes
to see the partitions in alphabetical order by label or mountpoint, or by
descending volume, or by color left to right.  In short, arbitrary.  Yeah,
I know part of the drive goes by the read head faster - show me some data
from a modern drive if you're going to argue the point, please.

Goofing around with your data at the block level is dangerous.  A user
that's trying to 'perfect' their partition layout before installing has a
much greater chance of failure.  IMO the convenience isn't worth the risk
or loss of space for more interesting things.

--Pete
-- 
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 even allows to uninstall RPM and systemd without warnings

[Pete Travis]

On Jun 23, 2014 4:55 PM, Gerald B. Cox gb...@bzb.us wrote:

 First of all thank you for your reasoned response.  I simply disagree.

 I understand the fact about require bugs, and the tons of dependent
packages.  I've seen that also when I've tried to remove a package and
noticed it had a myriad of dependencies which would also be removed.
 However, when I see this, I simply respond N when I'm asked if it is OK
to proceed.  I also cringe when I see the -y or --assumeyes option
mentioned.  IMO that is just inviting disaster.  I'm surprised no one is
demanding that be removed.  It is dangerous.

 Regarding your kernel comment, I've been using Fedora since Redhat 6.2
and DNF since it first came out and I've never encountered this.  When I
update the kernel, it leaves the prior two on my system for rollback, so I
have no idea what you're talking about.  Yes, if you manually enter dnf
remove kernel it will come back with a list of all your installed kernels,
but again, you have to tell it YES to proceed.

 That said, my concern is that valuable developer time be devoted to
something which basically is to assist a small fraction of people who are
careless, can't be bothered to read or both.


 On Mon, Jun 23, 2014 at 12:26 PM, Przemek Klosowski 
przemek.klosow...@nist.gov wrote:

 On 06/23/2014 11:51 AM, Gerald B. Cox wrote:

 This has got to be the silliest thing I've ever seen, but whatever.
You enter the command dnf remove dnf, and guess what?  It removes dnf.  You
enter the command dnf remove kernel, and guess what, it removes the
kernel.  What a concept, it does what you tell it to do.

 You present it as simple, but it's really trickier than you imply for
several reasons. We discussed several special cases, which you must have
missed so let me recall those for your benefit.

 First, the dependencies. Updates often involve chains of those, and I've
seen cases, e.g. caused by a require bugs, where
 suddenly some system libraries end up scheduled for removal, dragging
along tons of dependent packages. Yes, 'yum update' will then ask for
confirmation, but it just isn't scalable---the equivalent of 'yum -y
update' must be reliable and recoverable even if things go wobbly.

 Second, kernel updates deleting all old kernels can delete the only
running kernel. You can't just say don't ship broken kernel upgrades
because it's a per-system problem---new ones work for most people but if
you are the unlucky person for whom it
 doesn't work, you are in a bind:

  - you must upgrade because otherwise you will never get a fix
  - you can't upgrade because it'll delete the only running kernel, and
the new one might not work

 It just makes a lot of sense to identify and protect a subset of
packages whose removal is potentially irreversible.

 --

So, there are actually two overlapping discussions here:
- upstream features
- distribution defaults for protected packages

We can talk about them at the same time *here* because the upstream
developers also happen to maintain the distribution package.  Nobody around
here likes to mandate other people do work, so we often say this is
upstream's choice, we can't force them to do anything. That's how it
should be, and the way the dnf developers are reaching out for feedback is
an admirable exception to the rule.

(So please, don't pull the upstream's discretion card on people who
participate in an open, invited discussion)

The other side of the coin is distribution defaults.  Would Fedora use dnf
without the ability to define protected packages? Maybe, some seem to like
that, some say we have no other choice.  Would any other distro take on
such a casually destructive solution for their default?  Not so likely.

That said, it is clear that people have different opinions on the ideal
behavior of dnf, and future adopting distros will be the same.  The dnf
developers are doing a commendable job allowing for everyone to be
accommodated via the plugin structure.  The Fedora community is doing a
good job of communicating expectations, and upstream is listening. The dnf
threads lately are great examples of collaboration we could be proud of.

... Except for the unnecessarily tense disagreements between Fedora
voices.  That's not the point I started out to make, but damn does it ever
taint a good thing.

Anyway, Jan  company, I think it would be great if protected package
functionality were available for those who chose to use it, whether that's
Fesco, some other distro, or an admin out in the wild.  I know a few people
with root passwords to machines where I wouldn't ask them to even dust the
thing unless times were desperate...

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

[Pete Travis]

On Apr 22, 2014 3:05 AM, Christian Schaller cscha...@redhat.com wrote:
...

 As a sidenote, there has been a lot of discussions on this an other
Fedora lists
 over the last few Months where people have loudly come out against what
they see
 as infringements on the Freedom part of the four F's. Having seen this
thread I
 am disappointed to see that nobody has come out in defense of the Friends
part
 of the four F's, because the language and tone used by some people on
this thread
 has been beyond pale, accusing the other participants in the thread of
stupidity,
 incompetence and general maliciousness. If this doesn't change maybe the
time has come
 for a board ticket to change that F from Friends to Flames?

 Christian


A good point. There's a relative scarcity of discussion on the 'Friends'
foundation.

In one sense, a relationship moves from acquaintance to friendship when
familiarity crosses a threshold.  You expect an acquaintance to follow
social niceties, but you trust a friend to be honest even at the expense of
politeness.  Of course we still need a code of conduct, and occasional
friendly reminders to cool down and take a walk for a while, but friends
should mostly be able to look past choice of language to evaluate message
and good intentions.

Equating disagreement with antipathy is more detrimental than vitriolic
disagreement.  We need the 'Friends' foundation to remind us that even in
the hottest of flamewars, everyone has good intentions.  Sometimes strong
language is just a device for making a point.  Even the wildest of idiom
isn't inherently intended to convey personal disrespect.  We need a
reminder, especially with contentious issues, not to ignore valid points
because they were delivered poorly and not to overvalue perspectives that
were shared more politely.

--Pete
-- 
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: Diagrams and images used in documentation

[Pete Travis]

On Apr 3, 2014 9:27 PM, William Brown will...@firstyear.id.au wrote:

 Hi,

 What is the software that is used to make images like :


http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/images/IPA_arch.png

 Or


http://docs.fedoraproject.org/en-US/Fedora/18/html-single/System_Administrators_Guide/images/Network_Interfaces-bridge-with-bond.png

 I haven't been able to find references to this, but would like to be
 able to use this style of images in my own documentation.

 --
 William Brown will...@firstyear.id.au

 --


Didn't want to cross post, but I've passed this on to the Docs list.

--Pete
-- 
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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Pete Travis]

On Mar 25, 2014 8:27 PM, Dan Mashal dan.mas...@gmail.com wrote:

 On Tue, Mar 25, 2014 at 1:07 PM, Kevin Kofler kevin.kof...@chello.at
wrote:
  My point is that it must ALSO be possible to install the preferred
desktop
  directly, without installing GNOME first.


 Exactly this.

 Installing MATE from the spin is not exactly the same thing as
 installing it from the netinstall or the DVD.

 The spin does not include the same packages as the DVD and the
 netinstall due to size constraints.

 If we can keep the netinstall, which allows people to do exactly this,
 then I really could careless what happens with workstation (and I'm
 also a happy camper, as I imagine you and many others would be too).

 Dan
 --

Can this difference be fixed with a mate-firstboot ui, ie these
additional applications are recommended for use with MATE, would you like
to check off the ones that interest you and install them ?

--Pete
-- 
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: cron to systemd time units

[Pete Travis]

On Mar 4, 2014 10:52 AM, Lennart Poettering mzerq...@0pointer.de wrote:

 On Tue, 04.03.14 15:54, Miloslav Trmač (m...@volny.cz) wrote:

  Hello,
  2014-03-04 15:32 GMT+01:00 Jaroslav Reznik jrez...@redhat.com:
 
   = Proposed System Wide Change: cron to systemd time units =
   https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units

 It is probably time to port over these jobs now. With systemd 209+ we
 should have a somewhat comprehensive solution in systemd now that can do
 roughly what cron can do, plus some nice additional features (though
 minus a couple of others).

 I am looking into adding a couple of more things before the Fedora
 release, in order to make this functionality convincing enough that
 people can understand why this change is made. For example, I want
 support for timer events that can wake up the system, and simple
 anacron-like behaviour.

 I'd also like to make sure we sell this properly. While I think it
 should be a goal to port all cronjobs we *ship* over to this, I want to
 make sure that cron is advertised as a good solution for people who just
 want to queue a simple cronjob. This is because setting up a timer
 service is more complex than setting up a cronjob. A cronjob is a single
 line added to crontab -e or /etc/crontab. However, a systemd timer
 unit will always be two files, and they will have 2+ lines each. While
 the systemd way is certainly more uniform with the rest of service
 management, it is definitely a bit more work, and I don't want to be in
 competition here...

 Lennart

 --
 Lennart Poettering, Red Hat
 --

Will there be a way for regular users to use timer units? User= will
execute as a regular user, sure, but root still needs to set that up.

--Pete
-- 
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: cron to systemd time units

[Pete Travis]

On Mar 4, 2014 7:51 AM, Matthew Miller mat...@fedoraproject.org wrote:

 On Tue, Mar 04, 2014 at 03:32:03PM +0100, Jaroslav Reznik wrote:
  = Proposed System Wide Change: cron to systemd time units =
  https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units

 I'm in favor, but I think we could use a little bit more in the release
 notes -- at least a link to the systemd documentation and a quick note on
 how to override locally (although people should be getting used to this
with
 systemd by now), and I think people would appreciate a list of services
that
 were migrated.



 --
 Matthew Miller--   Fedora Project--mat...@fedoraproject.org
 --

ACK. Upstream documentation is great, and the tracking bugs will give the
list of affected packages.  I can work with that.

--Pete
-- 
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 for changes to auto-expiring bugs

[Pete Travis]

On Feb 6, 2014 11:06 AM, Kevin Fenzi ke...@scrye.com wrote:

 On Thu, 6 Feb 2014 04:00:17 -0500
 Matthew Miller mat...@fedoraproject.org wrote:

  I would like to see one of the following, in order of preference:
 
  1.  Step one: when a release hits EOL, move the bugs to NEEDINFO with
  a notice similar to the current one. (Essentially moving the
  current warning back a little bit.)
 
  Step one point five: I believe pretty much anyone can clear the
  NEEDINFO flag.
 
  Step two: when the *next* release hits EOL (and the release under
  consideration has been EOL for approximately 6 months), move any
  bugs still in NEEDINFO to a new closed resolution like CLOSED:EOL,
  with a message similar to the current EOL note.

 So, all those bugs stay open on the EOL version until EOL+1?

 That seems poor to me. What do we do if someone clears needinfo and
 says: Yes, this still affects me, I am running EOL release. Please fix
 it.

 We cannot, the EOL release is closed, no more updates or support.

 How does leaving it open there help?

  EOL wouldn't be visibile as an available status for bugzilla
  users to select when closing a bug in the interface, so it does not
  add to UI clutter, but also makes it easy for us to do reports
  distinguishing between intentional and eol closure.

 Is this possible?

  This gives a much longer timeframe where we're waiting for input,
  so by the time we actually close, the release has been EOL for a
  decent while (rather than now, at the I just got around to
  updating! point).
 
  This does risk some false positives (negatives? whatever) where
  NEEDINFO is cleared with works for me but the bug not closed, but
  that seems like a less serious problem.

 Yeah, thats another issue with this... they would stick around in that
 case until the maintainer or someone came in and cleared them.

  2.  As #1, but with no new CLOSED:EOL resolution. Instead, use
  WONTFIX or and add a ClosedEOL keyword automatically. This is uglier
  than the above but requires no bugzilla change.
 
  3.  As #1, but just leave bugs in NEEDINFO state forever.
 
  This would possibly require maintainers to update their searches /
  filters to leave out NEEDINFO bugs, or at least NEEDINFO bugs
  from older releases.

 It would also be misleading, IMHO.

 Hey reporter, I need info to fix this

 Here you go, here's the info you wanted from my Fedora 7 machine,
 please provide update

 kevin

 --

What do you all think about adding a note to bugs against Fedora N-1 when
Fedora N is released, ie:

You filed this bug against Fedora 19, and Fedora 20 has recently been
released.  A new Fedora release includes a version update for many
packages, and your issue may have been resolved.  Please consider checking
to see if your issue persists in Fedora 20 and updating this ticket
accordingly.  Any bugs remaining open when support ends for Fedora 19,
shortly after the release of Fedora 21, unless the issue affects Fedora 20
or Fedora 21.

Not polished copy, obviously, but giving the reporter some more
warning/prodding can't hurt.

--Pete
-- 
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: New UEFI guide on the wiki

[Pete Travis]

On Feb 3, 2014 9:31 PM, Adam Williamson awill...@redhat.com wrote:

 On Mon, 2014-02-03 at 20:14 -0800, Andrew Lutomirski wrote:
  On Mon, Feb 3, 2014 at 8:09 PM, Adam Williamson awill...@redhat.com
wrote:
   So, look what I wrote today:
  
   https://fedoraproject.org/wiki/Unified_Extensible_Firmware_Interface
  
   (just plain https://fedoraproject.org/wiki/UEFI redirects to that
page,
   too).
  
   It's a (hopefully) not too long and not too technical help for
   installing Fedora on UEFI systems. Should cover the 'greatest hits'
that
   show up in bug reports, forums and IRC the most.
 
  That'll be very useful.  Thanks!
 
  If you happen to know the magic incantations to turn an installed UEFI
  OS into a BIOS-bootable OS or vice versa, it would be great to have
  that in the wiki.
 
  (This is a particular pain point for me -- my main development box was
  originally installed as BIOS, and I switched it to UEFI, and I'm sure
  I did it wrong because the boot process is impressively finicky.)

 Erf. I haven't done that myself in anger, so I'd have to give it a shot
 to give reliable instructions. My usual advice would be 'just reinstall
 it', honestly...
 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
 http://www.happyassassin.net



I've done it, and it was indeed an angry and detailed process, so I decided
it probably wasn't something I wanted to advise people to do.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Review swap: glyphicons-halflings-fonts RHBZ#1050805

[Pete Travis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi, I'd like to swap reviews with someone for a font I've packaged up[1] .

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1050805

- -- 
- -- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJS5WrhAAoJEL1wZM0+jj2ZxXMH/jV3psuoT5RexCdh8VEHkGnR
80KxAaUAFedRS4807SwGML7bLuUQX8X46jjK1ZAEExivNmgBcvBXdpe8RokEtuUQ
NnRDA5pUrURm0Ku9fJCHYIiK5Zp+QAcb05D9EhVdQV6JkiPL2sSFF/uYKBwchLI7
CHynWxkUnaR7K1H1Sf/lW0NB8FvCMHFlohzSNZgh/3cIk4fZ9WYw0H5orxSbOiSW
bA+jqW0PsUFNWHzTZpLxRGL41e5fapwHV1Rm8KB2PaTUBpDkl4OXFzyQa2GVDS3f
ZxACJjd20Vs+0PhK7PA7maSICAzonQmZgDUlcHjgP92NeqH1ikfzmxR4/MTN7ms=
=bZYU
-END PGP SIGNATURE-

-- 
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: What to do about packaging beta, or rc as alternate installable

[Pete Travis]

On Jan 23, 2014 1:12 PM, Stephen Gallagher sgall...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 01/23/2014 01:43 PM, Kevin Kofler wrote:
  Christopher Meng wrote:
  But you can do this on copr IMO.  Also update-testing is not just
  a place for updates to have a break, you can let it satisfy the
  needs of testing for unstable.
 
  Well, that's kinda abusing updates-testing. IMHO, COPR is the much
  better option until you have something reasonably close to going
  stable.
 

 The other problem with using updates-testing in this way is that it
 makes it more difficult if you have to deliver a real bug or security
 fix to stable. Now you have to unpush your testing version, mangle
 your git history, file a new update ...


 I agree with Kevin that this is pretty much exactly what COPR is good
 at (and what I'm using it for myself[1]).

 1) http://copr.fedoraproject.org/coprs/sgallagh/ReviewBoard2/

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iEYEARECAAYFAlLhd8QACgkQeiVVYja6o6N1WgCgqGU51RjTv4/uizYPOV5HSBhE
 WFkAoLAl4Twg3iHIBgEx1O5++juLlaXH
 =rNyt
 -END PGP SIGNATURE-
 --

Is there something inherent to COPRs that solves the problem of duplicate
paths, ie /usr/bin/mercurial from two different sources?

If I missed something, a link with an appropriate measure of mocking would
be welcome.

--Pete
-- 
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.next in 2013 -- Big Picture and Themes

[Pete Travis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/03/2014 11:14 AM, Matthew Miller wrote:
 Since we can't afford a monthly conference (ha!), I want something that
 feels like it online. A hub for the community, where we have that
 interconnectedness all the time. I think this centers around HyperKitty --
 which should be ready for production any time now. Let's make that
 front-and-center when answering the question what is Fedora?, and tie it
 to Badges, Fedora Magazine, Ask Fedora (possibly have it _replace_ Ask
 Fedora), and a new solution for short, helpful howto-style content (an
 element we're sorely missing now).


I strenuously agree about the need for a solution providing tutorial
content. There's plenty on the wiki, if you can find it, but wiki
content just doesn't feel qualified and doesn't invoke the same trust as
something that's clearly taken more effort to curate and present. I
spoke with a few people about this at Flock, and came back with the
impression that much of the community would contribute smaller articles.
However, they regarded the existing offerings at docs.fp.o either too
involving to contribute to, or too established in scope to add new
information.

After some pondering, I brought these concerns and a possible solution
to the docs list[1]. Most agreed that making it easier to contribute to
docs was a good idea, though the discussion of how to achieve that
didn't take the course I intended.  The existing guide writers are doing
all they can to keep up with the Guides, so there was more interest in
facilitating those contributions than starting a divergent venture with
potentially just as little interest from the rest of the community.  We
decided to attempt a FAD[2] to hash it out.

If the rest of the community expressed an interest, I'm confident that
we could come up with an inviting and productive solution.  If anyone
wants to pursue it, I invite you to bring this portion of the
conversation to d...@lists.fedoraproject.org . I don't think we need a
second group to support a second documentation product - or an expansion
of the existing lineup - just a more active docs group.  The venture is
really peripheral to Fedora.next - but a larger docs community would
help us keep up with such changes, one way or another.



[1] https://lists.fedoraproject.org/pipermail/docs/2013-November/015317.html
[2] https://lists.fedoraproject.org/pipermail/docs/2013-November/015337.html

- -- 
- -- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSx2t9AAoJEL1wZM0+jj2Z9yMH/iXp5rBsHYyoO+zYwyfJrzFi
LcrWgdLAqPr6quiIqxsB8fdymEfOybxrh+QJ2nsqZwrhhHSAAoWbepBr/77xHFbU
YTk9kWwqq9LGrtcw7e/OjEvcuf3R30q8SP6cmudeFgoqi2SosV6qgU+fPlZ9yA6B
7zmIpNMZrhP9q5yPaLmPYHBrBqNtEvl8gWVBRfXzDmHDucwGF3leGK7k3EIL5jNl
jgLenEmNIFV2S/sJLMeQE0uUY3KZyVbrcT/B7iwcpsLOL/NUvi+O4FN78u7wMVmr
pNeKUESOXiyVpE1PRU5F7z2dsCJz5ixmpckxn+UijB39o/5UWgAC4FL7m8O3A+k=
=1kb2
-END PGP SIGNATURE-

-- 
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: Best practice for multiple version/OS boot?

[Pete Travis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/24/2013 11:33 PM, Tim Landscheidt wrote:
 Hi,

 IIRC fedora-review suggested to test packages on all sup-
 ported Fedora releases.  So, with a larger hard disk, I want
 to install Fedora 19, 20 (soon) and Rawhide and throw in
 (recent) Debian and Ubuntu as well.  As my notebook doesn't
 support VMs, I'm interested in best practices for partition-
 ing and multi-boot setups.

 Currently I use a partition for /boot and another for an en-
 crypted LVM, so I only need to worry not to put private data
 in /boot, and I would like to keep such flexibility.

 I suppose I need to create a /boot partition for each ver-
 sion/OS.  I have had different Fedora versions share the
 same encrypted LVM without problems; I assume Debian and
 Ubuntu will do so as well, but I will keep some free space
 and partitions just in case.

 More contested seems to be the multi-boot setup.
 https://bugzilla.redhat.com/show_bug.cgi?id=872826 has a
 myriad of opinions on how it should be set up;
 http://fedoraproject.org/wiki/User:Jlaska/Multiple_OS_Bootloader_Guide
 suggests chainloader, and

http://www.gnu.org/software/grub/manual/html_node/Multi_002dboot-manual-config.html
 recommends configfile.  Of course there is also GRUB's OS
 prober.

 So what are Fedora developers /actually/ using?  Creating a
 separate GRUB partition and chainloader/configfile?
 Running OS prober in the main OS after each installation/
 kernel update?  Something else?  How often do the setups al-
 low one to shoot oneself in the foot, or are they (more or
 less) foolproof?

 Thanks in advance,
 Tim


Enough people have asked this sort of question that Chris Roberts and I
started hacking on a Guide to address it. Suggestions, criticisms, or
contributions are equally welcome.

[1] https://git.fedorahosted.org/cgit/docs/multiboot-guide.git/

- -- 
- -- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSk2y7AAoJEL1wZM0+jj2ZU3EIAJBMdQg49E1Gh1Nzdvk2bxdo
6RowLli9qfow9HiMjESNNN70VIZQDnBfZ0d6V+tquEHeBLXG/PLh7fLyYIdn3wNL
JdogdQX2K9BicH+bsCpYqabXxOGWWHH5ss+J6+fBYAwDxo/z5/j4+XXRSkDG9Kci
8RR7uCcfWpNNvODBzYIp34LFe7m1QAsFnwBxtMGVg7qzLJ2LEiOVcm0jkWxwa+wa
OTfDpnngPUTjpKK2exICRMQzrJoHFlv7bduaEaH7yp7YfD7DN5UR/wLku1kFHjbh
Ym7d3MItawLkAtURTh0NuR4hT+TTzxgTYgYXxi7vCuNdX4+Uq6V5xuO6YGdCtEs=
=Qvmd
-END PGP SIGNATURE-

-- 
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: What is support status of PowerVR GPUs in Fedora? (Intel D2500 and gma500_gfx)

[Pete Travis]

On Nov 14, 2013 5:05 AM, valent.turko...@gmail.com 
valent.turko...@gmail.com wrote:

 Friend of mine just showed me his cheap 13 laptop running Intel D2500
 and first thing he said that he had issue installing linux on it.

 When I asked about GPU and answer was Intel I assured him that for
 last 10 years I only used Intel GPU based laptops and had great
 experience.

 I tried Fedora 19 Live - failed to boot, then Linux Mint 15 - got to
 screen but with terrible artifacts on screen, check them out -
 http://youtu.be/mha7fZU1xFg, then tried latest Fedora 20 Live Beta 5 -
 boot starts with artefacts but fails to boot into desktop.

 Few hours later after reading up on this issue I managed to get laptop
 working with Linux Mint 15 (updated kernel to 3.11) but had to
 blacklist gma500_gfx driver, only then I get somewhat usable laptop
 (but with lower resolution and no video acceleration).

 I'm really interested what is the state of gma500_gfx driver in latest
 kernel, is it reasonable to expect that this driver will get updated
 and have better support or should I just say to my friend to grab
 version of Windows 7 and to run with it... any suggestions?
 --

I have a box with the same generation of Atom/PowerVR (Cedar Trail? Cedar
View? No access at the moment).  I can't get *any* display manager to work
reliably, but I can `xinit gnome-session` with reasonable results.  Once X
stops, whether from killing the process or switching targets, the GPU is
locked until reboot.

I gave the thing to a friend to use as an HTPC, and he gave it back saying
he couldn't find Windows drivers for it, and neither could I. I'm using it
as a disposable rawhide playground now.

If anyone really wants to hack out support for this I'd be happy to ship it
to them.

--Pete
-- 
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: Is Gnome Software ready for primetime ?

[Pete Travis]

On Oct 31, 2013 11:43 PM, Tim Lauridsen tim.laurid...@gmail.com wrote:


 On Fri, Nov 1, 2013 at 4:58 AM, Ankur Sinha sanjay.an...@gmail.com
wrote:

 It isn't a *package* management application. It's an *application*
 management application, ie., it only handles packages that are desktop
 applications (and therefore have desktop files associated with them).

 I'm guessing power users that want to install other packages will need
 to resort to the command line: yum/dnf/packagekit-cli. I'm not really
 sure about this though. Someone else might know better.


 All users can use yumex, if they want a package management gui, there can
install every thing they want
 but it is not installed by default in the Gnome desktop, so new user need
to find out how to install it or how to
 to use yum from the command line.

 Tim


 --

Hmm... It sounds like yumex would be much more discoverable if it included
an appdata file :)

--Pete
-- 
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: Packages have proxy word.

[Pete Travis]

On Oct 31, 2013 6:08 PM, مصعب الزعبي moc...@hotmail.com wrote:

 بسم الله الرّحمن الرّحيم

 Hi,

 The result of updating Fedora by yum is fail !!

 When any package have proxy word marked to (install or update) , error
message will appear with http 403 error forbidden.

 In my country Syria (maybe others) all URLs have proxy word are
forbidden and couldn't open by default way.

 In Fedora there are two common packages and have many updates:

 libproxy - sssd-proxy .

 Can to rename to :

 libproxies - sssd-proxies

 Or something else.

 Then do new rule to write proxies instead of proxy, at Fedora packaging
guidlines.



 Regards



 -=-=-=-=-=-
 Mosaab Alzoubi


You might have some luck with rsync. I *think* there's some tooling out
there to enable a mirror with only your required packages; if not, you can
create a wrapper script for it. Something like --excludes=$(yum list all
- yum list installed) might do. [not actual code]

--Pete
-- 
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: communications and community [was Re: Lack of response about sponsorship]

[Pete Travis]

On Oct 25, 2013 3:09 PM, Michael Schwendt mschwe...@gmail.com wrote:

 On Fri, 25 Oct 2013 13:54:27 -0700, Adam Williamson wrote:

  I'm sure the docs team talks about stuff in Rawhide occasionally too;

 Unlike devel, the docs list is related to Documentation only, isn't it?

 Could you imagine turning devel into a less general list?
 Is devel the catch-all for anything related to arbitrary
 development issues in the Fedora Project?

 doc-fol [no description available]
 docsFor participants of the Documentation Project
 docs-commitsFor tracking commits to Docs Project owned modules
 docs-qa Fedora Docs QA list

*snip*

This really isn't a fair comparison. Fedora Documentation is a distinct
product; in some contexts it is an upstream project using
Fedora/fedorahosted resources. For this discussion, citing, oh, the cobbler
mailing list would be just as effective.

--Pete
-- 
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: Lack of response about sponsorship

[Pete Travis]

*snip*


https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
 lists, how to get sponsored. Just waiting might be a solution, but
 probably not the fastest one.

 Matthias

 --

I don't agree with this.  The sponsorship process is as much an
introduction to the community as a verification that someone understands
the guidelines.  It was valuable to me as a new packager in this context,
and there is a lot of potential for the process to foster a sense of
collaboration and community.

--Pete
-- 
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 Working Groups: Call for Self-Nominations

[Pete Travis]

On Oct 10, 2013 8:20 PM, Kevin Kofler kevin.kof...@chello.at wrote:

 Matthew Miller wrote:

  On Thu, Sep 19, 2013 at 12:58:32AM -0400, Jens Petersen wrote:
   * Fedora Workstation
  Will this subsume Live-Desktop.iso and Live-KDE.iso?
  What about other current desktop Spins?
  Presumably some of these might have a secondary WG.
 
  Right -- one of the key things we need to do is work on the
infrastructure
  for building these products in general, and make that infrastructure
  available to SIGs for possible products outside the initial primary
ones.

 But the current spins will become even more second-class citizens than
they
 are right now, whereas 2 spins of dubious value to our real-world users
 (Server and Cloud) get featured instead. (How many people will really use
 those?) The Workstation (hidden GNOME) monoculture is also a completely
 unchanged continuation of the Desktop (hidden GNOME) monoculture with
just
 a new name (a name which is all the sillier considering that most Fedora
 users are home users). The addition of 2 non-desktop spins is only a lame
 attempt at papering over that GNOME monopoly.

 The selection of the 3 Products makes the whole concept of Products and
 Working Groups worthless and counterproductive. The selection of Products
 should have been based on the existing successful spins, and the Working
 Groups formed from the existing SIGs.

  What about the main toolchain, devel languages, and X/Wayland, etc?
  Would they fit in here too, or would they be covered by FESCo?
 
  They'd fit somewhere else -- roughly where they always have been. There
is
  an idea for something like the Fedora Commons, except we can't call it
  that because that name is taken by the _other_ Fedora (the digital
  repository software).

 Fedora Core? ;-)

 Kevin Kofler

 --

Are you then nominating yourself for a working group to create the fourth
product?

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Documenting Changes

[Pete Travis]

The Fedora Documentation Project, as part of the Changes process, is
using bugzilla tickets to track the documentation of Changes.  Those of
you tracking tickets for System Wide Changes probably noticed that I
recently cloned your bugs for this, and I'll move on to the and here's
what's going on:

First, you should know that you aren't expected to work on these
tickets.  Docs writers will take them, and the information already in
the Change page is usually enough to get the process rolling. It helps
if you can answer any questions that might pop up, of course.

Each Change ticket is blocking two docs tickets. One is to track
representation of the Change in the official Release Notes that are
shipped with the media and published to docs.fedoraproject.org . The
other is filed against the docs-requests component, which is
traditionally used to request new documentation or for task tracking.
This second bug is for us to do a general assessment of the existing
documentation - I'm expecting to do some tasteful grepping - and open
bugs for guides that need to be updated to reflect the Change.

While I've got your attention, I want to mention that if you have
anything interesting that might fit in the Release Notes - or any other
docs - you can jot a note in the wiki page at
https://fedoraproject.org/wiki/Category:Documentation_beats?rd=Docs/Beats ,
mail the list at d...@lists.fedoraproject.org , set the
fedora_requires_release_note flag in a bug, drop in to #fedora-docs.
Again, don't worry about presentation and such; it can be difficult to
know what needs to be written about in the distribution and a point in
the right direction really helps.

-- 
-- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org




signature.asc
Description: OpenPGP digital signature
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

Re: Review swap request: web-assets

[Pete Travis]

On Aug 23, 2013 6:00 PM, T.C. Hollingsworth tchollingswo...@gmail.com
wrote:

 Hi!

 Would someone be willing to trade me a review for:
 https://bugzilla.redhat.com/show_bug.cgi?id=997678

 It's dead simple at the moment: it just provides a couple directories and
RPM
 macros.  Later on it will grow some httpd magic but that's on hold until
Fedora
 21 since we're still sorting that out with Debian and it's past Change
Freeze.

 Thanks!
 -T.C.
 --

I'll take this. I have one that I'd like your insight on regarding the web
assets dir, conveniently; details to follow.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: no mention of interface naming in Fedora 19 Release Notes

[Pete Travis]

On Jul 16, 2013 11:22 AM, Andrew McNabb amcn...@mcnabbs.org wrote:

 Fedora 19 has gone through yet another change to how network interfaces
 are renamed (biosdevname, etc.).  This isn't mentioned in the Changes
 in Fedora for System Administrators section of the Release Notes,
 though it does seem to be in the Changes for Desktop Users section.


It is mentioned in the Networking section.  The entire document is arguably
relevant to a sysadmin, but I can see where placing that in the higher
level Desktop category might be confusing.  This bears examination for the
next release, IMO.

 Is there any reason that this isn't mentioned in the Changes in Fedora
 for System Administrators section of the Release Notes, and is it too
 late to add it there?

Many changes could arguably fit into multiple beats - subcategories in the
document - and we try to pick the most appropriate one. Desktop changes vs
system administrator changes is mostly a way to organize content rather
than define scope, and perhaps an unneeded one.

Yes, it is too late to change this.  I might take time away from other work
for outright factual errors and such, but not for an aesthetic
reorganization.

By the way, d...@lists.fedoraproject.org might be more appropriate.


 --
 Andrew McNabb
 http://www.mcnabbs.org/andrew/
 PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868
 --


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

Re: F20 Self Contained Change: Application Installer

[Pete Travis]

On Jul 10, 2013 5:25 AM, Jaroslav Reznik jrez...@redhat.com wrote:

 = Proposed Self Contained Change: Application Installer =
 https://fedoraproject.org/wiki/Changes/AppInstaller

 Change owner(s): Richard Hughes rhug...@redhat.com, together with the
 desktop team

 We will replace the existing gnome-packagekit frontends
(gpk-update-viewer and
 gpk-application) by a new application.

 == Detailed description ==
 The current PackageKit frontends are focused on (surprise!) packages.

 The new tool, tentatively named gnome-software, is designed from the
beginning
 for installing applications. It will present applications with information
 that is relevant to users (screenshots, reviews, descriptions,
ratings,...)
 instead of information that is relevant for packagers (dependencies,
package
 size, file lists,...).

 It will be possible to search and browse for available applications.

 gnome-software will also be used to present information about available
and
 installed updates. Notifications about available updates will launch
gnome-
 software if the user chooses to see details. gnome-software will be fully
 integrated with 'offline updates' - if an update includes system
packages, it
 will be done as an offline update, regardless whether it gets initiated
from the
 gnome-shell menu, a notification, or the gnome-software UI.

 To improve some problematic aspects of the updates user experience (long
 waits, locks), we will use the new hawkey backend for PackageKit.

 == Scope ==
 Proposal owners:
 * Implement minimal required functionality for application installation in
 gnome-software
 * Implement minimal required functionality for updates in gnome-software
 * Replace gpkg-update-viewer
 * Package gnome-software
 * Include a hawkey backend in PackageKit and use it

 Other developers:
 * Use gnome-software instead of gpk-update-viewer when dealing with
updates in
 gnome-settings-daemon, gnome-shell and gnome-control-center

 Release engineering:
 * Make metadata available for packaged applications in Fedora
(screenshots,
 icons, ratings,...). Not all of this needs to be in place for F20

 Policies and guidelines:
 * No immediate changes needed; longer-term, we probably want to make
changes
 to way applications are distributed and installed
 * The update experience will also benefit from proposed changes to batch
 updates

 ___

A few questions:

How does gnome-software differentiate between user facing applications and
other packages, ie back end dependencies, system libraries, texlive
packages? What role do maintainers have in making this distinction, and by
what process?

Where does the additional user facing metadata live? How can maintainers
provide it for their packages, and in what format? Will other packagekit
applications be able to take advantage of it, or just gnome-software?

Thanks,

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

Re: icedtea-web installed and enabled by default in Fedora 19

[Pete Travis]

On Jun 17, 2013 9:03 AM, Bill Nottingham nott...@redhat.com wrote:
...
  
 
  I think given all the trouble this plugin has caused recently, it
wouldn't
  be wise to install it for everyone. If you need it, great, install it,
but
  if a users doesn't need it, it's really just creating a level of risk we
  probably don't want.
 
  Fedora currently has a reputation for being pretty secure, I think this
  could damage that reputation.

 The one issue I can see with removing it is that the plugin finder you
 then get in Firefox if you hit a Java site doesn't work to actually get
you
 the Fedora version.

 Bill
 --

+1

This is a strong argument for installing it by default. What would be more
secure - the distro maintained package or the user maintained tarball or
rpm without repo? The users that need help with security the most are the
users that will follow the inline instructions by rote, without searching
the repositories.

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

Re: git rebase master

[Pete Travis]

On May 27, 2013 11:17 AM, Sérgio Basto ser...@serjux.com wrote:

 Hi,
 git puts me crazy

 in here :
 http://pkgs.fedoraproject.org/cgit/debconf.git/

 I have master now correct and want F19 be the same (git merge master)
 but do a commit just in F19, seems that never will be the same .

 I try
 fedpkg switch-branch f19
 git rebase master

 merges conflict ???
 I just want F19 be a copy master who I can do that ?

 Thanks,
 --
 Sérgio M. B.

 --
I've been using
git checkout $targetbranch; git checkout $sourcebranch --
relative/path/to/file
to pull $file from $sourcebranch to $targetbranch. Globbing with * works,
too. I have no idea if this is the best approach, but it works for my
purposes.

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

Re: Maintainer input on release notes

[Pete Travis]

On Wed, May 15, 2013 at 12:04 AM, Dan Mashal dan.mas...@gmail.com wrote:

 On Mon, May 13, 2013 at 12:52 PM, John J. McDonough wb8...@arrl.net
 wrote:
  We had a short discussion of this at this morning's meeting but felt a
  broader discussion here was warranted.
 
  When preparing the Release Notes, we often ask the developers for wiki
  input, and generally come up dry. More recently, we look though the
  repos for changes, but the upstream release notes are often very poor or
  nonexistent. Every release includes literally thousands of changed
  packages, and while we strive to document significant changes, these
  poor upstream release notes leave us little clue as to what constitutes
  significant.  Certainly the feature pages get us started, but they
  only capture a tiny fraction of what changes in a release.
 
  But if we think about the maintainers, chances are they begin working on
  the next thing just as soon as the compose closes for the previous
  release, if not sooner.  Very likely they have an interest in the
  packages they are maintaining, and it would not be surprising if they
  viewed some features to be important.
 
  But by the time we ask for input, odds are they have moved on and most
  of the updated packages in the new release are ancient history.
 
  However, if we were to open the beats as soon as possible, certainly
  when the compose closes or even as soon as we have converted the beats
  to XML, then the developers could make a note in the wiki about what is
  significant, right at the time they are working on it and interested in
  it.
 
  Of course we would still need to remind the maintainers that we want
  their input, and especially that it doesn't need to be beautiful prose -
  all we really need is a clue as to what is important.  But I think if we
  can capture the input early, we have better odds of getting more
  complete release notes.
 
  Is this something we should do?  Is there something different we should
  be doing?
 
  --McD

 I think you should focus on Common Bugs and work with the IRC support
 SIG.

 Dan
 --



I think the Common Bugs are well handled by the QA team and effectively
feature-complete.  The docs writers could probably benefit from a feedback
loop with the IRC folks, I like that idea.  It would help improve the
guides - but not the Release Notes.

The goal of John's idea is to track changes better by keeping up with the
developers.  The existing communication channel includes
https://fedoraproject.org/wiki/Category:Documentation_beats?rd=Docs/Beats ,
which gets cleared around branch time and worked on until beta composes
start.  Opening the release note beats earler is an effort to change the
docs process to better align with the packagers' workflow.

Here's the question: If we clear this wiki space *now*, at this point in
the release cycle, would you use it?  If the wiki isn't an effective way to
point us at the changes you're currently working on for F20 and beyond, is
there something better?

I'll cite an example that demonstrates the changelog problem John refers
to, then share a little of our process, and the issue might make a little
more sense:

In writing the release notes, I noticed `pavucontrol` had been bumped to
version 2.0. I'm not picking on it's maintainers - I *like* pavucontrol,
and pulseaudio as a while - but I couldn't find out what had changed.
/usr/share/doc/pavucontrol-*/ had no NEWS or CHANGELOG. The packaging
changelog  said ~Updating to v2.0. The upstream website had an equally
release announcement, and their public git repo hadn't seen a commit since
March 2011.  Actually getting a diff of the source and sorting out the
changes would take more time than a single package might merit.

So, a package gets a major version bump and I'm silent about it.  There
might be some really interesting things in there, and I might be just as
silent about well documented changes in other packages because I didn't
know or think to look for them.  What we do come up with gets piled into
the release notes, which is used as a base for marketing materials like
release announcements and talking points.  These interesting changes might
miss marketing attention and press interest they would otherwise have
benefited from.

The public at large reads the Release Notes (albeit often secondhand) and
accepts them as the representation of the package maintainers' work. The
docs writers can create a better product with developer help, and we're
asking for input on how to make that process work.

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

Re: Do you think this is a security risk and if not is it a bad UI decision?

[Pete Travis]

On Fri, May 3, 2013 at 9:40 PM, M. Edward (Ed) Borasky zn...@znmeb.netwrote:

 I didn't notice this the last time I did an install. But yes, it's a
 *problem* if it does that. I'll upvote or whatever if someone re-opens; I
 do so many installs in coffee shops that I would flat out not use a distro
 that did this!





Regardless of the arguments for either position, whether for ease of use
and
pseudosecurity or for peace of mind and tradition, I think the above will
be the
reaction
from the world at large.  There may be valid and convincing reasons to
cease
obfuscating passwords, but doing so would put Fedora supporters in the
position of
presenting those justifications regularly.

Personally, I think it presents a false sense of security, and any valid
concerns can
easily be rectified by changing the password after installation.  However,
users
**expect** that security, and the result of removing it will be calamitous.
We'll get
lambasted by the tech press, flamed on user forums, and dejected
head-shaking in
server rooms.  Opportunities to provide a righteous counterargument will be
few and
readily dismissed.

I'll make a small concession here. The demographic most affected by the
propaganda
I'm describing are casual or inexperienced users, and not part of Fedora's
traditional
user base.Keep in mind that these users are also prospective Fedora
users, and
have the potential to gain experience, become proficient, and perhaps even
become
active contributors.

People **will** bitch about being able to read the password as they type
it.  Any
Press
is Good Press is a bromide that Fedora shouldn't test.

- Pete Travis
 - Fedora Docs Project Leader
 - 'randomuser' on freenode
 - immanet...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How do *you* use Fedora?

[Pete Travis]

On Thu, Apr 4, 2013 at 9:55 AM, David Lehman dleh...@redhat.com wrote:

 On Thu, 2013-04-04 at 08:59 -0400, Matthew Miller wrote:
  On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote:
   equated to the memory requirements for the running environment,
 especially
   for cloud guests. @minimal requires less memory to install than a full
   desktop - but does anyone want to run Fedora with less memory than
 that, or
   is doing so venturing out of reasonable guidelines and into
   proof-of-concept adventureland?
 
  Yes, people want to run Fedora in VMs with less memory than that. (Key
  demographic: large computer science classes.)

 Would those classes be installing the VMs themselves, or would the
 instructor/assistant do that beforehand? If the latter, this is a
 perfect case for anaconda's install-to-a-disk-image-file capability and
 makes little sense to handle by doing dozens of interactive
 installations.

 Dave



I wasn't aware of this compelling capability. I experimented with it a bit;
encouragingly, I can create an image with qcow-create that anaconda
recognizes, but I haven't sorted out how to run anaconda from the command
line without it taking over the system that runs it, with varying degrees
of success. The functionality seems... inconsistent. Is this the way I'm
using it[1] ?

[1] ssh to a guest to I don't kill my workstation
# ssh targetvm anaconda --kickstart=http://host/ks.cfg--image=/root/anaconda.img


-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize at fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How do *you* use Fedora?

[Pete Travis]

On Apr 5, 2013 2:23 PM, David Lehman dleh...@redhat.com wrote:

 On Fri, 2013-04-05 at 08:59 -0600, Pete Travis wrote:
  On Thu, Apr 4, 2013 at 9:55 AM, David Lehman dleh...@redhat.com
  wrote:
  On Thu, 2013-04-04 at 08:59 -0400, Matthew Miller wrote:
   On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote:
equated to the memory requirements for the running
  environment, especially
for cloud guests. @minimal requires less memory to install
  than a full
desktop - but does anyone want to run Fedora with less
  memory than that, or
is doing so venturing out of reasonable guidelines and
  into
proof-of-concept adventureland?
  
   Yes, people want to run Fedora in VMs with less memory than
  that. (Key
   demographic: large computer science classes.)
 
 
  Would those classes be installing the VMs themselves, or would
  the
  instructor/assistant do that beforehand? If the latter, this
  is a
  perfect case for anaconda's install-to-a-disk-image-file
  capability and
  makes little sense to handle by doing dozens of interactive
  installations.
 
  Dave
 
 
 
 
  I wasn't aware of this compelling capability. I experimented with it a
  bit; encouragingly, I can create an image with qcow-create that
  anaconda recognizes, but I haven't sorted out how to run anaconda from
  the command line without it taking over the system that runs it, with
  varying degrees of success. The functionality seems... inconsistent.
  Is this the way I'm using it[1] ?
 
 
  [1] ssh to a guest to I don't kill my workstation
  # ssh targetvm anaconda --kickstart=http://host/ks.cfg
  --image=/root/anaconda.img

 I found a bug just a few minutes ago that would prevent disk image
 installs from working as expected [1]. There may be other issues lurking
 as this is an under-used piece of functionality. Your usage seems fine.


 [1] When disk images are specified they automatically become the
 exclusive set of usable disks. The bug I found earlier marks all disks,
 including the disk image, as unusable.

 --

I thought this exclusivity was the expected behavior, although I only did
quick glance over the code.  The problem seems to stem from running
anaconda on an existing system rather than booting into anaconda.

I'll play around with this some more, and follow up with bug reports, or a
thread on anaconda-devel@ if you'd prefer. This thread is giving me a lot
to ponder...

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

Re: How do *you* use Fedora?

[Pete Travis]

On Tue, Apr 2, 2013 at 5:56 PM, Matthew Miller mat...@fedoraproject.orgwrote:

 On Tue, Apr 02, 2013 at 03:28:21PM -0700, Adam Williamson wrote:
  I'm considering system specs at this point, but establishing the roles
  deployed might aid in targeting more comprehensive documentation.
 Beyond a
  basic desktop, what use cases would you like to see us represent?
  Cloud guest, please.
  What kind of cloud? What kind of guest?
  I'm worried that this will turn into a very large and amorphous
  effort.

 Sure; let's start concrete -- Amazon EC2, starting at M1 Small. If we can
 make it run nicely on Micro instances (and I don't see why not), so much
 the
 better.


  Trying to pin down 'typical Fedora use cases' seems rather like trying to
  box a cloud.

 Maybe we could at least try to describe the cloud a bit, though? That one
 looks like a fluffy bunny

 --
 Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  
 mat...@fedoraproject.org


 --

I'm not sure we need to get too specific - at least, we can't make specific
claims unless someone can validate function, which I can't personally do
for cloud guests - but it would be nice to claim function on a certain
class of node. Once we clear the installer hurdle, a minimal system doesn't
need much.

Clearly, the memory requirements of the installation environment can't be
equated to the memory requirements for the running environment, especially
for cloud guests. @minimal requires less memory to install than a full
desktop - but does anyone want to run Fedora with less memory than that, or
is doing so venturing out of reasonable guidelines and into
proof-of-concept adventureland?


-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize at fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

How do *you* use Fedora?

[Pete Travis]

Hello,

The docs team has begun assembling release notes for Fedora 19, and I've
been thinking over hardware requirements.

Historically, we have cited the CPU, storage, and especially memory
requirements for the default installation - a basic GNOME desktop.  I'd
like to reexamine that practice, with input from the development community.
Fedora is too versatile a product to document so narrowly.

A few considerations come immediately to mind, but please don't limit
yourself to the examples:
Modern composited desktops like GNOME and KDE need better graphics hardware
than XFCE or MATE.  Headless servers would benefit from better NICs or
storage controllers, but not require them. Purpose driven virtual machines
clearly need fewer resources than the machine that hosts them.

I'm considering system specs at this point, but establishing the roles
deployed might aid in targeting more comprehensive documentation. Beyond a
basic desktop, what use cases would you like to see us represent?

-- Pete Travis
- Fedora Docs Project Leader
- 'randomuser' on freenode
- immanetize at fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Is there a reason we do not turn on the file system hardlink/symlink protection in Rawhide?

[Pete Travis]

On Mar 15, 2013 10:13 AM, Rahul Sundaram methe...@gmail.com wrote:

 On 03/15/2013 10:52 AM, Chris Adams wrote:

 I agree that it doesn't really need a feature page, but IMHO it should
 be in the release notes (this is something that could break existing
 programs).

  Here you go

 https://fedoraproject.org/wiki/Documentation_Security_Beat

 Rahul

 --

That is an excellent explanation, thanks Rahul!

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

Re: Fedora Knowledge Base / Help Center Idea

[Pete Travis]

On Mar 13, 2013 11:31 AM, Máirín Duffy du...@fedoraproject.org wrote:

 On 03/13/2013 11:53 AM, Nils Philippsen wrote:
  I imagine that some kind of well discoverable (e.g. advertised during
  installation, or in the default browser homepage) knowledge-base beyond
  installation guides, release notes e.a. could get us a far way, which
  would have vetted information about troubleshooting (So you updated and
  sound/wireless/suspend broke? Here's what you should check and
  how: ...) and power-user-ing (So we welded the hood in Fedora a little
  too shut for your taste? While we're busy munching self-baked cookies by
  the thankful Aunt Tilly, here's how you gnaw the hood open again: ...).
  That this needs a little cooperation on the OS components side is
  obvious, workarounds for power users either need to stay stable, be
  replaced by something more or less equivalent (with updated
  documentation), or rendered obsolete.

 I think this is a fantastic idea. Actually Ryan did a set of conceptual
 mockups for such a thing. We need some help developing the design omre
 and also someone to build it, though. We could advertise it during the
 ransom notes in anaconda if need be.

 The idea here is that it would be a desktop app that would aggregate
 information from ask.fedoraproject.org (as a kbase backend) as well as
 the Fedora docs, so you could search all places at once. If you were in
 a rough state and couldn't access the network or use the desktop, you
 could access those same resources directly on line and get the answers.
 We'd have to populate ask.fedoraproject.org with some good
 question/answer articles though for this to work well, but it's pretty
 easy to do given the content.

 https://fedoraproject.org/wiki/Design/Help_Center_Idea

 ~m
 --

While I like this idea in principle, I don't think we should actually put
it into practice.  Here's why:

The docs team has limited cycles as it stands. I realize that the proposal
isn't necessarily asking anything of them, but we aren't keeping up with
the existing guides as well as I'd like. If the current offerings at
docs.fedoraprojects.org aren't sufficient, we should be focusing our
efforts there.

Pulling content from Ask Fedora would require technical curation and
editing for presentation. That effort could be put towards existing guides.
Yes, the guides can be monolithic and a more atomic presentation would be
easier to navigate - but we can address that as a shortcoming of the
existing solution.

The your proposal competes with the docs team for the user attention,
current contributors' time, and potential contributors' attention.

Fwiw, we have been floating some ideas that might serve the same end goals.
The docs.fedoraprojects.org is getting a new backend, and possibly new
presentation if I, or someone, can work up some CSS for the Fedora publican
brand. We've discussed shipping guide rpms in the user repositories, and
even gnome-shell search integration after that. We've casually discussed
posting smaller topical articles.

Guides are getting updated too, of course. More writers make for better
docs, so if you want that for our users, please help write docs instead of
competing.

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

Re: Fedora Knowledge Base / Help Center Idea

[Pete Travis]

On Mar 13, 2013 1:55 PM, Rahul Sundaram methe...@gmail.com wrote:

 On 03/13/2013 02:52 PM, Pete Travis wrote:

 .

 Guides are getting updated too, of course. More writers make for better
docs, so if you want that for our users, please help write docs instead of
competing.


 Have you thought about the possibility that a friendly user interface for
documentation is not a competition but might help to actually bring new
writers?

 Rahul

 --

I think my conclusion was poorly posed, sorry. Yes, I think a more
accessible presentation of docs would help bring in new writers. I'd like
to see that almost as much as new members on the docs team. If one follows
the other, great. It just seems more logical for the relationship to work
the other way.

My goal in speaking up is to prevent redundant efforts, not kill the
conversation.

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

Re: Improving the Fedora boot experience

[Pete Travis]

On Mar 12, 2013 9:12 AM, Peter Jones pjo...@redhat.com wrote:

 On UEFI systems, which is most new desktops:

 1) we don't need any grub UI whatsoever
 2) we don't need the 5 second timeout
 3) we don't need to indicate to the firmware that we need USB probed
 unless it's the device we're booting from.


 --
 Peter
 --

This seems like a sane default to me, accommodating both end users that
don't care about GRUB or that don't dual boot, and 'power' users that can
learn to hold down a key.

For the use cases where it doesn't work, what about dropping a bootloader
config spoke into anaconda, or revealing the appropriate features in
kickstart options? Perhaps probing to test for dual boot to determine if a
brief timeout should be the default?

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

Re: Request for a firewalld secondary DHCP + PXEBOOT HOWTO

[Pete Travis]

On Feb 15, 2013 6:39 AM, Aaron Gray aaronngray.li...@gmail.com wrote:


 Pete,

 Yeah that's the easy bits, they need details too. The bit I have yet to
find out how to do is to forward HTTPS and DNS ports between the
primary internet network and the secondary DHCP BOOTP network on
192.168.1.x. I had this working on Shorewall but have taken the time to
work it out on iptables or firewalld ideally and was hoping for a quick fix
without having to reread iptables docs or learn firewalld configuration.

 Cheers for the link,

 Aaron

Port forwarding is simply and clearly documented in 'man firewall-cmd'.
Unless you're looking for masquerading, which is easily done per the man
page as well. I believe there are some firewalld docs in the works, fwiw.

Serving the installation repository from an outside network is a use case
straying from the norm; I wouldn't consider the installation guide lacking
because it does not document it.

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

Re: Non-responsive Maintainer: mediawiki

[Pete Travis]

On Feb 15, 2013 5:34 AM, Adam Williamson awill...@redhat.com wrote:

 On 08/02/13 01:36 PM, Pete Travis wrote:
.

 I haven't poked at mediawiki in a while, so please correct me if I'm
 wrong, but isn't it fairly self contained? I recall copying the content
 from /usr/share/ to /var/www/ then localizing. Having a new version
 shouldn't break existing deployments unless they are served out of
 /usr/share/, and that doesn't seem sane. The update would then be
 available, not imposed.


 I may be misunderstanding you, but I _think_ you've got the wrong end of
the stick here. Fedora webapps are indeed packaged to be served out of
/usr/share/whatever . They ship with /etc/httpd/conf.d config files which
point to the /usr/share location where they are installed. This is all by
policy and How It's Supposed To Be. Only files that absolutely need to be
actually inside /var/www for some reason or another are supposed to be
packaged there. In general, the idea is that webapp files are just static
data files like any others and belong in /usr/share . See
https://fedoraproject.org/wiki/Packaging:Guidelines#Web_Applications .

 You can copy the whole thing to somewhere else (e.g. /var/www) and
nerf/adjust the conf.d file if you really want to use the Fedora package
only as a base for your own deployment, but that's not the 'normal way'. In
general you're expected to simply install the package and use it; that way
you get the benefit of packaged updates.
 --
 Adam Williamson
 Fedora QA Community Monkey
 IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
 http://www.happyassassin.net

 --

Thanks for straightening me out, Adam. I'll have to poke at this to better
understand it when I get the chance.

Interestingly, 'repoquery -l'  does show some of the mediawiki packages
owning files in /var/www/. Whether grandfathered, broken, or just
misconception, I'll keep further comment to myself until I can play with a
VM.

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

Re: Request for a firewalld secondary DHCP + PXEBOOT HOWTO

[Pete Travis]

On Feb 9, 2013 3:47 AM, Aaron Gray aaronngray.li...@gmail.com wrote:

 On 7 February 2013 16:41, Jóhann B. Guðmundsson johan...@gmail.com
wrote:

 On 02/07/2013 04:23 PM, Aaron Gray wrote:

 Can someone who knows firewalld please do a HOWTO to on setting up a
secondary DHCP with DNS and HTTPS access for PXEBOOTing of Fedora18 please
to go with the PXEBOOT HOWTO :-

 http://linux-sxs.org/internet_serving/pxeboot.html

 Hope someone can help, I put I message on the User List but got no
response.



 Well what seems to be standards sysadmin practice with firewalld on
servers is to disable it and enable iptables.

 Firewalld is aimed at desktop users and roaming hardware which makes
zones useless concept for static server within an corporate
infrastructure.

 So the missing steps for your guide simply are...

 systemctl stop firewalld*
 systemctl disable firewalld*
 systemctl enable iptables.service
 systemctl start iptables.service



 Jóhann,

 That's okay so far, sort of makes sense, but I though firewalld had
equivalent functionality to iptables. Anyway I still need a HOWTO on
setting up a secondary DHCP on a second Ethernet controller in order to run
PXEBOOT.

 Thanks for the reply anyway,

 Aaron



Have you looked at
http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/sn-pxe-server-manual.html?
If so, can you elaborate on what is missing?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Request for a firewalld secondary DHCP + PXEBOOT HOWTO

[Pete Travis]

On Feb 14, 2013 12:03 PM, Pete Travis li...@petetravis.com wrote:


 On Feb 9, 2013 3:47 AM, Aaron Gray aaronngray.li...@gmail.com wrote:
 
  On 7 February 2013 16:41, Jóhann B. Guðmundsson johan...@gmail.com
wrote:
 
  On 02/07/2013 04:23 PM, Aaron Gray wrote:
 
  Can someone who knows firewalld please do a HOWTO to on setting up a
secondary DHCP with DNS and HTTPS access for PXEBOOTing of Fedora18 please
to go with the PXEBOOT HOWTO :-
 
  http://linux-sxs.org/internet_serving/pxeboot.html
 
  Hope someone can help, I put I message on the User List but got no
response.
 
 
 
  Well what seems to be standards sysadmin practice with firewalld on
servers is to disable it and enable iptables.
 
  Firewalld is aimed at desktop users and roaming hardware which makes
zones useless concept for static server within an corporate
infrastructure.
 
  So the missing steps for your guide simply are...
 
  systemctl stop firewalld*
  systemctl disable firewalld*
  systemctl enable iptables.service
  systemctl start iptables.service
 
 
 
  Jóhann,
 
  That's okay so far, sort of makes sense, but I though firewalld had
equivalent functionality to iptables. Anyway I still need a HOWTO on
setting up a secondary DHCP on a second Ethernet controller in order to run
PXEBOOT.
 
  Thanks for the reply anyway,
 
  Aaron
 
 

 Have you looked at

http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/sn-pxe-server-manual.html?
If so, can you elaborate on what is missing?

Oops, that should be
http://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/sn-pxe-server-manual.html
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Non-responsive Maintainer: mediawiki

[Pete Travis]

On Feb 8, 2013 12:54 PM, Stephen John Smoogen smo...@gmail.com wrote:
. Two the fix is to upgrade to a very new
 version which will break everyone who upgrades until they (or the
 first person who gets to the website :) ) runs the upgrade mode..
 which might not work due to either custom changes or the fact that it
 is a large upgrade change.

 --
 Stephen J Smoogen.

I haven't poked at mediawiki in a while, so please correct me if I'm wrong,
but isn't it fairly self contained? I recall copying the content from
/usr/share/ to /var/www/ then localizing. Having a new version shouldn't
break existing deployments unless they are served out of /usr/share/, and
that doesn't seem sane. The update would then be available, not imposed.

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

Re: Proposed F19 Feature: Cinnamon as Default Desktop

[Pete Travis]

On Jan 28, 2013 9:56 AM, inode0 ino...@gmail.com wrote:

(snip)

 I'm happy to see renewed discussion about the future of the Fedora
 desktop. After four releases it isn't bad to step back and take a look
 at how things are working out. I hope we can do that with an eye to
 where we want to go in the future rather than looking to the past.

 John
 --

This seems like the most productive track we can follow. As a downstream
consumer of GNOME, what can the Fedora Project do to address or remedy user
dissatisfaction with our default DE? If the answer is 'nothing, we just
have to accept what they ship' then there isn't much to say. If there is
room for a feedback loop, what would it look like?

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

Re: Feedback wanted: Fedora Formulas

[Pete Travis]

On Jan 9, 2013 12:32 PM, Nathanael D. Noblet nathan...@gnat.ca wrote:

 On 01/09/2013 12:26 PM, Seth Vidal wrote:




 On Wed, 9 Jan 2013, Kevin Fenzi wrote:


 One of the big questions to answer is distribution. I can see good
 arguments on the one hand distributing formulas via RPM and on the
 other having an official Git repository for them.


 Yep. I am torn here too. rpms get us a lot, but are also inflexable in
 other ways. :)


 Let me make an argument against rpms here.

 Ansible doesn't require anything on the local system to run a playbook.

 That's one of its virtues.

 For a user if we just use a git repo then the user doesn't have to
 modify their system in order to use the tools to change their system.

 There is a certain amount of elegance in that not to mention just not
 being annoying.


 It also allows a user to take a recipe, fork, modify, improve etc and
test it without necessarily knowing anything about rpm... or being a
packager in the packager group etc. Having a fedora account etc...


 --
 Nathanael d. Noblet
 t 403.875.4613

 --
I really like this idea.  A curated, task oriented system helps
inexperienced users get it right and advanced users work more efficiently.
The concept is highly marketable. Properly maintained, we could save scores
of users from the scourge of outdated, inaccurate, or potentially harmful
procedurals that a broad Google search might dig up.

With that in mind, I have to disagree with the comments above. Presenting
this as a playground for inexperienced users negates the benefit of
curation and compounds the very problems I think it should solve. Not that
the functionality shouldn't be there, of course, but the presentation
should stress quality over extensibility.

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

Re: GRUB menu hidden by default?

[Pete Travis]

A simple short term solution might be to purge this statement from the
documentation for affected releases. If we should expect the splash only in
certain cases, of course the docs should state that expected behavior.

Since you folks are testing, would anyone mind filing a bug against the
documentation?

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

Re: RFC: Feature process improvements

[Pete Travis]

 I don't see why these are features at all.  Surely it's better towards
 the end of each release cycle for someone to compare the versions of
 packages and add something in the release notes for each major GUI /
 programming language / user application that got a big update.

 Rich.


I only have a comment relative to the release notes.  I agree that the
release notes are the appropriate place to 'feature' changes that might not
meet the requirements of a 'Feature' .  Comparing the version numbers is
even relatively easy - we use a script for the Technical Notes that parses
repository sqlite meta data and effectively spits out the fully formed TNs.

This doesn't scale well to the verbose content expected in the release
notes. A human still needs to identify changes,  apply context, interpret
scope and write the actual content. Determining what should be included and
what changed is labor intensive.

There are several mechanisms for a developer to get their work into the
release notes. The rel-notes BZ tag was wholly unused during this cycle, to
the best of my knowledge. There were no bugs filed against the
release-notes bugzilla product to request inclusion.  When no emails were
sent to the Docs mailing list, we put out a request on devel-announce for
developers to get in touch; the only person that responded already had a
well composed Feature page for us to work from.

So here's my suggestion :
The guidelines for Features, however they turn out, should direct
developers to contacting the Docs team in some way if the feature
requirements are not met. We can still give our hard working contributors
the appropriate exposure, but there are *far* more developers than docs
maintainers and we need their help.

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

F18 Release Notes

[Pete Travis]

Greetings!

   As the Fedora Documentation Project prepares the release notes for
Fedora 18, we'd like to ask for your help.  Each Fedora release marks
the inclusion of new features and the retirement of others, and with
the help of the development community, we won't skip a beat. The Docs
team would like you to assign us some homework.

   The release notes are divided up into categories, or 'beats.' Each
beat is kept by a volunteer who follows mailing lists, changelogs,
announcements, and features in the space. Many beats also have a
developer point of contact for technical questions and cooperation. We
track these responsibilities with
http://fedoraproject.org/wiki/Category:Documentation_beats , which
includes links out to wiki pages for each individual beat.  As we
reach the end of the release cycle, developers and docs maintainers
populate these pages, then they are converted from wiki markup to
Docbook XML and published. With a little help, we can put out release
notes that can't be beat.

   If you're working on something for Fedora, we'd like to make sure
you get the credit you deserve. Leave us a quick note on a beats page,
send it to our mailing list (
http://lists.fedoraproject.org/mailman/listinfo/docs ), or join us in
#fedora-docs. You don't need to worry about language and composition
or even spelling - just let us know what you've been working on that
you'd like documented and we'll take it from there.

   We *really* don't want you to beat yourself up about presentation.
A simple make sure you mention this new feature is enough. We're
happy to do the research and compose the prose. Knowing where to start
writing makes the process considerably more efficient, just as a brief
note on hundreds of features from each developer is more effective
than a handful of docs maintainers trying to follow all of hundreds of
features.

   Thanks for helping us represent your work to the users,

Pete Travis,
The Fedora Docs Team
___
devel-announce mailing list
devel-announce@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce