Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage
Hello, Am Mon, 28 Dec 2009 01:25:17 +0100 schrieb Iustin Pop : > Sorry to hear about your bad experience. I use the same workflow, > git-buildpackage + 3.0 (quilt) and I have no problems so far. Before I have made official Debian packages I have collected many experience with format 1.0 and I find it easy. Since some weeks I make some official Debian packages and since my beginning of maintaining I use the new format 3.0 (quilt). I still use CDBS and I use "simple-patches" - but now without CDBS support. My minor change is the file "patches/series" which let dpkg-buildpackages know that there are patches. This seems very simple, too. To get the old manner, I must only delete the series file and add the CDBS line into debian/rules. But remaining in format 3.0. > > $ quilt pop -a > > ... blabla cannot find bla bla... > > $ git status > > ...still a pain Because I never used quilt, the syntax for quilt is a little bit stupid for me. So also with the new format I don't use quilt. The only missing item for me is: there are no simple command to unapply the patches with dpkg-buildpackages (or debuild). For example: debuild unapply > My .quiltrc includes this: > > QUILT_PATCHES=debian/patches > > So it uses the right directory. I have found this info at the beginning inside the first dpkg package with format 3.0 support. Final: I can work with the new format - but not with quilt! Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage
Joey Hess wrote: > Joachim Wiedorn wrote: > > I still use CDBS and I use "simple-patches" - but now without CDBS > > support. My minor change is the file "patches/series" which let > > dpkg-buildpackages know that there are patches. This seems very simple, > > too. To get the old manner, I must only delete the series file and add > > the CDBS line into debian/rules. But remaining in format 3.0. > > > Because I never used quilt, the syntax for quilt is a little bit stupid > > for me. So also with the new format I don't use quilt. > > If I understand correctly what you're doing, you have a 3.0 (quilt) > package with no quilt managed patches, and using a debian/rules based No, I don't use an debian/rules based patch system. The patches will be used by dpkg-buildpackage because I have created the patches/series file. So inside dpkg the quilt-management of the patches will be used. But I don't use quilt outside the dpkg system. > source package can be unpacked and the pre-patched source accessed > without needing to manually follow a README.source file. I also don't need any manually patching system. It is done by dpkg-buildpackage. Please try my package "xfe" for example and check whether it is the "perversion of the 3.0 format". Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage
Hello, Joachim Wiedorn wrote: > The only missing item for me is: there are no simple command to unapply > the patches with dpkg-buildpackages (or debuild). For example: > >debuild unapply Even though there are some newer Mails this question seems to not be solved. Is it true, that I need an installed quilt to unapply the patches? Or can I do it with dpkg-buildpackage or dpkg-source? Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Conditions to existing packages for transition into squeeze/stable
Hello, there are some packages with old Standards-Version, old debhelper version and so on. Who know the conditions to existing packages in lenny for the transition into squeeze when it goes to stable? Or does all existing packages be accepted for the new stable if it is already in testing (which is the usual case)? Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Bug#565544: ITP: duply -- easy to use frontend to duplicity
Package: wnpp Severity: wishlist Owner: Joachim Wiedorn * Package name: duply Version : 1.5.1.4 Upstream Author : Edgar Soldin * URL : http://sourceforge.net/projects/ftplicity/ * License : GPL-2 Programming Lang: Bash Description : easy to use frontend to duplicity Duply is a shell front end to duplicity that simplifies the usage by managing settings for each backup job in profiles. It supports executing multiple commands in a batch mode to enable single line cron entries and allows the user to use pre/post backup scripts. All duplicity backends are supported. The previous name fo duply was ftplicity. Fondest regards, Joachim Wiedorn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565544: ITP: duply -- easy to use frontend to duplicity
I found it is a nice package for better using of duplicity. It have the stability for getting a Debian package. I have tested the package and already created a new Debian package of duply. If nobody have the same intention I would upload the package onto mentors.debian.net. Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: quilt 3.0 source format and dpkg-source/dpkg-buildpackage
Hello, Raphael Hertzog wrote: > On Fri, 22 Jan 2010, tangke wrote: > > why not apply the patches when build automatically, > > This is the case when you build the source package (i.e. dpkg-source does > it if it was not yet done). > > > and make clean to unapply the patches? > > The clean process is controlled by the maintainer. You could in theory > unapply the patch there. Now I must use quilt for apply and unapply the patches. I think this way is transparent. But there is one problem: If I had unapplied all patches of debian/patches and later I start with debuild, then dpkg-source works with the unpatched sources - it doesn't apply the patches as in format 1.0. Is there a chance that dpkg-source see the patches and can recognize that they must be applied before run further? Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: Misc developer news (#21)
Hello, Raphael Hertzog wrote: > As of the time of writing, DEHS is only 45 watch files away from the > 1 milestone!. Out of them, only 7480 packages are up to date with > regard to upstream. What is with deactivated watch files, because upsteam is dead? For a short time I had this case with the package d4x: upstream homepage is deleted, there is no more upstream development. My wish: A string like "upstream dead" in debian/watch can say DEHS, the watch file is o.k. while there is no link. Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: About new source formats for packages without patches
Raphael Hertzog wrote: > There might be not short term benefit for the current maintainer, but > it's a benefit for our derivatives distributions to be able to simply add > patches in a consistent manner. It will also be a benefit for Debian if in > 2 years some newbie packager doesn't have to learn about the limitations > of the source format 1.0 when they try to add an icon to a source package > or when they package a new upstream version that is now bzip2 compressed. I see some different points: * more supported package compressions * only one patching system * alle patches in debian/patches are applied * one extra file for 3.0 And each point have people who support this change and other people who don't want it. I think this is human. And this is a competition. I find it would be the best way, at this time, to let all DD and DM make their own experiences with the new format and wait some time who they are decide in a longer distance ... > In the general case, switching is a small effort for sure, but in the case > pointed out by Neil (he won't convert packages with no patches because he > doesn't see the benefit) the effort is almost null, just create the file > debian/source/format with "3.0 (quilt)" and you're done. At the beginning I haven't seen any advantage of the new format for me. But I switched and had some problems with the new format, i.e. I found it not very useful that all patches are applied. But this is one point. All other points are advancements. So let us discuss factually about single points, but without generally speak evil of the new format 3.0. Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Popcon disabled?
Hello, since some days I noticed that the 'Popularity contest statistics' of packages are not updated. For example for the package "xfe" the last value of 'popcon' comes from 2010-04-01. Does anyone know why? Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: document meaning of transition?
Thomas Koch wrote: > I'm reading debian-devel to get to know all that's needed to become a Debian > Developer. I noticed, that I did not find any documentation about transitions > or their workflow and that I can only guess, what this thread is about. > Maybe this is something that would be worth to be written down? You need the New-Maintainer (NM) process to become DD. Details can be found here: http://www.debian.org/devel/join/newmaint Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: lilo removal in squeeze (or, "please test grub2")
Harald Braumann wrote on Tue, 25 May 2010: > > On simple standard system -- one disk, one kernel in /boot, no fancy > stuff -- it works quite well. This is enough to use grub2 for new installing of Debian. > On other systems it often breaks miserably. Updates leave my system > unbootable every other time. One major problem are incompatible > versions of the boot loader installed in the MBR and grub.cfg. > > Currently, automatic installation of grub in the MBR is a no-go for me, > because of #554790 but I can't prevent grub from automatically > updating grub.cfg which leads to incompatible versions, hence an > unbootable system. And these problems say, we still need an alternative - I would say: LiLO. William Pitcock wrote on Sat, 22 May 2010: > > After some discussion about lilo on #debian-devel in IRC, it has pretty > much been determined that kernel sizes have crossed the line past where > lilo can reliably determine the payload size. But not all kernels are to large - especially the custom kernels - and LiLO can be used for this special situation. Until which size of kernel is LiLO usable? My suggestion / recommendation is now: a) using grub2 as default boot manager for new installations (d-i) and for updating grub. b) provide LiLO in squeeze as alternative for grub2. The limitations must be said while installing the lilo package. I think it must not be a proposal in d-i. Because I still use LiLO for all my systems, I could support the maintaining of LiLO. Would this a way for you, William? Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: Re (2): lilo removal in squeeze / new lilo upstream
Russell Coker wrote on 2010-06-05 22:30: > On Wed, 26 May 2010, Stephen Powell wrote: > > You're missing the point. The main selling point to management > > is that Linux is free. If they have to buy new backup software > > in order to accommodate Linux' backup requirements, that will > > kill it on the spot. Whatever boot loader I use must not > > require new backup software or impose special backup requirements. > > One of the advantages of Linux is that you are not forced to do things the > way > that the distribution vendor packages it. > > You can take the last lilo package that gets uploaded, build it and put it in > your own apt repository, and then support it for your own users. I see that more people than thought still want to have or need LiLO. Now I have decided to start and reanimate the upstream development. Everyone is invited to join in this development. I'm working on LiLO version 23. Shortly with more informations ... Fondest regards, Joachim Wiedorn signature.asc Description: PGP signature
Re: [RFC] Updating boot loaders in lenny and squeeze
Hello, Ben Hutchings wrote on 2010-06-19 03:55: > However, given that route B is present in both lenny and squeeze (and > even in etch, I think) there is no good reason for packages not to rely > on it now. (Well, except lack of documentation.) All boot loader > packages that fall into case 1 or 2 should be installing hook scripts, > but currently only extlinux does. I intend to remove the vestigial code > for route A, and file bugs on all boot loaders in case 1 or 2 that do > not use route B. It seems this is the first step for optimizing lilo. I have checked the sources for extlinux (package syslinux) and the scripts appears to be simple. > In case 1, the boot loader should also be called by update-initramfs > when it is called outside of kernel package installation and removal. > This is normally covered by route D, but this seems a little fragile. I I have tested this behaviour with a hook script for update-initramfs. There is still a problem: Until now in the script is a check about which bootloader is active. Only if no grub is installed then the script starts lilo after install/update/remove of initrd's. But this feature shall go away and then a hook script for update-initramfs is a good solution (in /etc/initramfs-tools/hooks/). Over all - thanks for you very detailed information. Now I think the lilo package can better maintained again. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
New LILO upstream development
Hello, After the long silence about the popular bootloader LILO the development was started again. The new Homepage can be found here: http://lilo.alioth.debian.org/ For the development of the bootloader I have started an Alioth project with Git repository and Mailinglist: http://alioth.debian.org/projects/lilo/ The next version is in work: LILO 23.0 Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Re: Bootloaders BoF at DebConf?
Colin Watson wrote on 2010-06-21 22:22: > There've been several bootloader-related threads here of late, and > grub2, lilo, and syslinux all seem to have fairly active work happening > on them. (For all I know the same may be true of some of the > bootloaders specific to non-x86 architectures too.) Would it be worth > having a bootloaders BoF of some kind at DebConf, or maybe some hacking > sessions? I'd be curious to know who else would be interested in such a > thing, and whether there's anything particular that other bootloader > maintainers would like to discuss, or maybe things that people would > like to have supported in a bootloader and can come armed with > specialist knowledge. I think that would be a interesting idea. I hope this could be made online, because I have no time to come to far away DebConf's. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Re: Call for Testing: initramfs-tools 0.97
Michael Prokop wrote on 2010-06-18 23:48: > we - the initramfs-tools maintainers in Debian - want to provide a > solid initramfs-tools version for squeeze. The new release 0.97 is > expected to fix many longstanding problems. It would be great if we > could receive feedback from testers. > > The new release is available from Debian/unstable and is expected to > install without problems in at least lenny, squeeze and sid: > > > http://cdn.debian.net/debian/pool/main/i/initramfs-tools/initramfs-tools_0.97_all.deb > SHA256:56eb56d472d0dd24c8f2fd030222586e258ec882b716f02d114865cef9c19639 > > No matter how your partition layout looks like (rootfs on lvm, > crypto, sw-raid,...), if you're booting on physical hardware or a > virtualized system (Xen, openvz, kvm,...) - please give it a shot > and report any possible problems. I have checked the scripts and I was very happy to see that lilo is furthermore supported by initramfs-tools (script update-initramfs). Can I be sure that this support stay in your package? Because of changes in some other packages this would be nearly an existential question. FYI: Lilo have again an upstream developer - myself. If you have some hints for better work together with your package so feel free to send me a mail. Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
Hello William, perhaps you have read the recent email from Ben (see below). It would be important to update the lilo package to support these recent requirements to prepare LILO for Squeeze before it will get stable. Do you have the intention to update the lilo package to integrate some scripts for these recent requirements? Have a nice day, Joachim (Germany) --- Ben Hutchings wrote on 2010-06-28 03:02: > I propose the following policy for squeeze and later releases. This > affects all Linux kernel, initramfs builder and boot loader packages, > and the installer. > > I regret that this is happening so late in the release cycle, but > currently a kernel update can easily leave the system unbootable and > this does need to be addressed before release and I want to do so in a > way that is reasonably clean and maintainable. > > --- > 1. Packages for boot loaders that need to be updated whenever the files > they load are modified (i.e. those that store a block list) must install > hook scripts in /etc/kernel/postinst.d and /etc/kernel/postrm.d, which > will be called on installation/upgrade and removal of kernel packages, > respectively. > > The arguments given to all kernel hook scripts are the kernel ABI > version (the string that uname -r reports) and the absolute path to the > kernel image. The environment variable DEB_MAINT_PARAMS will contain > the arguments given to the kernel maintainer script, single-quoted. > > Since these boot loaders should be updated as the last step during > installation/upgrade and removal, hook scripts for boot loaders must be > named using the prefix 'zz-' and no other packages may use this prefix > or one that sorts later by the rules used by run-parts. A postrm hook > script should warn but exit with code 0 if the boot loader configuration > file still refers to the kernel image that has been removed. > > 2. Packages for boot loaders that need to be updated whenever the files > they load are modified must also install hook scripts in > /etc/mkinitramfs/post-update.d. Initramfs builders must call these > scripts using run-parts after they create, update or delete an > initramfs. The arguments given to these hook scripts are the kernel ABI > version and the absolute path to the initramfs image. > > 3. Initramfs builders must complete their work before returning from the > kernel postinst hook script. [initramfs-tools currently uses a trigger > to defer this because it can also be invoked twice, but this means it > also has to know how to update specific boot loaders.] > > 4. During a kernel package installation, upgrade or removal, various > boot loader hooks may be invoked (in this order): > > a. A postinst_hook or postrm_hook command set by the user or the >installer in /etc/kernel-img.conf > b. A hook script in /etc/mkinitramfs/post-update.d > c. A hook script in /etc/kernel/postinst.d or .../postrm.d > > To avoid unnecessary updates, the hooks invoked at step a and b may > check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and > do nothing in this case. [Is this sensible or is it too 'clever'?] > > 5. Kernel and initramfs builder packages must not invoke boot loaders > except via hooks. If /etc/kernel-img.conf contains an explicit > 'do_bootloader = yes', kernel package maintainer scripts should warn > that this is now ignored. > > 6. The installer must not define do_bootloader, postinst_hook or > postrm_hook in /etc/kernel-img.conf. > --- > > I'm particularly interested to hear whether there are any upgrade issues > I have not addressed. > > Ben. > signature.asc Description: PGP signature
Re: New LILO upstream version 23.0
Hello, the first version of the new LILO is released as version 23.0. The most patches (especially from Debian/OpenSuse/Fedora packages) are included, which fixes some problems. The links can be found in the mail below. Have a nice day, Joachim (Germany) Joachim Wiedorn wrote on 2010-06-19 11:51: > Hello, > > > After the long silence about the popular bootloader LILO the development > was started again. > > The new Homepage can be found here: > http://lilo.alioth.debian.org/ > > For the development of the bootloader I have started an Alioth project > with Git repository and Mailinglist: > http://alioth.debian.org/projects/lilo/ > > The next version is in work: LILO 23.0 > > > Have a nice day, > > Joachim (Germany) signature.asc Description: PGP signature
Re: Bootloaders BoF at DebConf?
Hello, Colin Watson wrote on 2010-06-21 22:22: > There've been several bootloader-related threads here of late, and > grub2, lilo, and syslinux all seem to have fairly active work happening > on them. (For all I know the same may be true of some of the > bootloaders specific to non-x86 architectures too.) Would it be worth > having a bootloaders BoF of some kind at DebConf, or maybe some hacking > sessions? I'd be curious to know who else would be interested in such a > thing, and whether there's anything particular that other bootloader > maintainers would like to discuss, or maybe things that people would > like to have supported in a bootloader and can come armed with > specialist knowledge. Now, I haven't heard more about bootloaders BoF at DebConf. Do you need some more input about LILO for this BoF? Have a nice day, Joachim (Germany) signature.asc Description: PGP signature
Re: List of FTBFS in Ubuntu
Lucas Nussbaum wrote on 2010-12-03 10:36: > No, sorry. I must admit that I didn't spend any time investigating the > failures. However, my irssi backlog says the two major changes in Ubuntu > that could cause failures are: > - --as-needed is now used by default by the linker > - python2.7 Many packages (e.g. xfe, xfce-*) fails with "[LD_ERROR] ...: could not read symbols: Invalid operation" I know that the Xfe package fails because Ubuntu use: "-Bsymbolic-functions" by default by the linker. The reasons for the problems are redefinitions of some library functions in the package. See: https://bugs.launchpad.net/ubuntu/+source/xfe/+bug/644645 Unfortunately I don't know any workaround. All upstreams ought to rewrite many parts of the source code to work with this default linker config. Have a nice day, Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101203112744.5d1d1...@jupiter.home
Re: Pre-Depends: dpkg (>= 1.15.7.2) for dpkg-maintscript-helper okay?
Anders Kaseorg wrote on 2011-03-05 04:05: > I see 4 packages currently in squeeze that declare ‘Pre-Depends: dpkg (>= > 1.15.7.2)’ (cron e16-data ntp ntpdate) and 9 in sid (apticron ccal cron > lilo midori mozplugger ntp ntpdate usb-modeswitch), but I can’t find any > discussion about this on debian-devel. I got the hint for use the Pre-Depends of dpkg with version in LILO from my sponsor. How Steve Langasek wrote "For packages in wheezy/sid, it's redundant" I will remove the Pre-Depends of dpkg in the next upload. Is that o.k.? --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110305232125.02b8c...@jupiter.home
Re: Lintian warning hardening-no-stackprotector although compiled with hardening options
Hello Daniel,
[the appended logfile wasn't complete!]
Daniel Leidert wrote on 2012-05-17 17:25:
> So why does lintian give me those warnings and how can it be fixed?
I had the same problem with fox1.6. Please check your build log file
wether "-fstack-protector" is really inside.
I had found that in configure.ac CXXFLAGS will be reset at first.
Now I use this solution in configure.ac:
CXXFLAGS=${CXXFLAGS}
LDFLAGS=${LDFLAGS}
Perhaps you can use a similar solution.
---
Have a nice day.
Joachim (Germany)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120517173943.4a36f...@jupiter.home
Re: Bug#680539: ITP: hmmer2 -- profile hidden Markov models for protein sequence analysis (version 2)
Hello, Laszlo Kajan wrote on 2012-07-06 18:47: > HMMER is an implementation of profile hidden Markov model methods for > sensitive searches of biological sequence databases using multiple sequence > alignments as queries. Which software/packages do you use together with this package? Is there a way to use this package directly together with some speech recognition software: cmusphinx or simon/julius? --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706194341.7d61e...@jupiter.home
Re: python 2.7 in wheezy / removal messages without reason
David Prévot wrote on 2011-10-06 21:26: > Sure: “All developers are expected to be subscribed to this list.” [0], > but Oliver was referring to “users”. On the other hand, his example mail > (To: duplic...@packages.debian.org) is obviously sent to developers, so > I'd guess no harm is done for our users. It would be very helpful to be subscribed to debian-devel - and I am subscribed. But nevertheless I had to analyse the removing of my package (duply). After a while I saw the reason was duplicity - but why? Until now I don't know the deeper reason - and I haven't found the reason on debian-devel. So I can only wildcatting. --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111007172801.1cf03...@jupiter.home
Re: python 2.7 in wheezy / removal messages without reason
Ben Finney wrote on 2011-10-08 07:34: > Why did it take so long? Aptitude shows immediately that ‘duply’ was to > be removed because ‘duplicity’ was to be removed; and looking one step Usually I use Debian Stable as productive system. So aptitude would be not a help. I looked on packages.qa.debian.org and further ... because of the mail "duply REMOVED from testing". > further, that ‘duplicity’ was to be removed because the available > version has a dependency on “python (< 2.7)”. Inside the named site http://release.debian.org/britney/hints/jcristau in the mail I could not found this information (and also not in the mail). > The tools available on your system can show the reason. Is there another > question you have that I'm not getting? No. --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111008002009.436ce...@jupiter.home
Re: Bug#645895: ftp.debian.org: epoch should be part of the .deb file name
Tollef Fog Heen wrote on 2011-10-19 15:49: > Yes, that's somewhat ugly. You already have to handle % encoded links > for anything pointing to packages with version numbers including ~ > though, so this won't make any difference there. And it would be more difficult for reading - at least for me. Every time copying package files from apt cache which *have* the epoch included I remove this short part in the file names (e.g. 4%3a) because it is bad to read and have no benefit. --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111019191921.2e637...@jupiter.home
Re: Packaging MATE for Debian
Jeremy Bicha wrote on 2012-12-03 15:39: > What's so bad about evince that you need to use a forked version > anyway? Or gnome-icon-theme, gnome-keyring, gnome-terminal, etc. And in the same way: why mdm instead of gdm ? I have created some updates of gdm with the same patches as mdm, but without renaming all files and strings to mdm. In this way the needed patches are smaller and works stable, too. By the way: linuxmint ignore the "quilt 3.0" technique of patching, instead it seems all packages were made as native packages ... --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121203223346.25356...@jupiter.home
Support for SMACK security framework
Hello, since kernel 2.6.25 SMACK is inside the official kernel as alternative to the large SELinux framework. But until now there are no userspace tools packaged in Debian to administrate SMACK. And also there are no additional patches made for system tools (coreutils, ssh, busybox ...). How is the opinion about support for this alternative security framework? Were this theme discussed in the past for Debian? Does some Debian developer want to add userspace support into Debian? Does anybody know reason against support of SMACK? By the way: The main (upstream) developer Casey Schaufler has switched his work to MeeGo (http://www.meego.com) where some packages for SMACK are in current development. --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330131427.11d1c...@jupiter.home
Re: Support for SMACK security framework
Russell Coker wrote on 2011-03-30 22:45: > On Wed, 30 Mar 2011, Joachim Wiedorn wrote: > > How is the opinion about support for this alternative security framework? > > I think it would be good to have it. O.k. > > Does some Debian developer want to add userspace support into Debian? > > Why don't you do it? That's an idea. But my know-how is not very great in security frameworks. Especially someone who know SELinux would be a good reference. > No-one has been interested in doing the coding. I think the support is very poor in Debian until now. Therefore nobody will install and test this new framework and stay with SELinux - right? --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110331203139.6f233...@jupiter.home
Re: Support for SMACK security framework
Hello Russell and Christian, Russell Coker wrote on 2011-04-01 10:19: > > If you need some tips then I will be happy to offer some. I can also host > some developer resources if you need it (we can discuss that off-list). Thank you for your offer for tips and resources. > But you really have to just do it. I didn't know much about "security > frameworks" before I started working on SE Linux. So it seems I have chances to learn it, too. > As SE Linux has significantly less than 50% user-share in Debian that leaves > plenty of scope for you to find some SMACK users. :-# That is my thought, too. "Christian Pohl" wrote on 2011-04-01 08:27: > > I would help you with installing and testing and Thank you for your offer. Then I want to start with maintainance of smack utilities. Thank you very much for your feedback! --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110401103017.4f010...@jupiter.home
Re: Bug#622922: ITP: apparmor -- AppArmor Mandatory Access Control system userspace tools
Ben Hutchings wrote on 2011-04-16 16:11: > I'm (slowly) working on a way to build in all LSMs and then free memory > for those that aren't used. That is a good news because I am on the way to package smack tools for Debian. --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110416195823.09d9b...@jupiter.home
Re: Debian x86 32-bits built for i586 !?
Drake Wilson wrote on 2011-05-15 18:57: > FWIW, I'm using Debian on a Soekris box with an AMD Geode. ISTR being > | model name : Geode(TM) Integrated Processor by National Semi For clarification. There were some different Geode CPUs on the market: CPUs of the old company National Semiconductor (NS): GX1; GX2 (with 3DNow!); GXLV (for the first time in year 2000 / 2001) CPUs of the new company AMD: GX (similar to NS GX2); LX (better GX); NX (similar to Athlon XP) (for the first time in year 2003 / 2004) My CPU "AMD Geode LX" already run with i686 kernel: processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping: 2 cpu MHz : 498.078 cache size : 128 KB fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 sep pge cmov clflush mmx mmxext 3dnowext 3dnow up bogomips: 996.15 clflush size: 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual power management: --- Have a nice day. Joachim (Germany) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110516163410.06b7d...@jupiter.home
Bug#801643: RFA: fox1.6 -- FOX C++ GUI Toolkit
Package: wnpp Severity: normal X-Debbugs-CC: debian-devel@lists.debian.org I request an adopter for the fox1.6 package, as I don't have enough time anymore. The package description is: FOX is a C++ based Toolkit for developing Graphical User Interfaces easily and effectively. It offers a wide collection of Controls and provides state of the art facilities such as drag and drop, selection, as well as OpenGL widgets for 3D graphical manipulation. FOX also implements icons, images, and user-convenience features such as status line help, and tooltips. Tooltips may even be used for 3D objects! The package is in a good shape and upstream is active. Following packages need this library: xfe, libgwenhywfar, sumo, fxcyberjack, gogglesmm, libace-foxreactor-6.3.2 Maintaining a package requires time and skills. Please only adopt this package if you are sure you will have enough time and attention to work on it. If you want to be the new maintainer, please see http://www.debian.org/devel/wnpp/index.html#howto-rfa for detailed instructions how to adopt a package properly. --- Have a nice day. Joachim (Germany) pgpNDE9uJCtWh.pgp Description: Digitale Signatur von OpenPGP
