April 2013 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] CrossToolchain question
by Matwey V. Kornilov 25 Oct '13

25 Oct '13

Hi, In CrossToolchain:avr, I see avr-gcc-* and cross-avr-gcc. What is the difference? What is correct naming? (I suppose the last one). What guidelines/rules should I follow to create CrossToolchain subproject for yet unsupported arch? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 22

[opensuse-packaging] Packaging Guideline enforcement
by Dominique Leuenberger a.k.a DimStar 10 Sep '13

10 Sep '13

Dear Factory contributors and packagers, As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be. Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches First, the .changes entry (rpm changelog) surves two purposes: - News for the user - History tracking of packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixeS). A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will. Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed) The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the Factory Review team: - The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that... And the Factory Review team also prefers to see complying submissions to having to reject SRs... reject is not fun for anybody! Looking forward to many more SRs to accept! Dominique / DimStar -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

29 105

[opensuse-packaging] Package looking for volunteers: CodeAnalyst
by Cristian Morales Vega 08 Aug '13

08 Aug '13

As per https://bugzilla.novell.com/show_bug.cgi?id=793541 it seems CodeAnalyst needs a new maintainer. Any volunteer? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 13

[opensuse-packaging] package looking for maintainer: the AT daemon
by Cristian Rodríguez 18 Jun '13

18 Jun '13

Hi: I will no longer maintain fix or otherwise care about the "at" daemon, starting now because I would rather devout my time testing and improving systemd.timer(5) So it is now up for grabs. that's all ;) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

19 47

[opensuse-packaging] Howto protect files from removing after uninstall of a rpm?
by Meike Stone 02 May '13

02 May '13

Hello, I try to build a RPM. All is working fine. But I need that after uninstall of the rpm two files always should be left on disk. If the package is updated, file should be replaced with the file from new rpm and replaced renamed as .rpmsave. Is there a way to do this in the spec file? Thanks Meike -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 11

[opensuse-packaging] glibmm and sigc static packages
by Sankar P 01 May '13

01 May '13

Hi, I am trying to build a static binary of https://github.com/i-rinat/fragview I patched the cmake file as: +SET (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static") to build a static binary. Now during the make phase, I get the following errors: /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lglibmm-2.4 /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lsigc-2.0 I got the above error for "-lm" too which went away after installing the libc-devel-static rpm. However I could not find either a glibmm-devel-static rpm or a sigc-devel-static rpm. Now what is the easiest way to get the static rpm of these packages so as to get the static binary generated ? Which buildservice packages should I fork and tweak ? I do not have much experience in building and so wanted to ask here before proceeding, to know if I am going in the right path. I need a static binary as I want to run this tool in some old SLE boxes where the latest GTK, glibmm packages are not available, and so I cannot compile the fragview tool from the source in those machines. On a side note, The earlier RPM search under software.opensuse.org/search will list the rpms (instead of the projects) and it was easier to find if there were any rpms in home projects etc. in just one page. Now, the search interface is kind of complex, and makes us click a lot more. Does anyone else apart from me, feel that this can be reported as an usability issue ? Thanks. Sankar -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 3

[opensuse-packaging] Failed to lookup host/port: "127.0.0.1:0": Name or service not known
by Martin Vidner 30 Apr '13

30 Apr '13

Hi, I am getting a build failure for rubygem-ruby-dbus.rpm(1). The package contains a test suite where a new dbus-daemon is started listening on localhost. This fails with Failed to lookup host/port: "127.0.0.1:0": Name or service not known It runs fine in local builds and in Travis(2). 1) https://build.opensuse.org/package/show?package=rubygem-ruby-dbus&project=d… 2) https://travis-ci.org/mvidner/ruby-dbus Does anyone have an idea what the problem is? -- Martin Vidner, Cloud & Systems Management Team http://en.opensuse.org/User:Mvidner Kuracke oddeleni v restauraci je jako fekalni oddeleni v bazenu

2 2

[opensuse-packaging] devel:lanugages:erlang proposal
by Matwey V. Kornilov 29 Apr '13

29 Apr '13

We are getting a lots of packages inside the devel:languages:erlang. We should think to change project structure to avoid massive rebuild of packages at erlang updates. My suggestion is to follow devel:langages:python approach: maintaince project for erlang is devel:languages:erlang:Factory, and packages inside devel:languages:erlang are built against erlang from the *distribution* repository (or from openSUSE:Factory for factory). Since we can not just broke the things, the following roadmap is proposed: 1) move devel:languages:erlang/erlang to devel:languages:erlang:Factory/erlang and make a link from devel:languages:erlang:Factory/erlang to devel:languages:erlang/erlang. Change devel project for openSUSE:Factory/erlang to devel:languages:erlang:Factory. 2) disable devel:languages:erlang/erlang for Factory and upcoming openSUSE 13.1 in order to make erlang packages use erlang from the distribution. then disable for 13.2, 13.3, etc. At this step for openSUSE >= 13.1 packages from the project will use erlang from distribution, and the packages for openSUSE < 13.1 will use erlang from devel:languages:erlang, as they do now. 3) when all versions up to 12.3 will be discontinued, drop disabled devel:languages:erlang/erlang finally. -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 3

[opensuse-packaging] Correctly splitting xinetd configuration file that has %config(noreplace).
by Michal Srb 26 Apr '13

26 Apr '13

Hi, There are two VNC related packages: * xorg-x11-Xvnc, contains: - Xvnc binary (Xserver working as VNC server), since 12.3 based on tigervnc * tightvnc, contains: - VNC client (tightvnc) - bunch of scripts to configure and start Xvnc comfortably - vnc_inetd_httpd (http server to deliver Java based VNC client) - /etc/xinetd.d/vnc file containing vnc and vnchttp services tightvnc depends on xorg-x11-Xvnc and usually they are installed together. The /etc/xinetd.d/vnc contains definition of vnc{1,2,3} services that start Xvnc from xorg-x11-Xvnc package and vnchttpd{1,2,3} services that start vnc_inetd_httpd from tightvnc package. Now, to fix a bug that prevents Xvnc from working correctly in 12.3, we need to add additional option (-SecurityTypes None) to the xinetd configuration file. But it doesn't feel correct to add tigervnc specific option to file in tightvnc package. The best solution would be to split the xinetd configuration file into two and put each to appropriate package. I have that prepared and I verified that YaST is still able to switch both vnc and vnchttp services on and off correctly. Problem is that the /etc/xinetd.d/vnc is %config(noreplace) and if someone modified it, he will end up with two files - the original with all services and the new one with half of them. Xinetd refuses to start when it finds duplicate services. Could you suggest some safe way to split the configuration file? Or is it better to keep it in one package? Michal -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Creating of systemd service files instead of init scripts for new packages
by Andreas Jaeger 25 Apr '13

25 Apr '13

Since we moved to systemd completely, I suggest that newly added files will contain service files - and not init scripts anymore. So, please only add service files to new packages and if you change your init file, consider using a service file and dropping the init file, Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

29 140

[opensuse-packaging] erlang packaging II
by Matwey V. Kornilov 23 Apr '13

23 Apr '13

Hi All, I've just accepted one request and declined the other. And I would like to discuss following thing: why do you name -src packages as -devel? Is there strong underlying reason to do that? I am not insist on -src at all, but It may lead to misconception, because you do not need src/*.erl files to develop application that uses function from this module. Also, maybe there you will find answers to some questions and further links: https://en.opensuse.org/User:Matwey/Erlang_guidelines_draft#Further_informa… -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 6

[opensuse-packaging] erlang autoreqprovs
by Matwey V. Kornilov 22 Apr '13

22 Apr '13

Hi, This mail is to highlight current status of my find-requires-provides-for-erlang story. I've experimented at home:matwey:erlang and I've used new rpm fileattrs interface to run modified Lemekov's scripts. The first issue is that I had to broke erlang-wx (see http://lists.opensuse.org/opensuse-packaging/2013-03/msg00079.html ) The second is more sophisticated. As you know, you can compile in a link to any module and any function (ever not existing at all). Until the code want to call this function, you never know that. This opportunity is used quite often. Let us take a look at erlang-rfc4672. It has interfaces to different http servers: cowboy, mochiweb, inets. The scripts are able to extract all symbols after package built, but... We don't have at all packages for cowboy and mochi, no package provides the modules required by erlang-rfc4672. So, some packages built with auto-requires are not installable. (and formally they are inconsistent, they may potentially have bugs) And I don't know how to gracefully track this. In C, you need library to be installed at compile-time in order to link your exe with it. In Erlang, you do not. Maybe we need some lint-checker to reject package if we found that it requires module not installed at our build-host. More interesting that even from this code: Mod = list_to_atom("demo"), %% Fool xref tests case file:set_cwd(Demo) of ok -> apply(Mod, start, []), I was able to extract erlang:mod(demo) with R15/16. :) -- With best regards, Matwey V. Kornilov http://0x2207.blogspot.com xmpp:0x2207@jabber.ru -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] Multiple spec files checked now
by Stephan Kulow 21 Apr '13

21 Apr '13

Hi, I added one more check to the automatic tests: If a package has multiple spec files, it's actually not one package submitted but two or more. But so far I only checked the package the submission came from. I changed this now and this has 2 consequences: if you have a python-foo/python-foo.spec and a python-foo/python3-foo.spec you now also need a python3-foo package in your project linking to the python-foo package *and* both packages have to be succeeded. This also means that both packages are checked for file conflicts and broken dependencies. I did a rather large rewrite of the way the checking works due to support of group requests that I wrote last week (and I will announce in more detail once I have some user interface for it, for now let me refer to my hackweek page[¹] :) Greetings, Stephan [1] https://github.com/SUSE/hackweek/wiki/Improved-Factory-devel-project-submis… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 3

[opensuse-packaging] find-lang.sh fails for paths containing colons
by Andrey Borzenkov 19 Apr '13

19 Apr '13

I tried to quickly build package locally and got bor@opensuse:~/obs/home:arvidjaar:grub2-next/grub2/foo/BUILD/grub-2.00> LC_ALL=C /usr/lib/rpm/find-lang.sh /home/bor/obs/home:arvidjaar:grub2-next/grub2/foo/BUILDROOT/grub2-2.00-0.x86_64 grub2 sed: -e expression #1, char 33: unknown option to `s' sed: -e expression #1, char 33: unknown option to `s' Well, find-lang.sh is using s:$PATH:: and that of course breaks if path itself contains ':'. Not sure how common it is, nor how to make it more robust. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] Turn off auto-requires on perl/python/ruby
by Michal Vyskocil 16 Apr '13

16 Apr '13

Hi, I was surprised when I've cheched the taskwarior's dependencies and found /usr/bin/{perl,python.ruby}. It seems it's autogenerated because some addon scripts are installed with a package. However I am not sure which of our magic scripts makes it. The /usr/lib/rpm/find-requires seems to add perl when it find a shebang and python in a case something in /usr/libxy/python is installed. There are already fileattrs with perl.attr and python.atts, but I did no found anything for ruby. Has anyone an idea how to suppress the automatic adding of a dependency to interpreters by default? package https://build.opensuse.org/package/show?package=taskwarrior&project=utiliti… build log https://build.opensuse.org/package/rawlog?arch=x86_64&package=taskwarrior&p… Regards Michal Vyskocil

2 2

[opensuse-packaging] Re: [obs submit-request 164046] devel:libraries:c_c++/ppl: accepted by namtrac
by Richard Biener 15 Apr '13

15 Apr '13

On Mon, 15 Apr 2013, Ismail Doenmez wrote: > > State of submit-request #164046 was changed by namtrac: > > new -> accepted This should have been declined. It increases the size of the bootstrap cycle and it's dependencies. GCC depends on ppl. Thus it will break Base:build even more. > Comment: > > > https://build.opensuse.org/request/diff/164046 > > Source > project: home:namtrac:bugfix > package: ppl > revision: 2 > > Target: > project: devel:libraries:c_c++ > package: ppl > > > -- Richard Biener <rguenther(a)suse.de> SUSE / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 GF: Jeff Hawn, Jennifer Guild, Felix Imend -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 7

[opensuse-packaging] Should kdebase4-workspace-plasma-calendar be merged into kdebase4-workspace
by Joseph Mulloy 15 Apr '13

15 Apr '13

After upgrading from 12.2 to 12.3 I started to get a dialog after logging into KDE asking me to install a "calendar data engine". Unfortunately the wizard can't actually find the package which turns out to be kdebase4-workspace-plasma-calendar. Since this package is required by the plasma clock widget for full operation it should either be required by kdebase4-workspace or merged into kdebase4-workspace. Based on the changelog from when the package was originally split off it's supposed to be recommended by kdebase4-workspace, but when I check it in 12.3 it's not. Is there any good reason for this package to be split? Is merging a split package into the main package on a released version of openSUSE allowed? https://bugzilla.novell.com/show_bug.cgi?id=803538 # kdebase4-workspace.changes ------------------------------------------------------------------- Wed Dec 7 14:18:37 UTC 2011 - saschpe(a)suse.de - New subpackages plasma-engine-akonadi and plasma-calendar: * Removed %kde4_akonadi_requires from base package, otherwise half of KDE depends on akonadi-runtime. * Both are recommended by base package Joseph Mulloy jdmulloy(a)gmail.com -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] "Upstream First" policy proposal
by Jan Engelhardt 12 Apr '13

12 Apr '13

Hi, I am hereby announcing that I added a new section regarding "Upstream First" policy to https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Package maintainers who are upstream at the same time may declare UF if they think it helps their workflow, and the wiki entry just formally writes down the practice formally that had already been in place with some packages. (In that regard, it is not really a proposal.) On 04/11/2013 07:22 PM, MediaWiki Mail wrote: > >The openSUSE page openSUSE:Packaging Patches guidelines has been >changed on 11 April 2013 by Jengelh, see >https://en.opensuse.org/openSUSE:Packaging_Patches_guidelines for the >current version. > >Editor's summary: Declare "Upstream First" > > Your friendly openSUSE notification system -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] When to use recommends?
by Greg Freemyer 11 Apr '13

11 Apr '13

All, How is the decision made to have a recommends statement made? == my situation I packaged fio for 12.3. Fio is a performance testing tool for disk subsystems. One of its features is it can produce plots viewable via gnuplot so there is a recommends gnuplot in the specfile. I've just had a user raise the concern that on a server gnuplot brings in a ton of desktop related packages. Further he argues he would run fio on the server, but gnuplot on his desktop. I can see both sides of this, but I am inclined to remove the recommends statement. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

10 14

[opensuse-packaging] tftp
by Stephan Kulow 10 Apr '13

10 Apr '13

Hi, There seem to be different concepts what permissions and owner /srv/tftpboot should have. Can we agree on something? :) found conflict of atftp-0.7.0-156.1.x86_64 with kiwi-pxeboot-5.05.7-582.1.noarch: - /srv/tftpboot [mode mismatch: d750 tftp:tftp, d755 root:root] found conflict of dnsmasq-2.65-5.1.x86_64 with kiwi-pxeboot-5.05.7-582.1.noarch: - /srv/tftpboot [mode mismatch: d750 root:tftp, d755 root:root] found conflict of kiwi-pxeboot-5.05.7-582.1.noarch with tftp-5.2-5.1.x86_64: - /srv/tftpboot [mode mismatch: d755 root:root, d750 root:tftp] Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 4

[opensuse-packaging] openSUSE:Factory:Staging:boost
by Stephan Kulow 10 Apr '13

10 Apr '13

Hi, The latest boost update (1.53) is breaking at least libzypp and libyui. If someone could have a look and fix those cases, we can have a new boost in factory again, so far it is kept in quarantine. Greetings, Stephan -- Work consists of whatever a body is obliged to do. Play consists of whatever a body is not obliged to do. -- Mark Twain -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging]
by Igor Zinovik 09 Apr '13

09 Apr '13

unsubscribe -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] Bash completion scripts without .sh suffix
by Andrey Borzenkov 09 Apr '13

09 Apr '13

Apparently on openSUSE /etc/bash.bashrc sources only completion scripts with .sh suffix. It is fine but some packages install them without suffix (I wondered why completions were missing). Does it warrant rpmlint check? On a related note, some completions use "have" function to check for command existence. Seems it was introduced in Debian. Would it make sense to add this to /etc/bash.bashrc to avoid need to patch every program? This comes unnoticed currently because two completions on my system that use "have" also do not have .sh suffix :) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

7 7

[opensuse-packaging] Packaging process issue: Package is out, broken
by Rajko 07 Apr '13

07 Apr '13

Lars Vogdt mentioned some of his review criteria in a: http://lists.opensuse.org/opensuse-packaging/2013-04/msg00091.html This reminded me that review process has too weak, or even missing, actual feedback from users of packaged software. The reason to think like that are titles that came out without being able to perform basic task they are designed for [1]. In effect we can't prevent situation where package that works for distros with different library version, but not with openSUSE, is shipped as part of the release. One can argue that such things happen and blame lack of testing, but it is actually only lack of in-house testing, as in example [1] it was easy to find problem reports and fixes on the web, but I doubt that many of our packagers will have time to look for them. Solution would be to add component to review process that will collect external feedback and make it available to reviewers and packagers. Collecting feedback does not require as much sophistication as packaging, so it will be accessible to many more people willing to contribute. Once when online instructions are created it is possible to list it on the wiki under "How to contribute", and point interested people to that. [1] Example that I have in mind was video editing software kdenlive few releases ago, which was the only one that will not crash right on the start, or in the middle of the work. I gave up on attempts to use it, so I don't know current status, nor I remember details. The issue was that at the time it had a bug that was valid only for specific library version that was included in openSUSE. It will pass compilation and packaging, and it will actually ran, but one could not render final video after editing. Newer library was fixed and kdenlive worked fine. -- Regards, Rajko. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

1 0

[opensuse-packaging] clisp package missing on 12.3 ppc
by Ruediger Meier 04 Apr '13

04 Apr '13

Hi, the clisp package is not built for 12.3 on ppc arch. Does anybody know why it's missing? It exists for 12.2 and Factory ppc. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 9

[opensuse-packaging] Issues trying to create a -doc sub-package
by Greg Freemyer 03 Apr '13

03 Apr '13

All, I don't know why, but I've struggled getting a doc file created that actually contains the files in it I have listed. My project is home:gregfreemyer:Tools-for-forensic-boot-cd > libpff Right now my specfile is dieing when I'm just trying to copy the doc files to the %_docdir folder tree. Here's my snippet: install -d -m 644 "%{buildroot}%{_docdir}/%{name}-doc" install -m 644 -t "%{buildroot}%{_docdir}/%{name}-doc" %{SOURCE1} %{SOURCE2} %{SOURCE3} %{SOURCE4} I've tried multiple variations of the above with no luck. (see below error). I've added ls calls to verify everything looks good and I don't see what the issue is: ls -l %{SOURCE1} %{SOURCE2} %{SOURCE3} %{SOURCE4} install -d -m 644 "%{buildroot}%{_docdir}/%{name}-doc" ls -ld "%{buildroot}%{_docdir}/%{name}-doc" install -m 644 -t "%{buildroot}%{_docdir}/%{name}-doc" %{SOURCE1} %{SOURCE2} %{SOURCE3} %{SOURCE4} The output from the above is: =============== [ 274s] + ls -l /home/abuild/rpmbuild/SOURCES/MAPI_definitions.pdf /home/abuild/rpmbuild/SOURCES/PFF_Forensics_-_analyzing_the_horrible_reference_file_format.pdf /home/abuild/rpmbuild/SOURCES/PFF_forensics_-_e-mail_and_appoinment_falsification_analysis.pdf '/home/abuild/rpmbuild/SOURCES/Personal_Folder_File_(PFF)_format.pdf' [ 274s] -rw-r--r-- 1 abuild abuild 862433 Apr 1 17:03 /home/abuild/rpmbuild/SOURCES/MAPI_definitions.pdf [ 274s] -rw-r--r-- 1 abuild abuild 220508 Apr 1 17:03 /home/abuild/rpmbuild/SOURCES/PFF_Forensics_-_analyzing_the_horrible_reference_file_format.pdf [ 274s] -rw-r--r-- 1 abuild abuild 159667 Apr 1 17:03 /home/abuild/rpmbuild/SOURCES/PFF_forensics_-_e-mail_and_appoinment_falsification_analysis.pdf [ 274s] -rw-r--r-- 1 abuild abuild 386190 Apr 1 17:03 /home/abuild/rpmbuild/SOURCES/Personal_Folder_File_(PFF)_format.pdf [ 274s] + install -d -m 644 /home/abuild/rpmbuild/BUILDROOT/libpff-0.0.0~20120802-9.1.x86_64/usr/share/doc/packages/libpff-doc [ 274s] + ls -ld /home/abuild/rpmbuild/BUILDROOT/libpff-0.0.0~20120802-9.1.x86_64/usr/share/doc/packages/libpff-doc [ 274s] drw-r--r-- 2 abuild abuild 4096 Apr 1 19:12 /home/abuild/rpmbuild/BUILDROOT/libpff-0.0.0~20120802-9.1.x86_64/usr/share/doc/packages/libpff-doc [ 274s] + install -m 644 -t /home/abuild/rpmbuild/BUILDROOT/libpff-0.0.0~20120802-9.1.x86_64/usr/share/doc/packages/libpff-doc /home/abuild/rpmbuild/SOURCES/MAPI_definitions.pdf /home/abuild/rpmbuild/SOURCES/PFF_Forensics_-_analyzing_the_horrible_reference_file_format.pdf /home/abuild/rpmbuild/SOURCES/PFF_forensics_-_e-mail_and_appoinment_falsification_analysis.pdf '/home/abuild/rpmbuild/SOURCES/Personal_Folder_File_(PFF)_format.pdf' [ 274s] install: cannot stat '/home/abuild/rpmbuild/BUILDROOT/libpff-0.0.0~20120802-9.1.x86_64/usr/share/doc/packages/libpff-doc/MAPI_definitions.pdf': Permission denied [ 274s] install: cannot stat '/home/abuild/rpmbuild/BUILDROOT/libpff-0.0.0~20120802-9.1.x86_64/usr/share/doc/packages/libpff-doc/PFF_Forensics_-_analyzing_the_horrible_reference_file_format.pdf': Permission denied [ 274s] install: cannot stat '/home/abuild/rpmbuild/BUILDROOT/libpff-0.0.0~20120802-9.1.x86_64/usr/share/doc/packages/libpff-doc/PFF_forensics_-_e-mail_and_appoinment_falsification_analysis.pdf': Permission denied [ 274s] install: cannot stat '/home/abuild/rpmbuild/BUILDROOT/libpff-0.0.0~20120802-9.1.x86_64/usr/share/doc/packages/libpff-doc/Personal_Folder_File_(PFF)_format.pdf': Permission denied [ 274s] error: Bad exit status from /var/tmp/rpm-tmp.sYmziu (%install) [ 274s] ================= Greg Freemyer Chief Technology Officer Intelligent Avatar Corporation (678) 653-4860 Greg.Freemyer(a)gmail.com http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retrie… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

4 7

[opensuse-packaging] Proper dev project for a small collection of C utility libs with python bindings
by Greg Freemyer 03 Apr '13

03 Apr '13

All, I'm about to submit 6 new small packages: libevt, libevtx, libregf, libmsiecf, liblnk, libvshadow. My basic question is what devel project I should send these to and if I should leave them as 6 discrete projects, or maybe try to combine them somehow. I've thought about just pushing all 6 to devel:libraries If that is a good choice let me know. == details All of them are from the same upstream author and have the same structure, all hosted at the same place etc. The specfiles are all very similar. For each one there is a c library created, a python bindings sub-package and a end-user tools sub-package (eg. evttools, etc.) with a couple simple tools each. My use case is a security tool that uses the python bindings of all 6, so in theory I could put them there, but it seems like the wrong place to me, but the "tools" sub-projects would all actually qualify as security tools for a forensic examiner. (I already have 15 or 20 forensic tools in the security project, so maybe it is time for me to create a security:dfir sub-project and just put everything in there?) Thanks Greg -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] Drop crosscrash package
by Petr Tesarik 03 Apr '13

03 Apr '13

Hi all, let me request dropping the crosscrash package. This package was originally written by Bernhard Walle, most likely as a SLES project. Bernhard was later laid off during the "big SUSE layoff", and I took over the maintainership of the whole kernel dump infrastructure. However, the crosscrash package has never reached maturity (the original goal was only partly met), it wasn't even publicly announced in the crash development list, let alone building its own community. Unsurprisingly, the code has been bitrotting over years, so it can't even open dumps of recent kernels. Since this package has no upstream, and I can't continue working on the project, I suggest the package be dropped. As a replacement, I might package a 32-bit version of crash on 64-bit platforms. FYI this was the only combination that ever worked with crosscrash (64-bit dump on 32-bit host never worked, and neither did different endianity between the dump and host). Comments? Petr Tesarik -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1

[opensuse-packaging] texlive packaging
by Joseph Comfort 02 Apr '13

02 Apr '13

I sent this message to the opensuse list, but the packaging list may be better. I am updating (fresh install) to v12.3. It looks very good so far. However, I am very unhappy with the new texlive packaging. Several reasons. * Very complex and confusing. It is very, very difficult to find out what collections/schemes are needed to get a particular latex package. * Each package has a rpm overhead; it must be downloaded separately; it must be installed separately (whether in a collection or not). Most inefficient and takes far too much time. * The previous packaging provided what I needed out of the box. Now, none of the collections do -- even the collection claimed to be closest to the original one. I have to go find and install some individual ones separately (elsarticle, revtex4; lineno is picked up if I include the 'latexextra' collection). * It is a very long process to remove texlive entirely. I tried with YaST2. Removing collections is not difficult, but there are many font and bin rpms left over with no supervising parent that I can see. Each one requires 2 clicks to delete, with long waits between items. I keep an ascii list of rpms. With about 4000 entries, nearly half are texlive stuff, and it could be worse. There may be some good reasons to try the packaging change. Currently, however, it is not implemented well at all. I hope the next release either restores the previous packaging, or makes huge improvements. Thank you, Joe Comfort -- Joseph Comfort Phone: (480)-965-6377 Physics Department Dept.: (480)-965-3561 Arizona State University Fax: (480)-965-7954 Tempe, AZ 85287-1504 Email: Joseph.Comfort(a)asu.edu -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

5 5

[opensuse-packaging] aclocal
by doiggl＠velocitynet.com.au 01 Apr '13

01 Apr '13

Hello, How is this error fixed[1] spec file[2] Thanks Glenn [1] [ 49s] + cd /home/abuild/rpmbuild/BUILD [ 49s] + /usr/bin/rm -rf /home/abuild/rpmbuild/BUILDROOT/reiser4progs-1.0.7-3.1.x86_64 [ 49s] ++ dirname /home/abuild/rpmbuild/BUILDROOT/reiser4progs-1.0.7-3.1.x86_64 [ 49s] + /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT [ 49s] + /usr/bin/mkdir /home/abuild/rpmbuild/BUILDROOT/reiser4progs-1.0.7-3.1.x86_64 [ 49s] + cd reiser4progs-1.0.7 [ 49s] + aclocal --force [ 49s] /var/tmp/rpm-tmp.DZct0Z: line 31: aclocal: command not found [ 49s] error: Bad exit status from /var/tmp/rpm-tmp.DZct0Z (%build) [2] https://build.opensuse.org/package/view_file?expand=1&file=reiser4progs.spe… -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 1