Re: [Mageia-dev] freeze push: libroffice
Thomas Backlund skrev 29.1.2013 06:36: Thierry Vignaud skrev 28.1.2013 07:37: Hi Please let in freeze push: libroffice-4.0.0.2 This is RC2, we have RC1. Thx Submitted. http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20130129043512.tmb.valstar.7406/log/libreoffice-4.0.0.2-1.mga3/build.0.20130129043609.log -- Thomas
Re: [Mageia-dev] freeze push: libroffice
Thierry Vignaud skrev 28.1.2013 07:37: Hi Please let in freeze push: libroffice-4.0.0.2 This is RC2, we have RC1. Thx Submitted. -- Thomas
Re: [Mageia-dev] Freeze push: libssh (security update)
David Walser skrev 29.1.2013 02:42: Updating to version 0.5.4, which just fixes 3 crasher bugs: -CVE-2013-0176 – NULL dereference leads to denial of service -Fixed several NULL pointer dereferences in SSHv1. -Fixed a free crash bug in options parsing. http://www.libssh.org/2013/01/22/libssh-0-5-4-security-release/ Confirmed it builds successfully locally. Submitted. -- Thomas
[Mageia-dev] Freeze push: libssh (security update)
Updating to version 0.5.4, which just fixes 3 crasher bugs: -CVE-2013-0176 – NULL dereference leads to denial of service -Fixed several NULL pointer dereferences in SSHv1. -Fixed a free crash bug in options parsing. http://www.libssh.org/2013/01/22/libssh-0-5-4-security-release/ Confirmed it builds successfully locally.
Re: [Mageia-dev] Cleaning up init
On Tue, 29 Jan 2013, JA Magallón wrote: After a test with symlinks -r, I discovered I had /etc/rc.d full of dangling symlinks, due to services moved to systemd. Should an update of initscripts clean them (symlinks -rd /etd/rc.d) ? I suppose this will also happen when people updates mga2 to mga3... In sendmail's post script I have a: chkconfig --del sendmail (guarded by some ifs!) so no leftover symlinks from sendmail. Christiaan
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 2013-01-28 22:38 (GMT) Barry Jackson composed: Felix Miata wrote: On 2013-01-28 19:27 (GMT) Barry Jackson composed: So IMO all of the FUD about "you can't install grub2 to the PBR" is pointless since it's just not necessary. Maybe not all is FUD. I don't see anything in that README that describes a procedure for an OS/2 or eCS multibooter whose primary bootloader and/or bootloader of choice is IBM Boot Manager, which is prerequisite to booting OS/2 when it is installed to a logical partition (the only place I've ever installed it in the past decade). It can't be told to load a particular file on a partition, only its PBR via the simple process of selecting a partition in its setup utility for inclusion in its boot menu. It works (in effect, chainloads) fine for partitions on which Grub Legacy has been configured with the Grub Legacy setup command. The only options I see for such users is selecting a partition with Grub Legacy configured with menu.lst stanza(s) that include core.img, or configuring IBM BM as a secondary bootloader to a primary bootloader that is not installed on the MBR. Maybe. I have no OS/2 systems to test with. I think grub2 can be forced to write to the PBR (but I can't find it documented just now). Maybe you could investigate and test this and suggest an edit to the README ? Doing this justice probably requires a bigger scope than I can handle. I stopped upgrading eCS at v2.0, while in releases since then, the default eCS boot manager was changed to AiR-Boot, which is yet another problem, as it installs into the MBR track. OTOH, Gene Alexander, who is an eCS VAR, should be equipped to do this if he's willing and able to invest the time. I see he's filed 25 Mageia bugs and was a Mandriva user pre-Mageia. Not only is eCS >2.0 beyond my means (and interest), Grub Legacy took me a long time to wrap my head around, leaving me loathe to invest more than nominal time in Grub2 issues, with its extensive deviations from Grub Legacy basics, and yet youthful stage of development and documentation. I've only ever allowed Grub2 to be installed on a very few *buntu installs. I currently have Kubuntu 10.04 LTS with Grub 1.98 on its sda12 PBR booting from IBM BM on sda2 on host gx150, and I have Kubuntu 12.04 LTS with Grub 1.99 on its sda15 PBR booting from IBM BM on sda2 on host t2240. These are 13 & 11 year old and slow Intel systems. The former is i815 with Piii CPU with neither had Mandriva nor Mageia ever installed, and I like to avoid doing any more than I must with it. The newer host t2240 is a Celeron P4 @ 2.40GHz and i845G chipset I have similar but weaker aversion to use. It does have M2 with Grub Legacy on sda16 PBR booting from IBM BM (until today not booted since June). Does M2 have current Grub2 in backports, or would it be simple enough to install from Cauldron repos? If so, maybe if needed and pressed I could find time to try installing Grub2 to its PBR. I'm not of a mind to replace M2 there yet, and it doesn't have space for a new installation of anything until I figure out what if anything I want to do about its crowded HD. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
[Mageia-dev] Cleaning up init
Hi... After a test with symlinks -r, I discovered I had /etc/rc.d full of dangling symlinks, due to services moved to systemd. Should an update of initscripts clean them (symlinks -rd /etd/rc.d) ? I suppose this will also happen when people updates mga2 to mga3... I also discovered what seem like leftovers from previous conversions in /etc/rc.d/init.d: - dm (native prefdm exists) - irqbalance (package includes both, native and sysv) - linux_logo (same, native+sysv) - lm_sensors (idem) - mpd (idem) - mysqld (idem) - portreserve (idem) - netconsole (package is not even in the repos) - partmon (idem) Are we in time to correct these for Mageia 3 ? And to switch the remins to systemd, like resolvconf or postfix ? TIA -- J.A. Magallon \ Winter is coming...
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 28/01/13 20:09, Frank Griffin wrote: ...this is where we disagree slightly ;) Chainloading into grub2 is not the best way, due to the block lists problem people keep mentioning and complaining about. Could you please explain why ? The whole MBR/PBR design was set up so that whatever gets loaded and receives control doesn't know which way it happened. How does grub2 break this ? My limited understanding is that the code in the 512 byte PBR has to use block lists to find the core image in /boot, since it is too small to understand filesystems. This is fragile in that filesystems and file utilities may move files around on disk invalidating the block lists, and for this reason the method is discouraged. A far as I know the same potential problem exists with grub legacy. Whether the same fragility applies to the multiboot approach I am not sure, as documentation is sparse, however grub2 developers agree that it is a valid method. Chanloading is un-necessary I don't claim that it's necessary, just that it's more desirable than requiring the MBR code to go poking around in partitons other than the one from which it was installed. If you're interested in keeping partitions functionally as separate as they can be, it just makes sense to have them booted by their own bootloaders. The MBR code cannot go poking around. It points to one location only. In the case of grub2 this is normally a copy of core.img located in the 'MBR-gap' of around 31kB (or larger depending on partitioning) below the start of the first sector. This then launches the boot menu for the system that created it, or a dedicated grub installation. If the intention is to put the bootloader in the root partition by whatever method, then it has no relation to the MBR. The intention is to boot into the system's bootloader from another primary bootloader. The bootloader built into the core.img in the system root *is* it's own, just as would be the case with chainloading, so I don't really see the distinction. Barry
Re: [Mageia-dev] Proposal for Gstreamer 1.0 packaging: tainted version should require the tainted specific plugins
On Mon, 28 Jan 2013 22:57:14 +0100 Olav Vitters wrote: > I think #2 is the best option. If someone enables tainted, then likely > they just want video playing to work. Furthermore, this avoids > changing all the video players which could use GStreamer. No, it should be 1 done as both tainted and Core just as is done with mplayer, xine, vlc, gstreamer-plugins-bad and others apps. Charles -- The last thing one knows in constructing a work is what to put first. -- Blaise Pascal -- Mageia release 3 (Cauldron) for x86_64$ On SuperSizehttp://www.eslrahc.com Registered Linux user #182463 3.8.0-server-0.rc5.1.mga3 x86_64 -- signature.asc Description: PGP signature
Re: [Mageia-dev] Proposal for Gstreamer 1.0 packaging: tainted version should require the tainted specific plugins
On Mon, 28 Jan 2013, Olav Vitters wrote: To allow Totem to play back any file, in practice you want to install GStreamer 1.0 from the tainted section. Ideally to play back a lot of files, you'll want: gstreamer1.0-dts gstreamer1.0-faad gstreamer1.0-x264 gstreamer1.0-amrwbdec However, I cannot rely on those in totem.spec, because they are in the tainted section. I see two ways of solving this: 1. Building a non-tainted and a tainted totem The tainted one has Requires: for the tainted gstreamer 1.0 packages you'll very likely want. Benefit: - Avoids Gstreamer 1.0 plugin packages from depending on lots of other packages Drawback: - Has to be repeated for every video player that uses GStreamer - Tracking subpackages can be difficult - Totem tainted version has a lot more dependencies 2. Ensure that installing the tainted gstreamer1.0 plugin packages installs all related tainted plugin packages Example: gstreamer1.0-plugins-bad package in tainted should have: Requires: gstreamer1.0-dts Requires: gstreamer1.0-faad Due to subpackages possibly being moved in and out of the tainted section, the only thing I want to change is the Requires. I'm not planning to merge the subpackage.. even if it maybe is a little bit weird to have the main package always require the subpackage. Benefit: - Ensures that enabling tainted section makes video playing 'work' in any player that uses GStreamer - List of subpackages is maintained in just one place Drawback: - Increases the size + dependencies of the tainted gstreamer subpackage - Cannot just install just one tainted subpackage, have to install them all at once I think #2 is the best option. If someone enables tainted, then likely they just want video playing to work. Furthermore, this avoids changing all the video players which could use GStreamer. Have you noticed gstreamer0.10-decoders and gstreamer0.10-decoders-audio ? Those can do the same as your point 2. but for all plugins independent of the source packages. So basically task- packages for gstreamer plugins that totem, other players and transcoders/editors can use. That way you get meta packages for demuxers, muxers, audio-decoders, audio-encoders, video-decoders, and video-encoders which depend on the standard/typical plugins. Christiaan
Re: [Mageia-dev] Proposal for Gstreamer 1.0 packaging: tainted version should require the tainted specific plugins
Le 28/01/2013 22:57, Olav Vitters a écrit : > To allow Totem to play back any file, in practice you want to install > GStreamer 1.0 from the tainted section. > > Ideally to play back a lot of files, you'll want: > gstreamer1.0-dts > gstreamer1.0-faad > gstreamer1.0-x264 > gstreamer1.0-amrwbdec > > However, I cannot rely on those in totem.spec, because they are in the > tainted section. > > I see two ways of solving this: > 1. Building a non-tainted and a tainted totem >The tainted one has Requires: for the tainted gstreamer 1.0 packages >you'll very likely want. > >Benefit: > - Avoids Gstreamer 1.0 plugin packages from depending on lots of > other packages > >Drawback: > - Has to be repeated for every video player that uses GStreamer > - Tracking subpackages can be difficult > - Totem tainted version has a lot more dependencies > > 2. Ensure that installing the tainted gstreamer1.0 plugin packages >installs all related tainted plugin packages > >Example: >gstreamer1.0-plugins-bad package in tainted should have: > Requires: gstreamer1.0-dts > Requires: gstreamer1.0-faad > >Due to subpackages possibly being moved in and out of the tainted >section, the only thing I want to change is the Requires. I'm not >planning to merge the subpackage.. even if it maybe is a little bit >weird to have the main package always require the subpackage. > >Benefit: > - Ensures that enabling tainted section makes video playing 'work' > in any player that uses GStreamer > - List of subpackages is maintained in just one place > >Drawback: > - Increases the size + dependencies of the tainted gstreamer > subpackage > - Cannot just install just one tainted subpackage, have to install > them all at once > > I think #2 is the best option. If someone enables tainted, then likely > they just want video playing to work. Furthermore, this avoids changing > all the video players which could use GStreamer. > > Thoughts? > It should not be automatically with packagekit ?
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 28/01/13 20:01, Felix Miata wrote:
On 2013-01-28 19:27 (GMT) Barry Jackson composed:
http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/README.Mageia?view=markup
Chainloading into grub2 is not the best way, due to the block lists
problem people keep mentioning and complaining about.
Grub2 can install it's kernel in the root filesystem which can be booted
directly. Installing the grub2 package, whether during install or later
automatically builds /boot/grub/i386-pc/core.img and also creates a
grub.cfg ready for use.
Chanloading is un-necessary since an entry in menu.lst on a legacy
system will boot a grub2 Mageia system using:
title Mageia via GRUB 2
root (hdx,y)
kernel /boot/grub2/i386-pc/core.img
...as explained in the above README.Mageia
I use a small grub2 partition sda1 as "master".
To boot into Mageia grub2 systems I use the grub2 multiboot command:
menuentry 'Mageia-3 multi sda6' {
search --no-floppy --label --set=root mageia-3
multiboot /boot/grub2/i386-pc/core.img
}
So IMO all of the FUD about "you can't install grub2 to the PBR" is
pointless since it's just not necessary.
Maybe not all is FUD. I don't see anything in that README that describes
a procedure for an OS/2 or eCS multibooter whose primary bootloader
and/or bootloader of choice is IBM Boot Manager, which is prerequisite
to booting OS/2 when it is installed to a logical partition (the only
place I've ever installed it in the past decade). It can't be told to
load a particular file on a partition, only its PBR via the simple
process of selecting a partition in its setup utility for inclusion in
its boot menu. It works (in effect, chainloads) fine for partitions on
which Grub Legacy has been configured with the Grub Legacy setup
command. The only options I see for such users is selecting a partition
with Grub Legacy configured with menu.lst stanza(s) that include
core.img, or configuring IBM BM as a secondary bootloader to a primary
bootloader that is not installed on the MBR.
Maybe.
I have no OS/2 systems to test with.
I think grub2 can be forced to write to the PBR (but I can't find it
documented just now).
Maybe you could investigate and test this and suggest an edit to the
README ?
Re: [Mageia-dev] Mageia 3 observations
On Mon, Jan 28, 2013 at 11:09:32PM +0100, Reinout van Schouwen wrote: > Size restrictions? I doubt it, I have 26G free on /. > > Note that I did a clean install so there must be something else that went > wrong. I meant size restrictions on whatever you downloaded, the DVD or maybe the USB version. Did you install the package from the DVD / USB stick, or install it via internet? Please also give a link to what you downloaded so I can take a look at the packages are on there. -- Regards, Olav
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On Mon, 28 Jan 2013 20:08:21 +, Barry Jackson wrote: > http://paste.kde.org/658670/ > Copy it quick I think it expires in 24 hours ;) Got it! Many thanks. -- /\/\aurice
Re: [Mageia-dev] Mageia 3 observations
Hi Olav,
Size restrictions? I doubt it, I have 26G free on /.
Note that I did a clean install so there must be something else that went
wrong.
--
Reinout van Schouwen
2013/1/28 Olav Vitters
> On Mon, Jan 28, 2013 at 10:29:52PM +0100, Reinout van Schouwen wrote:
> > Working with Gnome3, I found that some gvfs back-ends weren't set up
> > correctly so that the file chooser couldn't access smb or ssh locations.
> I
> > had to install gvfs-smb manually as well as the openssh client. This is
> an
> > inconvenience but I'm not sure it can be categorized as a bug.
>
> gvfs already has:
> Suggests: %{name}-fuse
> Suggests: %{name}-smb
> Suggests: %{name}-archive
> Suggests: %{name}-iphone
>
> I'm guessing size restrictions caused them not to be installed? Anyone
> have a suggestion on how to ensure that they're there without causing
> size issues? rpmsrate-raw?
>
> openssh client I don't see as a suggests.
> --
> Regards,
> Olav
>
--
Reinout van Schouwen
http://vanschouwen.info/
Re: [Mageia-dev] Mageia 3 observations
On Mon, Jan 28, 2013 at 10:29:52PM +0100, Reinout van Schouwen wrote:
> Working with Gnome3, I found that some gvfs back-ends weren't set up
> correctly so that the file chooser couldn't access smb or ssh locations. I
> had to install gvfs-smb manually as well as the openssh client. This is an
> inconvenience but I'm not sure it can be categorized as a bug.
gvfs already has:
Suggests: %{name}-fuse
Suggests: %{name}-smb
Suggests: %{name}-archive
Suggests: %{name}-iphone
I'm guessing size restrictions caused them not to be installed? Anyone
have a suggestion on how to ensure that they're there without causing
size issues? rpmsrate-raw?
openssh client I don't see as a suggests.
--
Regards,
Olav
[Mageia-dev] Proposal for Gstreamer 1.0 packaging: tainted version should require the tainted specific plugins
To allow Totem to play back any file, in practice you want to install GStreamer 1.0 from the tainted section. Ideally to play back a lot of files, you'll want: gstreamer1.0-dts gstreamer1.0-faad gstreamer1.0-x264 gstreamer1.0-amrwbdec However, I cannot rely on those in totem.spec, because they are in the tainted section. I see two ways of solving this: 1. Building a non-tainted and a tainted totem The tainted one has Requires: for the tainted gstreamer 1.0 packages you'll very likely want. Benefit: - Avoids Gstreamer 1.0 plugin packages from depending on lots of other packages Drawback: - Has to be repeated for every video player that uses GStreamer - Tracking subpackages can be difficult - Totem tainted version has a lot more dependencies 2. Ensure that installing the tainted gstreamer1.0 plugin packages installs all related tainted plugin packages Example: gstreamer1.0-plugins-bad package in tainted should have: Requires: gstreamer1.0-dts Requires: gstreamer1.0-faad Due to subpackages possibly being moved in and out of the tainted section, the only thing I want to change is the Requires. I'm not planning to merge the subpackage.. even if it maybe is a little bit weird to have the main package always require the subpackage. Benefit: - Ensures that enabling tainted section makes video playing 'work' in any player that uses GStreamer - List of subpackages is maintained in just one place Drawback: - Increases the size + dependencies of the tainted gstreamer subpackage - Cannot just install just one tainted subpackage, have to install them all at once I think #2 is the best option. If someone enables tainted, then likely they just want video playing to work. Furthermore, this avoids changing all the video players which could use GStreamer. Thoughts? -- Regards, Olav
[Mageia-dev] Mageia 3 observations
Hi all, I've installed the latest Mageia 3 beta with Gnome 3 and played with it a little in the past few days. Although I like the overall impression, there is an (almost) showstopper for me, namely the fact that the wireless network (ath9k) doesn't work right from the start as in Mageia 2. I filed this as bug 8758. Working with Gnome3, I found that some gvfs back-ends weren't set up correctly so that the file chooser couldn't access smb or ssh locations. I had to install gvfs-smb manually as well as the openssh client. This is an inconvenience but I'm not sure it can be categorized as a bug. I've had two occassions of X crashing as well. This is filed as bug 8877. regards, -- Reinout van Schouwen
[Mageia-dev] Freeze push : weboob
Please push weboob which as a tool that follows websites versions must be often updated : - added a requires for python-cssselect which is needed by some modules - new version 0.e is required by at least the arte module : Unable to load module "arte": Module requires Weboob 0.e, but you use Weboob 0.c
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 01/28/2013 02:27 PM, Barry Jackson wrote: Err... # grub root (hdx,y) setup (hdx,y) quit Job done - there is no need to touch install.sh Err, [root@ftglap grub]# cat /boot/grub/install.sh grub --device-map=/boot/grub/device.map --batch < ...this is where we disagree slightly ;) Chainloading into grub2 is not the best way, due to the block lists problem people keep mentioning and complaining about. Could you please explain why ? The whole MBR/PBR design was set up so that whatever gets loaded and receives control doesn't know which way it happened. How does grub2 break this ? Chanloading is un-necessary I don't claim that it's necessary, just that it's more desirable than requiring the MBR code to go poking around in partitons other than the one from which it was installed. If you're interested in keeping partitions functionally as separate as they can be, it just makes sense to have them booted by their own bootloaders.
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 27/01/13 15:24, Maurice Batey wrote: On Sun, 27 Jan 2013 12:31:37 +, Barry Jackson wrote: my "master" grub2 grub.cfg which is in a small grub partition at the start of sda. How does one acquire a 'small grub partition'? (Just get GRUB2 package to install into an empty partition?) Yes - in a nutshell Create a partition preferably near the start of the drive and label it "maingrub" then: mkdir -p /maingrub && \ mount -L maingrub /maingrub && \ grub2-install --root-directory=/maingrub /dev/sda Now the MBR point to maingrub, but there is no menu yet. You can manually create a simple grub.cfg - there are examples in the grub2 documentation - there's a link in the README It won't be pretty, but can be made to look nice with a good colour choice. You could let grub2 create a grub.cfg to get started, but it will be over complicated and point directly to the current kernels which is no use once kernels get updated. You really need entries that multiboot (into grub2) or chainload (into legacy linux). My current grub.cfg is a bit big as I need to remove some old entries, however it may be a good reference for you. The theme references don't work - that was just experimental. http://paste.kde.org/658670/ Copy it quick I think it expires in 24 hours ;) My MBR points to this partition, so all OS's are either chainloaded or multibooted from the manually created entries in this grub.cfg Which do you have in the MBR: GRUB2 or Legacy? Grub2 - have had for the last year or so, but you could also put grub legacy in there as well since they can coexist, then simply re-write one or the other to MBR to switch ;) My limited understanding is that it is similar to chainloading but does not need embedded code in the PBR. Ah,now that's interesting! (I assume you mean 'does not need GRUB2 installed in the PBR') Yes A useful side effect is that grub legacy may be installed to the PBR and used if required, I assume you mean the PBR of the 'small grub partition'. No - I mean that since grub2 is not using the PBR, legacy can, if you wish to have them installed side by side. Mamy thanks, Barry, especially w.r.t to the 'bootloader' partition! Note that the small grub partition is never mounted and never written to by any system (unless you need to modify it of course) This means that no system can screw it up :) - only you :\
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 2013-01-28 19:27 (GMT) Barry Jackson composed:
http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/README.Mageia?view=markup
Chainloading into grub2 is not the best way, due to the block lists
problem people keep mentioning and complaining about.
Grub2 can install it's kernel in the root filesystem which can be booted
directly. Installing the grub2 package, whether during install or later
automatically builds /boot/grub/i386-pc/core.img and also creates a
grub.cfg ready for use.
Chanloading is un-necessary since an entry in menu.lst on a legacy
system will boot a grub2 Mageia system using:
title Mageia via GRUB 2
root (hdx,y)
kernel /boot/grub2/i386-pc/core.img
...as explained in the above README.Mageia
I use a small grub2 partition sda1 as "master".
To boot into Mageia grub2 systems I use the grub2 multiboot command:
menuentry 'Mageia-3 multi sda6' {
search --no-floppy --label --set=root mageia-3
multiboot /boot/grub2/i386-pc/core.img
}
So IMO all of the FUD about "you can't install grub2 to the PBR" is
pointless since it's just not necessary.
Maybe not all is FUD. I don't see anything in that README that describes a
procedure for an OS/2 or eCS multibooter whose primary bootloader and/or
bootloader of choice is IBM Boot Manager, which is prerequisite to booting
OS/2 when it is installed to a logical partition (the only place I've ever
installed it in the past decade). It can't be told to load a particular file
on a partition, only its PBR via the simple process of selecting a partition
in its setup utility for inclusion in its boot menu. It works (in effect,
chainloads) fine for partitions on which Grub Legacy has been configured with
the Grub Legacy setup command. The only options I see for such users is
selecting a partition with Grub Legacy configured with menu.lst stanza(s)
that include core.img, or configuring IBM BM as a secondary bootloader to a
primary bootloader that is not installed on the MBR.
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
--- On Mon, 1/28/13, AL13N wrote: > From: AL13N > Subject: Re: [Mageia-dev] [changelog] cauldron core/release > task-obsolete-3-56.mga3 > To: mageia-dev@mageia.org > Cc: "David Walser" > Date: Monday, January 28, 2013, 2:08 PM > Op zondag 27 januari 2013 18:53:10 > schreef David Walser: > > zezinho wrote: > > > Name : > task-obsolete > Relocations: (not relocatable) > > > Version : 3 > > Vendor: > Mageia.Org > > > Release : 56.mga3 > > Build Date: Sun Jan 27 > > > 12:28:18 2013 > > > > > > zezinho 3-56.mga3: > > > + Revision: 392711 > > > - zsnes removed > > > > Why!?? I don't want this removed from my system! > > a reason to why it was removed would've been better The way we usually handle removing packages from the distro is there's some discussion about it on the list first, not just a packager unilaterally deciding it. Even if it was agreed to remove this one from the distro, putting it in task-obsolete in this case is not appropriate.
Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3
On 21/01/13 00:01, Frank Griffin wrote:
On 01/20/2013 02:58 PM, Maurice Batey wrote:
On Sun, 20 Jan 2013 20:04:32 +0200, Thomas Backlund wrote:
http://svnweb.mageia.org/packages/cauldron/grub2/current/SOURCES/README.Mageia?view=markup
Many thanks, Thomas!
Look, I don't don't want to restate the obvious, but you *do* realize
that in order for chainloader to work, you actually have to install the
secondary bootloader on the PBR of its owing partition ? You can't just
have installed grub on your MBR at some point in the past, then install
grub2 (or anything else, for that matter) on the MBR again, and expect
your original partitions to boot ?
In MGA install terms, and specific to the case of grub2 on the MBR
trying to boot grub on a PBR, you have to boot the grub partition (or do
the boot-elsewhere/chroot thing), modify the /boot/grub/install.sh to
not target the MBR (stage2=(hd0)) but indicate the PBR (stage2=(hd0,x))
and rerun install.sh to install grub on the PBR.
Err...
# grub
root (hdx,y)
setup (hdx,y)
quit
Job done - there is no need to touch install.sh
In terms of the install paradigm, you have to choose to install the
bootloader to the PBR (sdaX) rather than the MBR (sda). Otherwise, when
the MBR bootloader, whether grub2 or grub, boots and chains to the PBR
of the desired partition, there won't be anything there in the PBR to boot.
True, except as below...
If you need clarification on this, ask, and give specifics. The
objective of chainloading is to have each PBR (partition) behave as if
it is its own MBR. If you try to point grub2 menu entries to native
partiton grub files, or vice versa, you are just asking for trouble. The
clean way to do it is to use chainloading to link the MBR (whatever it
is) to the PBR (whatever it is), and let the PBR do the bootloading for
its own partition according to its own needs.
...this is where we disagree slightly ;)
Chainloading into grub2 is not the best way, due to the block lists
problem people keep mentioning and complaining about.
Grub2 can install it's kernel in the root filesystem which can be booted
directly. Installing the grub2 package, whether during install or later
automatically builds /boot/grub/i386-pc/core.img and also creates a
grub.cfg ready for use.
Chanloading is un-necessary since an entry in menu.lst on a legacy
system will boot a grub2 Mageia system using:
title Mageia via GRUB 2
root (hdx,y)
kernel /boot/grub2/i386-pc/core.img
...as explained in the above README.Mageia
If you do it this way, you can install whatever you want as a bootloader
on the MBR, and each partition can have whatever BIOS-compliant
bootloader it wants, including grub, grub2, lilo, OS/2, DOS, or Wndows.
Yes, I use a small grub2 partition sda1 as "master".
To boot into Mageia grub2 systems I use the grub2 multiboot command:
menuentry 'Mageia-3 multi sda6' {
search --no-floppy --label --set=root mageia-3
multiboot /boot/grub2/i386-pc/core.img
}
So IMO all of the FUD about "you can't install grub2 to the PBR" is
pointless since it's just not necessary.
My 2 cents ;)
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
Op zondag 27 januari 2013 18:53:10 schreef David Walser: > zezinho wrote: > > Name: task-obsoleteRelocations: (not relocatable) > > Version : 3 Vendor: Mageia.Org > > Release : 56.mga3 Build Date: Sun Jan 27 > > 12:28:18 2013 > > > > zezinho 3-56.mga3: > > + Revision: 392711 > > - zsnes removed > > Why!?? I don't want this removed from my system! a reason to why it was removed would've been better
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
On Mon, Jan 28, 2013 at 6:07 PM, Jose Jorge wrote: > Le 28/01/2013 13:26, Pascal Terjan a écrit : > >>> And isn't the purpose of task-obsoletes to remove from mirrors? >> >> >> No, it is to remove from users machine when the packages will not >> work/break other things/have security problems/... and there is no >> replacement >> > > So I badly understood the wiki : > > https://wiki.mageia.org/en/Packaging_guidelines#Obsoleting_a_package I think there was a discussion recently about defining it better :)
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
Le 28/01/2013 13:26, Pascal Terjan a écrit : And isn't the purpose of task-obsoletes to remove from mirrors? No, it is to remove from users machine when the packages will not work/break other things/have security problems/... and there is no replacement So I badly understood the wiki : https://wiki.mageia.org/en/Packaging_guidelines#Obsoleting_a_package
Re: [Mageia-dev] Peazip
On 27.01.2013 16:57, Joseph Wang wrote: I just uploaded to mgarepo a package that fixes peazip. It runs nicely on my 64-bit machine now, I assume that there isn't a problem in uploading since it's not scheduled for Mageia3 and the package that was there before was broken anyway. Now to take a look at mplayer2. Very nice, great job. I am testing your package and it runs smoothly, except the problem with missing 'pealauncher'. Another problem is when opening an archive from a command line "peazip some.tar.gz", it's not working.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release hydra-7.4.2-1.mga3
On 28 January 2013 15:07, Johnny A. Solbu wrote: > On Monday 28. January 2013 14.55, Sander Lepik wrote: >> think that's not the first package from you that breaks the version >> freeze w/o any notice or request on dev-ml. I know you were given the >> permissions to do so, but does that mean you don't have to explain >> anything? > > As I understand it, those of us who don't have submission rights during > version freeze have to explain to those who do have permission rights, why > they should to push a new version. > I don't see the point in guillomovitch explaining to guillomovitch why > guillomovitch should push guillomovitch's packages. :-)= > > Let's not create more bureaucracy for the sake of bureaucracy. > > -- > Johnny A. Solbu > PGP key ID: 0xFA687324 I'm with Colin, its good to be aware of what is going through, writing the mail takes seconds as you must already know why you are breaking the freeze with the package so putting the reasons down is simple.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release hydra-7.4.2-1.mga3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 28.01.2013 17:07, Johnny A. Solbu kirjutas: > On Monday 28. January 2013 14.55, Sander Lepik wrote: >> think that's not the first package from you that breaks the >> version freeze w/o any notice or request on dev-ml. I know you >> were given the permissions to do so, but does that mean you don't >> have to explain anything? > > As I understand it, those of us who don't have submission rights > during version freeze have to explain to those who do have > permission rights, why they should to push a new version. I don't > see the point in guillomovitch explaining to guillomovitch why > guillomovitch should push guillomovitch's packages. :-)= > > Let's not create more bureaucracy for the sake of bureaucracy. > Last time (during mga2 freeze) people with submission rights asked from others with the same rights like everyone else. At least the line in changelog could be a bit longer than just "new version". - -- Sander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRBpY7AAoJECMkkFJIyHr8UywIAJfTBNE6pNADYMG9I+FvYU84 BdKzJHuvlSIVSYwQW/ZDFs3jUv456+y5mwl9DhhW2onJvmeFGULHkubo54eSgoI1 8IAW2u0YXQTs9oGRwdbj/CXq3CYVmbRt3QXYleMWyzvy3Iuj+oiJn6X/RotQHQ73 2bYBSH7iVFOFZIBwd3Pndga/Ttn7vpGW0XsOqC5PmGPYtrYS99Y/Dg4Ph/D/hiTj rR4VICs2AVkhW7hMc//JhXfBoc38gxuZjm+ZnL5ZtWjYDT09tEQCTa7qgv28EA7c G/12zmf3HpUhn7aSyRNcrRUpXk01Ey+Lx05qk/eQ6aMlCvbgmAsFdD2j8raabkw= =1nYc -END PGP SIGNATURE-
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release hydra-7.4.2-1.mga3
On Monday 28. January 2013 14.55, Sander Lepik wrote: > think that's not the first package from you that breaks the version > freeze w/o any notice or request on dev-ml. I know you were given the > permissions to do so, but does that mean you don't have to explain > anything? As I understand it, those of us who don't have submission rights during version freeze have to explain to those who do have permission rights, why they should to push a new version. I don't see the point in guillomovitch explaining to guillomovitch why guillomovitch should push guillomovitch's packages. :-)= Let's not create more bureaucracy for the sake of bureaucracy. -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release hydra-7.4.2-1.mga3
'Twas brillig, and Guillaume Rousse at 28/01/13 14:30 did gyre and gimble: > Le 28/01/2013 14:55, Sander Lepik a écrit : >> I think that's not the first package from you that breaks the version >> freeze w/o any notice or request on dev-ml. I know you were given the >> permissions to do so, but does that mean you don't have to explain >> anything? > Is there any interest explaining they are bugfix release, and that I > checked before submission ? Yes please. IIRC last cycle even those with freeze busting powers still posted Freeze Push request mails for the purposes of peer review etc. (small exceptions for certain tasks (e.g. my LSB'ification of initscripts etc.) which were somewhat late in the cycle were made of course, but for the general course of things I think it's probably a good practice generally, even if somewhat frustrating - still it keeps everyone who can bust freeze on their toes at least :D) 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] [changelog] [RPM] cauldron core/release hydra-7.4.2-1.mga3
Le 28/01/2013 14:55, Sander Lepik a écrit : I think that's not the first package from you that breaks the version freeze w/o any notice or request on dev-ml. I know you were given the permissions to do so, but does that mean you don't have to explain anything? Is there any interest explaining they are bugfix release, and that I checked before submission ? -- BOFH excuse #209: Only people with names beginning with 'A' are getting mail this week (a la Microsoft)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release hydra-7.4.2-1.mga3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 28.01.2013 15:43, guillomovitch kirjutas: > Name: hydraRelocations: (not > relocatable) Version : 7.4.2 > Vendor: Mageia.Org Release : 1.mga3 > Build Date: Mon Jan 28 14:42:18 2013 Install Date: (not installed) > Build Host: jonund.mageia.org Group : Security > Source RPM: (none) Size: 669125 > License: GPLv3 Signature : (none) Packager: guillomovitch > URL : http://www.thc.org/thc-hydra/ Summary > : Network logon cracker Description : A very fast network logon > cracker which support many different services. > > guillomovitch 7.4.2-1.mga3: + Revision: 392917 - > new version > I think that's not the first package from you that breaks the version freeze w/o any notice or request on dev-ml. I know you were given the permissions to do so, but does that mean you don't have to explain anything? (just curious..) - -- Sander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRBoM4AAoJECMkkFJIyHr8+iwH/Roeuz9IerVnUmOHH12x9OBP bkeA1dTo9MBL0NjsptdXZNgO7aECqndbyQuNTrTcF7wUrtqJaMDqTJw+B+V+QTVL eKlR5B8AX3lTwWXuI5dZTYXX5esY0PxT4LKAlLdeykmoPvVb+ovXQJJgmNBCz5Fs 0cr2oqHkEtSCnhafZ5633CzqDcm+T6wl8UIBLlVVDebBmnt+dV8nGFRkq8ag+KWV KcNI4COqHCux+6XTujzp9dWkhY3CMS3G9UwK6a0TQsqHwBK/EzH7f/493GeiY/7v rZVwDKjdERDPMGBmi7f1FZg7Vy1ROAg6tAFVwvkIvhooDoaGfm2MMggmP1CjfhM= =TcHm -END PGP SIGNATURE-
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
On Mon, Jan 28, 2013 at 11:37 AM, Jose Jorge wrote: > Le 28/01/2013 09:53, Guillaume Rousse a écrit : > >> No, that's false. You have to remove obsoletes package from mirrors, >> there is no obligation to remove it from end user machines. >> > > And isn't the purpose of task-obsoletes to remove from mirrors? No, it is to remove from users machine when the packages will not work/break other things/have security problems/... and there is no replacement > The same discussion happened here when proprietary java was removed from the > distro, let's not start it again...
Re: [Mageia-dev] Freeze push: fetchyahoo-2.14.9
Le 28/01/2013 09:59, Sandro CAZZANIGA a écrit : > Le 27/01/2013 22:40, Sandro CAZZANIGA a écrit : >> Hi, >> >> Can someone push fetchyahoo? It fixes #8374: >> https://bugs.mageia.org/show_bug.cgi?id=8374 >> >> Thanks :) >> > > ping? > > thanks :) > ping #2 ? signature.asc Description: OpenPGP digital signature
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
Le 28/01/2013 09:53, Guillaume Rousse a écrit : No, that's false. You have to remove obsoletes package from mirrors, there is no obligation to remove it from end user machines. And isn't the purpose of task-obsoletes to remove from mirrors? The same discussion happened here when proprietary java was removed from the distro, let's not start it again...
Re: [Mageia-dev] bumblebee in mageia (and mentoring)
Al 15/04/12 07:08, En/na simple w8 ha escrit: >> I have revised the specs and here they are attached. >> >> Is anyone available that could help me in the mentoring proccess? > > Well seams that last bumblebee spec missed the scriplets to handle > systemd services. I've been given a laptop with optimus technology. I took the following SRPMS and rebuilt them for mageia 2: bumblebee-3.0-11.mga3.src.rpm dkms-acpi_call-0.1-2.mga3.src.rpm dkms-bbswitch-0.4.2-1.mga3.src.rpm libbsd-0.4.1-1.mga3.src.rpm virtualgl-2.3.1-1.mga3.src.rpm I have two issues (just FYI): 1) the [driver-nvidia] section in the configuration file should have a line KernelDriver=nvidia-current otherwise bumbleebed couldn't load the module and wouldn't start 2) running glxspheres with optirun, not only takes 5 seconds to start, but is slower than with the integrated graphics card (60 frames/sec. without optirun vs. 40 frames/sec. with optirun). I see they mention it in the FAQ, so this isn't probably an issue with the packages. I'm using the 310.32 nvidia driver built with the script by Anssi Hannula http://onse.fi/nvidia-mgabuild/ Bye -- Luca
Re: [Mageia-dev] freeze push: libroffice
Le 28/01/2013 07:58, Nicolas Lécureuil a écrit : Le lundi 28 janvier 2013 00:40:53 Liam R E Quin a écrit : On Mon, 2013-01-28 at 06:37 +0100, Thierry Vignaud wrote: Hi Please let in freeze push: libroffice-4.0.0.2 This is RC2, we have RC1. When to stop? It's not a difference here between a release candidate and a release... i don't understand what you mean. I don't think we should release a rc release in mga3 either. It does not mean we will have RC2 in final release. It will allow us to test new version that comes with modifications, see if there is no regression. Then when final release is out, the update gap is smaller and probability for a regression is smaller also. -- Anne http://mageia.org
Re: [Mageia-dev] Packagers meeting
Le 28/01/2013 10:38, Anne Nicolas a écrit : > Hi there > > We will have our weekly meeting tomorrow, 20h UTC: > > - quick beta 2 review > - release critical bugs review (this one should take most of our time) > > As usual feel free to propose a topic. QA and bug triage team, could you > please be around? > > Cheers > Thanks Anne, I'll be there. I hope Claire too ;) signature.asc Description: OpenPGP digital signature
[Mageia-dev] Packagers meeting
Hi there We will have our weekly meeting tomorrow, 20h UTC: - quick beta 2 review - release critical bugs review (this one should take most of our time) As usual feel free to propose a topic. QA and bug triage team, could you please be around? Cheers -- Anne http://mageia.org
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3
On Sun, 27 Jan 2013, AL13N wrote: hd44780_LDADD = libLCD.a @HD44780_DRIVERS@ @LIBUSB_LIBS@ @LIBFTDI_LIBS@ libbignum.a hd44780_DEPENDENCIES = @HD44780_DRIVERS@ so, i should move it to dependencies instead of ldadd in the Makefile.am and use autoreconf -i instead... Try to change hd44780_DEPENDENCIES there to EXTRA_hd44780_DEPENDENCIES . Library deps are automatic of course but defining foo_DEPENDENCIES overrides the automatic deps generated by automake. but... this isn't the only driver, does this mean i'll have to change dependencies for almost all these drivers? Christiaan
Re: [Mageia-dev] Freeze Push: bootsplash
'Twas brillig, and David Walser at 27/01/13 23:51 did gyre and gimble: > Colin Guthrie wrote: >> 'Twas brillig, and David Walser at 27/01/13 20:26 did gyre and gimble: >>> Colin Guthrie wrote: This is one of our packages thus semi-exempt from freeze rules. But either way it fixes a potential security issue. >>> >>> Care to elaborate? Mageia 2 also has 3.3.9. >> >> I already sent a mail to security@ (as per >> https://wiki.mageia.org/en/Packagers_Security_Team) to discuss it >> initially. I've updated the mga2 package in preparation already, but >> just wanted to discuss the process (i.e. order of certain actions) first. > > Does anyone get the mails sent to that list? I presumed it was the whole team... That said if no-one gets them, it's a *very* secure list ;) 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] Freeze push: fetchyahoo-2.14.9
Le 27/01/2013 22:40, Sandro CAZZANIGA a écrit : > Hi, > > Can someone push fetchyahoo? It fixes #8374: > https://bugs.mageia.org/show_bug.cgi?id=8374 > > Thanks :) > ping? thanks :) signature.asc Description: OpenPGP digital signature
Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3
Le 28/01/2013 08:05, Jose Jorge a écrit : Le 28/01/2013 00:53, David Walser a écrit : zezinho wrote: Name: task-obsoleteRelocations: (not relocatable) Version : 3 Vendor: Mageia.Org Release : 56.mga3 Build Date: Sun Jan 27 12:28:18 2013 zezinho 3-56.mga3: + Revision: 392711 - zsnes removed Why!?? I don't want this removed from my system! AFAIK, our policy is to obsolete any package that is no more in the distro. You can still install the MGA2 rpm if you remove task-obsolete... No, that's false. You have to remove obsoletes package from mirrors, there is no obligation to remove it from end user machines. -- BOFH excuse #259: Someone's tie is caught in the printer, and if anything else gets printed, he'll be in it too.
