Pidgin 2.10.4
by Heiko Adams
Hi there,
can anyone start building pidgin 2.10.4, which is a security update
since the package maintainer seems to be unresponsive?
--
Grüße aus Coburg
Ulrike, Leon Jan und Heiko
11 years, 9 months
upcoming libdb/db4/compat-db reorganization
by Jindrich Novy
Hi all,
it seems to be the right time to do an unification/reorganization of
Oracle (Berkeley) DB packages in rawhide. The current situation is that
there are three of them:
compat-db - shipping old libdbs for compatibility (4.5,4.6 and 4.7)
db4 - shipping latest 4.x libdb series (4.8)
libdb - shipping latest libdb release (5.3)
What I'm planning to do is getting rid of db4 package. But before that
I want to clean-up compat-db for a bit.
After fiddling a bit with repoquery nothing seems to be dependent on
libdb-4.5 so if there are no objections I want to remove it.
There was only one package dependent on 4.6 (squidGuard) because it
had compilation problems with 4.7. This package is now built against
5.3 with no problem so 4.6 could go away from compat-db as well.
Only one package (pam_abl-0:0.2.3-8.fc12) was dependent on 4.7
in Fedora 17 but it's already rebuilt in rawhide so 4.7 can go away as
well.
So the plan is:
1) remove 4.5, 4.6 and 4.7 from compat-db
2) put 4.8 to compat-db
3) make db4 a dead package
(db4 package name is not very descriptive any more as we have
libdb-5.3 ...)
The reason I'm sending this to fedora-devel is that I'm unable to
reveal dlopen() or similar deps in packages so if your package
requires older libdb I plan to remove and can not be rebuilt against
newer libdb then please speak up!
Thanks,
Jindrich
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá,
kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl.
--- Jan Werich
11 years, 9 months
Couldn't we enable 256 colors by default on TERM?
by Kévin Raymond
Hi there,
We are building a leading edge Operating System, but still use only 8bit colors
by default in our terminal (I don't know about KDE… I stay under
GNOME, gnome-term (xterm)).
This limit the colors of many applications like vim, screen, tmux, weechat…
As seen (quick but not exhaustive check), all dependencies for xterm
in 256 colors are there,
we just need to define `TERM=xterm-256color' in order to get 256 colors…
So what would be needed?
--
Kévin Raymond
(shaiton)
GPG-Key: A5BCB3A2
11 years, 9 months
*countable infinities only
by Gregory Maxwell
>From Fedora 18 on, Fedora will no longer include the freedom to for a
user to create a fork or respin which is the technological equal of
the Project's output. Instead, this freedom will be available
exclusively from Microsoft for $99 under unspecified conditions.
I wish this were a joke.
http://mjg59.dreamwidth.org/12368.html
11 years, 10 months
Proposed F18 feature: MiniDebugInfo
by Alexander Larsson
I just wrote a new Feature proposal for shipping minimal debug info by
default:
https://fedoraproject.org/wiki/Features/MiniDebugInfo
The feature page lists some of the background and statistics. It also
lists some options in how to implement this, which all have various
different pros and cons. I'd like to hear what peoples opinions on these
are.
My personal opinion is that we should go with compressed data, in the
original files without the line number information. This means we use
minimal space (i.e. an installation increase by only 0.5%) while being
completely transparent to users. It does however make the normal
packages larger in a non-optional way which some people disagree with.
11 years, 10 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, 10 months
F16: Sandy Bridge -> lags, missing effects, ui-crashes
by Reindl Harald
Hi
i notice growing problems on F16 with "Intel Sandy Bridge" graphics
* desktop effects in KDE partly not working (3D cube as example)
this worked well over months after upgrade from F14 to F15 and
* sometimes the whole desktop hangs with display errors
like missing parts of windows solveable mostly by logout
but sometimes resulting in a complete system hang
* lags while starting applications or activate windows
of running apps
________________________________________
may it be that this is caused by major kernel updates
without update the graphics stack?
3.3.7-1.fc16.x86_64 2012-05-22 16:59:51
xorg-x11-drv-intel-2.17.0-8.fc16 2012-01-25 21:54:48
________________________________________
my hardware should normally not show any lags because
a Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz with 16 GB
RAM was a short time ago a real high-end machine
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics
Controller (rev 09)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4)
00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b4)
00:1c.7 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 8 (rev b4)
00:1d.0 USB Controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a4)
00:1f.0 ISA bridge: Intel Corporation Q67 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
02:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 03)
03:00.0 Network controller: Atheros Communications Inc. AR5008 Wireless Network Adapter (rev 01)
11 years, 10 months
another upgrade, another disaster
by Neal Becker
Basically the same kind of failure as the last several times I did updates.
This time f16->f17. Used preupgrade.
It seems to have all gone wrong when cpio failed, because a python package had
been installed using pip into the (default) system dirs. The conflict IIRC
happens because pip installs a dir where cpio expects a file (or vice-versa).
I've since learned to use pip install --user instead - but there was still a
leftover package.
I was happy (temporarily) to see that I could still reboot the machine. Remove
the offending package.
Then IIRC I restarted the upgrade. It seemed to complete OK. I was pleased to
see it appear to continue from where it left off.
On reboot, I found a huge mess. Duplicate packages (f16/f17) all over.
So,
1) Could I have actually recovered from this mess without a complete re-install?
2) Can't we make the install fail more gracefully?
3) Would it be possible to continue an failed install, and have it actually
work?
11 years, 10 months
