[Test-Announce] Xfce Test Day tomorrow!
Remember, everyone tomorrow - 2011-02-17 - is Xfce Test Day! F15 will have Xfce 4.8 and this version is in already, so we need lots of testing to make sure it's all working fine. All the test info is on the Wiki page - https://fedoraproject.org/wiki/Test_Day:2011-02-17_Xfce - and we'll be in #fedora-test-day to help out and discuss results. Do come along if you have some spare time. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Abandoned packages (mediawiki-openid and php-pear-Auth-OpenID-2.1.1)
Sorry for the late reply, I have a filter rule for fedora-devel and forgot to check the folder. My account name on FAS is "kurtseifried" -Kurt On Thu, Feb 10, 2011 at 8:25 PM, Kevin Fenzi wrote: > On Thu, 10 Feb 2011 14:34:02 -0700 > Kurt Seifried wrote: > >> Hey just pinging you, do I need to do anything to get added to the >> packages still? > > Hum. You are not currently a packager? > (or if so, I can't find your account in that group). > > If you aren't, we will need to get you sponsored before you can work on > these packages. If you are, can you mail me in private your account > info? > > Thanks, > > kevin > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > -- Kurt Seifried k...@seifried.org skype: 1-703-879-3176 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
New celt build broke jack-audio-connection-kit...
I was just trying to build the latest Asterisk, which uses jack-audio-connection-kit, but it looks like the most recent build of celt from this afternoon broke the build: DEBUG util.py:247: libcelt0.so.1()(64bit) is needed by jack-audio-connection-kit-1.9.6-4.fc16.x86_64 -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
AutoQA for F15
Do we need to manually sign up for F15 AutoQA checks? It seems packages I'm building for F15 are not getting checked. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libstdc++ crash in Fedora 15
Michael Schwendt wrote: > In Fedora 15 development only, not reproducible with Fedora 14: > > Could you help classifying the following backtrace? > https://bugzilla.redhat.com/attachment.cgi?id=473671 > > It's related to dlopening a shared lib and crashes during initialization > of static members. ( https://bugzilla.redhat.com/669889 ) > Would be great to get confirmation whether it's a problem outside the > shared lib that's loaded. More details in the bz ticket. This is a C++ static initialization order issue (within the shared lib), see: https://bugzilla.redhat.com/show_bug.cgi?id=669889#c12 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary from today's FESCo meeting (2011-02-16)
=== #fedora-meeting: FESCO (2011-02-16) === Meeting started by nirik at 17:30:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-16/fesco.2011-02-16-17.30.log.html Meeting summary --- * init process (nirik, 17:30:02) * SMParrish and mmaslano unable to attend today. (nirik, 17:32:27) * #516 Updates policy adjustments/changes (nirik, 17:35:20) * mmaslano voted +1 on this in ticket. (nirik, 17:39:28) * AGREED: idea is not accepted at this time. (nirik, 17:42:15) * mmaslano voted 0 on this in ticket. (nirik, 17:44:05) * AGREED: idea is not accepted at this time. (nirik, 17:48:27) * #515 Investigate a "features" repo for stable releases (nirik, 17:48:37) * #517 Updates Metrics (nirik, 17:49:36) * kylem will try and spend a bit of time on this. (nirik, 17:51:32) * #544 List of services that may start by default (nirik, 17:51:38) * Will defer this and see what FPC decides over the next week. (nirik, 17:59:39) * #562 Transifex migration (nirik, 17:59:46) * l10n + infrastructure have decided to move from hosting our own transifex instance, to using upstream transifex.net (notting, 18:01:26) * this will cause some changes in workflow for developers (most of which are actually due to the transifex version upgrade) (notting, 18:01:30) * #561: Should bugz.fedoraproject.org give links to security/private bugs? (nirik, 18:11:33) * AGREED: Fesco is ok with showing bug numbers of private bugs. Or using some other method pkgdb maintainers wish like a disclaimer/link to query? (nirik, 18:24:11) * #560 Adding packages to EPEL without adding it to Fedora (nirik, 18:24:22) * AGREED: proposal: re-iterate that package maintainers should follow all the responsibilities of being a package maintainer for all the branches that their package has. No requirement should be forced for which branches a maintainer can request. (nirik, 18:44:16) * Open floor (nirik, 18:44:53) * gholms to ask rel-eng / qa about updates-testing enabled by default. (nirik, 18:59:05) Meeting ended at 19:01:20 UTC. Action Items Action Items, by person --- * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (148) * kylem (34) * notting (31) * ajax (30) * abadger1999 (24) * gholms (21) * mjg59 (15) * tibbs|h (15) * zodbot (13) * mclasen (11) * glezos (6) * Oxf13 (5) * SMParrish_mobile (4) * lmacken (1) * hicham (1) * SMParrish (0) * mmaslano (0) * cwickert (0) -- 17:30:02 #startmeeting FESCO (2011-02-16) 17:30:02 Meeting started Wed Feb 16 17:30:02 2011 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:30:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:30:02 #meetingname fesco 17:30:02 The meeting name has been set to 'fesco' 17:30:02 #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano 17:30:02 #topic init process 17:30:02 Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting 17:30:31 who all is around today? 17:31:05 * mclasen is somewhat around 17:32:04 * nirik guesses it might be a short meeting if we don't have quorum. ;) 17:32:04 sorry, here now 17:32:27 here but mobile 17:32:27 #info SMParrish and mmaslano unable to attend today. 17:32:34 oh, my mistake. ;) 17:33:06 yo. 17:34:00 * nirik waits a few more for more folks to show. 17:34:10 I guess we do have 5 now tho. 17:35:08 ok, I guess lets go ahead and dive in... 17:35:20 #topic #516 Updates policy adjustments/changes 17:35:20 .fesco 516 17:35:21 nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516 17:35:31 I added 2 new thoughts from the ideas container for this week: 17:35:36 Hey, sorry 17:35:42 hello again 17:36:12 welcome ajax and mjg59 17:36:17 so, first: 17:36:20 1) reduced karma requirement on other releases when one has gone stable. 17:36:47 The idea here is that if someone tested out ok in one release, it should be fine in another 17:37:49 so, say a openchrome driver goes stable in f14, the f13 update where no one with hardware to test it could go stable at a lower criteria. 17:37:53 i know we have problems with getting karma and stuff, but making it /easier/ to push updates to older stable releases doesn't seem entirely the answer... 17:38:20 not really a fan of that idea, i gotta say. 17:38:21 nirik, or, break everything because of a subtle version difference in a dependency that went unnoticed and then is pushed out... 17:38:27 yep. 17:38:32 Yeah, if anything we'd prefer that older releases get fewer updates 17:38:58 i mean, everything sucks, we're never going to win on this. i think i'm in favour of an edict from on high versus endless debate. :) 17:38:59 I personally am -1 to t
Re: GitHub Hosted upstream 'Source0'
> That does not mean that the compressed contents will always be the same. > At least the gzip compressed tarballs from github contain a time stamp. That is true of the tarball-generation feature of gitweb or whatever it's called last I looked too. It's easily fixed by having it pass -n to gzip (which I would have thought they could have fixed in gitweb by now), and already does not apply to bzip2 format. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-MooseX-NonMoose] update to 0.18
commit 8891b99465127140957810b80ea9a1ac685994b7
Author: Iain Arnell
Date: Wed Feb 16 18:18:56 2011 +0100
update to 0.18
.gitignore|1 +
perl-MooseX-NonMoose.spec |9 +++--
sources |2 +-
3 files changed, 9 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3c8ef52..130fed8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/MooseX-NonMoose-0.16.tar.gz
/MooseX-NonMoose-0.17.tar.gz
+/MooseX-NonMoose-0.18.tar.gz
diff --git a/perl-MooseX-NonMoose.spec b/perl-MooseX-NonMoose.spec
index 1b26cf4..895d1d5 100644
--- a/perl-MooseX-NonMoose.spec
+++ b/perl-MooseX-NonMoose.spec
@@ -1,6 +1,6 @@
Name: perl-MooseX-NonMoose
-Version:0.17
-Release:2%{?dist}
+Version:0.18
+Release:1%{?dist}
Summary:Easy subclassing of non-Moose classes
License:GPL+ or Artistic
Group: Development/Libraries
@@ -10,6 +10,7 @@ BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(List::MoreUtils)
BuildRequires: perl(Moose) >= 1.15
+BuildRequires: perl(MooseX::GlobRef)
BuildRequires: perl(MooseX::InsideOut)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::Moose)
@@ -60,6 +61,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Feb 16 2011 Iain Arnell 0.18-1
+- update to latest upstream version
+- BR perl(MooseX::GlobRef) for additional test coverage
+
* Tue Feb 08 2011 Fedora Release Engineering
- 0.17-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
diff --git a/sources b/sources
index b836aa3..c05cf97 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ffc6819c6107bfc4e9417f7e433cd4e5 MooseX-NonMoose-0.17.tar.gz
+ae49a26d05ab00cc9fefd5c06149b00e MooseX-NonMoose-0.18.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/mailman/listinfo/perl-devel
Re: Should bugz.fp.o give links to security/private bugs?
On 2/15/11 4:29 PM, Toshio Kuratomi wrote: > https://fedorahosted.org/fesco/ticket/561 > > Recently, it was brought up to me that bugz.fp.o was showing summaries of > bugs that are marked private. This was probably revealing too much > information as summaries could contain harmful clues about security issues. > My quick fix was to not list those bugs at all. However, I wanted to restore > the bug #'s themselves to the list (with a hidden summary). This brings up > a question of how much security is warranted: > > On the one hand, it could be argued that even seeing that there's a new > private (and therefore likely security) bug against a package may be giving > away too much information. "Oh, so bind has a new private bug in Fedora's > bugzilla? I wonder if I can ask my blackhat contacts for some bind exploit > code before that gets fixed." > > The opposite side is that maintainers have come to use bugz.fp.o as a way to > quickly find and see what bugs exist in their packages. A maintainer that > depends on that could be unpleasantly surprised by the lack of private bugs > -- for instance, forgetting about a security bug because it's not listed on > bugz.fp.o or someone reviving an orphaned package unaware that it has > unresolved security bugs. > > > I'm posting here to get feedback on whether other maintainers use bugz.fp.o > like this and see this as a problem. If so, I'll have FESCo decide whether > security or convenience/confusion is more important in this case. > > -Toshio > I think either way would be fine, but what I'd also like to see is a link for the query that one can click on and run within bugzilla using their own bugzilla credentials. That way they can get the full view of potentially private items as well. If you go on the side of not showing all bugs (if you can detect that there are some private ones), perhaps show a admonition somewhere that not all bugs are shown, please log into bugzilla for the full view, otherwise don't show the admonition. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Procedure to push a package causing broken deps to f15?
On 02/16/2011 05:07 PM, Marcela Maslanova wrote:
>
>
> - Original Message -
>> From: "Ralf Corsepius"
>> To: "Development discussions related to
>> Fedora"
>> Sent: Wednesday, February 16, 2011 12:44:44 PM
>> Subject: Re: Procedure to push a package causing broken deps to f15?
>> On 02/16/2011 10:55 AM, Kevin Kofler wrote:
>>> Marcela Mašláňová wrote:
I completely agree.
At least nag-mails about the broken dependencies (because of
rpm-4.9)
should be delivered sooner or we should wait with branching or do
mass-rebuild sooner. Now we have to build everything for F-{15,16}
and
even wait for testing,
>> The real problem behind all this is these packages having made it into
>> f15 - This should not have happened, QA should have caught them
>> earlier,
>> should have fixed them or at least have informed these packages'
>> owners.
>>
> Autoqa should be able to track these dependencies, but it's not ready yet.
Uncooked future ... irrelevant at this point in time.
>> That said, I would propose to immediately push package updates for f15
>> to testing (spares ca. 24 hours of delay) and to reduce the
>> "testing->stable" push delay to 24 hours or less.
>
> I suppose this was already denied by FESCo,
Well, provided the long history of "arguable" decisions of FESCo, this
would not surprize me.
May-be your FESCo collegues should be delegated to ironing out the
current perl mess to learn why the current practice is not helpful?
but I could be wrong.
> We were definitely speaking about shorter periods in testing, but the
> period looked to short and updates probably won't be tested at all.
ROTFL ... How many vote do your perl-package updates normally receive?
95%-99% of mine don't receive any. I.e. probably all testing they saw
was preformed by me (the maintainer).
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Email maintainer before updating package
On 02/16/2011 05:30 PM, Shakthi Kannan wrote: > Hi, > > I appreciate updates and hot-fixes applied to packages on new builds. > Is it possible to send an e-mail to the package maintainer before > updating the package? Or is there some reminder already in place that > does this? > > Please let me know, You should be receiving mails after every commit if you are owner or have watchcommits enabled for package. If you don't like the commit you can always do "git revert " and do it your way. Or just fix up the part you want to do differently... -- Stanislav Ochotnicky Associate Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Email maintainer before updating package
Hi, I appreciate updates and hot-fixes applied to packages on new builds. Is it possible to send an e-mail to the package maintainer before updating the package? Or is there some reminder already in place that does this? Please let me know, Thanks! SK -- Shakthi Kannan http://www.shakthimaan.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File MooseX-NonMoose-0.18.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-MooseX-NonMoose: ae49a26d05ab00cc9fefd5c06149b00e MooseX-NonMoose-0.18.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/mailman/listinfo/perl-devel
File Parse-CPAN-Meta-1.4401.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Parse-CPAN-Meta: 32c8b2ba97887b526a0948706c546eba Parse-CPAN-Meta-1.4401.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/mailman/listinfo/perl-devel
[Bug 678059] [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=678059 --- Comment #2 from Miguel 2011-02-16 11:22:14 EST --- http://mail.szabgab.com/pipermail/padre-dev/2009-May/000988.html -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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/mailman/listinfo/perl-devel
[Bug 678059] New: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) https://bugzilla.redhat.com/show_bug.cgi?id=678059 Summary: [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) Product: Fedora Version: 14 Platform: x86_64 OS/Version: Unspecified Status: NEW Status Whiteboard: abrt_hash:fb5f60b4a96a5778e5e4b8de47c5a4676729b571 Severity: unspecified Priority: unspecified Component: perl-Padre AssignedTo: mmasl...@redhat.com ReportedBy: luzem...@gmail.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora abrt version: 1.1.14 architecture: x86_64 Attached file: backtrace cmdline: /usr/bin/perl /usr/bin/padre component: perl-Padre executable: /usr/bin/perl kernel: 2.6.35.11-83.fc14.x86_64 package: perl-Padre-0.64-1.fc14 reason: Process /usr/bin/perl was killed by signal 11 (SIGSEGV) release: Fedora release 14 (Laughlin) time: 1297872396 uid: 500 How to reproduce - 1. launch padre 2. 3. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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/mailman/listinfo/perl-devel
[Bug 678059] [abrt] perl-Padre-0.64-1.fc14: Process /usr/bin/perl was killed by signal 11 (SIGSEGV)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=678059 --- Comment #1 from Miguel 2011-02-16 11:14:33 EST --- Created attachment 479153 --> https://bugzilla.redhat.com/attachment.cgi?id=479153 File: backtrace -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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/mailman/listinfo/perl-devel
Re: GitHub Hosted upstream 'Source0'
On 02/16/2011 04:58 PM, Andreas Schwab wrote: > Stanislav Ochotnicky writes: > >> On 02/16/2011 03:36 PM, Matej Cepl wrote: >>> Dne 16.2.2011 11:06, Stanislav Ochotnicky napsal(a): > Which basically takes the tag name and creates a nice tarball from it. Although I should pipe it through gzip/bzip2 :-/ >>> >>> And you really don't resolve the issue with unstable MD5 checksum. >> >> Why would that be? I am creating the tarball from the same git tag. Yes >> I am using tag name, so theoretically if upstream is ugly enough to >> overwrite their tags with different contents, this will be a problem. >> But normally I can re-create the tarball using "git archive" and the md5 >> checksum will stay the same. Can you tell me how exactly this won't work? > > That does not mean that the compressed contents will always be the same. $ git clone -q git://github.com/sonatype/sisu $ GIT_DIR=sisu/.git git archive --prefix="sonatype-sisu-1.4.3.2/" \ --format=tar sisu-1.4.3.2 | bzip2 > tarball1.tar.bz2 $ rm -rf sisu/ $ git clone -q git://github.com/sonatype/sisu $ GIT_DIR=sisu/.git git archive --prefix="sonatype-sisu-1.4.3.2/" \ --format=tar sisu-1.4.3.2 | bzip2 > tarball2.tar.bz2 $ md5sum tarball* 085fc5da0a7b504482e5e6449349316d tarball1.tar.bz2 085fc5da0a7b504482e5e6449349316d tarball2.tar.bz2 True, this is just one test run and yes...it's enough for the git or bzip2 defaults to change and this will stop working. But as long as they stay the same the MD5 is stable. Bonus points for using git hash instead of tag name I guess... > At least the gzip compressed tarballs from github contain a time stamp. True, but git-archive doesn't do that by default. That's just their "improvement" AFAIK -- Stanislav Ochotnicky Associate Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Procedure to push a package causing broken deps to f15?
- Original Message - > From: "Bruno Wolff III" > To: "Ralf Corsepius" > Cc: "Development discussions related to Fedora" > , "Tom Callaway" > Sent: Monday, February 14, 2011 6:51:21 PM > Subject: Re: Procedure to push a package causing broken deps to f15? > On Mon, Feb 14, 2011 at 18:35:54 +0100, > Ralf Corsepius wrote: > > > > I was looking into fixing the 10-15 perl-packages, which have made > > it > > into current f15, even though they carry broken deps. Waiting the > > usual > > 8-10 days of delay is not helpful for such cases, because they will > > cause f15 to remain broken for at minimum this delay time (Which in > > case > > of dep chains, can easily evolve to several weeks [1]). > > The policy is at http://www.fedora.redhat.com/wiki/Updates_Policy. > For branched (pre-beta) you only need to wait three days if you get no > karma > and it isn't critpath. You can set the karma required to one and get > someone > else to do a test and sign off on it and move it to stable right after > that. Or it should be possible to fix such bugs with request on release engineering ;-) https://fedorahosted.org/rel-eng/ticket/4443 -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Procedure to push a package causing broken deps to f15?
- Original Message -
> From: "Ralf Corsepius"
> To: "Development discussions related to Fedora"
>
> Sent: Wednesday, February 16, 2011 12:44:44 PM
> Subject: Re: Procedure to push a package causing broken deps to f15?
> On 02/16/2011 10:55 AM, Kevin Kofler wrote:
> > Marcela Mašláňová wrote:
> >> I completely agree.
> >>
> >> At least nag-mails about the broken dependencies (because of
> >> rpm-4.9)
> >> should be delivered sooner or we should wait with branching or do
> >> mass-rebuild sooner. Now we have to build everything for F-{15,16}
> >> and
> >> even wait for testing,
> The real problem behind all this is these packages having made it into
> f15 - This should not have happened, QA should have caught them
> earlier,
> should have fixed them or at least have informed these packages'
> owners.
>
Autoqa should be able to track these dependencies, but it's not ready yet.
> >> which is ridiculous in this case. It's only delay
> >> fixing of broken deps.
> Agreed, Note my wording: I call this a "delay queue", not a "QA input
> queue", because it's effectively a mere delay queue without any
>
> > Well, I proposed a way to fix the procedure:
> > http://lists.fedoraproject.org/pipermail/devel/2011-February/148604.html
> >
> > What do you think of that?
> Well, then the same will happen with the beta freeze.
>
> To me, the key would be not to let packages causing broken deps into
> the
> repos. QA should preform an analysis on how they made it into the
> repos
> (In my understanding, the cause this time, was an improperly merged
> last-minute mass rebuild of the perl-modules, which due to a change in
> rpm's dep-tracking is causing broken deps).
>
> That said, I would propose to immediately push package updates for f15
> to testing (spares ca. 24 hours of delay) and to reduce the
> "testing->stable" push delay to 24 hours or less.
>
> Ralf
>
I suppose this was already denied by FESCo, but I could be wrong.
We were definitely speaking about shorter periods in testing, but the
period looked to short and updates probably won't be tested at all.
Marcela
--
Marcela Mašláňová
BaseOS team Brno
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Procedure to push a package causing broken deps to f15?
- Original Message - > From: "Paul Howarth" > To: "Peter Robinson" > Cc: "Development discussions related to Fedora" > > Sent: Wednesday, February 16, 2011 10:43:18 AM > Subject: Re: Procedure to push a package causing broken deps to f15? > On 16/02/11 09:39, Peter Robinson wrote: > > On Wed, Feb 16, 2011 at 7:46 AM, Paul Howarth > > wrote: > >> On Mon, 14 Feb 2011 11:51:21 -0600 > >> Bruno Wolff III wrote: > >> > >>> On Mon, Feb 14, 2011 at 18:35:54 +0100, > >>>Ralf Corsepius wrote: > > I was looking into fixing the 10-15 perl-packages, which have > made > it into current f15, even though they carry broken deps. Waiting > the usual 8-10 days of delay is not helpful for such cases, > because > they will cause f15 to remain broken for at minimum this delay > time > (Which in case of dep chains, can easily evolve to several weeks > [1]). > >>> > >>> The policy is at http://www.fedora.redhat.com/wiki/Updates_Policy. > >>> For branched (pre-beta) you only need to wait three days if you > >>> get > >>> no karma and it isn't critpath. You can set the karma required to > >>> one > >>> and get someone else to do a test and sign off on it and move it > >>> to > >>> stable right after that. > >> > >> I just tried marking > >> https://admin.fedoraproject.org/updates/perl-Net-SSH-Perl-1.34-11.fc15 > >> as stable; it's been in testing for 3 days and 4 hours now so I > >> expected it to work but was told by bodhi that it hadn't been in > >> testing for the required period yet. Does bodhi know that the > >> pre-beta > >> testing period is a minimum of 3 days rather than 7? > > > > Its the date that its pushed to testing not the date its submitted. > > I know. It was pushed to testing on 2011-02-13 at 03:23:21 and I tried > to mark it stable on 2011-02-16 at 07:40:00 (+3 days and 4 hours). > > > Looking at it now it has a message that it can be pushed to stable. > > That's because Ralf has since tested it and given it karma to make it > to > the stable threshold (thanks Ralf). > > Paul. I've filed a ticket on bodhi, we'll see: https://fedorahosted.org/bodhi/ticket/586 -- Marcela Mašláňová BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub Hosted upstream 'Source0'
Stanislav Ochotnicky writes: > On 02/16/2011 03:36 PM, Matej Cepl wrote: >> Dne 16.2.2011 11:06, Stanislav Ochotnicky napsal(a): Which basically takes the tag name and creates a nice tarball from it. >>> >>> Although I should pipe it through gzip/bzip2 :-/ >> >> And you really don't resolve the issue with unstable MD5 checksum. > > Why would that be? I am creating the tarball from the same git tag. Yes > I am using tag name, so theoretically if upstream is ugly enough to > overwrite their tags with different contents, this will be a problem. > But normally I can re-create the tarball using "git archive" and the md5 > checksum will stay the same. Can you tell me how exactly this won't work? That does not mean that the compressed contents will always be the same. At least the gzip compressed tarballs from github contain a time stamp. Andreas. -- Andreas Schwab, sch...@redhat.com GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E "And now for something completely different." -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 677799] Broken dependency: perl-DateTime-Format-Mail-0.3001-9.fc15.noarch requires perl(DateTime) >= 0:0.1705
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=677799 --- Comment #8 from Ralf Corsepius 2011-02-16 10:50:10 EST --- (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #4) > > > Well, not *easily* ... but the AutoQA [1] folks are working on it. > > Meanwhile switch off this silly delay queue - Whether you like it or not, it > > has never worked, not even in f13 and f14 ... it's just that the "broken > > mass > > merger" is exposing the delay queue's detrimental effect to a wider > > audience. > > The "delay" as you call it, has worked quite nicely during Fedora 14 > stabilization. You are cheating to yourself - The only effect it has is it adding more delays to the already exiting delays. Probably you're too close to it and don't maintain enough packages to understand. > As maintainer, you might not have exposure to the numerous pain > points we experience when trying to assemble a distribution full of > interdependent moving targets. I am experiencing the detrimental impact of the delays at full strength all of the time, e.g. * fixing bugs takes weeks and months, if a bug fix adds a necessity of updating or adding a package chain (pretty common with perl). * updates/bug-fixes are outdated when they are being released (Typically happens when upstreams start "hectic activity", when being notified about bugs) * not being able to push bug-fixes in timely manners (typically happens when bugs are causing "non-security" relevant malfunctions). > As a Fedora user+contributor, I'm sure you are > aware of the issues we encounter leading up to release milestones. Correct, and the delays add further to them. Ask yourselves: Why is this thread around? because the delays are rending fixing bugs a nightmare and are the cause of churn and bugs, next to a release milestone!! > While the Karma system isn't perfect, and there are always improvements that > could be made, it has been a life saver to allow us to more consistently > release Fedora on time. You mean on the may-be 5-10% of packages which receive a vote at all? >From my packages (And I maintain many), in almost all cases, my packages don't receive any vote at all - I.e. the only benefit of karma my package receive is them being delayed and occasionally outdated before they are released. > Calling a process bureaucratic doesn't necessarily > move the discussion forward in a positive manner. I disagree, but I am not naive enough to assume the "officer" who processes the bureaucracy to understand the detrimental effects and overhead he adds. I only played nice to it this time, because this allowed us to escape the delays and to achieve mostly the same effect as "a push to stable". A functional "push to stable" would have had the same effect, w/ and w/o karma. 'nough said. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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/mailman/listinfo/perl-devel
Re: Procedure to push a package causing broken deps to f15?
- Original Message -
> From: "Kevin Kofler"
> To: devel@lists.fedoraproject.org
> Sent: Wednesday, February 16, 2011 10:55:26 AM
> Subject: Re: Procedure to push a package causing broken deps to f15?
> Marcela Mašláňová wrote:
> > I completely agree.
> >
> > At least nag-mails about the broken dependencies (because of
> > rpm-4.9)
> > should be delivered sooner or we should wait with branching or do
> > mass-rebuild sooner. Now we have to build everything for F-{15,16}
> > and
> > even wait for testing, which is ridiculous in this case. It's only
> > delay
> > fixing of broken deps.
>
> Well, I proposed a way to fix the procedure:
> http://lists.fedoraproject.org/pipermail/devel/2011-February/148604.html
>
As Ralf said before, the same problem will be with beta. I'd like to see
some changes here, at least be more flexible before branching and go
through number of broken builds/requirements.
> What do you think of that? Would you vote for that proposal if I filed
> a
> FESCo ticket for it? Do you think it'd have a chance to pass quorum?
>
Do not need push updates through bodhi in beta would be nice, but I don't
think this proposal can pass in FESCo.
btw I don't be there today.
> Kevin Kofler
>
--
Marcela Mašláňová
BaseOS team Brno
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundling binary allowed for bootstrapping?
On 02/16/2011 04:35 PM, Rex Dieter wrote: > Stanislav Ochotnicky wrote: > >> Hi everyone, >> >> We will need to package sonatype-tycho[1] sooner or later for building >> eclipse. I started looking into it a little bit and it seems things >> would be much, much more simple if I was able to bundle current binary >> release of tycho (or probably just some part of it) temporarily to build >> "our" tycho binary. >> >> I have a faint memory of something like this being allowed, but I can't >> find the guideline about it so maybe I remember wrong. Current bundling >> guidelines[2] doesn't mention bootstrapping at all. Any input on this? > > covered here: > http://fedoraproject.org/wiki/Packaging/Guidelines#No_inclusion_of_pre- > built_binaries_or_libraries > In particular, > http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions Ah, my bad. I was searching for word bundle in the page :-) Thanks, I'll get in touch with FPC. -- Stanislav Ochotnicky Associate Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundling binary allowed for bootstrapping?
Stanislav Ochotnicky wrote: > Hi everyone, > > We will need to package sonatype-tycho[1] sooner or later for building > eclipse. I started looking into it a little bit and it seems things > would be much, much more simple if I was able to bundle current binary > release of tycho (or probably just some part of it) temporarily to build > "our" tycho binary. > > I have a faint memory of something like this being allowed, but I can't > find the guideline about it so maybe I remember wrong. Current bundling > guidelines[2] doesn't mention bootstrapping at all. Any input on this? covered here: http://fedoraproject.org/wiki/Packaging/Guidelines#No_inclusion_of_pre- built_binaries_or_libraries In particular, http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 677799] Broken dependency: perl-DateTime-Format-Mail-0.3001-9.fc15.noarch requires perl(DateTime) >= 0:0.1705
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=677799 --- Comment #7 from James Laska 2011-02-16 09:52:02 EST --- (In reply to comment #5) > The update was pushed to stable overnight. Great, thanks Paul! (In reply to comment #6) > (In reply to comment #4) > > Well, not *easily* ... but the AutoQA [1] folks are working on it. > Meanwhile switch off this silly delay queue - Whether you like it or not, it > has never worked, not even in f13 and f14 ... it's just that the "broken mass > merger" is exposing the delay queue's detrimental effect to a wider audience. The "delay" as you call it, has worked quite nicely during Fedora 14 stabilization. As maintainer, you might not have exposure to the numerous pain points we experience when trying to assemble a distribution full of interdependent moving targets. As a Fedora user+contributor, I'm sure you are aware of the issues we encounter leading up to release milestones. While the Karma system isn't perfect, and there are always improvements that could be made, it has been a life saver to allow us to more consistently release Fedora on time. Calling a process bureaucratic doesn't necessarily move the discussion forward in a positive manner. We need ideas to improve our tools and process, but simply removing it without a review of the problem space isn't an option. Of course, apologies to Paul ... this isn't germane to this specific bug report. Ralf, as you've already done, feel free to continue discussion on test@ or devel@. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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/mailman/listinfo/perl-devel
Re: GitHub Hosted upstream 'Source0'
On 02/16/2011 03:36 PM, Matej Cepl wrote: > Dne 16.2.2011 11:06, Stanislav Ochotnicky napsal(a): >>> Which basically takes the tag name and creates a nice tarball from it. >> >> Although I should pipe it through gzip/bzip2 :-/ > > And you really don't resolve the issue with unstable MD5 checksum. Why would that be? I am creating the tarball from the same git tag. Yes I am using tag name, so theoretically if upstream is ugly enough to overwrite their tags with different contents, this will be a problem. But normally I can re-create the tarball using "git archive" and the md5 checksum will stay the same. Can you tell me how exactly this won't work? -- Stanislav Ochotnicky Associate Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Statistics-Basic/f15/master] Version unversioned Provides
Summary of changes: b726c4f... Version unversioned Provides (*) (*) This commit already existed in another branch; no separate mail sent -- 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/mailman/listinfo/perl-devel
[perl-Statistics-Basic] Version unversioned Provides
commit b726c4fff260faa5416910370bb7ac454e358d48
Author: Petr Písař
Date: Wed Feb 16 15:42:06 2011 +0100
Version unversioned Provides
perl-Statistics-Basic.spec |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
---
diff --git a/perl-Statistics-Basic.spec b/perl-Statistics-Basic.spec
index 4fd9759..c551dd4 100644
--- a/perl-Statistics-Basic.spec
+++ b/perl-Statistics-Basic.spec
@@ -1,6 +1,6 @@
Name: perl-Statistics-Basic
Version:1.6602
-Release:2%{?dist}
+Release:3%{?dist}
Summary:A collection of very basic statistics modules
License:LGPLv2+
Group: Development/Libraries
@@ -19,6 +19,7 @@ Requires: perl(Number::Format) >= 1.42
# Remove underspecified dependecies
%filter_from_requires /^perl(Number::Format)$/d
+%filter_from_provides s/^\(perl(Statistics::Basic\>[^=]*\)$/\1 = %{version}/
%filter_setup
%description
@@ -56,6 +57,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Feb 16 2011 Petr Pisar - 1.6602-3
+- Version unversioned Provides
+
* Wed Feb 09 2011 Fedora Release Engineering
- 1.6602-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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/mailman/listinfo/perl-devel
Re: F-15 Branched report: 20110215 changes
On Wed, Feb 16, 2011 at 15:14:06 +0100, Tim Niemueller wrote: > On 16.02.2011 00:01, Branched Report wrote: > > Compose started at Tue Feb 15 13:15:48 UTC 2011 > > > > Broken deps for x86_64 > > -- > > urg-0.8.7-4.fc15.i686 requires libboost_filesystem-mt.so.1.44.0 > > urg-0.8.7-4.fc15.x86_64 requires > > libboost_filesystem-mt.so.1.44.0()(64bit) > > I have built updated packages for this one and filed an update request > but it didn't appear in days. What's the proper way on getting it in? First you request a push to testing in bodhi and after reaching target karma or a timeout (if not critpath), you request a push to stable. Once the push to stable happens it will be in next compose to start. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub Hosted upstream 'Source0'
Dne 16.2.2011 11:06, Stanislav Ochotnicky napsal(a): >> Which basically takes the tag name and creates a nice tarball from it. > > Although I should pipe it through gzip/bzip2 :-/ And you really don't resolve the issue with unstable MD5 checksum. Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide is annoying me!
Dne 16.2.2011 09:38, Matej Cepl napsal(a):
> Looks like a bad bug I was hit by as well. Try to comment out putting
> clock on the gnome-shell black panel on the top in
> /usr/share/gnome-shell/js/ui/panel.js (see attached patch). Does it help?
and the second time with patch actually attached.
Matěj
--- panel.js.orig 2011-02-16 09:35:49.798554079 +0100
+++ panel.js 2011-02-16 09:34:37.400880195 +0100
@@ -688,10 +688,10 @@
this._menus.addMenu(appMenuButton.menu);
-/* center */
-this._dateMenu = new DateMenu.DateMenuButton();
-this._centerBox.add(this._dateMenu.actor, { y_fill: true });
-this._menus.addMenu(this._dateMenu.menu);
+// /* center */
+// this._dateMenu = new DateMenu.DateMenuButton();
+// this._centerBox.add(this._dateMenu.actor, { y_fill: true });
+// this._menus.addMenu(this._dateMenu.menu);
/* right */
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
libstdc++ crash in Fedora 15
In Fedora 15 development only, not reproducible with Fedora 14: Could you help classifying the following backtrace? https://bugzilla.redhat.com/attachment.cgi?id=473671 It's related to dlopening a shared lib and crashes during initialization of static members. ( https://bugzilla.redhat.com/669889 ) Would be great to get confirmation whether it's a problem outside the shared lib that's loaded. More details in the bz ticket. [...] Thread 1 (Thread 0x7fed6aea9820 (LWP 2171)): #0 0x7fed52eaf628 in construct (__val=@0x10, __p=0x1521910, this=) at /usr/include/c++/4.5.1/ext/new_allocator.h:105 No locals. #1 _M_create_node (__x=@0x10, this=) at /usr/include/c++/4.5.1/bits/stl_list.h:464 __p = 0x1521900 #2 _M_insert (__x=@0x10, __position=, this=) at /usr/include/c++/4.5.1/bits/stl_list.h:1434 __tmp = #3 push_back (__x=@0x10, this=0x7fed530fbb30) at /usr/include/c++/4.5.1/bits/stl_list.h:921 No locals. #4 _M_initialize_dispatch > (__last=, this=0x7fed530fbb30, __first=) at /usr/include/c++/4.5.1/bits/stl_list.h:1388 No locals. #5 list (__x=, this=0x7fed530fbb30) at /usr/include/c++/4.5.1/bits/stl_list.h:533 No locals. #6 CPlayers (this=0x7fed530fbb30) at core/players.h:54 No locals. #7 __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at adplug-xmms.cc:80 No locals. --more via link above-- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-15 Branched report: 20110215 changes
On 16.02.2011 00:01, Branched Report wrote: > Compose started at Tue Feb 15 13:15:48 UTC 2011 > > Broken deps for x86_64 > -- > urg-0.8.7-4.fc15.i686 requires libboost_filesystem-mt.so.1.44.0 > urg-0.8.7-4.fc15.x86_64 requires > libboost_filesystem-mt.so.1.44.0()(64bit) I have built updated packages for this one and filed an update request but it didn't appear in days. What's the proper way on getting it in? Thanks, Tim -- Tim Niemueller www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Test-Announce] Fedora 15 Alpha TC2 Available Now!
Chris Adams writes: > Hmm, also what does this do to PXE booting. IIRC there is a (relatively > low) limit on the size of the initrd loaded by pxelinux. Even if there is no limit, fetching large files over TFTP can be rather slow. The initrd seems to be 135MB right now, which seems to be on the high side. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arista Transcoder update?
On 02/16/2011 03:23 PM, valent.turko...@gmail.com wrote: > I know that the ansswer is always to shift package ownership to some > new blood, but I can't handle it. I'm weeky behind on releasing Fusion > Linux that is my primary focus so taking any additional stuff is not > realistic because I almost have no free time just by doing Fusion > Linux Remix. The point is that if you help out with maintaining a few packages in Fedora, you get to fix bugs etc that is of priority for you in the remix effort instead of always relying of someone else to help you with it. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub Hosted upstream 'Source0'
I ran into Github-related issues as well and filed a bug report: http://support.github.com/discussions/repos/4565-sha-in-download-filename-does-not-match-directory You can simply append the filename to the URL and it'll work, I'm using this for example in http://pkgs.fedoraproject.org/gitweb/?p=lua-xmlrpc.git;a=blob;f=lua-xmlrpc.spec;h=7ab862ae4d5059dca5cdce1dee7c532e4b8921de;hb=HEAD The remaining problem really is the one filed above and some more people watching and commenting the issue could bring it higher up on the priority list. Tim -- Tim Niemueller www.niemueller.de = Imagination is more important than knowledge. (Albert Einstein) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Procedure to push a package causing broken deps to f15?
On 02/16/2011 10:55 AM, Kevin Kofler wrote:
> Marcela Mašláňová wrote:
>> I completely agree.
>>
>> At least nag-mails about the broken dependencies (because of rpm-4.9)
>> should be delivered sooner or we should wait with branching or do
>> mass-rebuild sooner. Now we have to build everything for F-{15,16} and
>> even wait for testing,
The real problem behind all this is these packages having made it into
f15 - This should not have happened, QA should have caught them earlier,
should have fixed them or at least have informed these packages' owners.
>> which is ridiculous in this case. It's only delay
>> fixing of broken deps.
Agreed, Note my wording: I call this a "delay queue", not a "QA input
queue", because it's effectively a mere delay queue without any
> Well, I proposed a way to fix the procedure:
> http://lists.fedoraproject.org/pipermail/devel/2011-February/148604.html
>
> What do you think of that?
Well, then the same will happen with the beta freeze.
To me, the key would be not to let packages causing broken deps into the
repos. QA should preform an analysis on how they made it into the repos
(In my understanding, the cause this time, was an improperly merged
last-minute mass rebuild of the perl-modules, which due to a change in
rpm's dep-tracking is causing broken deps).
That said, I would propose to immediately push package updates for f15
to testing (spares ca. 24 hours of delay) and to reduce the
"testing->stable" push delay to 24 hours or less.
Ralf
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub Hosted upstream 'Source0'
Dne 16.2.2011 02:24, Tom Lane napsal(a):
> Ken Dreyer writes:
>> On Tue, Feb 15, 2011 at 4:22 PM, BJ Dierkes
>> wrote:
>>> I'm wondering how other people have resolved these issues for projects using
>>> GitHub as the upstream Source0 download provider.
>>> Finally, debian has a web app to resolve these issues at:
>>> http://githubredir.debian.net/
>> Cool idea, although it feels a bit like using some sort of URL
>> shortener. I wish GitHub would just fix their stuff.
> Seems like really we should lobby GitHub to provide download URLs that
> specify the full file name. There's no advantage to the way they are
> doing it, AFAICS, and it's not obvious what file format you will get
> from their URLs. ("zipball" seems a particularly poor choice here
> --- personally I'd have thought it meant a .zip archive ...)
>
> regards, tom lane
Have you already asked GitHub or is it just what we should? Also Kevin
notes should be mentioned. I believe they can do something about it.
Vit
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Bundling binary allowed for bootstrapping?
Hi everyone, We will need to package sonatype-tycho[1] sooner or later for building eclipse. I started looking into it a little bit and it seems things would be much, much more simple if I was able to bundle current binary release of tycho (or probably just some part of it) temporarily to build "our" tycho binary. I have a faint memory of something like this being allowed, but I can't find the guideline about it so maybe I remember wrong. Current bundling guidelines[2] doesn't mention bootstrapping at all. Any input on this? [1] https://github.com/sonatype/sonatype-tycho [2] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries -- Stanislav Ochotnicky Associate Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub Hosted upstream 'Source0'
On 02/16/2011 10:55 AM, Stanislav Ochotnicky wrote:
> On 02/16/2011 12:22 AM, BJ Dierkes wrote:
>> Hello all,
>>
>> I hope I am not the first to come across packaging issues for projects that
>> use GitHub as their upstream source download. For those not familiar,
>> GitHub dynamically generates downloads for all git 'tags'. So for example:
>>
>> $ git tag -a -m 'Tagging 1.0.0' 1.0.0
>>
>>
>> This would create a tag of '1.0.0' in git. On GitHub, this tag would be
>> 'downloadable' via a dynamic app such as:
>>
>> https://github.com/derks/myapp/zipball/1.0.0
>>
>>
>> This is the upstream URL that a lot of GitHub users are providing rather
>> than a direct download link. Unfortunately the above is not usable by RPM
>> because rpmbuild expects the URL to end with the file. If I were to use the
>> above in my spec, I would get an error saying something to the affect of
>> 'unknown source file 1.0.0'. Additionally, the tarbal that is created looks
>> like:
>>
>> myapp-1.0.0-XXX.tar.gz
>>
>>
>> Where XXX is the last bit of the git commit hash id... which cause yet
>> another pain in that... you need to update this commit revision every time
>> you update the spec... and it just makes things a bit less fluid. I'm
>> wondering how other people have resolved these issues for projects using
>> GitHub as the upstream Source0 download provider.
>>
>> Finally, debian has a web app to resolve these issues at:
>>
>> http://githubredir.debian.net/
>>
>>
>> What would be the thoughts of using that to produce more sane/traditional
>> tarbals of upstream GitHub source?
>>
>
> What I am using in my spec files is something like this:
> # git clone git://github.com/sonatype/sisu
> # git archive --prefix="sonatype-sisu-1.4.3.2/" --format=tar \
> # sisu-1.4.3.2 > sisu-1.4.3.2.tar.gz
> Source0:%{name}-%{version}.tar.gz
>
> Which basically takes the tag name and creates a nice tarball from it.
Although I should pipe it through gzip/bzip2 :-/
--
Stanislav Ochotnicky
Associate Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Catalyst-Controller-FormBuilder] fix filter for RPM4.9
commit c85af32b52a9e207e2631d77ef6ed9bab54c75e7
Author: Marcela Mašláňová
Date: Wed Feb 16 10:56:57 2011 +0100
fix filter for RPM4.9
perl-Catalyst-Controller-FormBuilder.spec | 38 ++---
1 files changed, 13 insertions(+), 25 deletions(-)
---
diff --git a/perl-Catalyst-Controller-FormBuilder.spec
b/perl-Catalyst-Controller-FormBuilder.spec
index 4ba7f30..39b68b7 100644
--- a/perl-Catalyst-Controller-FormBuilder.spec
+++ b/perl-Catalyst-Controller-FormBuilder.spec
@@ -1,6 +1,6 @@
Name: perl-Catalyst-Controller-FormBuilder
Version:0.05
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Catalyst FormBuilder Base Controller
License:GPL+ or Artistic
Group: Development/Libraries
@@ -37,36 +37,21 @@ Catalyst and the following templating systems: Template
Toolkit, Mason and
HTML::Template. This gives you access to all of FormBuilder's niceties,
such as controllablefield stickiness, multilingual support, and Javascript
generation. For more details, see CGI::FormBuilder or the website at:
+http://www.formbuilder.org
-http://www.formbuilder.org
+
+%{?filter_setup:
+%filter_from_requires /perl(FindBin)/d; /perl(Test::.*)/d
+%filter_from_requires /perl(Catalyst::View::HTML::Template)/d
+%filter_from_provides /perl(TestApp.*)/d
+
+%{?perl_default_filter}
+}
%prep
%setup -q -n Catalyst-Controller-FormBuilder-%{version}
%patch0
-find . -type f -exec chmod -x -c {} +
-
-# Filter unwanted Provides:
-cat << \EOF > %{name}-prov
-#!/bin/sh
-%{__perl_provides} $* |\
- sed -e '/perl(TestApp.*)/d'
-EOF
-
-%define __perl_provides
%{_builddir}/Catalyst-Controller-FormBuilder-%{version}/%{name}-prov
-chmod +x %{__perl_provides}
-
-
-# Filter unwanted Requires:
-cat << \EOF > %{name}-req
-#!/bin/sh
-%{__perl_requires} $* |\
- sed -e '/perl(FindBin)/d; /perl(Test::.*)/d'
-EOF
-
-%define __perl_requires
%{_builddir}/Catalyst-Controller-FormBuilder-%{version}/%{name}-req
-chmod +x %{__perl_requires}
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -94,6 +79,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Wed Feb 16 2011 Marcela Mašláňová - 0.05-8
+- fix filter for RPM4.9
+
* Tue Feb 08 2011 Fedora Release Engineering
- 0.05-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
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/mailman/listinfo/perl-devel
Re: Procedure to push a package causing broken deps to f15?
Marcela Mašláňová wrote:
> I completely agree.
>
> At least nag-mails about the broken dependencies (because of rpm-4.9)
> should be delivered sooner or we should wait with branching or do
> mass-rebuild sooner. Now we have to build everything for F-{15,16} and
> even wait for testing, which is ridiculous in this case. It's only delay
> fixing of broken deps.
Well, I proposed a way to fix the procedure:
http://lists.fedoraproject.org/pipermail/devel/2011-February/148604.html
What do you think of that? Would you vote for that proposal if I filed a
FESCo ticket for it? Do you think it'd have a chance to pass quorum?
Kevin Kofler
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub Hosted upstream 'Source0'
On 02/16/2011 12:22 AM, BJ Dierkes wrote:
> Hello all,
>
> I hope I am not the first to come across packaging issues for projects that
> use GitHub as their upstream source download. For those not familiar, GitHub
> dynamically generates downloads for all git 'tags'. So for example:
>
> $ git tag -a -m 'Tagging 1.0.0' 1.0.0
>
>
> This would create a tag of '1.0.0' in git. On GitHub, this tag would be
> 'downloadable' via a dynamic app such as:
>
> https://github.com/derks/myapp/zipball/1.0.0
>
>
> This is the upstream URL that a lot of GitHub users are providing rather than
> a direct download link. Unfortunately the above is not usable by RPM because
> rpmbuild expects the URL to end with the file. If I were to use the above in
> my spec, I would get an error saying something to the affect of 'unknown
> source file 1.0.0'. Additionally, the tarbal that is created looks like:
>
> myapp-1.0.0-XXX.tar.gz
>
>
> Where XXX is the last bit of the git commit hash id... which cause yet
> another pain in that... you need to update this commit revision every time
> you update the spec... and it just makes things a bit less fluid. I'm
> wondering how other people have resolved these issues for projects using
> GitHub as the upstream Source0 download provider.
>
> Finally, debian has a web app to resolve these issues at:
>
> http://githubredir.debian.net/
>
>
> What would be the thoughts of using that to produce more sane/traditional
> tarbals of upstream GitHub source?
>
What I am using in my spec files is something like this:
# git clone git://github.com/sonatype/sisu
# git archive --prefix="sonatype-sisu-1.4.3.2/" --format=tar \
# sisu-1.4.3.2 > sisu-1.4.3.2.tar.gz
Source0:%{name}-%{version}.tar.gz
Which basically takes the tag name and creates a nice tarball from it.
--
Stanislav Ochotnicky
Associate Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
signature.asc
Description: OpenPGP digital signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Arista Transcoder update?
On Mon, Feb 14, 2011 at 5:39 PM, Rahul Sundaram wrote: > On 02/12/2011 07:10 PM, valent.turko...@gmail.com wrote: >> Any chance of finishing Arista Transcoder review process? It is a >> great app that makes transcoding a breeze so it would be great win for >> Fedora users to have it in the repos. >> >> I tested Arista and I updated review ticket: >> https://bugzilla.redhat.com/show_bug.cgi?id=502477 >> >> Hope my input helps Arista gets into the repos. > > Not really. You should file bug reports upstream and not in a package > review. Upstream hasn't really responded much the last I was working on > it and I haven't had the time to look into it recently. If you want to > take over the package and maintain in Fedora, you are welcome to close > the one I have filed and file a new ticket yourself. That would help > it get into the repository. > > Rahul I know that the ansswer is always to shift package ownership to some new blood, but I can't handle it. I'm weeky behind on releasing Fusion Linux that is my primary focus so taking any additional stuff is not realistic because I almost have no free time just by doing Fusion Linux Remix. Hope somebody else takes it over from you. I found some bugs by manually compiling and running Arista and I'll file those bugs to upstream. That is the most I can pledge to do realistically. 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.turko...@hotmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GitHub Hosted upstream 'Source0'
BJ Dierkes wrote: > What would be the thoughts of using that to produce more sane/traditional > tarbals of upstream GitHub source? It doesn't fix the third, and main, issue: GitHub-generated tarballs get a new checksum each time they're regenerated (because some file dates change). This makes them completely unverifiable. (This also goes for other "generate tarball from tag" services, e.g. BitBucket.) The only reasonable thing to do there is really to have upstream upload a real, verifiable tarball (explaining the above issue to them). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Procedure to push a package causing broken deps to f15?
On 16/02/11 09:39, Peter Robinson wrote: > On Wed, Feb 16, 2011 at 7:46 AM, Paul Howarth wrote: >> On Mon, 14 Feb 2011 11:51:21 -0600 >> Bruno Wolff III wrote: >> >>> On Mon, Feb 14, 2011 at 18:35:54 +0100, >>>Ralf Corsepius wrote: I was looking into fixing the 10-15 perl-packages, which have made it into current f15, even though they carry broken deps. Waiting the usual 8-10 days of delay is not helpful for such cases, because they will cause f15 to remain broken for at minimum this delay time (Which in case of dep chains, can easily evolve to several weeks [1]). >>> >>> The policy is at http://www.fedora.redhat.com/wiki/Updates_Policy. >>> For branched (pre-beta) you only need to wait three days if you get >>> no karma and it isn't critpath. You can set the karma required to one >>> and get someone else to do a test and sign off on it and move it to >>> stable right after that. >> >> I just tried marking >> https://admin.fedoraproject.org/updates/perl-Net-SSH-Perl-1.34-11.fc15 >> as stable; it's been in testing for 3 days and 4 hours now so I >> expected it to work but was told by bodhi that it hadn't been in >> testing for the required period yet. Does bodhi know that the pre-beta >> testing period is a minimum of 3 days rather than 7? > > Its the date that its pushed to testing not the date its submitted. I know. It was pushed to testing on 2011-02-13 at 03:23:21 and I tried to mark it stable on 2011-02-16 at 07:40:00 (+3 days and 4 hours). > Looking at it now it has a message that it can be pushed to stable. That's because Ralf has since tested it and given it karma to make it to the stable threshold (thanks Ralf). Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Procedure to push a package causing broken deps to f15?
On Wed, Feb 16, 2011 at 7:46 AM, Paul Howarth wrote: > On Mon, 14 Feb 2011 11:51:21 -0600 > Bruno Wolff III wrote: > >> On Mon, Feb 14, 2011 at 18:35:54 +0100, >> Ralf Corsepius wrote: >> > >> > I was looking into fixing the 10-15 perl-packages, which have made >> > it into current f15, even though they carry broken deps. Waiting >> > the usual 8-10 days of delay is not helpful for such cases, because >> > they will cause f15 to remain broken for at minimum this delay time >> > (Which in case of dep chains, can easily evolve to several weeks >> > [1]). >> >> The policy is at http://www.fedora.redhat.com/wiki/Updates_Policy. >> For branched (pre-beta) you only need to wait three days if you get >> no karma and it isn't critpath. You can set the karma required to one >> and get someone else to do a test and sign off on it and move it to >> stable right after that. > > I just tried marking > https://admin.fedoraproject.org/updates/perl-Net-SSH-Perl-1.34-11.fc15 > as stable; it's been in testing for 3 days and 4 hours now so I > expected it to work but was told by bodhi that it hadn't been in > testing for the required period yet. Does bodhi know that the pre-beta > testing period is a minimum of 3 days rather than 7? Its the date that its pushed to testing not the date its submitted. Looking at it now it has a message that it can be pushed to stable. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Procedure to push a package causing broken deps to f15?
On 02/14/2011 06:35 PM, Ralf Corsepius wrote:
> On 02/14/2011 06:18 PM, Tom Callaway wrote:
>> On 02/14/2011 11:58 AM, Ralf Corsepius wrote:
>>> Hi,
>>>
>>> What is the procedure to push a package, which currently is causing
>>> broken deps in f15 to f15 as fast as possible?
>>>
>>> Though bodhi offers a "push to stable", it seems to ignore this and
>>> converts it to "push to testing".
>>>
>>> Are we supposed to wait the usual package update delays for f15
>>> packages, as well, even if they are such kind of critical as broken
>>> package deps?
>> If you're fixing a chain of dependencies, you can request a buildroot
>> override to build the chain, then push them all as a single update.
>>
>> It's not exactly what you asked for, but it is better than one update at
>> a time.
> Correct, that's not what I asked for.
>
> I was looking into fixing the 10-15 perl-packages, which have made it
> into current f15, even though they carry broken deps. Waiting the usual
> 8-10 days of delay is not helpful for such cases, because they will
> cause f15 to remain broken for at minimum this delay time (Which in case
> of dep chains, can easily evolve to several weeks [1]).
>
> Ralf
>
> [1] A similar consideration applies to fixing bugs in F13/f14, when the
> bug fix candidate pulls in a lengthy dependency chain (not uncommon with
> perl-modules).
>
I completely agree.
At least nag-mails about the broken dependencies (because of rpm-4.9)
should be delivered sooner or we should wait with branching or do
mass-rebuild sooner. Now we have to build everything for F-{15,16} and
even wait for testing, which is ridiculous in this case. It's only delay
fixing of broken deps.
Marcela
--
Marcela Mašláňová
BaseOS team Brno
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide is annoying me!
Dne 7.2.2011 05:12, David napsal(a): > I switched to XFCE two months, maybe longer ago, whenever it was that > this Gnome 3 or gnome-shell 'thing' first appeared in Rawhide. Why? > Becasue it broke my desktop. Actually I am not exactly sure why but I > know that I need *real* Nvidia drivers for my reasonably modern GeForce > 5800 GTX card to work properly. The Linux drivers do not work as they > should. For me. And something about the version of Xorg and this, or a > combination of theses, makes major problems for me. Broke my desktop and > the general Gnome 'expected to work things'. Putting aside my disgust for nvidia binary blob (I understand it is unfortunately part of our current reality), why do you think gnome-shell shouldn't work with it? Or is there other problem why gnome-shell doesn't work for you? Which ones? Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide is annoying me!
Dne 5.2.2011 19:01, Paul F. Johnson napsal(a): > Problem 2 (laptop). Gnome is dead. I can use KDE for my desktop but > gnome, irrespective of the user, gives me a blue stripy screen and > that's it. I've tried creating a new user in case it was my settings, > but nope, blue stripy screen. I am not sure if it's related to gnome-do > (I installed it, didn't like it, yum removed it) removing something it > shouldn't have, but it does mean my laptop, unless using KDE, is no use. Looks like a bad bug I was hit by as well. Try to comment out putting clock on the gnome-shell black panel on the top in /usr/share/gnome-shell/js/ui/panel.js (see attached patch). Does it help? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
