auditd 1.4 compilation
Hi, I would like to compile auditd 1.4[1] on an unstable box. I follow README-install and at the end of configure everything looks right. However make fails instantly (relevant lines only): --cut -- gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -I.. -fPIC -DPIC -D_GNU_SOURCE -g -O2 -MT libaudit.lo -MD -MP -MF .deps/libaudit.Tpo -c libaudit.c -fPIC -DPIC -o .libs/libaudit.o In file included from /usr/include/linux/sched.h:12, from /usr/include/linux/audit.h:27, from libaudit.h:35, from libaudit.c:42: /usr/include/linux/jiffies.h:84: error: syntax error before 'jiffies_64' /usr/include/linux/jiffies.h:88: error: syntax error before 'get_jiffies_64' /usr/include/linux/jiffies.h: In function 'timespec_to_jiffies': /usr/include/linux/jiffies.h:320: error: called object 'u64' is not a function /usr/include/linux/jiffies.h:320: error: called object 'u64' is not a function /usr/include/linux/jiffies.h:320: error: 'NSEC_PER_SEC' undeclared (first use in this function) [...] -- cut -- The syntax errors come from the u64 type is not defined in that scope. It's defined in [asm-i486|asm-x86_64]/types.h through asm/types.h ; but protected with an 'ifdef __KERNEL__' . So I have defined -D__KERNEL__ to the gcc switches, which results in a lot of redefinition errors. Removed it, and put the typedef into libaudit.h, still I get: /usr/include/linux/jiffies.h: In function 'timespec_to_jiffies': /usr/include/linux/jiffies.h:320: error: 'NSEC_PER_SEC' undeclared (first use in this function) Yes, NSEC_PER_SEC protected with 'ifdef __KERNEL__' as well. So I'm lost. It seems I need __KERNEL__ defined and not at the same time. Could anyone compile auditd on a Debian box? Any pointers are greatly appreciated! Regards, Laszlo/GCS [1] http://people.redhat.com/sgrubb/audit/audit-1.1.4.tar.gz signature.asc Description: This is a digitally signed message part
Re: Debian Installer - boot floppies
On Sun, Mar 05, 2006 at 11:19:04AM +0100, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: I think that this is not a position acceptable in debian right now, who aims to support many less-supported-arches/subarches, who still struggle to get their main patches into mainline. So i believe it is sane to accept that for I think it's not acceptable for Debian to try to support drivers or architectures which are unmaintained upstream unless somebody is ready to do the work here. By saying that these obsolete drivers should be supported anyway you are basically requesting other people to spend their time maintaining workarounds in their own packages. Well, we have done this for sarge in a much more extensive way when all we had was discovery to work with. Udev beeing a very important piece of software which is the cause of many troubles recently, and given that you are unwilling to support such backward compatible fixes, i suppose this probably means that you would be willing to accept a (or various) comaintainers who would be willing to maintain those workarounds. All that is asked is that you don't oppose such workaround to be implemented. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer - boot floppies
On Mar 05, Sven Luther [EMAIL PROTECTED] wrote: By saying that these obsolete drivers should be supported anyway you are basically requesting other people to spend their time maintaining workarounds in their own packages. Well, we have done this for sarge in a much more extensive way when all we had was discovery to work with. Udev beeing a very important piece of software which is the cause of many troubles recently, and given that you are unwilling to support such backward compatible fixes, i suppose this probably means that you would be willing to accept a (or various) comaintainers who would be willing to maintain those workarounds. This is just not true, the udev package contains multiple workarounds for broken drivers, starting from ide.agent and vio.agent. I would not mind receiving help with udev either, but with a few notable exceptions most people just talk without writing code, and often do not even know what they are talking about. All that is asked is that you don't oppose such workaround to be implemented. I have no such plan. Just do not expect to implement hacks in my own packages unless there is a timeline for their replacement with proper fixes. -- ciao, Marco signature.asc Description: Digital signature
Re: Debian Installer - boot floppies
On Sun, Mar 05, 2006 at 04:25:01PM +0100, Marco d'Itri wrote: On Mar 05, Sven Luther [EMAIL PROTECTED] wrote: By saying that these obsolete drivers should be supported anyway you are basically requesting other people to spend their time maintaining workarounds in their own packages. Well, we have done this for sarge in a much more extensive way when all we had was discovery to work with. Udev beeing a very important piece of software which is the cause of many troubles recently, and given that you are unwilling to support such backward compatible fixes, i suppose this probably means that you would be willing to accept a (or various) comaintainers who would be willing to maintain those workarounds. This is just not true, the udev package contains multiple workarounds for broken drivers, starting from ide.agent and vio.agent. I would not mind receiving help with udev either, but with a few notable exceptions most people just talk without writing code, and often do not even know what they are talking about. Well, i remember some issues with the firewire module in the sarge timeframe, and how you actively discouraged a workaround for this. All that is asked is that you don't oppose such workaround to be implemented. I have no such plan. Just do not expect to implement hacks in my own packages unless there is a timeline for their replacement with proper fixes. So, on one hand you say you have no plan to oppose workarounds, but on the other hand you clearly oppose such workarounds ? I propose you give some clear guidelines of what will be acceptable and not, and that it be discussed together with all involved people (the kernel team, the release managers and the d-i team at least), before you put any such far-reaching constraints on any possible workarounds, and thus actively discourage people to write code. Also, i would be interested in how your vio and ide hacks described above fit in these guidelines. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer - boot floppies
On Mar 05, Sven Luther [EMAIL PROTECTED] wrote: Well, i remember some issues with the firewire module in the sarge timeframe, and how you actively discouraged a workaround for this. It's hard to be specific since I do not remember the details either, but IIRC I suggested a solution to be implemented in the libraw1394 package. The reason was that the kernel firewire code is close to be unmaintained and there was no plan to add whatever was needed. I do not know if it has been fixed since then, but at least it still does not provide a way to support events synthesis for devices plugged at boot time. I have no such plan. Just do not expect to implement hacks in my own packages unless there is a timeline for their replacement with proper fixes. So, on one hand you say you have no plan to oppose workarounds, but on the other hand you clearly oppose such workarounds ? No, I oppose attempts to require me to maintain them indefinitely in my own packages. It is still possible to add to other packages the rules and scripts needed. I propose you give some clear guidelines of what will be acceptable and not, I am happy to implement compatibily hacks as long as there is a clear plan to remove the need for them in future kernel versions, like a patch which will soon be submitted to the maintainer of the relevant subsystem, and there is no better package to contain them. Or if they are like /lib/udev/modalias_ieee1394, which is unobtrusive enough that I do not mind maintaining it in udev (it is trivial and it will just be ignored when the firewire stack will support $MODALIAS). Also, i would be interested in how your vio and ide hacks described above fit in these guidelines. Respectively 2.6.15 and 2.6.16 implement $MODALIAS, so the rules file will stop calling them. -- ciao, Marco signature.asc Description: Digital signature
Processing of initramfs-tools_0.53b_i386.changes
initramfs-tools_0.53b_i386.changes uploaded successfully to localhost along with the files: initramfs-tools_0.53b.dsc initramfs-tools_0.53b.tar.gz initramfs-tools_0.53b_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
initramfs-tools_0.53b_i386.changes ACCEPTED
Accepted: initramfs-tools_0.53b.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.53b.dsc initramfs-tools_0.53b.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.53b.tar.gz initramfs-tools_0.53b_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.53b_all.deb Announcing to debian-devel-changes@lists.debian.org Closing bugs: 355235 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355235: marked as done (initramfs-tools: file name illegal in variable names)
Your message dated Sun, 05 Mar 2006 13:47:49 -0800 with message-id [EMAIL PROTECTED] and subject line Bug#355235: fixed in initramfs-tools 0.53b has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: initramfs-tools Severity: important From the 0.52 changelog: * scripts/init-premount/udev-helper: Renamed from scripts/init-premount/ide. As - is not valid in shell variable names and initramfs-tools uses shell variable names for handling dependencies, this will cause errors like: eval: 1: array_udev-helper=udev: not found eval: 1: array_udev-helper=: not found on boot. Please rename the file to udev_helper to work around this. - tfheen ---End Message--- ---BeginMessage--- Source: initramfs-tools Source-Version: 0.53b We believe that the bug you reported is fixed in the latest version of initramfs-tools, which is due to be installed in the Debian FTP archive: initramfs-tools_0.53b.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.53b.dsc initramfs-tools_0.53b.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.53b.tar.gz initramfs-tools_0.53b_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.53b_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. maximilian attems [EMAIL PROTECTED] (supplier of updated initramfs-tools package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 4 Mar 2006 15:26:13 +0100 Source: initramfs-tools Binary: initramfs-tools Architecture: source all Version: 0.53b Distribution: unstable Urgency: low Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: maximilian attems [EMAIL PROTECTED] Description: initramfs-tools - tools for generating an initramfs Closes: 355235 Changes: initramfs-tools (0.53b) unstable; urgency=low . * scripts/init-premount/udev_helper: Renamed from udev-helper. Thanks to Tollef Fog Heen [EMAIL PROTECTED] (closes: #355235) Files: 347ac675608ea0aac33945434e43a05e 631 utils optional initramfs-tools_0.53b.dsc d7a29d94649fb846a60a553a3fcd9ff4 34502 utils optional initramfs-tools_0.53b.tar.gz 4c4a4dc288f95c229dfe8bc2f540dfe9 40362 utils optional initramfs-tools_0.53b_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFECy286n7So0GVSSARAvxyAJ9BOestmiQ5o4FBnYLmV/R5GAZNvwCgi505 GpjYSulhvWTrkcWw0JxRGP4= =h2+d -END PGP SIGNATURE- ---End Message---
Re: Debian Installer - boot floppies
On Sun, Mar 05, 2006 at 08:39:28PM +0100, Marco d'Itri wrote: On Mar 05, Sven Luther [EMAIL PROTECTED] wrote: So, on one hand you say you have no plan to oppose workarounds, but on the other hand you clearly oppose such workarounds ? No, I oppose attempts to require me to maintain them indefinitely in my own packages. It is still possible to add to other packages the rules and scripts needed. Which is why i proposed co-maintainership, so that it would not be *you* who had to maintain those issues you don't want to maintain :) If you propose it is best to maintain a udev-hacky-workaround package to make this possible, then so be it, i am not 100% sure it is the best thing to do though, as it would have to closely mirror udev uploads probably, given the highly volatile nature of udev :) Actually, i have been thinking of a grander plan. The reality is that there is a bunch of stuff out there which is not yet hotplug friendly, two that came to my attention was the sparc sbus stuff and the powermac floppies, but undoubtly they are others. I believe it would be best for all involved if we maintained a list of such cases, and had proper workaround in either udev or a separate package, and then, actively search to get those cases fixed in the kernel, either by doing the development ourself, or by pulling attention to it, and try to get the involved persons to act on this. This would have the benefit of clearly showing the problematic cases, providing a workaround to our users who would not have to care about such crass details, and provide a way to do the real fixes and not mean we have to maintain those workarounds indifinitely. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Installer - boot floppies
On Mar 05, Sven Luther [EMAIL PROTECTED] wrote: I believe it would be best for all involved if we maintained a list of such cases, and had proper workaround in either udev or a separate package, and then, actively search to get those cases fixed in the kernel, either by doing the development ourself, or by pulling attention to it, and try to get the involved persons to act on this. This would be very useful. I think you should start a page on the wiki, with links to the LWN articles about the driver core. -- ciao, Marco signature.asc Description: Digital signature
Re: Debian Installer - boot floppies
On Sun, Mar 05, 2006 at 11:35:55PM +0100, Marco d'Itri wrote: On Mar 05, Sven Luther [EMAIL PROTECTED] wrote: I believe it would be best for all involved if we maintained a list of such cases, and had proper workaround in either udev or a separate package, and then, actively search to get those cases fixed in the kernel, either by doing the development ourself, or by pulling attention to it, and try to get the involved persons to act on this. This would be very useful. I think you should start a page on the wiki, Bah, a text page in the kernel svn if i would do that. with links to the LWN articles about the driver core. If you would be so kind and provide the urls for it ? But really, the plan is to provide workaround first ... Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: Re: Bug#354995: amd64-k8-smp kernel makes clock run fast
By the way as an addendum to my previous post. I has the same problem on this machine with a number of (but not all) kernels both 64 and 32 bit. I can't tell you if the BIOS upgrade fixed the problem on all kernels, but I suspect so. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355486: initramfs-tools: please consider to include sata_mv
Package: initramfs-tools
Severity: wishlist
Version: 0.53
Tags: patch
Hi,
I noticed initramfs-tools hadn't sata_mv [Marvell SATA controller]
in hooks, so initramfs-tools couldn't make correct initrd to support
this driver.
Although sata_mv is under development, it works at least.
Thanks,
--
Kenshi Muto
[EMAIL PROTECTED]
--- hook-functions.orig 2006-03-06 00:16:32.0 +
+++ hook-functions 2006-03-06 00:16:50.0 +
@@ -153,7 +153,7 @@
done
;;
scsi)
- for x in 3w-9xxx 3w- a100u2x aacraid advansys ahci aic79xx
aic7xxx ata_piix atari_scsi atp870u BusLogic cciss ch dc395x dmx3191d dpt_i2o
eata fdomain ibmvscsic initio ipr ips isp1020 lpfc max_scsi mac53c94 megaraid
megaraid_mbox megaraid_mm mesh mptfc mptscsih mptsas mptspi nsp32 osst qla1280
qla2100 qla2200 qla2300 qla2322 qla2xxx qla6312 qlogicfas408 qlogicfc
sata_promise sata_nv sata_qstor sata_sil sata_sis sata_svw sata_sx4 sata_uli
sata_via sata_vsc scsi_mod scsi_transport_fc scsi_transport_iscsi
scsi_transport_spi sd_mod sym53c8xx tmscsim; do
+ for x in 3w-9xxx 3w- a100u2x aacraid advansys ahci aic79xx
aic7xxx ata_piix atari_scsi atp870u BusLogic cciss ch dc395x dmx3191d dpt_i2o
eata fdomain ibmvscsic initio ipr ips isp1020 lpfc max_scsi mac53c94 megaraid
megaraid_mbox megaraid_mm mesh mptfc mptscsih mptsas mptspi nsp32 osst qla1280
qla2100 qla2200 qla2300 qla2322 qla2xxx qla6312 qlogicfas408 qlogicfc
sata_promise sata_nv sata_qstor sata_sil sata_sis sata_svw sata_sx4 sata_uli
sata_via sata_vsc sata_mv scsi_mod scsi_transport_fc scsi_transport_iscsi
scsi_transport_spi sd_mod sym53c8xx tmscsim; do
manual_add_modules ${x}
done
;;
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349354: initramfs-tools - kernel -udev dependency loop
On Sat, 2006-03-04 at 00:47 +0100, maximilian attems wrote: On Thu, 02 Mar 2006, Adam C Powell IV wrote: The new upgrade procedure fails on alpha, regardless of the kernel workaround, there's still a udev - initramfs-tools dependency loop which interrupts the udev postinst, and the failures cascade from there: please upgrad initramfs-tools to latest 0.53 in testing/unstable. Okay, 0.53 is in testing now (maybe a day or two ago). But again, with the new initramfs-tools unpacked (but not configured): Setting up udev (0.085-1) ... Kernel version too old. initramfs-tools requires at least 2.6.12. dpkg: error processing udev (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of initramfs-tools: initramfs-tools depends on udev (= 0.076-5); however: Package udev is not configured yet. I don't know whether this will prevent an upgrade from sarge, but it does stop an upgrade from old etch to new etch. Thanks, -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#349354: initramfs-tools - kernel -udev dependency loop
On Sun, Mar 05, 2006 at 10:54:33PM -0500, Adam C Powell IV wrote: Okay, 0.53 is in testing now (maybe a day or two ago). But again, with the new initramfs-tools unpacked (but not configured): Setting up udev (0.085-1) ... Kernel version too old. initramfs-tools requires at least 2.6.12. dpkg: error processing udev (--configure): subprocess post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of initramfs-tools: initramfs-tools depends on udev (= 0.076-5); however: Package udev is not configured yet. I don't know whether this will prevent an upgrade from sarge, but it does stop an upgrade from old etch to new etch. thanks for your testing, you catched me. didn't reset takeover as declared in changelog... ooh zut. you'll get an 0.53c today in unstable. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
