Self introduction
by Patrick マルタインアンドレアス Uiterwijk
Hello,
I would like to introduce myself as a hopefully new packager for Fedora.
My current residence is in the Netherlands, where I'm studying for my
Bachelors degree for Computer Science at the Radboud University
Nijmegen.
I have been running Red Hat Linux since version 9, and am now running Fedora 17.
Currently, I am packaging the compiler for the Clean programming
language, which is designed and implemented by the Radboud University,
for which my package review request has been submitted
(https://bugzilla.redhat.com/show_bug.cgi?id=834069), and I plan on
building and packaging more libraries for Clean.
My GPG Key ID is 9AB51E50.
With kind regards,
Patrick Uiterwijk
11 years, 11 months
.so's in devel packages...
by Nelson Marques
Hi all,
I have a doubt regarding the '.so's' in devel packages... From my
understanding they go in devel packages to allow the installation of
several packages with different versioning....
Who defined this? Is this part of some standards (ex: LSB, etc) ?
Is there some written documentation about this ?
NM
11 years, 11 months
Retiring akonadi-googledata
by Mario Santagiuliana
Hi to all,
I am going to retire akonadi-googledata. An old akonadi resource for Google
contacts and calendars. Like explain in this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=833041
I suggest to all users who are using akonadi-googledata to switch to new
resources akonadi-google (that new version will be included in kdepim-
runtime).
Thank a lot to Rex Dieter for his work!
--
Mario Santagiuliana
www.marionline.it
11 years, 11 months
*countable infinities only
by Gregory Maxwell
[I'm sorry for getting repetitive here, but I'm responding to several
people concurrently in order to minimize volume]
On Thu, May 31, 2012 at 10:32 AM, Bryn M. Reeves <bmr(a)redhat.com> wrote:
> That discussion is happening right now. You're welcome to join in.
That wasn't my understanding, my understanding is that this is a done
deal and not up for discussion. I'm happy to learn otherwise.
> It's rather disingenuous to suggest that this is a situation of
> Fedora's making. This is coming whether we or other distributions like
> it or not as a consequence of the Windows 8 logo program.
I did not say that this situation was "fedora's making", I know — for example—
That MJG cares deeply about software freedom and that he understands
the loss of freedom here. I know that everyone involved in this feels that
it is being exposed from outside and that there is no other viable choice.
(And I grant that there is at least a choice of bad compromises being
enforced from outside).
This does not change the fact that a freedom of fedora is being lost.
And Fedora does have a choice here.
> If you think you have a better scheme then please describe it.
I know that the people who have been working on this for months and in
direct negation with Microsoft have already explored more options than
I can hope to guess at. I won't be able to outdo a bunch of really
smart people working, with the cooperation of lawyers, for months in
an email here (and I already attempted this in private with MJG, and
failed as expected).
I offer instead that Fedora should not participate and leave it so
that Fedora and forks will both have equal inconvenience on this
hardware. This will preserve the freedom I'm speaking of losing here,
and it will keep Redhat and the Fedora community laser focused on
minimizing this inconvenience.
[and I didn't spell this out before simply because it's an obvious
option that you don't need my help to find]
The plan presented here will instead potentially leave RedHat and the
Fedora community in the odd position of defending TC lockdown as
compatible with the GPLv2 "installation instructions", v3 anti-TC, and
future licenses which may be _specifically_ targeted to address the
loss of freedom created here — I'm not trying to argue that the
licensing here myself, only pointing out that the fact that you'll
now be in the business of arguing against prohibitions in free
software licenses is a very clear sign that something is wrong, and a
very bad investment in resources.
The overall situation here is not Fedora's making— not something you
would choose to have. But there absolutely is a choice available
here. Fedora can choose to continue to participate in the ecosystem
as an equal— without access to special signing keys which they can't
give to their users would may wish to make forks—, or Fedora can
choose to make the install easier on this hardware.
And it's not to say that I'm 100% doom and gloom about this, the
increase in friction for loading binary only drivers will be a very
positive upside.
> Perhaps to give the users who want to have Fedora cohabit with another
> OS that uses trusted boot the freedom do do so without turning it off?
And again— Forks and Respins of Fedora lose the ability to provide
parity in this regard.
I apologize that I'm presenting you with an impossible argument: You
argue that it's important to do this, I argue that the loss of freedom
is great— you argue that the hurdles for forks/respins are small, I
argue that you should not do this. But it isn't me who created this
dissonance. It's the people arguing that this is not a clear loss of
a prior freedom in Fedora.
Once you accept that this option is a loss of freedom then the
argument is no longer cyclic and we can have a meaningful discussion
about if the loss of freedom is better or worse than the loss of
capability.
> Starting a new thread that deliberately omits important aspects (such
> as the user's ability to toss out and replace vendor keys or disable
> the whole mess) is pretty close to my definition of fear, uncertainty
> and doubt.
That isn't a relevant aspect for someone who would want to fork the
software for other people to use. The relevant part is that if you
fork fedora you will either have to pay $99 (and pass whatever
certification Microsoft imposes) or you will be harder to install. If
you think that my focus on this point to the exclusion of all the ways
that this doesn't suck— ways which would likely be unlawful— is going
to confuse people, then perhaps you should communicate about this
better so that I'm unable to confuse people.
On Thu, May 31, 2012 at 10:34 AM, Peter Jones <pjones(a)redhat.com> wrote:
> You keep using "technological equals" when you clearly mean "market equals".
> The technology is all there. The market is what's more difficult to gain
> access to. I'm not happy about that at all, but it's still a worthwhile
> distinction.
Access to cryptographic signing keys is a technological restriction.
Requiring the user to go bios spelunking or key generating at install
time is similar in character to other technological shortcomings,
e.g., only being able to use a text mode installer— or the
distribution of a binary only driver which is required to work on some
hardware— something Fedora has previously chosen not to do even while
some other distributions did so.
I agree that it's not quite a issue of "technological equals": If it
were just technology I could independently reinvent the bootloader
without paying people, but I won't here— and if I manage to backdoor
the trusted boot through some technical means I would probably be
breaking the law.
Market equality is something that free software has never promised,
and could not promise. It couldn't be taken away because it could
never have been provided.
On Thu, May 31, 2012 at 11:10 AM, Pierre-Yves Chibon
<pingou(a)pingoured.fr> wrote:
> I don't really think this is Fedora specific, all linux distro will face
> the same problem.
Fedora has made the freedom provided more central to it's marking and
values than other mainstream distributions.
"Why Is the Fedora Project Different? We try to always do the right
thing, and provide only free and open source software. We will fight
to protect and promote solutions that anyone can use and redistribute.
To this end, we use only free and open source software to power the
Fedora infrastructure itself."
Other distributions have distributed (and/or provided easy
install-time options to download) binary only drivers for the sake of
hardware compatibility. Other distributions offer and promote things
like flash, encumbered codecs, etc. All for the sake of improved user
experience but at the cost of a strong position on software freedom.
Not only does Fedora not provide these things, but it doesn't
generally promote them or even facilitate them.
Personally, I've viewed Fedora as a source of pragmatic compromises to
hard software freedom issues, but still a distro which isn't afraid to
put freedom first even if it creates inconvenience or some loss of
market share, and this is one reason why I use it. I don't believe
that there is any other major distribution which would be more likely
to take the other option here— the hard option of reduced
compatibility for the sake of equality in licensing.
... and it's really only the mainstream distributions which have the
market clout to make a refusal to participate here mean anything at
all— in terms of the public's perception of these limitations, and in
terms of the workaround and remedies.
On Thu, May 31, 2012 at 10:52 AM, Chris Adams <cmadams(a)hiwaay.net> wrote:
> The basic fact is that Microsoft drives the desktop x86 PC market.
> Nobody else has the power they do, and that isn't going to change any
> time soon. They are creating the two classes you describe. The
> hardware is coming (like it or not), and Fedora can either change to
> deal with it or not.
>
> If Fedora does nothing different than is being done today with F17, it
> will always be in the second class, requiring the user to disable secure
> boot. Even getting to the point where the user can generate/install
> their own key requires more work.
Microsoft is creating the situation but Fedora can choose between two
bad options:
(1) Have two classes, where not all Fedora distributors are equals.
(2) Have harder installs on some hardware.
I think the second option is better and more in line with the Fedora
project's mission. The second option is also terrible, but it means
that Fedora's resources will be invested in minimizing the costs, and
not invested in fighting against free software developers who would
like to use licensing restrictions to prohibit code signing lockdown
of their software.
11 years, 11 months
Escalation - better desktop printing policy (over two years old issue)
by Valent Turkovic
Hi,
Fedora still has quite strict printing policies even if users choose
to be a part of Administrator group during installation still need to
input passwords while changing even the minor printer settings (like
unpausing). This is still an issue on Fedora 16 and 17, is has been in
bugzilla for over 2 years:
https://bugzilla.redhat.com/show_bug.cgi?id=596711
Why are Administrator users being asked for root pasword when editing
printer options? There is a fix from Fedora wiki page:
http://fedoraproject.org/wiki/Printing/ConfigurationTool
Please make this fix permanent and enabled by default in Fedora.
If I'm not mistaken this is the same issue that Linus Torvalds vented
regarding same issue on OpenSuse -
https://plus.google.com/102150693225130002912/posts/1vyfmNCYpi5
Thanks,
Valent.
--
follow me - www.twitter.com/valentt & http://kernelreloaded.blog385.com
linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave
ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turkovic(a)hotmail.com
11 years, 11 months
KDE-SIG meeting report (25/2012)
by Jaroslav Reznik
This is a report of the weekly KDE-SIG-Meeting with a summary of the
topics that were discussed. If you want to add a comment please reply
to this email or add it to the related meeting page.
= Weekly KDE Summary =
Week: 25/2012
Time: 2012-06-19 15:00 UTC
Meeting page: https://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-06-19
Meeting minutes: http://bit.ly/LBr9BF
Meeting log: http://bit.ly/LBRmTH
------------------------------------------------------------------------
= Participants =
* jreznik
* rdieter
* rnovacek
* Kevin_Kofler
* than
* ltinkl
------------------------------------------------------------------------
= Agenda =
* topics to discuss:
** status updates
** a new features that hits KDE Plasma Workspaces spin
*** Initial Experience
*** Offline Updates
*** Mini debug infos
= Summary =
Status updates
* kdemm split mostly done, missing kscd and ffmpegthumbs (rpmfusino) (jreznik, 15:15:10)
* ACTION: jreznik to finish kscd review (jreznik, 15:15:44)
* dantti, rhughes and ltinkl fixed some of the battery applet/upower bugs yesterday (jreznik, 15:16:03)
* a couple of new ktp packages to be reviewed (jreznik, 15:16:26)
a new features approved by FESCo that hits KDE spin
* there are several new features approved by FESCo that could affect KDE spin (jreznik, 15:22:51)
* AGREED: to try to make 800 MiB goal possible (jreznik, 15:45:30)
* ACTION: jreznik to create feature page asap and mention our size intentions there (jreznik, 15:49:42)
* ACTION: rdieter to help maintain cd-sized (700mb) kde spin (rdieter, 15:50:17)
* defer offline updates until Apper supports them (dantti will implement it) (jreznik, 15:54:28)
* ACTION: jreznik to contact KDE upstream about IE (jreznik, 15:58:21)
= Next Meeting =
http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2012-06-26
--
Jaroslav Řezník <jreznik(a)redhat.com>
Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc. http://cz.redhat.com/
11 years, 11 months
Weekly ARM status meeting - Wed 2012/06/20
by Paul Whalen
Good day all,
This weeks Fedora ARM status meeting will take place today (Wednesday June 20th) in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):
PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 8pm
BST: 9pm
CST: 10pm
Current items on the agenda:
1) Cleaning up the wiki - moving dated items to an archive section.
- refreshing where needed
2) On to F18 - How do we be more like PA?
- Anaconda, livemedia-creator
- linker path
3) F18 build status - problem packages
4) Your topic here
If you have any other items you would like to discuss that are not mentioned, please feel free to send an email to the list or bring it up at the end of the meeting.
Paul
11 years, 11 months
