Re: [Mageia-dev] Freeze push: worldofpadman and worldofpadman-data
Hi, Please remove worldofpadman-1.6-4 from core/release, I mistakenly pushed it there instead of nonfree. Thanks. On Sat, Mar 2, 2013 at 7:16 PM, Olivier Blin wrote: > Juan Luis Baptiste writes: > >> That's strange... I did a mgarepo sync with no errors, and if I run it >> now it doesn't try to upload the sources as they seem to be already >> uploaded: >> >> [mageia@dci-laptop worldofpadman-data]$ mgarepo sync >> [mageia@dci-laptop worldofpadman-data]$ >> >> But the sources don't seem to be recognized by svn: >> >> [mageia@dci-laptop SOURCES]$ ls >> README.install.urpmi sha1.lst wop-1.5-unified.zip >> wop-1.5.x-to-1.6-patch-unified.zip >> [mageia@dci-laptop SOURCES]$ svn status >> ? wop-1.5-unified.zip >> ? sha1.lst >> ? wop-1.5.x-to-1.6-patch-unified.zip >> >> How to fix this ? a svn add on those files ? > > You just have to svn add sha1.lst, the other files are binaries that > should not be hosted on the svn repository. > > boklm: mgarepo sync should really do this automatically for us :-) > > -- > Olivier Blin - blino -- Juancho
Re: [Mageia-dev] Another try at IRAF?
Just an update. I've been told on astrobetter that a lot of work has been done in making IRAF easier to build from source in 2.16, and I've found that this is the case. Right now I've gotten the bootstrap compiler working. There is one sub-library (libVO) that is not working, but I think i can get that working within a week. Once we have IRAF in, I'll look at PyRaf. Once that is in this means that the big three professional astronomy packages will be available via standard RPM (ds9, midas, iraf). One thing about the astronomy community is that it's been moving heavily toward Macintosh, and I'm hoping that by making RPM's available with on the standard distributions, linux is going to be able to stay competitive. It's also important to make the packages standard parts of a linux distribution because making them add-ons means that they don't use the build test infrastructure of the distribution as well as the non-astronomy human infrastructure. On Sun, Mar 3, 2013 at 11:25 AM, Joseph Wang wrote: > Anyone game for trying to package IRAF (again)? > > With 2.16 all of the licensing issues have been fixed. The build > system is ancient but with github we might be able to hack away on > that.
[Mageia-dev] Dutch tax program dependencies
Hi all, The Dutch tax service makes life difficult for (64-bit) Mageia users because the tax filing program expects the i586 versions of libxext6 and libsm6 to be around. The tax service claim on their web site that Ubuntu 12.x and Linux Mint 13 are supported. Could it be that they have these libraries preinstalled on 64 bit platforms? Would it be possible to provide some kind of stub package that downloads the program with the required dependencies, like Arch does? ( https://aur.archlinux.org/packages/belastingdienst-ib2012/ ) regards, -- Reinout van Schouwen
[Mageia-dev] Freeze push libselinux
Please push libselinux It provides a ton of bug fixes the version is the one required for the family It builds locally -- Best regards Thomas Spuhler signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] freeze push: drakx-installer-stage2 & drakxtools
On 5 March 2013 09:27, Guillaume Rousse wrote: >> please push drakx-installer-stage2 & drakxtools >> >> stage2: >> - fork displaying help, thus workarounding a webkit segfault (mga#9124) >> - prevent displaying twice release notes >> >> drakxtools: >> - finish-install: >>o prevent displaying twice release notes > > Build errors for both: > http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130305081954.guillomovitch.valstar.19490/log > http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130305081910.guillomovitch.valstar.18782/log Sorry I'd an issue with git add. Fixed
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
Am 28.02.2013 22:18, schrieb Dan Fandrich: > On Thu, Feb 28, 2013 at 03:25:41PM +0100, Guillaume Rousse wrote: >> Build dependencies are usually specified in installation >> instructions. For humans, of course. You may also try to parse the >> outpout of ./configure (or equivalent) script. In both case, there is >> not garanty then every build dependency will get specified. > The other way is to work backwards by looking at the install dependencies > that rpmbuild discovered, or the NEEDED lines from objdump -x, and adding the > -devel versions of those libraries. That won't catch any compile-time-only > dependencies, though (like libtool, autoconf or flex) but it will give you > something to start from. Note also that some programs will automatically > discover what optional libraries are available at build time and configure > themselves accordingly. So, if you miss some BuildRequires, you might end up > with a binary that works but is missing features. > Dan Or you could try to use iurt, which basically does what the buildsystem does, but it either needs a local Mageia mirror, or fast internet connection, or some patience ;) As the buildsystem can only be used by those with full packager accounts, iurt is the corresponding alternative for padawans and everybody else. https://wiki.mageia.org/en/Packagers_Mentoring_Howto#iurt
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
On Tue, Mar 5, 2013 at 12:54 PM, AL13N wrote: > Op dinsdag 5 maart 2013 20:10:20 schreef Thomas Backlund: > [...] > > For servers (& bigger workstations) where you rely on SCSI / SAS / FC / > > you still need initrds, and usually you dont really care if a > > boot take a little longer. > > does this mean that AHCI is enabled only for desktop kernels? > AHCI is definitely enabled for all kernels. Its also statically compiled into all kernels as well: # cd /usr/src/linux-3.8.1-1.mga3/arch/x86/configs # grep SATA_AHCI * i386_defconfig:CONFIG_SATA_AHCI=y i386_defconfig-desktop:CONFIG_SATA_AHCI=y i386_defconfig-desktop:CONFIG_SATA_AHCI_PLATFORM=y i386_defconfig-desktop586:CONFIG_SATA_AHCI=y i386_defconfig-desktop586:CONFIG_SATA_AHCI_PLATFORM=y i386_defconfig-server:CONFIG_SATA_AHCI=y i386_defconfig-server:CONFIG_SATA_AHCI_PLATFORM=y x86_64_defconfig:CONFIG_SATA_AHCI=y x86_64_defconfig-desktop:CONFIG_SATA_AHCI=y x86_64_defconfig-desktop:CONFIG_SATA_AHCI_PLATFORM=y x86_64_defconfig-server:CONFIG_SATA_AHCI=y x86_64_defconfig-server:CONFIG_SATA_AHCI_PLATFORM=y (If any were modular, they be set to 'm')
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
Op dinsdag 5 maart 2013 20:10:20 schreef Thomas Backlund: [...] > For servers (& bigger workstations) where you rely on SCSI / SAS / FC / > you still need initrds, and usually you dont really care if a > boot take a little longer. does this mean that AHCI is enabled only for desktop kernels?
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
On Tue, Mar 5, 2013 at 12:19 PM, Thomas Backlund wrote: > > If you follow raid devel list you will soon learn that they dont recommend > trusting the /dev/sd* naming either as it is by > no means static... :) > > depending on your hw, they may for example hange place if you happend > to have a usb disk plugged at boot and so on. > > so the thing to check is for example what disk is mapped as > /dev/disk/by-id/* > > > where you can match on actual disc serial number and so on... > then you can be sure wich disk is failing / has failed.. Great advice. I'll make sure the drive's serial numbers are visible without removal and then use ls /dev/disk/by-id/ to make sure I get the right one, if/when the time ever comes... Thanks again -- RJ
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
R James skrev 5.3.2013 19:53: On Tue, Mar 5, 2013 at 11:11 AM, Colin Guthrie mailto:mag...@colin.guthr.ie>> wrote: Anything that relies on ordering is just broken by design. We need to handle things gracefully regardless of the order they are detected. This is why UUIDs are the defacto method for filesystem identification these days and why in mga4 we'll likely switch to a consistent naming scheme for networking devices too. Yes, I understand that cryptic-looking UUIDs are the defacto identifiers but when mdadm reports that /dev/sdf1 has failed in a parity RAID setup, it will be good if a mere mortal can know which drive to replace. :o) If you follow raid devel list you will soon learn that they dont recommend trusting the /dev/sd* naming either as it is by no means static... :) depending on your hw, they may for example hange place if you happend to have a usb disk plugged at boot and so on. so the thing to check is for example what disk is mapped as /dev/disk/by-id/* where you can match on actual disc serial number and so on... then you can be sure wich disk is failing / has failed... -- Thomas
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
R James skrev 5.3.2013 19:34: On Tue, Mar 5, 2013 at 9:41 AM, Thomas Backlund mailto:t...@mageia.org>> wrote: It's needed to be able to boot new hw without need for initrd. https://wiki.mageia.org/en/Feature:BootSansRamdisk Ah, I didn't know about that. It seems like the target systems will need to be simple AND have ahci compliant boot controllers. Otherwise a bunch of SATA drivers will need to be statically compiled in kinda like the old IDE days. It'll be interesting to see how many users complain because they "think" they shouldn't need an initrd... :o) yeah, we / I chose to make only AHCI builtin as pretty much all new hw coming out theese days are ahci-compliant, so it works out of the box. And to not bloat the kernel the "rest of the hw support" got left as modules. Now this feature "booting without initrd" is obviously targetted for laptops/netbooks & desktops where people care about fast boot. For servers (& bigger workstations) where you rely on SCSI / SAS / FC / you still need initrds, and usually you dont really care if a boot take a little longer. -- Thomas
[Mageia-dev] Freeze push: phoronix-test-suite
Hi, Please submit phoronix-test-suite 4.4.0 (4.2.0 for now). Release Date: 20 February, 2012 - Phodevi Hardware/Software Detection Improvements - OpenBenchmarking.org Integration Enhancements - Improved Reporting Of Test Installation Errors - Improved Reporting Of Test Run-Time Errors - Improved BSD Operating System Support - Rewritten PTS External Dependencies Handling - Improved Compiler/User Flag Reporting On Test Results Thanks, -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
On Tue, Mar 5, 2013 at 11:11 AM, Colin Guthrie wrote: > Anything that relies on ordering is just broken by design. We need to > handle things gracefully regardless of the order they are detected. This > is why UUIDs are the defacto method for filesystem identification these > days and why in mga4 we'll likely switch to a consistent naming scheme > for networking devices too. > Yes, I understand that cryptic-looking UUIDs are the defacto identifiers but when mdadm reports that /dev/sdf1 has failed in a parity RAID setup, it will be good if a mere mortal can know which drive to replace. :o) Also "modprobe ordering" is increasingly not true either as many modules > are automatically loaded when the hardware is present. > Yes, but it is possible to override the automatic loading...which is why I like the modular approach. Now that I understand the reasons for going back to statically compiled drivers, I'm OK with rolling my own. Thanks -- RJ
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
On Tue, Mar 5, 2013 at 9:41 AM, Thomas Backlund wrote: > > It's needed to be able to boot new hw without need for initrd. > > https://wiki.mageia.org/en/Feature:BootSansRamdisk Ah, I didn't know about that. It seems like the target systems will need to be simple AND have ahci compliant boot controllers. Otherwise a bunch of SATA drivers will need to be statically compiled in kinda like the old IDE days. It'll be interesting to see how many users complain because they "think" they shouldn't need an initrd... :o)
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
'Twas brillig, and R James at 05/03/13 16:20 did gyre and gimble: > I remember when PATA (IDE) drivers were statically compiled into the > kernel, then we went to modular IDE which I liked because modprobe > ordering could be controlled. (When dealing with parity RAID, its nice > to have logical drive enumeration because SATA ports don't have UUID > labels.) Anything that relies on ordering is just broken by design. We need to handle things gracefully regardless of the order they are detected. This is why UUIDs are the defacto method for filesystem identification these days and why in mga4 we'll likely switch to a consistent naming scheme for networking devices too. Also "modprobe ordering" is increasingly not true either as many modules are automatically loaded when the hardware is present. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
R James skrev 5.3.2013 17:20: I remember when PATA (IDE) drivers were statically compiled into the kernel, then we went to modular IDE which I liked because modprobe ordering could be controlled. (When dealing with parity RAID, its nice to have logical drive enumeration because SATA ports don't have UUID labels.) But now it seems we've come full circle: [root@localhost ~]# grep SATA_AHCI /boot/config-3.8.1-desktop-1.mga3 CONFIG_SATA_AHCI=y CONFIG_SATA_AHCI_PLATFORM=y Is there a compelling reason to do this (other than AHCI is popular)? It's needed to be able to boot new hw without need for initrd. https://wiki.mageia.org/en/Feature:BootSansRamdisk I'm putting together a home-brewed a file server using an old motherboard plus a couple of add-in SATA controllers. With the Mageia stock kernel, the enumeration looks like: sda = RAID disk 08 (ahci) sdb = RAID disk 09 (ahci) sdc = RAID disk 10 (ahci) sdd = RAID disk 11 (ahci) sde = Mageia OS (sata_nv) (1st port on mobo) sdf = RAID disk 01 (sata_nv) sdg = RAID disk 02 (sata_nv) sdh = RAID disk 03 (sata_nv) sdi = RAID disk 04 (sata_sil) sdj = RAID disk 05 (sata_sil) sdk = RAID disk 06 (sata_sil) sdl = RAID disk 07 (sata_sil) Of course its no problem to re-compile the kernel with AHCI as a module so I can modprobe it last. Just wondering why AHCI is now the exception to modular sata...? -- Thomas
[Mageia-dev] Why is AHCI statically compiled into kernel?
I remember when PATA (IDE) drivers were statically compiled into the kernel, then we went to modular IDE which I liked because modprobe ordering could be controlled. (When dealing with parity RAID, its nice to have logical drive enumeration because SATA ports don't have UUID labels.) But now it seems we've come full circle: [root@localhost ~]# grep SATA_AHCI /boot/config-3.8.1-desktop-1.mga3 CONFIG_SATA_AHCI=y CONFIG_SATA_AHCI_PLATFORM=y Is there a compelling reason to do this (other than AHCI is popular)? I'm putting together a home-brewed a file server using an old motherboard plus a couple of add-in SATA controllers. With the Mageia stock kernel, the enumeration looks like: sda = RAID disk 08 (ahci) sdb = RAID disk 09 (ahci) sdc = RAID disk 10 (ahci) sdd = RAID disk 11 (ahci) sde = Mageia OS (sata_nv) (1st port on mobo) sdf = RAID disk 01 (sata_nv) sdg = RAID disk 02 (sata_nv) sdh = RAID disk 03 (sata_nv) sdi = RAID disk 04 (sata_sil) sdj = RAID disk 05 (sata_sil) sdk = RAID disk 06 (sata_sil) sdl = RAID disk 07 (sata_sil) Of course its no problem to re-compile the kernel with AHCI as a module so I can modprobe it last. Just wondering why AHCI is now the exception to modular sata...? Thanks -- RJ
Re: [Mageia-dev] Freeze push: squid
Le 05/03/2013 14:42, David Walser a écrit : This updates to bugfix release 3.2.8, which also fixes a minor security issue with tmpfile creation. Done. -- BOFH excuse #18: excess surge protection
Re: [Mageia-dev] Freeze push: wine
Le 05/03/2013 13:46, Damien Lallement a écrit : Please push wine 1.5.25 as it's a new bug fix release of the 1.5.x series. Done. -- BOFH excuse #147: Party-bug in the Aloha protocol.
[Mageia-dev] Freeze push: squid
This updates to bugfix release 3.2.8, which also fixes a minor security issue with tmpfile creation. Changes to squid-3.2.8 (02 Mar 2013): - Bug 3767: tcp_outgoing_tos/mark ACLs do not obey acl_uses_indirect_client - Bug 3763: diskd Error: no filename in shm buffer - Bug 3752: objects that cannot be cached in memory are not cached on disk - Bug 3753: Removes the domain from the cache_peer server pconn key - Bug 3749: IDENT lookup using wrong ports to identify the user - Bug 3723: tcp_outgoing_tos/mark broken for CONNECT requests - Bug 3686: cache_dir max-size default fails - Bug 3515: crash in FtpStateData::ftpTimeout - Bug 3329: Quieten orphan Comm::Connection messages - Make squid -z for cache_dir rock preserve the rock DB - Fixed several server connect problems - ... and some build issues on Solaris, OpenIndiana, MacOS X - ... and some documentation and debugs polishing http://www.squid-cache.org/Versions/v3/3.2/changesets/SQUID_3_2_8.html I've confirmed that it builds and works fine in Cauldron.
[Mageia-dev] Freeze push: wine
Please push wine 1.5.25 as it's a new bug fix release of the 1.5.x series. Thanks. -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
[Mageia-dev] Team elections
Hi there Here we go again. All Mageia teams are organizing elections for their leaders. Deadline for this vote is 16th of march. Here is the proposed planning: - people can candidate until 10th of march. Please send a mail on this ML explaining why you would like to do so. - we will then open a vote using epoll from 10th to 16th of march Officially we need 2 leaders for the team but I'd like to propose 3 of them as work is big and we are not all available at the same time. What we should wait for these guys (and girls): - organize regular meetings - attend council meetings to represent packagers team - moderate and organize discussions on -dev ML - solve potential conflict between people in the team - look for new comers and help to make them integrate mentoring process - organize specifications and development for the coming releases Feel free to comment :) People should apply if they want to spend some time on these tasks. This does not mean it's a full time job hopefully but it needs to spend some time on it. Cheers -- Anne http://mageia.org
[Mageia-dev] Postpone tonight's meeting
Hi there On my side I'm not available for tonight's meeting but it would be nice to have one this week. Can we organize it tomorrow same time for once ? Main topics: - team leaders vote - release critical bugs review AS usual feel free to propose any topic Cheers -- Anne http://mageia.org
Re: [Mageia-dev] freeze push: subsurface
On Tue, 05 Mar 2013, Guillaume Rousse wrote: > bugfix release. Submitted.
Re: [Mageia-dev] freeze push: stunnel
On Tue, 05 Mar 2013, Guillaume Rousse wrote: > Version 4.55 fixes CVE-2013-1762 Submitted.
[Mageia-dev] freeze push: subsurface
bugfix release. -- BOFH excuse #241: _Rosin_ core solder? But...
[Mageia-dev] freeze push: stunnel
Version 4.55 fixes CVE-2013-1762 -- BOFH excuse #356: the daemons! the daemons! the terrible daemons!
Re: [Mageia-dev] freeze push: drakx-installer-stage2 & drakxtools
Le 05/03/2013 07:20, Thierry Vignaud a écrit : Hi please push drakx-installer-stage2 & drakxtools stage2: - fork displaying help, thus workarounding a webkit segfault (mga#9124) - prevent displaying twice release notes drakxtools: - finish-install: o prevent displaying twice release notes Build errors for both: http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130305081954.guillomovitch.valstar.19490/log http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130305081910.guillomovitch.valstar.18782/log -- BOFH excuse #418: Sysadmins busy fighting SPAM.
Re: [Mageia-dev] Freeze push: xfce4-eyes-plugin 4.4.2
Le 04/03/2013 19:06, Jani Välimaa a écrit : Hi, please push new xfce4-eyes-plugin. It fixes some bugs reported upstream and some other issues. Done. -- BOFH excuse #67: descramble code needed from software company
Re: [Mageia-dev] freeze-push 389-ds-base
Le 04/03/2013 17:39, Thomas Spuhler a écrit : Please push 389-ds-base It fixes a lot of bugs It build locally Done. -- BOFH excuse #165: Backbone Scoliosis
Re: [Mageia-dev] Freeze push: gnome-online-accounts 3.6.3
Le 04/03/2013 18:43, Jani Välimaa a écrit : Hi, please push new gnome-online-accounts. Done. -- BOFH excuse #171: NOTICE: alloc: /dev/null: filesystem full
Re: [Mageia-dev] freeze push: bootloader-utils
Le 05/03/2013 07:13, Thierry Vignaud a écrit : Hi Please push bootloader-utils: it addds support for GRUB2 in rebootin. Done. -- BOFH excuse #267: The UPS is on strike.
