Re: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 8:46 am, Scott Talbert wrote:

On Mon, 11 Nov 2019, Scott Talbert wrote:


Ouch.  So now you're talking about wanting to package a *fork* of a 
development release of wxGTK.
No. (unless it was done by simply turning on a config item). Looking 
closer, building audacity requires an already built wxGTK/dev, which is 
a separate process. I'm not sure the Fedora packaging system could even 
do that - build a build requires from a bundled lib, and then install it 
before the main application build ?




I would strongly suggesting talking to Audacity team about why they
need a fork of wx 3.1.x and why they cannot get their fixes/changes
upstreamed (and backported to wx 3.0). Upstream wx is usually
pretty good about backporting fixes to 3.0 if you request it.


I just took a quick look at the changes in their wx 3.1.1 fork.  It 
appears they are all Windows and Mac related.  So, their instructions to 
use their fork when building on Linux make no sense.
Interesting... and is there any difference between 3.0.4 and what they 
have as 3.1.1 ?



I would recommend doing as Kevin suggested and continue to build against 
wx 3.0.4 in Fedora.  If you run into a bug that has been fixed in wx 
3.1.x, feel free to report it and we will get the fix backported.


While the above is what I've already done locally and what I'll do...

I think it's a good idea to make available these (advanced) build 
environments, without requiring a whole "rawhide" machine to do this on 
(which currently still only has the old version anyway).


Don't we want to make it easier for all sorts of people to contribute to 
open source development. Modules sound like an easy way for that to 
happen (for the user of the module). We need tester's and developers 
using future "pieces" that interest them without foregoing an otherwise 
stable machine.


And this usage can be the impetus that allows library development to be 
well tested by multiple real applications and issues 
known/fixes/improvements in place before the library hardens it's 
ABI/API interfaces at the release.


In this case extending this idea to also make other Fedora packaged, 
wxGTK3 using applications [1] built with the (hopefully soon) to be 
released library would allow more thorough testing of the library, and 
give us ahead of time the things that need work - in either the library 
or the applications.



Given it would be me doing the work - although I'll need some guidance - 
are any guidelines etc. actually being broken if I was to do the 
modularity thing for wxGTK/Audacity ?


ps. I haven't come across the docs on the packaging side of modules - 
any pointers, please ?


Dave.

[1] https://paste.fedoraproject.org/paste/nAopftRQuTcxokDbHP~nkw
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 8:05 am, David Timms wrote:
Audacity support when my users crash because they aren't running the 
recommended library (there is other locally adjusted libs which Audacity 
uses). Not that this is different from the past - but I would like it to 

oops, dropped word this is "no" different !
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 1:33 am, Fabio Valentini wrote:
On Mon, Nov 11, 2019, 15:09 Vít Ondruch <mailto:vondr...@redhat.com>> wrote:


Dne 11. 11. 19 v 14:39 Kevin Kofler napsal(a):
     > David Timms wrote:
 >> I would like to be able to release the next Audacity (once
tested) when
 >> it drops.
 > I would recommend against doing that (unless you can get it to
build against
 > wxGTK 3.0 after all). Please wait until wxGTK 3.2 is actually
stable and
 > available in Fedora.

In the mean time, you can use Copr to provide updated wxGTK + Audacity.
Keeping the resolution of possible conflicts on the users.

Vít

I think the easiest solution would be to introduce a wxGTK "compat 
package" for 3.1, assuming it wouldn't conflict with the stable 
versions, and provide both the compat package and audacity builds based 
on it via COPR for testing.


https://trac.wxwidgets.org/wiki/Roadmap

Perhaps calling a compat package 3.2.0.develseries.3.1.3 etc would make 
sense to indicate to consumers that they are using what will soon (TM) 
become the main version.


Dave.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 1:51 am, Scott Talbert wrote:

On Mon, 11 Nov 2019, David Timms wrote:


Issue:
Audacity development (git) requires linking against wxGTK3.1.
The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2 
release.

Upstream is currently at 3.1.3 and expecting at least a 3.1.4 next year.
Audacity 2.3.3 release is imminent (RC02).


Hi, one of the wxGTK maintainers here.  Where is the requirement to use 
wxGTK 3.1 documented?  Like Kevin, I can't find that documented.  And if 
it is definitely required, *why* is it required?


I would like to be able to release the next Audacity (once tested) 
when it drops.


I've been reading about Fedora modules, and am wondering whether the 
following would make sense as a potential solution ?:


$ dnf  modules  list  wxGTK3


I would be strongly opposed to using a module for this.  If you 
absolutely *must* have wx 3.1, we should just use a regular 
(non-modular) package. Note that we've already had one request for wx 
3.1 [1], but I've been hesitant to package it since it has unstable 
API/ABI and we typically don't package development releases.


Can you provide amplifying information on the wx 3.1 requirement from 
audacity first?
See earlier, and I'm not sure how realistic this web analysis tool is... 
I don't think it's the same one I've used before:

https://abi-laboratory.pro/index.php?view=timeline&l=wxwidgets

Dave.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 2:36 am, Christopher Engelhard wrote:

On 11/11/2019 3:51 PM, Scott Talbert wrote:
 > Hi, one of the wxGTK maintainers here.  Where is the requirement to use
 > wxGTK 3.1 documented?  Like Kevin, I can't find that documented.  
And if

 > it is definitely required, *why* is it required?

Because it fixes many issues with the earlier version.


On Archlinux audacity-git [1] builds against the default repo version of
wxGTK, i.e. 3.0.4, so it does not seem to be required.
It can in fact build against it - but then shows all the bugs that 
building against the old wxGTK entails. It means I can't get upstream 
Audacity support when my users crash because they aren't running the 
recommended library (there is other locally adjusted libs which Audacity 
uses). Not that this is different from the past - but I would like it to be.


Cheers, Dave.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

On 12/11/19 12:39 am, Kevin Kofler wrote:

David Timms wrote:

Audacity development (git) requires linking against wxGTK3.1.


Does it really? I cannot find this requirement in their git repository.

see: https://wiki.audacityteam.org/wiki/Building_On_Linux
or from the horse - (Mr Ed):
https://github.com/audacity/audacity/blob/master/linux/build.txt
"
wxWidgets:

 1) Clone wxWidgets and checkout 3.1.1 from the Audacity fork of the
wxWidgets project:
   https://github.com/audacity/wxWidgets/
"

I missed the fact that they build against their fork of wxWidgets from 
their own repo; I'm not sure whether it started as 3.1.1 or not.




The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2
release. Upstream is currently at 3.1.3 and expecting at least a 3.1.4
next year. Audacity 2.3.3 release is imminent (RC02).


Ewww! Why is nobody complaining to Audacity upstream about that (assuming
that they really do require 3.1)? Requiring an unreleased/unstable wxGTK (I
would not count a development release as "released") makes no sense
whatsoever for a stable release of Audacity. Why are they not maintaining a
stable branch based on a stable wxGTK release? They should.

I found out yesterday, and that's why I'm trying to find most suitable way.


I would like to be able to release the next Audacity (once tested) when
it drops.


I would recommend against doing that (unless you can get it to build against
wxGTK 3.0 after all). Please wait until wxGTK 3.2 is actually stable and
available in Fedora.
Well, ... it does build and run against 3.0.4, but lots of "already 
fixed" - in wxGTK - issues are present.


I would prefer to follow Audacity teams requirements, as otherwise any 
issue reported in Fedora - I get the "did you build it like we said ?" 
response.



I've been reading about Fedora modules, and am wondering whether the
following would make sense as a potential solution ?:

$ dnf  modules  list  wxGTK3

Fedora Modular 30 - x86_64
Name Stream   Profiles Summary
wxGTK3   3.1.n-unstable   default [d], devel   GTK wxWidgets GUI library


No, that would be a very bad idea, because it means Audacity would then
conflict with all other wxGTK applications, or at least force them to run
with the unstable wxGTK with which they were not tested (depending on
whether wxGTK 3.1 is binary-backwards-compatible with 3.0 or not).
But if my user's "must" have the latest Audacity, and don't care about 
any other WxGTK3 using software, shouldn't this be my user's choice to 
make ?

It seems that modules would allow it.

Modules are always the wrong solution for libraries because they are 

Isn't that exactly what the module examples are doing ?


not parallel-installable.

Agreed, I got that much from the reading I've done on modules.


If the module was setup like this, then could the normal repo
audacity.spec package:
BuildRequires: wxGTK3:3.1.n-unstable/devel

Requires: does this get sorted out magically like in a normal package ?


No, building against a module does not work like that, it is more
complicated. But a module is a bad idea anyway, see above.

Where can I find information on using a module in another package ?


As I'm not on the wxGTK3 package team, can I do this without their
approval/assistance ?


No, you definitely need to find a solution together with them.
First step completed: Scott says he is on the wxGTK maintainers team, 
and thanks everyone for your responses so far.


Dave
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Potential module for wxGTK3.1 unstable series / Audacity

[David Timms]

Issue:
Audacity development (git) requires linking against wxGTK3.1.
The normal Fedora wxGTK3 package is at wxGTK3-3.04 in F29/30/31/devel.
wxGTK3.1 is a development series which eventually leads to wxGTK3.2 release.
Upstream is currently at 3.1.3 and expecting at least a 3.1.4 next year.
Audacity 2.3.3 release is imminent (RC02).

I would like to be able to release the next Audacity (once tested) when 
it drops.


I've been reading about Fedora modules, and am wondering whether the 
following would make sense as a potential solution ?:


$ dnf  modules  list  wxGTK3

Fedora Modular 30 - x86_64
Name Stream   Profiles Summary
wxGTK3   3.1.n-unstable   default [d], devel   GTK wxWidgets GUI library


If the module was setup like this, then could the normal repo 
audacity.spec package:

BuildRequires: wxGTK3:3.1.n-unstable/devel

Requires: does this get sorted out magically like in a normal package ?

I don't know whether any other wxGTK using packages could or should be 
using the wxGTK devel series.


As I'm not on the wxGTK3 package team, can I do this without their 
approval/assistance ?


Advice ? Am I on the right track ?

Cheers, Dave.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: package downgrades from f28 to f29

[David Timms]

On 11/10/18 01:50, José Abílio Matos wrote:

Even so the problem described seems to be related with packages that were not
build for F29 by mistake (probably around the time that F29 was branched from
rawhide August 14). If the same nvr exists in F28 and rawhide it is difficult
to come with a reason why it does happen the same for F29.


Given Fedora runs on community power, have you tried rebuilding the 
packages that interest you under f29 to see/fix any problems that arise ?
You can also use the web tools to see what the current rpm spec and 
builds have been requested, and if any new freshness bugs are in bugzilla.

The maintainer may very well appreciate your assistance.

Dave.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Disabling build options for SSE on non-capable arches ?

[David Timms]

On 20/09/18 09:38, Sérgio Basto wrote:
> On Thu, 2018-09-20 at 07:58 +1000, David Timms wrote:
> The conditional is correct but [1] from the previous %endif you leave
> two blanks lines which you can't, one blank line makes terminate the
> ./configure command and so last option "--disable-sse" is not included
> in build, you may check build.log [2] and you don't find any "
> --disable-sse" 

OK, thanks, guys. I had already noticed the blank lines removed and
commited, but my git foo can't have been on the ball. I was also getting
a clog generated which had the comment from an earlier commit - another
thing I don't understand.

Once properly committed, build succeeded on f27 on copr, so commited to
Fedora, and awaiting success!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Disabling build options for SSE on non-capable arches ?

[David Timms]

Hi, (this is a 4th retry, now trying devel as first try to packaging a
week ago says held by moderator, but doesn't seem to have been posted to
the list, and I don't know why...)

Audacity has had the following as part of rpm spec in the %configure
section:

%configure \
--disable-dynamic-loading \
...
%ifnarch %{ix86} x86_64
--disable-sse \
%else
%{nil}
%endif

Which fails on: non x86 arches:
https://koji.fedoraproject.org/koji/taskinfo?taskID=29513664

If I remove the conditional, I get successful build, but not optimized
on x86 with SSE.

What's wrong with this conditional ?

Cheers, David
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: upgradepath FAILED for audacity-2.1.2-3.fc23

[David Timms]

On 05/03/16 13:37, notificati...@fedoraproject.org wrote:
> upgradepath FAILED for audacity-2.1.2-3.fc23
>   
> https://taskotron.fedoraproject.org/artifacts/all/119e1b68-e27b-11e5-a932-525400120b80/task_output/audacity-2.1.2-3.fc23.log

Hi, I've received the above notification from the QA processes after
submitting a build.

Background:
- new gcc has broken audacity build in future Fedora releases. So can't
update F24/devel yet.
- new soundtouch in f23 has broken audacity there. The new build is
correct and works, but is newer than the uncompilable F24/devel for the
moment.

Can I ignore that an push the build anyway for F23 (I can't see the push
button) ?

Cheers, Dave.
--
devel mailing list
devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: wxGTK3 - drop down fields - text misplaced (Audacity)

[David Timms]

On 24/11/15 01:29, Scott Talbert wrote:
> On Mon, 23 Nov 2015, David Timms wrote:
> 
> When updating my code for wxGTK3, there were some places where I had to
> add a Layout() call to my wxPanel after adding items to a wxChoice in
> order to get it to size correctly.  The same code worked just fine with
> GTK2, so I'm not sure whether I really should have had a Layout() call
> there in the first place.
OK, that sounds like a great place to start... now to find that point in
the app source haystack. Thanks.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

wxGTK3 - drop down fields - text misplaced (Audacity)

[David Timms]

Hi any GTk3 or WxWidgets devs,

In Audacity (next), upstream has moved to wxGTK3. The only visible issue
I can see is with the placement of text within drop down fields.

The text is too low, and if it's too wide, the combo box isn't resizing
to fit the width. [1]

Just wondered if this is a problem with any other wxGTK3 using
applications, or any pointers in trying to nut out the cause would be
welcome ?

[1]

contains 3 screen shots indicating the issue, where it's difficult to
read the text.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: copr - hung or out of control build .. ? resolved by itself.

[David Timms]

On 14/11/15 01:18, Miroslav Suchý wrote:
> Dne 13.11.2015 v 13:30 David Timms napsal(a):
>> Hi, I submitted an audacity build f22,23,rawhide. Usually it finishes in
>> 12-20 mins. 22/23 are done, but rawhide's been 80 minutes, so I think
>> something has gone wrong... No logs yet for it.
>>
>> https://copr.fedoraproject.org/coprs/dtimms/audacity-git/build/139224/
> 
> I see it as succeeded, so your problems are likely resolved now :)

Thanks Miroslav, it did finish in 112 mins. That was way longer than
normal, I guess the builders where under heavy load or something. Thanks
anyway.

I'm also none the wiser about the Koji build which failed. Since the
same on COPR eventually finished, I tried Koji again, and succeeded as
expected, so all good.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

copr - hung or out of control build .. ? infrastructure help

[David Timms]

Hi, I submitted an audacity build f22,23,rawhide. Usually it finishes in
12-20 mins. 22/23 are done, but rawhide's been 80 minutes, so I think
something has gone wrong... No logs yet for it.

https://copr.fedoraproject.org/coprs/dtimms/audacity-git/build/139224/

Can I, should I kill the build and if so how ?

Also, I had earlier tried the same on koji, but that failed:
http://koji.fedoraproject.org/koji/taskinfo?taskID=11804001

I can't see what has gone wrong in the logs there ?

- this also doesn't show up in:
http://koji.fedoraproject.org/koji/packageinfo?packageID=1352

btw, local mock build on f22 for rawhide (f24) suceeded.

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: [Fedora-packaging] build failure - Failed to create the file ./: Is a directory

[David Timms]

trying on -devel On 25/06/15 02:06, David Timms wrote:
> I haven't seen this one before. I'm fixing up my first mistake which was
> that adding the new source file to look-aside dropped the
> audacity-manual zip entry from sources.
> 
> I've re-added that, but still getting build failure on fedpkg build:
> 
> Any ideas ?
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=10198630
> 
> https://kojipkgs.fedoraproject.org//work/tasks/8630/10198630/root.log
> ===
> DEBUG buildroot.py:322:  _nuke_rpm_db: removing
> /var/lib/mock/f23-build-3572318-495695/root/var/lib/rpm/__db.001
> DEBUG util.py:509:  child environment: None
> DEBUG util.py:442:  Executing command: ['fedpkg', 'sources'] with env
> {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash',
> 'PROMPT_COMMAND': 'printf "\x1b]0;\x07"',
> 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'HOME': '/builddir',
> 'HOSTNAME': 'mock'} and shell False
> DEBUG util.py:252:  Unsharing. Flags: 134217728
> DEBUG util.py:378:% Total% Received % Xferd  Average Speed
> TimeTime Time  Current
> DEBUG util.py:378:   Dload  Upload
> Total   SpentLeft  Speed
> DEBUG util.py:378:
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
> 0
> 100 23.2M  100 23.2M0 0  77.3M  0 --:--:-- --:--:-- --:--:--
> 77.7M
> DEBUG util.py:378:% Total% Received % Xferd  Average Speed
> TimeTime Time  Current
> DEBUG util.py:378:   Dload  Upload
> Total   SpentLeft  Speed
> DEBUG util.py:378:
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
> 0
> 100 18.4M  100 18.4M0 0  50.1M  0 --:--:-- --:--:-- --:--:--
> 50.2M
> DEBUG util.py:378:% Total% Received % Xferd  Average Speed
> TimeTime Time  Current
> DEBUG util.py:378:   Dload  Upload
> Total   SpentLeft  Speed
> DEBUG util.py:378:
>   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
> 0Warning: Failed to create the file ./: Is a directory
> DEBUG util.py:378:  curl: (23) Failed writing body (0 != 1085)
> DEBUG util.py:489:  Child return code was: 23
> DEBUG util.py:171:  kill orphans
> DEBUG util.py:509:  child environment: None
> ===

Given this builds locally with rpmbuild, and mock, can anyone help with
what might be going wrong when attempting to build the build system ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Install Fedora by hand ... feeling brave :-)

[David Timms]

Hi, I'm keen to install F22 on a laptop (shared with windows 7), but the
installer bugs out due to problems in libparted when reading my disk
(bz: 1223111):
https://bugzilla.redhat.com/show_bug.cgi?id=1223111

The machine boots and runs the live iso via usb, but also can't do
install to the HD due to the above.

So, what would it take to set up Fedora by hand ?

My first go is:
boot live iso to runlevel 2
login: root

mount /dev/sda6 /mnt
mount /dev/sda5 /mnt/boot
mount /dev/sda7 /mnt/home
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/proc
mount -t tmpfs  tmpfs  /mnt/tmp ???

dnf --installroot=/mnt install filesystem kernel firefox grub2  grubby
(workstation stuff)

chroot /mnt
passwd

dnf reinstall kernel (to make initrd creation work.)

useradd myuser
passwd myuser
usermod -G wheel ??

grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg

What other things will I need to do / what does Anaconda do ?

My first effort looks like it may be hanging/dying on selinux parts; I
was able to /etc/selinux/config to turn is to DISABLED and add selinux=0
to kernel command line.

Since all my files are installed without SE context, boot fails with SE
enforcing. If SE disabled then restorecon etc don't work. What's the
steps, to bootstrap selinux ?

I imagine someone has done / documented this before, but google search
not fruitful.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Pushing the extra AppData files into Rawhide

[David Timms]

On 01/04/15 12:54, Bill Nottingham wrote:
> David Timms (dti...@iinet.net.au) said: 
...
> I thought about trying to reliably parse major/minor/subminor versions in
> bash, and track it against where things were implemented. But then just went
> the lazy route:
> 
> if appstream-util --help | grep -q replace-screenshots ; then
>   ... do stuff here ...
> fi

Even with little sleep, I find that understandable, Bill. Thanks very much.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Pushing the extra AppData files into Rawhide

[David Timms]

On 01/04/15 00:34, Richard Hughes wrote:
> On 31 March 2015 at 14:07, David Timms  wrote:
>> I see my package was adjusted, but I can't get it to build:
> 
> I only build the new-enough libappstream-glib into rawhide -- seeing
> as most of the f23 builds have succeeded I'll do the same for F22 and
> submit an update. F20 is much too old for that version of
> appstream-glib, and I'm not sure the gnome-software in f20 actually
> supported screenshots :/
> 
Thanks Richard.

I would love to be able to keep the spec files "same as possible".
$ appstream-util --version
Version:0.2.5

What is the minimum version ?

Can someone give me a simple spec file conditional to achieve:

if appstream-util --version >= 0.2.5
{
  appstream stuff
}

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Pushing the extra AppData files into Rawhide

[David Timms]

On 27/03/15 04:48, Matthew Miller wrote:
> On Thu, Mar 26, 2015 at 05:40:29PM +, Richard Hughes wrote:
>> So, the overwhelming amount of help I received (one person) meant I
>> spent the whole of today fixing up 230 packages. Most of the packages
> 
> Looks like about 22 hours since you asked for help, so... I dunno, one
> person seems pretty good.
> 
> But all that aside, thanks for doing all this work — the end results
> are good for Fedora.

I see my package was adjusted, but I can't get it to build:
---
make[1]: Leaving directory
`/home/davidt/rpmbuild/BUILD/audacity-minsrc-2.1.0'
+ rm -Rf
/home/davidt/rpmbuild/BUILDROOT/audacity-2.1.0-1.fc20.x86_64/usr/share/audacity/include
+ appstream-util replace-screenshots
/home/davidt/rpmbuild/BUILDROOT/audacity-2.1.0-1.fc20.x86_64/usr/share/appdata/audacity.appdata.xml
https://raw.githubusercontent.com/hughsie/fedora-appstream/master/screenshots-extra/audacity/a.png
Usage:
  appstream-util [OPTION...]

  appdata-from-desktop  Creates an example Appdata file from
a .desktop file
  check-rootCheck installed application data
  convert   Converts AppStream metadata from one
version to another
  dump  Dumps the applications in the
AppStream metadata
  install   Installs AppStream metadata
  install-originInstalls AppStream metadata with new
origin
  non-package-yaml  List applications not backed by packages
  status-csvCreate an CSV status document
  status-html   Create an HTML status page
  uninstall Uninstalls AppStream metadata
  upgrade   Upgrade AppData metadata to the
latest version
  validate  Validate an AppData or AppStream file
  validate-relaxValidate an AppData or AppStream
file (relaxed)
  validate-strict   Validate an AppData or AppStream
file (strict)

Help Options:
  -h, --helpShow help options

Application Options:
  --nonet   Do not use network access
  -v, --verbose Show extra debugging information
  --version Show version

error: Bad exit status from /var/tmp/rpm-tmp.WgpZI1 (%install)


RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.WgpZI1 (%install)

---
Ideas ?



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: amending the new package process

[David Timms]

On 21/01/15 22:15, Matthias Runge wrote:
> On 21/01/15 11:49, Nikos Mavrogiannopoulos wrote:
> 
>> I don't have a solution to bring extra resources to reviewing (which
>> will be the ideal), but I'd like to propose an amendment to allow
>> bringing packages even if no reviewers are available (the typical case).
>>
>> Step 6: ... If the proposed package is not reviewed for 2 months, the
>> package must be reviewed by the submitter, and a git module with the
>> master branch will be approved.
Open slather is probably not ideal.

Perhaps we could formalize a multi-level reviewer approach...
eg. I've done pre-reviews and reviews, picking up various items. But
then someone who actually knows what they are doing in writing specs for
Fedora often kicks in a makes lots of suggestions / points out issues.

So for me, I'd be happy to pre-review packages, but I'm not confident that:
- I'll pick up anything / everything

- I quite often don't have much experience with a particular build
system or source language. So again, I miss the "easy" way to get it to
build properly.

- To give a final OK/Accept on a package. I'd prefer for a more
experienced packager to make that call.

- License checking is difficult to understand.

- I'm not keeping up with continued packaging guidelines changes.

Hence: I propose creating groups of packagers/wiki pages with expertise in:
- language specific area, eg Python.
- build system specific, eg cmake.
- licensing checking,.
- package accepters.

However, I get rather annoyed when I try to build a spec/srpm, and this
doesn't work at all.

Is there a possibility that we can have a review request with
retrievable .spec and .srpm automatically be build in mock
(current/previous/next release) and respond with build success/failure
back to the review request bug. The submitter would then immediately
know that they have BR/R issues to resolve (and that they probably
should have built in mock before submission).

Dave.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: Installer - how to get a shell ?

[David Timms]

On 08/10/14 10:41, Mike Ruckman wrote:
> The list of ttys you see along the bottom is from tmux [0]. From that screen
> if you were to hit `ctrl-b 2` it would switch to the pane labelled 'shell' at
> the bottom of the screen.
Uh-hah, thankyou.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Installer - how to get a shell ?

[David Timms]

Hi, booted up a F21 alpha iso cd, and realized after the long wait that
I didn't have networking configured during boot, and this probably led to:
- no repository
- no package selection possible.

I thought I would Alt-F1,F2 etc to find the shell (and set up networking
manually, rather than waiting for a second boot cycle).
F1 had the list of ttys along the bottom, but the shell one (F2 from
memory) accepts enter (which outputs a blank line, but never gave a
prompt or other response.

What's the trick to getting that (usable) shell to do things like
check/set network ?

Also, should we be able to access wireless network during the first part
of the installer (for network download/install of repos/packages) ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

fedpkg build error: Error running GIT command "git reset --hard ..

[David Timms]

Hi, I'm trying to build an updated package, first in master, then in f21
and the command failed with the below. Google hasn't helped me so far.
What happening here ?

Dave.
=
$ fedpkg build
Building tnef-1.4.11-1.20140826git0b35ad8.fc21 for f21-candidate
Created task: 7494307
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=7494307
Watching tasks (this may be safely interrupted)...
7494307 build (f21-candidate,
/tnef:0b5ed5d06268924f1c545174dc57e15e951a8ff6): open
(arm02-builder18.arm.fedoraproject.org)
  7494310 buildSRPMFromSCM
(/tnef:0b5ed5d06268924f1c545174dc57e15e951a8ff6): open
(arm04-builder03.arm.fedoraproject.org)
  7494310 buildSRPMFromSCM
(/tnef:0b5ed5d06268924f1c545174dc57e15e951a8ff6): open
(arm04-builder03.arm.fedoraproject.org) -> FAILED: BuildError: Error
running GIT command "git reset --hard
0b5ed5d06268924f1c545174dc57e15e951a8ff6", see checkout.log for details
  0 free  1 open  0 done  1 failed
7494307 build (f21-candidate,
/tnef:0b5ed5d06268924f1c545174dc57e15e951a8ff6): open
(arm02-builder18.arm.fedoraproject.org) -> FAILED: BuildError: Error
running GIT command "git reset --hard
0b5ed5d06268924f1c545174dc57e15e951a8ff6", see checkout.log for details
  0 free  0 open  0 done  2 failed

7494307 build (f21-candidate,
/tnef:0b5ed5d06268924f1c545174dc57e15e951a8ff6) failed
[davidt@davidtdesktop tnef]$

checkout.log:
$ git clone -n git://pkgs.fedoraproject.org/tnef
/var/lib/mock/f21-build-2342345-415439/root/tmp/scmroot/tnef
Cloning into
'/var/lib/mock/f21-build-2342345-415439/root/tmp/scmroot/tnef'...
$ git reset --hard 0b5ed5d06268924f1c545174dc57e15e951a8ff6
fatal: Could not parse object '0b5ed5d06268924f1c545174dc57e15e951a8ff6'.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: difference between F18 and F19 ? was: how to build a scratch build of an older version of my package ?

[David Timms]

On 18/09/13 20:45, Paul Howarth wrote:
> On 17/09/13 20:30, David Timms wrote:
...
> Note that old builds (source and binary RPMs, plus logs) can be found
> at: http://kojipkgs.fedoraproject.org/packages//

Thanks Richard, Mikolaj and Paul. These were all useful and helpful
responses.

With the info links, I downloaded older builds of audacity, installed
and tested a particular feature (Effect|Equalization), and found that
packages built on F19 or later produce a segmentation fault before the
wxDialog is shown on screen.

The builds in the build system use the same spec and sources. The built
for F18 rpm runs on my F19 machine, and the feature showing the bug
works fine, no crash. The same issue was noted on Arch linux build (with
recent builds some months), but not on an Ubuntu build (might be an
older release).

Reviewing mock logs:
- state.log: mock v 1.1.22 both F18 and F19.
- root log: most packages are very similar versions, usually just
a few -releases later. (I can show complete diffs if that would help).
- gcc-c++:  fc18 (4.7.2-8)   fc19 (4.8.1-1).
- wxGTK:fc18 (2.8.12-5)  fc19 (2.8.12-8).


build.log:
gcc-cc FLAGS:
- fc18(a heap of them)  fc19 (same heap plus -grecord-gcc-switches)

The .configure line ends of with multiple copy of
above grecord-gcc-...items (f19 only).

- fairly new spec code:

# ensure we use the system headers for these, note we do this after
# configure as it wants to run sub-configures in these dirs
for i in ffmpeg libresample libsoxr libvamp portaudio-v19; do
   rm -rf lib-src/$i
done



On build f18, this is not logged. The f19 build does log this removals.

Does any of this ring any "oh yeah, build system could cause this issue"
scenarios ? [https://bugzilla.redhat.com/show_bug.cgi?id=999145]

Thanks, David.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

how to build a scratch build of an older version of my package ?

[David Timms]

In trying to track down when a bug began showing up, I'd like to build
an earlier version of my package eg from 9 months ago (hence earlier
upstream release and different spec/patches). How can that be achieved
on the builder ?

Does the build system keep the build logs of old packages, ie that shows
what build requires-version was installed, and which gcc compiler
version was used ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: F-18 Branched report: 20120907 changes

[David Timms]

On 08/09/12 11:50, Kevin Fenzi wrote:
> Well, if you want to look, or anyone else wishes to take up the 
> gauntlet:
> 
> http://git.fedorahosted.org/cgit/mash/tree/utils/spam-o-matic
Thanks for the link. Anyone see merit in these ideas ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F-18 Branched report: 20120907 changes

[David Timms]

On 07/09/12 22:07, Fedora Branched Report wrote:
> Compose started at Fri Sep  7 09:15:28 UTC 2012
> 
> Broken deps for x86_64
> --
Who would like to re-arrange this report to be more effective and useful ?

1. The broken dependency first, not the package that requires it !
[libboost_thread-mt.so.1.48.0()(64bit)] [{owner/username/last commiter}]
blocking:
   LuxRender
   condor
   ekiga
   flush
   gearmand
   glob2
   glom
   iwhd
   leechcraft
 total: 9 packages blocked due to missing dependency on {blah}
  last: previously found in package libboost, from source package boost
  (or whatever).

And so on.

2. The other simplifying thing would be to only note x86_64 or 686 if
both are not broken.
eg:
both broken:
[libboost_thread-mt.so.1.48.0()(64bit)]
[libboost_thread-mt.so.1.48.0()]
show only once as
[libboost_thread-mt.so.1.48.0()] !both!

, but show:
[libboost_thread-mt.so.1.48.0()] !32bit!

Otherwise the report is really just duplicating half the information, ie
is twice as long as it needs to be.

3.
It could also be much nicer in a web page, perhaps with columns for
applies to (64 bit and 32 bit), and links to the git package source for
failing dependency package and the packages using it.

Having no internal knowledge of Fedora build stuff, I'm not volunteering
myself.

> Summary:
> Added Packages: 0
> Removed Packages: 0
> Upgraded Packages: 0
> Compose finished at Fri Sep  7 12:03:57 UTC 2012

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Audacity - audio editor - test request

[David Timms]

On 18/02/12 09:46, Richard Vickery wrote:

Have you received an indication from anyone to do this?
No, actually. Although I thought I sent it to the test list but see now 
I sent to devel.



I would like to
help test it; how am I to get it off the site using Google-Chrome?

Looks like I built a scratch build, and the results have expired.
Since there has been more changes, I'll update and rebuild later today.

(I'll also send to test list instead.)

Cheers.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Audacity - audio editor - test request

[David Timms]

Hi, It appears Audacity is getting close to v2 release (it's been in 1.3 
beta mode for a few years).


I've built the current svn release as 2.0.0.alpha... , and request 
anyone with audio hardware who would like to help to download and 
install it to check whichever functions you feel like testing operate as 
expected.


build: {rawhide}, also runs on F16 OK.
i686:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3771416

x86_64:
http://koji.fedoraproject.org/koji/taskinfo?taskID=3771415

Any crash/exceptions definitely report in bugzilla.

Cheers, David Timms.

ps. An ffmpeg & mp3 version should be ready @RPM Fusion in a few days.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: pyvnc2swf and vnc2flv

[David Timms]

On 29/11/11 06:51, Casey Dahlin wrote:
> On Mon, Nov 28, 2011 at 12:18:01PM +0100, Jos Vos wrote:
>> I was looking for a tool to record X/VNC session in a movie and found
>> pyvnc2swf.  But looking at the project's home page,
>> , I see that the
>> development has been superseded by its successor, vnc2flv,
>> ,
>> since 2 years.
>>
>> Maybe Fedora should upgrade to this new version for F17.
Since the two tools output different file types, my thinking would be 
for both applications to be able to install side by side.

As packager of pyvnc2swf, I modified the existing app names in pyvnc2swf 
so that their names wouldn't clash with existing fedora app names. 
Possibly the same was/is needed for vnc2flv ?

> You should contact the maintainer directly and see if he will package
> the new app (or at the very least retire the old one so a new maintainer
> can obsolete it).
I don't think the old one needs retiring, since it still works as 
expected. In fact there is already a (stale) Review Request:
https://bugzilla.redhat.com/show_bug.cgi?id=567877

Jos: how would you like to finalise the work done by Chen, and bring 
this packages to acceptable state ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Heads-up: Maven builds might be failing for some period

[David Timms]

On 23/06/11 22:53, Alexander Kurtakov wrote:

> maintainers of most of the stack are slightly moving it to maven 3 only. We
Hey Alex, is that supposed to be slowly  ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [solved] illegal instruction - create compile variants ?

[David Timms]

On 02/05/11 11:01, Reindl Harald wrote:
> the application must cpu-runtime-detect itself what means taht for
> performance-critical parts different code is included and at
> the start the application checks what code-parts have to be used
>
> but this is nothing anybody can make generic by packaging if
> the developer do not support native nor you can analyze the
> binary to find this out
OK, thanks all responders for clear logic and possible solutions.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: illegal instruction - create compile variants ?

[David Timms]

On 02/05/11 06:31, Kevin Kofler wrote:
> David Timms wrote:
>> Should I be suggesting to upstream to attempt to detect CPU before
>> running non-available instructions, eg as part of app startup ?
Further, what can I run over an existing executable to detect what CPU 
it was built for, ie what instuctions have been included ?

> Yes, all the packages which have WORKING support for SSE etc. in Fedora do
> that. See e.g.
> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/solid/solid/backends/shared/cpufeatures.cpp
> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/solid/solid/backends/udev/cpuinfo.cpp
> https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/entry/solid/solid/backends/udev/udevprocessor.cpp
> for the implementation Solid (in kdelibs) uses.
Thanks Kevin, I'll make the suggestion to developers, and see if they 
are interested. Cheers, David.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

adding manual to existing package - soft review ?

[David Timms]

Hi, I'm adding a subpackage -manual to audacity to include the 
additional manual archive. It links from the help menu items if it is 
installed, or else points you to the in development online version.

I already made a mistake and included manual files in both the main and 
sub package. The spec change [1] I've committed fixes this.

The -manual package can be used by either audacity or 
audacity-freeworld. At the moment the manual spec marks up the 
datadair/audacity folder and hence dually owns it with audacity if that 
is installed. Reading the packaging examples, seems that this can 
sometimes be OK, but does what I've done make sense ?

Or should I Require the audacity (or audacity-freeworld) package, and 
not add the datadir/audacity folder to the -manual directory.

Thirdly, vague recollection of one source/package. Should the -manual 
just be a separate package anyway (review?) ? It's likely to be updated 
more often, but not necessarily in sync with the program.

4. Being new to git/fedpkg, how can I tell which branch I'm on ?

[1] 


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: illegal instruction - create compile variants ?

[David Timms]

On 01/05/11 17:41, Hans de Goede wrote:
> Erm, specifying a minimum support CPU in the package description is
> not acceptable IMHO. The fix here is to patch the packages buildsystem,
> so that it gets build for the minimum cpu level which is supported by
> Fedora, and thus will work out of the box on all systems Fedora
> supports.
Where is that stated currently, and for older releases ?

> No tricks / hacks with multiple compilation, cpu detect scripts, etc.
> will be necessary then.
Though it comes at the cost of audio lag/latency increase when we are 
trying to achieve near real time (eg live guitar input to sound effect 
generation output). Even on the my machine (4x core amd 3Ghz), the 
calculations the app performs for difficult presets (convolution) can 
cause jack to abort because rakarrack didn't finish it's calculations 
before it was required to deliver data.

Should I be suggesting to upstream to attempt to detect CPU before 
running non-available instructions, eg as part of app startup ?
Can that even be done (reliably) ?

Thanks for your input.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: illegal instruction - create compile variants ?

[David Timms]

On 01/05/11 16:47, Ralf Corsepius wrote:
> Rpm's and Fedora's philosophy is to let rpm specify/dictate CFLAGS,
> which packages are supposed to respect.
Yes, I still have VSs bug (514991) regarding opt flags still open.

So, for the lesser CPU problem, does that mean I just suggest, rebuild 
srpm on their machine ?

Can I add that minimum CPU requirement to package description ?

If a user wanted to rebuild srpm for their CPU, would it be acceptable 
to place some sort of conditional in the spec make line, so that the 
local CPU build could use a suitable Instruction Set ?

Would it still be worth adding a CPU detect script to avoid abrt traces 
from non-compatible CPU machines. In this case, could it just exit, or 
leave a message to suggest the user to obtain and rebuild the srpm ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

illegal instruction - create compile variants ?

[David Timms]

Hi, a user of rakarrack was getting startup exception SIGILL [1].

Seems the config/make/compile process for this app checks CPU capability 
of the machine it is being compiled on, and applies optimisations that 
are available on that processor.

The user has a much older processor.

Upstream suggest [2] that distros could add a script to detect runtime 
CPU, and call the appropriately compiled executable.

To do that in rpm, I think I would need to call configure a second time.
Also, the new compile would overwrite the first compile, so it doesn't 
seem that easy.

Any suggestions on a way forward ?


[1] https://bugzilla.redhat.com/show_bug.cgi?id=700183

[2] http://rakarrack.sourceforge.net/FAQ.html
  [Why when I run rakarrack I receive a "Illegal Instruction" message?]
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [dokuwiki/el5/master] - Upgrade to latest upstream - large patches in git

[David Timms]

I guess anyone on the scm-commits list would have seen a few like this:

On 18/01/11 08:59, topdog wrote:
>  dokuwiki-2010-11-07a.tgz  |  Bin 0 -> 2758654 bytes
>  dokuwiki-rm-bundled-libs.patch|54035 
> +
>  dokuwiki-use-fedora-email-valid.patch |   12 -
>  dokuwiki-use-fedora-geshi.patch   |   25 -
>  dokuwiki.spec |   57 +-
>  sources   |1 -
>  6 files changed, 54084 insertions(+), 46 deletions(-)
> ---
> diff --git a/dokuwiki-2010-11-07a.tgz b/dokuwiki-2010-11-07a.tgz

Even just opening this email takes my machine 4 seconds. Trying to hit
reply took more than 2 minutes before I terminated thunderbird.

Should that 54000 line patch have been added as a new source and
uploaded to the lookaside cache, rather than into git proper ?

If not, then a 2596K Byte commits email is a bit over the top. Perhaps
we could have the automation check the size of the commit, and send the
email with only the first 200 lines or whatever is common ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: process to use when missed a patch addition

[David Timms]

On 05/10/10 07:27, Jon Ciesla wrote:
> In my experience, git add the patch, fedpkg commit -p, fedpkg build.  
> The tag is based on the git revision hash, so it's unique, no need to 
> bump the EVR.
Cool, thanks, will do.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

process to use when missed a patch addition

[David Timms]

Hi, new to git, and while following the "conversion" guide [1], I missed
the fact that I had added a new patch, but not added it to git.

So the build failed. I have now: git add x.patch

I'm not sure what is correct procedure to attempt rebuild with the
included patch:
1. fedpkg commit -p
2. fedpkg commit && fedpkg push
3. bump release in spec first, then one of the above.
?

Does a new unique tag get created automatically, or do I need to mess
with "git tag $(fedpkg verrel) && git push --tags" ?

[1] http://fedoraproject.org/wiki/Using_Fedora_GIT
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

spin development: how to trust an iso built outside the fedora build sys

[David Timms]

Hi there,

I was wondering if there is any process that we (spin developers - music
list) could use to confirm that a spin iso was
1. built with a particular kickstart file (or list of files when there
is kickstart %include x directives).
2. hasn't been doctored on purpose eg by the person building the iso, or
corrupted by the upload/download process
3. hasn't been tainted by unknown code on the build machine

A few thoughts:
1. the spin build process could place copies of all the spin kickstarts
files in a folder on the destination machine eg /root/build-process.
This would be in addition to the automatically created anaconda-ks.cfg
(which is the combined ks file).
2. shaNsum created by the spin creator and uploaded alongside the iso
3. content test by downloader of the iso:
- mount -o loop/image on existing known good system
- using known system rpm -Va all packages
- using known system tools, compare filelist from on image rpm db with
complete list of files on disk to indicate every "extra" file present
anywhere on the image. list the name and contents of them.
- above check to indicate every "modified" rpm installed file
4. If a user builds a spin at a different time, or with repo out of
sync, I expect that I could get different versions of packages in my
build, so I don't think you could say: User built from the spin
kickstart, and has a different sized/content iso, hence the original
spin is "faulty". Does that make sense ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

music list maintainer/owner - how to get changes made

[David Timms]

Over on mu...@lists.fp.org, we have some difficulty because by default a
reply to a list message doesn't automatically get sent back to the list.

I find it really limiting in a forum that is supposed to be enhancing
communication and collaboration to end up with most people replying only
to the original author. I hope it isn't intended.

Anyway, with no response from the list owner, is there somewhere else I
can request a change ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Make pkgdb grant co-maintainer status automatically? (was Re: Non-responsive maintainer fast track procedure for libsndfile)

[David Timms]

On 07/07/10 20:16, Thomas Spura wrote:
> To get such a button, to apply for becoming real maintainership makes
> this possible and is the easiest way, because it doesn't need e.g. a
> fast track procedure or anyone agreeing from fesco or anyone to change
> it manually in pkgdb.
> 
> When you have another solution for this, let me hear. :)
I have an idea that people who spent the hard yards to create a
package/improve it enough to get into fedora are proud of their
accomplishment - for non-prolific packagers, like my self, having
yourself listed as maintainer can be a bit of status symbol.

Having to officially say I don't want that any more would not be easy.

It would be good if the package db grew a history of (co)maintainers:
Package developed: 2007-06-01 fschepsi
Retired maintainers:
2009-12-06 -> 2010-04-13 bcandoit
2008-07-01 -> 2009-09-13 jbloggers

Anymay, just wanting to put a view from a basic (<10 packages) maintainer.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: jack2

[David Timms]

On 21/07/10 02:54, Fernando Lopez-Lezcano wrote:
> On Tue, 2010-07-20 at 10:04 -0400, Orcan Ogetbil wrote:
>> On Tue, Jul 20, 2010 at 2:30 AM, Andy Shevchenko wrote:
>>> On Tue, May 11, 2010 at 6:17 PM, Orcan Ogetbil wrote:
 For F-13 it may be a little late. So shall we make this an F-14 target?
>>> I see new commit to the koji. Thanks for working on jack2, but the
>>
>> No problem. Although I was the one collecting the pieces, it was
>> rather a collective work. Thanks to everyone who is involved. We need
>> to do some testing now, and clean up the glitches before F-14.
>>
>>> question is why the package name is jack-audio-connection-kit? As far
>>> as I know the package name should be derived from the main tarball
>>> name.
>>>
>>
>> I thought about doing that once. Jack1's and jack2's source codes are
>> distributed on the same website [1],  We know that JACK stands for
>> Jack-Audio-Connection-Kit.  So there shouldn't be any confusion.
>>
>> Sadly, there is no unique agreement on the package name across
>> distribution. As far as I know, we were the only distro distributing
>> jack1 under the full name "jack-audio-connection-kit". There is also a
>> very different project called jack [2], although we don't have it on
>> Fedora. This adds more to the subtlety as Mandriva distributes this
>> jack as just "jack".
>>
>> What do other maintainers think?
> 
> "jack-audio-connection-kit" is the official name of the project and it
> has been the suggested name for packages - I could try to dig through my
> very old email and find an email from Paul on the subject. I have used
> that name since 2001 or so (version 0.37) - I may have been one of the
> first if not the first to package Jack as part of Planet CCRMA. 
> 
> The jack1 tarball is actually named "jack-audio-connection-kit", not
> "jack". As mentioned above jack2 is a different code base that
> implements the same "official" jack API and was developed independently.
> Its developer chose to name the tarball jack (I don't know why, we could
> ask). 
> 
> Who knows what the future could bring. I certainly don't know :-)
> When/if jack2 becomes the official jack maybe the tarball will change to
> jack-audio-connection-kit. Of jack1 could evolve, supplant the current
> jack2 as the next version, and the tarball would still be
> jack-audio-connection-kit. I would keep the current name. 
And in our Fedora world, yum search jack gives you the full name anyway.
Also jack is underlying layer; other applications simply require it and
hence you never really need to know/type the exact package name.

I sort of think that "jack" has other connotations (eg ac/dc: she's got
the jack...)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

source url when upstream disappears (geocities)

[David Timms]

I vaguely remember something about this, but can't find it in wiki or
list archives:
My upstream hasn't updated in years, but the package (glglobe) still
builds for fedora and epel. Late in 2009, it appears that the upstream
hosting site was closed: http://www.geocities.com  (now yahoo).

However, www.oocities.com has chosen to create an archive of various
parts of geocities, and hence the original web pages and source are
available within the archive; it then has a different URL.

Since rpmlint complains, W invalid-URL, for the URL and Source0, it it
acceptable to point to the archive site ?

Concern would be:
- the archive places the content in a frame, so it's not exactly the
same look
- content could get changed by someone else
- linked source could get changed by someone else.

Should I update the URL ?
I was thinking to comment the original URL & Source indicating the
original site, but then change the tagged lines to the oocities versions.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Bug 531464 - why the WONTFIX?

[David Timms]

On 17/07/10 08:12, Christoph Wickert wrote:
...
> It refers to "bugs" and thus *covers* all bugs. You should first try to
> fix it yourself and upstream the fix if it's not Fedora specific. If you
> cannot fix the problem yourself, ask upstream for help.
Many packagers are not programmers, and even those that are, work in
entirely different worlds and are not familiar with thousands or 10,000
lines of code. To actually fix one bug might take work in spare over a
month to make any progress at all. And it isn't obvious when something
goes wrong in a library the app is using, whether it is the usage of the
library, or the library itself that is at fault.

Could rpm spec have a URL of upstream bug reporting system ?
Or maybe just in package database:
- link the upstream bug reporting information (ie how the upstream want
to receive bug reports)
- link to the bug reporting mechanism
- whether upstream are happy to receive semi-automated crash traces ?

Could abrt / tools list that as the first possible item in the "report
this bug where" dialog ?

On a different note: does there exist an open bug report system ?
ie one were any upstream package can be added, and bug's reported there.

Would it it be useful for abrt to automatically submit bugs to such a
thing ?
This wouldn't pollute either fedora's or upstream bug systems, yet it
would capture vital info (backtrace) that would otherwise go missing.
With some marketing, it might be possible for upstream developers to
"want" to be subscribed to their apps external bug info ?

David.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rfc: give koji diff capabilities

[David Timms]

On 21/06/10 09:38, Thomas Spura wrote:
>> Any comments (other than 'show me the money/code') ?
>
> I don't see a benefit of that... When a build fails, it kills all
> other current builds of other architectures, so you need to check that
> architecture, that fails first and the diff would not contain the error.
Hi Thomas, good point. But reality might be different:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2260035 -> build.log

The x86_64 build failed, and is says that the i686 was cancelled.

However, the build.log shows that the package and -debuginfo .rpms were 
created, ie the build actually succeeded. This seems like a bug in the 
koji web interface.

Having the non-failing build be cancelled may not be optimal; I have 
definitely found it helpful to compare the build logs of different 
archs, when one succeeds (or at least gets further). It helps to see the 
diff in log results to understand what is different about the process 
between each build.

> Other that that. The diff would show, different which different
> packages are installed, e.g. gcc.i386 instead of gcc.x86_64, which
> doesn't interest me either...
> (And different requires etc.)
That would be more bonus points for the diff to optionally ignore !
A decent visual diff will highlight lines that are different, but also 
show the actual characters that differ (I don't know if viewvc can do that).

> What would be the benefit of such a feature?
Resolving build problems more quickly:
- what changed in the build process from arch to arch ...
- what changed in the bp from fedora release to fedora release ...
- what changed in the bp compare to an earlier version-release ...

However, for the less experienced package maintainers: tell me shortest 
time for you to determine the cause for the failure in:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2260034  -> build.log

Now, would these screen shots from a visual diff program have reduced 
the time for working out both the error, and the cause ?
http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff1.png
http://members.iinet.net.au/~timmsy/rakarrack/meld.rakarrack.diff2.png
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rfc: give koji diff capabilities

[David Timms]

Probably thought of a million times, but was wondering whether it would 
be possible, and useful to give diff capabilities within the koji web 
interface.

eg: x86_64 build
...
Output  build.log  (tail)
 root.log (tail)
 state.log (tail)
could become:
Output  build.log  (tail)  (diff)
 root.log (tail)(diff)
 state.log (tail)   (diff)

hovering over diff would cause a (json) load of options:
- diff -u with other arch:
   i686, ppc, ppc64
- diff -u with other version:
   list other builds in this release (eg devel): 4.3-1, 4.3-4,
- diff -u with other release:
   list other releases of same version that have been built: f12, f13

The diff could be generated to look like a viewvc side by side diff.
Bonus points if the diff ignores things like:
- tmp file names (/var/tmp/rpm-tmp.trZK8P)
- log address: 0x2b9c82662f90
- builder: x86-05.phx2.fedoraproject.org

Previously, I found the build logs rather boring; by saving each 
locally, then running meld on them, I immediately see what has changed 
between eg F12 and devel.

Any comments (other than 'show me the money/code') ?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rpm -q --changelog listing items twice

[David Timms]

On 17/06/10 23:59, Mogens Kjaer wrote:
> On 06/17/2010 03:51 PM, David Timms wrote:
>> Hi, with the recent libcurl/curl updates for F12 I tried a:
>> rpm -q --changelog of each.
>> While curl's changelog looks normal, the information is shown twice for
>> libcurl.
>
> Do you have two libcurl's? (i686 and x86_64)?
>
> That's what I have on a x86_64 F13:
>
> $ rpm -qa | fgrep libcurl
> libcurl-7.20.1-2.fc13.x86_64
> libcurl-7.20.1-2.fc13.i686
> libcurl-devel-7.20.1-2.fc13.x86_64

Aha, two people well on top of the ball. Thanks Ralf and Mogens.
Resolution: rpm -q --changelog libcurl.x86_64
works as expected.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rpm -q --changelog listing items twice

[David Timms]

Hi, with the recent libcurl/curl updates for F12 I tried a:
rpm -q --changelog of each.
While curl's changelog looks normal, the information is shown twice for 
libcurl.

Is this normal for a subpackage ?
Bug in rpm ?
Bug in the package  (while the .spec in cvs looks normal):
http://cvs.fedoraproject.org/viewvc/rpms/curl/F-12/curl.spec?revision=1.139&view=markup

I was going to write a bug, but maybe it is supposed to be this way ?

David.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: main problems of fedora?

[David Timms]

On 18/03/10 05:32, Gergely Buday wrote:
> if such list does not exist, can you name a few missing item from
> fedora? Think of relatively small would-be software, without a GUI.
Not sure if you mean you would like to work on gui interface to existing 
CLI ?

Anyway, I think it would be nice for anaconda installer to grow more 
informative in providing information that indicates it is really doing 
something, rather than possibly hung.

My idea was to lift/use code from gkrellm / gnome system monitor, to 
provide CPU, disk and network graphs, during any part of the install 
process that takes more than 1 second. Whether anyone else would see 
this as useful, you would have to find out.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

review request - pre-review done, needing actual reviewer

[David Timms]

Hi, I would love to get tnef (an ms lookout email attachment lister / 
extractor) review completed for F13 (ie before next week). Anyone 
reviewer like to take a look (I can't convince every acquaintance to 
stop sending ms "rich text" which this application fixes for me :~).

https://bugzilla.redhat.com/show_bug.cgi?id=522920 if interested.

Cheers, David Timms
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

review request - pre-review done, needing actual reviewer

[David Timms]

Hi, I would love to get tnef (an ms lookout email attachment lister / 
extractor) review completed for F13 (ie before next week). Anyone 
reviewer like to take a look (I can't convince every acquaintance to 
stop sending ms "rich text" which this application fixes for me :~).

https://bugzilla.redhat.com/show_bug.cgi?id=522920 if interested.

Cheers, David Timms
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel