On Feb 20, 2013 6:29 PM, "Basil Mohamed Gohar"
wrote:
>
> For a while now the package "mate-file-archiver" has had a dependency
problem and cannot be updated. I've opened a ticket about it (
https://bugzilla.redhat.com/show_bug.cgi?id=908137) but it has received no
response for over two weeks. I
On Wed 20 Feb 2013 08:38:56 PM PST, Kevin Fenzi wrote:
>
> See:
> http://fedoraproject.org/wiki/Package_maintainer_policy#Submitter_not_responding
>
Thank you. New bug report submitted with closed old review as duplicate:
https://bugzilla.redhat.com/show_bug.cgi?id=913367
--
Luya Tshimbalanga
Gra
On 02/20/2013 10:37 PM, Chris Murphy wrote:
On Feb 20, 2013, at 3:45 PM, Digimer wrote:
Currently, as the OS disk, it mounts on boot with the default values set by
Fedora;
==] /etc/fstab [
/dev/mapper/luks-bd252fe0-a16f-4a14-ad4e-b99a0d4c0716 / ext4
defaults,x-systemd.
On Wed, 20 Feb 2013 20:31:12 -0800
Luya Tshimbalanga wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Greetings all,
> I contacted the original reviewee for packaging gpick on rhgz 853775
> last Friday February 12 but I have not received any response. I would
> like to take over t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings all,
I contacted the original reviewee for packaging gpick on rhgz 853775
last Friday February 12 but I have not received any response. I would
like to take over the package (essentially the same) which will contain
changes corresponding to
We discussed a few possible changes to the blocker bug meeting process
at the QA meeting this week. It was agreed that I'd draft up these
changes for list discussion. So here they are! Sent to test@ and devel@
as QA, devel and releng are the stakeholders in this process: I'm
figuring releng folks a
On Feb 20, 2013, at 3:45 PM, Digimer wrote:
>
> Currently, as the OS disk, it mounts on boot with the default values set by
> Fedora;
>
> ==] /etc/fstab [
> /dev/mapper/luks-bd252fe0-a16f-4a14-ad4e-b99a0d4c0716 / ext4
> defaults,x-systemd.device-timeout=0 1 1
> UUID=eca11
For a while now the package "mate-file-archiver" has had a dependency
problem and cannot be updated. I've opened a ticket about it
(https://bugzilla.redhat.com/show_bug.cgi?id=908137) but it has received
no response for over two weeks. I am not sure that the package is
terribly important, but
Hi All. I am the upsteam dev for profile-sync-daemon and have
packaged it for: Arch Linux, Gentoo, and Ubuntu. I would like to
extend that list to include Fedora as well. I have been simply
posting rpms to a web host, but feel that the right way to maintain a
package is in an official repo. I re
On 02/20/2013 05:01 PM, Chris Murphy wrote:
On Feb 20, 2013, at 12:42 PM, Digimer wrote:
b) I 0'ed out the entire drive (over USB from F18 on my older SSD) before
reinstalling F18 on the Samsung.
FYI this isn't a good idea with SSDs. Use ATA Secure Erase instead with hdparm,
or the includ
On Feb 20, 2013, at 12:42 PM, Digimer wrote:
>
> b) I 0'ed out the entire drive (over USB from F18 on my older SSD) before
> reinstalling F18 on the Samsung.
FYI this isn't a good idea with SSDs. Use ATA Secure Erase instead with hdparm,
or the included Windows utility can do this - it almost
Thanks to those who were able to join us for the weekly status meeting today.
For those that were unable, the minutes are posted below:
Minutes:
http://meetbot.fedoraproject.org/fedora-meeting-1/2013-02-20/fedora-meeting-1.2013-02-20-21.00.html
Minutes (text):
http://meetbot.fedoraproject.org/
Hello,
I've been asked by Luya Tshimbalanga to
maintain the gimp-separate+ package for official Fedora project so that
it can be included in Design Suite Livemedia.
Having read some introductory information, I would now like to introduce
myself with few short facts:
- I'm using Linux (at start
Thanks. I've got the license info (GPLv3) pushed to the git
repository, but need to tag a new version for it to show up on the
download page (probably tonight once I get a couple more front-end
scripts in the repo).
On Wed, Feb 20, 2013 at 2:34 PM, Miro Hrončok wrote:
> Hi.
>
> Not answering you
Hi.
Not answering your questions, but I would strongly recommend to add a
LICENSE or COPYING file with the license of your app.
--
Miro Hrončok
--
Phone: +420777974800
Jabber: m...@hroncok.cz
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/d
On Wed, Feb 20, 2013 at 1:55 PM, Ville Skyttä wrote:
> Hello,
>
> I've released ownership of the following low maintenance packages I
> haven't used in a while. None of these have any co-maintainers.
>
> Branches in Fedora and EPEL:
> - seeker: Random access disk benchmark utility
>
> Taken.
-J
Hello,
I've released ownership of the following low maintenance packages I
haven't used in a while. None of these have any co-maintainers.
Branches in Fedora and EPEL:
- seeker: Random access disk benchmark utility
Branches in Fedora only:
- vdr-skins: Collection of skins for VDR's on-screen dis
On 02/19/2013 01:49 AM, Chris Murphy wrote:
On Feb 18, 2013, at 10:13 PM, Digimer wrote:
what's "offline data collection"?
http://smartmontools.sourceforge.net/man/smartctl.8.html
Read in particular the paragraph containing the word unfortunate.
0x0009 2 19 Transition from d
Hi Fedora users, developers and friends!
It's time to start thinking about Test Days for Fedora 19.
For anyone who isn't aware, a Test Day is an event usually focused
around IRC for interaction and a Wiki page for instructions and results,
with the aim being to get a bunch of interested users and
Josh Boyer (jwbo...@gmail.com) said:
> On Tue, Feb 19, 2013 at 7:39 PM, Miloslav Trmač wrote:
> > Following is the list of topics that will be discussed in the FESCo
> > meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on
> > irc.freenode.net.
> >
> > Links to all tickets
On Tue, Feb 19, 2013 at 7:39 PM, Miloslav Trmač wrote:
> Following is the list of topics that will be discussed in the FESCo
> meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on
> irc.freenode.net.
>
> Links to all tickets below can be found at:
> https://fedorahosted.org/
On 02/20/2013 05:33 PM, Jakub Jelinek wrote:
Of course, the script needs to be smart, because e.g. glibc will always
contain __xstat symbol, as it is part of the exported ABI.
It's sufficient to consider references only, definitions don't count. I
believe Eric's script does exactly that. (sy
On Wed, Feb 20, 2013 at 09:40:00AM -0600, Eric Sandeen wrote:
> I really don't think it's safe to add -D_FILE_OFFSET_BITS=64 to the
> default CFLAGS. Code will start getting bigger numbers and will
> need to cope appropriately lest they overflow. It'd be draconian
> but I'd prefer to do somethin
Good Morning all,
Please join us today (Wednesday, February 20th) at 4PM EST (9PM UTC)
for the Fedora ARM weekly status meeting in #fedora-meeting-1 on Freenode.
On the agenda so far..
0) Status of ACTION items from our previous meeting
1) Problem packages
2) ARM Koji moved to Phoenix - Remain
> "David" == David Malcolm writes:
David> In particular, for scripting languages,
David> it's most useful to be able to extract the script-level backtrace from
David> the C-level stack (i.e. "what was the Python code doing?")
FWIW we're adding direct support for this to gdb.
You'll be able t
On 02/20/2013 03:04 AM, Ian Malone wrote:
Question: does a python segfault from a broken script indicate a
python bug as well? The scripting engine shouldn't really be crashing.
Of course--I'd argue such thing is really a blessing in disguise and the
offending script should be added to the Py
On 2/20/13 8:23 AM, Chris Adams wrote:
> Once upon a time, Bill Nottingham said:
>> Florian Weimer (fwei...@redhat.com) said:
>>> If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes
>>> pretty close to an ABI bump. But considering the numbers, I wonder
>>> if it's the right thing t
On 02/08/2013 11:54 AM, Troy Dawson wrote:
> Hello,
> A couple of months back I asked about updating MongoDB from 2.0.7 to
> 2.2.0 in EPEL6 and Fedora 17.
> Although it is backwards compatible, there were several bugs brought up
> that people wanted fixed in Mongodb 2.2.x before we moved to this
>
On Wed, Feb 20, 2013 at 01:23:56PM +, Richard Hughes wrote:
> On 20 February 2013 10:32, Florian Weimer wrote:
> > If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes pretty
> > close to an ABI bump. But considering the numbers, I wonder if it's the
> > right thing to do if we n
Once upon a time, Bill Nottingham said:
> Florian Weimer (fwei...@redhat.com) said:
> > If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes
> > pretty close to an ABI bump. But considering the numbers, I wonder
> > if it's the right thing to do if we need to cope with 64-bit inode
On Wed, Feb 20, 2013 at 09:01:30AM -0500, Colin Walters wrote:
> The first option on the table should be patching upstreams, not hacking
> around it in RPM or changing the default.
>
> With autoconf, all you need is to add AC_SYS_LARGEFILE to configure.ac,
> and assuming no source changes are nece
On Wed, 2013-02-20 at 14:43 +0100, Joe Orton wrote:
> If we want the "system default" for the LFS APIs to change, surely it is
> safer and more correct to change the system (libc) default and have
> _FILE_OFFSET_BITS defined to 64 eveywhere?
The first option on the table should be patching upst
On Wed, Feb 20, 2013 at 11:32:46AM +0100, Florian Weimer wrote:
> If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes
> pretty close to an ABI bump. But considering the numbers, I wonder
> if it's the right thing to do if we need to cope with 64-bit inode
> numbers.
I think that wou
On Wed, Feb 20, 2013 at 01:31:49PM +0100, Miloslav Trmač wrote:
> If one wants to run tmpwatch on a different directory, it is easiest
> to set up a separate cron entry (either in /etc/cron.daily, or in
> users' crontab); this avoids the issue.
In which case, maybe it shouldn't be marked as a con
On 20 February 2013 10:32, Florian Weimer wrote:
> If we add -DFILE_OFFSET_BITS=64 to the default CFLAGS, this comes pretty
> close to an ABI bump. But considering the numbers, I wonder if it's the
> right thing to do if we need to cope with 64-bit inode numbers.
I think this is the sanest thing
On Wed, Feb 20, 2013 at 2:17 PM, Bill Nottingham wrote:
> Miloslav Trmač (m...@volny.cz) said:
>> That would be very useful.
>>
>> 1) Easy: run a script to find affected packages and auto-file bugs.
>> 2) Fairly possible: get at least the important packages fixed in F19
>> (or, 1+2: change default
Miloslav Trmač (m...@volny.cz) said:
> That would be very useful.
>
> 1) Easy: run a script to find affected packages and auto-file bugs.
> 2) Fairly possible: get at least the important packages fixed in F19
> (or, 1+2: change default build configuration to cover most packages,
> and rebuild.)
>
commit 3b41e3c8785f4aa9da554b710a172895ff7ee5f5
Author: Petr Písař
Date: Wed Feb 20 13:54:40 2013 +0100
0.032 bump
.gitignore |1 +
.rpmlint |2 ++
perl-threads-lite.spec | 30 +--
A file has been added to the lookaside cache for perl-threads-lite:
7b78207f85beb6c2b8ccf4c1b4df9f73 threads-lite-0.032.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/ma
On Mon, Feb 18, 2013 at 10:33 PM, Eric Sandeen wrote:
> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
> inode numbers creep past 2^32 as well.
>
> While most applications don't care one bit about st_ino returned from a
> stat() call, the sad fact is that you'll get
On Tue, Feb 19, 2013 at 5:04 PM, Florian Weimer wrote:
> On 02/19/2013 04:32 PM, Jakub Jelinek wrote:
>>
>> On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
(3) For my code that uses st_ino, I need to ensure this is never
assigned to a 32 bit integer (eg. 'int', 'int32_
On Tue, Feb 19, 2013 at 4:28 PM, Matthew Miller
wrote:
> Without commenting on the general case, I think that in the specific case
> the explanation applies. If one wants to add a new directory to the tmpwatch
> list, thus modifying the file, and then we (oh for example) change the
> location of /
On Tue, Feb 19, 2013 at 3:43 PM, Sergio Belkin wrote:
> Hi, rpmlint complains about cron files, is that a bug?
>
> For example:
>
> tmpwatch.x86_64: E: executable-marked-as-config-file
> /etc/cron.daily/tmpwatch
> Executables must not be marked as config files because that may prevent
> upgrades f
On 20/02/13 09:40, Jiri Moskovcak wrote:
> One thing we're struggling with now is the normalization of stacktraces
> which means deciding which functions are important and which are not.
> e.g. for kernel there are stacktraces with a lot of warn_* functions and
> only a few functions are differe
Florian Weimer (fwei...@redhat.com) said:
> On 02/18/2013 10:33 PM, Eric Sandeen wrote:
>
> >XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
> >inode numbers creep past 2^32 as well.
> >
> >While most applications don't care one bit about st_ino returned from a
> >s
Thank you Dave!
That's exactly the kind of ideas I was looking for.
Just a short summary what we can do on the server (now) to get this
brainstorm going:
- it has all the rpm debuginfo packages, so getting the symbol names or
lines is not a problem (actually we do that even now)
- it can ext
Christoph Wickert (christoph.wick...@gmail.com) said:
> 3. The feature submission deadline was poorly communicated. First
> the schedule was only preliminary, then it was finalized, but
> this changed not announced. The announcement about the final
> feature submission
47 matches
Mail list logo
