Re: [Mageia-dev] Beta Install failure with Intel Atom 330 Nvidia Ion

[James Kerr]

On 28/04/2012 11:21, Mika Laitio wrote:

Just tried to boot (and also install) the
Mageia-2-beta3-LiveCD-GNOME-Europe2-i586-CD.iso
on Zotac Atom 330 NVIDIA Ion system and it didn't really work out.

Install starts up just fine and it shows up the Mageia splash screen
with 2 balls on top of it.

Then it goes to black console and shows text
"need to reboot in 30 seconds due to graphics change".

If accepting that and trying again, it will show up the same error
message again. Is this a known problem or should I fill a new bug?



https://wiki.mageia.org/en/Mageia_2_Errata#LiveCD_and_Nvidia_card

Jim

Re: [Mageia-dev] Question about update media and GUI

[James Kerr]

On 21/05/2012 09:35, Colin Guthrie wrote:

Hi,

Random question...  I've only just noticed that mgaapplet/rpmdrake
started telling me that I had no media... is this just because we've
"flipped a switch" telling it to only update media marked as update
while 99% of the cauldron cycle it would update all media?

I've not actually used the GUI tools until this cycle (in previous years
I always ran --auto-update manually) in order to try and actually use
them and make sure they work etc, hence why I'm perhaps a little more
ignorant than I should be :D



On stable releases mgaapplet checks only media marked as update media. 
On cauldron it checks release media, whether or not they are marked as 
update media. Since the release has been updated to Mageia 2, you are 
now running a stable release. When cauldron is re-opened and the release 
is changed back to cauldron, it should start checking the release media 
again.


I'm not certain if on cauldron it checks all enabled media (i.e. 
including testing media) or just the release media. I enable only the 
release media on cauldron.


Jim

Re: [Mageia-dev] Cauldron?

[James Kerr]

On 24/05/2012 18:44, David wrote:

Is it safe to update Cauldron?


Yes it is safe to update cauldron.

I ask because the package

mageia-release-common-2-3.mga2.x86_64.rpm that urpmi wants to install
from the /Cauldron directory says that this is "Mageia release 2
(Official) for x86_64"

Or should I just add  mageia-release-common and mageia-release-Default
to the skip.list file for now?




That is not necessary. When cauldron is re-opened that package will be 
updated to refer to cauldron. (Provided you keep cauldron sources.)


Jim

Re: [Mageia-dev] [soft-commits] [5019] drop duplicated Mageia wording

[James Kerr]

On 27/07/2012 21:26, Olivier Blin wrote:

Thierry Vignaud  writes:


On 25 June 2012 09:25,   wrote:

Revision 5019 Author fwang Date 2012-06-25 09:25:45 +0200 (Mon, 25 Jun 2012)

Log Message

drop duplicated Mageia wording


This break translations.
Please fix translations w/o fuzzying them.
Else would replace the 2nd "Mga" by "Mga linux".


I don't think that the distribution should be referred as "Mageia
Linux", it's just "Mageia".
Better drop the 2nd wording, as already done.


Modified: drakx/trunk/perl-install/messages.pm
===
-\"Mageia\", \"Mageia\" and associated logos are trademarks of Mageia
+\"Mageia\" and associated logos are trademarks of Mageia




Should that not read "are trademarks of Mageia.Org"?

Mageia is the distro, but I think that Mageia.Org is the legal entity, 
which owns the trademarks.


Jim

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release draklive-2.1-1.mga3

[James Kerr]

On 28/09/2012 10:36, tmb wrote:

Name: draklive Relocations: (not relocatable)
Version : 2.1   Vendor: Mageia.Org
Release : 1.mga3Build Date: Fri Sep 28 11:36:11 2012
Install Date: (not installed)   Build Host: ecosse.mageia.org
Group   : System/Configuration/OtherSource RPM: (none)
Size: 49252License: GPLv2+
Signature   : (none)
Packager: tmb 
URL : http://wiki.mandriva.com/Development/Packaging/Tools/draklive
Summary : Live systems generation and copying tool
Description :
This tool lets you generate Mageia live systems.


The URL no longer exists. The mdv wiki page, which has not been updated 
since the fork, is http://wiki.mandriva.com/en/Draklive


and that page has been imported to the mga wiki
https://wiki.mageia.org/en/Draklive

Jim

Re: [Mageia-dev] rehashing the faac issue

[James Kerr]

On 02/10/2012 12:26, Frank Griffin wrote:


At least for my part, I always viewed tainted as being the equivalent of
PLF,


PLF had both free and non-free repo's.

If you include both free and non-free in tainted, which is probably the 
"least bad" solution, then there needs to be a way for FOSS enthusiasts 
(who choose to do so) to avoid the non-free packages - perhaps a 
statement in the package description would suffice.


Jim

Re: [Mageia-dev] rehashing the faac issue

[James Kerr]

On 02/10/2012 13:58, Wolfgang Bornath wrote:

2012/10/2 James Kerr :

On 02/10/2012 12:26, Frank Griffin wrote:


At least for my part, I always viewed tainted as being the equivalent of
PLF,



PLF had both free and non-free repo's.

If you include both free and non-free in tainted, which is probably the
"least bad" solution, then there needs to be a way for FOSS enthusiasts (who
choose to do so) to avoid the non-free packages - perhaps a statement in the
package description would suffice.


Well, are you saying that tainted includes free packages although they
are subject to a patent?


Yes. Those are the only packages that are included at present in 
tainted. The fact that a package includes software that may be 
encumbered by patent claims does not make it non-free.


Jim

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release drakx-installer-stage2-14.46.2-1.mga3

[James Kerr]

On 03/10/2012 12:58, tv wrote:

Name: drakx-installer-stage2   Relocations: (not relocatable)
Version : 14.46.2   Vendor: Mageia.Org
Release : 1.mga3Build Date: Wed Oct  3 13:54:37 2012
Install Date: (not installed)   Build Host: jonund.mageia.org
Group   : Development/Other Source RPM: (none)
Size: 4455908  License: GPLv2+
Signature   : (none)
Packager: tv 
URL : http://wiki.mandriva.com/Tools/DrakX
Summary : DrakX installer stage2 image
Description :
This is the stage2 image for Mageia DrakX installer.



The quoted URL no longer exists. The nearest appropriate mdv page seems 
to be:

http://wiki.mandriva.com/en/Development/Howto/MDK_Installer

That page has been imported to the mga wiki as:
https://wiki.mageia.org/en/Drakx-installer_tips_and_tricks

Jim

Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3

[James Kerr]

On 20/01/2013 13:30, Maurice Batey wrote:

On Sun, 20 Jan 2013 13:08:57 +, Barry Jackson wrote:


Installing the grub2 package will not impact your current bootloader in
any way.


   Installing GRUB2 where, Barry?
(MBR or  Root partition?)

If - as I did with Ubuntu 12.01 - GRUB2 goes into the MBR, then I can
no longer boot from its menu into a GRUB Legacy install, a I said
earlier (despite the GRUB2 boot menu purporting to do so).



On a recent install of Beta1, I chose Grub2 and selected to put the 
boot-loader in the MBR of the boot disk, replacing the legacy grub 
boot-loader of Mageia2. Grub2 created a boot menu that enables me to 
successfully boot the pre-existing Mageia2 installation.


Jim

Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3

[James Kerr]

On 30/01/2013 11:54, Maurice Batey wrote:

On Sun, 20 Jan 2013 14:39:26 +, James Kerr wrote:


Grub2 created a boot menu that enables me to
successfully boot the pre-existing Mageia2 installation.


James, does the Mageia2 installation have GRUB-Legacy in the PBR?


No. Mageia 2's Grub boot-loader was installed to the MBR of the boot disk.



What is the GRUB2 boot stanza that boots Mageia2?


This is the stanza in /boot/grub2/grub.cfg for Mageia 2:


menuentry 'linux (on /dev/sdb1)' --class gnu-linux --class gnu --class 
os $menuentry_id_option 
'osprober-gnulinux-/boot/vmlinuz--20599988-d027-4cd2-80c4-b834e1013a80' {

insmod part_msdos
insmod ext2
set root='hd1,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos1 
--hint-efi=hd1,msdos1 --hint-baremetal=ahci1,msdos1 
20599988-d027-4cd2-80c4-b834e1013a80

else
		  search --no-floppy --fs-uuid --set=root 
20599988-d027-4cd2-80c4-b834e1013a80

fi
		linux /boot/vmlinuz BOOT_IMAGE=linux root=LABEL=mga-root splash quiet 
nokmsboot resume=UUID=a3dabcb9-c43e-4035-8bbe-576aa9c5573b vga=788

initrd /boot/initrd.img


I've attached grub.cfg, in case it's of some help.

os-prober creates a boot menu which lists the first entry from Grub's 
menu.lst on the top-level Grub2 boot menu, even when the first entry in 
menu.lst is not the default. As a result, in order to reach the menu 
entry for Mageia 2, I have to access the second level "Advanced options" 
menu.


On this system /dev/sdb is the boot disk.

Jim



#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  load_env
fi
set default="0"

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if loadfont unicode ; then
  set gfxmode=1024x768x32
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_GB
  insmod gettext
fi
terminal_output gfxterm
insmod part_msdos
insmod ext2
set root='hd1,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos8 
--hint-efi=hd1,msdos8 --hint-baremetal=ahci1,msdos8  
f64c1cea-d7d7-44f6-8c3f-90d4dc886511
else
  search --no-floppy --fs-uuid --set=root f64c1cea-d7d7-44f6-8c3f-90d4dc886511
fi
insmod gfxmenu
insmod png
set theme=($root)/boot/grub2/themes/maggy/theme.txt
export theme
set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Mageia GNU/Linux' --class mageia --class gnu-linux --class gnu 
--class os $menuentry_id_option 
'gnulinux-simple-f64c1cea-d7d7-44f6-8c3f-90d4dc886511' {
set gfxpayload=text
insmod gzio
insmod part_msdos
insmod ext2
set root='hd1,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos8 
--hint-efi=hd1,msdos8 --hint-baremetal=ahci1,msdos8  
f64c1cea-d7d7-44f6-8c3f-90d4dc886511
else
  search --no-floppy --fs-uuid --set=root 
f64c1cea-d7d7-44f6-8c3f-90d4dc886511
fi
echo'Loading Linux desktop ...'
linux   /boot/vmlinuz-desktop 
root=UUID=f64c1cea-d7d7-44f6-8c3f-90d4dc886511 ro  splash
echo'Loading initial ramdisk ...'
initrd  /boot/initrd-desktop.img
}
submenu 'Advanced options for Mageia GNU/Linux' $menuentry_id_option 
'gnulinux-advanced-f64c1cea-d7d7-44f6-8c3f-90d4dc886511' {
menuentry 'Mageia GNU/Linux, with Linux desktop' --class mageia --class 
gnu-linux --class gnu --class os $menuentry_id_option 
'gnulinux-desktop-advanced-f64c1cea-d7d7-44f6-8c3f-90d4dc886511' {
set gfxpayload=text
insmod gzio
insmod part_msdos
insmod ext2
set root='hd1,msdos8'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --

Re: [Mageia-dev] Grub2 vs. Grub Legacy in M3

[James Kerr]

On 31/01/2013 16:19, Maurice Batey wrote:

On Wed, 30 Jan 2013 17:22:43 +, James Kerr wrote:


Mageia 2's Grub boot-loader was installed to the MBR of the boot disk.


   But earlier  you said:

   "On a recent install of Beta1, I chose Grub2 and selected to put
the  boot-loader in the MBR of the boot disk..."

Then: "Grub2 created a boot menu that enables me to
 successfully boot the pre-existing Mageia2 installation."

My question was about the pre-existing Mageia2 installation, and asked:
Does that have GRUB installed in its PBR?

(I ask because others have opined that GRUB2 cannot boot a GRUB Legacy
install unlessthat install has GRUB installed in its PBR.)



I did answer your question:

"MB  --   does the Mageia2 installation have GRUB-Legacy in the PBR?

 JK  --   No. Mageia 2's Grub boot-loader was installed to the MBR of
  the boot disk."

When I wrote "No", I meant "No" :)

To be absolutely clear, I have never placed any boot-loader in any PBR 
on this system.


Jim

[Mageia-dev] Multiple builds on mirrors

[James Kerr]

A couple of issues that I've not seen mentioned elsewhere:

1. There are multiple builds of some packages on the mirrors.  For example:

drakconf-12.21-1
drakconf-12.21-2
drakconf-12.21-3

2. In /core/release/media_info there is an ever-increasing number of 
symlinks to the meta-data files (hdlist.cz etc.)


(These apply to distrib-coffee and mandrivauser.de, but ibiblio seems 
not to  be fully sync'd. I haven't checked the others.)


Are these known issues or should I open bug reports?

Jim

Re: [Mageia-dev] Bugs list test?

[James Kerr]

On 16/02/11 21:37, bugzilla-dae...@mageia.org wrote:

test



I assume that this was a test of the bugs list. It seems to have worked. :)

Jim

Re: [Mageia-dev] About panotools patent problem (and other problematic rpms)

[James Kerr]

On 18/02/11 12:07, Michael Scherer wrote:

Le vendredi 18 février 2011 à 12:43 +0100, Oliver Burger a écrit :

Philippe DIDIER  schrieb am 2011-02-18

And what I talked about (in the other thread with the same name)
was about the easiness to build and use different rpms with the
same spec having mdv versus plf suffixes...
And about it seems that we need to have different naming for Mageia
(whether it's a "normal" or tainted rpm)

I still don't see a reason for this. We devide those packages by the
repo they get in, why do another thing?



From a build system point f view, this is easier to indeed treat that

like non-free, because there is no modification to do.

A better solution would indeed be to allow to have a tainted rpm in code
and tained, the core version being "cleaned" from litigious parts.

let's take a exemple, let's imagine someone has a patent on a fictional
video codec let's call it MCVC ( MegaCompressionVideoCodec ), and a army
of cloned lawyers from Hell that enforce the patent in USA.

Let's assume that Mplayer, as it support almost everything, support MCVC
in the current version.

First solution : we move mplayer rpm to tainted, with support for MCVC.

Second solution : we compile mplayer in core without support for MCVC

Third solution : we compile mplayer 2 times, once in tainted with MCVC,
another one to core without.


The first solution force us to place everything that requires mplayer to
tainted, as core must be self contained. So that mean various frontends,
firefox plugin, etc. This could be problematic if we place some
libraries in tainted. ( like freetype ).

The second solution may slightly annoy people with lots of holidays
movies encoded in MCVC. And would render tainted basically useless.

The third solution is the one we use for PLF, but suffer from a few
technical issues :
- I am not sure the current system support it. In mdv, the 2 uploads
system are fully separated. Not here.

- We need to make sure that the binaries and source rpms are kept in
sync. If I upload a new version of mplayer, it will erase the source rpm
and use the new one. So if I built the tainted one, the srpm that was
used for the core rpm is no longer here.

- we need to make sure that the binaries rpms are in sync. If we upload
the core one, it would be nice to wait for the tainted one to be
uploaded too. Ie keep them in sync like we keep x86_64/i586 in sync.
But, only if the package is dual lived ( ie, there is rpms that will be
distributed only in tainted ).

That's a rather non trivial problem to solve.

And hopefully, we only have core and tainted ( ie, while non-free could
be added to the mix, there is no dual life issue with it ).



If there are two packages, one in core and another in tainted, then 
doesn't urpmi need a way to recognise that the tainted package is newer 
than (an update to) the corresponding core package? I believe that this 
is achieved in Mandriva, because plf is greater than mdv.


Jim

Re: [Mageia-dev] Bugs mailing list, new bugs Subject line

[James Kerr]

On 01/03/11 18:52, Ahmad Samir wrote:

At the moment when a new bug report is filed bugzilla adds the string
"New:" to the subject line of the email, this is removed in subsequent
emails (once the bug is not new any more, i.e. more comments were
added... etc).

This is a sort of an unofficial poll about how many people out there
find this useful (or not).



I hadn't noticed that :)

It's immediately apparent on reading the email, whether or not it's a 
new bug, but if that string is useful to some people, then I don't have 
any problem with it.


Jim

Re: [Mageia-dev] dual iso content

[James Kerr]

On 04/04/11 10:49, Donald Stewart wrote:

On 4 April 2011 10:35, Anne nicolas  wrote:

Hi there

While working on beta1 isos, looks like recent improvement in deps
management for base system made some more free space. I know have 30
Mo available to add more packages. Just keep in mind that dual content
is both 32 and 64 bits and focus on minimal installation and
diagnostic tools

Here is the current list:
http://zarb.org/~ennael/mageia-dual-1-Beta1-dual.idx

Feel free to comment
Cheers

--
Anne
http://www.mageia.org



mc would be nice. Otherwise the list looks good.



I agree. nano would also be useful. (At least one of those two should be 
included.) A few of us still haven't mastered vi.  :)


Jim

[Mageia-dev] Bugzilla

[James Kerr]

When marking a bug as a duplicate, bugzilla insists that a comment be 
added. This seems redundant since bugzilla itself adds an explanatory 
comment automatically.


Is it possible to make an exception in this case, to the requirement to 
add a comment when changing the status of a bug?


Jim

Re: [Mageia-dev] 3G usb pen

[James Kerr]

On 09/05/11 10:28, Stefano Negro wrote:

Hi
I am trying to install my 3G usb pen modem.
It is recognized :

usb 5-3: new high speed USB device using ehci_hcd and address 5
usb 5-3: New USB device found, idVendor=19d2, idProduct=2000
usb 5-3: New USB device strings: Mfr=2, Product=1, SerialNumber=3
usb 5-3: Product: ZTE CDMA Technologies MSM
usb 5-3: Manufacturer: ZTE,Incorporated
usb 5-3: SerialNumber: 3AUP673A4CDROMMS
scsi5 : usb-storage 5-3:1.0
scsi 5:0:0:0: CD-ROMZTE  USB SCSI CD-ROM  2.31 PQ: 0 ANSI: 2
sr0: scsi-1 drive
sr 5:0:0:0: Attached scsi CD-ROM sr0
sr 5:0:0:0: Attached scsi generic sg1 type 5

Under mcc it's not recognized, no 3g modem found.
Is there any workaround to get configured?



"Eject" the CDROM device (for example in dolphin or nautilus places 
panel). It should then be recognised as a modem. (This has worked for me 
and for others.)


Jim

Re: [Mageia-dev] [RPM] cauldron core/release java-1.6.0-sun-1.6.0.25-1.mga1

[James Kerr]

On 15/05/11 12:23, Mageia Team wrote:

Name: java-1.6.0-sun   Relocations: (not relocatable)
Version : 1.6.0.25  Vendor: Mageia.Org
Release : 1.mga1Build Date: Sun May 15 13:19:30 2011
Install Date: (not installed)   Build Host: ecosse
Group   : Development/Java  Source RPM: (none)
Size: 170629478License: Operating System 
Distributor License for Java (DLJ)
Signature   : (none)
Packager: Mageia Team
URL : http://java.sun.com/j2se/1.6.0
Summary : Java Runtime Environment for java-1.6.0-sun
Description :
This package contains the Java Runtime Environment for java-1.6.0-sun.



Is this Free software? It was always in nonfree on mdv.

Jim

Re: [Mageia-dev] Discrepancy between /etc/version and /etc/release - which one for MIRRORLIST

[James Kerr]

On 08/06/11 08:42, Oliver Burger wrote:

Hi,

after some discussion in the German forums, I saw, that there are
discrepancies between /etc/version and /etc/release, both coming from
the mageia-release-common-1-2.mga1 package.

While /etc/release calls my system
--
Mageia release 1 (Official) for i586
--

it is called
--
1 2 cauldron
--

by /etc/version.

Which one of those defines the branch used by MIRRORLIST


I thought that /etc/product.id was used.

Jim

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

[James Kerr]

On 10/06/11 13:54, Michael Scherer wrote:

Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :

Thomas Backlund  schrieb am 10.06.2011

So the path would then be */updates_testing ->  */updates _if_ we
decide that's the way to go...

As I see it, it's the only user friendly way. Using backports is fine
for experienced users who do know what to install from backports or
who are capable of facing the consequences.
If a total newbie asks fort a package in the forums and is pointed to
backports he is in great danger of wrecking his system by installing
some new kernel, graphics driver, desktop or whatever, precisely
because there is no real qa on backports.


He can also wait for the release. Or he can enable backport just for the
time needed to install and then disable it. I think rpmdrake have some
stuff for that.



Even though backports are disabled rpmdrake can display a list of 
available backports. (The sources are automatically updated by 
mgaonline.) A selected backport can then be installed, without enabling 
the backports source. (I've just tested this on mdv 2010.0, the only mdv 
system that I have available.)


Jim

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

[James Kerr]

On 10/06/11 15:09, James Kerr wrote:

On 10/06/11 13:54, Michael Scherer wrote:

Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :

Thomas Backlund schrieb am 10.06.2011

So the path would then be */updates_testing -> */updates _if_ we
decide that's the way to go...

As I see it, it's the only user friendly way. Using backports is fine
for experienced users who do know what to install from backports or
who are capable of facing the consequences.
If a total newbie asks fort a package in the forums and is pointed to
backports he is in great danger of wrecking his system by installing
some new kernel, graphics driver, desktop or whatever, precisely
because there is no real qa on backports.


He can also wait for the release. Or he can enable backport just for the
time needed to install and then disable it. I think rpmdrake have some
stuff for that.



Even though backports are disabled rpmdrake can display a list of
available backports. (The sources are automatically updated by
mgaonline.) A selected backport can then be installed, without enabling
the backports source. (I've just tested this on mdv 2010.0, the only mdv
system that I have available.)



I've just realised there is a potential problem with this. Because 
Mageia has /backports_testing repo's (mdv does not) packages from 
/backports_testing may also be displayed. Mgaonline is updating those 
sources.


Jim

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

[James Kerr]

On 10/06/11 15:27, Oliver Burger wrote:

James Kerr  schrieb am 10.06.2011

Even though backports are disabled rpmdrake can display a list of
available backports. (The sources are automatically updated by
mgaonline.)

I make you parden, but: no!

When a repo is disabled it doesn't get updated automatically and its
packages are not to be found in rpmdrake.
Did you confuse "disabling repos" and "marking a repo for updates"
(sorry, me doesn't know the exact English strings).


So you have to enable the backports repos and even though you don't
"mark them as update repos", urpmi will ignore that (rpmdrake won't
but urpmi will) and will update everything from those repos...



I meant exactly what I wrote. Select Backports from the first filter in 
rpmdrake and packages from disabled backports sources will be displayed.


Check /var/log/auth.log to see what mgaonline is doing.

Jim

Re: [Mageia-dev] Missing packages in Mageia 1. How to backport?

[James Kerr]

On 10/06/11 22:44, andre999 wrote:

James Kerr a écrit :


On 10/06/11 15:09, James Kerr wrote:

On 10/06/11 13:54, Michael Scherer wrote:

Le vendredi 10 juin 2011 à 14:21 +0200, Oliver Burger a écrit :

Thomas Backlund schrieb am 10.06.2011

So the path would then be */updates_testing -> */updates _if_ we
decide that's the way to go...

As I see it, it's the only user friendly way. Using backports is fine
for experienced users who do know what to install from backports or
who are capable of facing the consequences.
If a total newbie asks fort a package in the forums and is pointed to
backports he is in great danger of wrecking his system by installing
some new kernel, graphics driver, desktop or whatever, precisely
because there is no real qa on backports.


He can also wait for the release. Or he can enable backport just for
the
time needed to install and then disable it. I think rpmdrake have some
stuff for that.


Even though backports are disabled rpmdrake can display a list of
available backports. (The sources are automatically updated by
mgaonline.) A selected backport can then be installed, without enabling
the backports source. (I've just tested this on mdv 2010.0, the only mdv
system that I have available.)


I've just realised there is a potential problem with this. Because
Mageia has /backports_testing repo's (mdv does not) packages from
/backports_testing may also be displayed. Mgaonline is updating those
sources.

Jim


That was a bug in rpmdrake.
If you had updated the repos with backports media enabled, when the
backports media was subsequently disabled, the previously available
backports packages remained displayed/installable. But new backports
were not added if the repos were updated with backports disabled. There
was the same problem for other media (like non-free).
Otherwise enabling/disabling backports (or any other media) wouldn't
make any sense.



It is not a bug, but intended behaviour. When mdkonline/mgaonline is 
running it updates backports sources each time it checks for updates. As 
I indicated in an earlier email you can see that this is done if you 
check /var/log/auth.log.


The system that I tested on, has never had backports sources enabled and 
I was able to install a recent package from a disabled backports source, 
by selecting it from Backports, displayed using the first filter in 
rpmdrake.


This facility was set up to allow inexperienced users to selectively 
install backports, without enabling the backports sources.


Jim

Re: [Mageia-dev] Question about backports: calibre (bug 1659)

[James Kerr]

On 13/06/11 10:51, Radu-Cristian FOTESCU wrote:



Therefore, I strongly believe that all calibre updates be packaged
into updates, not backports, especially as there isn't any Mageia 2.0
as of yet.



The reference to backporting means backporting from Cauldron.

Jim

Re: [Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2

[James Kerr]

On 13/06/11 13:06, Dick Gevers wrote:

On Mon, 13 Jun 2011 09:37:40 +0200, Cazzaniga Sandro wrote about Re:
[Mageia-dev] [RPM] cauldron core/release biew-6.1.0-1.mga2:


Quite a few packages reached the mirrors since this one, but biew has
not.



So it needs a rebuild?


Anything similar to rebuild, push, boot, shove, %mkrel or opening the window
to let it fly: IANAE.



In case it's relevant - the i586 package is on the mirrors. It's only 
x86-64 that's missing.


Jim

Re: [Mageia-dev] [RPM] cauldron core/release drakx-installer-binaries-1.50-3.mga2

[James Kerr]

On 19/06/11 18:43, Mageia Team wrote:

Name: drakx-installer-binaries Relocations: (not relocatable)
Version : 1.50  Vendor: Mageia.Org
Release : 3.mga2Build Date: Sun Jun 19 19:40:17 2011
Install Date: (not installed)   Build Host: jonund
Group   : Development/Other Source RPM: (none)
Size: 914415   License: GPL
Signature   : (none)
Packager: Mageia Team
URL : http://wiki.mandriva.com/Tools/DrakX
Summary : DrakX binaries
Description :
binaries needed to build Mandriva installer (DrakX)



Are the Mandriva references appropriate?

Jim

Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?

[James Kerr]

On 06/07/11 12:58, Romain d'Alverny wrote:

On Wed, Jul 6, 2011 at 12:10, Wolfgang Bornath  wrote:

If we go back to the beginning of the discussion where to put such
packages which were in PLF we made a clear difference:

1. All non-free goes into non-free

2. Software which may be illegal in some countries (mostly because of
licensing) will go into tainted.

That's all. Clear and simple.

The question about GPL or other free licenses is not touched by
tainted. So, everything which does not have to go to tainted will go
to free (core) or non-free, depending on it's status.


Indeed. http://mageia.org/wiki/doku.php?id=licensing_policy#acceptable_licenses
says:

"The tainted section accepts software under a license that is might be
free or open source and which cannot be redistributed publicly in
certain areas in the world, or due to patents issues."

Reformulating it in an other, more explicit way maybe:
  - "core" hosts 100% free software that can be redistributed anywhere
(or almost, the world is a bit more complicated than that)
  - "nonfree" hosts non-free software that can be redistributed anywhere (same)




  - "tainted" hosts all the rest, be it free software or not.



I don't think that the last line is entirely consistent with what I 
understood was Mageia's commitment to provide a free distro for those 
users who want it. Such a user would have to investigate whether or not 
a tainted package was free or nonfree, or not use the tainted repo at all.


Jim

Re: [Mageia-dev] Summary of the release cycle decision

[James Kerr]

On 07/07/11 06:07, Remco Rijnders wrote:

On Wed, Jul 06, 2011 at 07:47:49PM -0400, David W. Hodgins wrote:

On Wed, 06 Jul 2011 08:44:07 -0400, Michael scherer 
wrote:


Since we took one month for various things ( such as discussing
everything ), we propose
the next release to be on 4th april, and start the cycle today. This
is in the middle
of the week on purpose, to avoid the weekend.


Wasn't there a request some time ago to consider releasing just before
the end of a month
so people with monthly limits could choose to use up their current
month's limit, or wait,
depending on how close they were to the limit?


I don't recall seeing such a discussion... but I think we are now
drifting too far off... I think the number of persons for which this is
an issue is really limited and any date that we pick will be somewhat
arbitrarily.



https://bugs.mageia.org/show_bug.cgi?id=984

I believe that monthly download quotas are quite common in some 
countries, although the "month" to which the quota applies is not always 
a calendar month. My quota, for example, is re-set on my billing date, 
which is not the first day of the month.


I have no idea how many people have quotas that renew on the first of 
the month.


Jim

Re: [Mageia-dev] Repository question: where do we put non-free+tainted RPMs?

[James Kerr]

This thread has strayed far from the original question, which could be 
re-stated as:


Should tainted free software and tainted nonfree software be commingled 
in a single tainted repository?


Given Mageia's commitment to the promotion of free software, I believe 
that they should not. If Mageia wishes to distribute tainted nonfeee 
software, then that should be done through an additional separate 
tainted-nonfree repository.


Jim