Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Ian Malone]

On 18 June 2018 at 11:27, Zbigniew Jędrzejewski-Szmek  wrote:
> On Sun, Jun 17, 2018 at 11:13:39PM +0100, Ian Malone wrote:
>> On 16 June 2018 at 13:50, Björn Persson  wrote:
>> > Tomasz Kłoczko wrote:
>> >> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
>> >> [..]
>> >> > Don't forget that if your proof of concept can be modified to either
>> >> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
>> >>
>> >> before ~/.bashrc is executed many other scripts  executions
>> >> already is finished
>> >
>> > This is true and completely irrelevant.
>> >
>> >> Whatever you want to do over you account session or profile scripts it
>> >> is already _to late_.
>> >> Is that clear now?
>> >
>> > No it's not clear. I have no idea why you're rambling about the order
>> > in which Bash executes its startup files. The order doesn't matter,
>> > especially since the hypothetical attacker is supposedly unable to
>> > modify those files.
>> >
>> > You claimed to have a proof of concept that would demonstrate how some
>> > security hole can be exploited if and only if ~/.local/bin is listed
>> > before /usr/bin in PATH. I asked you to post your proof of concept. You
>> > didn't. I will therefore conclude that you don't actually have one.
>> >
>>
>>
>> Well, two things:
>>
>> 1. For example, a kiosk mode, where the home directory is wiped each
>> login would be made less secure. The profile for the GUI is set at
>> login, so writing .bash_profile has no effect on the GUI environment,
>> but an attacker able to place files where the user has write
>> permission could mask system binaries.
>
> Even if .bash_profile is not always read, .bashrc is read every time
> a shell is started (OK, not "every time", but often enough). So for
> example if I open a new tab in the terminal, or run some scripting plugin
> from an editor, etc, the effect is the same as overwriting .bash_profile.
>

But these assume you are only attacking the shell. The system path is
used to resolve commands started from the gui too, independent of
bash.

> But more generally, if one uses a public kiosk that somebody else had
> logged into first, for *any* purpose requiring security, that is a
> grave mistake already. How would one even know that the gui they are
> accessing hasn't been substituted wholesale?
>

This is a misdirection. We can still worry about an attack on a user
logging into a clean profile (the case I was discussing), or from the
point of view of the kiosk administrator concerned with ensuring the
security of their users, the system itself and the network it's
attached to. To put it another way, you probably use a proprietary CPU
in your computer, how do you know it's not compromised? Why do we
worry at all about security if you can't guarantee that?

>> But a more major worry for me here, the reason I'm bothering to reply
>> to a thread about setting paths (though to be honest, someone who
>> doesn't understand how to do that may not have much business
>> installing unpackaged software, particularly when the examples are
>> developer tools):
>>
>> 2. The fact that a proof of concept cannot be provided is not a proof
>> that a change you make is secure. Take Spectre; that vulnerability has
>> been around for decades with no public proof of concept, or even
>> knowledge there was a vulnerability, yet it can be exploited from
>> Javascript in a browser. So this repeated insistence on providing a
>> proof of concept before a security concern is taken seriously is
>> fundamentally wrong, and I would be concerned to see it applied
>> elsewhere in Fedora.
>
> In this case we understand what the change in behaviour means, we just
> seem to disagree on how significant this is. We even know how any such
> exploit would look. The calls to provide a POC have the intent to take
> any such POC and tweak it to modify .bash_profile/.bashrc/.i18n instead,
> and thus turn the discussion around by showing that $PATH order is
> irrelevant to the attack.
>

Fundamentally flawed approach, since you are assuming you know the
constraints an attacker is working under, here you assume that they
are able to freely write to all locations the user can access. This
may not always be the case. An attacker's first job is to leverage a
weakness to gain that control. As I mentioned what worries me most is
this attitude that you must be smarter than the attacker and that you
do not need to think defensively because of that.


-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OKVKAN4NTSNP5WAWGFSEFLUWUABDU47H/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Ian Malone]

On 18 June 2018 at 00:49, Tomasz Kłoczko  wrote:
> On Sun, 17 Jun 2018 at 23:23, Ian Malone  wrote:
> [..]
>> Well, two things:
>>
>> 1. For example, a kiosk mode, where the home directory is wiped each
>> login would be made less secure. The profile for the GUI is set at
>> login, so writing .bash_profile has no effect on the GUI environment,
>> but an attacker able to place files where the user has write
>> permission could mask system binaries.
> [..]
>
> Do you want to say that Linux on the kiosk type system requires
> /usr/local based paths on the front of the $PATH?
> If not .. sorry to say this but somehow you lost context of the
> discussion is, and you just started adding some random comments.
> Please don't this.
>

No I did not, please re-read original email and the one I was replying to.


-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JOQLGL3PT4AAG3JVVMAWLBFJOI45U4RX/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Ian Malone]

On 16 June 2018 at 13:50, Björn Persson  wrote:
> Tomasz Kłoczko wrote:
>> On Fri, 15 Jun 2018 at 23:21, Björn Persson  wrote:
>> [..]
>> > Don't forget that if your proof of concept can be modified to either
>> > overwrite or append to ~/.bashrc, then it's irrelevant to this debate.
>>
>> before ~/.bashrc is executed many other scripts  executions
>> already is finished
>
> This is true and completely irrelevant.
>
>> Whatever you want to do over you account session or profile scripts it
>> is already _to late_.
>> Is that clear now?
>
> No it's not clear. I have no idea why you're rambling about the order
> in which Bash executes its startup files. The order doesn't matter,
> especially since the hypothetical attacker is supposedly unable to
> modify those files.
>
> You claimed to have a proof of concept that would demonstrate how some
> security hole can be exploited if and only if ~/.local/bin is listed
> before /usr/bin in PATH. I asked you to post your proof of concept. You
> didn't. I will therefore conclude that you don't actually have one.
>


Well, two things:

1. For example, a kiosk mode, where the home directory is wiped each
login would be made less secure. The profile for the GUI is set at
login, so writing .bash_profile has no effect on the GUI environment,
but an attacker able to place files where the user has write
permission could mask system binaries.

But a more major worry for me here, the reason I'm bothering to reply
to a thread about setting paths (though to be honest, someone who
doesn't understand how to do that may not have much business
installing unpackaged software, particularly when the examples are
developer tools):

2. The fact that a proof of concept cannot be provided is not a proof
that a change you make is secure. Take Spectre; that vulnerability has
been around for decades with no public proof of concept, or even
knowledge there was a vulnerability, yet it can be exploited from
Javascript in a browser. So this repeated insistence on providing a
proof of concept before a security concern is taken seriously is
fundamentally wrong, and I would be concerned to see it applied
elsewhere in Fedora.

-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J7YVS2NVEPDF5TEZ2EFGFKI6TB42F3HA/

Re: A less "bloated" KDE spin

[Ian Malone]

On 11 September 2017 at 14:19, Gerald B. Cox  wrote:
>
>
> On Mon, Sep 11, 2017 at 3:45 AM, Richard W.M. Jones 
> wrote:
>>
>> On Sun, Sep 10, 2017 at 07:17:56PM -0400, Gerald Henriksen wrote:
>> > While you (and others) may well know the name of the software you like
>> > for a given task, new people will not have that knowledge.
>>
>> Isn't that really a discoverability problem?
>>
>> I could imagine having menu items pointing to best-in-class
>> applications which are not actually installed.  Selecting the menu
>> item would bring up a box asking you if you want to install it.
>
>
> That wasn't his main point which you removed:
> "But there is also the audience who are trying out KDE (or Gnome/etc)
> for the first time and providing them with an installed base of
> software to try / check out is convenient and the right thing to do."
>
> This is an issue about default applcaitons.  As I said above:
> "I believe you are missing the point of defaults which is to provide as
> complete environment as possible out of the box.  Since this is a KDE spin,
> we should be providing as complete of a KDE environment as possible.   Users
> shouldn't be required to go on a treasure hunt to seek out available KDE
> applications.  If you don't want to use a KDE default you can easily either
> go into settings and change the defaults, remove the package you don't want,
> etc."
>
>
>

To provide a purely anecdotal data point, what I use the KDE spin for
is to install a version of Fedora with the KDE desktop.

-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

troubleshooting wireless network issue

[Ian Malone]

Does anyone have suggestions on troubleshooting an issue with
apparently intermittent wifi on Fedora after upgrade to 25? The
machine is working okay in its location on windows and was okay on
F22, and other devices are alright on the access point. The
networkmanager status (KDE) doesn't show the connection dropping,
however fairly frequently a site will not respond. It's particularly
noticeable in Ajax or form submission, e.g. a site login (such as
gmail) just wont go any further, or sites that load as you scroll down
(such as facebook) just hit a point and stop.

I'd link to what I've already posted on the users list (thread
Terrible F25 WiFi Performance), but hyperkitty says there haven't been
any messages in March. So:

Device:
02:00.0 Network controller: Qualcomm Atheros AR93xx Wireless Network
Adapter (rev 01)

Module:
driver: ath9k
version: 4.9.14-200.fc25.x86_64
firmware-version: N/A
expansion-rom-version:
bus-info: :02:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

Which is the correct driver, unless there's been a regression. It
seems like key rotation or something is not taking place smoothly. I
see quite a lot of this while it's connected (journactl output, lines
may be truncated):

Mar 24 22:46:13 atlas wpa_supplicant[898]: wlp2s0:
CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Mar 24 22:46:13 atlas kde5-nm-connection-editor[2310]:
networkmanager-qt: virtual void
NetworkManager::DevicePrivate::propertyChanged(co
Mar 24 22:46:13 atlas wpa_supplicant[898]: wlp2s0: Associated with
xx:xx:xx:xx:xx:xx
Mar 24 22:46:13 atlas kdeinit5[1192]: networkmanager-qt: virtual void
NetworkManager::DevicePrivate::propertyChanged(const QString&, con
Mar 24 22:46:13 atlas wpa_supplicant[898]: wlp2s0:
CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Mar 24 22:46:13 atlas kdeinit5[1192]: networkmanager-qt: virtual void
NetworkManager::DevicePrivate::propertyChanged(const QString&, con
Mar 24 22:46:13 atlas wpa_supplicant[898]: wlp2s0:
CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=GB

I've tried setting the domain to GB as in this bug:
https://bugs.mageia.org/show_bug.cgi?id=18935 but still see those
WORLD domain entries in the log (and the problem persists). Have also
tried disabling ipv6 with no success.

-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support (Take Two!)

[Ian Malone]

On 10 January 2017 at 10:08, Florian Weimer  wrote:
> On 01/08/2017 01:52 AM, Kevin Kofler wrote:
>>
>> Brendan Conoboy wrote:
>>>
>>> Enhancing interoperability increases the reach of Fedora and doesn't
>>> require a bit of compromise on the the Freedom principle.
>>
>>
>> Splitting a single well-integrated distribution (where all the pieces are
>> known to work well together) into a bunch of loosely-coupled black-box
>> modules that have no idea what libraries the other modules even contain
>> actually DECREASES interoperability.
>
>
> Only if you do not rebuild each modules from scratch (with the exception of
> the build tools themselves, but which do not end up in the module). If you
> do rebuild the module, the build process of each component could be made
> aware what is available in the module, and integrate well with the features
> which are available.
>
> I think this would resemble what's being done in the embedded space with
> Yocto and BitBake.
>

Isn't that another problem? Aside from the fact you now need to
rebuild dependencies of each component every time, there's now scope
for package foo to be built with bar-2.1 while faa is built against
bar-3.0 and fuu uses its own bundled bar which was forked off bar-1.5.
While having to watch useful programs drop out (occasionally) and be
replaced (or not) because they didn't keep up with the rest of the
ecosystem is a bit annoying, the containerise-everything alternative
means reducing the incentive for programs to keep up to date,
particularly a worry for security issues, but also generally. The
externally nice and shiny container may contain code well past its
use-by-date, this is always my worry when someone suggests containers
as a way around compatibility issues, they have their uses, but they
can also amount to sweeping problems under the carpet.

-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Someone needs to stop texlive madness!!!

[Ian Malone]

On 15 October 2016 at 23:38, Matěj Cepl <mc...@cepl.eu> wrote:
> On 2016-10-15, 21:55 GMT, Ian Malone wrote:

> to be one Red Hat employee who did a lot of TeXLive maintenance
> (not much how much in his free time), but he is gone from Red
> Hat and now the main maintainer is spot. He is my hero, but take
> a look at the number of packages he maintains (including tiny
> ones like Chromium).
>

It's much appreciated!

-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Someone needs to stop texlive madness!!!

[Ian Malone]

On 15 October 2016 at 20:58, Tomasz Kłoczko <kloczko.tom...@gmail.com> wrote:
> On 15 October 2016 at 12:55, Ian Malone <ibmal...@gmail.com> wrote:
>>
>> > What was scarry 9 years ago now is even more scary today.
>> > Will try to present you what is in texlive today over now available rpm
>> > packages.
>>
>> What exactly are you using TeX for? The following examples suggest you
>> aren't very clear on its uses:
>
>
> You are losing the point.
> It doesn't matter how and for what I'm using TeX. I've not said even single
> word about how I'm using TeX.

>
>
> So again: what is the size of cross section of those two sets?
>

>
> Did I made any question about unes and unicode??
> Don't you see that you not answered eve on my single question or pointed


>
> Unanswered question ..
>

>
> Sorry asking. I want to be only sure.
> Above it is an answer on my question or ony random comment?
>

>
> OMG. Did I ask how can I draw cube/dice?
> If yes .. I'm really sorry to distract you.
>

>
> Hmm. did I ask when TeX development started?

> Seems you completely lost on what I've been pointing.
> Will try to rephrase this as shortly as possible.

I apologise, I have clearly failed in my obligation to answer every
one of your questions in detail and debate the use and existence of
TeX purely on your terms. Please continue in your campaign to have it
discontinued, I suggest you now write to the people at CTAN, the
creators of TeX Live and Donald Knuth with your concerns, I'm sure
they will all bow to your inexorable logic.


-- 
imalone
http://ibmalone.blogspot.co.uk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Someone needs to stop texlive madness!!!

[Ian Malone]

On 15 October 2016 at 00:03, Tomasz Kłoczko  wrote:
>> "TeX live is maintained IMO by real MORONS."
>
>> is what you wrote.
>
> Yes it is.
>
> Probably you never had occasion to have closer look what exactly is
> maintained in texlive source tree.
> I had fist time been trying to contemplate what exactly is texlive tree
> about 9 years ago.
> What was scarry 9 years ago now is even more scary today.
> Will try to present you what is in texlive today over now available rpm
> packages.

What exactly are you using TeX for? The following examples suggest you
aren't very clear on its uses:

> So lets go alphabetically:
>
> Name: texlive-ESIEEcv
> Summary : Curriculum vitae for French use
> Description :
> The package allows the user to set up a curriculum vitae as a
> French employer will expect.
>
> Package contains style template to write some CV. Using google you can find
> few examples of how it looks like.
> Number of google results: ~2.9k. I can give anyone £10 to anyone who in last
> 5 years been using this template installed on any Linux distro installed
> from packages to wrote own CV.
>

Style templates are how LaTeX is supposed to work, for a re-used
document format you fill in various parameters in your .tex document
and it generates the format for you, creating or adjusting your own
style is more involved. Note this comes from CTAN, you don't need to
install this package yourself, but if you require it it is much easier
to install from a fedora package.

> Name: texlive-allrunes
> Summary : Fonts and LaTeX package for almost all runes
> Description :
> This large collection of fonts (in Adobe Type 1 format), with
> the LaTeX package gives access to almost all runes ever used in
> Europe. The bundle covers not only the main forms but also a
> lot of varieties.
>
> Few questions:
> What is the size of the cross section of the sets: "we are using Linux" and
> "we uses runes fonts"?
> Maybe few artist in whole word are using runes .. how many of them are using
> Linux?

"Artist"... TeX is largely used by academics, and the whether people
wish to use runes (for example for books and papers) and are using TeX
to do so are probably not independent factors.

> Why those vectorised resources are only available as TeX users?
> Why TeX is not prepared to use system wide Type1 font and is not able to
> share those fonts with other applications?
> Why most Type1/TTF fonts are at least served three times as: ghoscript
> fonts, X11/Weyland fonts and TeX fonts?
> Why TeX live is not able to share those fonts with other applications? Maybe
> someone who what to quickly prepare some post card want to use those runes
> as some funny markings? However probability that he/she will use TeX is
> probably the same as probability that bucket of water left on open fire will
> freeze (according to quantum physics probability of something like this is
> greater than zero) and probably more likely will try to use LibreOffice.
> Isn't it?

TeX predates Type1 fonts, though most distributions support them, and
is used for its typesetting abilities. The needs of someone who wants
to do a little cultural appropriation for a quick postcard are going
to be less stringent than someone who actually wants to use the
language, but they'll be in luck, because there is a runic block in
unicode and fonts that support it outside TeX
https://en.wikipedia.org/wiki/Runic_(Unicode_block).

> Does Fedora really need to regenerate package with these fonts every time
> when someone will change even single bit in any TeX live resources?
>
> Name: texlive-a2ping
> Summary : Advanced PS, PDF, EPS converter
> Description :
> a2ping is a Perl script command line utility written for Unix
> that converts many raster image and vector graphics formats to
> EPS or PDF and other page description formats. Accepted input
> file formats are: PS (PostScript), EPS, PDF, PNG, JPEG, TIFF,
> PNM, BMP, GIF, LBM, XPM, PCX, TGA. Accepted output formats are:
> EPS, PCL5, PDF, PDF1, PBM, PGM, PPM, PS, markedEPS, markedPS,
> PNG, XWD, BMP, TIFF, JPEG, GIF, XPM. a2ping delegates the low-
> level work to Ghostscript (GS), pdftops and sam2p. a2ping fixes
> many glitches during the EPS to EPS conversion, so its output
> is often more compatible and better embeddable than its input.
>
> If anyone today will need to convert any of those formats to EPS or PDF more
> likely will use convert from ImageMagic.
> Isn't it?

From its description this looks like an interface layer, since TeX's
main use is producing pdf and eps it's not particularly surprising it
has one. ImageMagick itself uses ghostscript.

> I don't remember name of this TeX package but I'm almost 100%
> sure that it is still in texlive tree somewhere. "The Package"
> generates using metapost cube view with visable only one side,
> two sides and EVEN THREE sides!!! 8-O
> As example of generating some graphics it was obsolete in the
> time when people 

Re: F24, small backward steps

[Ian Malone]

On 13 September 2016 at 21:24, Stephen John Smoogen  wrote:
> On 13 September 2016 at 16:03, Michael Catanzaro  wrote:

> OK this is the most frustrating of a TON of frustrating parts of this
> conversation.
>
> 1. WHY DO WE SHIP PACKAGES THAT WE 'KNOW' AREN'T MAINTAINED?
> 2. Why are people 'maintainers' of such packages if they know upstream
> is dead and they aren't going to maintain things.

Sometimes an application can be working though upstream is dead and
keeping it going on a best-effort basis can provide some functionality
that wouldn't exist otherwise. Of course library churn and general
moving on of other technology will eventually kill it despite a
maintainer's best efforts. This doesn't apply for security issues
where providing software with known unpatched problems may be actively
harmful.



-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: PATH contains at build time

[Ian Malone]

On 3 February 2016 at 14:35, Petr Pisar  wrote:
> On 2016-02-02, Florian Weimer  wrote:
>> May packages assume that /usr/sbin is on PATH when they are built?
>>
>> If you need a program which is currently only in /usr/sbin, should a
>> package use an absolute path, or reset PATH to include /usr/sbin?
>>
> When I was small, I was tought that sbin is for programs executed by
> superuser, therefore only root user's login shell adds sbin into PATH.
>
> Thus the question boils down to: What user does build the package?
>
> But I can forsee the answer for `Does Fedora support building packages as
> non-root?' The answer is `defined by koji^Wimplementation'. So does not
> have answer.
>

On what architecture is root required to build packages? I thought a
build user was recommended?

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: On packager motivation

[Ian Malone]

On 3 February 2016 at 23:00, Kevin Kofler  wrote:

>
> Really, it is not realistic to expect people who need to urgently fix
> something to write up a polite e-mail and wait possibly days for you to
> reply (especially if you then answer that you don't want the change and more
> days are wasted going back and forth arguing for why the change is needed).
> Either you are reachable quickly through real-time communication (which
> effectively means IRC in the Free Software world) or you will just not be
> asked.
>
> I always curse when I try to contact a packager and see either no IRC
> contact info, or an IRC nick that is clearly not in active use (last seen
> weeks ago).
>

If this is a requirement then it rules out a lot of potential
packagers who are not full time employed to work on OSS. I could not
sit at my desk and respond to IRCs about Fedora all day.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Self-Reintroduction: DJ Delorie

[Ian Malone]

On 28 Jan 2016 19:42, "DJ Delorie"  wrote:
>
>
> I've been around for a while, but as I'm taking on a new role inside
> Red Hat, I'll be showing up in different places here and upstream, so
> I figured I'd refresh everyone's memory as well as announce the change :-)
>

Meanwhile, on LKML, "From: Linus Torvalds..." :)
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ian Malone]

On 22 January 2016 at 09:05, Paul Howarth <p...@city-fan.org> wrote:
> On 21/01/16 22:24, Ian Malone wrote:
>>
>> Since RHEL/CentOS 7 already does not exist in a native 32bit version I
>> do wonder what would actually be running in a hypothetical
>> mock/container/VM to build and run 32 bit systems down the road if
>> multilib went away.
>
>
> CentOS 7 does now have a 32-bit version:
>
> http://seven.centos.org/2015/10/centos-linux-7-32-bit-x86-i386-architecture-released/
>

While interesting to know, that is a CentOS SIG effort. If you are
using RHEL you presumably aren't supported for it, and I'm giving it
as an example of the way things are going. In any case I find this
whole 'just build in mock' as a work around for what is basically a
packaging problem a rather weak fix. Why is multilib devel install of
libraries any more difficult than multilib install of run time
libraries? They live in the same place. If the issue is header
includes and documentation conflicting, if that's a real problem then
shouldn't it be .noarch?

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ian Malone]

On 22 January 2016 at 13:38, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> On Fri, Jan 22, 2016 at 6:53 AM, Ian Malone <ibmal...@gmail.com> wrote:
>> On 22 January 2016 at 09:05, Paul Howarth <p...@city-fan.org> wrote:
>>> On 21/01/16 22:24, Ian Malone wrote:
>>>>
>>>> Since RHEL/CentOS 7 already does not exist in a native 32bit version I
>>>> do wonder what would actually be running in a hypothetical
>>>> mock/container/VM to build and run 32 bit systems down the road if
>>>> multilib went away.
>>>
>>>
>>> CentOS 7 does now have a 32-bit version:
>>>
>>> http://seven.centos.org/2015/10/centos-linux-7-32-bit-x86-i386-architecture-released/
>>>
>>
>> While interesting to know, that is a CentOS SIG effort. If you are
>> using RHEL you presumably aren't supported for it, and I'm giving it
>> as an example of the way things are going. In any case I find this
>
> If you're using RHEL, then you'd use RHEL to build for RHEL surely.
> Which means you build on RHEL however it enables you to build 32-bit
> applications.  Sure, you could use Fedora to build for RHEL, but I
> find that baffling in either the mock or the multilib case.  There's
> just no sanity in expecting something built on Fedora multilib to work
> on RHEL except in the simplest of cases.
>

Indeed. I don't build for RHEL using Fedora. However it would be
unexpected (unprecented?) for Fedora to diverge from RH on handling
multilib, and I expect changes here will show up there eventually,
hence taking an interest in this issue. Fedora I use at home and don't
often have call to build 32bit with (though this would probably be
different if I made use of Wine at all).


-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ian Malone]

On 21 January 2016 at 09:10, Yanko Kaneti  wrote:
> On Wed, 2016-01-20 at 15:50 +, Richard W.M. Jones wrote:
>> If you're on freshly installed Fedora 23 (x86-64), then
>>
>>   dnf install gtk3-devel.x86_64
>> ..
>>
>> Is this a bug or is it not expected this would work or I am doing it
>> wrong?
>
> IMO trying to get this (i686 development environment on x86_64 native
> install) to work reliably and chasing down all the corner cases is
> futile, leads to confusion instead of improving the developer
> experience in any significant way compared to using mock and should be
> declared unsupported.
>

That would be extremely disappointing.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ian Malone]

On 21 January 2016 at 14:25, Dennis Gilmore  wrote:

>
> However I  really think we need to sit down and rethink multilib. I would like
> to start by changing the multilib method to runtime. So you only get runtime
> libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building you
> should just use mock, docker, systemd-nspawn or something else. It would mean
> we need to make and ship a i386 docker base image if we say use docker.
>
> We have dropped most multilib support already. Today s390x has multilib with
> s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, we
> are working to drop s390 which will leave x86_64 standing all alone. Given
> changes in technologies since x86_64 first became a thing I think we sit back
> and reevaluate the idea of multilib. Maybe there is better ways to achieve
> what we want today

Successfully build and run 20+ year old programs without having to
completely rewrite them would be one of the things I want today. In
fact it's one of the things I was doing earlier this week.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Should 'dnf install gtk3-devel.i686' work?

[Ian Malone]

On 21 January 2016 at 15:15, Josh Boyer <jwbo...@fedoraproject.org> wrote:
> On Thu, Jan 21, 2016 at 10:10 AM, Ian Malone <ibmal...@gmail.com> wrote:
>> On 21 January 2016 at 14:25, Dennis Gilmore <den...@ausil.us> wrote:
>>
>>>
>>> However I  really think we need to sit down and rethink multilib. I would 
>>> like
>>> to start by changing the multilib method to runtime. So you only get runtime
>>> libraries and nothing to build 32 bit apps on 64 bit. For 32 bit building 
>>> you
>>> should just use mock, docker, systemd-nspawn or something else. It would 
>>> mean
>>> we need to make and ship a i386 docker base image if we say use docker.
>>>
>>> We have dropped most multilib support already. Today s390x has multilib with
>>> s390 and x86_64 multilib with i386.we dropped 32 bit ppc support entirely, 
>>> we
>>> are working to drop s390 which will leave x86_64 standing all alone. Given
>>> changes in technologies since x86_64 first became a thing I think we sit 
>>> back
>>> and reevaluate the idea of multilib. Maybe there is better ways to achieve
>>> what we want today
>>
>> Successfully build and run 20+ year old programs without having to
>> completely rewrite them would be one of the things I want today. In
>> fact it's one of the things I was doing earlier this week.
>
> Is there a reason that would not work in mock?
>

It would, it would require installing the entire development system in
mock though, and shifting data in and out is more awkward than working
directly on it. Additionally, notice the:

>>> Given
>>> changes in technologies since x86_64 first became a thing I think we sit 
>>> back
>>> and reevaluate the idea of multilib. Maybe there is better ways to achieve
>>> what we want today"

Since RHEL/CentOS 7 already does not exist in a native 32bit version I
do wonder what would actually be running in a hypothetical
mock/container/VM to build and run 32 bit systems down the road if
multilib went away.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: dnf still is unuseable

[Ian Malone]

On 18 January 2016 at 01:32, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Mon, Jan 18, 2016 at 12:55:54AM +0100, Heiko Adams wrote:
>> But it seems to be broken since Feb 2015, which is IMHO unacceptable
>> since a default package manager and all of its features have to work
>> absolutely reliable.
>
> When was the last time you saw a program bigger then /bin/true that was
> "absolutely reliable"? Your implicit premise that yum was bug free
> is completely bogus, just look for yum bugs in bugzilla [1].
>

xz
tar
cp
...

Being reliable might be difficult, but it is achievable, and the more
core a tool is the more important it is that it approaches
reliability.

> It seems that with dnf we are currently in the phase of fine-tuning
> user interaction. The resolver works nicely, there is a growing system
> of plugins based on a stable API, the codebase was ported to the
> current version of python, speed is decent most of the time... There
> *are* things to fix, but calling for the return of yum is a complete
> waste of the time of everbody on this list.
>

So there's no need to fight hyperbole with hyperbole.


-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: kmods and Fedora

[Ian Malone]

On 14 January 2016 at 19:29, Andrew Lutomirski  wrote:
>
> On Jan 14, 2016 9:34 AM, "Nicolas Chauvet"  wrote:
>>
>> 2016-01-14 18:05 GMT+01:00 Neal Gompa :
>>>
>>> On Thu, Jan 14, 2016 at 11:01 AM, Reindl Harald 
>>> wrote:
>>> >
>>> > Am 14.01.2016 um 16:56 schrieb Neal Gompa:
>>> >>
>>> >> I've recently been wondering why we haven't allowed kernel module
>>> >> packages in Fedora since Fedora 8. I've tried searching through our
>>> >> wiki and the mailing list, but I haven't come up with any concrete
>>> >> reasons for why we disallow them.
>>> >>
>>> >> If it is perhaps the issue of keeping things in sync with kernels we
>>> >> provide (that is, maintainers didn't/couldn't keep up with new kernels
>>> >> being pushed during a release cycle), then I think the situation has
>>> >> changed.
>>> >>
>>> >> We have two tools that can help us in this regard: akmod and Koschei,
>>> >> both came after our policy change to disallow kernel modules.
>>> >
>>> >
>>> > akmod is a dirty hack and fails often enough for rpmfusion stuff
>>> >
>>> > additionally you should *never* need GCC and devel packages installed
>>> > on a
>>> > normal enduser system for a ton of reasons
>>>
>>> The most common reason that akmod fails is the same reason dkms often
>>> fails: the correct kernel-devel isn't installed. For whatever reason,
>>> there's no logic in DNF to handle this case properly. Of course, to be
>>> fair, this problem happens in Yum too, but since Yum isn't actively
>>> supported in Fedora anymore, it's not as much of a concern.
>>
>>
>> Maybe this particular concern can be addressed in DNF with a plugin ?
>>
>> The way I've previously worded a possible solution is to have a yum/dnf
>> plugin for akmod.
>> This plugin will select the appropriate kernel-devel based on the kernel
>> that is currently installed.
>> ( https://bugzilla.rpmfusion.org/show_bug.cgi?id=3386 ).
>>
>> But this dnf plugin can be useful by default in fedora, since the
>> kernel-devel issue can rise when one user install a particular development
>> group where kernel-devel is needed.
>> (user typically ends with kernel-debug-devel instead of the one for their
>> kernel variant that can also be kernel-lpae or else).
>
> There are two issues here, I think:
>
> 1. Is Fedora okay, in principle, with shipping out-of-tree modules?
>
> I won't comment on #1.  (I also won't comment on Secure Boot issues.)
>
> 2. Assuming that shipping an out-of-tree module is okay, is akmod a good
> mechanism?
>
> I would argue strongly that akmod is *not* a good mechanism.
>
> Clearly any end-user-box-builds-modules system needs the package manager to
> pull in the right devel stuff.  This is clearly a solvable problem.
>
> But akmod in particular has a really nasty built-in assumption: it assumes
> that the running kernel came from an RPM at all.  For people who write
> kernels, this utterly sucks.  For example, I have no intention of rpm-ifying
> every test kernel I build for my laptop.  I install them according to the
> standard arrangement, which "make install" can do just fine.  There are
> symlinks in standard places that a kmod build system could find.  Akmod
> can't do that.  Akmod also can't figure out what to make its freshly-built
> rpm depend on because there is no correct answer.
>
> I think that, if Fedora were to adopt a kmod build system: it should have a
> QA requirement: if you "make modules_install && make install" a kernel and
> boot into it, the kmod system should work.  Akmod fails utterly in that
> scenario.
>

I don't quite get this one, if you build any package from a non-rpm
source it's not a given that rpm modules will work with it. Akmod is
really a convenience for people reliant on non-tree modules who are
also using the distribution rpm kernel, so they have a chance of
getting a working module whenever the kernel updates. If you're
building your own kernel you probably know when you've done it and how
to build the module.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Stop please

[Ian Malone]

On 8 January 2016 at 12:02, Sam Varshavchik  wrote:
> Samuel Sieb writes:
>
>> On 01/07/2016 08:34 PM, Michael Catanzaro wrote:
>>>
>>> I decided I would instruct Byron in how to unsubscribe from our mailing
>>> list, when I discovered *I don't know how.*
>>>
>>> It seems with HyperKitty we no longer have an easily-accessible way to
>>> unsubscribe from our mailing lists. How can this be done without
>>> registering a Fedora account?
>>>
>> There's info in the email headers although if you're not that familiar
>> with mailing lists that's not exactly discoverable.
>
>
> Robust mail clients can use the RFC 2369 headers to prominently present an
> unsubscribe link when displaying list mail.
>

Excellent, that's that solved then.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: wayland in rawhide

[Ian Malone]

On 30 November 2015 at 12:29, Steve Clark <scl...@netwolves.com> wrote:
> On 11/26/2015 06:32 AM, Ian Malone wrote:
>>
>> On 25 November 2015 at 22:01, Adam Williamson
>> <adamw...@fedoraproject.org> wrote:
>>


>>> The wiki page explaining the GNOME-on-Wayland approach to middle-button
>>> paste - https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection -
>>> makes this claim as one of the reasons why it wasn't initially planned
>>> for inclusion in Wayland:
>>>
>>> "Additionally, reasons against keeping it:
>>>
>>> the middle click is a hard-to-discover easter egg
>>> there are few middle mouse buttons in the world"
>>>
>>> Ian was, I think with reason, questioning the second of those. I was
>>> pointing out that those are only a couple of *supplementary* reasons,
>>> so it's not really worth spending much time disputing that assertion,
>>> even though it does seem like an odd one. The primary reasons why
>>> Wayland wasn't initially going to implement a PRIMARY selection
>>> mechanism are given earlier in the page:


> Throw these in to support any breakage you would like to introduce and
> suddenly you're a breath of fresh air blowing all the old cruft away
> and anyone who disagrees is stuck in the dark ages. Except in this
> case they're trivially demonstrated as untrue (well documented, unlike
> documenting all new features in blog posts and leaving them to rot,
> hardware support widespread). So this feature is being re-introduced
> because "many longterm X users have become reliant on this easter egg"
> (still an easter egg) and it is, "to ease the transition for long-term
>

> How can you say it is an "easter-egg"? It is clearly documented in the X
> Window system
> documentation.
>

Before anyone else gets confused about what I've written (seeing it's
happened once already), I'm not claiming it's an Easter egg, I'm
quoting the assertion on the wayland page linked above, and pointing
out the questionable use of language in it. I suppose that might have
been clearer if I had included quotes around the second occurence of
"Easter egg" in my mail, but I hope my objection to the use of the
term is clear enough from my post and my earlier emails in this
thread.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: wayland in rawhide

[Ian Malone]

On 25 November 2015 at 22:01, Adam Williamson
<adamw...@fedoraproject.org> wrote:
> On Wed, 2015-11-25 at 15:40 -0500, Przemek Klosowski wrote:
>> On 11/25/2015 03:25 PM, drago01 wrote:
>> > On Wed, Nov 25, 2015 at 9:17 PM, Adam Williamson
>> > <adamw...@fedoraproject.org> wrote:
>> > > On Fri, 2015-11-20 at 14:34 +, Ian Malone wrote:
>> > > > [1] Apparently middle mouse buttons are rare. I'm in an office
>> > > This seems an odd assertion [...]
>> > Its not odd ... its plain wrong.
>> >
>>
>> I think Ian meant to say that the mice WITHOUT middle button are rare.
>> The quote above continues on like this:
>>
>> I'm in an office surrounded by them and them only computers I've used 
>> without one for roughly the past decade are my old laptop
>>
>> Am I right, Ian?
>
> No.
>

Well, it was what I said. I was going to add that it would be possible
to check in the archives, but I can't actually find my original post
there. Not sure why this thread has woken up again.

> The wiki page explaining the GNOME-on-Wayland approach to middle-button
> paste - https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection -
> makes this claim as one of the reasons why it wasn't initially planned
> for inclusion in Wayland:
>
> "Additionally, reasons against keeping it:
>
> the middle click is a hard-to-discover easter egg
> there are few middle mouse buttons in the world"
>
> Ian was, I think with reason, questioning the second of those. I was
> pointing out that those are only a couple of *supplementary* reasons,
> so it's not really worth spending much time disputing that assertion,
> even though it does seem like an odd one. The primary reasons why
> Wayland wasn't initially going to implement a PRIMARY selection
> mechanism are given earlier in the page:
>

I was questioning those and a tone that's become very common:
1. This is obscure, only crusty old dinosaurs know about it and use
it. (I'm fairly sure I'm neither crusty or old.)
2. Not relevant any more because Y.

Throw these in to support any breakage you would like to introduce and
suddenly you're a breath of fresh air blowing all the old cruft away
and anyone who disagrees is stuck in the dark ages. Except in this
case they're trivially demonstrated as untrue (well documented, unlike
documenting all new features in blog posts and leaving them to rot,
hardware support widespread). So this feature is being re-introduced
because "many longterm X users have become reliant on this easter egg"
(still an easter egg) and it is, "to ease the transition for long-term
X users." (Who just can't cope with the modern world, so let's throw
them a bone.) They look like very little consideration was given.

> "Among the arguments for eschewing the PRIMARY selection were:
>
> It makes it easy to unintentionally paste passwords, snippets of
> private conversations and other non-public information,
> into online communication.
> security concerns with unexpected data stealing if the mere act of
> selecting a text fragment makes it available to all running
> applications"
>

That is a genuine concern, but compare it to having a clipboard of the
past N selections which most users are probably not aware of either.
It looks like they've come up with a scheme to tie it down.

> and it goes on to propose that the primary selection should in fact be
> implemented.

And turned off by default of course.

Actually, my main comment (snipped) was that the utility of having
separate buffers is not even discussed, and it is not actually clear
that this wont simply be reintroduced as an option to turn on a form
of auto-copy on select. Which the discussion of the signalling
mechanism involved and the "not just text" aspect seem to suggest it
might be.

-- 
imalone
http://ibmalone.blogspot.co.uk
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: wayland in rawhide

[Ian Malone]

On 12 November 2015 at 14:59, Ray Strode  wrote:
> Hi,
>
> On Thu, Nov 12, 2015 at 5:51 AM, Jared K. Smith
>  wrote:
>> I've been testing Wayland myself since around the F22 time period, but
>> "middle click paste" and the occasional odd bug keep annoying me enough to
>> go back to X.  Can you elaborate on the plans for supporting middle click to
>> paste, or is it considered a relic of a bygone era and I should try to
>> unlearn?
>
> Plans for middle-click paste are tracked here:
>
> https://wiki.gnome.org/Initiatives/Wayland/PrimarySelection
>

This would actually be quite a productivity killer for me, not just
the lack of middle-button paste[1], but also removing a separate
copy-buffer. It is seriously useful to be able to carry around
multiple pieces of text, particularly if you're going to need to
keeping one and change the other (or working on two things at once).

[1] Apparently middle mouse buttons are rare. I'm in an office
surrounded by them and them only computers I've used without one for
roughly the past decade are my old laptop (now moved on, but had
emulated middle click, maybe the wayland developers were unaware of
this too), and other people's mac laptops, which have their own
'easter egg' combinations of one, two, three(?) finger clicks and
drags.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: On running gui applications as root

[Ian Malone]

On 19 November 2015 at 03:18, Matthew Miller  wrote:
> On Wed, Nov 18, 2015 at 03:09:34PM -0500, Adam Jackson wrote:
>> To the bug in question: probably we should make it so 'sudo gedit' does
>> work, but I'd still strongly discourage anyone from actually doing so.
>
> Actually, there's a better way. The authors of sudo already considered
> this. Set "VISUAL" to gedit, and use `sudo -e`. That invokes the editor
> as non-root on a temporary file, and copies that temp file into place
> when done.
>

Completely forgot about that one! I remember using crontab's similar
function was the first time I encountered vi, that was lots of fun...

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: On running gui applications as root

[Ian Malone]

On 19 November 2015 at 15:31, Adam Jackson <a...@redhat.com> wrote:
> On Wed, 2015-11-18 at 21:45 +0000, Ian Malone wrote:
>
>> Not really getting this. For any configuration task where you replace
>> editing a root owned text file with access through some authorised
>> gui, that gui is still vulnerable.
>
> That gui's code, unlike emacs, doesn't allow you to write arbitrary
> data to arbitrary files.  I can feed arbitrary input events to an emacs
> window and have it modify any file the process could modify.  It's a
> lot harder to get, say, virt-manager to write arbitrary data to
> arbitrary places.
>

Harder, but you still have the permissions that the application has,
whatever route it may be using to modify those files. Emacs (for
example) while you are using it does not just access arbitrary files
under normal operation unless instructed, an attacker needs to subvert
it somehow. There are differences of course, but if an application has
rights that allow it access to things then someone taking control of
it can access them too.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: On running gui applications as root

[Ian Malone]

On 18 November 2015 at 20:24, Adam Williamson
 wrote:
> On Wed, 2015-11-18 at 15:09 -0500, Adam Jackson wrote:
>> On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
>>
>> > I don't understand.  If a user who has the right to act as root asks
>> > to authorize a program to run as root on their behalf, we should grant
>> > that request.  And, once we grant it, we shouldn't be
>> > passive-aggressive and say "sure you can run it, but no graphics for
>> > you!".
>>
>> The point is, if things in Fedora require "run this bit of GUI as root"
>> in order to function, we've done a poor job. That people have bad
>> habits already is not sufficient justification to encourage them to
>> have more.
>>
>> To the bug in question: probably we should make it so 'sudo gedit' does
>> work, but I'd still strongly discourage anyone from actually doing so.
>
> ISTR seeing some work lately in gvfs or gio or something which would
> allow GNOME-y things to acquire necessary perms for changes to files
> via PolicyKit when necessary.
>
> I've always thought this would be an entirely reasonable feature.
> There's no inherent security advantage in making people run a console
> editor as root instead of using their preferred graphical editor, if
> the graphical editor can use an appropriately restricted permission
> granting mechanism to do the job. I've certainly had times where I'd
> quite have liked to edit a system file with gedit rather than nano or
> vi.

That's really what's needed, just a pity that all the vfs systems seem
to be tied to desktops.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: On running gui applications as root

[Ian Malone]

On 18 November 2015 at 23:38, Reindl Harald  wrote:
>
>
> Am 18.11.2015 um 19:49 schrieb Adam Jackson:
>>
>> On Tue, 2015-11-17 at 17:30 +, Andrew Haley wrote:
>>>
>>> On 11/02/2015 03:05 PM, Adam Jackson wrote:

 But, why take the risk exposure, when you could simply not?
>>>
>>>
>>> How else would I edit root-owned files?  I don't get it.  I mean,
>>> I guess I could run an editor in a text window, but I don't want to
>>> do that.
>>
>>
>> That's kind of a non sequitur. To a first order, there are zero root-
>> owned files you need to edit routinely. And I feel pretty comfortable
>> calling any counterexamples bugs that need fixing
>
>
> hopefully all configuration files on your system are root-owned and
> "routinely" is not black and white because it depens on your use-cases
>
> as serveradmin you *routinely* edit root-owned files and *yes* i pull them
> from 35 machines to a dedicated admin server and open them all together in a
> GUI editor with tabs to make changes i want to have on all servers while the
> file itself is machine specific
>
> why?
>
> because it's much faster than login to each and every machine when i can
> pull them with a script, edit them centralized and push them back followed
> by a "distribute-command 'systemctl condrestart affected-service'" and it
> saves a ton of overhead for configuration management tools with their own
> security issues all the time
>

Technically if doing this then the editing only needs to be done as
the owner of the copies and it's the process of copying them back that
requires root permission on the target machine.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: On running gui applications as root

[Ian Malone]

On 18 November 2015 at 20:09, Adam Jackson  wrote:
> On Wed, 2015-11-18 at 11:53 -0800, Andrew Lutomirski wrote:
>
>> I don't understand.  If a user who has the right to act as root asks
>> to authorize a program to run as root on their behalf, we should grant
>> that request.  And, once we grant it, we shouldn't be
>> passive-aggressive and say "sure you can run it, but no graphics for
>> you!".
>
> The point is, if things in Fedora require "run this bit of GUI as root"
> in order to function, we've done a poor job. That people have bad
> habits already is not sufficient justification to encourage them to
> have more.
>
> To the bug in question: probably we should make it so 'sudo gedit' does
> work, but I'd still strongly discourage anyone from actually doing so.
>

Not really getting this. For any configuration task where you replace
editing a root owned text file with access through some authorised
gui, that gui is still vulnerable. It may have theoretically reduced
risks (assuming its permission to alter things is suitably locked
down, not sure how well that is down generally), but it still has them
and potential vulnerabilities. Versus being able to use a text editor,
which is necessary for people using customised systems even in the
hypothetical world where everything provided by fedora provides a
perfect tool for configuring it. My conclusion would be better
security and controls for gui tools that need general access to root
owned resources.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Naming ANTs

[Ian Malone]

On 2 November 2015 at 09:14, Igor Gnatenko  wrote:
> Hi folks,
>
> I'm working on bringing libraries/tools for neuroscience and neuroimaging
> into Fedora[0]. Now I'm packaging ANTs[1] (Advanced Normalization Tools
> (ANTs)), but we already have package ants[2] (game).
>
> How do I proceed with it? I think I can name it ANTs in upper case, but
> probably it will confuse people. Suggestions? Ideas?
>
> [0] https://fedoraproject.org/wiki/SIGs/NeuroFedora
> [1] https://github.com/stnava/ANTs
> [2] https://admin.fedoraproject.org/pkgdb/package/ants/
>

Pennsylvania-ANTS? Would abbreviate to PANTS though...
Possibly neuro-ANTS. Anyway, giant bikeshedding exercise aside, this
is good news! Likely to end up in EPEL?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 15 October 2015 at 06:55, 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).
>

Well, it does say "Most emulators (applications which emulate another
platform) are not permitted for inclusion in Fedora." It probably
shouldn't use the term emulators or at least qualify it a bit. Maybe
"console emulators" might be a more accurate term. As people have
mentioned, wine, dosbox, qemu. Some of those aren't emulators in the
hardware sense.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 15 October 2015 at 11:50, Petr Pisar  wrote:
> On 2015-10-14, Alexandre Moine  wrote:
>> But, we have to be very careful with this software since it downloads
>> scripts and icons from the web (in the automated installer part)...
>> And it can install for example IE or steam by simply clicking a
>> button, without any mentions of the proprietary part of these
>> software. I don't know if this is legal from the point of vue of our
>> lawyers :)
>>
> Yet web browsers download and execute proprietary software every minute
> and nobody is for removing the browsers from Fedora because of that.
>

There is a GNU project to do roughly that (at least for Javascript),
https://www.gnu.org/software/librejs/

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Ian Malone]

On 12 October 2015 at 16:27, Kevin Kofler <kevin.kof...@chello.at> wrote:
> Ian Malone wrote:
>> Maybe there's some confusion about the point I was making. I'm
>> referring to the case where the bundled library has functions that are
>> no longer present in the fedora version and the application requires
>> them.
>
> And I already answered that point:
> https://lists.fedoraproject.org/pipermail/devel/2015-October/215591.html
>
> Now you are replying to my reply to Haïkel's objection to my above answer,
> which indeed addresses Haïkel's point and not yours.
>

I'd thought Haïkel at least misinterpreted what I'd said and then
thought maybe you had too.

As for the suggestion, it's not always trivial to replace a function.
Sometimes you'll get away with a patch that replaces a single use with
an updated call. Other times you'll find you need to re-structure
things to use a new way of doing stuff, possibly even re-design. If
you really want maintainers to take that on you can call them lazy for
not doing so, but you might find you're shouting them at their backs
as they walk away.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Ian Malone]

On 11 October 2015 at 12:43, Kevin Kofler  wrote:
> Haïkel wrote:
>> And what happens if the library is consumed by other packages
>> requiring the new API?
>
> Of course you have to support both the new and the old one.
>
>> Let's keep Ian example:
>> You keep the deprecated function in the new library despite upstream's
>> decision. Since we keep shipping it, developers will keep using it in
>> their new software, making it incompatible with other distro.
>
> Which is not our problem. (Developers should not use deprecated functions,
> no matter whether or when they get removed, so it's their fault, not ours.
> And in the end, it won't affect us at all if we ship the deprecated
> function, so why would we care?)
>
>> We only had one problem, now we have more problems.
>
> No. The other distro has a problem. Why would we care?

Maybe there's some confusion about the point I was making. I'm
referring to the case where the bundled library has functions that are
no longer present in the fedora version and the application requires
them.

An upstream may (or may not if abandoned) have their own schedule for
moving something to a newer version of a dependency, but if they're
bundling then that may be happening at a different speed to what
fedora is doing with that library. A maintainer who has unbundled
things independent of upstream will find themselves needing to
rebundle, fork and modify or just drop.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Ian Malone]

On 8 October 2015 at 23:58, Kevin Kofler  wrote:
> Matthew Miller wrote:
>> In many cases, this effectively means creating a Fedora-specfic fork of
>> the project.
>
> Only if you call patches to the build system (with little to no changes to
> the actual code) a "fork".
>
>> Even if we accept unbundling as goal in itself is a given, there just
>> aren't enough people in the world who have the inclination, time, and
>> expertise to do this. Especially when you consider that for most projects,
>> the only people with *deep* understanding of this kind of invasive change
>> *are* the upstream.
>
> Huh? 3 simple steps to unbundling (>90% success rate, especially with the
> growing number of stupid upstreams that bundle not out of necessity, but
> because they simply don't believe in unbundling):
> 1. rm -rf the bundled library (in %prep, or rip it out of the tarball
>entirely if there is any chance of a licensing issue of any kind),
> 2. Remove the building of the bundled library from the build system and add
>the required -I and -l flags instead.
> 3. Check the source code for hardcoded relative
>#include "../3rdparty/foo/bar.h" paths and fix them to use proper
>#include  or #include  paths (depending on the library,
>read its documentation). (If the code already uses the correct path
>style, there is nothing to do.)
>

4. Take over responsibility for keeping the application up to date
with Fedora's version of the library.

I'm actually all for unbundling, but going it alone is not guaranteed
to be simple. "Oh, hey, that deprecated function has been removed."

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Ian Malone]

On 14 September 2015 at 16:47, Jóhann B. Guðmundsson  wrote:

> They simply have welcomed their new container overlords and are using only
> the recommended upstream method for installing for their application (
> pip,gem etc since developers can use the upstream support community for
> those ) in those container images, followed by a strong attitude of use it (
> their produced container/vm image not some downstream shipped/provided
> "package" ) or "take your freedom of choice and get lost, we are done trying
> to support and play the "X-factor of linux distributions" game. "
>
> And once the "market" has ( started ) taken a stance ( moving away from
> downstream provided package of their components since it does not work due
> to the fragmentation in the linux ecosystem ) it's irrelevant what I think
> or you think or distributions think or implement locally beside providing
> the underlying structure to run their application for the sole purpose of
> being relevant as an platform for deployment ( which today is basically any
> distribution that ships systemd ).
>

Ultimately that is going to be self limiting, you can only do it while
the most fundamental components are playing by the old rules. I can
think of a few research software packages (in the sense of software
packages, not fedora packages) which are so tied to particular
underlying libraries that getting them to work in the same environment
is a real pain (various ones that bundle underlying libraries and have
their own setups that force that on the whole system because they
can't even get linking right). Now you can containerise that, but
eventually you are going to have to have containers within containers,
and somewhere in there will be a piece of rotting software.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Proposal to reduce anti-bundling requirements

[Ian Malone]

On 15 September 2015 at 10:11, Jóhann B. Guðmundsson <johan...@gmail.com> wrote:
>
>
> On 09/15/2015 08:41 AM, Ian Malone wrote:
>>
>> On 14 September 2015 at 16:47, Jóhann B. Guðmundsson <johan...@gmail.com>
>> wrote:
>>
>>> They simply have welcomed their new container overlords and are using
>>> only
>>> the recommended upstream method for installing for their application (
>>> pip,gem etc since developers can use the upstream support community for
>>> those ) in those container images, followed by a strong attitude of use
>>> it (
>>> their produced container/vm image not some downstream shipped/provided
>>> "package" ) or "take your freedom of choice and get lost, we are done
>>> trying
>>> to support and play the "X-factor of linux distributions" game. "
>>>
>>> And once the "market" has ( started ) taken a stance ( moving away from
>>> downstream provided package of their components since it does not work
>>> due
>>> to the fragmentation in the linux ecosystem ) it's irrelevant what I
>>> think
>>> or you think or distributions think or implement locally beside providing
>>> the underlying structure to run their application for the sole purpose of
>>> being relevant as an platform for deployment ( which today is basically
>>> any
>>> distribution that ships systemd ).
>>>
>> Ultimately that is going to be self limiting, you can only do it while
>> the most fundamental components are playing by the old rules. I can
>> think of a few research software packages (in the sense of software
>> packages, not fedora packages) which are so tied to particular
>> underlying libraries that getting them to work in the same environment
>> is a real pain (various ones that bundle underlying libraries and have
>> their own setups that force that on the whole system because they
>> can't even get linking right). Now you can containerise that, but
>> eventually you are going to have to have containers within containers,
>> and somewhere in there will be a piece of rotting software.
>>
>
> It's self limiting with or without containers is it not? besides there is
> rotting piece of software littered all across the software galaxy even in
> Fedora so that's nothing new.
> ( which is to be expected for a distribution that has more components than
> the require manpower to maintain them properly, inefficient deprecation and
> clean up procedures etc. )
>
> In the end containers wont solve all the world problems and there exist use
> cases outside it just as it was with virtualization but at the moment it's
> want the market wants.
>

What I mean is they're not a magic solution, and this approach is
beginning to burn up the accumulated benefit of years of discipline
over this stuff. Currently you can see the software that has problems,
and an over-dependence on bundling libraries is often a sign that a
project is a bit flaky, containerisation allows that to be hidden. It
does have plenty of legitimate uses of course.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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 Ring 0 definition

[Ian Malone]

On 7 September 2015 at 13:21, Miloslav Trmac  wrote:

>
> Also, it seems to me that it would be useful to, at least conceptually, to
> not think about Fedora as a self-hosting perpetual motion^Wrecompilation
> machine, but as “just another huge application” being built using compilers
> and other tools which come from $some_other_magic_place. That’s not to say
> that self-hosting is not valuable—it is a critical property of the subset of
> the Open Source ecosystem which Fedora distributes—but it is more of a
> property of the ecosystem than the produced artifacts.
>

I'm perfectly happy to leave this discussion to Redhat people, and I
think you have some good points about not letting implementation drive
goals. However people seem to be talking down self-hosting here. For
fedora as a distribution self-hosting is a part of the "Freedom"
foundation. It's no good insisting that source is available for
packages if they cannot be built. Similarly it's not just a part of
the ecosystem as that might imply, since the ability to improve and
extend it also requires self-hosting. I've no opinion beyond that on
whether it's considered part of ring 0 or cube beta.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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 Jam not in nightly composes / F23 alpha or beta?

[Ian Malone]

On 4 September 2015 at 11:17, Ian Malone <ibmal...@gmail.com> wrote:
> Hi,
>
> It seems Fedora Jam is not included in current test composes for F23
> and is not being included in nightly composes
> http://koji.fedoraproject.org/koji/tasks?state=all=tree=livecd=-id
> (not failing to build as Live Workstation is, simply not being
> included in attempted builds). I can't find any reference in spins@,
> test@ or devel@ to this, except in the lead-up to F22 release that
> there was an issue which was fixed (and didn't prevent Jam being
> included in the release),
> <https://bugzilla.redhat.com/show_bug.cgi?id=1197940>. Has it been
> intentionally dropped or has there just been some oversight?
>

There appears to have been a period 2015-07-30 - 2015-08-01 when most
of the composes were failing, there are Jam compose failures on
2015-07-30 <http://koji.fedoraproject.org/koji/taskinfo?taskID=10541486>
and 2015-07-31, but no Jam compose on 2015-08-01 and it doesn't appear
again.
E.g.
http://koji.fedoraproject.org/koji/taskinfo?taskID=10559702 Live-KDE fail
http://koji.fedoraproject.org/koji/taskinfo?taskID=10559694 Games fail
http://koji.fedoraproject.org/koji/taskinfo?taskID=10559685 Cinnamon fail
http://koji.fedoraproject.org/koji/taskinfo?taskID=10559706 LXDE fail

Roughly page 
http://koji.fedoraproject.org/koji/tasks?start=1850=all=tree=livecd=-id

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Fedora Jam not in nightly composes / F23 alpha or beta?

[Ian Malone]

Hi,

It seems Fedora Jam is not included in current test composes for F23
and is not being included in nightly composes
http://koji.fedoraproject.org/koji/tasks?state=all=tree=livecd=-id
(not failing to build as Live Workstation is, simply not being
included in attempted builds). I can't find any reference in spins@,
test@ or devel@ to this, except in the lead-up to F22 release that
there was an issue which was fixed (and didn't prevent Jam being
included in the release),
. Has it been
intentionally dropped or has there just been some oversight?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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 it time to allow Chromium in Fedora?

[Ian Malone]

On 12 August 2015 at 09:33, Reindl Harald h.rei...@thelounge.net wrote:

 Am 12.08.2015 um 02:42 schrieb Thomas Daede:

 *if* you use binary tarballs they *should not* be extracted in a user
 writeable location as *no binary* whenever possible should have
 permissions allowing a ordinary user to change them


 This is simply not the way how end users install original Mozilla
 Firefox binaries.


 In addition, if you have write access to ~/, you can also change .bashrc
 to add paths to executable files and do all sorts of other nasty things


 that's why chattr exists

 chattr +i ~/.bashrc
 chattr +i ~/.bash_profile

 [root@rh:~]$ touch /home/harry/.bashrc
 touch: cannot touch '/home/harry/.bashrc': Permission denied


However a compromised application that can write files can probably
make executable and fork too. So while immutable provides limited
protection, if the real attack surface is the web browser and the
worry is privilege escalation then overwriting .bashrc is a side show.
Having to run the browser as root to update it (which would remove
most of the advantage of automated updates by the mozilla binary)
replaces exposing user privileges with exposing root privileges. If
you really wanted to be paranoid about this you'd make a separate user
account with write permission for that binary to be used for updates.
(Which is one of the reasons package managers are a good idea.)

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Thunderbird-38.0.1 integrates lightning? Very disturbing!!

[Ian Malone]

On 1 July 2015 at 14:02, Ahmad Samir ahmadsamir3...@gmail.com wrote:
 On 1 July 2015 at 12:14, Ian Malone ibmal...@gmail.com wrote:
 snip

 It appears to have broken the ability to install the gdata provider,
 at least when I installed a new F22 system at the weekend I found I
 couldn't install it because it requires the lightning package which is
 obsoleted by current thunderbird.


 That's a packaging bug; either thunderbird should obsolete _and_
 provide thunderbird-lightning or thunderbird-lightning-gdata should be
 changed to require thunderbird instead of -lightning. You should file
 a bug so that the issue is tracked/fixed.


Thought that might be the case, but hadn't been able to find out
whether the lightning package really had been retired or if it was
just one of the metadata caching problems you occasionally run into.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Thunderbird-38.0.1 integrates lightning? Very disturbing!!

[Ian Malone]

On 30 June 2015 at 16:33, Ahmad Samir ahmadsamir3...@gmail.com wrote:
 On 30 June 2015 at 17:22, Reindl Harald h.rei...@thelounge.net wrote:


 Am 30.06.2015 um 17:02 schrieb Ahmad Samir:

 IIUC, what's happening here is that they bundle the extension with
 Thunderbird 38 so it's installed and enabled by default; so when you
 create a new Thunderbird profile,

 /usr/lib*/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/
 will get copied to ~/.thunderbird/PROFILE_NAME/extensions; that also
 happens if you run 38.0.1 for the first time and didn't have the
 Lightning extension already installed (I was surprised to see the
 calendar pane in Thunderbird after updating to 38.0.1, since I didn't
 have that extension installed previously).

 Also (IIUC) Lightning will be updated in your profile, just like any
 other user-installed extension.

 So what you can do is just copy the dir from
 /usr/lib*/thunderbird/distribution/extensions and restart Thunderbird
 or re-install it from addons.mozilla.org, I think either would lead to
 the same result


 but that all makes zero sense

 * i had lightning installed for many years as user extension
 * i never used the rpm because it was always too late after TB updates
 * now due start TB 38 it was updated
 * it is still a user-extension in the profile
 * if i uninstall it it's gone
 * the files from the package still exists unused

 the point is if it is now part of the TB package it should be present after
 uninstall the extension in the user-profile becasue the state now is no
 improvement at all and just wasting space for no gain


 This is an upstream change; from this blog post[1] I gather that
 upstream's intention is that Lightning is installed and enabled by
 default when you use the upstream binary tarball; the same applies for
 the distro-packaged version.

 - This change doesn't affect the user if he already has Lightning installed
 - With a new TB profile the user is presented with a notification
 about the extension, and he can disable/remove it
 - This is a one time offer, so if the user uninstalls Lightning it
 won't be auto-installed again for that TB profile

 [1] https://blog.mozilla.org/thunderbird/2015/06/thunderbird-38-released/


It appears to have broken the ability to install the gdata provider,
at least when I installed a new F22 system at the weekend I found I
couldn't install it because it requires the lightning package which is
obsoleted by current thunderbird.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Btrfs as default filesystem for Fedora 23?

[Ian Malone]

On 24 June 2015 at 04:28, M. Edward (Ed) Borasky zn...@znmeb.net wrote:
 On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa ngomp...@gmail.com wrote:

 Certainly, but with none of the features in Btrfs actually emitting scary
 experimental warnings anymore, and even all features working in btrfs RAID
 5/6 now, I think we should really start pushing it to more people. Or at
 least develop some kind of test plan to prove the worthiness of using it
 as default. We must have something, ne?

 Bingo! We need

 a. Pass/fail performance criteria
 b. Pass/fail data loss criteria
 c. Pass/fail security criteria


And advice for end users on btrfs management. People trying it out
already are going to be more enthusiastic about understanding
filesystems than the typical user. Also considering whether anything
will be broken by the change, for example, df reporting inaccurate
numbers may have knock on effects.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

[Ian Malone]

On 27 April 2015 at 21:36, Chris Murphy li...@colorremedies.com wrote:
 On Mon, Apr 27, 2015 at 10:52 AM, Simon Farnsworth si...@farnz.org.uk wrote:

 Windows doesn't work fine with RTC in local time, unless you have one and
 only one Windows install on the system. If you (say) dual-boot Windows 95
 and Windows NT 4.0 (I've done this in a work environment), and boot back and
 forth between them on a DST change flag day, then both OSes expect to change
 the RTC to reflect current local time. You then have to pull the RTC time
 back to reality manually, as it's now out by one hour.

 The point is that systemd gets fussy when RTC is in local time even if
 it's a single boot system. I don't know what the full consequence of
 its complaint is, but it complains nevertheless (via timedatectl)
 basically saying it's unsupported.

 Windows 95 and NT are completely different lineages and never
 supported dual-boot. Maybe Windows 95 followed by 98, or Windows NT
 3.5 followed by 4.0 would have; just as it's possible to dual boot
 Windows 7 followed by 8.

 IOW, Windows works with RTC in local time if (and only if) it's the one and
 only OS on the system that writes to the RTC. Fedora also writes to the RTC,
 and thus we have to somehow co-ordinate changes with Windows in such a way
 that DST adjustments only get applied once

 If there's evidence of another system present, maybe don't change the
 RTC? Just use it as a guide absent an Internet connect, and with one
 chrony can set system time without changing the RTC which only causes
 problems.


Why doesn't Windows follow this strategy then (not changing RTC)? Why
change RTC for daylight savings?

Actually, Fedora (most OSes) update the RTC to deal with drift
compared to the more accurate time available from NTP, not to twiddle
daylight savings. Updating the BIOS time is not primarily for DST

 Apple's boot camp package patches Windows to deal with this problem, FWIW.


Which sounds like Apple got fed up with it too.


; I've not looked at UEFI to find
 out whether UEFI solves this.

 It's solved there, I have no idea if this is honored by the kernel or
 systemd though.
 http://wiki.phoenix.com/wiki/index.php/EFI_TIME


Worth noting the bug being discussed and reasons for closing
https://bugzilla.redhat.com/show_bug.cgi?id=1201978 refer to /BIOS/
time and the fact it does not have time zones.



 snip
  We could try to build an infrastructure to store tz information, and
  rebuild initramfses, etc, or we can just rip of the bandaid. This is a
  game of whack-a-mole which accelerates are systems get more dynamic
  and mobile that we cannot really hope to win.

 Hindsight being 20/20, obviously around 13 years ago Linux (and
 friends) should have agreed to not fight the RTC being in local time
 on multiboot systems, in particular dual boot ones with Windows.
 Windows figures out what timezone the RTC is in by reading the
 registry entry 
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
 which a Linux OS service could also defer to by default rather than
 the adversarial relationship that's been chosen.

 Which registry entry 
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation?
 The one in my Windows 95 install, or the one in my Windows NT 4.0 install?

 Seeing as Microsoft doesn't support either one of those for something
 like 20 years now, I'd say neither but still possible to infer another
 OS is already present and to leave the RTC alone and just adapt to a
 local setting and time service rather than insisting on changing the
 clock.

Basically the Windows approach (keep shuffling the BIOS clock and use
flags to remember whether you've done it or not) is broken, or at
least inherently fragile. Multi-boot shows this up.


 Come to that, how is Linux supposed to find and read the registry, given
 that it may not be allowed by administrator policy to mount the filesystem
 that contains the registry? In the worst case, you dual boot the way I did
 at work, where the machine's disk is in a cold swap caddy, and you cannot
 physically get at the disk.

 If it seems like a mono OS installation, then its reasonable for the
 OS to assume it can assume complete ownership of the RTC.

 But just like a VM doesn't assert control over the real hardware RTC,
 a guest OS in a dual boot situation shouldn't either. If that guest is
 intending to be friendly, it ought to adapt rather than enforce a
 whole new policy the primary OS can't deal with.


No OS in a dual boot situation is a 'guest'. Unlike a VM guest the OS
running on hardware is expected to be responsible for that hardware. I
use Fedora daily and Windows less than once a week. Which is the
'primary' OS? Apparently Windows, since it wants to mess with the RTC.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

[Ian Malone]

On 27 April 2015 at 06:47, Chris Murphy li...@colorremedies.com wrote:

 Time in UTC is just as absurd and arbitrary as time in a local
 timezone, so if Windows is going to get berated for not dealing with
 UTC properly, then Fedora can be berated for not dealing with local
 time properly.


Not really, as multiboot systems need to be able to handle DST and
timezone change.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: [Bug 1201978] dracut assumes BIOS time is UTC closed without fixing again

[Ian Malone]

On 27 April 2015 at 09:54, Ralf Corsepius rc040...@freenet.de wrote:
 On 04/27/2015 09:34 AM, Ian Malone wrote:

 On 27 April 2015 at 06:47, Chris Murphy li...@colorremedies.com wrote:

 Time in UTC is just as absurd and arbitrary as time in a local
 timezone, so if Windows is going to get berated for not dealing with
 UTC properly, then Fedora can be berated for not dealing with local
 time properly.


 Not really, as multiboot systems need to be able to handle DST and
 timezone change.


 They have been able to do so for many years with one
 exception: Recent Fedora releases.


I have at least once had a multiboot system two hours out because two
OS both decided they should be updating the BIOS clock. Since when
running the system clock on UTC has seemed the rational thing to do.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Quick C++ question for C++ experts :)

[Ian Malone]

On 1 April 2015 at 16:09, Jonathan Wakely jwak...@redhat.com wrote:
 On 01/04/15 15:16 +0100, Ian Malone wrote:

 Do you mind clarifying? I thought string should provide that
 http://www.cplusplus.com/reference/string/string/operator+/ or is that
 what fno-implicit-templates is turning off?


 Of course string provides it, but it's a template, so it needs to be
 instantiated. The GCC manual documents -fno-implicit-templates like
 so:

  Never emit code for non-inline templates that are instantiated
  implicitly (i.e. by use); only emit code for explicit
  instantiations.

 The invalid program in the OP uses operator+(), which would normally
 instantiate the function template implicitly. But if you use
 -fno-implicit-templates you are promising the compiler you will
 provide explicit instantiations. The program above does not provide
 them, so it is broken.


Thanks. Hadn't occurred to me the + operator here was a template as
I'd never had to deal with basic_string. Still a bit puzzled as
cplusplus.com says string is an instantiation of basic_string while
cppreference.com says it's a typedef (which I guess doesn't count as
explicit instantiation).

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Quick C++ question for C++ experts :)

[Ian Malone]

On 1 April 2015 at 14:32, Jonathan Wakely jwak...@redhat.com wrote:
 On 28/03/15 16:45 -0300, Paulo César Pereira de Andrade wrote:

 2015-03-28 16:06 GMT-03:00 Paulo César Pereira de Andrade
 paulo.cesar.pereira.de.andr...@gmail.com:

 Is this expected to not compile with -fno-implicit-templates?

 ---%---
 $ cat test.cc
 #include string
 std::string test(int i)
 {
 std::string t;
 std::string s = (;
 t = ;
 for (int r = i; r; r=1) {
 if (r  1)
 t = 1 + t;
 else
 t = 0 + t;
 }
 s += t;
 s += );
 return s;
 }

 int
 main(int argc, char *argv[])
 {
 std::string s = test(16);
 return 0;
 }


 As I stated in the bug report, the code is invalid, but used to work
 due to an undocumented accidental feature of libstdc++.so which
 happens to provide instantiations of the required operator+().

 If you use -fno-implicit-templates then it is your responsibility to
 instantiate all the templates you use. The program uses operator+()
 without instantiating it, so the program is wrong. (It also uses a
 number of other templates without instantiating them, which is also
 wrong).


Do you mind clarifying? I thought string should provide that
http://www.cplusplus.com/reference/string/string/operator+/ or is that
what fno-implicit-templates is turning off?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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] Ring-based Packaging Policies

[Ian Malone]

On 13 February 2015 at 13:06, Michael Schwendt mschwe...@gmail.com wrote:
 On Thu, 12 Feb 2015 16:49:13 -0500, Stephen Gallagher wrote:

 On Thu, 2015-02-12 at 20:18 +0100, Alec Leamas wrote:
  On 12/02/15 19:32, Stephen Gallagher wrote:
   (Logistical note: please keep all replies to this thread on
   devel@lists.fedoraproject.org)
  
   tl;dr Shall we consider requiring a lesser package review for packages
   that are not present on Product or Spin install media?
 
 
  Thanks for bringing this up. We really need to do something about this,
  and the proposal is likely to get things rolling.
 
  This is really about two things, right? A lighter review and a general
  bundling exception for packages not in the core (?)
 

 Ultimately, it's about one thing: Help get more software into Fedora
 without scaring people away.

 What is the background for this? Who has been scared away?

 Is this about a few vocal people, who boycott everything related to
 packaging guidelines and update guidelines? We've had a few incidents like
 that *many* years ago when somebody wanted to put pressure on the Fedora
 Project because things are not done in the same way as preferred by such
 people.

 IMO:

 What scares away people primarly is the actual maintenance period during
 the life-cycle of a Fedora. Somebody, who is afraid of making mistakes,
 whether small or large, will likely not join at all. Somebody, who takes
 the requirements too lightly, will run into trouble sooner than later.
 A good example is the first lib upgrade that bumps the soname and has been
 pushed to stable without even testing installation, because of treating
 the repo like a dumping ground. The sudden requirements to learn about
 what needs to be done to prevent this (ABI checks, buildroot overrides,
 rebuilds) make some people think twice whether they want to maintain the
 packages at Fedora.  Plus, in order to rebuild dependencies, they would
 need to co-maintain the dependencies (for commit access) or actively
 communicate with the maintainers of the deps. For some this is too much
 effort to be worthwhile.

Actually, a question I have about this is how it will impact people
trying to become maintainers. When I last checked (it may have
changed) the only way to do that was to create a new package.
Typically that will be a package you're interested in getting into
Fedora which may be non-trivial and benefit from someone more
experienced doing it, or it might be somewhat arbitrarily chosen if
you want to help maintain an existing package.
So, is that implicit test (can you package according to the
guidelines?) going to become easier? Is it necessary to then have a
second level of approval before you can work on core packages if you
started on a non-core package? Should becoming a maintainer become a
bit more decoupled from the process of actually preparing a package?
This doesn't really affect the proposal at hand, but it would be useful to know.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: How to become a packager (was: Re: [Proposal] Ring-based Packaging Policies)

[Ian Malone]

On 13 February 2015 at 15:35, Michael Schwendt mschwe...@gmail.com wrote:
 On Fri, 13 Feb 2015 14:00:07 +, Ian Malone wrote:

 Actually, a question I have about this is how it will impact people
 trying to become maintainers. When I last checked (it may have
 changed) the only way to do that was to create a new package.

 That isn't the only way to become a packager. And it hasn't changed
 for a very long time:

   https://fedoraproject.org/wiki/Category:Package_Maintainers
- 
 https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

 Submitting a new package is just _one_ of multiple ways to find a sponsor,
 since it is an opportunity to demonstrate that you know packaging.


Thanks. I think when I'd looked at it I'd discounted the review and
comment on others' submissions process as it would seem to require you
to have a better idea of what you're doing than the person submitting
the package, and potentially just creating noise when other people are
looking at it too.
Yes, probably a good idea maintainers know how to package. :)

 Random fire'n'forget builds in a public Fedora repo would be something
 that would scare me.

This is sort of a situation we have by default, as it's simpler for
people to package into the SUSE public repo.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: GUI applications writing garbage to stdout/stderr

[Ian Malone]

On 27 January 2015 at 19:10, Przemek Klosowski
przemek.klosow...@nist.gov wrote:
 On 01/27/2015 07:03 AM, Bastien Nocera wrote:

 All those are warnings, not garbage or debug output. File bugs about
 those, there should be zero warnings in normal usage.

 Shouldn't they trigger abrt then? more importantly, is it possible to
 capture that in the QA process during distribution composition? I believe a
 lot of those warnings aren't environment dependent, but rather would appear
 in a generic installation, so it would be appropriate to detect them early
 and take some corrective action---either block them or at least log bugs.


Warnings should not cause an application to crash, which IIUC is what
abrt is supposed to pick up on. Ideally you should have no warnings,
in practice lots of them may not have any symptoms that affect the
user and be relevant to the developer instead.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Set sshd(8) PermitRootLogin=no

[Ian Malone]

On 14 January 2015 at 14:31, Simo Sorce s...@redhat.com wrote:
 On Wed, 14 Jan 2015 05:53:23 + (UTC)
 P J P pj.pan...@yahoo.co.in wrote:


 IMO, the ones opposing are those who fear their current
 setups/practices would break. Because they need remote 'root' access
 in their set-up. Which is a genuine use-case. And to support it, we
 could provide an option to enable remote root access with
 'PermitRootLogin=Yes', based on the the user's response to Anaconda
 at install time, as was suggested in previous email. However, let's
 not assume _all_ Fedora users have this use-case.

 Workstation do not even enable sshd (IIRC) so this impacts the server
 images (cloud images already do their magic with sshd so I am not
 counting them here), and server has different use cases and security
 implications than a generic population.


Not just workstation, spin images, it's a decision pre-dating workstation.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Ian Malone]

On 30 December 2014 at 01:26, Rahul Sundaram methe...@gmail.com wrote:
 Hi

 On Mon, Dec 29, 2014 at 7:36 PM, Ian Malone wrote:


 Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL
 upstream (so far as I am aware anyway).


 That is incorrect.  Fedora is upstream for RHEL and therefore upstream for
 CentOS as well albeit, one step removed.


I stand corrected then. Anyone know when this changed?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Ian Malone]

On 30 December 2014 at 13:13, Emmanuel Seyman emman...@seyman.fr wrote:
 * Ian Malone [30/12/2014 13:09] :

 On 30 December 2014 at 01:26, Rahul Sundaram methe...@gmail.com wrote:

  That is incorrect.  Fedora is upstream for RHEL and therefore upstream for
  CentOS as well albeit, one step removed.

 I stand corrected then. Anyone know when this changed?

 This has always been the case. What made you think differently?


Thought I'd been told otherwise at some point in the past, but must
have been a misunderstanding. Had thought they weren't that closely
coupled, i.e. not direct forks, but looks like I was wrong.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Ramblings and questions regarding Fedora, but stemming from gnome-software and desktop environments

[Ian Malone]

On 27 December 2014 at 21:53, Adam Williamson
adamw...@fedoraproject.org wrote:
 On Sat, 2014-12-27 at 15:57 +0200, Alexander Ploumistos wrote:

 Actually we do have a VLTS (Very Long Term Support) release, CentOS,
 especially now that they've joined the family, but the connection is
 not immediately apparent.



 CentOS is not a release of Fedora. It is a separate distribution which
 has Fedora as its upstream.

Minor correction, CentOS is unbranded RHEL and Fedora is not RHEL
upstream (so far as I am aware anyway).

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Poll: How users use DNF

[Ian Malone]

On 9 December 2014 at 17:28, Radek Holy rh...@redhat.com wrote:
 Dear users of YUM and DNF,

 I'm writing to you regarding a request for your feedback. I would be very 
 grateful if you could send me a brief description of how you use YUM or DNF 
 currently or how would you like to use it. I am particularly interested in 
 the occurrences of dnf/yum install calls in your scripts. What does these 
 scripts do and what do they expect when they call the install command in 
 different situations?

 Please share with me the use cases, not the description of the install 
 command. Think twice before you share something because I believe it's not as 
 easy as it might seem. As an example I think it might be something like:


Hi,

I do different things at home (Fedora) and work (RHEL). At work our
system administrator uses satellite to push out changes (as a result
no scripting of yum), but as I do building and testing of things I
need to be able to install packages and often while maintaining
existing versions, so things will usually go:
1. yum install foo-devel
2. If offered a foo-devel with update to foo and various dependencies,
say no, if no updates then say no.
3. Copy current version of package and attempt with that appended,
e.g. yum install mesa-libGLU-devel-7.11
In the single example of a -devel package I could short circuit this
by doing an rpm -q on the base package first, but in some cases you're
installing completely new libraries, in which case offered updates
mean using
yum search --showduplicates
to find earlier available versions. Don't do this often enough to have
looked into more efficient ways of doing it, since it's not that time
consuming if the things actually exist.

Home, usually just the regular user stuff of making sure packages are
most recent. Occasionally downgrading or installing things from koji
when working with bugs.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 10 December 2014 at 00:43, Bastien Nocera bnoc...@redhat.com wrote:


 - Original Message -
 On 9 December 2014 at 13:47, Matthew Miller mat...@fedoraproject.org wrote:
  On Tue, Dec 09, 2014 at 01:11:33PM +, Ian Malone wrote:
   have a proposal for a new spin focused on privacy and security — the
   Netizen Spin. (If you're interested, I think that could use additional
   contributors.)
  I was under the impression spins were to be phased out. I could be
  wrong, the discussion was about the time of the product proposal.
 
  That's wrong; the clear outcome of that discussion was that we want to
  keep them, and provide more flexiblity and opportunity for spins
  maintainers as well.
 

 Well that's some good news to come out of this at least.

  Everyone knows that there are improvements to be made, but it's _not_
  an easy problem. Contributions are welcome towards making that better
  for F22 and beyond. (Use cases. Design mockups. Code)
 

 Rather time poor at the moment and not a gnome developer
 unfortunately. Does rather sound like things like rygel need fixed,
 but as I have no intention of ever using it I'm not highly motivated
 to do something about it.

 Just like Reindl you make the mistake of thinking that rygel needs to be fixed
 or that it's the only service impacted by this scheme. It's not, and it was
 pointed out in earlier mails.


You're sniping at me now, and making assumptions. So I get to do this,
please read the fedora code of conduct and be awesome!
http://fedoraproject.org/code-of-conduct

I have skimmed the links you listed. Like I said, time poor. I see no
explanation of why rygel needs a random port or why it cannot supply
that information to firewalld. The same goes for any others that have
random ports.


-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 10 December 2014 at 11:47, Bastien Nocera bnoc...@redhat.com wrote:


 - Original Message -
 On 10 December 2014 at 00:43, Bastien Nocera bnoc...@redhat.com wrote:
 
 
  - Original Message -
  On 9 December 2014 at 13:47, Matthew Miller mat...@fedoraproject.org
  wrote:
   On Tue, Dec 09, 2014 at 01:11:33PM +, Ian Malone wrote:
have a proposal for a new spin focused on privacy and security — the
Netizen Spin. (If you're interested, I think that could use
additional
contributors.)
   I was under the impression spins were to be phased out. I could be
   wrong, the discussion was about the time of the product proposal.
  
   That's wrong; the clear outcome of that discussion was that we want to
   keep them, and provide more flexiblity and opportunity for spins
   maintainers as well.
  
 
  Well that's some good news to come out of this at least.
 
   Everyone knows that there are improvements to be made, but it's _not_
   an easy problem. Contributions are welcome towards making that better
   for F22 and beyond. (Use cases. Design mockups. Code)
  
 
  Rather time poor at the moment and not a gnome developer
  unfortunately. Does rather sound like things like rygel need fixed,
  but as I have no intention of ever using it I'm not highly motivated
  to do something about it.
 
  Just like Reindl you make the mistake of thinking that rygel needs to be
  fixed
  or that it's the only service impacted by this scheme. It's not, and it was
  pointed out in earlier mails.
 

 You're sniping at me now, and making assumptions. So I get to do this,
 please read the fedora code of conduct and be awesome!
 http://fedoraproject.org/code-of-conduct

 Given the amount of time I've thrown into this dead-end thread, I think
 I'm already pretty awesome.

 I have skimmed the links you listed. Like I said, time poor.

 You'll accuse me of being rude again, but if you can't read 3 pages of text
 because of the lack of time, maybe spending that time throwing factually
 and technically incorrect suggestions on the list shouldn't top of your
 TODO list.


Well, there are different levels I suppose. There's, I don't have
time before work to read through three pages of chaff AND COMMENTS in
detail. As it turned out the only salient point was in a comment. The
rest was pretty irrelevant.
There's, I don't have time in the foreseeable future to spend
learning sufficient information about the internals of the various
systems to help out with this particular problem. There's, I used to
spend time doing spin QA, but hardware requirements are currently such
that I can't virtualise recent releases and don't have time for bare
metal testing which may change in the new year.
And there's, I do have time to respond to an email accusing me of
making factually and technically incorrect suggestions. Because I'd
have walked away at this point if you hadn't felt like padding out
your wonderful life coaching.
(I note that I'm a saddo who doesn't know how to manage time, but
you're awesome for spending time on exactly the same thread.)

You answered precisely half of this:

 I see no
 explanation of why rygel needs a random port or why it cannot supply
 that information to firewalld. The same goes for any others that have
 random ports.

 Because that's the mechanism the kernel offers for applications when 
 selecting a
 port isn't important, the high port isn't defined by the IANA, and the specs
 (DLNA/UPnP in this case) don't force particular ports to be opened.

 Even if we chose static ports for those (or rather port ranges, because if you
 have multiple users running, you'd need multiple ports), leaving only those 
 ports
 opened wouldn't stop other random applications from choosing those ports to
 do something nefarious. You're just limiting the availability of ports without
 increasing security.

There's no predefined port. So rather than picking one, which would be
perfectly possible, any port is asked for. Yes, limiting it to one
means only one user can use it without changing those scary settings,
but how often is that actually done? Having the other ports closed
prevents unintentional exposure and also makes life harder for any
nefarious use. But this has all been pointed out already. It also, if
I understand correctly, means policies could be shipped with the
package.

But if you really want to use a random port, this is what firewalld
was for, dynamic firewall changes. In fact, a quick google finds this
bug:
https://bugzilla.redhat.com/show_bug.cgi?id=626188
Which was showing progress towards rygel being able to do that. But
it's been closed 'next release', because apparently the ports above
1024 have been unblocked in the firewall. Except this is not a fix, as
(as we've learned) it doesn't apply to Fedora other than Desktop and
Cloud. That's an interesting move, perhaps you would like to suggest a
'fixed in product X' resolution for use in future.

-- 
imalone
http://ibmalone.blogspot.co.uk

Re: Workstation Product defaults to wide-open firewall

[Ian Malone]

On 9 December 2014 at 11:35, Michael Catanzaro mcatanz...@gnome.org wrote:
 On Mon, 2014-12-08 at 10:49 -0500, Bastien Nocera wrote:
 If Reindl, Kevin or Tomas want to disagree with that, I'll give you a
 little
 exercise:
 Having just installed and updated my Fedora 20, I want to share a
 video in my
 home directory using UPnP/DLNA to my TV, using rygel for example.
 Document the
 steps necessary to achieve that.

 So unless anyone opposed to the firewall configuration change actually
 attempts this exercise, and comes up with a working alternative solution
 to the problem, I'm not sure there's much point in continuing the
 discussion.


Well, without access to Bastien's TV, home directory and router it's a
bit difficult. Or is that the point?
I haven't used rygel, is there any reason to believe difficulty doing
this is not a problem with rygel in F20?

 We are concerned with practical security -- keeping the user safe by
 anticipating the user's typical response to situations. But if you think
 the firewall configuration GUI in F20 existed for any purpose other than
 to completely disable the firewall, please take a reality check.

This isn't quite as bad as that other thing. Isn't the most
persuasive argument, and in some cases it is worse (at least a user
who's disabled the firewall knows they've done so).

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 8 December 2014 at 15:33, Matthew Miller mat...@fedoraproject.org wrote:
 On Mon, Dec 08, 2014 at 02:31:58PM +, Ian Malone wrote:
 There are three products: workstation, server, cloud. Workstation is
 the one for desktop use. That leaves server to aim for the traditional
 fedora user base, since cloud is (understandably) a very different
 thing. So if you want a desktop system with a security focus where do
 you look now?

 So, it's important to understand — here on the devel list, certainly —
 that these three are part of a marketing strategy, and in order for
 such a thing to be effective and not just fluffy talk, it does involve
 technical changes to match the plan.

 Right now, desktop system with a security focus for new users isn't a
 key part of that effort. I certainly don't dispute that user security
 and education are good goals, and I don't think anyone on the
 workstation team does either — it's just a matter of the steps we take
 to get there.

 So, if you're not in the target of that focus, where do you look? Well,
 you can certainly pick one of our other desktop spins, which have
 different firewall defaults. Currently, all the generic one, but I'd
 like to move to a model where spins have more freedom here too. We even
 have a proposal for a new spin focused on privacy and security — the
 Netizen Spin. (If you're interested, I think that could use additional
 contributors.)

I was under the impression spins were to be phased out. I could be
wrong, the discussion was about the time of the product proposal.


 Or, you can do what I do: start with Fedora Workstation and then
 configure it in a way that makes sense for my needs, or if you're
 deploying for users into a managed environment, use the tools the OS
 provides to preconfigure the system for whatever makes sense there.


The thing is, while everyone in this discussion is probably capable of
changing such defaults, it reflects a shift in priorities that leaves
me wondering whether there'll be more such things that change and
current users need to keep an eye on. If workstation doesn't want to
appeal to current users why should they hang on and keep trying to
tweak it to what they want? We now need to watch workstation to see
what's going to happen on the desktop too. So the current list of
things fedora users need to be subscribed to if they don't want to
miss changes:

users
devel
desktop
(testing?)
Where two of those are development lists where users aren't
particularly welcome and on the other any discussion that involves
what goes into the OS (or of an upcoming release the week before it's
out) is declared off topic.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 9 December 2014 at 13:47, Matthew Miller mat...@fedoraproject.org wrote:
 On Tue, Dec 09, 2014 at 01:11:33PM +, Ian Malone wrote:
  have a proposal for a new spin focused on privacy and security — the
  Netizen Spin. (If you're interested, I think that could use additional
  contributors.)
 I was under the impression spins were to be phased out. I could be
 wrong, the discussion was about the time of the product proposal.

 That's wrong; the clear outcome of that discussion was that we want to
 keep them, and provide more flexiblity and opportunity for spins
 maintainers as well.


Well that's some good news to come out of this at least.

 Everyone knows that there are improvements to be made, but it's _not_
 an easy problem. Contributions are welcome towards making that better
 for F22 and beyond. (Use cases. Design mockups. Code)


Rather time poor at the moment and not a gnome developer
unfortunately. Does rather sound like things like rygel need fixed,
but as I have no intention of ever using it I'm not highly motivated
to do something about it.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 8 December 2014 at 08:38, Paul Howarth p...@city-fan.org wrote:
 On Mon, 08 Dec 2014 07:41:52 +0100
 Kevin Kofler kevin.kof...@chello.at wrote:

 Hi,

 I just happened to look at the firewalld default settings, and I was
 not amused when I noticed this:
 http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml
   port protocol=udp port=1025-65535/
   port protocol=tcp port=1025-65535/
 This firewall is a joke! ALL higher ports are wide open!

 There had been a prior discussion on this list where they wanted to
 disable the firewall entirely. We told them that that's a horrible
 idea (which it is, of course!). But the result is that they
 implemented this solution which is almost entirely as bad, and
 which additionally gives users a false sense of security, because a
 firewall is enabled (for a very twisted definition of enabled).

 IMHO, this is a major security issue that MUST be fixed. It also
 shows what horribly bad an idea per-Product configuration is.

 Yet another reason why you should NOT use --product=workstation to
 upgrade your F20 to F21 (ALWAYS use --product=nonproduct).
 Installing the Workstation Product, or upgrading to it, will leave
 you with a totally insecure system.

 FWIW, this is mentioned in the release notes:

 http://docs.fedoraproject.org/en-US/Fedora/21/html/Release_Notes/sect-Products.html#Products-Workstation

 2.3.3. Developer oriented firewall

 Developers often run test servers that run on high numbered ports, and
 interconnectivity with many modern consumer devices also requires these
 ports. The firewall in Fedora Workstation, firewalld, is configured to
 allow these things.

 Ports numbered under 1024, with the exceptions of
 sshd and clients for samba and DHCPv6, are blocked to prevent access to
 system services. Ports above 1024, used for user-initiated
 applications, are open by default.


That's a rather confused explanation to me, developers are able to
adjust their firewalls or disable them for troubleshooting if they
wish. It then ropes in interconnectivity with many modern consumer
devices.

Does feel rather like a fedora-no-longer-has-your-back moment.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 8 December 2014 at 12:02, Aleksandar Kurtakov akurt...@redhat.com wrote:
 - Original Message -
 From: Reindl Harald h.rei...@thelounge.net
 To: devel@lists.fedoraproject.org
 Sent: Monday, December 8, 2014 1:26:29 PM
 Subject: Re: Workstation Product defaults to wide-open firewall



 Am 08.12.2014 um 12:22 schrieb Bastien Nocera:
  Am 08.12.2014 um 11:45 schrieb Bastien Nocera:
  Well, I'll understand these aspects.
 
  But when I think about Linux, especially about Fedora, I'm thinking
  about the freedom to make decisions. This means to me, to customize
  and take advantage of my computer and in this case my operating system.
 
  You're free to select another firewall zone
 

And free to move to another distro of course.

  so why do you not make secure defaults and say You're free to select
  another (more unsecure) firewall zone?
 
  1) It is secure enough and Eclipse listening to a port by default is a bug
  (and I have the firewall specialists at Red Hat/Fedora to back me up)
  2) Good defaults

 again: the *purpose* of a Firewall is to protect from application bugs
 or unintentional user faults - frankly the early KDE4 setups in 2008 had
 a ton of 0.0.0.0 listenining high ports, that where indeed a bug and
 hence a firewall to protect the user against such bugs

 it is not a bug that ZendStudio is listening on a high UDP port for
 license verification (only one instance in the same network via broadcasts)

 it is intentional by the software

 I'm not going to comment what is good, what is intentional and etc.
 All I'm asking for is for precise wording aka when something is done by 
 ZendStudion or any other Eclipse plugin is to name it unless it's something 
 that Eclipse Platform/RCP does.
 As both Fedora and upstream Eclipse platform developer I really care about 
 negative press we get because of such statements. Eclipse listens on some 
 port by default translates into Eclipse is insecure and etc. is entirely 
 not-true. We have a very strict privacy policy 
 (http://www.eclipse.org/legal/privacy.php and 
 http://wiki.eclipse.org/Policies/Uploading_and_Downloading_from_Eclipse_Software_Policy)
  so I sincerely ask people to not spread false statements like the one.


Well, it's in your hands now, and every application developer's hands,
if RH is going to be turning the default firewall off.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 8 December 2014 at 13:45, Matthew Miller mat...@fedoraproject.org wrote:
 On Mon, Dec 08, 2014 at 12:11:40PM +, Ian Malone wrote:
   You're free to select another firewall zone
 And free to move to another distro of course.

 Well, or free to select another Fedora offering, or configure you
 systems to not be Fedora Workstation.

 The defaults are different in the generic config, and appropriately
 more strict in Server. However, as a point of reference, there is no
 configured host packet-filter firewall at all in Cloud, as that's not
 the expectation in that environment.


Pulling in another quote:
 That's the main point, but as a secondary one, please take a look at
 http://fedoraproject.org/wiki/Workstation/Workstation_PRD. We aren't
 those other operating systems, but the target audience that Workstation
 is aiming for _isn't_ entirely the traditional Fedora userbase. That's
 a good thing; we have a model here were we can actually have different
 configurations for different use cases.

There are three products: workstation, server, cloud. Workstation is
the one for desktop use. That leaves server to aim for the traditional
fedora user base, since cloud is (understandably) a very different
thing. So if you want a desktop system with a security focus where do
you look now?

As pointed out elsewhere, the firewall configuration GUI isn't even
installed by default, so if you want to change this on a new system
you may have to connect to the internet to do it and this is hidden
from people who are new to the system.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Are both the audio and jackuser groups necessary?

[Ian Malone]

On 8 December 2014 at 15:15, Jonathan Underwood
jonathan.underw...@gmail.com wrote:
 Hi,

 A perhaps naive question, but is it really necessary to have both the
 audio and jackuser groups? Could these not be consolidated moving
 forward?


jackuser is used for realtime priority and memlock rights,
/etc/security/limits.d/95-jack.conf. I'm not certain how audio is used
these days with pulseaudio in the mix, but it's still attached to
devices in /dev/snd, so they do quite different things.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: How many users does Fedora have?

[Ian Malone]

On 1 December 2014 at 20:55, Stephen John Smoogen smo...@gmail.com wrote:


 On 1 December 2014 at 05:05, Reindl Harald h.rei...@thelounge.net wrote:


 Am 01.12.2014 um 12:57 schrieb Pierre-Yves Chibon:

 So we come back to the question: is any number better than no number at
 all?
 Even to get a trend?


 no number is in fact better than wrong numbers backed by nothing beause
 they lead in wrong conclusions - your 122/133 numbers could in reality also
 be 1000 users installed them from mirrors and your calculation is the best
 example for wrong assumptions


 While that is 'true', most of the world doesn't work on 'true'. Your cars
 speedometer doesn't give you the accurate km/hour. [Even BMW digital has a
 +/- 2 km/hour due to all the factors from tire present size to road
 conditions.]. The answer is can you accurately remove enough noise to feel
 confident that you are doing 100 km/hour versus 120 km/hour. The same goes
 for measuring downloads.


It depends how and why you are collecting data. If, for example, you
are sensitive to how often downloads occur from mirrors, then sites
that use local repositories will be under-represented. And if that
happens to be a use type that typically customises their package
choices in some way then those choices wont turn up. There are two
types of error in general, random noise and bias. Rough analogy, if
your spedometer actually reported 0.85 of your real speed if may not
make a very noticeable difference at 30mph, but at 70 it does (and
worse if it turns out to be non-linear).

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Trig functions from math.h

[Ian Malone]

On 26 November 2014 at 19:06, Les Howell hlhow...@pacbell.net wrote:
 Gentle developers:
 I have some older code that used to compile, which I wish to reuse and
 maybe redesign.  However the code is C and uses the sinf function, which
 seems to have disappeared from math.h.  Can anyone tell me where this
 has gone?  The man pages no longer return the sinf function, Info pages
 say that it should be in either math.h or complex.h, but it is not.  The
 either math.h needs some modification (dated Sep 26 this year), and the
 man pages need updating, or the new function needs to be named,
 supported and the information on the Info pages needs to be updated.
 But in the interim, what is a work around?  Please don't tell me I have
 to code a trig function.

This is part of c99, so if it's not there it's a bug.

Don't have a Fedora box in front of me to test on, but it might not be
available if you don't supply -lm (in theory only applies to linking
the libraries, but I think it can have other effects), and may need to
specify a standard that includes it, possibly --std=c99 or --std=gnu99
to get the right definitions available. Defining _DEFAULT_SOURCE
suggested by Kevin Kofler may have a similar effect if your build
system is forcing c89 or something.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Improving the offline updates user experience

[Ian Malone]

On 22 October 2014 20:07, Michael Stahl mst...@redhat.com wrote:
 On 17.09.2014 13:58, Miroslav Suchý wrote:
 On 09/17/2014 11:54 AM, Bastien Nocera wrote:
 All those OSes require reboots when updating the OS.

 Define OS.

 Firefox is definitely not OS. While systemd is OS.
 I am fine with reboot after systemd upgrade, but not after upgrading Firefox.

 the important point in that case is not reboot after upgrading Firefox
 but *before* upgrading Firefox, which means that at the time of the
 upgrade no Firefox will be running and potentially crashing because one
 of the 100s of DSOs it loads on-demand has changed in an incompatible way.

 there used to be quite a few ABRT crashes reported against desktop
 applications with impossible looking stack traces (although with the
 automatic micro-reports it's less of a problem nowadays as they are
 easier to ignore), and sometimes the reporter gives feedback that the
 application was running across a yum update...


While it can be a bit confusing the first time it happens to you, the
solution is just to start and stop firefox again in that case. If it
the goal is just to tidy ABRT crash reports (and I'm not sure it is)
then forcing reboots on users wouldn't be very kind.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Dash as default shell

[Ian Malone]

On 8 October 2014 12:35, Miloslav Trmač m...@redhat.com wrote:

Been away for a week and come back to this nonsense. Why put so much
effort into arguing *against* having the right interpreter listed at
the top of a script. Seems pretty perverse to insist it should be
/bin/sh to maintain a conflation that's unique to RH.

 - Original Message -
 On 6 October 2014 17:28, Miloslav Trmač m...@redhat.com wrote:
  - Original Message -
   usage/requirement as well.  Bringing the benefits of supporting dash to…
   the satisfaction of pedantically using the POSIX /bin/sh path as
   frequently as possible?
 
  Also known as portability, compatibility
 
  Upstreams can be interested in cross-distro portability and compatibility.
  I don’t see much benefit for Fedora and Fedora’s users.
 

 Fedora is never upstream? Ever?

 The cases where Fedora is both a distribution and upstream happen, but in 
 these cases the difference doesn’t matter.  It’s the other cases, where the 
 roles are separate, that allow us to judge where the benefit, effort and 
 policy should be allocated.


Fedora is upstream for packaging and remixes. I tried to illustrate
that, but you've cut it from the quotes.

  and transparency.
 
  Perhaps for changing the #! line; adding yet another programming language
  to the OS would make it more complex and thus _reduce_ transparency.

 Not another programming language, one that is already being used.

 If they have so different features and syntax that people writing scripts 
 need to be aware of this, they are different languages.  Or to put it the 
 other way, if they were the same languages then assumption that /bin/sh is 
 bash couldn’t matter.


And they're not the same, which is what the whole discussion about, so
it does matter.

  Do we
  encourage people to turn compiler warnings off?
 
  No, but most compiler warnings are useful _for increasing quality
  noticeable to users of Fedora_.  A warning about use of a bash construct
  when we are using bash doesn’t help us help users.

 Getting dependencies right isn't helpful?

 That’s what I said, and I think I said why.  If you think that changing 
 dependencies, when it would change neither behavior nor on-disk contents is 
 helpful, could you explain how?


Because they're the true dependencies.
Anyway I'm off to change gcc to a link to g++ on my systems because
they're close enough it shouldn't matter.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 6 October 2014 09:41, Rahul Sundaram methe...@gmail.com wrote:
 Hi

 One of the long standing features that were enabled by default in yum is
 support for delta rpms.  dnf developers have disabled this and I think this
 change deserves a broader discussion

 https://bugzilla.redhat.com/show_bug.cgi?id=1148208


I have an internet flatrate at 150 mbs, and downloading the full rpms
is ALOT faster than the the work that the delta rpms requires.

Wow. Good to see normal users are taken into account. The main
argument from a distro point of view is reducing load on servers, but
I don't know many people on 150Mbs either. Heck, I've just tested my
work janet connection and that's 100Mbs in our office. At home 8Mbps
is a good day. (I'm assuming mbs is a typo for Mbps and not milli bit
seconds, where the very slow transfer speed declines exponentially as
the connection progresses.)

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Dash as default shell

[Ian Malone]

On 6 October 2014 16:57, Miloslav Trmač m...@redhat.com wrote:
 - Original Message -
 On Fri, Oct 03, 2014 at 02:29:53PM -0600, Orion Poplawski wrote:
  Is it worth considering using Dash as the default (non-interactive)
  shell in Fedora?  Other distributions including Ubuntu and Debian
  (https://lwn.net/Articles/343924/) have been using dash as the default
  shell and Android uses mksh.  While this appears to have been done
  primary to increase bootup efficiency (which is not relevant with
  systemd), it might help with security
 
  More bashism's in .spec files:
  + pushd src
  /tmp/rpm/rpm-tmp.047Jay: 43: /tmp/rpm/rpm-tmp.047Jay: pushd: not found

 All the other things aside, I think it'd be fine for us to leave bash as the
 shell for spec file scripts even if we changed /bin/sh and/or the root
 shell.

 At that point switching anything to dash can _only increase_, not reduce, the 
 disk space needed, and is very likely to increase the total page cache 
 usage/requirement as well.  Bringing the benefits of supporting dash to… the 
 satisfaction of pedantically using the POSIX /bin/sh path as frequently as 
 possible?

Also known as portability, compatibility and transparency. Do we
encourage people to turn compiler warnings off?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Dash as default shell

[Ian Malone]

On 6 October 2014 17:28, Miloslav Trmač m...@redhat.com wrote:
 - Original Message -
  At that point switching anything to dash can _only increase_, not reduce,
  the disk space needed, and is very likely to increase the total page cache
  usage/requirement as well.  Bringing the benefits of supporting dash to…
  the satisfaction of pedantically using the POSIX /bin/sh path as
  frequently as possible?

 Also known as portability, compatibility

 Upstreams can be interested in cross-distro portability and compatibility.  I 
 don’t see much benefit for Fedora and Fedora’s users.


Fedora is never upstream? Ever? What happened to all the discussions
of remixes in Janurary for a start? And we're not interested in
interoperability with other distros? Because Fedora-land is quite
small compared to the whole picture.

 and transparency.

 Perhaps for changing the #! line; adding yet another programming language to 
 the OS would make it more complex and thus _reduce_ transparency.


Not another programming language, one that is already being used.
Being explicit about it. Why be so resistant to that?

 Do we
 encourage people to turn compiler warnings off?

 No, but most compiler warnings are useful _for increasing quality noticeable 
 to users of Fedora_.  A warning about use of a bash construct when we are 
 using bash doesn’t help us help users.

Getting dependencies right isn't helpful?

Lastly:
http://en.wikipedia.org/wiki/Open_Build_Service
Even the scripts that you might think are solely Fedora specific could
be useful to other people.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Dash as default shell

[Ian Malone]

On 2 October 2014 07:33, Lennart Poettering mzerq...@0pointer.de wrote:
 On Wed, 01.10.14 22:39, Rahul Sundaram (methe...@gmail.com) wrote:

 Hi

 Is it worth considering using Dash as the default (non-interactive) shell
 in Fedora?  Other distributions including Ubuntu and Debian (
 https://lwn.net/Articles/343924/) have been using dash as the default shell
 and Android uses mksh.  While this appears to have been done primary to
 increase bootup efficiency (which is not relevant with systemd), it might
 help with security

 Since the recent Shellshock aka Bashdoor vulnerability, there have been
 some discussions about more distributions switching over (
 http://lwn.net/SubscriberLink/614218/019d9a52b0eaae3d/) and I was wondering
 whether it is worth considering for Fedora?  FWIW, both dash and mksh is
 already packaged in Fedora.

 This sounds really wrong to me.

 If you change /bin/sh to dash, then you'll have to map two shell
 binaries into memory (since the login shell is going to stay on bash),
 hence the resource usage grows. You increase the number of packages
 and minimal footprint of our OS images since we need to install one
 more package.

Total download size: 91 k
Installed size: 163 k


 You also increase the attack surface, since there'll be
 two shells running. You have to maintain + security-fix more code,

Versus this the default shell may be more exposed, it plays a
particular role in the system. As does a login shell. To be honest
most people do not need bashisms in the login shell either

 since you have two packages to look after (Yes, by adding dash to the
 default stack you just put the extra burden on Fedora to quickly
 update two packages instead of just one in case of a security
 problem). You create a *lot* of porting work for all those
 scripts. You *break* all scripts that currently reference /bin/sh in
 the shebang-line but use bashisms. Also, many of the bashisms are

/bin/sh scripts usings bashisms are broken already, you merely expose
it. Much of this work will have been done in debian/ubuntu already. I
was under the impression the move was away from system scripts in any
case.

 actually pretty useful, hence you replace a more powerful language by
 a crappier one. You create an entirely new problem for our users, by

Well, less powerful is not 'crappier'. It may well be the lower
complexity of dash that contributed to bash being the first one to
show up a vulnerability.

 making them *think* whether they actually mean /bin/sh or
 /bin/bash. You confuse users by disallowing certain expressions in
 scripts that work fine if you type them on the interactive shell.

None of this is a problem. You also have to think whether you mean
/bin/sh or /usr/bin/python. Or .c or .cxx.


 So, in order to keep things simpler, faster, more secure, more
 maintainable, more compatible, let's please stick with one shell and
 one shell only, and let's stay with bash. Thank you.


I'm not a big dash partisan, whenever I write a shell script more
often than not it starts /bin/bash, but this at least needs some
consideration. Fedora has made quite a few radical changes in the
past, with mixed results. This is a not very radical change that's
been used for quite some time in other distros and doesn't actually
break POSIX for once.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Dash as default shell

[Ian Malone]

On 2 October 2014 17:13, Ralf Corsepius rc040...@freenet.de wrote:
 On 10/02/2014 03:07 PM, Rahul Sundaram wrote:

 Hi

 On Thu, Oct 2, 2014 at 8:59 AM, Chris Adams wrote:


 If that's the case, why do we have the /bin/sh symlink?  Just remove
 it
 and make the bash dependency explicit (so everything has to call
 /bin/bash).


 I understand this is a rherotical argument but the symlink exists
 because it is required by things like system()


 No. /bin/sh is supposed to be a POSIX-compatible shell.

 I.e. scripts using #!/bin/sh shebang rely upon being interpreted
 POSIX-correctly and not to use any feature diverging from POSIX.


 As bash implements a superset of POSIX, it changes its behavior to a more
 POSIX-compliant behavior depending upon the name it is being invoked.


More posix compliant maybe, but still providing extensions. Otherwise
changing sh to another posix compliant shell would not cause people to
worry about /bin/sh scripts that would be broken by the change.

Whether bash or dash is more secure (and don't discount the fact that
debian and ubuntu mean there is effort going into dash), it's not a
great argument that /bin/sh should be bash to support scripts that
incorrectly use sh when they mean bash. From the point of view of
specifying dependencies, interoperability, even potentially security
auditing, if it needs bash it should specify bash. This makes sense
when you consider:
1. shellshock. A temporary workaround if /sh could be changed to a
different shell without breaking things would have been to do that
until patches came out. This applies whatever the default shell is.
2. Lightweight. It may make sense to change to dash by default, it
might not, but if sh means sh then people building minimal systems can
make that choice themselves and easily see (by grepping /bin/bash)
whether they're going to hit a problem. Applies for something like ash
or other alternatives too.
3. Portability. BSD, Debian, Ubuntu don't use bash. It really is the
case that there is still an API for sh and it's not bash.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Dash as default shell

[Ian Malone]

On 2 October 2014 13:59, Chris Adams li...@cmadams.net wrote:
 Once upon a time, Lennart Poettering mzerq...@0pointer.de said:


 In general, I am pretty sure that except a couple of programming
 language or UNIX aficionades very few people can actually correctly
 separate bashisms from true bourneshellisms.

 It isn't that hard.

Anyone who has to write things that work on Ubuntu too for a start.
Really if you don't know what the extensions are you probably don't
need bash.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Increasing application icon sizes to 64px

[Ian Malone]

On 30 September 2014 02:09, Michael Catanzaro mcatanz...@gnome.org wrote:
 On Mon, 2014-09-29 at 22:05 +0100, Ian Malone wrote:
 Who is using magnifying glasses to view icons?

 Icons are displayed far larger in GNOME Shell than in other desktop
 environments, and the difference between an SVG icon and a 256x256 icon
 (the mandatory minimum size for GNOME apps, and I'm definitely not the
 maintainer of several apps with only 128x128 icons, don't look at me) is
 fairly noticeable. 48x48 is really too low. 64x64 is too low


That might be a good reason, but it's not the one given at the start
of this proposal, that was that larger icons are needed for the
software centre (i.e. for applications to get included in the
installer) due to higher resolution displays. In which case thinking
of the level of detail that should be in an icon should not be in
terms of 32x32, 64x64 etc., but in displayed sizes. Gnome Shell (last
time I looked) displays  what you might call large icons, where more
detail is appropriate, those will have to get bigger (in pixel count)
too by this reasoning, without increasing in detail.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Increasing application icon sizes to 64px

[Ian Malone]

On 29 September 2014 12:40, Richard Hughes hughsi...@gmail.com wrote:
 On 29 September 2014 12:23, Matěj Cepl mc...@cepl.eu wrote:
 Couldn’t we just stop this madness of bitmaps?

 SVGs are not a silver bullet. You'd want a very different source SVG
 file for an icon that's designed to be displayed at 22x22, to an icon
 designed to be displayed at 256x256. Plus, rendering SVGs with
 inkscape and rsvg sometimes output *very* different results...


Not necessarily. The strongest argument so far in this thread about
not simply scaling up (in pixels) icons has been that it's noticeable
in an environment where the other elements are crisp. Your point about
SVGs is that larger icons can include more detail, but actually the
icons are not supposed to be physically larger, so is adding more
detail a good move? Who is using magnifying glasses to view icons? Is
it a good idea taking into account visually impaired people to cram in
more detail to the same screen area just because it's available?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: OT: Patching a source makes it a fork?

[Ian Malone]

On 15 August 2014 12:30, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Fri, Aug 15, 2014 at 5:28 AM, Ian Malone ibmal...@gmail.com wrote:
 (I'm very sympathetic to your plight as I've been waiting months to
 try and get a known patch from the actual author of the original code
 into the kernel.)

 Which?


Oh, it's this one, you've already tried to help with it,
https://bugzilla.redhat.com/show_bug.cgi?id=991708 I need to push
harder at the lkml to get it taken up (think there was a bit of a
derail at the ack stage, not unlike what I've accidentally done to
this thread).

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: unsigned char vs. signed char

[Ian Malone]

On 16 July 2014 10:28, Florian Weimer fwei...@redhat.com wrote:
 On 07/16/2014 11:00 AM, Jakub Jelinek wrote:

 On Wed, Jul 16, 2014 at 10:55:57AM +0200, Florian Weimer wrote:

 On 07/15/2014 07:22 PM, Adam Jackson wrote:

 On Tue, 2014-07-15 at 10:40 -0600, Orion Poplawski wrote:

 Did you know that char defaults to signed char on x86 but unsigned
 char
 on ppc and arm?  I didn't.


 Yep, found that out the hard way.  It annoyed me enough that I went
 digging in the gcc source to find the answer for all platforms:

 http://ajax.fedorapeople.org/is-char-signed-or-not.txt


 Any idea why aarch64 and ppc64le got this wrong?


 Why is char == unsigned char wrong?  Because i?86/x86_64 do it
 differently?


 Yes, it looks like a totally avoidable portability hazard.  iOS has signed
 chars as well, so even when considering current ARM, the natural choice is
 unclear.  Older ARMs couldn't perform sign-extending 8-bit loads in a single
 instruction, but that's true for historic x86, too, and yet even the old
 16-bit compilers used signed chars.

 History aside, I assumed that the idea behind both architectures (aarch64
 and ppc64le) is to use it to run current general-purpose server loads, and
 those are predominantly x86 right now.  That's why picking unsigned chars
 puzzles me.


Implementation defined in all iterations of the C standard. End of story really.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 23 June 2014 23:54, 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.


How much time would it take to write such a feature? (DNF is well
designed and easy to write for right? That's part of the justification
for doing it.)
How much time would it take for someone unfamiliar with the workings
of DNF to write a plugin and get it accepted by the DNF team?
How much time has been wasted arguing against it on this mailing list?

And lastly:
Why do you assume that making a mistake implies careless or can't be
bothered to read, rather than, for example, inexperienced, out of
depth following instructions or under pressure and very busy?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 24 June 2014 11:03, Reindl Harald h.rei...@thelounge.net wrote:


 Am 24.06.2014 11:40, schrieb Florian Weimer:
 On 06/24/2014 11:31 AM, Thomas Bendler wrote:
 Hopefully you don't write professional software with this kind of
 attitude.

 Please don't try to win arguments by labeling the opposition as
 incompetent.  You won't convince anyone, and it contributes to
 making the Fedora mailing lists a hostile place

 well, tell the same the guy he responded to having nothing better
 to do than calling people stupid which don't accept regressions
 and steps backwards here and on bugzilla

 hopefully some kernel update in the future won't work on his
 machine and the third update removes his only bootable one
 not for malicious joy but it turns out some people need to
 learn it the hard way

 that attitude would be acceptable if we would dicuss about new
 protections never existed before - but in fact we are talking
 about a proposed replacement of YUM which has these kind of
 things for years now and in that context it's just a rgeression


Comment 16 of the Bugzilla suggests that the running kernel is
retained during updates in DNF, as it is in Yum.
https://bugzilla.redhat.com/show_bug.cgi?id=1049310#c16

I don't know if that's correct and it doesn't invalidate any of the
arguments about general safety, but apparently update does do
something similar to the Yum behaviour (it inverts the meaning of the
related setting though).


-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 24 June 2014 12:51, Reindl Harald h.rei...@thelounge.net wrote:


 Am 24.06.2014 12:56, schrieb Ian Malone:
 On 24 June 2014 11:03, Reindl Harald h.rei...@thelounge.net wrote:


 Am 24.06.2014 11:40, schrieb Florian Weimer:
 On 06/24/2014 11:31 AM, Thomas Bendler wrote:
 Hopefully you don't write professional software with this kind of
 attitude.

 Please don't try to win arguments by labeling the opposition as
 incompetent.  You won't convince anyone, and it contributes to
 making the Fedora mailing lists a hostile place

 well, tell the same the guy he responded to having nothing better
 to do than calling people stupid which don't accept regressions
 and steps backwards here and on bugzilla

 hopefully some kernel update in the future won't work on his
 machine and the third update removes his only bootable one
 not for malicious joy but it turns out some people need to
 learn it the hard way

 that attitude would be acceptable if we would dicuss about new
 protections never existed before - but in fact we are talking
 about a proposed replacement of YUM which has these kind of
 things for years now and in that context it's just a rgeression

 Comment 16 of the Bugzilla suggests that the running kernel is
 retained during updates in DNF, as it is in Yum.
 https://bugzilla.redhat.com/show_bug.cgi?id=1049310#c16

 I don't know if that's correct and it doesn't invalidate any of the
 arguments about general safety, but apparently update does do
 something similar to the Yum behaviour (it inverts the meaning of the
 related setting though)

 don't get me wrong, but instead speculate you could try it out and
 see that it would get removed and until yesterday the DNF developers
 statet that they won't protect anything which leaded to my first
 is DNF ready to replace YUM thread at the begin of this year

 [root@rawhide ~]# dnf remove kernel
 Failed loading plugin: copr
 Dependencies resolved.


I meant to say I don't know for sure because I don't have a system
with DNF to try it on. However I said 'update' and not 'remove', which
I realise is the main point in this whole debate, but the 'running
kernel preserved against updates' argument is not about 'remove'.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

bugzilla use and bug 1049310

[Ian Malone]

Kevin Fenzi on bugzilla:
 Hey folks. There are 47 people cc'ed on this bug.

 Can we please be kind to them and refrain from discussion here unless you
 have some new information that hasn't already been noted in the last 35
 comments?

Quite a sensible comment. We got to this situation because the
maintainer requested bugzilla CCs as a kind of poll system. Is there a
better way to do this?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Replace Yum With DNF

[Ian Malone]

On 17 June 2014 19:11, David dgbo...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 6/17/2014 1:59 PM, Reindl Harald wrote:

 Am 17.06.2014 19:26, schrieb David:

 before you call others zealots you should ask yourself if you
 are just only a ordinary user with his single machine or have to
 manage *a lot* of machines, some of them even RHEL5/RHEL6 and want
 consistency if a break has no good reason except because we can
 break what we want



 You completely missed my point. The Fedora Devs have been working on
 this. The Fedora Devs want to do this. The Fedora Devs have said that
 they are going to do this. And when. Which means? You, and others, are
 going to have to deal with this.

Or leave. And the more perception there is that things are being done
for no other reason than The Fedora Devs want to do this, the more
people will want to go elsewhere.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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 Self Contained Change: The Shogun Machine Learning Toolbox

[Ian Malone]

On 30 April 2014 14:10, Jaroslav Reznik jrez...@redhat.com wrote:
 = Proposed Self Contained Change: The Shogun Machine Learning Toolbox =
 https://fedoraproject.org/wiki/Changes/shogun

 Change owner(s): Björn Esser besse...@fedoraproject.org

 SHOGUN is a large Scale Machine Learning Toolbox, being implemented in C++ and
 offering interfaces to C#, Java, Lua, Octave, Perl, Python, R and Ruby.


Nice. :)

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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

[Ian Malone]

On 16 April 2014 00:11, William Brown will...@firstyear.id.au wrote:
 On Tue, 2014-04-15 at 13:49 -0700, Matthias Clasen wrote:

 I don't think we want a 'firewall' UI anyway; the firewall is not
 something most users can or should understand and make decisions of.

 Never take decisions away from users.

 The OSX style firewall works well when enabled. It blocks all by
 default, then when an application wants a listening port, the user is
 prompted to allow or deny it. I think this is a good model.


Users can't understand a firewall, let's just turn it off (I realise
that's not your position, it's the one that seems to be coming up in
this thread.)
Anyone else astounded this discussion is actually taking place?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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 Self Contained Change: SDDM as the default KDE display manager instead of KDM

[Ian Malone]

On 14 April 2014 14:40, Jaroslav Reznik jrez...@redhat.com wrote:
 = Proposed Self Contained Change: SDDM as the default KDE display manager
 instead of KDM =
 https://fedoraproject.org/wiki/Changes/SDDMinsteadOfKDM

 Change owner(s): Martin Briza mbr...@redhat.com  KDE SIG

 Retire KDM as the default display manager of the KDE Fedora Spin in favor of
 SDDM.

 == Detailed Description ==
 As described in many articles and discussions, KDM is nearing its end of life
 and it's time we decided upon the successor.

 I'm proposing to switch to SDDM, which is a new project that suits our needs
 perfectly despite its immaturity:

 As of July 2013, KDM's maintenance consists of bugfixes for the most painful
 bugs, consisting of only about 20 actual commits to the repository in last two
 years (excluding translation, themes and merges), adding many new features
 would require major changes to a lot of the code and there is no active
 maintainer.

 SDDM is written in C++11/Qt5 (compared to the bits of XDM in KDM), compilable
 against Qt4, supports QtQuick theming and its upstream is quite active.

 Compared to the current DM, KDM, it currently lacks a few features (such as
 XDMCP) but adds some other ones (QtQuick themes) or is currently adding them
 (Keyboard layout switching in the greeter).

 == Scope ==
 * Proposal owners:
 ** Create sddm and sddm-kcm packages.
 ** Change kde-settings and the spin-kickstarts to provide SDDM package instead
 of KDM
 ** (eventually) exclude KDM from the kde-workspace package
 * 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)
 ___

Does scope need to include a specific plan to deal with this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1034414
since failure to login is worse than any bug in KDM?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Five Things in Fedora This Week (2014-04-08)

[Ian Malone]

On 8 April 2014 23:01, Corey Sheldon sheldon.co...@gmail.com wrote:
 I'm glad to supply a mirror site for initial seeding for such actions as
 needed (GMT-4 (US ES/DT)
 Also great mailing list but curious do you plan on creating a blog or
 podcast with such info for those not always near email client ..been
 forwarding to many friends not tied to pc or devel lists and have had
 inquiries

The email is a convenient repost of the blog:
 Reposted from
 http://fedoramagazine.org/five-things-in-fedora-this-week-2014-04-08/

Fedora this week:
http://fedoramagazine.org/category/general-news/fedora-this-week/

(FWIW, I generally detest podcasts. That's not an objection to them
being provided, but this is one person who is unlikely to listen to
them.)

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Five Things in Fedora This Week (2014-04-01)

[Ian Malone]

On 1 April 2014 21:11, Matthew Miller mat...@fedoraproject.org wrote:
 Reposted from
 http://fedoramagazine.org/five-things-in-fedora-this-week-2014-04-01/


 This is the third installment of this series, and I'm still calibrating
 a few things. I'm aiming at a wide audience, but I'm not quite sure how
 much explaining I should do of general Fedora knowledge. Is it helpful
 for me to (as above), give a quick explanation when I talk about
 Rawhide, Flock, or FESCo? Or, does that just increase the word count
 for no reason? Let me know.


Finding these pretty interesting, please keep them going. Think it's
useful to have a little context tagged onto things (like your
explanation of Flock) for anyone coming across it for the first time.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: lbzip2 as default bzip2 implementation

[Ian Malone]

On 2 April 2014 21:46, drago01 drag...@gmail.com wrote:
 On Wed, Apr 2, 2014 at 10:27 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
 ** possibly adjust spec files to require or build-require lbzip2 instead of
 bzip2.
 Is this necessary? Wouldn't it be better to have lbzip2 Provide bzip2
 or something so that updating all those packages is not necessary,
 and also that people who prefer normal bzip2 can still use it?

 Why would people prefer it? If it is the same but slower?

Yes, if it's interface compatible then it's pretty nice. Multithreaded
compression is handy from time to time. Pity about no library
interface (lbzip2 might be an unfortunate name choice...),
particularly for things like perl and python. I suppose from the pov
of minimal systems it might be nice to not have to have both if you
need to fulfil both a bzip2 library requirement and a bzip2
requirement, but that's a very particular case for a few kB saving.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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 Present and Future: a Fedora.next 2014 Update (Part II, What's Happening?)

[Ian Malone]

On 1 April 2014 02:50, David dgbo...@gmail.com wrote:
 On 3/31/2014 8:37 PM, Corey Sheldon wrote:
 Whatever if they can't learn the basics and the fundamental basis of
 Linux or the Patent issues and what have you then go somewhere else
 like to mac or windows..sometimes you need to work for things and
 teaching a man to fish is always better and personally while i think at
 first you may be right the community as a whole will have less of the
 why the #@#@@# can't I use this or that in the development forums and
 force the maintainers to make this more transparent and beyond that if
 you can't grasp that minor issue then why are you on a RPM-based IT
 linux distro much less Fedora in the blanking first place?



 So what you are saying is that you want people that Use Windows in some
 form or MacOS in some form that actually works as installed to switch to
 Linux in some form that *does not work without fudges and hacks*?  Good
 luck with that.


Or to put it another way, does it add any value to do work to provide
an extra RPM that doesn't provide what people expect it to in almost
all cases and will just trip people up?

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: default file system, was: Comparison to Workstation Technical Specification

[Ian Malone]

On 2 March 2014 14:56, Ric Wheeler rwhee...@redhat.com wrote:
 On 03/02/2014 01:17 PM, Ian Malone wrote:

 Can we get some definition of legacy here?  kernel/nfs-utils versions?
 

 I'd have to check what I can share. If it helps: not current RHEL or
 recent Fedora, until recently some that were over five years old. Also
 this comment in the XFS FAQ: Beware that some old programs might have
 problems reading 64bit inodes which seems to be related to stat vs
 stat64, there are some old programs that might require us to modify.


 Just to be clear, defaults are only important when you install. I don't
 think anyone is suggesting compiling out the ext4 code from the kernel so
 this should be of zero impact to someone running a file year old system who
 wants to upgrade to something modern.

 If you need to stay on that five year old system and not upgrade, I am not
 sure I understand why it would be a reasonable example.

 As other people have mentioned, there are ways to create an XFS instance
 that does not use 64 bit inodes (but that is *not* a sane default since the
 problems you refer to are not common with modern apps).


Yes, I maybe wasn't clear in my first email and the context has been a
bit lost in people following up details. My point was really that
there may be reasons for selecting a particular fs in a server
context[1] and that people setting up servers will often want to
change from the defaults. What seemed to be happening looked the wrong
way around: talk about the workstation defaults being the same as the
server ones, for not much more reason than the server decision was
taken first. It now looks like the consensus is it *could* be
different.

[1] Aside: it's an NFS server with some older clients, so upgrading
the server while retaining the clients would be a perfectly feasible
scenario, and actually ext4 seems to be working as well for us as XFS
did.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: default file system, was: Comparison to Workstation Technical Specification

[Ian Malone]

On 1 March 2014 21:37, Orion Poplawski or...@cora.nwra.com wrote:
 On 03/01/2014 02:30 PM, Ian Malone wrote:
 On 1 March 2014 18:57, Simo Sorce s...@redhat.com wrote:
 On Sat, 2014-03-01 at 12:04 +, Ian Malone wrote:
 On 28 February 2014 20:45, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote:

 As you say they are 'plain' filesystems. Though I now regret not
 sending my small datapoint in before the Server WG decision. That's
 that a while ago, after using XFS for a long time we started putting
 new filesystems onto ext4 and in the past month we moved probably our
 largest remaining dataset (1.1TB) from XFS to ext4, the main reason
 has been flexibility with resizing. Particularly the XFS 32bit inode
 ceiling, (inode64 not working well with NFS).

 As far as I know inode64 is not really a problem on NFS anymore, which
 is why I did not raise this as an issue at all (I use NFS and I have a
 6TB XFS filesystem with inode64).


 Unless you have legacy systems that must talk to it.

 Can we get some definition of legacy here?  kernel/nfs-utils versions?


I'd have to check what I can share. If it helps: not current RHEL or
recent Fedora, until recently some that were over five years old. Also
this comment in the XFS FAQ: Beware that some old programs might have
problems reading 64bit inodes which seems to be related to stat vs
stat64, there are some old programs that might require us to modify.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: default file system, was: Comparison to Workstation Technical Specification

[Ian Malone]

On 28 February 2014 20:45, Adam Williamson awill...@redhat.com wrote:
 On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote:
 On Feb 27, 2014, at 11:07 PM, James Wilson Harshaw IV jwhars...@gmail.com 
 wrote:

  I apologize, I guess I did not get the whole background out of it.
 
  What filesystems are we considering?

 It's XFS vs ext4 and Server WG has agreed on XFS on LVM.

 As a server WG member I voted +1 on XFS as I have no particular
 objection to XFS as a filesystem, but I do think it seems a bit
 sub-optimal for us to wind up with server and desktop having defaults
 that are very similar but slightly different, for no apparently great
 reason.

 ext4 and xfs are basically what I refer to as 'plain' filesystems (i.e.
 not all souped-up btrfs/zfs stuff), they're stable, mature, and
 generally good-enough for just about all cases. Is xfs really so much
 better for servers, and ext4 so much better for desktops, that it's
 worth the extra development/maintenance to allow Desktop to use ext4 and
 Server to use xfs?

 Basically, what I'm saying is that if Desktop would be OK with using
 xfs-on-LVM as default with all choices demoted to custom partitioning
 (no dropdown), as Server has currently agreed on, that'd be great. Or if
 we could otherwise achieve agreement on something.


As you say they are 'plain' filesystems. Though I now regret not
sending my small datapoint in before the Server WG decision. That's
that a while ago, after using XFS for a long time we started putting
new filesystems onto ext4 and in the past month we moved probably our
largest remaining dataset (1.1TB) from XFS to ext4, the main reason
has been flexibility with resizing. Particularly the XFS 32bit inode
ceiling, (inode64 not working well with NFS).
1TB doesn't sound very big. These are imaging datasets in a research
environment, files going from small text to images at tens of MB (some
bigger, but not the dominant type). Projects usually get their own FS
(for a variety of reasons including backup, audit and budgeting
reasons). And often it's not known how large a project will eventually
be, so filesystems get extended as appropriate. With XFS we have to
take care to avoid the 32bit inode ceiling, and most recently found a
filesystem that refused to take any more files for some other reason,
even after creating a new clean copy. We didn't get to the bottom of
that, and moved the data to ext4.
Which is not to say XFS is a bad decision, there's plenty of people
using it for other tasks, but I looked through the Server WG meeting
and couldn't see mention of the for/against arguments. If my ramble
above demonstrates anything it's not really about XFS, it's that
server admins have reasons for choosing an FS and the scope to look at
and change to alternatives. Default FS on the Server is not actually a
massive impact, LVM is a different decision and makes sense there.
LVM on a workstation though, well, you can make it the default, but a
couple of releases ago I started turning it off and will continue
doing so. It adds an extra level of complication to management which
doesn't gain you anything on a workstation.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: default file system, was: Comparison to Workstation Technical Specification

[Ian Malone]

On 1 March 2014 18:57, Simo Sorce s...@redhat.com wrote:
 On Sat, 2014-03-01 at 12:04 +, Ian Malone wrote:
 On 28 February 2014 20:45, Adam Williamson awill...@redhat.com wrote:
  On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote:

 As you say they are 'plain' filesystems. Though I now regret not
 sending my small datapoint in before the Server WG decision. That's
 that a while ago, after using XFS for a long time we started putting
 new filesystems onto ext4 and in the past month we moved probably our
 largest remaining dataset (1.1TB) from XFS to ext4, the main reason
 has been flexibility with resizing. Particularly the XFS 32bit inode
 ceiling, (inode64 not working well with NFS).
 1TB doesn't sound very big. These are imaging datasets in a research
 environment, files going from small text to images at tens of MB (some
 bigger, but not the dominant type). Projects usually get their own FS
 (for a variety of reasons including backup, audit and budgeting
 reasons). And often it's not known how large a project will eventually
 be, so filesystems get extended as appropriate. With XFS we have to
 take care to avoid the 32bit inode ceiling, and most recently found a
 filesystem that refused to take any more files for some other reason,
 even after creating a new clean copy. We didn't get to the bottom of
 that, and moved the data to ext4.

 As far as I know inode64 is not really a problem on NFS anymore, which
 is why I did not raise this as an issue at all (I use NFS and I have a
 6TB XFS filesystem with inode64).


Unless you have legacy systems that must talk to it. And the other
problem I mentioned, which we didn't solve, but didn't seem to be
inode64 (copy data onto a new fs of sufficient size and it should be
difficult to hit the 32bit limit). That machine is running an older
kernel, I'm not saying there's a particular problem with going with
XFS for server, what I should have said was it's probably the wrong
way round to have the server FS decision dictate the desktop one,
which seems to be what's going to happen.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: Heads up; F22 will require applications to ship appdata to be listed in software center

[Ian Malone]

On 17 February 2014 08:45, Christian Schaller cscha...@redhat.com wrote:



 Well with GCC we are assuming people will read docs and figure out the command
 line parameters needed to use gcc. So expecting people to read the docs on how
 to use yum or 'yum search' is not expecting to much in my opinion.

 That said we should list the Developer Assistant in the Software center (or 
 even have it installed by default)
 and that should be the tool IMHO to install these and other developer tools.

Really? I mean, it's one thing to say 'if you want to use command line
tools you have to use a command line package manager' (which isn't
really the case anyway), but is it actually the intention that non-GUI
components get split up into separate domains with their own GUI
managers. Just seems a little odd.


-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: advertisement in packaged software (e.g. Firefox)

[Ian Malone]

On 14 February 2014 06:08, Ralf Corsepius rc040...@freenet.de wrote:
 On 02/13/2014 07:50 PM, Nicolas Mailhot wrote:


 Le Jeu 13 février 2014 19:40, Rahul Sundaram a écrit :

 Hi


 On Thu, Feb 13, 2014 at 12:56 PM, Ralf Corsepius wrote:

 A party who is molesting me with ads and tries to spy on me, hardly is
 my
 friend.



 That certainly goes way too far.  We have assurance from Mozilla that
 there
 is no spying or tracking going on here


 How can they give any assurance? Unless the targets of those ads are
 hosted by mozilla, all it takes to track people is for one of the
 advertisers to read its server logs.

 Exactly.

 Beside this, IMO, the FLOSS community needs to set a non-misunderstandable
 sign that Ads are not welcome.


Even the Fedora home page has a hosting sponsor link (though Gnome and
FSF don't). I think there's quite a lot of premature overreaction
going on here. Provided it's been done in a secure manner this is
basically just providing a set of bookmarks, which will actually
disappear once you start browsing the web. Mozilla is not Shazam,
they're still controlled by a NPO, they've been pushing free software
and open standards for over a decade. If they can find a way to get
continued funding and less reliance on Google without compromising
their principles that's a good thing (hmm, an open source organisation
with one major commercial sponsor, sounds familiar).

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: advertisement in packaged software (e.g. Firefox)

[Ian Malone]

On 13 February 2014 18:50, Nicolas Mailhot nicolas.mail...@laposte.net wrote:

 Le Jeu 13 février 2014 19:40, Rahul Sundaram a écrit :
 Hi


 On Thu, Feb 13, 2014 at 12:56 PM, Ralf Corsepius wrote:

 A party who is molesting me with ads and tries to spy on me, hardly is
 my
 friend.


 That certainly goes way too far.  We have assurance from Mozilla that
 there
 is no spying or tracking going on here

 How can they give any assurance? Unless the targets of those ads are
 hosted by mozilla, all it takes to track people is for one of the
 advertisers to read its server logs. Surely one does not need an
 engineering degree to realise
 user processing in the browser + advertiser logs (of the ad picture or the
 ad link) = tracking by the advertiser of all people that match the
 processing rules


Fedora actually already packages software that would allow third
parties to track users, it's called yum and it makes requests to
mirrors who could determine what release and software you had
installed and rough geographical location. So context is important.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
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: advertisement in packaged software (e.g. Firefox)

[Ian Malone]

On 12 February 2014 14:44, Josh Boyer jwbo...@fedoraproject.org wrote:
 On Wed, Feb 12, 2014 at 9:39 AM, Matthew Miller
 mat...@fedoraproject.org wrote:
 On Wed, Feb 12, 2014 at 03:36:00PM +0100, Kai Engert wrote:
 Question (1)
 Are we allowed to ship software in Fedora that dynamically loads
 advertisements from the web and shows them to users?

 I think this might need to be broken down or clarified. Otherwise, any web
 browser is out.

 I think you need to also clarify what advertisements mean.
 Otherwise you'll get people playing wordsmith saying e.g. a
 software-installer tool is advertising some applications over others
 and is disallowed.

It wouldn't really be playing wordsmith, the application installer (or
whatever it's called) is talked about in terms of advertising
applications, it seems to be part of it's philosophy (though the word
'promote' has been more common). If it's just a case of Fedora wants
to control what advertising goes on in Fedora then that's not that
much different from Canonical or iTunes. If it's about third parties
tracking users I think that's a different and stronger argument about
privacy.

-- 
imalone
http://ibmalone.blogspot.co.uk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct