Re: [Mageia-dev] what's the purpose of this list ?

[AL13N]

> On Wed, Apr 3, 2013 at 10:32 AM, nicolas vigier 
> wrote:
>> On Wed, 03 Apr 2013, Guillaume Rousse wrote:
>>
>>> Le 03/04/2013 07:59, Oliver Burger a écrit :
 2013/4/2 Guillaume Rousse >>> >
  > Since a few days, I'm getting mail through this list. But given
 their
 content, I don't any added value to keep it separated from the main
 mageia-dev one...

 It's not a list, it's the contact address for packagers team listed
 here: https://www.mageia.org/en/contact/
>>> Let's rephrase my question then: what the point of a public contact
>>> address
>>> for packagers team ? Who is supposed to send what ?
>>
>> In most cases people should only use the mailing lists.
>>
>> They probably use it instead of the mailing list because it is easier to
>> find it on the contact page linked from the menu. And they don't read
>> the text saying that they should use the mailing list.
>>
>> So I think those addresses should be removed from the contact page, or
>> at least the mailing lists should be easier to find.
>>
>
> Maybe this contact address can be forwarded to the mailing list, or
> does it require people to be subscribed?
>

what about an automated reply saying that you should subscribe to ml for
packagers team?

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libvirt-1.0.2-4.mga3

[AL13N]

Op maandag 1 april 2013 08:38:43 schreef Mustafa Muhammad:
> On Mar 31, 2013 10:19 PM, "AL13N"  wrote:
> > Op zondag 31 maart 2013 00:52:08 schreef Thierry Vignaud:
> > > On 31 March 2013 00:48, Thierry Vignaud 
> 
> wrote:
> > > > On 8 March 2013 07:54, AL13N  wrote:
> > > >>> Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor
> > > >>> ioctl 3166208: Permission non accordée
> > > > 
> > > > I applied a patch from FC that fixed the ioctl errors
> > > 
> > > BTW all FC patches seems to have been mergd in libvirt-1.0.3
> > > See http://libvirt.org/news.html for changelog
> > 
> > i have been testing libvirt-1.0.3 locally, due to a bug that kills
> 
> libvirtd
> 
> > when a domain has been shut down... unfortunately, it doesn't fix it...
> 
> i'm
> 
> > trying to follow up with upstream to get this fixed... i hope i make it in
> > time...
> 
> Then I hope you push 1.0.4 as it out today.

is it? or is this an april fools joke?

i'm gonna check it out, since i haven't heard of the libvirt persons who would 
check out my bug...

Re: [Mageia-dev] freeze push: ldetect, drakx-installer-binaries, drakx-installer-stage2, drakx-installer-images

[AL13N]

Op zondag 31 maart 2013 00:36:47 schreef Thierry Vignaud:
> Hi
> 
> Please let in ldetect, drakx-installer-binaries, drakx-installer-stage2 &
> drakx-installer-images.
> They bring support for installing on Xen (PV).
> 
> - ldetect: add support for detecting Xen blk & net controllers (mga#9546)
> 
> Once it's available, please submit:
> - drakx-installer-binaries: probe virtual drivers too (mga#9546)
>   (install from Xen hd not supported yet but fetching installer from HD is
>   not that usefull when virtualized)
> - drakx-installer-stage2: fix detecting Xen hard disks (mga#9546)
> 
> Once drakx-installer-binaries is available, please submit
> drakx-installer-images (both to core/release and to nonfree-release):
> it'll include new stage1 binary in stage1 (boot.iso and all.rdz) so that
> we support installing on Xen.
> 
> Tested on Xen paravirtualising on legacy (no KVM support) HW.
> 
> Thx

that's just awesome work! i'm gonna test this on HVM-PV

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libvirt-1.0.2-4.mga3

[AL13N]

Op zondag 31 maart 2013 00:52:08 schreef Thierry Vignaud:
> On 31 March 2013 00:48, Thierry Vignaud  wrote:
> > On 8 March 2013 07:54, AL13N  wrote:
> >>> Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor
> >>> ioctl 3166208: Permission non accordée
> > 
> > I applied a patch from FC that fixed the ioctl errors
> 
> BTW all FC patches seems to have been mergd in libvirt-1.0.3
> See http://libvirt.org/news.html for changelog

i have been testing libvirt-1.0.3 locally, due to a bug that kills libvirtd 
when a domain has been shut down... unfortunately, it doesn't fix it... i'm 
trying to follow up with upstream to get this fixed... i hope i make it in 
time...

Re: [Mageia-dev] Apache doesn't always like restarting....

[AL13N]

Op woensdag 27 maart 2013 23:12:13 schreef Colin Guthrie:
[...]
> Are you absolutely sure it's not just apache resetting the value when
> you don't set CoreDumpDirectory in your httpd.conf?

for me it was with libvirtd and on x86_64 setting coreLIMIT=infinity, made it a 
soft limit to 0; and hard to unlimited, setting it to a lower value worked for 
me. perhaps it was libvirtd doing this itself... allthough that seems 
farfetched... it seemed more likely that setting max number was somehow broken 
in systemd or below...

> > moreover, the systemd is compiled without coredump functionality, and that
> > seems to have an effect on this and disallows one to configure
> > systemd-coredump (which isn't build nor packaged) for usage with
> > integrated coredumps with the systemd-coredump-ctl executable, (which is
> > packaged).
> 
> This was a deliberate decision at the time. There were not sufficient
> tools to extract coredumps from the journal logs and really the coredump
> support should be separate from the coredump capturing and logging to
> the journal anyway, so it shouldn't affect anything you're doing right
> now (e.g. it shouldn't affect how you setup apache)

ok, but you can package it and not set it to be used...

> The fact that systemd-coredump-ctl is build is IMO a bug, and one that
> could very well be fixed upstream already (probably is) but I didn't
> want to keep the rm in the %install section of the spec lest it was
> accidentally left in there when we turn the feature on (when it's
> generally more useful - i.e. you can store cores in a directory outside
> of the journal etc etc.).

perhaps it wouldn't get left as you would have an additional executable, so 
you'd have to change the file sections anyway...

[...]
> As for the core dump support, I would be happy enough re-enabling it
> again. I'm just not convinced that storing the dumps in the journal is a
> great idea. I mean if you get a constantly crashing service, your logs
> will fill up quickly and be rotated away quickly. I think the cores
> should be stored outside of the journal. I can't remember off hand if
> the patch that implemented this was finally committed or not - I'll have
> a look and check.

i'm not saying it should be set as default, but if you have systemd-coredump-
ctl i think you should also have systemd-coredump ...

and why not provide the service if people want to use it, as long as you don't 
set the /proc thing, it doesn't get used, so...

Re: [Mageia-dev] Packages not rebuilt since Mageia 2

[AL13N]

Op woensdag 27 maart 2013 19:47:12 schreef Guillaume Rousse:
[...]

no offense meant, and the time you spend fixing these are very much 
appreciated, 
but if tests fail, perhaps we should just drop these instead of having them?

Re: [Mageia-dev] Apache doesn't always like restarting....

[AL13N]

Op woensdag 27 maart 2013 15:44:48 schreef Guillaume Rousse:
> Le 27/03/2013 15:09, AL13N a écrit :
> > the other day i tried to get cores, but somehow unlimited meant 0 meant no
> > core at all
> 
> You need to set LimitCORE=infinity in unit file, according to
> systemd.exec man page. And you probably need the adequate sysctl setting
> (kernel.core_pattern) to ensure the core file get dumped into a
> predictible directory.

actually, no, setting LimitCORE=infinity (also our default as shown with 
systemctl show *.service) ends up with the actual limit being 0 as shown by 
prlimit. (this was with help from #systemd people)

moreover, the systemd is compiled without coredump functionality, and that 
seems to have an effect on this and disallows one to configure systemd-coredump 
(which isn't build nor packaged) for usage with integrated coredumps with the 
systemd-coredump-ctl executable, (which is packaged).

@colin, so please, fix these 2 issues (first one looks like a systemd issue; 
while the second one is a packaging issue)

Re: [Mageia-dev] Apache doesn't always like restarting....

[AL13N]

> Hiya,
>
> Not sure if others ever get this but sometimes my apache really doesn't
> like being restarted.
>
> Looking at things when it's in this stuck state it appears to be waiting
> on a mutex:
>
> Process 24205 attached
> futex(0x7fde0090c640, FUTEX_WAIT_PRIVATE, 2, NULL 
>
> Eventually systemd gets tired waiting and kills it properly
> +++ killed by SIGKILL +++
>
> which is nice from a  cleanliness perspective - I'm pretty sure that
> before either sysvinit would have just hung or returned from the stop
> job without killing things properly and then started apache again and
> gotten then "failed to bind to port 80" type error I'm sure I remember
> seeing.
>
> Anyway, don't think this is something we can easily fix just now and
> it's quite sporadic (doesn't always happen).
>
> One of these days I'll be able to attach to it properly and get a nice
> backtrace :)

this reminds me... you should try to fix the dumping of core via systemd.

the other day i tried to get cores, but somehow unlimited meant 0 meant no
core at all

#systemd people told me that my distro's systemd isn't built with the
coredump option, which may refuse to dump cores in services.

Re: [Mageia-dev] mageia 3 beta 4 installer infinitely slow?

[AL13N]

Op woensdag 27 maart 2013 08:10:18 schreef Eatdirt:
> Hi,
> just tested a boot.iso with network upgrade from mga2->mga3.
> 
> That's completely unusable even on a 10Mb connection. It announces more
> than 10h of upgrade even by selecting the minimal number of media (core
> release only).
> 
> Playing with the CTRL+ALT+Fx, the packages are downloaded fast (up to
> 10Mb/s) but the installer looses *a lot* of time doing this:
> 
> "workaround bug in rpmlib by removing /var/lib/rpm/__db*"
> 
> is that pb fixed already or shall I open a bug report?
> 
> Cheers,
> chris,

better to have a bug and mark it release critical

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op dinsdag 26 maart 2013 18:35:00 schreef Thierry Vignaud:
> On 23 March 2013 13:31, Thierry Vignaud  wrote:
> >>> >> @thierry: i donno what you think of it, but imo:
> >>> >> A) fixing lstdetect would be the cleanest way (maybe not the
> >>> >> simplest)
> >>> >> B) perhaps in the comparing i can workaround this, but the compare
> >>> >> code
> >>> >> will not be as simple as it should...
> >>> > 
> >>> > forgot to mention option C:
> >>> > 
> >>> > C) using kmod in stage1
> >>> > 
> >>> > but option C might not be as easy and will increase the stage1 size;
> >>> > and
> >>> > raises the question if stage2 is actually still needed then...?
> >>> 
> >>> As already said, stage1 uses ldetect which use libkmod, thus we already
> >>> are linked to it.
> >>> mdv switched to kmod.
> >>> You can look at it.
> >>> But show me the patch before commiting it.
> >>> In the meantime please upload a stage1 with your change revertd
> >> 
> >> yeah, this might be over my head as a beginner in this kind of code...
> >> 
> >> I was hoping a simple workaround would do for now, since we're already
> >> this
> >> late...
> >> 
> >> but i guess since we're linking into libkmod anyway, it might as well be
> >> done.
> >> 
> >> i'm not confident, but i'll give it a try.
> > 
> > I've backported the needed changes.
> > I've tested it with USB hid, it worked.
> > Please test too (normal modules + xen).
> > Then I'll submit it
> 
> Ping? Can you test it?

ah, sorry, all modules seem to load fine, i tested with several modules, no 
failed modules, including xen modules

that effectively solves this problem.

Re: [Mageia-dev] Fw: Wifi

[AL13N]

Op zaterdag 23 maart 2013 19:27:35 schreef Juergen Harms:
> Sorry for missing out people, here is an updated list (and sorry for
> just having sent a junk message) - probably this should be an attachment
> to one of the bugzilla reports.
> 
> Reports on interface problem  bugzilla #, ML
> 
> 
> BCM4311   tho...@btspuhler.com  6111
> 
> BCM4312   e...@writeme.com  7828
> 
> BCM4313   tipaul2...@hotmail.com7828
> BCM4313   thinkst...@arcor.de   6220
> 
> BCM4353   sander.le...@eesti.ee 7828
> 
> BCM43224  paul.blackb...@gmail.com  7827
> 
> BCM43228  juergen.ha...@unige.ch7828  Dell Latitude E6530
> 
>   tho...@btspuhler.com  7828  Dell Inspiron  E1405
> 
> 
> Reports on working interface
> 
> 
> BCM4313 on NM f...@roadrunner.com   ML
> BCM4318   imno...@rock3d.netML

or maybe a tracker of related bug reports and a note in that bugreport which 
people want to help

Re: [Mageia-dev] drakxtools & drakx-installer-stage2 (mga#9428)

[AL13N]

Op zaterdag 23 maart 2013 14:51:11 schreef Glen Ogilvie:
> On 23 March 2013 11:57, Pascal Terjan  wrote:
> > On 22 Mar 2013 22:21, "Glen Ogilvie"  wrote:
> > > On 23 March 2013 05:12, AL13N  wrote:
> > >> Op vrijdag 22 maart 2013 07:38:56 schreef Frank Griffin:
> > >> > On 03/22/2013 07:20 AM, Glen Ogilvie wrote:
> > >> [...]
> > >> 
> > >> > > 1. How does the src tar.xz file for drakx-installer-stage2 get
> > >> > > created?   I assume it comes from a
> > >> > > build of svn://svn.mageia.org/svn/soft/drakx/trunk
> > >> > > <http://svn.mageia.org/svn/soft/drakx/trunk>, but can't find how it
> > >> > > ends up as a tar.xz
> > >> > 
> > >> > I'm maybe about two days ahead of you on this, but here's what I
> > >> > think
> > >> > happens, FWIW.  You do your checkout, and then in the mdk-stage1
> > >> > subdirectory, do a "make dist-svn".  This should produce the tar.xz
> > >> > in
> > >> > the mdk-stage1 directory.
> > >> 
> > >> [...]
> > >> 
> > >> "make dist" actually...
> > >> 
> > >> it will target make "dist-svn" or "make dist-git" depending on if
> > 
> > you're using
> > 
> > >> git-svn or not.
> > >> 
> > >> be advised that dist-svn uses the BASE and any uncommitted change will
> > 
> > not be
> > 
> > >> applied.
> > >> 
> > >> dist-git however, you can commit without pushing them and that will be
> > 
> > used.
> > 
> > > I've had a good play around with make dist.
> > > It seems to me, like running make dist in the perl-install directory,
> > 
> > (svn://svn.mageia.org/svn/soft/drakx/trunk/ )
> > 
> > > does not produce the same tar.xz file as found within
> > 
> > drakx-installer-stage2 sources.
> > 
> > > For example, the tar.gz produced by "make dist" does not contain the
> > 
> > "kernel", "perl-install/install" directories, etc.
> > 
> > > Also, inside the tar, the first directory is: "drakxtools-15.29", rather
> > 
> > than "drakx-installer-stage2-15.29".  It is also
> > 
> > > only 2.4MB instead of about 4.3MB.
> > > 
> > > Any suggestions?
> > 
> > Yes, you need to go into install subdirectory (if I remember the name
> > correctly)
> 
> Ah, great.  Thank you.. That does the trick. :)
> 
> Would anyone mind if update
> https://wiki.mageia.org/en/Drakx-installer_tips_and_tricks, and then update
> the URL in the spec file of drakx-installer-stage2 to point to it, along
> with a comment on how to create the source tar.xz
> Current URL in the spec is: http://wiki.mandriva.com/Tools/DrakX  (which
> just goes to Mandriva's main wiki page)

no, it should go to a DrakX mageia wiki page instead. 

the installer tips and tricks link should be in the spec file, but i'd love it 
if you updated it with what you know by now...

Re: [Mageia-dev] drakxtools & drakx-installer-stage2 (mga#9428)

[AL13N]

Op vrijdag 22 maart 2013 07:38:56 schreef Frank Griffin:
> On 03/22/2013 07:20 AM, Glen Ogilvie wrote:
[...]
> > 1. How does the src tar.xz file for drakx-installer-stage2 get
> > created?   I assume it comes from a
> > build of svn://svn.mageia.org/svn/soft/drakx/trunk
> > , but can't find how it
> > ends up as a tar.xz
> 
> I'm maybe about two days ahead of you on this, but here's what I think
> happens, FWIW.  You do your checkout, and then in the mdk-stage1
> subdirectory, do a "make dist-svn".  This should produce the tar.xz in
> the mdk-stage1 directory.
[...]

"make dist" actually...

it will target make "dist-svn" or "make dist-git" depending on if you're using 
git-svn or not.

be advised that dist-svn uses the BASE and any uncommitted change will not be 
applied.

dist-git however, you can commit without pushing them and that will be used.

Re: [Mageia-dev] freeze push: urpmi & rpmdrake

[AL13N]

Op donderdag 21 maart 2013 08:41:32 schreef Thierry Vignaud:
> Hi
> 
> Please let in urpmi & rpmdrake.
> Both test testsuites pass.
> 
> urpmi fixes main_window management for rpmdrake
> 
> rpmdrake is fixed regarding download progress bar.
> It also now uses the global progress bar for downloads too.
> 
> thx

whoa, that is nice!

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op woensdag 20 maart 2013 21:28:51 schreef Thierry Vignaud:
> On 20 March 2013 21:22, AL13N  wrote:
> >> > > That's because modules.alias enables to match through wildchars.
> >> > > 
> >> > > eg for ehci (see either /sbin/modinfo ehci_pci or
> >> > > "fgrep ehci /lib/modules/3.8.3-desktop-2.mga3/modules.alias"):
> >> > > 
> >> > > alias pci:v104AdCC00sv*sd*bc*sc*i* ehci_pci
> >> > > alias pci:v*d*sv*sd*bc0Csc03i20* ehci_pci
> >> > > 
> >> > > That means that ehci matches both:
> >> > > - 0x104A 0xCC00 (probably a device that reports a broken/bogus class)
> >> > > - any PCI device whose class is PCI_CLASS_SERIAL_USB_EHCI
> >> > > 
> >> > > Note that for this one:
> >> > > - lsmod reports ehci_pci
> >> > > - modinfo reports the real fs path: ehci-pci
> >> > > - lspci -vvk reports: ehci-pci
> >> > 
> >> > I understand.  It is the kernel itself (and associated tools) that mix
> >> > and match underscore and dash.  Hence the need for a conversion patch.
> >> 
> >> not really, it just means that in the kernel - are mapped to _; modprobe
> >> tools handle both cases, just modinfo reports the filename which can
> >> include '-', but it can still handle both.
> >> 
> >> lspci and most tools just report it as it's really named (depending on
> >> filename). modules.dep and modules.descr, etc... has the name as it is as
> >> well, meaning there can be '-' in the name.
> >> 
> >> i just see this workaround being effective to handle lstdetect, which
> >> somehow forces all of it being lowercase...
> >> 
> >> i don't know how much of lstdetect is hardcoded and how much of it is
> >> generated, but imho the cleanest way would be to fix lstdetect, so that
> >> it
> >> gives the proper module names...
> >> 
> >> i've been looking at a way to fix the module list window for choosing,
> >> but
> >> the problem isn't as simple as i thought, since insmod looks at
> >> filenames... which is another workaround.
> >> 
> >> @thierry: i donno what you think of it, but imo:
> >> A) fixing lstdetect would be the cleanest way (maybe not the simplest)
> >> B) perhaps in the comparing i can workaround this, but the compare code
> >> will not be as simple as it should...
> > 
> > forgot to mention option C:
> > 
> > C) using kmod in stage1
> > 
> > but option C might not be as easy and will increase the stage1 size; and
> > raises the question if stage2 is actually still needed then...?
> 
> As already said, stage1 uses ldetect which use libkmod, thus we already
> are linked to it.
> mdv switched to kmod.
> You can look at it.
> But show me the patch before commiting it.
> In the meantime please upload a stage1 with your change revertd

yeah, this might be over my head as a beginner in this kind of code...

I was hoping a simple workaround would do for now, since we're already this 
late...

but i guess since we're linking into libkmod anyway, it might as well be done.

i'm not confident, but i'll give it a try.

PS: i commited the revert.

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op woensdag 20 maart 2013 21:21:35 schreef Thierry Vignaud:
> On 20 March 2013 20:47, AL13N  wrote:
> >> > I see your point: modules.dep and the actual driver module filenames
> >> > in /lib/modules use dashes in the names, while usbtable uses
> >> > underscores.  So why does lsmod show underscores instead of dashes ?
> >> > 
> >> > Also, why do the two differ ?  If the kernel package, which one would
> >> > think is definitive, uses dashes, why does ldetect-lst use underscores
> >> > ?
> >> 
> >> Oh, one other thing.  On the working system, harddrake shows two
> >> keyboard devices: a USB keyboard (PCI 0x1226/0x0034) and a LiteON USB
> >> Keyboard (PCI 0x04ca/0x0022).  Neither of these appear in usbtable.  Or
> >> is the problem with *any* USB device because of the ehci-*** modules
> >> that are needed ?
> > 
> > 1. since ages already, modprobe accepts with - or with _ it makes no
> > difference,
> 
> You know we don't use modprobe in stage1, do you?

yes, i know... :-)

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op woensdag 20 maart 2013 21:20:14 schreef AL13N:
> Op woensdag 20 maart 2013 15:50:06 schreef Frank Griffin:
> > On 03/20/2013 01:33 PM, Thierry Vignaud wrote:
> > > That's because modules.alias enables to match through wildchars.
> > > 
> > > eg for ehci (see either /sbin/modinfo ehci_pci or
> > > "fgrep ehci /lib/modules/3.8.3-desktop-2.mga3/modules.alias"):
> > > 
> > > alias pci:v104AdCC00sv*sd*bc*sc*i* ehci_pci
> > > alias pci:v*d*sv*sd*bc0Csc03i20* ehci_pci
> > > 
> > > That means that ehci matches both:
> > > - 0x104A 0xCC00 (probably a device that reports a broken/bogus class)
> > > - any PCI device whose class is PCI_CLASS_SERIAL_USB_EHCI
> > > 
> > > Note that for this one:
> > > - lsmod reports ehci_pci
> > > - modinfo reports the real fs path: ehci-pci
> > > - lspci -vvk reports: ehci-pci
> > 
> > I understand.  It is the kernel itself (and associated tools) that mix
> > and match underscore and dash.  Hence the need for a conversion patch.
> 
> not really, it just means that in the kernel - are mapped to _; modprobe
> tools handle both cases, just modinfo reports the filename which can
> include '-', but it can still handle both.
> 
> lspci and most tools just report it as it's really named (depending on
> filename). modules.dep and modules.descr, etc... has the name as it is as
> well, meaning there can be '-' in the name.
> 
> i just see this workaround being effective to handle lstdetect, which
> somehow forces all of it being lowercase...
> 
> i don't know how much of lstdetect is hardcoded and how much of it is
> generated, but imho the cleanest way would be to fix lstdetect, so that it
> gives the proper module names...
> 
> i've been looking at a way to fix the module list window for choosing, but
> the problem isn't as simple as i thought, since insmod looks at
> filenames... which is another workaround.
> 
> @thierry: i donno what you think of it, but imo:
> A) fixing lstdetect would be the cleanest way (maybe not the simplest)
> B) perhaps in the comparing i can workaround this, but the compare code will
> not be as simple as it should...

forgot to mention option C:

C) using kmod in stage1

but option C might not be as easy and will increase the stage1 size; and 
raises the question if stage2 is actually still needed then...?

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op woensdag 20 maart 2013 15:50:06 schreef Frank Griffin:
> On 03/20/2013 01:33 PM, Thierry Vignaud wrote:
> > That's because modules.alias enables to match through wildchars.
> > 
> > eg for ehci (see either /sbin/modinfo ehci_pci or
> > "fgrep ehci /lib/modules/3.8.3-desktop-2.mga3/modules.alias"):
> > 
> > alias pci:v104AdCC00sv*sd*bc*sc*i* ehci_pci
> > alias pci:v*d*sv*sd*bc0Csc03i20* ehci_pci
> > 
> > That means that ehci matches both:
> > - 0x104A 0xCC00 (probably a device that reports a broken/bogus class)
> > - any PCI device whose class is PCI_CLASS_SERIAL_USB_EHCI
> > 
> > Note that for this one:
> > - lsmod reports ehci_pci
> > - modinfo reports the real fs path: ehci-pci
> > - lspci -vvk reports: ehci-pci
> 
> I understand.  It is the kernel itself (and associated tools) that mix
> and match underscore and dash.  Hence the need for a conversion patch.

not really, it just means that in the kernel - are mapped to _; modprobe tools 
handle both cases, just modinfo reports the filename which can include '-', but 
it can still handle both.

lspci and most tools just report it as it's really named (depending on 
filename). modules.dep and modules.descr, etc... has the name as it is as well, 
meaning there can be '-' in the name.

i just see this workaround being effective to handle lstdetect, which somehow 
forces all of it being lowercase...

i don't know how much of lstdetect is hardcoded and how much of it is 
generated, but imho the cleanest way would be to fix lstdetect, so that it 
gives the proper module names...

i've been looking at a way to fix the module list window for choosing, but the 
problem isn't as simple as i thought, since insmod looks at filenames... which 
is another workaround.

@thierry: i donno what you think of it, but imo:
A) fixing lstdetect would be the cleanest way (maybe not the simplest)
B) perhaps in the comparing i can workaround this, but the compare code will 
not be as simple as it should...

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op woensdag 20 maart 2013 12:50:06 schreef Frank Griffin:
> On 03/20/2013 12:34 PM, Frank Griffin wrote:
> > I'm confused.
> > 
> > I see your point: modules.dep and the actual driver module filenames
> > in /lib/modules use dashes in the names, while usbtable uses
> > underscores.  So why does lsmod show underscores instead of dashes ?
> > 
> > Also, why do the two differ ?  If the kernel package, which one would
> > think is definitive, uses dashes, why does ldetect-lst use underscores ?
> 
> Oh, one other thing.  On the working system, harddrake shows two
> keyboard devices: a USB keyboard (PCI 0x1226/0x0034) and a LiteON USB
> Keyboard (PCI 0x04ca/0x0022).  Neither of these appear in usbtable.  Or
> is the problem with *any* USB device because of the ehci-*** modules
> that are needed ?

1. since ages already, modprobe accepts with - or with _ it makes no 
difference,
2. lsmod will always show _.
3. lstdetect (used in stage1) uses _ only.
4. stage1 manual module uses it based on filename/modules.dep, so it keeps 
original - or _  ==> this is what i'll write a patch for. to convert in table 
before displaying manual check.


then, i'll also try to write a detect XenDevices procedure (like the virtIO 
that i've seen).

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op dinsdag 19 maart 2013 18:53:07 schreef Frank Griffin:
> On 03/19/2013 04:56 PM, AL13N wrote:
> > a module list of loaded modules with that hardware...
> > 
> > i think it might be this commit, but i'm wondering what's the difference
> > inbetween automatic loading and loading from the module box.
> > 
> > iow: we need to find what module is actually the problem
> 
> Here we go ...
> 
> [root@ftgfw ftg]# lsmod
> Module  Size  Used by
> ipcomp 12661  0
> xfrm_ipcomp13413  1 ipcomp
> ah413044  0
> esp4   17098  0
> deflate12617  0
> ctr13005  0
> twofish_generic16635  0
> twofish_x86_64_3way27181  0
> twofish_x86_64 12907  1 twofish_x86_64_3way
> twofish_common 21113  3
> twofish_generic,twofish_x86_64_3way,twofish_x86_64
> camellia_generic   29260  0
> camellia_x86_6453205  0
> serpent_sse2_x86_6450443  0
> serpent_generic25727  1 serpent_sse2_x86_64
> xts12914  3
> camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
> lrw13286  3
> camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
> gf128mul   14951  2 lrw,xts
> glue_helper13541  3
> camellia_x86_64,serpent_sse2_x86_64,twofish_x86_64_3way
> blowfish_generic   12530  0
> blowfish_x86_6421381  0
> blowfish_common16739  2 blowfish_generic,blowfish_x86_64
> cast5_generic  21429  0
> cast_common12983  1 cast5_generic
> ablk_helper13597  1 serpent_sse2_x86_64
> cryptd 20403  1 ablk_helper
> des_generic21350  0
> cbc12774  0
> xcbc   12815  0
> rmd160 16744  0
> sha512_generic 12770  0
> sha256_generic 21005  0
> sha1_generic   12845  0
> crypto_null12840  0
> af_key 36092  2
> xfrm_algo  15508  4 ah4,esp4,af_key,xfrm_ipcomp
> fuse   78830  2
> ipt_IFWLOG 12622  2
> ipt_psd57587  1
> cls_basic  12946  0
> cls_flow   17125  0
> cls_fw 12904  0
> cls_u3217137  0
> sch_tbf13064  0
> sch_prio   13152  0
> sch_htb22146  0
> sch_hfsc   22206  0
> sch_ingress12866  0
> sch_sfq21375  0
> bridge100378  0
> stp12976  1 bridge
> llc14552  2 stp,bridge
> xt_CHECKSUM12549  0
> ipt_rpfilter   12546  0
> xt_statistic   12601  0
> xt_CT  12868  18
> xt_LOG 17521  8
> xt_time12661  0
> xt_connlimit   12636  0
> xt_realm   12498  0
> xt_addrtype12635  4
> ip_set_hash_ip 32055  2
> xt_comment 12504  18
> xt_recent  18542  0
> xt_policy  12582  20
> xt_nat 12681  0
> ipt_ULOG   18245  0
> ipt_REJECT 12541  4
> ipt_MASQUERADE 12880  1
> ipt_ECN12529  0
> ipt_CLUSTERIP  13508  0
> ipt_ah 12806  0
> xt_set 13099  2
> ip_set 36382  2 ip_set_hash_ip,xt_set
> nf_nat_tftp12489  0
> nf_nat_snmp_basic  17302  0
> nf_conntrack_snmp  12857  3 nf_nat_snmp_basic
> nf_nat_sip 17152  0
> nf_nat_pptp13115  0
> nf_nat_proto_gre   13009  1 nf_nat_pptp
> nf_nat_irc 12643  0
> nf_nat_h32317720  0
> nf_nat_ftp 12770  0
> nf_nat_amanda  12491  0
> ts_kmp 12605  5
> nf_conntrack_amanda13041  3 nf_nat_amanda
> nf_conntrack_sane  13143  2
> nf_conntrack_tftp  13121  3 nf_nat_tftp
> nf_conntrack_sip   29771  3 nf_nat_sip
> nf_conntrack_proto_udplite13281  0
> nf_conntrack_proto_sctp18822  0
> nf_conntrack_pptp  19245  3 nf_nat_pptp
> nf_conntrack_proto_gre14434  1 nf_conntrack_pptp
> nf_conntrack_netlink35735  0
> nf_conntrack_netbios_ns12665  2
> nf_conntrack_broadcast12589  2 nf_conntrack_netbios_ns,nf_conntrack_snmp
> nf_conntrack_irc   13518  3 nf_nat_irc
> nf_conntrack_h323  73845  1 nf_nat_h323
> nf_conntrack_ftp   18643  3 nf_nat_ftp
> xt_TPROXY  17327  0
> nf_defrag_ipv6 18261  1 xt_TPROXY
> nf_tproxy_core 12610  1 xt_TPROXY
> xt_tcpmss  12501  0
> xt_pkttype 12504 

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op dinsdag 19 maart 2013 16:53:46 schreef Frank Griffin:
> On 03/19/2013 03:35 PM, AL13N wrote:
> > the patch removes the previous workaround that converts - in module
> > filenames, to _ . it's removed because if a module is selected manually,
> > it's made from filenames. so the - must match.
> > 
> > maybe if a module isn't selected manually, it comes from lstdetect or udev
> > or whatever it comes from... maybe your module is wrong... like that the
> > modules are called ehci-hcd and the filename is called ehci_hcd ? it
> > would be nice to know... if you can find a working setup (older livecd)
> > and give an lsmod, we might be able to deduce that. from whatever modules
> > you need.
> > 
> > in any case, with this hardware, did the previous beta work?
> 
> Well, I don't really test from the ISOs; I just build straight from
> cauldron.
> 
> It did work on the same box on Mar 11, and I have that working system
> with its initrd and kernel module directories.  But I'm not very
> familiar with the internal metadata lists we keep that would have to
> match up.
> 
> If you can tell me precisely what you need and where to find it, I'll be
> happy to dig it out.

a module list of loaded modules with that hardware...

i think it might be this commit, but i'm wondering what's the difference 
inbetween automatic loading and loading from the module box.

iow: we need to find what module is actually the problem

Re: [Mageia-dev] USB Keyboard disabled in current stage1

[AL13N]

Op dinsdag 19 maart 2013 14:33:30 schreef Frank Griffin:
> On 03/19/2013 12:15 PM, Colin Guthrie wrote:
> > 'Twas brillig, and Frank Griffin at 19/03/13 15:25 did gyre and gimble:
> >> Problem still present in last night's installer upload...
> > 
> > Were you able to try Thierry's suggestion?
> 
> My apologies, I must have missed it.  I looked it up in the archives,
> and from the code involved, it looked like a good possibility.  I went
> and read bug#9242, but given the trouble al13n had, I don't think I'd
> fare too well trying to check out and rebuild stage1.  I've used svn
> lightly, years ago, but I'm not familiar with the MGA SVN layout at all.
> 
> The dracut patch you mentioned added ehci-pci and ehci-platform.  I
> drilled down into the all.rdz files for isolinux, and boot.iso, and
> all.rdz.uncompressed has all three of them (-hcd, -pci, -platform). The
> working cauldron partition from Mar 11's MCC harddrake reports the
> module for the USB keyboard as usbhid, which is there as well in all of
> them.
> 
> So perhaps the problem is in some control list of things to be loaded ?
> If you can point me to that, I'll check it.
> 
> > I don't see any significant changes:
> > http://svnweb.mageia.org/soft/drakx/trunk/mdk-stage1/?view=log
> > 
> > So it would still be interesting to know if the commit he mentioned
> > (http://svnweb.mageia.org/soft?view=revision&sortby=date&revision=7542)
> > is the one to blame for this.
> 
> My impression from the code and the bug report comments is that the
> change either converts "-" in module names to "_" or vice-versa, or
> stops whichever of these it was doing before.
> 
> Also, the bugreports states that "tv is OK with this provided it's
> tested", and follows this up with "I couldn't test it", so it's unclear
> what the status of the change really is.

the patch removes the previous workaround that converts - in module filenames, 
to _ . it's removed because if a module is selected manually, it's made from 
filenames. so the - must match.

maybe if a module isn't selected manually, it comes from lstdetect or udev or 
whatever it comes from... maybe your module is wrong... like that the modules 
are called ehci-hcd and the filename is called ehci_hcd ? it would be nice to 
know... if you can find a working setup (older livecd) and give an lsmod, we 
might be able to deduce that. from whatever modules you need.

in any case, with this hardware, did the previous beta work?

Re: [Mageia-dev] Release critical bugs for Mageia 3

[AL13N]

Op vrijdag 15 maart 2013 17:02:47 schreef Johnny A. Solbu:
> On Friday 15. March 2013 15.26, Anne Nicolas wrote:
> > So here is a review of these bugs:
> > 
> > https://docs.google.com/spreadsheet/ccc?key=0Ao3phYOTRNeQdEEtSjBSSWkxTmdIc
> > mJZcGtfYjN1NVE&usp=sharing
> Really!?
> So now we need to register at Google in order to help develop Mageia?
> (I'm asked to login in order to see it)
> 
> What's wrong with the wiki, a html file or a plain old text file?

this is called bikeshedding...

what's important here is that the bugs are fixed, and i'm sure you can find 
them 
using bugzilla anyway...

Re: [Mageia-dev] [soft-commits] [7542] - fix loading modules with "-" in their names (mga#9242)

[AL13N]

> 'Twas brillig, and AL13N at 15/03/13 06:50 did gyre and gimble:
>> Op donderdag 14 maart 2013 21:25:15 schreef Thierry Vignaud:
>>> On 14 March 2013 20:29, AL13N  wrote:
>>>>>> - fix loading modules with "-" in their names (mga#9242)
>>>>>> - add an easy buildtarget for testing
>>>>>
>>>>> A couple remarks:
>>>>> - next time do a commit a time (first your change, then bumping
>>>>> version)
>>>>
>>>> ah, ok, is there a reason for this (to have separate a change and then
>>>> a
>>>> version bump)?
>>>
>>> in order to have smaller easier to review commits.
>>> You really do not want to come on big old commits when trying to
>>> understand
>>> a problem.
>>>
>>>>> I hope you tested several modules with both case?
>>>>
>>>> yes, i tried with several. and since the xen-netfront modules aren't
>>>> autodetected for some reason (i'm trying to look into it)
>>>
>>> b/c it has no pci/usb alias, only the following (which we do not look
>>> for)
>>> alias:  xennet
>>> alias:  xen:vif
>>>
>>> well, we don't know how to detect that.
>>
>> supposedly udev should give events to load that...
>>
>> but perhaps stage1 doesn't use udev?
>>
>> would you think it would be ok, to manually add such workaround code in
>> stage1?
>
> For mga4 I hope I have the time to look into rebasing stage1 on
> dracut... not sure it is the right thing overall, but it would be nice
> to cut down on different things used in different places (assuming it
> doesn't cause any problems!).
>
> But, meh, we'll see how the time goes!!

i doubt you'll have time...

but, in that case, maybe stage1 (or stage2) is not required anymore???

maybe i should first do these workarounds about xen:vif ...

Re: [Mageia-dev] [soft-commits] [7542] - fix loading modules with "-" in their names (mga#9242)

[AL13N]

Op donderdag 14 maart 2013 21:25:15 schreef Thierry Vignaud:
> On 14 March 2013 20:29, AL13N  wrote:
> >> > - fix loading modules with "-" in their names (mga#9242)
> >> > - add an easy buildtarget for testing
> >> 
> >> A couple remarks:
> >> - next time do a commit a time (first your change, then bumping version)
> > 
> > ah, ok, is there a reason for this (to have separate a change and then a
> > version bump)?
> 
> in order to have smaller easier to review commits.
> You really do not want to come on big old commits when trying to understand
> a problem.
> 
> >> I hope you tested several modules with both case?
> > 
> > yes, i tried with several. and since the xen-netfront modules aren't
> > autodetected for some reason (i'm trying to look into it)
> 
> b/c it has no pci/usb alias, only the following (which we do not look for)
> alias:  xennet
> alias:  xen:vif
> 
> well, we don't know how to detect that.

supposedly udev should give events to load that...

but perhaps stage1 doesn't use udev?

would you think it would be ok, to manually add such workaround code in 
stage1?

Re: [Mageia-dev] [soft-commits] [7542] - fix loading modules with "-" in their names (mga#9242)

[AL13N]

Op donderdag 14 maart 2013 19:47:36 schreef Thierry Vignaud:
> On 13 March 2013 20:52,   wrote:
> > Revision 7542 Author alien Date 2013-03-13 20:52:07 +0100 (Wed, 13 Mar
> > 2013)
> > 
> > Log Message
> > 
> > - fix loading modules with "-" in their names (mga#9242)
> > - add an easy buildtarget for testing
> 
> A couple remarks:
> - next time do a commit a time (first your change, then bumping version)

ah, ok, is there a reason for this (to have separate a change and then a 
version bump)?

now that you mention this, i think i've seen you say this to thomas before... 
it would've been nice to have had some documentation regarding these things...

> - please revert your dist-svn-test;
>   when one wants to test, either he commits in git-svn or he locally runs
> "make"

well, it would've been nicer if you have said so before (or documented it 
someplace), i spent more than 4 hours figuring out why my changes had no 
effect... but sure, i'll revert it.

> I hope you tested several modules with both case?

yes, i tried with several. and since the xen-netfront modules aren't 
autodetected for some reason (i'm trying to look into it), i had the 
opportunity to test alot with various modules. (also, i note that virtmanager 
telling to use e1000 or other model, it still uses the netfront one instead..)

> > Modified Paths
> > 
> > drakx/trunk/mdk-stage1/Makefile
> > drakx/trunk/mdk-stage1/NEWS
> > drakx/trunk/mdk-stage1/modules.c
> > 
> > Modified: drakx/trunk/mdk-stage1/Makefile
> > ===
> > --- drakx/trunk/mdk-stage1/Makefile 2013-03-12 19:12:12 UTC (rev 7541)
> > +++ drakx/trunk/mdk-stage1/Makefile 2013-03-13 19:52:07 UTC (rev 7542)
> > @@ -15,7 +15,7 @@
> > 
> >   # along with this program; if not, write to the Free Software
> >   # Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> > 
> > -VERSION=1.74.1
> > +VERSION=1.75
> > 
> >  PRODUCT=drakx-installer-binaries
> >  
> >   #
> > 
> > @@ -217,6 +217,14 @@
> > 
> >  fi;
> >   
> >   $(info $(PRODUCT)-$(VERSION).tar.xz is ready)
> > 
> > +dist-svn-test:
> > + mkdir -p $(PRODUCT)-$(VERSION)
> > + svn export -q . $(PRODUCT)-$(VERSION)/mdk-stage1
> > + svn export -q ../kernel $(PRODUCT)-$(VERSION)/kernel
> > + cp ../Makefile.config $(PRODUCT)-$(VERSION)/
> > + tar cfa $(PRODUCT)-$(VERSION).tar.xz $(PRODUCT)-$(VERSION)
> > + rm -rf $(PRODUCT)-$(VERSION)
> > +
> > 
> >  dist-svn:
> >   mkdir -p $(PRODUCT)-$(VERSION)
> >   svn export -q -rBASE . $(PRODUCT)-$(VERSION)/mdk-stage1

Re: [Mageia-dev] no signature errors on latest updates

[AL13N]

> On Thu 14 Mar 2013 14:00:19 GMT, Johnny A. Solbu wrote:
>> On Thursday 14. March 2013 14.46, isadora wrote:
>>> See:
>>> https://bugs.mageia.org/show_bug.cgi?id=9385
>>
>> In my opinion, this should qualify as a release blocker.
>
> There is no need to call everything "release blocker" as soon as a bug
> is annoying.
> Here, it's just something annoying that needs to be fixed by the
> sysadmin team. It happens periodically.
> Cheers,


like... every year around the middle of March :-)

Re: [Mageia-dev] freeze push: drakx-installer-binaries

[AL13N]

> AL13N skrev 14.3.2013 08:38:
>> Op woensdag 13 maart 2013 21:00:45 schreef AL13N:
>>> Please push: drakx-installer-binaries:
>>> - fix loading modules with "-" in their names (mga#9242)
>>>
>>> in the stage1 window to load extra modules (eg: xen-netfront), all
>>> modules
>>> with '-' in the name failed. this fix allows those modules to be loaded
>>> when
>>> requested.
>>
>> ping
>>
>
> d-i-b was pushed ~10 h ago by guillomovitch
>
>
> I just pushed stage2/images/rescue to pick up latest d-i-b.

ah, i hadn't seen it... thanks!

Re: [Mageia-dev] freeze push: drakx-installer-binaries

[AL13N]

Op woensdag 13 maart 2013 21:00:45 schreef AL13N:
> Please push: drakx-installer-binaries:
> - fix loading modules with "-" in their names (mga#9242)
> 
> in the stage1 window to load extra modules (eg: xen-netfront), all modules
> with '-' in the name failed. this fix allows those modules to be loaded when
> requested.

ping

[Mageia-dev] freeze push: drakx-installer-binaries

[AL13N]

Please push: drakx-installer-binaries:
- fix loading modules with "-" in their names (mga#9242)

in the stage1 window to load extra modules (eg: xen-netfront), all modules 
with '-' in the name failed. this fix allows those modules to be loaded when 
requested.

Re: [Mageia-dev] RFC: Patch e2fsprogs to not print the "clean" message on fsck.

[AL13N]

same thing with brtfsck

Op woensdag 13 maart 2013 14:03:02 schreef Colin Guthrie:
> 'Twas brillig, and Colin Guthrie at 13/03/13 12:35 did gyre and gimble:
> > Hi,
> > 
> > I would like to propose that we push a patch to e2fsprogs to make it not
> > print out the "clean" message when it checks the filesystem.
> > 
> > In my current boot (which is an experiment without initrds), it prints
> > this message over the top of plymouth and stays during the nice fade
> > transition to gdm and generally makes the boot ugly.
> > 
> > I believe only the e2fsprogs print this message and the others do not
> > e.g. see this comparison with XFS:
> > 
> > [root@jimmy ~]# dd if=/dev/zero of=xfs.img bs=1M count=100 >/dev/null
> > 2>&1; mkfs.xfs xfs.img >/dev/null 2>&1; xfs_check xfs.img
> > [root@jimmy ~]# dd if=/dev/zero of=ext4.img bs=1M count=100 >/dev/null
> > 2>&1; mkfs.ext4 -F ext4.img >/dev/null 2>&1; fsck.ext4 -a ext4.img
> > ext4.img: clean, 11/25688 files, 8896/102400 blocks
> > 
> > 
> > 
> > My patch would propose to not print the "clean" message when the -a
> > option was passed. This is similar logic which prevents showing the
> > version when -a is passed.
> > 
> > I've not tested this but I will before committing if no-one disapproves
> > of this approach.
> > 
> > --- e2fsprogs-1.42.7/e2fsck/unix.c.orig 2013-03-13 10:57:22.349126868
> > +
> > +++ e2fsprogs-1.42.7/e2fsck/unix.c  2013-03-13 12:33:08.340522834 +
> > @@ -421,13 +421,14 @@
> > 
> > }
> > 
> > /* Print the summary message when we're skipping a full check */
> > 
> > -   log_out(ctx, _("%s: clean, %u/%u files, %llu/%llu blocks"),
> > -   ctx->device_name,
> > -   fs->super->s_inodes_count - fs->super->s_free_inodes_count,
> > -   fs->super->s_inodes_count,
> > -   ext2fs_blocks_count(fs->super) -
> > -   ext2fs_free_blocks_count(fs->super),
> > -   ext2fs_blocks_count(fs->super));
> > +   if (!(ctx->options & E2F_OPT_PREEN))
> > +   log_out(ctx, _("%s: clean, %u/%u files, %llu/%llu blocks"),
> > +   ctx->device_name,
> > +   fs->super->s_inodes_count - 
> > fs->super->s_free_inodes_count,
> > +   fs->super->s_inodes_count,
> > +   ext2fs_blocks_count(fs->super) -
> > +   ext2fs_free_blocks_count(fs->super),
> > +   ext2fs_blocks_count(fs->super));
> > 
> > next_check = 10;
> > if (fs->super->s_max_mnt_count > 0) {
> > 
> > next_check = fs->super->s_max_mnt_count - fs->super-
>s_mnt_count;
> 
> FWIW, this patch is a bit wrong (as it still prints out a newline and
> some other fluff about when the next check is etc.) and it causes a test
> to fail.
> 
> But an updated and tested patch fixes it up. If there are no complaints,
> I'll push it.
> 
> Cheers
> 
> Col

Re: [Mageia-dev] urpmi always use rsync

[AL13N]

Op woensdag 13 maart 2013 16:12:11 schreef Guillaume Rousse:
> Le 13/03/2013 15:01, David Walser a écrit :
> > zezinho  writes:
> >> in my two cauldron systems, urpmi is now always using rsync, even if
> >> another downloader is setup in urpmi.cfg or asked in CLI.
> >> 
> >> I am using default mirrorlist created by edit-urpm-sources.pl.
> > 
> > Indeed it does, and even worse, if your network requires a proxy, this
> > totally does not work.  Even if you have a proxy configured through
> > drakconf, it still won't use it for rsync.  This technically is correct,
> > as that proxy setting is supposed to be just for http/https/ftp, and
> > globally setting the RSYNC_PROXY variable along with those may be
> > undesirable and cause problems with using rsync across your local
> > network.  Still, it'd be nice if this could be handled better somehow. 
> > I'm just not sure what the right solution is.
> 
> Quick solution: stop using useless complexity layers without added
> value, and declare explicitely with mirror url you want to use. You'll
> also have sane source identifiers, instead of the crappy defaut ones
> unusable in command line.

it annoys me that the spaces seem to break the bash-completion for the media 
names...

Re: [Mageia-dev] Team elections

[AL13N]

> Le 05/03/2013 14:06, Anne Nicolas a écrit :
[...]
>> 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
>>
>
> Nobody there? I will not go alone on that. Does that mean there is no
> more packagers team ?

I feel kind of guilty reading this... i don't want Mageia to die out, so
if there's no-one else, i can be a helper if you want me...

Re: [Mageia-dev] [Bug 5199] Several error with ocaml bytecode compilation in ocaml-xen module

[AL13N]

Op zondag 10 maart 2013 17:33:28 schreef Florent Monnier:
> > > ocaml-xen should be split in ocaml-xen and ocaml-xen-devel, (2013-03-04)
> 
> [...]
> 
> > what kind of filenames should be in -devel and which in regular package?
> 
> main package:
> - .cma .cmi .cmo .cmxs .so META .so.owner
> (and README, LICENSE, etc...)
> 
> devel package:
> - .a .cmxa .cmx .o .mli .ml
> (and documentation)
> 
> For more details, read here:
> https://wiki.mageia.org/en/OCaml_policy
> 
> > should some files be deleted? ie: the .a files?
> 
> If you don't know just don't delete anything, just provide what the
> install script did installed.
> Anyway if there is something installed (by error) it won't have bad
> effects on the real parts of the lib.

in any case, i'm asking because we do have a policy of remove all static libs 
(.a) and .la files. i just wasn't sure the .a files were static libs in this 
case, or just something completely unrelated.

but since the others have .so, i think they are static libs.

also, usually there are versioned .so files and the .so files themselves need 
to 
be in -devel; i guess it's not so for ocaml packages...

> For any question, don't hesitate to ask to the current ocaml
> packagers, they are listed at the beginning of this page:
> https://wiki.mageia.org/en/OCaml_Packaging
> 
> Also for any issue, or TODO things you can also use the ocaml wiki pages.


did i accidentally reply to a br mail? i thought i put this in the bugreport, 
but i guess i'm not sure?

Re: [Mageia-dev] [Bug 5199] Several error with ocaml bytecode compilation in ocaml-xen module

[AL13N]

Op zondag 10 maart 2013 17:33:28 schreef Florent Monnier:
> > > ocaml-xen should be split in ocaml-xen and ocaml-xen-devel, (2013-03-04)
> 
> [...]
> 
> > what kind of filenames should be in -devel and which in regular package?
> 
> main package:
> - .cma .cmi .cmo .cmxs .so META .so.owner
> (and README, LICENSE, etc...)
> 
> devel package:
> - .a .cmxa .cmx .o .mli .ml
> (and documentation)
> 
> For more details, read here:
> https://wiki.mageia.org/en/OCaml_policy
> 
> > should some files be deleted? ie: the .a files?
> 
> If you don't know just don't delete anything, just provide what the
> install script did installed.
> Anyway if there is something installed (by error) it won't have bad
> effects on the real parts of the lib.

in any case, i'm asking because we do have a policy of remove all static libs 
(.a) and .la files. i just wasn't sure the .a files were static libs in this 
case, or just something completely unrelated.

but since the others have .so, i think they are static libs.

also, usually there are versioned .so files and the .so files themselves need 
to 
be in -devel; i guess it's not so for ocaml packages...

> For any question, don't hesitate to ask to the current ocaml
> packagers, they are listed at the beginning of this page:
> https://wiki.mageia.org/en/OCaml_Packaging
> 
> Also for any issue, or TODO things you can also use the ocaml wiki pages.


did i accidentally reply to a br mail? i thought i put this in the bugreport, 
but i guess i'm not sure?

[Mageia-dev] XEN (known issues)

[AL13N]

i've finally been able to make XEN work... (with libvirtd and virt-manager)

albeit with some issues...

see https://wiki.mageia.org/en/XEN for anyone wishing to try it.

is this something that should be added to errata for mga3? it seems most of 
the problems are libvirtd related issues with their xen module.

WDYT?

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3

[AL13N]

Op zondag 3 maart 2013 11:46:06 schreef Thierry Vignaud:
>  On 3 March 2013 11:27, AL13N  wrote:
> >> > alien  4.2.1-6.mga3:
> >> > + Revision: 401170
> >> > - Fix creation of log directory
> >> 
> >> now if someone would fix libvirt/virt-manager with xen...
> > 
> > working on it, but it looks like i would need native qemu to get the best
> > results. that would mean trowing all around.
> > 
> > i am in contact with native to have better build procedure and build
> > against qemu natively, so that qemu itself can build the xen and we have
> > proper support, but it's not ready yet.
> > 
> > atm, i'm planning on holding off with that and doing this for mga4.
> > 
> > also a problem is that the qdisk driver (which is really needed if you
> > have a file image with libvirt, instead of having LVM partitions) seems
> > to have some kind of bug, in that the remote and local state don't match.
> > 
> > How far did you get? i was looking for your email, (i know you sent one),
> > but was unable to find it
> 
> as told a couple weeks ago, xl/xm top works but libvirt can't connect to
> xen: Mar 03 10:21:19 localhost libvirtd[833]: erreur interne impossible de
> se connecter à Xen
> Mar 03 10:21:19 localhost libvirtd[833]: unable to connect to
> 'localhost:8000': Connexion refusée
> Mar 03 10:21:19 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:20 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:21 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:49 localhost libvirtd[833]: No response from client
> 0x14423a0 after 5 keepalive messages in 30 seconds

my tests were successfull in both HVM and PV now.

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3

[AL13N]

Op zondag 3 maart 2013 11:46:06 schreef Thierry Vignaud:
>  On 3 March 2013 11:27, AL13N  wrote:
> >> > alien  4.2.1-6.mga3:
> >> > + Revision: 401170
> >> > - Fix creation of log directory
> >> 
> >> now if someone would fix libvirt/virt-manager with xen...
> > 
> > working on it, but it looks like i would need native qemu to get the best
> > results. that would mean trowing all around.
> > 
> > i am in contact with native to have better build procedure and build
> > against qemu natively, so that qemu itself can build the xen and we have
> > proper support, but it's not ready yet.
> > 
> > atm, i'm planning on holding off with that and doing this for mga4.
> > 
> > also a problem is that the qdisk driver (which is really needed if you
> > have a file image with libvirt, instead of having LVM partitions) seems
> > to have some kind of bug, in that the remote and local state don't match.
> > 
> > How far did you get? i was looking for your email, (i know you sent one),
> > but was unable to find it
> 
> as told a couple weeks ago, xl/xm top works but libvirt can't connect to
> xen: Mar 03 10:21:19 localhost libvirtd[833]: erreur interne impossible de
> se connecter à Xen
> Mar 03 10:21:19 localhost libvirtd[833]: unable to connect to
> 'localhost:8000': Connexion refusée
> Mar 03 10:21:19 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:20 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:21 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:49 localhost libvirtd[833]: No response from client
> 0x14423a0 after 5 keepalive messages in 30 seconds


see https://wiki.mageia.org/en/XEN

atm, i'm almost successfull, but it seems you need to have a kernel in the 
image for paravirtualisation, due to libvirtd using pygrub.

which i'm normally not using...

(i also found a libvirt connection bug)

Re: [Mageia-dev] A question about BuildRequires and other RPM questions.

[AL13N]

> On 08/03/13 11:18, Robert Wood wrote:
[...]
>> I still don't get this whole trial and error thing. It seems that you
>> might submit something to the repositories that someone finds doesn't
>> install because of a missing dependency and you redo it. Then you can
>> retry that for up to five goes before it finally works? That seems
>> crazy. I must have misunderstood.

well, if we submit packages, the buildsystem uses the buildrequires and
such to build the packages. if the package fails to build (due to missing
buildrequire) the package is never submitted and we get an email back to
us or we can follow the built packages on the buildsystem: see
http://pkgsubmit.mageia.org/ for examples.

also, buildrequires have nothing to do with regular requires or what
normal users come into contact with.

thus finding buildrequires is trial and error for the packager if he's
making a new package, but only the first time and even then, after you
acquire the skillset, this only takes maximum a few hours (unless it's
java :-) ).

but the best way to understand is to just try it.

the simplest way to start making a package is to first make a src.rpm out
of a tarball (with a spec in it) and then rebuild it.

1. find a tarball which includes a spec file. (or put one in it)
2. rpmbuild -ts file.tar.gz
3. rpmbuild --rebuild file.src.rpm

starting small is the way to get there.

>> I have no problem learning stuff, I do it every single day in my work
>> and it's what makes it so enjoyable, but maybe I need to take smaller
>> steps first? No idea where to start or how to go about doing that
>> though. As I might not have any work in a week's time it would
>> potentially be an ideal time to learn, but maybe I'm just not the right
>> person to do this?

a mentor would definately help, i assume noone has stepped forward for you
yet?

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-7.mga3

[AL13N]

> On 3 March 2013 15:35, alien  wrote:
>> Name: xen  Relocations: (not
>> relocatable)
>> Version : 4.2.1 Vendor: Mageia.Org
>> Release : 7.mga3Build Date: Sun Mar  3
>> 15:28:13 2013
>> Install Date: (not installed)   Build Host:
>> jonund.mageia.org
>> Group   : System/Kernel and hardwareSource RPM: (none)
>> Size: 39692824 License: GPL
>> Signature   : (none)
>> Packager: alien 
>> URL : http://xen.org/
>> Summary : The basic tools for managing XEN virtual machines
>> Description :
>> The basic tools for managing XEN virtual machines.
>>
>> alien  4.2.1-7.mga3:
>> + Revision: 401283
>> - typo in filename
>> - helperscripts are only moved if different arch
>> - Move helper scripts to location they are looked after by various
>> scripts and hardcoded binaries
>
> See https://bugs.mageia.org/show_bug.cgi?id=9294
> xencommons service fails to start on legacy hw (w/o hw support for virt)
>
> systemctl status xencommons.service
> xencommons.service - LSB: Start/stop xenstored and xenconsoled
>   Loaded: loaded (/etc/rc.d/init.d/xencommons)
>   Active: failed (Result: exit-code) since Fri, 2013-03-08
> 06:56:33 CET; 1min 59s ago
>  Process: 685 ExecStart=/etc/rc.d/init.d/xencommons start
> (code=exited, status=127)
>   CGroup: name=systemd:/system/xencommons.service
>   ├ 825 /usr/sbin/oxenstored --pid-file
> /var/run/xenstored.pid
>   └ 838 xenconsoled --pid-file=/var/run/xenconsoled.pid
>
> Mar 08 06:56:32 localhost xencommons[685]: Starting oxenstored...
> Mar 08 06:56:32 localhost xencommons[685]: Setting domain 0 name...
> Mar 08 06:56:32 localhost xencommons[685]: Starting xenconsoled...
> Mar 08 06:56:32 localhost xencommons[685]: Starting QEMU as disk
> backend for dom0
> Mar 08 06:56:32 localhost xencommons[685]:
> /etc/rc.d/init.d/xencommons: ligne119:
> /usr/lib/xen/bin/qemu-system-i386: No such file or directory
> Mar 08 06:56:33 localhost systemd[1]: Failed to start LSB: Start/stop
> xenstored and xenconsoled.
> Mar 08 06:56:33 localhost systemd[1]: Unit xencommons.service entered
> failed state
>
> It's in /usr/bin, not in /usr/lib/xen/bin...
>
> (/etc/sysconfig/xencommons needs fixing)
>
> And it lacks a require on qemu
>

1. /usr/lib/xen/bin/qemu-system-i386 is where the qemu-upstream version is
(which we don't ship), we should switch this to traditional:
/usr/lib/xen/bin/qemu-dm

but... xencommons isn't supposed to be run anymore (unless you're using
xend).

normally, we only need 'xenconsoled' and 'xenstored' for the xl service.

2. if you don't have hardware virt support, i would think it's normal that
it fails to start?

3. you don't need qemu to run xen, if you run paravirtualisation only,
there is no need for qemu. so definately not a requirement.

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release libvirt-1.0.2-4.mga3

[AL13N]

Op vrijdag 8 maart 2013 07:15:48 schreef Thierry Vignaud:
> On 8 March 2013 01:50, alien  wrote:
> > alien  1.0.2-4.mga3:
> > + Revision: 401739
> > - XEN: do not force blktap as disk backend
> 
> Still:
> # service libvirtd status
> Redirecting to /bin/systemctl status libvirtd.service
> libvirtd.service - Virtualization daemon
>   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
> Active: active (running) since Fri, 2013-03-08 07:12:14 CET; 2min 48s ago
> Main PID: 860 (libvirtd)
>   CGroup: name=systemd:/system/libvirtd.service
>   ├  860 /usr/sbin/libvirtd
>   └ 1280 dnsmasq
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf
> 
> Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor
> ioctl 3166208: Permission non accordée
> Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor
> ioctl 3166208: Permission non accordée
> Mar 08 07:12:59 localhost libvirtd[860]: Unable to issue hypervisor
> ioctl 3166208: Permission non accordée
> Mar 08 07:12:59 localhost libvirtd[860]: erreur interne impossible de
> se connecter à Xen
> Mar 08 07:12:59 localhost libvirtd[860]: unable to connect to
> 'localhost:8000': Connexion refusée
> Mar 08 07:12:59 localhost libvirtd[860]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 08 07:13:00 localhost libvirtd[860]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 08 07:13:01 localhost libvirtd[860]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 08 07:13:02 localhost libvirtd[860]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 08 07:13:28 localhost libvirtd[860]: No response from client
> 0x21d39b0 after 5 keepalive messages in 30 seconds


either try to connect to xen://127.0.0.1/ or ssh+xen://127.0.0.1/ . (as a 
remote machine)

that, or use xend and xm commands (supposedly xend works better with libvirt 
rather than xenlight)

i see connection refused, so, is port 8000 actually running? and/or firewalled?

check with "netstat -lntop" if 8000 is in use by xend.

it seems to fall back to libxl... maybe if you change default.xml file to have




(this is if you have an existing bridge)

this is because libxl doesn't manage a bridge and/or networking. libxl 
mentions that the user should set up a bridge on your system with network 
scripts.

so in short, there's 2 ways to do xen (+libvirt) and you're somewhere in 
between atm...

Re: [Mageia-dev] Why is AHCI statically compiled into kernel?

[AL13N]

Op donderdag 7 maart 2013 12:18:09 schreef Anne Wilson:
> On 07/03/13 12:03, AL13N wrote:
> >> On 07/03/13 04:38, R James wrote:
> > [...]
> > 
> >>> So the 'nickname' feature you request is available with a little
> >>> pre-install preparation and post-install config file editing.
> >>> 
> >>> Hope this helps -- RJ
> >> 
> >> Thanks.  It will help a lot for my own use.  However, that really
> >> needs to be included in the gui disk partitioning, so that people can
> >> find and use it.  I'm fairly sure there is no way to do that at present.
> > 
> > imho: dolphin already shows the filesystem label; but, imho, there is no
> > need to use label instead of uuid on the inside... it's not like most
> > people actually look into fstab...
> > 
> > i'm not sure, but i thought the expert had a way to change label in
> > filesystems in the partitioner. label isn't used in fstab, but i don't
> > think it should.
> 
> OK - when I partition, I do add an identifier, which may be what jpbfree
> referred to, but what I see in Dolphin is not, IMO, very helpful.  The
> shortcut added to Places shows the long number, not Win_C or anything
> like that.  Maybe this is a Dolphin fault - I don't know.
> 
> Anne

i've always seen the labels of the USB-sticks and such, and they are also just 
filesystem labels. also i've seen at least in the past also the labels of other 
filesystems that i didn't mount

Re: [Mageia-dev] Why is AHCI statically compiled into kernel?

[AL13N]

> On 07/03/13 04:38, R James wrote:
[...]
>> So the 'nickname' feature you request is available with a little
>> pre-install preparation and post-install config file editing.
>>
>> Hope this helps -- RJ
>>
> Thanks.  It will help a lot for my own use.  However, that really
> needs to be included in the gui disk partitioning, so that people can
> find and use it.  I'm fairly sure there is no way to do that at present.

imho: dolphin already shows the filesystem label; but, imho, there is no
need to use label instead of uuid on the inside... it's not like most
people actually look into fstab...

i'm not sure, but i thought the expert had a way to change label in
filesystems in the partitioner. label isn't used in fstab, but i don't
think it should.

Re: [Mageia-dev] Why is AHCI statically compiled into kernel?

[AL13N]

Op woensdag 6 maart 2013 13:46:06 schreef Anne Wilson:
> On 05/03/13 17:11, 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.
> 
> While I appreciate the intention, from a user PoV, those UUIDs mean
> b* all.  It would be really nice if, when they are first named, it
> was possible to allocate a "nickname" for want of a better term.

if you use it, filesystems also have label functionalities, which iinm are 
shown in dolphin.

Re: [Mageia-dev] Why is AHCI statically compiled into kernel?

[AL13N]

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] [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3

[AL13N]

Op zondag 3 maart 2013 11:46:06 schreef Thierry Vignaud:
>  On 3 March 2013 11:27, AL13N  wrote:
> >> > alien  4.2.1-6.mga3:
> >> > + Revision: 401170
> >> > - Fix creation of log directory
> >> 
> >> now if someone would fix libvirt/virt-manager with xen...
> > 
> > working on it, but it looks like i would need native qemu to get the best
> > results. that would mean trowing all around.
> > 
> > i am in contact with native to have better build procedure and build
> > against qemu natively, so that qemu itself can build the xen and we have
> > proper support, but it's not ready yet.
> > 
> > atm, i'm planning on holding off with that and doing this for mga4.
> > 
> > also a problem is that the qdisk driver (which is really needed if you
> > have a file image with libvirt, instead of having LVM partitions) seems
> > to have some kind of bug, in that the remote and local state don't match.
> > 
> > How far did you get? i was looking for your email, (i know you sent one),
> > but was unable to find it
> 
> as told a couple weeks ago, xl/xm top works but libvirt can't connect to
> xen: Mar 03 10:21:19 localhost libvirtd[833]: erreur interne impossible de
> se connecter à Xen
> Mar 03 10:21:19 localhost libvirtd[833]: unable to connect to
> 'localhost:8000': Connexion refusée
> Mar 03 10:21:19 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:20 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:21 localhost libvirtd[833]: this function is not
> supported by the connection driver: virConnectNumOfInterfaces
> Mar 03 10:21:49 localhost libvirtd[833]: No response from client
> 0x14423a0 after 5 keepalive messages in 30 seconds


how do you connect? on both mga2 and cauldron i was able to connect. i use 
xen+ssh://root@10.238.9.54/ . it seems you're connecting to the http 
interface? is the http interface running? that only works with xm / xend.

i didn't use the xend/xm setup. i started only xenstored and xenconsoled, 
enough to use the xl tools.

i noticed that the way i connect libvirt actually uses the xl tools, so that 
went ok.

i do had some trouble, like the log directory didn't exist, so libvirt failed 
to create a machine.

and now i have some issue with xen-blkfront and xen-netfront to get a machine 
installed... (i have a pxe installer system)

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-6.mga3

[AL13N]

Op zondag 3 maart 2013 10:40:33 schreef Thierry Vignaud:
> On 2 March 2013 23:30, alien  wrote:
> > alien  4.2.1-6.mga3:
> > + Revision: 401170
> > - Fix creation of log directory
> 
> now if someone would fix libvirt/virt-manager with xen...

working on it, but it looks like i would need native qemu to get the best 
results. that would mean trowing all around.

i am in contact with native to have better build procedure and build against 
qemu natively, so that qemu itself can build the xen and we have proper 
support, but it's not ready yet.

atm, i'm planning on holding off with that and doing this for mga4.

also a problem is that the qdisk driver (which is really needed if you have a 
file image with libvirt, instead of having LVM partitions) seems to have some 
kind of bug, in that the remote and local state don't match.

How far did you get? i was looking for your email, (i know you sent one), but 
was unable to find it

[Mageia-dev] libvirt-utils requires policykit?

[AL13N]

and gamin, making it pull in oxygen etc...

libvirt-utils is meant for dedicated servers too...

is this really required?

Re: [Mageia-dev] A question about BuildRequires and other RPM questions.

[AL13N]

Op donderdag 28 februari 2013 15:43:22 schreef Robert Wood:
> On 28/02/13 14:25, Guillaume Rousse wrote:
> > There is not much choice, beside building from a specified build
> > environment, which is usually the minimal installation for your target
> > distribution + rpmbuild. Most distributions use dedicated systems to
> > automatically deploy such clean environment before eac package build
> > attempt (iurt, mock, etc...).
> 
> So, I should maybe install a minimal install on a virtual machine? Then
> when it needs packages I can add those to the dependencies list? It
> strikes me the problem with that would be that once you've added a load
> of packages for one RPM, then started on another, you'd be back to the
> same problem as before and need to keep reinstalling Mageia for each RPM
> you do. There must be a better way than that.

i myself have made a script that uses a minimal install btrfs subvolume, makes 
a snapshots for this package, then builds the rpm in a screen session, then 
removes the snapshot again.

i use this script mostly for testbuilding on my local machine.

in the past i just submitted it to the buildsystem (to updates_testing) when i 
was done working on it, and if it failed, i added some extra buildrequires, 
until it built, after that i did a final test

> > 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.
> 
> It sounds like there is a load of trial and error then? I am sure I must
> misunderstand, building reliable RPMs must be a relatively
> straightforward thing once you're up and running surely?

trial and error for buildrequires yes, mostly for new packages, if you're 
updateing packages, you sort of know more about the package and if it has 
extra builddependencies, the BS will tell you this.

so, in short for new packages you can have some trial and error (usually no 
more than 5 or 6 tries, wrt buildrequires).

it's not such a big deal...

Re: [Mageia-dev] Bug #7633

[AL13N]

Op donderdag 28 februari 2013 11:27:14 schreef Sander Lepik:
> https://bugs.mageia.org/show_bug.cgi?id=7633
> 
> Can we do something about this bug? 80+ people in CC getting spammed
> every second day. If we can't fix it then let's drop it.

i agree

Re: [Mageia-dev] About bug 6676

[AL13N]

Op donderdag 21 februari 2013 14:04:31 schreef Pierre-Malo Deniélou:
> On 21/02/13 12:12, Dan Fandrich wrote:
> > On Thu, Feb 21, 2013 at 12:02:13PM +, Pierre-Malo Deniélou wrote:
> >> I would say that packages which autodownload non-free material should
> >> be in nonfree (like get-skype). For the same reason that free
> >> packages which Require a package in nonfree should be in nonfree.
> > 
> > But what happens when free content becomes available so that the non-free
> > download is no longer required? This is unlikely in the case of Skype,
> > but has happened with other games engines in the past.
> 
> If it becomes free, we push the newer version to the free repository.
> Fairly simple :-).
> 
> Cheers,

except that if this package is free and dependant on nonfree other package or 
content.

the moment this changes, it means that the old package becomes completely free 
without having any changes.

with games this is a possibility.

with respect to this, i would prefer it to be possible to have a gaming engine 
in free if it's free, even if there's content that is nonfree...; especially 
if it's theorethically possible for free content to be added.

it would mean that people developing free content for such a game (or starting 
such development) would not need to enable nonfree...

Re: [Mageia-dev] Package request with src.rpms

[AL13N]

Op dinsdag 19 februari 2013 15:52:08 schreef atilla ontas:
> Hi there. I merely working on zemberek and its dependencies for Mageia
> Cauldron. As a Turkish sporen guy; i'd like to see zemberek in
> repositories. Zemberek is a natural language processing library for Turkic
> languages (Turkish, Azerbaijanin, Turkmen etc.), It is written in java.
> Altough its development stalled since 2010; it is still working on Magea,
> Also zemberek is the only true Turkish spell checking app. Aspell-tr won't
> do right corrections.
> 
> Zemberek needs apache-mina < 1.8, libmatthew-java, slfj4 and dbus-java
> packages to run. While it won't work apache-mina package in official
> repositores; i decided to apache-mina-1.1.7 in zemberek-server package;
> also i patched libmatthew-java due to
> bug#9002.
> 
> Also i hava made package for Al-Anvar, a Holy Qur'an study tool.
> 
> So, if you mind to inspect, review and add to repositories those apps it
> will be awesome.
> 
> I'm willing to be a packager but have little time to work on packages due
> to my job and familiy, AItough i can not attend weekly meetings most of
> time, still is it possible? May i find a mentor?

alot of us have jobs and family and little time, even if you only maintain 
your packages, that is fine. you can contribute and find a mentor no problem.

on the mageia wiki page, there's some information on packaging and our 
policies, and there's also a page for you to put your name to find a mentor.

but, nothing stops you from already contributing if you don't have a mentor, 
you can already file bug reports for new packages, and attach your spec files 
for review. also, on #mageia-mentoring, you can always ask for questions on 
policies or packaging, even if you don't have a mentor yet.

also the meetings are public on IRC, and we have meeting logs, so if you want 
to be up2date regarding the meetings, you can read the logs. i also advise you 
to subscribe to the mageia-dev mailing list, since that one has sometimes 
crucial info on packaging.

good luck

Re: [Mageia-dev] Fail2Ban vs Blockhosts vs DenyHosts vs iptable throttle for SSH

[AL13N]

> Hello all!
>
> After reading this article:
> http://it.slashdot.org/story/13/02/16/2129244/ssh-password-gropers-are-now-trying-high-ports?utm_source=rss1.0mainlinkanon&utm_medium=feed
>
> I have been using Blockhosts (http://www.aczoom.com/blockhosts) for many
> years now without issue (I also use a certificate with passwords turned
> off) but I leave the port as standard 22
>
> I never tried the others, so not sure which is most effective . . .
>
> My question is two fold:
>
> 1) I was curious of what others use on Mageia - and your experiences
>
> 2) Should we not have something standard in the SSH config during
> install as a dependency?  Make it automatic so at least the standard
> config of ssh is a bit more protected from bot scans??

security is as strong as the weakest link.

users system is as secure as their password and by default you can't get
in as root

Re: [Mageia-dev] System doen't boot with LVM

[AL13N]

> I rebooted my laptop this morning and it failed to boot: unable to find
> my / under lvm.
>
> I did try to do a fresh cauldron result but got same result.
>
> Dracut gi a shell, It seems 'lvm vgmknodes' has no effect (the swap lv
> did existed already).
>
> BTW: lvm command seems to be missing in rescue mode.
>
> It is impossible to use an already existing encrypted partition: it said
> 'cryptsetup failed' and nothing more.

i think rescue mode has "lvm2" command

Re: [Mageia-dev] freeze push: gnutls

[AL13N]

Op maandag 11 februari 2013 19:53:06 schreef Johnny A. Solbu:
> On Monday 11. February 2013 19.48, Guillaume Rousse wrote:
> > A 'security bugfix' isn't a 'bugfix' release ?
> 
> I had the same reaction.

my second reaction was that if translated, this might very well give different 
words to these meaning, making them less related.

Re: [Mageia-dev] freeze push: perl-URPM-4.26 & urpmi-7.19

[AL13N]

Op zaterdag 9 februari 2013 22:35:47 schreef Thierry Vignaud:
> Hi
> 
> Please let in perl-URPM-4.26 & urpmi-7.19
> I got rid of playing with rpm -Uvh --oldpackage foobar*rpm libfoobarX*rpm,
> so I added basic support for --downgrade (mga#6655).
[...]

ooh, this is nice!

Re: [Mageia-dev] [RFC] rsyslog vs journalctl

[AL13N]

Op donderdag 7 februari 2013 15:10:43 schreef Guillaume Rousse:
> Le 07/02/2013 14:40, Colin Guthrie a écrit :
> > Is anyone against the name "system-logger"? If so I'll update things
> > accordingly. Other name suggestions welcome.
> 
> Fine with me.

that's fine.

i just mentioned this because iirc lennart at his talk in FOSDEM said that 
journald didn't do remote syslogging

Re: [Mageia-dev] [RFC] rsyslog vs journalctl

[AL13N]

Op donderdag 7 februari 2013 13:34:06 schreef Colin Guthrie:
> 'Twas brillig, and AL13N at 07/02/13 11:40 did gyre and gimble:
[...]
> > what about the tty12 bug? can this be fixed with journald? it seems to be
> > a feature that people don't want to lose?
> 
> Not sure. I'll find out. It should be trivial really... i.e. all it
> really needs is a journalctl -f command run on tty12. You could craft an
> agetty command that worked like that easily enough, although there may
> be something more elegant that is more efficient and cleaner.

since the tty12 "feature" is present now, it would be nice if it could still 
be there and started as soon as possible, just like before.

Re: [Mageia-dev] [RFC] rsyslog vs journalctl

[AL13N]

> 'Twas brillig, and David Walser at 06/02/13 18:28 did gyre and gimble:
[...]
> What I guess we could to to avoid putting rsyslog on the physical media
> would be to put a versioned conflicts in the main systemd package with
> rsyslog and syslog-ng. Thus the old packages should be removed when
> upgrading (AIUI).

not a really good idea imho, i have a server which uses rsyslog for
network remote syslogging... so upgrading that would break this.

what about the tty12 bug? can this be fixed with journald? it seems to be
a feature that people don't want to lose?

Re: [Mageia-dev] [RFC] rsyslog vs journalctl

[AL13N]

> 'Twas brillig, and Anne Nicolas at 06/02/13 08:43 did gyre and gimble:
>> There was a discussion yesterday evening in packager meeting about what
>> we should do with rsyslog. It's needed for upgrade from Mageia 2. But
>> journalctl is now installed by default.
>>
>> Is there some requirement for systemd ? Shall we have both installed? We
>> need an answer to deal with upgrade and isos
[...]

I'm afraid it might not be as easy as anyone would think:

1. journald does not do UDP remote syslogging, according to lennart at his
talk at FOSDEM?

==> this means old syslog shouldn't be obsoleted

2. it appears it also doesn't fill tty12 with info as rsyslog does

==> if true, and not fixable, then i would still suggest to have both.

Re: [Mageia-dev] freeze push: munin

[AL13N]

> Please push munin 2.0.11, it's a bugfix release.
> Wow, it's already done, wonderful !

:)

Re: [Mageia-dev] Packager's meeting

[AL13N]

> Hi there
>
> We will have our meeting tonight focused on release critical bugs review.
> Please have a look before on
> https://bugs.mageia.org/buglist.cgi?cmdtype=runnamed&namedcmd=release_blocker

Could we also mention that if you bump/bumped versions of dependencies,
because older ones don't work anymore, to restrict those dependencies for
those versions.

Re: [Mageia-dev] x11-driver-video-qxl/qemu/libvirt (was Re: Please remove qemu, and qemu-img from Mageia 3.)

[AL13N]

Op dinsdag 5 februari 2013 00:09:52 schreef Christiaan Welvaart:
> On Sun, 3 Feb 2013, David W. Hodgins wrote:
> > During testing of updates to qemu, and x11-driver-video-qxl,
> > it has become very clear that no-one could possibly be using
> > these packages, as they are so slow, as to be useless.
> 
> Qemu (or rather each qemu-system-*) is an emulator at its core, so
> slowness is not a huge surprise. You probably wanted to run it in (fast)
> virtualization mode - use qemu-kvm for that (and the kvm module for your
> cpu must be loaded to get virtualization working). But running qemu
> directly is tiresome, try virt-manager - it works about as well as
> virtualbox even if I need to run it as root. I use virt-manager/qemu-kvm
> to build+test mga2 updates for iceape, only graphics (spice+vmvga) is slow
> (but better than vnc+cirrus).
> 
> Unfortunately people keep updating libvirt, apparently without testing it
> - now it is broken again in cauldron. I need to kill all the qemu-system-*
> and qemu-kvm that libvirtd starts one by one before virt-manager can
> connect.
> 
> > There are many problems with xorg crashing, mouse pointer not
> > being where the pointer is shown, etc.  These bugs are described
> > in https://bugs.mageia.org/show_bug.cgi?id=8938
> 
> A month ago I updated the spice packages; I also tried to update
> x11-driver-video-qxl (which is part of spice AFAIK) but it did not work at
> all. So if you ask for *that* package to be removed, fine with me.
> 
> 
>  Christiaan

no, please,... get it working instead :-)

Re: [Mageia-dev] [Mageia-sysadm] Please remove qemu, and qemu-img from Mageia 3.

[AL13N]

Op zondag 3 februari 2013 03:45:59 schreef David W. Hodgins:
> During testing of updates to qemu, and x11-driver-video-qxl,
> it has become very clear that no-one could possibly be using
> these packages, as they are so slow, as to be useless.
> 
> Over 6 hours to do a net install of a kde x86-64 system,
> on hardware where that would normally be under 20 minutes.
> 
> There are many problems with xorg crashing, mouse pointer not
> being where the pointer is shown, etc.  These bugs are described
> in https://bugs.mageia.org/show_bug.cgi?id=8938
> 
> Please drop these useless packages, so we don't have to test
> or install security updates for them.
> 
> Thanks, Dave Hodgins


i use qemu-img to convert kvm images to vmdk

Re: [Mageia-dev] Mariadb 5.5.29?

[AL13N]

Op donderdag 31 januari 2013 19:47:59 schreef David Walser:
> FundaWang  writes:
> > Hello,
> > Would pushing mariadb 5.5.29 be a good choice? It seems that there are two
> > many security fixes in this release[1].
> > [1]: https://kb.askmonty.org/en/mariadb-5529-release-notes/
> 
> Thanks for bringing this up.  Looks like it would be good to have for Mageia
> 2 and Cauldron.

please don't i'm working on things...

i will stop at 5.5.28 for cauldron (and security patch it upwards) just like i 
done with 5.5.25 for mga1.

perhaps in the near future we might go higher, but definately not now.

there are changes in the versioning builds, which makes our versioning hacks 
fail...

this needs to be tested better; and since we're this far, i'm not planning to 
update it. (for now).

Re: [Mageia-dev] Power consumption disaster with AMD open source drivers

[AL13N]

Op woensdag 30 januari 2013 06:29:08 schreef Mustafa Muhammad:
> On 01/30/2013 02:01 AM, AL13N wrote:
> > Op woensdag 30 januari 2013 00:57:44 schreef Mustafa Muhammad:
> >> Hi, I reported a bug because open source driver for AMD cards reduced my
> >> laptops batter life to half:
> >> https://bugs.mageia.org/show_bug.cgi?id=8891
> >> Please either implement the solution (shipping two xorg-server packages
> >> and choosing from them during install), or extend the life of Mageia 2
> >> to 5 years (or at least 3), nobody can keep using Mageia to kill his
> >> battery life.
> >> I know I asked about this before but it is critical.
> >> Regards
> > 
> > I might be mistaken, but i think there is work going on to make this
> > happen... if it does, it'll need some manual intervention though...
> > 
> > (but unsure on this), we'll have to see...
> 
> Anything is OK, manual intervention or completely manual setup is OK,
> just don't leave us in the cold by only supporting xorg 1.13

i am not certain, but i believe i have heard this.
 I too suffer from this problem, even though the real problem is AMD/ATI 
behaving cruelly and not suppporting their slightly older hardware

Re: [Mageia-dev] Power consumption disaster with AMD open source drivers

[AL13N]

Op woensdag 30 januari 2013 00:57:44 schreef Mustafa Muhammad:
> Hi, I reported a bug because open source driver for AMD cards reduced my
> laptops batter life to half:
> https://bugs.mageia.org/show_bug.cgi?id=8891
> Please either implement the solution (shipping two xorg-server packages
> and choosing from them during install), or extend the life of Mageia 2
> to 5 years (or at least 3), nobody can keep using Mageia to kill his
> battery life.
> I know I asked about this before but it is critical.
> Regards

I might be mistaken, but i think there is work going on to make this happen... 
if it does, it'll need some manual intervention though...

(but unsure on this), we'll have to see...

Re: [Mageia-dev] FOSDEM - friday evening

[AL13N]

> Hi there,
>
> I will arrive in Buxelles on Friday evening.
> So anyone of you would like to have some beer and pizza with me, just
> tell me...
>
> Oliver
>

well, i'm picking up sebsebseb and coling at the airport, so i think us
three are up for that... :-)

at what time are you arriving?

Re: [Mageia-dev] [council] *ping* Media query: secure boot support

[AL13N]

> On Tue, Jan 29, 2013 at 10:02 AM, Guillaume Rousse
>  wrote:
>> Le 29/01/2013 10:37, Wolfgang Bornath a écrit :
>>
>>> As for now Microsoft requires all W8 certified systems with secure
>>> boot to allow secure boot to be switched off by user/sysadmin. One
>>> reason why I do not understand the reason why all these people (Garret
>>> et all) are stumbling all over themselves to solve a problem which is
>>> not even sure to ever come by.
>>
>> I guess that's because secure boot may be considered useful, if you're
>> in
>> control of it, of course. And because something working out of the box
>> is
>> probably better when targetting non-experts.
>
> Yes I think the main problem is that for probably 10 years it had
> became easy for someone non technical to test/install linux, now they
> would need to change setup in the bios and would probably give up (or
> be scared).
>

no 100% sure, but some time ago, i remember someone looking into this with
motherboard/PC manufacturers and it seemed like most manufacturers weren't
even planning on having secure boot / let alone enable it by default.

I suspect that most PC manufacturers are putting the win8 sticker on it
regardless of it using secure boot. and i think that most win8
preinstalled PCs won't even be able to use secure boot.

in other words... is this REALLY gonna be an issue? (except for ARM
platforms)?

i'm not 100% sure on this, but i'm not really that worried atm...

Re: [Mageia-dev] Packagers meeting

[AL13N]

> 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?

if possible, i would like to have some kind of status (planning) of bug 2317:
 - iinm it was decided to fix (was there a timeframe set?)
 - is there something anyone can help with, do we commit some patches?
 - or is it now only on tv to actually have the time to do the work?

(preferably in the beginning of the meeting)

Re: [Mageia-dev] [changelog] cauldron core/release task-obsolete-3-56.mga3

[AL13N]

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] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3

[AL13N]

Op zondag 27 januari 2013 20:45:20 schreef Pascal Terjan:
> On Sun, Jan 27, 2013 at 7:14 PM, AL13N  wrote:
> > Op zondag 27 januari 2013 17:18:01 schreef Pascal Terjan:
> >> On Sun, Jan 27, 2013 at 5:05 PM, Pascal Terjan  wrote:
> >> > On Sun, Jan 27, 2013 at 4:50 PM, AL13N  wrote:
> >> >> Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud:
> >> >>> On 27 January 2013 17:32, AL13N  wrote:
> >> >>> >> > alien  0.5.6-6.mga3:
> >> >>> >> > + Revision: 391755
> >> >>> >> > + rebuild (emptylog)
> >> >>> >> 
> >> >>> >> what for?
> >> >>> > 
> >> >>> > autobuild failed that release, but for some reason i had to bump
> >> >>> > release
> >> >>> > anyway...
> >> >>> 
> >> >>> rebuild did succeeded:
> >> >>> * Sat Jan 12 2013 umeabot  0.5.6-2.mga3
> >> >>> + Revision: 356696
> >> >>> - Mass Rebuild -
> >> >>> https://wiki.mageia.org/en/Feature:Mageia3MassRebuild
> >> >>> 
> >> >>> and it was rebuild again later.
> >> >>> 
> >> >>> You should have stopped when seeing you'd to bump release as that
> >> >>> mean
> >> >>> that previous build was successful..
> >> >>> 
> >> >>> > i donno how to fix this properly.
> >> >>> > 
> >> >>> > what should i do with revision logs?
> >> >> 
> >> >> not the mass rebuild, but on of the autobuilds kept showing lcdproc as
> >> >> failed. i had to rebuild it for it to show up properly.
> >> >> 
> >> >> it meant i had a personal entry on check.mageia.org
> >> > 
> >> > If you just rebuild it without fixing anything, it will come back next
> >> > time...
> >> 
> >> Looking at the failure logs:
> >> 
> >> gcc -fPIC -Wall  -O3 -Wno-unused-function -shared  -o hd44780.so
> >> hd44780-hd44780.o libLCD.a hd44780-hd44780-serial.o
> >> hd44780-hd44780-lis2.o hd44780-hd44780-usblcd.o hd44780-hd44780-4bit.o
> >> hd44780-hd44780-ext8bit.o hd44780-lcd_sem.o hd44780-hd44780-winamp.o
> >> hd44780-hd44780-serialLpt.o hd44780-hd44780-bwct-usb.o
> >> hd44780-hd44780-lcd2usb.o hd44780-hd44780-uss720.o
> >> hd44780-hd44780-usbtiny.o hd44780-hd44780-usb4all.o
> >> hd44780-hd44780-ftdi.o hd44780-hd44780-ethlcd.o hd44780-hd44780-i2c.o
> >> -lusb   -lftdi -lusb   libbignum.a -ldl
> >> gcc: error: libbignum.a: No such file or directory
> >> make[3]: *** [hd44780.so] Error 1
> >> make[3]: Leaving directory
> >> `/home/pterjan/rpmbuild/BUILD/lcdproc-0.5.6/server/drivers'
> >> 
> >> So in the Makefile in server/drivers, hd44780.so needs to depend on
> >> libbignum.a
> > 
> > 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...
> > 
> > but... this isn't the only driver, does this mean i'll have to change
> > dependencies for almost all these drivers?
> 
> I don't know if they use the lib :)

there are at 20ish or more of them that have that exact library in their 
respective ldadd...

i was hoping to have a easier way to make that library built before these 
drivers...

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3

[AL13N]

Op zondag 27 januari 2013 17:18:01 schreef Pascal Terjan:
> On Sun, Jan 27, 2013 at 5:05 PM, Pascal Terjan  wrote:
> > On Sun, Jan 27, 2013 at 4:50 PM, AL13N  wrote:
> >> Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud:
> >>> On 27 January 2013 17:32, AL13N  wrote:
> >>> >> > alien  0.5.6-6.mga3:
> >>> >> > + Revision: 391755
> >>> >> > + rebuild (emptylog)
> >>> >> 
> >>> >> what for?
> >>> > 
> >>> > autobuild failed that release, but for some reason i had to bump
> >>> > release
> >>> > anyway...
> >>> 
> >>> rebuild did succeeded:
> >>> * Sat Jan 12 2013 umeabot  0.5.6-2.mga3
> >>> + Revision: 356696
> >>> - Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild
> >>> 
> >>> and it was rebuild again later.
> >>> 
> >>> You should have stopped when seeing you'd to bump release as that mean
> >>> that previous build was successful..
> >>> 
> >>> > i donno how to fix this properly.
> >>> > 
> >>> > what should i do with revision logs?
> >> 
> >> not the mass rebuild, but on of the autobuilds kept showing lcdproc as
> >> failed. i had to rebuild it for it to show up properly.
> >> 
> >> it meant i had a personal entry on check.mageia.org
> > 
> > If you just rebuild it without fixing anything, it will come back next
> > time...
> Looking at the failure logs:
> 
> gcc -fPIC -Wall  -O3 -Wno-unused-function -shared  -o hd44780.so
> hd44780-hd44780.o libLCD.a hd44780-hd44780-serial.o
> hd44780-hd44780-lis2.o hd44780-hd44780-usblcd.o hd44780-hd44780-4bit.o
> hd44780-hd44780-ext8bit.o hd44780-lcd_sem.o hd44780-hd44780-winamp.o
> hd44780-hd44780-serialLpt.o hd44780-hd44780-bwct-usb.o
> hd44780-hd44780-lcd2usb.o hd44780-hd44780-uss720.o
> hd44780-hd44780-usbtiny.o hd44780-hd44780-usb4all.o
> hd44780-hd44780-ftdi.o hd44780-hd44780-ethlcd.o hd44780-hd44780-i2c.o
> -lusb   -lftdi -lusb   libbignum.a -ldl
> gcc: error: libbignum.a: No such file or directory
> make[3]: *** [hd44780.so] Error 1
> make[3]: Leaving directory
> `/home/pterjan/rpmbuild/BUILD/lcdproc-0.5.6/server/drivers'
> 
> So in the Makefile in server/drivers, hd44780.so needs to depend on
> libbignum.a



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...

but... this isn't the only driver, does this mean i'll have to change 
dependencies for almost all these drivers?

/me sighs

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3

[AL13N]

Op zondag 27 januari 2013 17:43:50 schreef Thierry Vignaud:
> On 27 January 2013 17:32, AL13N  wrote:
> >> > alien  0.5.6-6.mga3:
> >> > + Revision: 391755
> >> > + rebuild (emptylog)
> >> 
> >> what for?
> > 
> > autobuild failed that release, but for some reason i had to bump release
> > anyway...
> 
> rebuild did succeeded:
> * Sat Jan 12 2013 umeabot  0.5.6-2.mga3
> + Revision: 356696
> - Mass Rebuild - https://wiki.mageia.org/en/Feature:Mageia3MassRebuild
> 
> and it was rebuild again later.
> 
> You should have stopped when seeing you'd to bump release as that mean
> that previous build was successful..
> 
> > i donno how to fix this properly.
> > 
> > what should i do with revision logs?

not the mass rebuild, but on of the autobuilds kept showing lcdproc as failed. 
i had to rebuild it for it to show up properly.

it meant i had a personal entry on check.mageia.org

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release lcdproc-0.5.6-6.mga3

[AL13N]

Op zondag 27 januari 2013 17:05:20 schreef Thierry Vignaud:
> On 24 January 2013 00:44, alien  wrote:
> > alien  0.5.6-6.mga3:
> > + Revision: 391755
> > + rebuild (emptylog)
> 
> what for?

autobuild failed that release, but for some reason i had to bump release 
anyway...

i donno how to fix this properly.

what should i do with revision logs?

Re: [Mageia-dev] Status note

[AL13N]

> The cinnamon conflict with gnome has been fixed in the packages I
> have.  There is a patch that fixes the problem that I've sent
> upstream, and I can package it locally with the patch.

iinm you're still a novice packager, so ideally this should be
doublechecked by others(mentor) and since you might have conflicts, there
should at least be approval by the gnome packager... but well, we have
some time for that anyway, since cauldron only reopens in april.

> As far as the other packages
>
> peazip - I'm looking at getting that packaged.  It's pascal code, but
> it open source pascal code that doesn't look too bad.
>
> energytycoon - working on that
>
> openra - the problem with openra is that it seems to require closed
> source data files.  That doesn't keep us from putting it into tainted,
> but it does put it on much lower priority.  lgeneral also has that
> problem

tainted is for patented packages.
nonfree is for nonfree packages, or if they require nonfree files.

> I've looked over the package requests.  I just submitted a few Chinese
> fonts.  Mplayer2 looks interesting.
>

in the mean time while cauldron is version frozen. perhaps you can also
help to fix some of the bugs (especially if they are release critical)

also, keep in mind that new packagers are great, but even those need to be
maintained (of course, this only is for full packagers, but you can ask
your mentor to maintain them in your place and when you become full
packager to shift them to you).

Re: [Mageia-dev] Status note

[AL13N]

Op zaterdag 26 januari 2013 12:20:48 schreef Sandro CAZZANIGA:
> Le 26/01/2013 12:19, Pierre-Malo Deniélou a écrit :
> > On 26/01/13 05:58, Joseph Wang wrote:
> >> I've been avoiding checking anything into the tree so as not to
> >> interfere with the Mageia 3 release.  But I've been quite busy at
> >> working on various projects to be checked in as so as Cauldron opens
> >> up.  Most of them involve somewhat more than packaging since I've been
> >> sending patches upstream
> >> 
> >> The things that I've been working on are:
> >> 
> >> 1) Cinnamon environment.  I not only have a cinnamon environment
> >> working on my local box, but I've also created a set of packages that
> >> pull in all of the latest cinnamon themes, applets, and desklets.
> 
> Really good! Will this be in Mageia 3? :)

no, he said for Cauldron after Mageia 3 release. (unless backport, but 
cinnamon is not a leaf package, so not there either). you'll have to wait for 
at least Mageia 4 ( that is IF this package plays well with gnome and there's 
maintenance and such)

Re: [Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]

[AL13N]

> 2013/1/24 Oliver Burger :
>> Am 24.01.2013 01:11, schrieb eatdirt:
>>>
>>>
>>> Indeed. The other suggestion would be to bet a lot of Belgian beers,
>>>
>> That's an option for after dinner :D
>> See you next week for some talking and Belgian beers...
>
> I had no objections against the restaurant and the dinner in 2011.
> Location, food & drinks were ok. I did not hear or read negative
> "reviews", although I don't know what happened when the drinking
> started after Oliver and I left.

i had some negative comment, but looking back now (especially after the
difference with 2012)... it might not have been that bad.

the problem here is that i almost never go into the brussels region, and i
was of the opinion that belgian food was the best of the world.

i guess i need to exclude the brussels region from that.

it's just stupid that due to location, we're forced to eat expensive and
not the best-of-the-world food...

Re: [Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]

[AL13N]

> On 24/01/13 00:23, AL13N wrote:
>
>> This time, i had actually tried to find an option to use a good caterer
>> i know
>> well, but location proves a big issue, most places i checked didn't
>> allow
>> external catering... :-( or the price had to be right...
>
> Indeed. The other suggestion would be to bet a lot of Belgian beers,
> then nobody will pay attention any more to the food :)

that is nice!


another solution is to move FOSDEM nearer to hotel/restaurants with good
food :-)

Re: [Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]

[AL13N]

Op woensdag 23 januari 2013 21:25:16 schreef eatdirt:
> On 23/01/13 14:01, AL13N wrote:
> > sorry, i figured i was supposed to do it like last time, i'll clear the
> > wiki again.
> > 
> > I hope you can do better than what i got last year :-)
> 
> Hey buffoon !!! :)
> 
> you mean like *I did* last time, right

:)

> I reckon it was a bit shit but that's difficult to fit 25 nerds + 1 veg
> in a room ;

very true.

This time, i had actually tried to find an option to use a good caterer i know 
well, but location proves a big issue, most places i checked didn't allow 
external catering... :-( or the price had to be right...

> Looking forward to see you soon my dear!
> 
> Cheers,
> Chris.

Re: [Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]

[AL13N]

> Le 23/01/2013 13:42, AL13N a écrit :
>> I'm sorry, i have sort of forgotten to get the restaurant, i've tried
>> reserving in 3 random restaurants, i would like to ask what order you
>> prefer the ones listed:
>>
>> see https://wiki.mageia.org/en/Fosdem_2013#Dinner_Saturday_night
>>
>> i can try to look for others, but i need feedback ASAP.
>>
>
> We have some recommanded addresses. We will book it tomorrow I guess
> waiting for late registration on the wiki. BTW we have some specific
> requires from coling for it ;)


sorry, i figured i was supposed to do it like last time, i'll clear the
wiki again.

I hope you can do better than what i got last year :-)

[Mageia-dev] URGENT: FOSDEM restaurant [input needed from everyone]

[AL13N]

I'm sorry, i have sort of forgotten to get the restaurant, i've tried
reserving in 3 random restaurants, i would like to ask what order you
prefer the ones listed:

see https://wiki.mageia.org/en/Fosdem_2013#Dinner_Saturday_night

i can try to look for others, but i need feedback ASAP.

Re: [Mageia-dev] What's the point of the latest nvidia update?

[AL13N]

Op zondag 20 januari 2013 23:50:16 schreef Thomas Backlund:
> Robert Wood skrev 20.1.2013 23:16:
> > So you're saying that because v295 has been out a while you feel it's
> > stable so you're happy to have that in the official repositories? I can
> > kind of understand that, although in the case of nvidia you'd think they
> > had already done the bug fixing.
> 
> If that ever would be true...
> many times when they add support for new hardware, old support gets
> either broken or dropped...
> 
> for example going past 304.x to 310.x or higher drops hardware support
> for older hw.
> 
> > Anyway, in the case of the latest nvidia version it certainly does have
> > new features, because it supports newer cards. In this case, it's not a
> > big thing because it's relatively easy for me to install, but I would
> > think that for new users who have modern software you'd really want them
> > to have access to it. After all M2 is the latest stable release.
> 
> But yes, this is a thing we need to improve... without breaking
> anything in the process...
> 
> The best way for now to get newer drivers is to rebuild the srpm in
> cauldron and install that.

and soonish, we could have (supported) backports, so that people 
needing/wanting this can have this one, while the people with older hardware 
can keep their things working.

Re: [Mageia-dev] [RPM Groups] Final Final change for Mageia 3

[AL13N]

Is there a way to list all packages violating these? since the mass rebuild is 
done, i would think that the previous changes are now enforced.

the list for these should be small.

so, a list+maintainer could be nice

Op zondag 20 januari 2013 21:23:55 schreef Pierre-Malo Deniélou:
> Dear Packagers,
> 
> I lay before you a last (I promise) change for the rpm groups. It affect
> packages currently in System, and it is done so that there is no cost in
> terms of new strings (since we are in freeze).
> 
> - System/Configuration/Boot and Init renamed as System/Boot and Init
> - System/Configuration/Hardware disappears
> - System/Configuration/Networking renamed as System/Networking
> - System/Configuration/Other disappears
> - System/Configuration/Packaging renamed as System/Packaging
> - System/Configuration/Printing disappears
> 
> For the groups that are disappearing, the packages can be easily spread
> among the System subgroups:
> 
> - System/Base
> - System/Boot and Init
> - System/Cluster
> - System/Configuration
> - System/Fonts
> - System/Internationalization
> - System/Kernel and hardware
> - System/Libraries
> - System/Networking
> - System/Packaging
> - System/Printing
> - System/Servers
> - System/X11
> 
> I remind you that the policy is at:
> https://wiki.mageia.org/en/RPM_groups_policy#List_of_official_groups
> 
> Thanks a lot !

[Mageia-dev] pulseaudio multicast RTP sound sharing

[AL13N]

after updates, it failed to work. even thought the devices exist and it's 
being sent that way, the volume on the sender is there, and the volume on the 
receiver is 0.

[Mageia-dev] radeon opensource driver chooses 640x480

[AL13N]

after complete update,

it seems due to plymouth working, it chooses the first mode from HDMI probe 
(which seems to be 640x480 (the resolution plymouth ran on?), right before 
1920x1080.)

the old log file has 1920x1080 as first mode.

atm, i set xorg.conf fixed on full HD resolution.

Re: [Mageia-dev] how to NFS+PXE

[AL13N]

Op zondag 6 januari 2013 23:54:22 schreef AL13N:
> Op vrijdag 4 januari 2013 10:08:04 schreef AL13N:
> > Op donderdag 3 januari 2013 22:14:51 schreef AL13N:
[...]

just a reply to note that /dev/dvd does not exist, making playing DVDs in 
media players not working:

[]# ln -s /dev/sr0 /dev/dvd

i am unsure of course if this link will be there next time? is /dev on tmpfs?

did i forgot to install some packages that have udev rules in it? or is there 
something more going on? i do remember even going to deviceinfo in MCC, so... 
i would expect that at least to tell me what would need to be installed...

Re: [Mageia-dev] What's the point of the latest nvidia update?

[AL13N]

Op zaterdag 19 januari 2013 17:59:32 schreef Claire Robinson:
> On 19/01/13 17:52, Juan Luis Baptiste wrote:
> > On Sat, Jan 19, 2013 at 9:44 AM, AL13N  wrote:
> >> if for mga2 you want a newer driver you should ask for a backport
> >> request, ie: to have 310 on mga2 as well.
> >> 
> >> plz file such requests at https://bugs.mageia.org/
> > 
> > This means that backports at last are opened ??
> 
> http://is.gd/RPG8NO

this blocks backports, but this has been decided to fix soon-ish.

so, soon backports is opened (hopefully), but perhaps sooner if there are more 
backport requests.

be advised that asking for a backport means you in combination with maintainer 
will have make sure you have at least 2 people (i586/x86_64) who can QA test 
it for QA validation. (since we could use more help on QA when we're opening 
backports).

i think your request is a sensible one and hope you're willing to help out to 
get it into mga2.

I would advise you if you find those people to state so in the bug report.

The, hopefully that bug will be finished and backports will be opened.

Re: [Mageia-dev] php packages failing to build

[AL13N]

Is anything used by something else?

Do most of them have replacements or are obsoleted by others?

php-bcompiler ... iirc, i donno if there is a replacement for this
php-archive ... sounds like it's obsoleted by others
php-xslcache ... is this obsolete too?
php-gtk2 ... is there a php-gtk3
php-tdb ... this might be used for samba stuff

and:

php-perl & php-python <--- WTF?

Op zaterdag 19 januari 2013 09:26:35 schreef Thomas Spuhler:
> The following packages don't build anymore.
> The php-5.4(zend) patches have been applied, but there are a lot of other
> issues. All of them haven't seen any upstream activities fir 2 years.
> 
> I propose to move them to obsoletes if nobody complains or steps I will do
> it early next week:
> 
> php-archive
> php-bcompiler
> php-colorer
> php-courierauth
> php-ecasound
> php-event
> php-filepro
> php-framegrab
> php-funcall
> php-gtk2
> php-mcache
> php-mnogosearch
> php-perl
> php-ps
> php-python
> php-syck
> php-tcpwrap
> php-tdb
> php-teng
> php-tk
> php-xslcache
> php-yp

Re: [Mageia-dev] What's the point of the latest nvidia update?

[AL13N]

Op zaterdag 19 januari 2013 10:51:21 schreef Robert Wood:
> I have a modern nvidia graphics card on my desktop that necessittated
> having to get the very latest nvidia driver from the nvidia site and
> manually install.
> 
> So, when we had a nvidia pakcage update on my laptop, I thought I'd give
> the Mageia package another go, but it makes sack-all difference, it
> still just sits there doing nothing and says:
> 
> Failed to start Wait for Plymouth Boot Screen to Quit
> 
> So I went and looked on my laptop and it looks like it's v 295.49
> whereas the very latest version is 304.43. I need this for my modern
> graphics card or the desktop refuses to boot. So, why bother with
> v295.49 when there's a much more modern one?
> 
> **

for mga2, the driver update (meaning no new functionality, just bugfixes is 
295)

for mga3 (beta1) the latest driver is atm 310...

if for mga2 you want a newer driver you should ask for a backport request, ie: 
to have 310 on mga2 as well.

plz file such requests at https://bugs.mageia.org/

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-2.mga3

[AL13N]

Op vrijdag 18 januari 2013 17:14:28 schreef Thierry Vignaud:
> On 16 January 2013 21:02, AL13N  wrote:
> > i was planning on removing xm and xend support.
> > 
> > perhaps closer should be to find out what libvirtd isn't working?
> > 
> > of course, i did ask to maintain this, but it isn't easy for me to
> > actually
> > test it :-(. i had planned to test this at work, but other work has made
> > me
> > unable to actually run it for a while...
> > 
> > anyway, i had to patch some stuff about xenconsole, but maybe i should
> > take a closer look into what other patches fedora has. well, i should at
> > least try to find some hardware i can use for this.
> > 
> > also, i had planned on dropping internal qemu, but it upstream told me to
> > wait for the next major version.
> > 
> > if anyone can help me out with xen, i'd appreciate it.
> > 
> > @tv:
> >  - did you manually make another boot entry in grub with the hypervisor as
> > 
> > kernel and the kernel as module and the initrd as another module? (that is
> > necessary)
> 
> no since that's automatic with grub2
> 
> >  - could you check if the xl command does work?
> 
> "xl list" works but not libvirt users
> 
> >  - could you possibly give logs for libvirtd (and maybe do: 'systemctl
> >  list-
> > 
> > units' ?)
> > 
> > thanks a bunch
> 
> [root@localhost ~]# service libvirtd status
> Redirecting to /bin/systemctl status libvirtd.service
> libvirtd.service - Virtualization daemon
>   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
> Active: active (running) since Fri, 2013-01-18 16:56:53 CET; 12min ago Main
> PID: 867 (libvirtd)
>   CGroup: name=systemd:/system/libvirtd.service
>   ├  867 /usr/sbin/libvirtd
>   └ 1214 dnsmasq
> --conf-file=/var/lib/libvirt/dnsmasq/default.conf
> 
> Jan 18 17:01:28 localhost libvirtd[867]: Unable to issue hypervisor
> ioctl 3166208: Permission non accordée
> Jan 18 17:01:28 localhost libvirtd[867]: Unable to issue hypervisor
> ioctl 3166208: Permission non accordée
> Jan 18 17:01:28 localhost libvirtd[867]: Unable to issue hypervisor
> ioctl 3166208: Permission non accordée
> Jan 18 17:01:28 localhost libvirtd[867]: Unable to issue hypervisor
> ioctl 3166208: Permission non accordée
> Jan 18 17:01:28 localhost libvirtd[867]: erreur interne impossible de
> se connecter à Xen
> Jan 18 17:01:28 localhost libvirtd[867]: unable to connect to
> 'localhost:8000': Connexion refusée
> Jan 18 17:01:58 localhost libvirtd[867]: No response from client
> 0x8ec290 after 5 keepalive messages in ...conds
> Jan 18 17:04:53 localhost libvirtd[867]: erreur interne impossible de
> se connecter à Xen
> Jan 18 17:04:53 localhost libvirtd[867]: unable to connect to
> 'localhost:8000': Connexion refusée
> Jan 18 17:04:53 localhost libvirtd[867]: End of file while reading
> data: Erreur d'entrée/sortie
> 
> # systemctl list-units|grep xen
[..]

perhaps libvirtd cannot connect because of some kind of thing not being being 
enabled... i would like to see more of the libvirtd log, from the beginning... 
it seems like there's more earlier logs.

also, perhaps libvirtd might be trying to connect to the server as if it were 
a kvm server... so need more logs and possibly config files.

with xl, can you actually start a VM (para/hvm), that you can get into with 
the xenconsole?

I might soon get a test system meant for virtualisation for personal use 
later... i plan on doing a complete test with it. and try to enable kvm and 
xen at the same time /o\ if that would be possible... (i doubt it)

Re: [Mageia-dev] Missign rebuilds tagged mga1

[AL13N]

Op woensdag 16 januari 2013 22:33:10 schreef Johnny A. Solbu:
> On Wednesday 16. January 2013 21.22, AL13N wrote:
> > you can look at the logfile if it mentions HIT_AFTER_FAIL
> > (which means it gets you cache after it failed)
> 
> # grep -i HIT_AFTER_FAIL /var/log/urpmi-proxy.log |wc -l
> 0
> 
> So that's not the issue. :-)=

then it looks like you're up2date after all...

Re: [Mageia-dev] Missign rebuilds tagged mga1

[AL13N]

Op woensdag 16 januari 2013 21:22:22 schreef Colin Guthrie:
> 'Twas brillig, and AL13N at 16/01/13 20:22 did gyre and gimble:
> > Op dinsdag 15 januari 2013 12:32:27 schreef Johnny A. Solbu:
> >> On Tuesday 15. January 2013 11.43, Colin Guthrie wrote:
> >>> Sounds like one of your media couldn't be updated or something. Not
> >>> directly related to urpmi-proxy per-se but it could certainly confuse
> >>> the issue :)
> >> 
> >> Just for good measure, I ran «urpmi.upfdate -a» just now, and the count
> >> didnt change. No media where unable to update, and I only have one repo
> >> configured. (http://ftp-stud.hs-esslingen.de/pub/Mirrors)
> > 
> > just mentioning, that the disadvantage to urpmi-proxy, is that it hides
> > connection errors to repositories, since it will use cache if it fails.
> > you
> > can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets
> > you cache after it failed)
> > 
> > lately, i've been testing with 2 repositories and changing the timeout
> > value to very low values (5s)
> > 
> > as first repos, i choose one that is fast, and as second repos, i use what
> > is always up2date. considering MD5SUM would be asked for both
> > repositories (it's a specially configured file for that), it would get
> > you always up2date results, since the first would fail to have the file
> > and the second one would be asked for it.
> > 
> > for me, this gave alot better results especially for cauldron during the
> > mass rebuild...
> 
> Interesting idea. Never thought about using two mirrors in the config.
> 
> I fought with urpmi-proxy today for a while. No matter what I tried,
> when downloading a synthesis via the proxy it always ended up too small
> and with md5sum failures. Requesting the same file direct from the
> mirrors worked every time. I noticed that the file never ended up in the
> cache tree, just in the tmp dir. Time wasn't on my side, so I didn't
> debug further... one to fight another day.
> 
> (this is with urpmi-proxy-0.3.2-1.mga2 on mga2 FWIW)
> 
> 
> Col

so, either a partial file, or out of disk space? better make sure the cache 
tree is the same partition as the tmp dir it uses.

in any case, using multiple mirrors isn't supported...

(yet)

i'm just trying them out this way.

i had alot of troubles with cauldron due to mismatches with MD5SUM and the 
synthesis files, because the MD5SUM doesn't match the synthesis files

but, sometimes, i do have some oddness in files (i think maybe i need better 
error-checking) like if you get a partial result, it doesn't get removed from 
cache. so if it does fail, i delete the file from the cache tree for now.

don't forget to do that in all your cascading urpmi-proxy's...

i actually have tested 3 cascading urpmi-proxy's.

in normal usage, i have an urpmi-proxy at my local lan. one at my desktop 
itself, and then once i tested urpmi-proxy in a VM on my desktop.

the one on my desktop has an "extra" repository (and changes which ones are 
default), and the one on the server has now 2 sources (http mirrors), with 
very small timeouts (i may have used 3 or 5 seconds)

since i have an urpmi-proxy at work, my work-laptop had always 2 sources which 
i uncommented constantly, but perhaps i should actually set them both, with 
very small timeouts... maybe with a 3rd slow one?

/me continues to ponder

Re: [Mageia-dev] Missign rebuilds tagged mga1

[AL13N]

Op dinsdag 15 januari 2013 12:32:27 schreef Johnny A. Solbu:
> On Tuesday 15. January 2013 11.43, Colin Guthrie wrote:
> > Sounds like one of your media couldn't be updated or something. Not
> > directly related to urpmi-proxy per-se but it could certainly confuse
> > the issue :)
> 
> Just for good measure, I ran «urpmi.upfdate -a» just now, and the count
> didnt change. No media where unable to update, and I only have one repo
> configured. (http://ftp-stud.hs-esslingen.de/pub/Mirrors)

just mentioning, that the disadvantage to urpmi-proxy, is that it hides 
connection errors to repositories, since it will use cache if it fails. you 
can look at the logfile if it mentions HIT_AFTER_FAIL (which means it gets you 
cache after it failed)

lately, i've been testing with 2 repositories and changing the timeout value 
to very low values (5s)

as first repos, i choose one that is fast, and as second repos, i use what is 
always up2date. considering MD5SUM would be asked for both repositories (it's 
a specially configured file for that), it would get you always up2date results, 
since the first would fail to have the file and the second one would be asked 
for it.

for me, this gave alot better results especially for cauldron during the mass 
rebuild...

Re: [Mageia-dev] Unable to complete update rtkit package and system failure

[AL13N]

Op donderdag 17 januari 2013 01:23:12 schreef Kira:
> 在 Thu, 17 Jan 2013 00:49:01 +0800, Johnny A. Solbu 寫道:
> > On Wednesday 16. January 2013 16.29, Kira wrote:
> >> Today I use the power button to force shutdown and boot,
> > 
> > I used to do that too, untill I stumbled across a tip about the SysRq
> > key.
> > http://en.wikipedia.org/wiki/Magic_SysRq_key#Uses
> > 
> > Now I only use the power button when the SysRq sequence ain't working.
> 
> In my cases, all system hotkey don't work. I have tried Ctrl+Alt+Backspace.
> 
> X won't restart. Maybe this should be noted with further testing.

iinm Ctrl+Alt+Backspace is now disabled by default in X?

in any case SysReq keys are quite different, they work directly in kernel, so 
you could try that...

Re: [Mageia-dev] Features

[AL13N]

Op woensdag 16 januari 2013 17:43:36 schreef Thomas Backlund:
> Colin Guthrie skrev 16.1.2013 17:34:
> > 'Twas brillig, and mustafaa1...@yahoo.com at 16/01/13 15:18 did gyre and
> > 
> > gimble:
> >> On Tuesday, January 15, 2013 05:56:34 PM Mustafa Muhammad wrote:
> >>> On 01/15/2013 03:42 PM, Thomas Backlund wrote:
>  Mustafaa Al-Hamdaani skrev 15.1.2013 14:35:
> > Hi,
> > Are features still accepted for Mageia 3? I have these three:
> > 1) Enable vertical two finger scrolling by default, simple but
> > important.
> > 2) Desktop greeter (like kaptan of pardus or its fork for Chakra,
> > kapudan):
> > http://www.chakra-linux.org/wiki/index.php/Kapudan
> > 3) catalyst-legacy for AMD cards 4xxx and before.
>  
>  This one depends on AMD.
>  They have not released any legacy driver since 12.6 last summer,
>  and that is not supporting x11-server 1.13 we use.
> >>> 
> >>> I know, I just hoped we can ship x11-server 1.12 and 1.13 and only one
> >>> of them is installed, the power consumption with the open source drivers
> >>> is just insane, especially for a laptop (and the quality too).
> >> 
> >> I asked yesterday and the answer was "too late", but if this is
> >> technically
> >> possible, I think it will make a huge difference for a big number of
> >> Mageia
> >> users, maybe 25% of all users use those AMD cards, so please would you
> >> reconsider shipping catalyst-legacy if it is technically feasible.
> >> For such a benefit for the community, I think it worth considering (from
> >> catalyst maintainer and others).
> > 
> > Being realistic, shipping two x servers is simply not going to happen in
> > time.
> 
> or ever...
> 
> > It'll need lots of extra work including more h/w detection and automatic
> > installation of the legacy x server (assuming the user wants the
> > proprietary drivers only, the free drivers will of course want the
> > latest xserver instead).
> > 
> > I feel it's just too much complication at this late stage to do this.
> 
> There is way too much stuff integrated / interacting with x11-server,
> to sanely provide 2 of them without introducing regressions on
> either side...
> 
> > Perhaps someone can do some clever edits on the binaries to make them
> > work with the newer xserver...
> 
> Nope. No can do... that would violate the license.

it's sad, i too have one that's just not supported by AMD anymore, but that's 
simply the way it is... AMD doesn't think 3y old hardware needs to be 
supported, you need to buy new stuff instead... :-(

i found it annoying, but ah well, i'm just running it with open source driver 
on my media center, and at least the video performence is adequate...

Re: [Mageia-dev] [changelog] [RPM] cauldron core/release xen-4.2.1-2.mga3

[AL13N]

Op woensdag 16 januari 2013 10:06:19 schreef Colin Guthrie:
> 'Twas brillig, and Colin Guthrie at 16/01/13 09:53 did gyre and gimble:
> > Cool, so I had this still on my list to check. Seems the "fix" (which
> > was just ghosting the files) wasn't correct and as I mentioned in a
> > previous mail about tmpfiles stuff, it would be wise to check the Xen
> > package to see what was done about adding tmpfiles support.
> > 
> > AL13n reckoned that fedora just ghosted the files, but on closer
> > inspection they do also add tmpfiles support...
> > 
> > http://pkgs.fedoraproject.org/cgit/xen.git/tree/tmpfiles.d.xen.conf
> > 
> > I'll fix it up.
> 
> Should be fixed by:
> http://svnweb.mageia.org/packages?view=revision&revision=388627
> 
> (assuming that the error really was about that file :D)
> 
> Col

i kind of doubt it, it looks more like xc isn't available (xenconsole?) 
(thanks anyway, colin :-) )

btw: @tv, any reason why you're using xend? the xl toolchain doesn't require 
xend at all.

i was planning on removing xm and xend support.

perhaps closer should be to find out what libvirtd isn't working?

of course, i did ask to maintain this, but it isn't easy for me to actually 
test it :-(. i had planned to test this at work, but other work has made me 
unable to actually run it for a while...

anyway, i had to patch some stuff about xenconsole, but maybe i should take a 
closer look into what other patches fedora has. well, i should at least try to 
find some hardware i can use for this.

also, i had planned on dropping internal qemu, but it upstream told me to wait 
for the next major version.

if anyone can help me out with xen, i'd appreciate it.


@tv:
 - did you manually make another boot entry in grub with the hypervisor as 
kernel and the kernel as module and the initrd as another module? (that is 
necessary)
 - could you check if the xl command does work?
 - could you possibly give logs for libvirtd (and maybe do: 'systemctl list-
units' ?)

thanks a bunch

Re: [Mageia-dev] GRUB can't see HD from chroot unless parent /dev is bind-mounted in chroot ?

[AL13N]

Op woensdag 16 januari 2013 11:30:27 schreef Liam R E Quin:
> On Wed, 2013-01-16 at 16:24 +, Colin Guthrie wrote:
> > Personally I've been bind mounting /dev, /proc and /sys for years
> > whenever doing any rescuecd etc. stuff. Partly because I have several
> > LVM volumes where a static /dev/ wouldn't help anyway...
> > 
> > But bind mounting /dev has just been part of my chroot routine for as
> > long as I remember.
> 
> Knowing about this would have saved me several days after trying to
> install the mageia beta (I now have it running with the
> 3.6.5-tmb-desktop-3.mga3 kernel as the 3.8 one is broken without a fix
> to the recursive panic problem, which is fixed upstream). It's not
> obvious to people who don't do it often :-)
> 
> Why not add a command to the rescue disk,
> bind-mount dir - mount /dev, /proc and /sys as /dir/dev etc for chroot
> 
> Liam

because in fact, it's not really the correct solution (and there's multiple 
solutions for this too)

A) mount --bind solution (in fact, only /dev is required) ; mount /proc and 
/sys can be done inside.
B) in fact, udev people told us for a while now, you'd better just run udev 
inside the chroot, instead of mount --bind 'ing it.
C) of course, udev is not inside systemd, so it appears the new way is now to 
somehow spawn a systemd process inside the chroot (maybe systemd-nspawn?)

oh well, rescuing is for advanced users, so i don't really see the need here. 
rescue should be as small as possible anyway.

i have no clue how you'd be successfull without binding; i didn't think disk 
devices were statically made anyway, at least not sdX.

Re: [Mageia-dev] Help needed: rpmlint checks not working

[AL13N]

Op zondag 13 januari 2013 13:26:51 schreef Colin Guthrie:
[...]
> Ghosting achieves very little in this case. Does xen automatically
> create those directories happily without the need for tmpfiles? If so
> I'd personally not package them at all (as it just continues to show up
> in the list generated by the urpmf command listed earlier as a false
> positive).
> 
> While ghosting does have the advantage that rpm -qf will return sort of
> valid results, it does make this transition period more difficult as it
> would mean our "list of packages" would never get smaller.
> 
> I'm also not totally convinced that the rpm -qf use case is benefitial
> enough to keep package %files+%ghosts synced with tmpfiles contents,
> especially as the tmpfiles become part of the upstream package.
> 
> If it could somehow become automated (i.e. via a packaging script) then
> I'd be happy to support that.
> 
> So, question. Does xen actually work? There appears to be no tmpfiles in
> it and thus I don't see what creates those folders unless xen does it
> internally (i.e. like gdm does).
> 
> Can you confirm it's OK without tmpfiles and I'll manually filter it out
> of my urpmf command. If you also feel there is no real point in ghosting
> here specifically and not in any of the other packages, please do remove
> the ghosts as it'll save that manual filtering.

thanks, i'll take this under advisement

Re: [Mageia-dev] Help needed: rpmlint checks not working

[AL13N]

Op zaterdag 12 januari 2013 22:24:35 schreef AL13N:
> Op zaterdag 12 januari 2013 16:43:09 schreef Colin Guthrie:
> [..]
> 
> > There are currently ~70 ish packages to fix. I'll fix them up, but help
> > is welcome :)
> 
> [...]
> 
> > Then there are the udev rules :)
> 
> [...]
> 
> > I will do all of these but as I've said already, people are more than
> > welcome to fix some up :D
> > 
> > Col
> 
> i'll try and fix xen for both

it seems for xen, it doesn't seem so standard. fedora ghosted those 3, so i 
did that too.

no idea what to do with the udev parts, what is wrong with it?