Re: [Mageia-dev] Freeze Push: xlog
On Friday 8. March 2013 20.39, Barry Jackson wrote: > Please push xlog > New version released a few days ago - builds/tests OK. I think you forgot to upload the new tarball. (mgarepo sync) And I think the idea is that you need to explain why a new version needs to be pushed during a Version freeze. A new version by itself is not a good reason. :-)= -- Johnny A. Solbu PGP key ID: 0xFA687324 signature.asc Description: This is a digitally signed message part.
[Mageia-dev] Freeze Push: xlog
Please push xlog New version released a few days ago - builds/tests OK. Thanks
Re: [Mageia-dev] Freeze push: calibre
Le 08/03/2013 17:19, Damien Lallement a écrit : Please submit calibre 0.9.22 (now: 0.9.17) - new drivers for new devices (Tolino, Iriver, C4 Touch, Trekstor - support new features of the Kobo firmware 2.3.1 & 2.4.0 - bug fixes on: - conversion - book polishing - epub, pdf and azw3 output - broken downloading of images in gif format - fix regression on template editor - ... - new news sources Done. -- BOFH excuse #374: It's the InterNIC's fault.
Re: [Mageia-dev] Freeze push: darktable
Le 08/03/2013 18:07, Damien Lallement a écrit : Please submit dartable 1.1.3 (1.1.1 for now): It a bug fix release and also it adds support for a lot of new camera http://www.darktable.org/2013/01/released-darktable-1-1-2/ and http://www.darktable.org/2013/02/released-1-1-3/ Done. -- BOFH excuse #89: Electromagnetic energy loss
[Mageia-dev] freeze push: perl-TAP-Harness-JUnit
Bugfix release. -- BOFH excuse #347: The rubber band broke
[Mageia-dev] Freeze push: darktable
Please submit dartable 1.1.3 (1.1.1 for now): It a bug fix release and also it adds support for a lot of new camera http://www.darktable.org/2013/01/released-darktable-1-1-2/ and http://www.darktable.org/2013/02/released-1-1-3/ Thanks! -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
[Mageia-dev] Freeze push: calibre
Please submit calibre 0.9.22 (now: 0.9.17) - new drivers for new devices (Tolino, Iriver, C4 Touch, Trekstor - support new features of the Kobo firmware 2.3.1 & 2.4.0 - bug fixes on: - conversion - book polishing - epub, pdf and azw3 output - broken downloading of images in gif format - fix regression on template editor - ... - new news sources Thanks! -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
[Mageia-dev] Please help testing nvidia on Mageia 2 with older cards
Hi If you have any of the older nvidia cards listed here: https://bugs.mageia.org/show_bug.cgi?id=7902#c31 Could you please help by testing an update candidate for ldetect-lst and the two older drivers. Update ldetect-lst can be found in Core Updates Testing and the nvidia drivers are both in Nonfree Updates Testing. You will need to be able to update from the testing medias https://wiki.mageia.org/en/Enabling_the_Testing_media#Enable_them_the_easy_way and then enable them only to update the packages listed on the bug report, it will probably ask you to update rpmdrake first which is safe to do (we've been using it in QA for a few months). When you've updated only the packages listed on the bug please disable the two Testing medias again. Please leave any comments on the bug report, include information on the graphics card installed and whether you tested with an x86_64 or i586 installation. Many thanks Claire (MrsB)
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
> 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
> 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] A question about BuildRequires and other RPM questions.
On 08/03/13 11:18, Robert Wood wrote: > Even as a programmer/electronics engineer (admittedly down at an > embedded level most of the time) some of this is going so far over my > head, it's a vapour trail in the sky. > > There are far too many acronyms of stuff I've not come across, for me to > even get the vaguest grasp of what's been talked about. > > I'm not sure what the answer is really, I thought maybe a you tube > tutorial might be a good idea, but even then, how do you know what level > to talk down to. > > No idea, for example. what iurt, mock are or do; how to make a minimal > install and keep making the system go back to minimal install when > creating the next RPM; what a btrfs subvolume is and other things. > > 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. > > 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? There is a great mentoring programme Robert and we're always short of packagers. Have a read here and find yourself a mentor: https://wiki.mageia.org/en/Becoming_a_Mageia_Packager Claire
Re: [Mageia-dev] A question about BuildRequires and other RPM questions.
Even as a programmer/electronics engineer (admittedly down at an embedded level most of the time) some of this is going so far over my head, it's a vapour trail in the sky. There are far too many acronyms of stuff I've not come across, for me to even get the vaguest grasp of what's been talked about. I'm not sure what the answer is really, I thought maybe a you tube tutorial might be a good idea, but even then, how do you know what level to talk down to. No idea, for example. what iurt, mock are or do; how to make a minimal install and keep making the system go back to minimal install when creating the next RPM; what a btrfs subvolume is and other things. 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. 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? On 28/02/13 21:18, Dan Fandrich wrote: On Thu, Feb 28, 2013 at 03:25:41PM +0100, Guillaume Rousse wrote: Build dependencies are usually specified in installation instructions. For humans, of course. You may also try to parse the outpout of ./configure (or equivalent) script. In both case, there is not garanty then every build dependency will get specified. The other way is to work backwards by looking at the install dependencies that rpmbuild discovered, or the NEEDED lines from objdump -x, and adding the -devel versions of those libraries. That won't catch any compile-time-only dependencies, though (like libtool, autoconf or flex) but it will give you something to start from. Note also that some programs will automatically discover what optional libraries are available at build time and configure themselves accordingly. So, if you miss some BuildRequires, you might end up with a binary that works but is missing features. Dan
Re: [Mageia-dev] Why is AHCI statically compiled into kernel?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/03/13 19:14, AL13N wrote: > 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 > Interestingly, USB sticks etc. do show their labels in Dolphin. I wonder why the Windows partition behaves differently? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE5s2gACgkQj93fyh4cnBeq7gCeIQoBItot1tIX1OrU5cwZa9wa 6mYAoIEDWNbDIL/3ddluGrkIlneITipv =DuyK -END PGP SIGNATURE-
