These are the spec files that we are using to build rpms for openSUSE. I was wondering if someone won't mind looking at them since I've never build packages for fedora. There packages require mono 2.4 so I'm hoping to be able to provide packages for fedora 11. Some of the specs don't have versions on them. That's because these files are stored in our trunk and the versions get set when we branch and tag.
Thanks!
Stephen
http://anonsvn.mono-project.com/viewvc/trunk/uia2atk/build/specs/
2009/4/30 Stephen Shaw sshaw@decriptor.com
These are the spec files that we are using to build rpms for openSUSE. I was wondering if someone won't mind looking at them since I've never build packages for fedora. There packages require mono 2.4 so I'm hoping to be able to provide packages for fedora 11. Some of the specs don't have versions on them. That's because these files are stored in our trunk and the versions get set when we branch and tag.
Thanks!
Stephen
http://anonsvn.mono-project.com/viewvc/trunk/uia2atk/build/specs/
You will need to restructure the spec layout to fit better with the Fedora way of doing things. Also you are not allowed to use %{_prefix} as that would break our currently terrible Mono packaging guidelines which require that we build Mono stuff as arch - please use %{_libdir} instead.
You need to keep a changelog.
I also believe that adding copyright notices to spec files in generally frowned upon.
AutoReqProv: on seems like SuSE magic and should perish
Release should be > 0
pkgconfig files go in a separate -devel package
I only briefly looked at one spec file but generally it looks like an excellent start
The Banshee spec is a fairly well kept example to go by (just ignore the commented buildrequires, that's maintainer preference and not the general style).
http://cvs.fedoraproject.org/viewvc/rpms/banshee/F-11/banshee.spec?revision=...
Good work Sr. Shaw.
- David
2009/4/30 David Nielsen gnomeuser@gmail.com:
2009/4/30 Stephen Shaw sshaw@decriptor.com
These are the spec files that we are using to build rpms for openSUSE. I was wondering if someone won't mind looking at them since I've never build packages for fedora. There packages require mono 2.4 so I'm hoping to be able to provide packages for fedora 11. Some of the specs don't have versions on them. That's because these files are stored in our trunk and the versions get set when we branch and tag.
Thanks!
Stephen
http://anonsvn.mono-project.com/viewvc/trunk/uia2atk/build/specs/
You will need to restructure the spec layout to fit better with the Fedora way of doing things. Also you are not allowed to use %{_prefix} as that would break our currently terrible Mono packaging guidelines which require that we build Mono stuff as arch - please use %{_libdir} instead.
You need to keep a changelog.
I also believe that adding copyright notices to spec files in generally frowned upon.
AutoReqProv: on seems like SuSE magic and should perish
Release should be > 0
pkgconfig files go in a separate -devel package
I only briefly looked at one spec file but generally it looks like an excellent start
The Banshee spec is a fairly well kept example to go by (just ignore the commented buildrequires, that's maintainer preference and not the general style).
http://cvs.fedoraproject.org/viewvc/rpms/banshee/F-11/banshee.spec?revision=...
Good work Sr. Shaw.
- David
Thanks!!! I'll start looking into that. I'll take the first one and see if I can get it updated and then when its mostly in shape I'll update the others
Cheers, Stephen
2009/4/30 David Nielsen gnomeuser@gmail.com:
You will need to restructure the spec layout to fit better with the Fedora way of doing things. Also you are not allowed to use %{_prefix} as that would break our currently terrible Mono packaging guidelines which require that we build Mono stuff as arch - please use %{_libdir} instead.
You need to keep a changelog.
I added it for the fedora packages. Usually with the openSUSE build service there is a .changes file that gets updated and it then reformats and auto appends it to the spec file.
I also believe that adding copyright notices to spec files in generally frowned upon.
I removed this from out spec files as well.
AutoReqProv: on seems like SuSE magic and should perish
It turns out that this has been deprecated, so its removed from the openSUSE rpms too now.
Release should be > 0
Easy fix :) The openSUSE build service auto increments this and that's why it was zero. In the end it was irrelevant making it an easy change.
pkgconfig files go in a separate -devel package
Not all of the packages have a .pc file. We had talked about this in our group and decided to put them in the same rpm as these are all library type files. So, in a way I would guess that the whole rpm is really just a devel package.
What do you think?
I only briefly looked at one spec file but generally it looks like an excellent start
The Banshee spec is a fairly well kept example to go by (just ignore the commented buildrequires, that's maintainer preference and not the general style).
http://cvs.fedoraproject.org/viewvc/rpms/banshee/F-11/banshee.spec?revision=...
I created a directory in svn for fedora - http://anonsvn.mono-project.com/viewvc/trunk/uia2atk/build/specs/fedora/
Thanks, Stephen
Stephen Shaw wrote:
2009/4/30 David Nielsen gnomeuser@gmail.com:
pkgconfig files go in a separate -devel package
Not all of the packages have a .pc file. We had talked about this in our group and decided to put them in the same rpm as these are all library type files. So, in a way I would guess that the whole rpm is really just a devel package.
What do you think?
The issue is keeping development files and runtime files separate. Usually libraries are runtime dependencies and you don't want them dragging in the dep chain of development packages on install.
If a package doesn't have a .pc file but only runtime libraries then you wouldn't need a -devel subpackage.
-Toshio
pkgconfig files go in a separate -devel package
sorry it took me so long to get back to this. I've made this change to the packages. I was hoping that someone would be about to review them.
Thanks, Stephen
PS. If its any easier, here is the svn link http://anonsvn.mono-project.com/viewvc/trunk/uia2atk/build/specs/fedora/
2009/5/20 Stephen Shaw sshaw@decriptor.com
pkgconfig files go in a separate -devel package
sorry it took me so long to get back to this. I've made this change to the packages. I was hoping that someone would be about to review them.
Using the uiautomation.spec as the example since that had the newest change time according to svn.
For purely managed code currently, due entirely to stupidity on the part of the Mono packaging guidelines, currently you need to add:
%define debug_package %{nil}
Or you will end up with an empty debug package, It is prefered to be at the very first line of the spec file.
Source: needs to be a full valid URL (for something like codeplex where direct downloading isn't possible because of clickthrough licenses add a comment). E.g.
Source0: http://banshee-project.org/files/banshee/banshee-1-%%7Bversion%7D.tar.bz2
Your buildroot isn't unique and thus can cause problems, the prefered standard is:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Group is 2 steps deep:
Invalid: Group: Development/Languages/Mono
Valid: Group: Development/Libraries
Your use of the license tag is invalid:
Invalid: License: MIT/X11
Valid: License: MIT
If you fail using parallel make:
make %{?_smp_mflags}
then you need to add a comment referencing the filed bug documenting.
%install needs to start by cleaning up, e.g.
%install rm -rf %{buildroot}
Also please keep package descriptions at the top of the spec and have separate %files entries at the buttom, mixing them is bad style.
You should probably also work on the description, it can stand to be a little bit cleaner and possibly lose the coding jargon. Remember this is what users see, something along the lines of:
"User Interface Automation (UIA) is an advanced accessibility framework for use with Mono".
You should also avoid the "politics" in descriptions:
The Mono Project is an open development initiative that is working to develop an open source, Unix version of the .NET development platform. Its objective is to enable Unix developers to build and deploy cross-platform .NET applications. The project will implement various technologies that have been submitted to the ECMA for standardization.
Parts of winfx
Maybe could be:
"User Interface Automation (UIA) WinFX components for use with Mono"
Finally in the changelog please append the release:
Bad:
* Thu Apr 30 2009 Stephen Shaw sshaw@decriptor.com - 1.0
Good:
* Thu Apr 30 2009 Stephen Shaw sshaw@decriptor.com - 1.0-1
This lets us see what happened at specific releases.
Aside that you look good, once these are fixed I will attempt a mock build and see if that and rpmlint will throw up any dirt.
- David
On 05/20/2009 01:30 PM, David Nielsen wrote:
For purely managed code currently, due entirely to stupidity on the part of the Mono packaging guidelines, currently you need to add:
%define debug_package %{nil}
Note, I joined in a thread on mono-dev recently about whether to package mono CLI's in /usr/share or /usr/lib64. Unfortunately, Miguel's reply to CLI code being arch independent was basically, I don't know if it is and if it is we don't guarantee that it will stay that way in subsequent mono releases. Not very helpful. He also didn't reply at all to my question of why mono is using %{prefix}/lib instead of %{libdir} everywhere which was also not very helpful.
If anyone cares to join in, that would be great because I can't keep pressing for changes and clarifications without more assistance.
-Toshio
2009/5/20 Toshio Kuratomi a.badger@gmail.com
On 05/20/2009 01:30 PM, David Nielsen wrote:
For purely managed code currently, due entirely to stupidity on the part of the Mono packaging guidelines, currently you need to add:
%define debug_package %{nil}
Note, I joined in a thread on mono-dev recently about whether to package mono CLI's in /usr/share or /usr/lib64. Unfortunately, Miguel's reply to CLI code being arch independent was basically, I don't know if it is and if it is we don't guarantee that it will stay that way in subsequent mono releases. Not very helpful. He also didn't reply at all to my question of why mono is using %{prefix}/lib instead of %{libdir} everywhere which was also not very helpful.
If anyone cares to join in, that would be great because I can't keep pressing for changes and clarifications without more assistance.
The best bet for getting those packaging questions answered is not from Miguel. He isn't a packaging guy. However you can ask the Debian pkg-mono group, they have years of experience working with Mono packaging and have a very well written set of guidelines, I would be willing to say that the lead developer there know more about the little caveats involved with packaging than Novells Mono developers.
Fedora currently is the odd man out in terms of packaging managed code as arch dependent, one of the big plans I had for the SIG was to find a way to change that and bring us more in line with what everyone else is doing including upstream. It would make it much easier for us to share work, e.g. I would love to import the size reduction work Debian and Ubuntu have been doing (which recently was shown to make Banshee plus deps take up less space than rhythmbox plus deps on the livecd, something I find attractive). Optimally we could get some upstream guidelines but second to that would be a tenative agreement with openSUSE and Debian to use similar guidelines.
- David
On 05/20/2009 03:40 PM, David Nielsen wrote:
2009/5/20 Toshio Kuratomi <a.badger@gmail.com mailto:a.badger@gmail.com>
On 05/20/2009 01:30 PM, David Nielsen wrote: > > For purely managed code currently, due entirely to stupidity on the part > of the Mono packaging guidelines, currently you need to add: > > %define debug_package %{nil} > Note, I joined in a thread on mono-dev recently about whether to package mono CLI's in /usr/share or /usr/lib64. Unfortunately, Miguel's reply to CLI code being arch independent was basically, I don't know if it is and if it is we don't guarantee that it will stay that way in subsequent mono releases. Not very helpful. He also didn't reply at all to my question of why mono is using %{prefix}/lib instead of %{libdir} everywhere which was also not very helpful. If anyone cares to join in, that would be great because I can't keep pressing for changes and clarifications without more assistance.The best bet for getting those packaging questions answered is not from Miguel. He isn't a packaging guy. However you can ask the Debian pkg-mono group, they have years of experience working with Mono packaging and have a very well written set of guidelines, I would be willing to say that the lead developer there know more about the little caveats involved with packaging than Novells Mono developers.
Debian actually is doing things a bit strangely. They are using /usr/lib which is their place for architecture dependent binaries but their packages are marked architecture independent. If we were to do the same in Fedora we'd be able to dispense with things like defining debug but we would still have to patch files to place them in %{_datadir}. (Unless Debian has a reason for not placing them in /usr/share. The reason that I saw given, though, was that the binaries were architecture dependent, given by Miguel on the Debian lists).
there's a lot of good stuff in the Debian Guidelines. If someone cares about mono on Fedora, it would be great to get those incorporated into the Fedora Guidelines.
http://pkg-mono.alioth.debian.org/cli-policy/index.html
-Toshio
2009/5/21 David Nielsen gnomeuser@gmail.com
Fedora currently is the odd man out in terms of packaging managed code as arch dependent, one of the big plans I had for the SIG was to find a way to change that and bring us more in line with what everyone else is doing including upstream.
I've started the packaging of Chronojump + nplot-gtk. I've being taking some notes in order to propose the enhance of the guidelines but I'm not the most experiencied guy for proposing them.
Could you suggest a working agenda for doing this? Seems to me you have a clear idea of what you want to achieve.
2009/5/23 Ismael Olea ismael@olea.org
2009/5/21 David Nielsen gnomeuser@gmail.com
Fedora currently is the odd man out in terms of packaging managed code as arch dependent, one of the big plans I had for the SIG was to find a way to change that and bring us more in line with what everyone else is doing including upstream.
I've started the packaging of Chronojump + nplot-gtk. I've being taking some notes in order to propose the enhance of the guidelines but I'm not the most experiencied guy for proposing them.
Could you suggest a working agenda for doing this? Seems to me you have a clear idea of what you want to achieve.
Poke me on Monday, while my access to fedora cvs is utterly broken I can help out translating the pkg-mono work into Fedora speak. I have also been in contact with Ubuntu's directhex (Jo Shields) to help us adapt the work they did to obsolete mono 1.0 to space savings and performance increases.
I think the top issues would be debating what the road ahead for pure managed code is. Personally I sway towards making it noarch and putting it in %{_datadir} but that is somthing worth debating and seeking input from upstream and other downstream vendors on. Ideally this work would go towards making a set of downstream packaging guidelines for everyone to lean on.
I think our guidelines should handle:
pure managed code mixed managed and unmanaged code monodoc documentation generation handling of debuginfo Insertion of .dll into the GAC Use of system libraries obsoleting Mono 1.0 support
I ,quickly and without much thought, propose the following:
Pure managed code is noarch and goes into %{_datadir} (I believe this is similar to what python does in Fedora)
Mixed code is by definition arch (compile failures for these must be clearly commented and bugs filed with polite requests for our arch teams to help), we also need to review which Fedora supported platforms currently has Mono and craft a new ExclusiveArchs string or similar manner of handling these cases. Thanks to the nice people at IBM we now have Mono on ppc64 e.g. and everything we have packaged so far ignores this arch.
If your package has documentation it must be built and put in a separate package, the correct monodoc magic must be invoked and the correct requires applied.
debuginfo I am sketchy on, there are good reasons to keep this as part of the package since mono handles debugging differently from most code and it is only enabled when you run with the --debug switch. The only saving we get thus from splitting them out is diskspace savings, this would be important mainly for getting on the desktop livecd (where it has already been made abundently clear that we are second class citizens and generally unwelcome). I doubt this is worth the work. However Jeremy Katz has been kind enough to create a patch to make this possible, it is untested so we would need to evaluate this heavily.
Occasionally you may need to insert a library into the GAC, we need guidelines for when and how to do this correctly. For most packages this happens automatically but there are cases where we need to do it manaually and for those we need clear guidelines for packagers. Investigation is needed here, I don't yet know enough about this specific area, generally I do what pkg-mono does here as they generally have a good hold on how to wangle this beast.
I would propose that every package should delete all prepackaged .dll files prior to configuration to ensure that we are not building against bundled libraries, if this is impossible the package is not suitable for Fedora without patching.
Mono 1.0 support should be obsoleted where we can, if upstream willtake patches that is good otherwise we need to carry them. It is a significant gain in performance and a substantial saving on disk. It is well worth the effort and should be made policy. We need a guideline for how to do this for packagers.
- david
Using the uiautomation.spec as the example since that had the newest change time according to svn.
For purely managed code currently, due entirely to stupidity on the part of the Mono packaging guidelines, currently you need to add:
%define debug_package %{nil}
Or you will end up with an empty debug package, It is prefered to be at the very first line of the spec file.
ok, I added this to all of them except uiaatkbridge because it does have a c library in it
Source: needs to be a full valid URL (for something like codeplex where direct downloading isn't possible because of clickthrough licenses add a comment). E.g.
Source0: http://banshee-project.org/files/banshee/banshee-1-%%7Bversion%7D.tar.bz2
I added this to all of them except uiadbuscorebridge since that hasn't officially been released
Your buildroot isn't unique and thus can cause problems, the prefered standard is:
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
I updated this in all of them. With openSUSE they generate fresh jails on top of xen on the fly for everybuild so thi build root really doesn't matter. That is why they were really simple
Group is 2 steps deep:
Invalid: Group: Development/Languages/Mono
Valid: Group: Development/Libraries
Updated
Your use of the license tag is invalid:
Invalid: License: MIT/X11
Valid: License: MIT
should I add another line in there for X11 or is MIT good enough?
If you fail using parallel make:
make %{?_smp_mflags}
then you need to add a comment referencing the filed bug documenting.
I've added this, but had previously left it out since there really isn't much to build in these packages. They all tend to build within a few minutes
%install needs to start by cleaning up, e.g.
%install rm -rf %{buildroot}
Added.
Also please keep package descriptions at the top of the spec and have separate %files entries at the buttom, mixing them is bad style.
Fixed.
You should probably also work on the description, it can stand to be a little bit cleaner and possibly lose the coding jargon. Remember this is what users see, something along the lines of:
"User Interface Automation (UIA) is an advanced accessibility framework for use with Mono".
Maybe fixed :)
You should also avoid the "politics" in descriptions:
The Mono Project is an open development initiative that is working to develop an open source, Unix version of the .NET development platform.
Its objective is to enable Unix developers to build and deploy cross-platform .NET applications. The project will implement various technologies that have been submitted to the ECMA for standardization.
That was just something I pulled from the upstream package... removed.
Parts of winfx
Maybe could be:
"User Interface Automation (UIA) WinFX components for use with Mono"
Changed.
Finally in the changelog please append the release:
Bad:
- Thu Apr 30 2009 Stephen Shaw sshaw@decriptor.com - 1.0
Good:
- Thu Apr 30 2009 Stephen Shaw sshaw@decriptor.com - 1.0-1
This lets us see what happened at specific releases.
updated.
Aside that you look good, once these are fixed I will attempt a mock build and see if that and rpmlint will throw up any dirt.
- David
Thanks, Stephen
http://anonsvn.mono-project.com/viewvc/trunk/uia2atk/build/specs/fedora/
2009/5/20 Stephen Shaw sshaw@decriptor.com
Using the uiautomation.spec as the example since that had the newest
change
time according to svn.
For purely managed code currently, due entirely to stupidity on the part
of
the Mono packaging guidelines, currently you need to add:
%define debug_package %{nil}
Or you will end up with an empty debug package, It is prefered to be at
the
very first line of the spec file.
ok, I added this to all of them except uiaatkbridge because it does have a c library in it
Perfect
Source: needs to be a full valid URL (for something like codeplex where direct downloading isn't possible because of clickthrough licenses add a comment). E.g.
Source0: http://banshee-project.org/files/banshee/banshee-1-%%7Bversion%7D.tar.bz2http://banshee-project.org/files/banshee/banshee-1-%%7Bversion%7D.tar.bz2
I added this to all of them except uiadbuscorebridge since that hasn't
officially been released
Then we can't ship it, unless you do a svn shapshot (I will find you are reference for doing that when we get that far). The tarball has to be reproducable either as a vetted download or a SVN snapshot that can be repeated.
I updated this in all of them. With openSUSE they generate fresh jails on top of xen on the fly for everybuild so thi build root really doesn't matter. That is why they were really simple
It's one of those things that annoy me about rpm, why do I need to define this.. make the default sane and let me overwrite it if I have a good reason. I think Fedora does this mostly for belt and suspender reasons but really that is a question for the buildsystem guys. It never hurts to do it right though.
should I add another line in there for X11 or is MIT good enough?
MIT is all you need if that is the sole license covering your code. There is also no need to put the license tag on your subpackages, unless a different license applies to them.
I've added this, but had previously left it out since there really isn't much to build in these packages. They all tend to build within a few minutes
It's a standard thing in Fedora, it tends to catch bugs and we are apparently all about correctness. Neat code, neat packages and all.
You still need to review all your summaries and descriptions, but this is a minor thing. One issue though, there are trademark issues with certain things and a policy to deal with them but if you could avoid mention things like Microsoft or MS we wouldn't have to venture into that set of guidelines (oh the jungle we have created).
Problems still:
just placing the descriptions under the package data isn't enough, it needs to be e.g.
%description devel
or rpm tends to get very upset. In the same vein adding -n to the subpackage name isn't needed.
%defattr(-, root, root)
Should be:
%defattr(-, root, root,-)
unless there is a good reason not to.
cases like:
Requires: mono-uia == %{version}-%{release}
Should always be:
Requires: %{name} == %{version}-%{release}
Now the worst renaming issue, the spec file needs to be mono-uia not uiautomation.spec - package name and spec file must be the same unless there is good reason (e.g. the mirage plugin for banshee is banshee-mirage.spec)
We are so close to something that builds I can smell it. Thanks for doing this Stephen.
- David
2009/5/21 David Nielsen gnomeuser@gmail.com
We are so close to something that builds I can smell it. Thanks for doing this Stephen.
and yet so far, I did the changes locally, btw. the -n thing extends to %files
You do not honor --libdir and thus all the files end up in /usr/lib for x86_64 where it needs to be in /usr/lib
Please consider the attached completely untested patch.
- David
2009/5/21 David Nielsen gnomeuser@gmail.com
2009/5/21 David Nielsen gnomeuser@gmail.com
We are so close to something that builds I can smell it. Thanks for doing this Stephen.
and yet so far, I did the changes locally, btw. the -n thing extends to %files
You do not honor --libdir and thus all the files end up in /usr/lib for x86_64 where it needs to be in /usr/lib
Please consider the attached completely untested patch.
- David
And mono-uia fails with parallel make:
gmcs -lib:/usr/lib64/mono/2.0 -lib:../bin -lib:/usr/lib64/mono/accessibility -noconfig -codepage:utf8 -warn:4 -warnaserror -optimize+ -debug "-define:DEBUG" -d:NET_2_0 -out:../bin/UIAutomationProvider.dll -target:library './AssemblyInfo.cs' './../build/common/*.cs' './System.Windows.Automation.Provider/AutomationInteropProvider.cs' './System.Windows.Automation.Provider/ICaretProvider.cs' './System.Windows.Automation.Provider/IClipboardProvider.cs' './System.Windows.Automation.Provider/IDockProvider.cs' './System.Windows.Automation.Provider/IEditableRangeProvider.cs' './System.Windows.Automation.Provider/IEmbeddedImageProvider.cs' './System.Windows.Automation.Provider/IExpandCollapseProvider.cs' './System.Windows.Automation.Provider/IGridItemProvider.cs' './System.Windows.Automation.Provider/IGridProvider.cs' './System.Windows.Automation.Provider/IInsertDeleteTextProvider.cs' './System.Windows.Automation.Provider/IInvokeProvider.cs' './System.Windows.Automation.Provider/IMultipleViewProvider.cs' './System.Windows.Automation.Provider/IRangeValueProvider.cs' './System.Windows.Automation.Provider/IRawElementProviderAdviseEvents.cs' './System.Windows.Automation.Provider/IRawElementProviderFragment.cs' './System.Windows.Automation.Provider/IRawElementProviderFragmentRoot.cs' './System.Windows.Automation.Provider/IRawElementProviderHwndOverride.cs' './System.Windows.Automation.Provider/IRawElementProviderSimple.cs' './System.Windows.Automation.Provider/IScrollItemProvider.cs' './System.Windows.Automation.Provider/IScrollProvider.cs' './System.Windows.Automation.Provider/ISelectionItemProvider.cs' './System.Windows.Automation.Provider/ISelectionProvider.cs' './System.Windows.Automation.Provider/ITableItemProvider.cs' './System.Windows.Automation.Provider/ITableProvider.cs' './System.Windows.Automation.Provider/ITextProvider.cs' './System.Windows.Automation.Provider/ITextRangeProvider.cs' './System.Windows.Automation.Provider/IToggleProvider.cs' './System.Windows.Automation.Provider/ITransformProvider.cs' './System.Windows.Automation.Provider/IValueProvider.cs' './System.Windows.Automation.Provider/IWindowProvider.cs' './System.Windows.Automation.Provider/NavigateDirection.cs' './System.Windows.Automation.Provider/ProviderOptions.cs' -r:WindowsBase -r:System -r:UIAutomationBridge -r:UIAutomationTypes sn -q -R ../bin/UIAutomationProvider.dll ../mono.snk sn -q -R ../bin/UIAutomationProvider.dll ../mono.snk ERROR: Unknown error during processing: System.IO.IOException: Sharing violation on path /home/david/rpmbuild/BUILD/mono-uia-1.0/bin/UIAutomationProvider.dll at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) at System.IO.File.OpenWrite (System.String path) [0x00000] at Mono.Security.StrongName.Sign (System.String fileName) [0x00000] at Mono.Tools.SN.ReSign (System.String assemblyName, System.Security.Cryptography.RSA key) [0x00000] at Mono.Tools.SN.Process (System.String[] args) [0x00000] at Mono.Tools.SN.Main (System.String[] args) [0x00000] make[1]: *** [../bin/UIAutomationProvider.dll.mdb] Fejl 1 make[1]: *** Venter på uafsluttede job.... Assembly ../bin/UIAutomationProvider.dll signed. make[1]: Forlader katalog '/home/david/rpmbuild/BUILD/mono-uia-1.0/UIAutomationProvider' make: *** [all-recursive] Fejl 1 fejl: Fejl-afslutningsstatus fra /var/tmp/rpm-tmp.skGLqH (%build)
Aside that with the changes made locally and the patch applied everything now builds and things seem to be in a good mood.
Some rpmlint output to worry slightly about:
mono-uia.src: E: description-line-too-long User Interface Automation (UIA) is a new accessibility standard for use with Mono mono-uia.src: W: non-standard-group System/Libraries mono-uia-mono-uia-devel.x86_64: W: summary-not-capitalized mono-uia devel package
Nothing major, so I think with those changes we are in good shape for the Fedora guidelines.
- David
2009/5/21 David Nielsen gnomeuser@gmail.com
We are so close to something that builds I can smell it. Thanks for doing this Stephen.
and yet so far, I did the changes locally, btw. the -n thing extends to %files
You do not honor --libdir and thus all the files end up in /usr/lib for x86_64 where it needs to be in /usr/lib
Please consider the attached completely untested patch.
- David
And mono-uia fails with parallel make:
gmcs -lib:/usr/lib64/mono/2.0 -lib:../bin -lib:/usr/lib64/mono/accessibility
<snip>
make: *** [all-recursive] Fejl 1 fejl: Fejl-afslutningsstatus fra /var/tmp/rpm-tmp.skGLqH (%build)
Aside that with the changes made locally and the patch applied everything now builds and things seem to be in a good mood.
Some rpmlint output to worry slightly about:
mono-uia.src: E: description-line-too-long User Interface Automation (UIA) is a new accessibility standard for use with Mono mono-uia.src: W: non-standard-group System/Libraries mono-uia-mono-uia-devel.x86_64: W: summary-not-capitalized mono-uia devel package
Nothing major, so I think with those changes we are in good shape for the Fedora guidelines.
- David
I'll try and get those changes in within the next hour
Thanks, Stephen
PS. The uiadbuscorebridge is still a work in progress. I just wanted to make sure that it was in good shape. I'll planning on trying to make our, openSUSE, spec files as similar to the fedora ones as possible
Some rpmlint output to worry slightly about:
mono-uia.src: E: description-line-too-long User Interface Automation (UIA) is a new accessibility standard for use with Mono
I shorten it a little. I hope that it works now.
mono-uia.src: W: non-standard-group System/Libraries
I thought this was a standard group... What do you recommend?
mono-uia-mono-uia-devel.x86_64: W: summary-not-capitalized mono-uia devel package
This has to do with the acronym. Do we ignore this?
Nothing major, so I think with those changes we are in good shape for the Fedora guidelines.
- David
As for the patch, I don't think we will appear it as all of our work is on openSUSE and the UIA stuff is really part of the .NET framework or at least mono-uia is. We have to play by the mono team's rules.
Thanks, Stephen
On Thu, May 21, 2009 at 9:18 AM, Stephen Shaw sshaw@decriptor.com wrote:
Some rpmlint output to worry slightly about:
mono-uia.src: E: description-line-too-long User Interface Automation (UIA) is a new accessibility standard for use with Mono
I shorten it a little. I hope that it works now.
mono-uia.src: W: non-standard-group System/Libraries
I thought this was a standard group... What do you recommend?
mono-uia-mono-uia-devel.x86_64: W: summary-not-capitalized mono-uia devel package
This has to do with the acronym. Do we ignore this?
Nothing major, so I think with those changes we are in good shape for the Fedora guidelines.
- David
As for the patch, I don't think we will appear it as all of our work is on openSUSE and the UIA stuff is really part of the .NET framework or at least mono-uia is. We have to play by the mono team's rules.
Thanks, Stephen
Ooops, forgot to checkin the changes :) I've checked them as well as adding your patch to that directory.
-Stephen
Any chance that someone was able to test out those spec files? They should have fedora 11 in the openSUSE Build Service soon, so as soon as they do that I can test them here as well. Should I be creating bugs for each of these spec files?
Thanks, Stephen
2009/6/11 Stephen Shaw sshaw@decriptor.com
Any chance that someone was able to test out those spec files? They should have fedora 11 in the openSUSE Build Service soon, so as soon as they do that I can test them here as well. Should I be creating bugs for each of these spec files?
I apologize for not having had time to do this work, but I will see to it tomorrow. I have been buried in other work for a while but tomorrow should present a few hours of peace and quiet to test these for you.
Also congratulations on your newly appointed openSUSE council seat.
- David
2009/6/12 David Nielsen gnomeuser@gmail.com:
2009/6/11 Stephen Shaw sshaw@decriptor.com
Any chance that someone was able to test out those spec files? They should have fedora 11 in the openSUSE Build Service soon, so as soon as they do that I can test them here as well. Should I be creating bugs for each of these spec files?
I apologize for not having had time to do this work, but I will see to it tomorrow. I have been buried in other work for a while but tomorrow should present a few hours of peace and quiet to test these for you.
Also congratulations on your newly appointed openSUSE council seat.
- David
Thanks!!! I figured that I'd add that as well since I don't have a ton of thing on my plate ;)
Also, thanks for taking a look at the packages... I did move the fedora directory up a level. I'm not sure what's taking so long to get fedora up and running on the openSUSE Board System, but as soon as its there I'll start trying to get them up there as well.
Thanks, Stephen
2009/6/12 Stephen Shaw sshaw@decriptor.com
2009/6/12 David Nielsen gnomeuser@gmail.com:
2009/6/11 Stephen Shaw sshaw@decriptor.com
Any chance that someone was able to test out those spec files? They should have fedora 11 in the openSUSE Build Service soon, so as soon as they do that I can test them here as well. Should I be creating bugs for each of these spec files?
I apologize for not having had time to do this work, but I will see to it tomorrow. I have been buried in other work for a while but tomorrow
should
present a few hours of peace and quiet to test these for you.
Also congratulations on your newly appointed openSUSE council seat.
- David
Thanks!!! I figured that I'd add that as well since I don't have a ton of thing on my plate ;)
Also, thanks for taking a look at the packages... I did move the fedora directory up a level. I'm not sure what's taking so long to get fedora up and running on the openSUSE Board System, but as soon as its there I'll start trying to get them up there as well.
Thanks, Stephen
First up:
the base build mono-uia which we have reviewed still do not apply the patch I provided which means it will not assemble a valid rpm on Fedora x86_64. Then when you try to install it in asks for mono(WindowsBase) 3.0.0.0 I assume our winforms or something requires updating but I will need your insight here.
http://ftp.novell.com/pub/mono/sources/uiadbuscorebridge/ doesn't exist so I can't get the uiadbuscorebridge source so that one I have left out.
The remaining rpms you need to replace %_libdir with %{_libdir} and I assume that these also need a similar patch as mono-uia to create valid rpms on x86_64 for Fedora. Since I can't install mono-uia and these depend on it I can't test them. I have attached proposed and naturally untested patches for these. These patches must be applied in the spec for Fedora, there is no need to push them upstream if you do not desire but they are required for Fedora.
Finally you should probably clean up those commented out dependencies for a cosmeticly pleasing result.
-David
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/12 Stephen Shaw sshaw@decriptor.com
2009/6/12 David Nielsen gnomeuser@gmail.com:
2009/6/11 Stephen Shaw sshaw@decriptor.com
Any chance that someone was able to test out those spec files? They should have fedora 11 in the openSUSE Build Service soon, so as soon as they do that I can test them here as well. Should I be creating bugs for each of these spec files?
I apologize for not having had time to do this work, but I will see to
it
tomorrow. I have been buried in other work for a while but tomorrow
should
present a few hours of peace and quiet to test these for you.
Also congratulations on your newly appointed openSUSE council seat.
- David
Thanks!!! I figured that I'd add that as well since I don't have a ton of thing on my plate ;)
Also, thanks for taking a look at the packages... I did move the fedora directory up a level. I'm not sure what's taking so long to get fedora up and running on the openSUSE Board System, but as soon as its there I'll start trying to get them up there as well.
Thanks, Stephen
First up:
the base build mono-uia which we have reviewed still do not apply the patch I provided which means it will not assemble a valid rpm on Fedora x86_64. Then when you try to install it in asks for mono(WindowsBase) 3.0.0.0 I assume our winforms or something requires updating but I will need your insight here.
Well doh, it helps when I actually install the mono-wincorefx package. Okay time for more coffee
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/12 Stephen Shaw sshaw@decriptor.com
2009/6/12 David Nielsen gnomeuser@gmail.com:
2009/6/11 Stephen Shaw sshaw@decriptor.com
Any chance that someone was able to test out those spec files? They should have fedora 11 in the openSUSE Build Service soon, so as soon as they do that I can test them here as well. Should I be creating bugs for each of these spec files?
I apologize for not having had time to do this work, but I will see to
it
tomorrow. I have been buried in other work for a while but tomorrow
should
present a few hours of peace and quiet to test these for you.
Also congratulations on your newly appointed openSUSE council seat.
- David
Thanks!!! I figured that I'd add that as well since I don't have a ton of thing on my plate ;)
Also, thanks for taking a look at the packages... I did move the fedora directory up a level. I'm not sure what's taking so long to get fedora up and running on the openSUSE Board System, but as soon as its there I'll start trying to get them up there as well.
Thanks, Stephen
First up:
the base build mono-uia which we have reviewed still do not apply the patch I provided which means it will not assemble a valid rpm on Fedora x86_64. Then when you try to install it in asks for mono(WindowsBase) 3.0.0.0 I assume our winforms or something requires updating but I will need your insight here.
Well doh, it helps when I actually install the mono-wincorefx package. Okay time for more coffee
In Fedora 11 we only have gtk-sharp2-2.12.7-4.fc11.x86_64
Is there a special reason you require 2.12.8 or can we lower the requirement? If not I will need to request an update of this package before we can proceed.
On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/12 Stephen Shaw sshaw@decriptor.com
2009/6/12 David Nielsen gnomeuser@gmail.com:
2009/6/11 Stephen Shaw sshaw@decriptor.com
Any chance that someone was able to test out those spec files?
They
should have fedora 11 in the openSUSE Build Service soon, so as
soon
as they do that I can test them here as well. Should I be creating bugs for each of these spec files?
I apologize for not having had time to do this work, but I will
see to it
tomorrow. I have been buried in other work for a while but
tomorrow should
present a few hours of peace and quiet to test these for you.
Also congratulations on your newly appointed openSUSE council seat.
- David
Thanks!!! I figured that I'd add that as well since I don't have a ton of thing on my plate ;)
Also, thanks for taking a look at the packages... I did move the fedora directory up a level. I'm not sure what's taking so long to get fedora up and running on the openSUSE Board System, but as soon as its there I'll start trying to get them up there as well.
Thanks, Stephen
First up:
the base build mono-uia which we have reviewed still do not apply the patch I provided which means it will not assemble a valid rpm on Fedora x86_64. Then when you try to install it in asks for mono(WindowsBase) 3.0.0.0 I assume our winforms or something requires updating but I will need your insight here.
Well doh, it helps when I actually install the mono-wincorefx package. Okay time for more coffee
In Fedora 11 we only have gtk-sharp2-2.12.7-4.fc11.x86_64
Is there a special reason you require 2.12.8 or can we lower the requirement? If not I will need to request an update of this package before we can proceed. _____________________________
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
As for the dbus package, please ignore it for now. I was purely interested in making sure that the spec file was ready.
As soon as I get to my computer I'll look at those patch and either apply them or put them I'm the fedora directory in svn. Since openSUSE is the primary target we have to play by the mono teams rules. Infortunately it's the odd one out. Maybe one day? I'm going to at least try to keep our spec files as closer as I can other then the arch issue.
Thanks again!!! Stephen
2009/6/13 Stephen Shaw sshaw@decriptor.com
On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
Awesome is my middle name.. or is it Modest I forget. Okay if there is a hard requirement on 2.12.8 for a11y reasons then I will file a bug with gtk-sharp2 and ask for an update. I believe it will be required for Banshee 1.5.1 or above as well for atk support so we might as well serve our users. Till that goes through we are stuck with the review sadly.
As for the dbus package, please ignore it for now. I was purely interested in making sure that the spec file was ready.
okay I will finish that review once it is ready then.
As soon as I get to my computer I'll look at those patch and either apply them or put them I'm the fedora directory in svn. Since openSUSE is the primary target we have to play by the mono teams rules. Infortunately it's the odd one out. Maybe one day? I'm going to at least try to keep our spec files as closer as I can other then the arch issue.
I have been thinking, there is a concerning lack of uniformity, parhaps in your newfound capacity as an openSUSE deity I could ask you to help put some rock into this. I have been thinking it would be good to get pkg-mono debian, Fedora, openSUSE and upstream Mono to sit down and draft a set of guidelines for packaging to get some uniformity. While you upstream guys do great code it is definitely not as easy to package as it could be and having common upstream blessed guidelines would really easy both our jobs and I suspect general acceptance of Mono. Right now bad packaging makes things suck rather badly.
Once you are ready though I would suggest submitting these to Fedora as well as the OBS. It would be nice to have all of this a11y stuff available for our users and as upstream I am sure you will make the right decisions on how to work this out. Plus more users to expose your bugs can't hurt.. much.
- David
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 Stephen Shaw sshaw@decriptor.com
On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
Awesome is my middle name.. or is it Modest I forget. Okay if there is a hard requirement on 2.12.8 for a11y reasons then I will file a bug with gtk-sharp2 and ask for an update. I believe it will be required for Banshee 1.5.1 or above as well for atk support so we might as well serve our users. Till that goes through we are stuck with the review sadly.
update progress can be followed here: https://bugzilla.redhat.com/show_bug.cgi?id=505751
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 Stephen Shaw sshaw@decriptor.com
On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
Awesome is my middle name.. or is it Modest I forget. Okay if there is a hard requirement on 2.12.8 for a11y reasons then I will file a bug with gtk-sharp2 and ask for an update. I believe it will be required for Banshee 1.5.1 or above as well for atk support so we might as well serve our users. Till that goes through we are stuck with the review sadly.
update progress can be followed here: https://bugzilla.redhat.com/show_bug.cgi?id=505751
With a locally updated gtk-sharp2 I noticed that uiaatkbridge.spec has a dependence simply on 2.24 which seems to be a leftover from a clean up. Please remove or the package is non-installable.
uiautomationwinforms has a dependency on glib-sharp2 which isn't in Fedora as a separate package, however it is in gtk-sharp2. With that fixed it fails to build here:
test -z "/usr/lib64/uiautomationwinforms" || /bin/mkdir -p "/home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/uiautomationwinforms" /usr/bin/install -c 'bin/Debug/UIAutomationWinforms.dll' '/home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/uiautomationwinforms/UIAutomationWinforms.dll' /usr/bin/gacutil /i bin/Debug/UIAutomationWinforms.dll /f /root /home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib || exit 1; Failure adding assembly bin/Debug/UIAutomationWinforms.dll to the cache: Strong name cannot be verified for delay-signed assembly make[2]: *** [gac-install] Error 1 make[2]: Leaving directory `/home/david/rpmbuild/BUILD/uiautomationwinforms-1.0/UIAutomationWinforms' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/david/rpmbuild/BUILD/uiautomationwinforms-1.0/UIAutomationWinforms' make: *** [install-recursive] Error 1 fejl: Fejl-afslutningsstatus fra /var/tmp/rpm-tmp.8py1wX (%install)
Which looks like I missed a hardcoded reference to prefix/lib somewhere.
Generally if you br on a -devel package you do not need to have a requires for it as well, applying those clean ups would improve the specs.
- David
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 Stephen Shaw sshaw@decriptor.com
On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
Awesome is my middle name.. or is it Modest I forget. Okay if there is a hard requirement on 2.12.8 for a11y reasons then I will file a bug with gtk-sharp2 and ask for an update. I believe it will be required for Banshee 1.5.1 or above as well for atk support so we might as well serve our users. Till that goes through we are stuck with the review sadly.
update progress can be followed here: https://bugzilla.redhat.com/show_bug.cgi?id=505751
With a locally updated gtk-sharp2 I noticed that uiaatkbridge.spec has a dependence simply on 2.24 which seems to be a leftover from a clean up. Please remove or the package is non-installable.
uiautomationwinforms has a dependency on glib-sharp2 which isn't in Fedora as a separate package, however it is in gtk-sharp2. With that fixed it fails to build here:
test -z "/usr/lib64/uiautomationwinforms" || /bin/mkdir -p "/home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/uiautomationwinforms" /usr/bin/install -c 'bin/Debug/UIAutomationWinforms.dll' '/home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/uiautomationwinforms/UIAutomationWinforms.dll' /usr/bin/gacutil /i bin/Debug/UIAutomationWinforms.dll /f /root /home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib || exit 1; Failure adding assembly bin/Debug/UIAutomationWinforms.dll to the cache: Strong name cannot be verified for delay-signed assembly make[2]: *** [gac-install] Error 1 make[2]: Leaving directory `/home/david/rpmbuild/BUILD/uiautomationwinforms-1.0/UIAutomationWinforms' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/david/rpmbuild/BUILD/uiautomationwinforms-1.0/UIAutomationWinforms' make: *** [install-recursive] Error 1 fejl: Fejl-afslutningsstatus fra /var/tmp/rpm-tmp.8py1wX (%install)
Which looks like I missed a hardcoded reference to prefix/lib somewhere.
Nope good old failure with parallel make.
now we get:
PM opbygningsfejl: Fil ikke fundet: /home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/mono/gac/UIAutomationWinforms
file not found. Please address.
And when those two are addressed, I think every spec file you submitted will work. I worked hard so now I will reward myself with diet coke and a book.
- David
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 Stephen Shaw sshaw@decriptor.com
On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
Awesome is my middle name.. or is it Modest I forget. Okay if there is a hard requirement on 2.12.8 for a11y reasons then I will file a bug with gtk-sharp2 and ask for an update. I believe it will be required for Banshee 1.5.1 or above as well for atk support so we might as well serve our users. Till that goes through we are stuck with the review sadly.
update progress can be followed here: https://bugzilla.redhat.com/show_bug.cgi?id=505751
With a locally updated gtk-sharp2 I noticed that uiaatkbridge.spec has a dependence simply on 2.24 which seems to be a leftover from a clean up. Please remove or the package is non-installable.
uiautomationwinforms has a dependency on glib-sharp2 which isn't in Fedora as a separate package, however it is in gtk-sharp2. With that fixed it fails to build here:
test -z "/usr/lib64/uiautomationwinforms" || /bin/mkdir -p "/home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/uiautomationwinforms" /usr/bin/install -c 'bin/Debug/UIAutomationWinforms.dll' '/home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/uiautomationwinforms/UIAutomationWinforms.dll' /usr/bin/gacutil /i bin/Debug/UIAutomationWinforms.dll /f /root /home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib || exit 1; Failure adding assembly bin/Debug/UIAutomationWinforms.dll to the cache: Strong name cannot be verified for delay-signed assembly make[2]: *** [gac-install] Error 1 make[2]: Leaving directory `/home/david/rpmbuild/BUILD/uiautomationwinforms-1.0/UIAutomationWinforms' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/david/rpmbuild/BUILD/uiautomationwinforms-1.0/UIAutomationWinforms' make: *** [install-recursive] Error 1 fejl: Fejl-afslutningsstatus fra /var/tmp/rpm-tmp.8py1wX (%install)
Which looks like I missed a hardcoded reference to prefix/lib somewhere.
Nope good old failure with parallel make.
now we get:
PM opbygningsfejl: Fil ikke fundet: /home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/mono/gac/UIAutomationWinforms
file not found. Please address.
Okay that one was just me accidently commenting out the patch.. surprisingly stupid of me.
And when those two are addressed, I think every spec file you submitted will work. I worked hard so now I will reward myself with diet coke and a book.
and now I deserve goodies.
LOL
On Jun 13, 2009, at 11:29 AM, David Nielsen gnomeuser@gmail.com wrote:
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 Stephen Shaw sshaw@decriptor.com On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
Awesome is my middle name.. or is it Modest I forget. Okay if there is a hard requirement on 2.12.8 for a11y reasons then I will file a bug with gtk-sharp2 and ask for an update. I believe it will be required for Banshee 1.5.1 or above as well for atk support so we might as well serve our users. Till that goes through we are stuck with the review sadly.
update progress can be followed here: https://bugzilla.redhat.com/show_bug.cgi?id=505751
With a locally updated gtk-sharp2 I noticed that uiaatkbridge.spec has a dependence simply on 2.24 which seems to be a leftover from a clean up. Please remove or the package is non-installable.
uiautomationwinforms has a dependency on glib-sharp2 which isn't in Fedora as a separate package, however it is in gtk-sharp2. With that fixed it fails to build here:
test -z "/usr/lib64/uiautomationwinforms" || /bin/mkdir -p "/home/ david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/ uiautomationwinforms" /usr/bin/install -c 'bin/Debug/UIAutomationWinforms.dll' '/home/ david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/ uiautomationwinforms/UIAutomationWinforms.dll' /usr/bin/gacutil /i bin/Debug/UIAutomationWinforms.dll /f /root / home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/ lib || exit 1; Failure adding assembly bin/Debug/UIAutomationWinforms.dll to the cache: Strong name cannot be verified for delay-signed assembly make[2]: *** [gac-install] Error 1 make[2]: Leaving directory `/home/david/rpmbuild/BUILD/ uiautomationwinforms-1.0/UIAutomationWinforms' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/david/rpmbuild/BUILD/ uiautomationwinforms-1.0/UIAutomationWinforms' make: *** [install-recursive] Error 1 fejl: Fejl-afslutningsstatus fra /var/tmp/rpm-tmp.8py1wX (%install)
Which looks like I missed a hardcoded reference to prefix/lib somewhere.
Nope good old failure with parallel make.
now we get:
PM opbygningsfejl: Fil ikke fundet: /home/david/rpmbuild/BUILDROOT/ uiautomationwinforms-1.0-1.x86_64/usr/lib64/mono/gac/ UIAutomationWinforms
file not found. Please address.
Okay that one was just me accidently commenting out the patch.. surprisingly stupid of me.
And when those two are addressed, I think every spec file you submitted will work. I worked hard so now I will reward myself with diet coke and a book.
and now I deserve goodies. _______________________________________________ fedora-mono mailing list fedora-mono@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mono
On Jun 13, 2009, at 10:00 AM, David Nielsen gnomeuser@gmail.com wrote:
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 David Nielsen gnomeuser@gmail.com
2009/6/13 Stephen Shaw sshaw@decriptor.com On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
Awesome is my middle name.. or is it Modest I forget. Okay if there is a hard requirement on 2.12.8 for a11y reasons then I will file a bug with gtk-sharp2 and ask for an update. I believe it will be required for Banshee 1.5.1 or above as well for atk support so we might as well serve our users. Till that goes through we are stuck with the review sadly.
update progress can be followed here: https://bugzilla.redhat.com/show_bug.cgi?id=505751
With a locally updated gtk-sharp2 I noticed that uiaatkbridge.spec has a dependence simply on 2.24 which seems to be a leftover from a clean up. Please remove or the package is non-installable.
uiautomationwinforms has a dependency on glib-sharp2 which isn't in Fedora as a separate package, however it is in gtk-sharp2. With that fixed it fails to build here:
test -z "/usr/lib64/uiautomationwinforms" || /bin/mkdir -p "/home/ david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/ uiautomationwinforms" /usr/bin/install -c 'bin/Debug/UIAutomationWinforms.dll' '/home/ david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/lib64/ uiautomationwinforms/UIAutomationWinforms.dll' /usr/bin/gacutil /i bin/Debug/UIAutomationWinforms.dll /f /root / home/david/rpmbuild/BUILDROOT/uiautomationwinforms-1.0-1.x86_64/usr/ lib || exit 1; Failure adding assembly bin/Debug/UIAutomationWinforms.dll to the cache: Strong name cannot be verified for delay-signed assembly make[2]: *** [gac-install] Error 1 make[2]: Leaving directory `/home/david/rpmbuild/BUILD/ uiautomationwinforms-1.0/UIAutomationWinforms' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/david/rpmbuild/BUILD/ uiautomationwinforms-1.0/UIAutomationWinforms' make: *** [install-recursive] Error 1 fejl: Fejl-afslutningsstatus fra /var/tmp/rpm-tmp.8py1wX (%install)
Which looks like I missed a hardcoded reference to prefix/lib somewhere.
Nope good old failure with parallel make.
now we get:
PM opbygningsfejl: Fil ikke fundet: /home/david/rpmbuild/BUILDROOT/ uiautomationwinforms-1.0-1.x86_64/usr/lib64/mono/gac/ UIAutomationWinforms
file not found. Please address.
And when those two are addressed, I think every spec file you submitted will work. I worked hard so now I will reward myself with diet coke and a book.
- David
Really sorry I forgot to mention that. Sadly I'm still stuck on my ipod touch. I'm getting better at emailing with it though :). I'll owe you big time for all the effort and work that you have put in.
Stephen
On Jun 13, 2009, at 8:39 AM, David Nielsen gnomeuser@gmail.com wrote:
2009/6/13 Stephen Shaw sshaw@decriptor.com On Jun 13, 2009, at 3:45 AM, David Nielsen gnomeuser@gmail.com wrote:
You are awesome! I believe that there is a hard req for 2.12.8. We have been putting work into that atk stuff.
Awesome is my middle name.. or is it Modest I forget. Okay if there is a hard requirement on 2.12.8 for a11y reasons then I will file a bug with gtk-sharp2 and ask for an update. I believe it will be required for Banshee 1.5.1 or above as well for atk support so we might as well serve our users. Till that goes through we are stuck with the review sadly.
As for the dbus package, please ignore it for now. I was purely interested in making sure that the spec file was ready.
okay I will finish that review once it is ready then.
As soon as I get to my computer I'll look at those patch and either apply them or put them I'm the fedora directory in svn. Since openSUSE is the primary target we have to play by the mono teams rules. Infortunately it's the odd one out. Maybe one day? I'm going to at least try to keep our spec files as closer as I can other then the arch issue.
I have been thinking, there is a concerning lack of uniformity, parhaps in your newfound capacity as an openSUSE deity I could ask you to help put some rock into this. I have been thinking it would be good to get pkg-mono debian, Fedora, openSUSE and upstream Mono to sit down and draft a set of guidelines for packaging to get some uniformity. While you upstream guys do great code it is definitely not as easy to package as it could be and having common upstream blessed guidelines would really easy both our jobs and I suspect general acceptance of Mono. Right now bad packaging makes things suck rather badly.
Once you are ready though I would suggest submitting these to Fedora as well as the OBS. It would be nice to have all of this a11y stuff available for our users and as upstream I am sure you will make the right decisions on how to work this out. Plus more users to expose your bugs can't hurt.. much.
- David
I'll respond more fully once I'm at a 'real' computer :). The intention has always been about getting this a11y stuff out to all the distros. We have been working on several projects such as acceeciser, converting at-spi over to dbus, firefox, openoffice, and orca. The only reason for putting it into OBS is so that it works with our test automation. We are planning on testing this stuff on both 32 and 64 for openSUSE, SLE, fedora, and ubuntu.
Sadly, I'm also concidered downstream when it comes to mono. But I'll more respond to that later.
Thanks, Stephen
On 05/20/2009 04:02 PM, David Nielsen wrote:
2009/5/20 Stephen Shaw <sshaw@decriptor.com mailto:sshaw@decriptor.com>
> Using the uiautomation.spec as the example since that had the newest change > time according to svn. > > For purely managed code currently, due entirely to stupidity on the part of > the Mono packaging guidelines, currently you need to add: > > %define debug_package %{nil} > > Or you will end up with an empty debug package, It is prefered to be at the > very first line of the spec file. ok, I added this to all of them except uiaatkbridge because it does have a c library in itPerfect
Source: needs to be a full valid URL (for something like codeplex where direct downloading isn't possible because of clickthrough licenses add a comment). E.g.
Source0: http://banshee-project.org/files/banshee/banshee-1-%%7Bversion%7D.tar.bz2
http://banshee-project.org/files/banshee/banshee-1-%%7Bversion%7D.tar.bz2
I added this to all of them except uiadbuscorebridge since that hasn't officially been releasedThen we can't ship it, unless you do a svn shapshot (I will find you are reference for doing that when we get that far). The tarball has to be reproducable either as a vetted download or a SVN snapshot that can be repeated.
I updated this in all of them. With openSUSE they generate fresh jails on top of xen on the fly for everybuild so thi build root really doesn't matter. That is why they were really simple
Note that Fedora's buildsystem does this as well. The Fedora spec files have buildroot specified so that people rebuilding packages on their own machines for their own purposes are okay. (We don't have fresh xen instances for every build... but we do have fresh chroot jails).
It's one of those things that annoy me about rpm, why do I need to define this.. make the default sane and let me overwrite it if I have a good reason. I think Fedora does this mostly for belt and suspender reasons but really that is a question for the buildsystem guys. It never hurts to do it right though.
rpm in F10+ defines a buildroot now thanks to Panu and his team. I'll see about updating the guidelines and see if we can phase out the need for it over time. (Note that packagers who want a single spec file for Fedora and EPEL releases will still need it.)
-Toshio
mono@lists.stg.fedoraproject.org
-
David Nielsen -
Ismael Olea -
Stephen Shaw -
Toshio Kuratomi