Steve Grubb wrote:
On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote:
which I interpret to mean that after using -fstack-protector-all and
removing prelink, SELinux would become obsolete because no executable
can be exploited.
I would say there is a place for SE Linux even if we
Jerry James wrote:
I've got two Rawhide VMs, one x86_64, one i686, both otherwise
identical. I last booted them yesterday and did a yum repo-sync.
Today, neither of them will boot.
First, systemd complained about being unable to find
systemd-journal-flush.service. Sure enough, it wasn't in
If you run make distcheck (the rule generated by automake),
be sure that it is safe. Until a few days ago, running that
rule in a directory readable by others would put you at risk
from a local attacker. It can be exploited reliably.
It's fixed in the latest, automake-12.2
Even in mature projects full of nit-picky reviewers, it seems there
are always a few misspelled words in comments, documentation, etc.
Here's a recipe for correcting those. Hook this up as a
make check dependent rule to prevent recurrence.
First, get this http://github.com/lyda/misspell-check
I posted about MALLOC_PERTURB_ about a year ago,
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/132690
but it is clear that not everyone is setting the variable, so for those
who didn't take the time last year, or who are new to the subject,
do yourself a favor and set
John Reiser wrote:
# http://udrepper.livejournal.com/11429.html
export MALLOC_PERTURB_=$(($RANDOM % 255 + 1))
For supportability (and to help remind you to turn it off before
performance tests), then also consider adding a line such as:
echo 12 MALLOC_PERTURB_=$MALLOC_PERTURB_
Kaleb Keithley wrote:
About a week ago I did a scratch build of one of my packages that
includes sys/sysctl.h and it built successfully.
Today I did another scratch build and it broke with:
...
Making all in src
CC fuse-helpers.lo
CC fuse-resolve.lo
CC fuse-bridge.lo
Michal Schmidt wrote:
On 05/14/2012 10:11 AM, Jim Meyering wrote:
Miloslav Trmač wrote:
I'm pretty sure that naming conflicts in /usr/bin have happened before
in Fedora, I'm not sure how they were resolved.
Even in a relatively minimal system, I see many programs installed
in both /sbin
Miloslav Trmač wrote:
On Fri, May 11, 2012 at 10:14 AM, Jim Meyering j...@meyering.net wrote:
Miloslav Trmač wrote:
On Thu, May 10, 2012 at 9:49 PM, Greg McGary greg.mcg...@gmail.com wrote:
Minor conflict: the name of one of id-utils main commands lid is also the
same as an existing command
Josh Boyer wrote:
On Mon, May 7, 2012 at 8:43 AM, Jim Meyering j...@meyering.net wrote:
Today I noticed that some tests from coreutils' test suite
were taking far longer than they used to on rawhide.
For example, run this command in an empty directory:
seq 20|env time xargs touch
Miloslav Trmač wrote:
On Thu, May 10, 2012 at 9:49 PM, Greg McGary greg.mcg...@gmail.com wrote:
Minor conflict: the name of one of id-utils main commands lid is also the
same as an existing command, though installed in a different place. id-utils
has /usr/bin/lid, while libuser has
Pádraig Brady wrote:
On 05/11/2012 09:14 AM, Jim Meyering wrote:
Miloslav Trmač wrote:
On Thu, May 10, 2012 at 9:49 PM, Greg McGary greg.mcg...@gmail.com wrote:
Minor conflict: the name of one of id-utils main commands lid is also the
same as an existing command, though installed
Today I noticed that some tests from coreutils' test suite
were taking far longer than they used to on rawhide.
For example, run this command in an empty directory:
seq 20|env time xargs touch
it takes 5s on F17 3.3.4-1.fc17.x86_64 ext4/sdb8/SSD, yet
it takes 47s on rawhide
Josh Boyer wrote:
On Mon, May 7, 2012 at 8:43 AM, Jim Meyering j...@meyering.net wrote:
Today I noticed that some tests from coreutils' test suite
were taking far longer than they used to on rawhide.
For example, run this command in an empty directory:
seq 20|env time xargs touch
I built another x86_64 rawhide VM yesterday and was surprised
to find that its gcc was unusable:
$ printf 'int main(){return 0;}' k.c; gcc k.c
/usr/bin/ld: skipping incompatible
/usr/lib/gcc/x86_64-redhat-linux/4.7.0/../../../libc.so when searching for -lc
/usr/bin/ld: skipping
Mark Wielaard wrote:
On Mon, Apr 09, 2012 at 10:58:43AM -0400, Daniel J Walsh wrote:
I thought I made this clear in my blogs and the feature page that I wanted
this on deny_ptrace on by default.
[...]
We did have a bug in Alpha where it was turned off. Now that people are
actually seeing it
I installed x86_64 F17 from the netinst.iso yesterday, selected
a minimal install, and immediately upgraded to rawhide.
Worked like a charm.
However, now that I try to use the resulting system and need a
few packages, I find that installing them is um, ... challenging.
For example, yesterday I
Colin Walters wrote:
On Thu, 2012-04-05 at 14:40 +0200, Jim Meyering wrote:
I installed x86_64 F17 from the netinst.iso yesterday, selected
a minimal install, and immediately upgraded to rawhide.
Worked like a charm.
However, now that I try to use the resulting system and need a
few
James Antill wrote:
On Thu, 2012-04-05 at 14:40 +0200, Jim Meyering wrote:
I installed x86_64 F17 from the netinst.iso yesterday, selected
a minimal install, and immediately upgraded to rawhide.
Worked like a charm.
[...]
Packages skipped because of dependency problems:
gcc-c
Daniel J Walsh wrote:
...
I have been running with a tmpfs /tmp for years, without a problem. I have
found the having /tmp be anything else that a tmpfs has caused me pain over
the years with mislabeled files or files with the wrong UID.
Change to use a confined user or change the UID of a
Jochen Schmitt wrote:
Hallo,
I have some issues to build aplus-fsf via mock for the master branch.
Because I don't have any idea to selve the existing issues, I have uploaded
the build.log, the SPEC file and a patch to
http://www.herr-schmitt.de/pub/aplus-fsf/
It will be nice, if anyone
Richard W.M. Jones wrote:
On Tue, Mar 13, 2012 at 10:00:59AM +0100, Jan Kratochvil wrote:
On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
I suspect the answer is 'no', but is is possible to access or download
the build directory of a failed build, on the Fedora Koji servers?
Jim Meyering wrote:
Richard W.M. Jones wrote:
On Tue, Mar 13, 2012 at 10:00:59AM +0100, Jan Kratochvil wrote:
On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
I suspect the answer is 'no', but is is possible to access or download
the build directory of a failed build
Jan Kratochvil wrote:
On Fri, 16 Mar 2012 11:16:51 +0100, Jim Meyering wrote:
That works very well. However, the base64 output in my first log was
corrupt, due to some asynchronous output (stderr about job completion)
that was emitted in the middle of the big base64 block.
Adding the sync
FYI, I released parted-3.1 yesterday,
http://thread.gmane.org/gmane.comp.gnu.parted.bugs/10790
In addition to pretty many bug fixes,
This is to announce parted-3.1, a bug fix release that also reintroduces
a minimal subset of the file system resizing capability that was removed
Kévin Raymond wrote:
I've managed to get the whole list of transifex.net projects who appears
dead, here they are:
...
[D] iwhd
I deliberately switched iwhd from transifex to http://translationproject.org
because the latter provides anonymous rsync access, while transifex requires
that one
Matthew Garrett wrote:
On Wed, Feb 15, 2012 at 07:23:24PM -0500, Steve Clark wrote:
On 02/15/2012 05:19 PM, mike cloaked wrote:
I use bash completion all the time every single day - I guess I have
become a corner case!
No you haven't. All the developers I have worked with since the
early
Reindl Harald wrote:
Am 15.02.2012 13:43, schrieb Martin Langhoff:
On Feb 15, 2012 6:16 AM, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@thelounge.net wrote:
there is no single reason for a feature like /usrmove which
in fact nobody NEEDS at all and definitly not now to press
it into
Simo Sorce wrote:
On Thu, 2012-02-16 at 13:22 +0100, Jim Meyering wrote:
...
Prior to F17, I've always put /usr on a partition separate from /.
$ df -hT / /usr
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda4 ext4 11G 7.3G 3.2G 70% /
/dev/sda6
Matthew Garrett wrote:
There's various issues with the hfsplus utilities we ship at the moment,
including the fact that fsck.hfsplus crashes on 64-bit. I'd like to
Glad you're looking at this. I noticed that recently, too.
I wanted to use fsck.hfsplus in a test to verify that parted's
Matthew Garrett wrote:
On Fri, Feb 03, 2012 at 02:56:51PM +0100, Jim Meyering wrote:
Can you point me to the latest upstream sources?
git://cavan.codon.org.uk/hfsplus-tools.git - it needs clang to build.
Thanks.
I built it, and when using that version of fsck.hfs,
my new parted test passes
Chris Murphy wrote:
On Feb 3, 2012, at 6:56 AM, Jim Meyering wrote:
Matthew Garrett wrote:
There's various issues with the hfsplus utilities we ship at the moment,
including the fact that fsck.hfsplus crashes on 64-bit. I'd like to
Glad you're looking at this. I noticed that recently, too
Daniel J Walsh wrote:
On 01/31/2012 12:07 PM, Jerry James wrote:
After installing today's Rawhide updates on an x86_64 VM, I
started having troubles running programs. Nothing linked with
libselinux.so.1 could actually open that library; the programs were
getting EACCESS on the attempt. I
Just a heads up.
I usually update a rawhide VM daily and reboot at least once or twice
a week. Today space was getting a little low on the parent partition,
so I stopped the VM in order to run virt-sparsify on its image.
Nice: that saved 3GB. Booting again, however, there were numerous
Daniel J Walsh wrote:
On 01/13/2012 11:42 AM, Daniel J Walsh wrote:
On 01/13/2012 06:59 AM, Frank Murphy wrote:
On 13/01/12 11:46, Jim Meyering wrote:
Just a heads up.
Ran into it yesterday:
https://lists.fedoraproject.org/pipermail/test/2012-January/105084.html
Thought it was systemd
Daniel J Walsh wrote:
On 01/13/2012 01:17 PM, Jim Meyering wrote:
Daniel J Walsh wrote:
On 01/13/2012 11:42 AM, Daniel J Walsh wrote:
On 01/13/2012 06:59 AM, Frank Murphy wrote:
On 13/01/12 11:46, Jim Meyering wrote:
Just a heads up.
Ran into it yesterday:
https://lists.fedoraproject.org
Jakub Jelinek wrote:
On Mon, Jan 02, 2012 at 07:03:44PM +0100, Jim Meyering wrote:
I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
(built manually: 4.7.0 20111202), and it worked fine, so I'm not quite
sure why iwhd is on the list. Maybe the gcc-4.7.x that Jakub used
Denis Arnaud wrote:
Hi Jim,
2012/1/3 devel-requ...@lists.fedoraproject.org
Is there some sort of reminder service that could be configured to nag the
maintainers of a package in a situation like this? Personally, I would
appreciate it, and I think Fedora would benefit if we
Nils Philippsen wrote:
...
I've attached a list of packages and (co)maintainers, to easily find if
one of your packages is affected or not.
...
iwhd: meyering - clalance,zaitcev
Thank you for the list.
I have just tried to build iwhd on F16 using a pretty recent gcc-4.7.x
(built manually:
Richard W.M. Jones wrote:
On Thu, Nov 24, 2011 at 03:01:03PM +, Paul Howarth wrote:
http://marc.info/?l=pptpclient-develm=132102054518031
This is indeed rather unexpected behaviour of make!
BTW I think your patch is incomplete, since it will create an
incomplete config.h if the disk
Kaleb S. KEITHLEY wrote:
...
Perhaps there's some extra fedpkg flag I should be using for epel builds?
Perhaps try without parallel make?
Yes, that makes it work.
Thanks for the tip.
When running make from the command line, I always use -j$N, for 1 N.
But of course, I rarely type the -j
Rahul Sundaram wrote:
On 11/08/2011 10:18 PM, Gerd Hoffmann wrote:
Hi,
Fedora 16 is not science fiction. It is here right now:
http://get.fedoraproject.org
Hmm, no jigdo downloads any more?
Yes. Would be nice to have this back. It is not a big burden. Is it?
I have used them, too.
So far I've only noticed it via a test, but everyone uses *printf,
and malloc is implicated due to recent arena-related changes:
malloc deadlock makes *printf hang
http://bugzilla.redhat.com/753601
With glibc-2.14.90-15.2.x86_64 (f16-testing and rawhide), this hangs:
( ulimit -v
Richard Shaw wrote:
On Wed, Nov 9, 2011 at 11:18 AM, Tom Lane t...@redhat.com wrote:
postgresql is currently failing to rebuild in rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3499379
This seems quite repeatable, in koji, but the package builds fine on my
workstation under
Adam Williamson wrote:
... The only breakage
in one which was approved was to do with compiling things - which, sure,
is a pain in the ass, but it's not the kind of problem critpath was
introduced to deal with in the first place.
The problem is bigger than it first seemed, and still not
Jim Meyering wrote:
Adam Williamson wrote:
... The only breakage
in one which was approved was to do with compiling things - which, sure,
is a pain in the ass, but it's not the kind of problem critpath was
introduced to deal with in the first place.
The problem is bigger than it first
I spent too many hours debugging this today, so feel obliged to warn
about this. Plus, I feel a little guilty for giving it positive
karma initially. Today's -1 was too late.
glibc-2.14.90-12.999, which has just made it to stable provokes a
hard-to-diagnose (for me at least) problem.
While
Simo Sorce wrote:
On Wed, 2011-10-19 at 20:51 +0200, Jim Meyering wrote:
...
To recover an F16 system that works better, I ran this:
yum downgrade glibc glibc-static glibc-devel glibc-common glibc-headers \
glibc-utils nscd
What did you downgrade to ?
AFAIK Several people had
darrell pfeifer wrote:
Fails for me too, with the same error.
Thanks for confirming that.
I don't mean to be rude or inflammatory, but do have to wonder how such
a fundamentally-broken package was released -- even to rawhide. In the
fedora openssh release process, isn't there some sort of
Frank Murphy wrote:
On 11/09/11 09:33, Jim Meyering wrote:
darrell pfeifer wrote:
Fails for me too, with the same error.
Thanks for confirming that.
I don't mean to be rude or inflammatory, but do have to wonder how such
a fundamentally-broken package was released -- even to rawhide
Rahul Sundaram wrote:
On 09/11/2011 02:13 PM, Frank Murphy wrote:
Is not rawhide the sanity check, even if used productively by many?
Not many and I think the branch being less fragile would certainly
help. If I know my system will still boot and I can access the network
and my browser is
I cannot ssh to my rawhide VM today:
$ date; ssh r; date
Sat 2011-09-10 19:55:35 +0200
Write failed: Broken pipe
Sat 2011-09-10 19:57:35 +0200
Note the two-minute delay.
I was unable to interrupt it, nor suspend. Very annoying.
Using the console, I see nothing in
Thomas Moschny wrote:
having a rm command accidentally removing 3/4 of my system yesterday,
I am starting to wonder whether it is possible to have rm reliably
stop at bind mounts. I know there is a --one-file-system option, but
it is not working when the bind mount points to the same device:
Kevin Fenzi wrote:
See:
https://bugzilla.redhat.com/show_bug.cgi?id=735970
Seems to just be broken in the 5.9 series. ;(
Thanks. I've marked mine as a duplicate of that one.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I was getting ready to release coreutils-8.13, after two pre-release snapshots,
http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1554
http://thread.gmane.org/gmane.comp.gnu.coreutils.general/1631
when I went to make sure its tests all pass also on rawhide.
I test that regularly,
Jim Meyering wrote:
...
$ touch a $ env -i /usr/bin/install a b
zsh: segmentation fault env -i /usr/bin/install a b
[Exit 139 (SEGV)]
Rich Jones found that updating to libselinux-2.1.5-2.fc17.x86_64
made it so he too sees the above failure.
http://bugzilla.redhat.com/736259
Richard W.M. Jones wrote:
On Wed, Sep 07, 2011 at 01:44:36PM +0200, Jim Meyering wrote:
Jim Meyering wrote:
...
$ touch a $ env -i /usr/bin/install a b
zsh: segmentation fault env -i /usr/bin/install a b
[Exit 139 (SEGV)]
Rich Jones found that updating to libselinux-2.1.5
Daniel J Walsh wrote:
...
Grab libselinux-2.1.5-3.fc17 out of koji, should fix the problem.
Thanks. That solved it for me.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Jan Kratochvil wrote:
On Tue, 09 Aug 2011 19:45:15 +0200, Matthew Garrett wrote:
If a package fails to build in a mass rebuild because -Werror was enabled
then that's additional work for several people to fix something that may not
have ever actually been broken.
99% of warnings will not
Ralf Corsepius wrote:
On 08/13/2011 10:51 AM, Jim Meyering wrote:
Whether to invest in enabling -Werror for all packages in a mass rebuild
however is another question.
Pardon, but this is not a question, this is beyond reason and foolish.
There will be many build failures, and
some
FYI, I've just yum-updated my rawhide VM to the latest
(but not from the console) and was surprised to lose the connection
while it was happening. Again. It happened to me last week, too.
I got back in via the console and tried to reinstall it via yum
reinstall openssh-server. That failed
Clyde E. Kunkel wrote:
On 07/26/2011 12:22 PM, Jim Meyering wrote:
snip
service ssh restart
Would that be:
service sshd restart
Yes, thanks.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Richard W.M. Jones wrote:
Anyone seeing this error? Unless I boot with enforcing=0, I see
this error when I try to log in as any user:
Unable to get valid context for username
It seems like it's just started happening, since I upgraded something
within the last 1-2 weeks.
Hi Rich,
I'm
Richard W.M. Jones wrote:
On Wed, Jun 08, 2011 at 09:19:43PM -0500, Bruno Wolff III wrote:
On Wed, Jun 08, 2011 at 17:01:07 -0600,
Jerry James loganje...@gmail.com wrote:
On Wed, Jun 8, 2011 at 4:58 PM, Tom London seli...@gmail.com wrote:
See
Just a quick FYI:
If you haven't already gotten Fedora 15's latest glibc-headers package,
you may want to wait for 2.13.90-11. Here's why:
glibc-headers-2.13.90-10.x86_64 no longer includes any of
the /usr/include/rpc/*.h files.
Contrast with glibc-headers-2.13.90-9.x86_64, where there are 18:
Harald Hoyer wrote:
Am 08.04.2011 12:38, schrieb Jim Meyering:
So maybe there *is* a bug to report after all:
With TMPDIR pointing to a directory with context not like /tmp,
the kernel's initramfs-building code fails and gives a diagnostic
(calling it Non-fatal), but lets
Jim Meyering wrote:
Daniel J Walsh wrote:
On 04/07/2011 07:46 AM, Jim Meyering wrote:
I updated my rawhide VM today (on F15 host), but it failed to reboot
using the new kernel, vmlinuz-2.6.39-0.rc1.git5.0.fc16.x86_64
I got a failure (VFS diagnostic complaining that the UUID-specified
root
I updated my rawhide VM today (on F15 host), but it failed to reboot
using the new kernel, vmlinuz-2.6.39-0.rc1.git5.0.fc16.x86_64
I got a failure (VFS diagnostic complaining that the UUID-specified
root partition was not available), then panic.
Two subsequent attempts to reboot failed because
Daniel J Walsh wrote:
On 04/07/2011 07:46 AM, Jim Meyering wrote:
I updated my rawhide VM today (on F15 host), but it failed to reboot
using the new kernel, vmlinuz-2.6.39-0.rc1.git5.0.fc16.x86_64
I got a failure (VFS diagnostic complaining that the UUID-specified
root partition
Richard W.M. Jones wrote:
Compiling libguestfs using gcc-4.6.0-0.11.fc15.x86_64 gives lots of:
error: assuming signed overflow does not occur when changing X +- C1 cmp C2
to X cmp C1 +- C2 [-Werror=strict-overflow]
These seem to be associated with code that does 'if (strcmp (s1, s2) == 0)'
Adam Jackson wrote:
On 3/7/11 10:35 AM, Richard W.M. Jones wrote:
Below is how the failure line expands(!)
Thanks, I needed a laugh this morning.
If I do this as a minimal testcase:
---
#include string.h
#include stdio.h
int
do_rm_rf (const char *path)
{
int r;
char *buf,
James Antill wrote:
On Tue, 2011-02-22 at 22:38 +0100, Jim Meyering wrote:
With some effort, and help from the guys on #anaconda@freenode (thanks!),
today I finally installed a bare-metal F15 system (part of the complication
was my existing partitions).
Then I updated it to rawhide. However
Andreas Schwab wrote:
Jim Meyering j...@meyering.net writes:
--- Package glibc.x86_64 0:2.8.90-11 will be a downgrade
Where did you get that ANCIENT package? It's almost 3 years(!) old.
I have *no* idea.
As I said, I installed F15 (into existing partitions,
but told anaconda to format
Hi,
With some effort, and help from the guys on #anaconda@freenode (thanks!),
today I finally installed a bare-metal F15 system (part of the complication
was my existing partitions).
Then I updated it to rawhide. However, the whole point of this was to
be able to compile and test some things,
[...btrfs and read-only root,/etc...]
Music to my ears.
Glad you're working on this.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
TL;DR if you have a working rawhide system, you may want to refrain
from updating it for a little while.
I have been maintaining a headless rawhide system for more than two years,
updating every 1-4 days. There have been a few hassles, but nothing
terrible. Today however, after an update and a
If you are into development on glibc-based systems
and do not set MALLOC_PERTURB_ to a nonzero value, then you
are missing an easy opportunity to detect subtle bugs early.
Sure, you can use valgrind, and it will detect whatever a
MALLOC_PERTURB_ setting would have caught, and more, but it's
far
H. Guémar wrote:
This is useful enough that it is worth considering for inclusion
in /etc/profile.
during development cycle: +1
for stable/production release: not so much (users would hate us for that)
It's definitely not suitable for everyone.
My suggestion was intended to be provocative
Michal Schmidt wrote:
On Wed, 05 May 2010 17:30:29 +0200 Jim Meyering wrote:
I propose (seriously, now) to add this to /etc/profile,
or to some always-sourced file like /etc/profile.d/glibc.sh:
# Enable glibc's malloc perturbing feature in Rawhide.
# http://udrepper.livejournal.com
James Antill wrote:
On Fri, 2010-04-23 at 15:52 -0400, Seth Vidal wrote:
On Fri, 23 Apr 2010, Jim Meyering wrote:
I've just realized that I had a list of all packages/versions
that were installed as of a few weeks ago (April 5).
In case it helps:
Yah - the history sqlite file you
Frank Murphy wrote:
On 22/04/10 22:01, Jim Meyering wrote:
There was only one: history-2010-03-08.sqlite
BZ-attached here:
http://bugzilla.redhat.com/584997
Read up on:
yum-plugin-protect-packages
if your going on autopilot.
Thanks. Installed.
IMHO, one should always be able to run yum
Seth Vidal wrote:
On Fri, 23 Apr 2010, Jim Meyering wrote:
Frank Murphy wrote:
On 22/04/10 22:01, Jim Meyering wrote:
There was only one: history-2010-03-08.sqlite
BZ-attached here:
http://bugzilla.redhat.com/584997
Read up on:
yum-plugin-protect-packages
if your going on autopilot
Seth Vidal wrote:
On Fri, 23 Apr 2010, Jim Meyering wrote:
Seth Vidal wrote:
On Fri, 23 Apr 2010, Jim Meyering wrote:
Frank Murphy wrote:
On 22/04/10 22:01, Jim Meyering wrote:
There was only one: history-2010-03-08.sqlite
BZ-attached here:
http://bugzilla.redhat.com/584997
Read up
Seth Vidal wrote:
On Thu, 22 Apr 2010, Jim Meyering wrote:
I hope it's just me...
but I was very dismayed to find that today's F13 update (which pulled
in a lot of changes) hosed my laptop. It removed almost everything
from /boot, and removed or emptied /sbin, /bin, /usr/sbin and /usr/bin
Branched Report wrote:
...
Removed package 4ti2
Removed package bakefile
Removed package cppi
...
Why has cppi been removed?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bruno Wolff III wrote:
...
Removed package cppi
...
Why has cppi been removed?
Probably the f12 version was being inherited into f13 stable. Currently
there is an f13 version in f13 testing. The maintainer can push this
to f13 stable if they want it in the release.
Oh, ok.
Thanks.
--
Richard W.M. Jones wrote:
Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
It seems that Jim can no longer set the fedora-review flag on packages
that he's reviewed, and this may be connected with Warren leaving Red
Hat for new pastures yesterday. In any case I've agreed
Dan Horák wrote:
Richard W.M. Jones píše v Čt 18. 03. 2010 v 12:01 +:
Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
It seems that Jim can no longer set the fedora-review flag on packages
that he's reviewed, and this may be connected with Warren leaving Red
Hat
Jim Meyering wrote:
Richard W.M. Jones wrote:
Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
It seems that Jim can no longer set the fedora-review flag on packages
that he's reviewed, and this may be connected with Warren leaving Red
Hat for new pastures yesterday
Mamoru Tasaka wrote:
...
My recognition is that if you change your email in FAS it may take
about an hour or so for RH bugzilla database to recognize it.
Thank you.
I will be patient ;-)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Dan Horák wrote:
Jim Meyering píše v Čt 18. 03. 2010 v 13:24 +0100:
Dan Horák wrote:
Richard W.M. Jones píše v Čt 18. 03. 2010 v 12:01 +:
Jim Meyering (FAS username: meyering) was sponsored by Warren Togami.
It seems that Jim can no longer set the fedora-review flag on packages
There was a nasty flaw in _every_ automake-generated Makefile.in
until recently[*]. When making releases, most of us who maintain
automake-using packages run make dist or make distcheck.
Even if you don't, your users may. The flaw put all of us at risk.
With a Makefile.in file generated by
Jim Meyering wrote:
There was a nasty flaw in _every_ automake-generated Makefile.in
until recently[*]. When making releases, most of us who maintain
To clarify, the vulnerability affects the distdir commands
that appear only in so-called top-level Makefile.in files.
Note however, that some
Jon Masters wrote:
On Wed, 2010-02-10 at 10:58 +0100, Jim Meyering wrote:
There was a nasty flaw in _every_ automake-generated Makefile.in
until recently[*]. When making releases, most of us who maintain
automake-using packages run make dist or make distcheck.
Even if you don't, your users
Jim Meyering wrote:
Hello,
I've just returned one relatively new disk drive[*],
and hope I'm not about to return another...
[*] It was a 1TB Samsung ecogreen, and some strenuous testing
would reliably provoke I/O errors which would apparently
damage the disk enough to force
95 matches
Mail list logo
