Re: [Mageia-dev] Network issue with pm-suspend
> Hi, > > To move between my home and work I swith off my computer using > pm-suspend. > > But when I wake up my laptop, the network is not reset so previous IP > and route remain (on both ethernet and wifi card). > > Pluging and unpluging the ethernet cable has no action and even an > ifconfig down / ifconfig up does not make the ethernet sending a dhcp > request. > > Am I the only one to have sucj issue ? Any idea about this issue ? on my worklaptop (mga2) i use suspend-to-disk, and after i have my screensaver, it seems to hang and take quite a while before the screensaver actually moves... (1min)? by that time, the network is down and after a little while after i log in, the wifi comes up with the new wifi connection... or did you use suspend-to-memory? (i used that too, for smaller times, but haven't switched locations in between suspends)
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release kernel-3.5.0-1.mga3
> On 28 July 2012 05:11, tmb wrote: >> tmb 3.5.0-1.mga3: >> + Revision: 275103 >> - fix perf build with glibc-2.16 >> - fix unionfs build with 3.5 series kernels >> - rediff mrproper patch >> - update defconfigs >> - drop merged patches >> - rediff unionfs patch >> - add include/memory/ to -devel and -source filelists >> - update to 3.5 > > Could you enable fontswap & zcache please? > Thx > also, not directly related, btrfs.fsck doesn't have a -a option, which means it's not executed at boot time, if needed...
Re: [Mageia-dev] Packagers meeting
> On 27 June 2012 08:11, AL13N wrote: >>> Our meeting will happen tomorrow evening at 19hUTC. Here are the >>> proposed topics: >>> >>> - pending security updates >>> - Mageia 3 features >>> - Backports policy >>> >>> For the 2 last topics please read following links *before* meeting: >>> >>> https://www.mageia.org/pipermail/mageia-dev/2012-June/016819.html >>> https://www.mageia.org/pipermail/mageia-dev/2012-June/016855.html >>> >>> Cheers >> >> can we have another talk of bug 2317? to find people willing to make a >> new >> patch that's quite more complex? >> >> ideally bug 2317 should be fixed before backports opens > > No, it's not related since you can't garanty that every user will get the > update > prior to use backports. > So there's no need to rush... > QA team told me that it would increase their workload dramatically, so i think there is need rush.
Re: [Mageia-dev] bug 2317 revisited: --update option should behave like --search-media
> 21.06.2012 13:35, AL13N kirjutas: >> B. fetch dependencies only from enabled repositories >> Problems: >> - if backports are enabled, dependencies could come from backports >> instead of release. >> >> Solutions for this: >> - this can be prevented in various ways: even as simple as the backport >> packager to bump an update with stricter requires so that the backport >> wouldn't be fetched (_IF_ it indeed would be incompatible) AND the >> update >> could have stricter requires for that new dependency. > I still can't see how are you going to solve this case: > I have backports enabled. There are packages that are newer than the one > in release. I > haven't installed them. Now new update requires such package that is both > in release and in > backports. Update will pull package from enabled backports as they are > newer - i didn't want > that. And you can't just submit new backport that blocks it. Older > backports are still > there. So you can install those if new backport doesn't work for you (the > same we have for > updates at the moment). IF the update cannot work with the backported new dependency, it should be strict required in the update. in that case, the one from release will be used. if the update does work with the backport, then i don't see why you wouldn't want that, since you enabled backports. ==> this sounds like cherry-picking backports. in other words, you're advanced enough to find out what you want, because i don't think we can support all forms of cherry-picking backports.
[Mageia-dev] Freeze push: task-lamp
task-lamp requires mysql I've changed it to mariadb instead (and added the mariadb-extra on task-lamp- extra as well (there was no mysql-extra))
Re: [Mageia-dev] Mageia 2 LiveCD contents...
Op zaterdag 05 mei 2012 07:37:12 schreef Mika Laitio: > On 05/02/2012 12:28 AM, David Walser wrote: > > Pascal Terjan wrote: > >> On Mon, Apr 30, 2012 at 19:42, John wrote: > >>> On Mon, 30 Apr 2012 17:59:13 +0200 > >>> > >>> zezinho wrote: > Em 30-04-2012 16:28, Thomas Backlund escreveu: > > tvtime can be removed, as analog tv is going away almost everywhere. > >>> > >>> Everywhere is exactly where? > >> > >> Luxembourg, the Netherlands, Finland, Andorra, Sweden, Switzerland, > >> Belgium, Germany, the United States, Norway, Denmark, Spain, Latvia, > >> Estonia, Slovenia, Israel, Austria, Monaco, UK, Cyprus, Japan, Malta, > >> France, Czech Republic, Arab World, Serbia, Canada, Brazil. > >> Australia is doing it region by region. > >> > >> http://en.wikipedia.org/wiki/Analog_television#Transition_to_digital_bro > >> adcasts > > > > tvtime is used for more than analog broadcast TV, so this is irrelevant. > > It probably doesn't need to be on the LiveCDs anyway, however. > > I agree, no need for being in livecd. > But I for example need tvtime for being able to connect Wii to > same display with my computer. > > My display does not have Wii compatible input connection, so I have > connected my Wii to Technotrends dvb-t ff card on my computer > and then I use tvtime for showing up the wii screen in my desktop. > > Mika ok, but is this something you will do with a livecd? i think you will install it, if it comes to this...
Re: [Mageia-dev] kernel-3.3.3 and wifi problems
Op dinsdag 01 mei 2012 23:23:29 schreef zezinho: > Em 01-05-2012 23:10, Maarten Vanraes escreveu: > > perhaps it can be made into a module option? > > If it detects unusable networks, I understand they don't want to care > upstream but, is it really unusable? isn't it just very slow? besides, from a viewpoint of wifi detection and traffic capture, it sounds reasonable to me.
Re: [Mageia-dev] kernel-3.3.3 and wifi problems
Op dinsdag 01 mei 2012 22:38:44 schreef simple w8: > 2012/5/1 Colin Guthrie : > > 'Twas brillig, and simple w8 at 01/05/12 14:38 did gyre and gimble: > >>> > Anyway, checking commit logs between upstream 3.3.1 and 3.3.3 > >>> > shows one commit that specifically touches the module you use... > >>> > > >>> > So can you try kernel-3.3.4-1.1.mga2 from: > >>> > http://tmb.mine.nu/Mageia/Cauldron/bugs/3.3.4-rtlwifi-revert/ > >>> > http://tmb2.mine.nu/Mageia/Cauldron/bugs/3.3.4-rtlwifi-revert/ > >>> > > >>> > If that works, you can ping upstream that: > >>> > http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=c > >>> > ommit;h=eb641120479de7ee703fabb5e6ee0ec7947474ba > >>> > > >>> > broke your wireless. > >> > >> In fact with this kernel the machine is able to detect the same wifi > >> networks that sued to detect with kernel-3.3.1... > > > > Well that means that the commit listed above is problematic. > > > > You should tell the upstream folks about this as Thomas stated. Please > > confirm when you've done this so the issue can be tracked accordingly. > > I have been discussing this with Larry Finger (one of the realtek main > developers) in "wireless " ML and this > Larry Finger what he said: > > "That patch keeps your device from running forever at a maximum of 1 > Mbps by adjusting the initial gain of the RX amplifier. You may > reverse it if you want so that you can detect more APs when you scan; > however, most people prefer to get better performance from the device. > That patch will not be reversed." perhaps it can be made into a module option?
[Mageia-dev] advisories for rpmdrake
this bug report has been lying around for too long: https://bugs.mageia.org/show_bug.cgi?id=2223 ( rpmdrake doesn't show advisories) apparently it's pretty easy and the descriptions file just needs to be modified by the people who push the update. (is this sysadmin?) i think we just need to put this in the policy and have the people who push it put the advisory in this descriptions file on the mirrors. the only question i have is how does this get onto the mirrors? is there an svn file we can just modify so that the advisories become available? in any case, i'm planning on putting this in the policy once and for all, so that this minor bug is finally resolved. any objections?
Re: [Mageia-dev] [changelog] [RPM] cauldron core/release btrfs-progs-0.19-1.20120328.1.mga2
Op zaterdag 28 april 2012 20:16:53 schreef Thomas Backlund: > 27.04.2012 13:41, Thierry Vignaud skrev: > > On 22 April 2012 15:29, tmb wrote: > >> tmb 0.19-1.20120328.1.mga2: > >> + Revision: 232555 > >> - update to 2012-03-28 snapshot > >> > >> * switch back to master branch as dangerdonteveruse branch is now > >> merged > > > > You should add btrfsck to: > > perl-install/install/share/list.xml > > added. > > > rescue/list.xml > > already there > > > Also we still miss something to set UUID on btrfs partitions (see > > fs/format.pm) > > I dont know yet how... i noticed today that it tried to do fsck -a on the btrfs partition but btrfsck: -a option does not exist... i donno if it actually checks the partition or not though...
Re: [Mageia-dev] Release blocker bugs
Op donderdag 26 april 2012 17:14:27 schreef Thierry Vignaud: > On 26 April 2012 16:35, Guillaume Rousse wrote: > >> Please quote only what's needed next time. > > > > I humbly apologize for pasting at least 5 perfectly useless lines. > > Ops, I did it again ! > > Stop trolling. > You quoted 52 lines for a 2 lines answer (which was only answering to the > two last lines about spec-helper) i saw an attached file, not quoted lines...
Re: [Mageia-dev] Handling single user/rescue/failsafe mode
imho: it's because something could've happend so that the /etc/passwd file can't be read, or various login parts wrong pam selection, or whatever, imho, if you want to secure this, you should secure the grub instead.
Re: [Mageia-dev] broken dependencies are growing again...
Op zondag 22 april 2012 08:38:53 schreef Jerome Quelin: > On 12/04/22 01:22 +0200, Maarten Vanraes wrote: > > Op zaterdag 21 april 2012 21:42:23 schreef Pascal Terjan: > > > On Sat, Apr 21, 2012 at 20:15, Maarten Vanraes wrote: > > [...] > > > > > > ==> missing perl modules: > > > > perl-Catalyst-Authentication-Credential-OpenID > > > > perl-JavaScript > > > > > > Yes and we can't do more about them, we should probably just remove > > > them from mirrors > > > > [...] > > > > iinm identity uses perl-Catalyst-Authentication-Credential-OpenID (or > > planned to at some point) > > > > besides, it points to perl-Catalyst-Engine-HTTP not being there. which > > seems to me (a novice) a more important package (unless renames or > > stuff) > > catalyst::engine::http does not exist anymore upstream. i already > reported a bug. until the bug is solved (either by providing back ::http > or to do without it), there's nothing much i can do. > > perl-javascript doesn't compile anymore with latest javascript libs, > once again a bug exists upstream. > > so, nothing much to do for those. > jérôme ah, ok. is this a release_blocker? i hope not? maybe we can include it on the errata if not. or will this be problematic on mga1 > mga2 upgrade? if not, perhaps we need some quick workarounds or something
Re: [Mageia-dev] microcode needed by default
Op zondag 22 april 2012 07:01:04 schreef simple w8: > Hi, > > when booting i alwas saw that systemd was complaning about not being > able to start service microcode.service (Description: LSB: Update the > Intel / AMD CPU microcode). > > I made a research with urpmq and found the package microcode, i > installed it and now theres no complains in systemd regarding > microcode. perhaps it would be better to have the service in the packages itself... and get this to split off
Re: [Mageia-dev] broken dependencies are growing again...
Op zaterdag 21 april 2012 21:42:23 schreef Pascal Terjan: > On Sat, Apr 21, 2012 at 20:15, Maarten Vanraes wrote: [...] > > ==> missing perl modules: > > perl-Catalyst-Authentication-Credential-OpenID > > perl-JavaScript > > Yes and we can't do more about them, we should probably just remove > them from mirrors [...] iinm identity uses perl-Catalyst-Authentication-Credential-OpenID (or planned to at some point) besides, it points to perl-Catalyst-Engine-HTTP not being there. which seems to me (a novice) a more important package (unless renames or stuff)
[Mageia-dev] broken dependencies are growing again...
plz look at: http://check.mageia.org/cauldron/dependencies.html ==> wrong strict versioned requires? (or not enough rebuilt packages) brasero ==> needs dropping: cluster ==> rebuild without the dropped openais? ocfs2-tools ==> missing perl modules: perl-Catalyst-Authentication-Credential-OpenID perl-JavaScript ==> likely need rebuild due to newer dependant libs: telepathy-qt4
Re: [Mageia-dev] freeze push: linux ha cluster stack
Op vrijdag 20 april 2012 20:38:55 schreef Anne Nicolas: > Le 20/04/2012 20:13, nicolas vigier a écrit : [...] > > - cluster (including cman, rmanager) : obsoleted upstream, pacemaker > > should be used instead : > > https://fedorahosted.org/cluster/wiki/HomePage cluster seems not to be deleted... see http://check.mageia.org/cauldron/dependencies.html [...] > > - openais : project seems dead (no website online anymore), and nothing > > require this (except cman from cluster package which we are dropping) ocfs2-tools seems to require openais-devel, and as such is now broken: see http://check.mageia.org/cauldron/dependencies.html
Re: [Mageia-dev] RPM groups change: Productivity ?
Op zaterdag 21 april 2012 07:33:23 schreef Remco Rijnders: > Hi all, > > I've just submitted taskwarrior, a command line tool to organise, > prioritise, and track tasks etc. > > From the Fedora spec which I adopted, they have it in the group > "Applications/Productivity". We have no such group available on > https://wiki.mageia.org/en/RPM_groups_policy . In the end I resorted to > picking "Text tools", but it just didn't feel right to me. As I have > similar tools I'm thinking of packaging, as well as we have other tools > in the distro such as taskcoach in "Office", I think a "Productivity" > category might be of use. What do you think? > > Remmy Since our license policy is fedora based, i see no problem with this group policy change
Re: [Mageia-dev] Please welcome a new packager : remmy
Op donderdag 19 april 2012 19:24:30 schreef Samuel Verschelde: > Remmy has completed his packager mentorship program [...] welcome
Re: [Mageia-dev] mysql CVE's in mga1 => have it update to mariadb
Op vrijdag 13 april 2012 19:35:15 schreef Thomas Backlund: > 13.04.2012 19:30, Maarten Vanraes skrev: [...] > > bye any chance do you have the CVE for the new one? i remember there was > > one in mariadb a few days ago, so i want to make sure this is the same > > one. > > Unfortunately no CVE yet... it only refers to a locked bug report: > > Security Fix: Bug #59533 was fixed. > > > > But as mariadb 5.5.23 is supposed to be based on mysql 5.5.23, it > should be fixed. I hate this... oracle is really fucking things up here...
Re: [Mageia-dev] mysql CVE's in mga1 => have it update to mariadb
Op vrijdag 13 april 2012 18:19:14 schreef Thomas Backlund: [...] > I've started working on mysql-5.5.23 (as it contains another security > fix), and will release it to updates_testing for Mageia 1 as soon as > possible. bye any chance do you have the CVE for the new one? i remember there was one in mariadb a few days ago, so i want to make sure this is the same one.
Re: [Mageia-dev] mysql CVE's in mga1 => have it update to mariadb
Op vrijdag 13 april 2012 13:12:08 schreef AL13N: [] i guess most packagers want option 2 here. i don't think this is a good idea in general and i was of the opinion that the diff between migrating mysql 5.5.22 and mariadb 5.5.23 were quite the same... nonetheless, the package naming difference could have effects on it on a stable version, so i concede to this solution. however, i'll note that mariadb likely contains extra bugfixes, which this mysql 5.5.22 will not have. i guess this is the step where this is more or less decided and some packager steps in and does the actual work. any volunteers? perhaps that person can also become maintainer of it?
[Mageia-dev] mysql CVE's in mga1 => have it update to mariadb
regarding bug https://bugs.mageia.org/show_bug.cgi?id=5260 after talking with mariadb people and some others, i'm proposing to update mysql 5.5.10 to mariadb-5.5.23 in mga1. however, QA should extra-double-test the php-mysql dependency, as mariadb noted that php-mysql seems to have a very strict versioning scheme sometimes and having a new mysql provider without rebuilding php-mysql often fails... in case of no objections, i'll go ahead with this.
Re: [Mageia-dev] Freeze push mariadb 5.5 GA release
Op woensdag 11 april 2012 01:56:04 schreef Maarten Vanraes: > Please push mariadb: > > This updates to the 5.5 GA release (it's not announced yet, but they are > waiting for it to hit all the mirrors) ping
[Mageia-dev] alternatives policy
Hi, from a question someone asked, i was reminded why an alternative file ( /var/lib/rpm/alternative/gl_conf ) was not owned. I found out that alternative files are usually %ghost 'ed, but it seems not in this case. I looked at the alternatives policy, but it was empty as it needs yet to be written. so, is it true that alternative files should be %ghost 'ed? or not?
[Mageia-dev] Freeze push mariadb 5.5 GA release
Please push mariadb: This updates to the 5.5 GA release (it's not announced yet, but they are waiting for it to hit all the mirrors)
Re: [Mageia-dev] bumblebee in mageia (and mentoring)
Op dinsdag 10 april 2012 21:53:57 schreef Guillaume Rousse: > Le 10/04/2012 21:12, Maarten Vanraes a écrit : > >>>> if [ $1 -eq 1 ]; then > >>>> > >>>># Initial set > >>>># Enable (but don't start) the unit by default > >>>>/bin/systemctl enable bumblebeed.service > >>>> > >>>> fi > >>> > >>> I don't think this stuff is needed on Mageia, that is done by default. > >> > >> Really? I didnt knew about it, is there any page documenting that? > >> Im quite curious about how is done :) > > just read the the add-service helper code, or alternatively the > rpm-helper README file. > > > perhaps filetriggers or the post and preun service helpers do all this > > automagically... i don't know, i usually just look at other packages. > > > > i think a provided existing service file is picked up by filetriggers > > No, that's handled by add-service helper here. thanks for correcting me
Re: [Mageia-dev] bumblebee in mageia (and mentoring)
Op dinsdag 10 april 2012 21:28:19 schreef simple w8: [...] > > better to follow the policy. > > I dont know about mageia policies, but i will read about them so i can > start using them from now on. check https://wiki.mageia.org/en/Policies , you don't have to read all of them, but it's nice to look at what kind of policies exist, so that later you can look them up if required. [...] > > you can afterwards make a kmod-bbswitch and kmod-acpi_call packages that > > make prebuilt modules for all available kernels. > > Yeap, i have seen those kind of packages and that way theres no need > to use a dkms. well, except to actually build the kmod package, since it requires the dkms package :-) [...] > > perhaps filetriggers or the post and preun service helpers do all this > > automagically... i don't know, i usually just look at other packages. > > > > i think a provided existing service file is picked up by filetriggers > > I do see one systemd filetrigger: systemd-daemon-reload.script > > but i would like to know hows processed, so far for what i have seen i > dont see how that is possible, to put systemd running services without > put them in the scripts. > > And to remember that bumblebee is provided with service files for > systemd and sysvinit, i did had that caution, thats why i put in > scripts both usage. > > Still i think it would be better to simply keep the ones for systemd, > since its the one used by default. well, if i was you, comment out the code and see if it actually does enable it by default. i'm definately not an expert, but for mariadb i didn't have to enable it, it worked like that... since i have not seen any other packages where it effectively does that, i don't think it's required. [...] > > iinm you can also add extra option to %cmake. if it's possible it'd be > > nice to have %cmake in it. if there would be systemwide changes at a > > later time, possibly due to changed newer cmake behavior, or whatever, > > it can be picked up without much effort. > > > > also it looks better to me, having all cmake packages using %cmake :-) > > Did you read what i wrote? ? of course i did, why else would i take the effort to reply? > i did tried to use %cmake but build fails, so its really need to use > it explicitely like its currently, and the same goes for when i did > not used %makeinstall_std in libbsd. well as you already know, %cmake evaluates to cmake with some extra stuff, so if one of these things give you difficulty, either it points to a point that can be improved, or you can just override them for the ones you need. that way, you can still make it work with %cmake. [...]
Re: [Mageia-dev] bumblebee in mageia (and mentoring)
i have some sparsely extra comments, i hope i'm correct on this...
Op dinsdag 10 april 2012 20:35:26 schreef simple w8:
> 2012/4/10 Anssi Hannula :
> > 10.04.2012 07:46, simple w8 kirjoitti:
> >> Currently i dont have any account to be able to comit these new
> >> packages for the distro so i ask if someone can review the specs so
> >> that these packages can start existing in the distro, and i also ask
> >> if theres someone that can help me with mentoring
> >
> > Reviewed below. However, there looks to be quite a lot of work
> > remaining, so I don't think I'll be able to help you personally with the
> > issues. I hope you'll find a mentor who'll help you through.
> >
> >> Name: libbsd
> >> Summary: Library providing BSD-compatible functions for portability
> >>
> >>[...]
> >>
> >> %{_libdir}/libbsd.so.%{major}*
> >
> > [...]
> >
> >> %{_libdir}/libbsd.so
> >
> > [...]
> >
> > We already have libbsd.a from glibc-devel, which would conflict with
> > this. If they are really different libraries, something drastic would
> > have to be done (e.g. renaming or dropping one). I suspect they are the
> > same, though, in which case this isn't needed.
> >
> >> %prep
> >> %setup -q
> >> # fix encoding of flopen.3 man page
> >> for f in src/flopen.3; do
> >> iconv -f iso8859-1 -t utf-8 $f >$f.conv
> >> touch -r $f $f.conv
> >> mv $f.conv $f
> >> done
> >>
> >> %build
> >> %make
> >
> > %optflags not used.
> >
> >> %install
> >> make install DESTDIR=%{buildroot} \
> >
> > %makeinstall_std
>
> Here you really need to spefify them, with %makeinstall_std fails
>
> >> libdir=%{_libdir} \
> >> usrlibdir=%{_libdir} \
> >> exec_prefix=%{_prefix}
> >
> > [...]
> >
> >> optidesk.spec
> >>
> >>
> >> Name: optidesk
> >> Summary:Tool to configure .desktop files to run with optirun
> >> Group: Graphical desktop/Other
> >> Version:0.1
> >> Release:1
> >> URL:https://github.com/Bumblebee-Project/optidesk
> >> License:GPLv3
> >> # source from git repo git://github.com/Bumblebee-Project/optidesk.git
> >> Source0: %{name}.tar.xz
> >
> > Tarball needs to be versioned.
>
> I did add a comment saying its from git, but i usually use to create a
> macro and put some like this:
>
> Source0: %{?git:%{name}}%{!?git:%{name}-%{version}}.tar.xz
>
> but still there isnt any version released
>
> >> Requires: bumblebee
> >>
> >> %description
> >> This tool is intended to be an easy way of configuring your desired
> >> applications to be run through Bumblebee. It will allow to create
> >> and modify a menu entry with an alternative (Optirun) version of the
> >> default launcher.
> >>
> >> %files
> >> %{_bindir}/%{name}
> >>
> >>
> >> %prep
> >> %setup -qn %{name}
> >>
> >> %build
> >> autoreconf -fi
> >> %configure
> >
> > %configure2_5x
>
> I also use to use configure2_5X~but here would not make any
> difference, but yes here i didnt put because i missed ateention on
> this line
>
> >> %make
> >
> > [...]
> >
> >> %changelog
> >> * Mon Mar 19 2012 Simple 3.0-1
> >> - initial package
> >
> > No single-entry changelog needed for imported packages, it will be
> > created from the import commit message. (applies to all .specs)
>
> Even so i do add an entry in changelog for my personall reports.
>
> >> dkms-bbswitch.spec
> >>
> >>
> >> %define oname bbswitch
> >>
> >> Name: dkms-%{oname}
> >> Summary:bbswitch - Optimus GPU power switcher
> >> Group: System/Kernel and hardware
> >> Version:0.4.1
> >> Release:%mkrel 1
> >> License:GPLv3
> >> URL:https://github.com/Bumblebee-Project/bbswitch
> >> # source from git repo git://github.com/Bumblebee-Project/bbswitch.git
> >> Source0:%{oname}.tar.xz
> >
> > Tarball needs to be versioned.
>
> This is from git and already explained that there was no release
i like to add that if it's a git version, it's best if to have some kind of
git version on it. so it can be uniquely named. same git version should also
be used in the version or release.
> >> BuildArch:noarch
> >> Requires(post): dkms
> >> Requires(preun):dkms
> >
> > Needs to require dkms.
>
> AFAIK dkms its only used in post and preun scriptlets., so why add
> another plain require?
it's in the policy, if you think the policy is incorrect, you should send a
separate email about it.
better to follow the policy.
> >> %description
> >> bbswitch is a kernel module which automatically detects the required
> >> ACPI calls for two kinds of Optimus laptops. It has been verified to
> >> work with "real" Optimus and "legacy" Optimus laptops (at least, that
> >> is how I call them).
> >>
> >> %files
> >> %{_usrsrc}/%{oname}-%{version}/*
> >>
> >> %post
> >> set -x
> >> dkms add -m %{oname} -v %{version} --rpm_safe_upgrade || :
> >> dkms build -m %{oname} -v %{version} --rpm_safe_upgrade || :
> >> dkms install -m %{oname} -v %{v
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 23:48:59 schreef Florian Hubold: > Am 07.04.2012 21:25, schrieb Maarten Vanraes: [...] > > otoh, "silence is acceptance" is one of my favourite sayings... > > Well, when i pointed out those branding issues before, > noone was interested either, here on this list ... guilty as charged...
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 21:14:00 schreef Florian Hubold: > Am 07.04.2012 20:59, schrieb Maarten Vanraes: > > Op zaterdag 07 april 2012 20:50:03 schreef Florian Hubold: > >> Am 05.04.2012 14:19, schrieb Romain d'Alverny: > >>> On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes wrote: > >>>> Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: > >>>>> As there was no real objection, and no other comments > >>>>> or votes for iceape, i've dropped it from cauldron. FWIW i'm quite > >>>>> unhappy with this. Related, i've also not got any reply yet to my > >>>>> aforementioned inquiry about mozilla branding permissions. > >>>> > >>>> About the mozilla branding... > >>>> > >>>> Perhaps this should be a meeting point for packaging/council > >>>> meeting... > >>>> > >>>> ie: someone assigned to this point so it's not forgotten. > >>> > >>> Would have been good to raise this point in Council way sooner. No > >>> other than the maintainers may answer both questions (about changes, > >>> and about contact/permissions from Mozilla). For Firefox it's dmorgan > >>> and for Thunderbird it's anssi. > >> > >> For thunderbird it's actually me, Anssi grabbed it on my behalf > >> when i was still apprentice ;) > > > > no offense, but if you're the thunderbird maintainer, why don't you ask > > mozilla about it? tell them if we're not getting this official > > permission we won't ship it and do the iceape thing instead... > > Did you read my previous mails? I've asked Kev Needham, > mozilla distribution channel manager, about the approval > process, sadly no answer yet. ah, mea culpa, i must've missed a few and too bad though... you can ask a few more people and CC some of the "important people" (or ones having good connections) like annael, stewb or such... otoh, "silence is acceptance" is one of my favourite sayings...
[Mageia-dev] [systemd] keyboard shortcut to show jobs during boot
in order to investigate hangs or slow boots or whatever, it would be useful to have some kind of key combination that lists the current systemd jobs and where it's hanging/waiting or whatever either that or detect a hang an spawn some kind of emergency login somewhere actually, if i'm really pulling out my want-to-have book, howabout a tty that (until it can actually get a tty), shows an top like watch of current jobs in systemd, where you can force some kind of process, ie: killing it, or letting all the dependant ones go through. perhaps that could be on the tty that would eventually always become a tty (as i remember we talked about) let's say that tty12 gets the kernel logging, then tty11 could show first dracut/udev stuff, then proceed with systemd jobs, and when it can get a tty, to be reserved for tty. (all the others could be reserved for graphicals then) that way, no matter what happens, you get some nice info/tty availability. ok, give all this nice-to-have... is there a way we can find out why a boot hangs? is there some logging we can check in a rescue or ...?
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op zaterdag 07 april 2012 20:50:03 schreef Florian Hubold: > Am 05.04.2012 14:19, schrieb Romain d'Alverny: > > On Thu, Apr 5, 2012 at 08:11, Maarten Vanraes wrote: > >> Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: > >>> As there was no real objection, and no other comments > >>> or votes for iceape, i've dropped it from cauldron. FWIW i'm quite > >>> unhappy with this. Related, i've also not got any reply yet to my > >>> aforementioned inquiry about mozilla branding permissions. > >> > >> About the mozilla branding... > >> > >> Perhaps this should be a meeting point for packaging/council meeting... > >> > >> ie: someone assigned to this point so it's not forgotten. > > > > Would have been good to raise this point in Council way sooner. No > > other than the maintainers may answer both questions (about changes, > > and about contact/permissions from Mozilla). For Firefox it's dmorgan > > and for Thunderbird it's anssi. > > For thunderbird it's actually me, Anssi grabbed it on my behalf > when i was still apprentice ;) no offense, but if you're the thunderbird maintainer, why don't you ask mozilla about it? tell them if we're not getting this official permission we won't ship it and do the iceape thing instead...
Re: [Mageia-dev] Release_blocker bugs
Op vrijdag 06 april 2012 13:17:46 schreef Anne nicolas: [...] > Does not seem to be release_blocker > === > 4301 bugsq...@mageia.org Migration of module-init-tools to kmod lib in > Mageia 2 - specifications > => 4802 [...] i may understand this wrong, but iinm, module-init-tools doesn't work with current kernel anymore, and kmod is now required => doublecheck with tmb
Re: [Mageia-dev] [RFC] How to proceed with seamonkey/iceape for security updates and freeze push
Op woensdag 04 april 2012 22:59:30 schreef Florian Hubold: > Am 26.03.2012 19:46, schrieb Florian Hubold: > > Hi all, > > > > i've taken a look at iceape and locally updated it to 2.7.2¹ after > > talking with maintainer > > about it, with the intent to at least push this to Mageia 1, because > > since initial import > > it has not received any security updates (and there are countless > > security problem) I've also completed the rebrand to iceape as far as i > > saw fit (change URL to release > > notes, applied some more debian rebranding patches, removed updater files > > and updater menu item, and some more smaller fixes, current svn diff is > > attached) and did some cleaning of old and unused stuff. > > > > ¹: I've only updated it to 2.7.2 as 2.8 does require newer NSPR, and > > that's a no-go for Mageia 1, which is my primary target. > > > > > > > > The biggest problem is: current maintainer does not have enough time to > > maintain it properly, and i'm not planning on doing it either, as i > > don't use it or know it well. > > > > There are at least 3 good options on how to proceed, apart from mga1 > > update: > > > > > > 1. > > push latest version to cauldron, and hope somebody will maintain it > > afterwards (this is the worst IMHO, as we'll probably face the same > > situation with a de-facto umaintained package throughout Mageia 2 > > lifetime, which i want to avoid) > > > > > > 2. > > drop iceape, package as seamonkey again and sync with Fedora > > (this one would at least make maintenance easier, only need to follow > > Fedora) > > > > > > 3. > > drop iceape completely > > (actually this has the advantage that users can have official upstream > > binaries, and take advantage of automatic updates. Current maintainer > > agrees with this, as it's simply too fragile for him to maintain it > > easily. > > If somebody is against this, please step up as maintainer or help the > > current maintainer) > > > > > > I'm currently in contact with some seamonkey developers, to maybe clear > > up why/if the > > rebrand is needed, if it's needed like it's currently done, and why > > Fedora can simply > > ship seamonkey without the need for a rebrand, but the dialog may take > > some time, this > > would be only relevant for option 2. > > > > > > If nobody responds, i'll push my current work as security update for > > Mageia 1, and drop iceape from cauldron so that we won't have an > > outdated package and a potential security risk for Mageia 2. > > > > > > Kind regards > > As there was no real objection, and no other comments > or votes for iceape, i've dropped it from cauldron. FWIW i'm quite > unhappy with this. Related, i've also not got any reply yet to my > aforementioned inquiry about mozilla branding permissions. About the mozilla branding... Perhaps this should be a meeting point for packaging/council meeting... ie: someone assigned to this point so it's not forgotten.
Re: [Mageia-dev] Freeze push: pidgin-sipe
Op maandag 02 april 2012 11:36:37 schreef Damien Lallement: > Le 01/04/2012 20:06, Damien Lallement a écrit : > > Le 30/03/2012 10:31, Damien Lallement a écrit : > >> Le 29/03/2012 11:46, Damien Lallement a écrit : > >>> Le 28/03/2012 13:22, Damien Lallement a écrit : > Hi, > > Can you please push pidgin-sipe. > The new version (1.13.0) is a bug fix version: > - add TLS-DSK authentification scheme (mandatory for Office365) > - add non-public Lync support > - fix build vith latest glib2 > - refactored crypto code > - remove kopete backend (telepathy now) > > http://sourceforge.net/projects/sipe/files/sipe/pidgin-sipe-1.13.0/ > > Thanks, > >>> > >>> ping ? > >> > >> ping ? > > > > ping? > > ping? ping?
Re: [Mageia-dev] noarch packages containing binaries should be rejected
Op maandag 02 april 2012 12:35:49 schreef Guillaume Rousse: > Le 02/04/2012 10:37, Thierry Vignaud a écrit : > > Please make arch-independent-package-contains-binary-or-object a > > reason to reject > > > packages at upload time: > The rule need some subtle exceptions. For instance, some pentest tools > such as metasploit are arch-independant, but contains native code to be > executed on remote systems. hmm, that's an interesting use case that i didn't think of...
Re: [Mageia-dev] Please push fwbuilder
Op maandag 02 april 2012 03:07:35 schreef Luis Daniel Lucio Quiroz: > Please kindly push fwbuilder, it fixes many iptables compillations issues > and it reports itself that there is a new update. Complete changelog is > here > http://www.fwbuilder.org/4.0/docs/firewall_builder_release_notes.html#5.0 > > Enviado desde mi teléfono Verizon Wireless fwbuilder is irritating in the fact that if someone has edited with a newer version, the .fwb file is upgraded and you need that version or more to open it again...
Re: [Mageia-dev] Problems with flash 11.2
Op zaterdag 31 maart 2012 10:46:43 schreef JA Magallón: > On 03/31/2012 08:43 AM, Dimitrios Glentadakis wrote: > > Στις 31/03/2012 08:38:19 γράψατε: > >> Στις 31/03/2012 02:38:24 JA Magallón γράψατε: > >>> And, btw, to get hw video decoding I had to write a file in > >>> /etc/adobe/mms.cfg with > >>> > >>> EnableLinuxHWVideoDecode=1 > >> > >> Thanks, this solved the problem for me > > > > i had to reverse to disable hw acceleration because the embedded youtube > > videos in konqueror are invisible (in youtube it is ok) > > Yep, and flash also behaves mch more unstable, I'm having hangs I > has never seen before. > > Crappy flash... > > BTW, how can I check if html5 has hardware support ? depending on the browser, but i think most browsers use native stuff, therefor if you have hw support, it's likely to be working in html5 as well
Re: [Mageia-dev] Removal of sun java
Op vrijdag 30 maart 2012 16:03:14 schreef Guillaume Rousse: [...] > Issuing a specific sun jdk security update package, containing only a > README.urpmi file and a shell script inciting the user to read this file > eventually, would be a fair compromise for me. And can be considered as > a standard practice for semi-automatically removing > very-dangerous-packages-we-cannot-afford-to-let-installed-anywhere-otherwis > e-the-apocalypse-will-happen. if at all possible, i'd like a similar solution, but with task-obsolete somehow, since it ties in nicely with all the related stuff (iiuc above) but i think it is nice to have such a notification with such kind of packages... ie: if we're proposing to delete something, i'd rather know why...
Re: [Mageia-dev] Removal of sun java
Op vrijdag 30 maart 2012 16:00:22 schreef nicolas vigier: [...] > I think an empty package is not a good idea, it would be better to > obsolete it in task-obsolete : > - it's more clear that the package is obsoleted and is not a regular >update. Users installing an empty package as update would only see that >it is removed but not updated when it's already removed. > - package is really removed and no longer listed as installed in rpm >database > - it's easy to add task-obsolete in urpmi skip.list for people who >don't want unmaintained packages to be automatically removed wrt to task-obsolete, do the users get notified? maybe a README.urpmi listing all the packages and reasons would be an option to get notified?
Re: [Mageia-dev] dropping mysql-workbench
Op vrijdag 30 maart 2012 10:11:34 schreef nicolas vigier: > On Thu, 29 Mar 2012, Maarten Vanraes wrote: > > unfortunately, atm it doesn't work, so it needs to be rebuilt, but it > > doesn't rebuild at all... and since we're in version freeze, you can't > > just update to a new version. even more is that soon is release > > freeze... > > No, fixing a package that doesn't work can be a good reason for version > freeze exception. So if a new version can help fix the problem, it > should be considered. ic, well in that case, i guess it can be done like this, but if there's no maintainer for it... personally, i have no problem with this being dropped. which is not to say i'm trying to hurt people who use it... but if we can't maintain a package, maybe it's better if the people who want to use it, can get it from upstream themselves. and since this is from oracle, i guess the maintainer should also doublecheck licensing to be on the safe side, since oracle has relicensed quite some code. who knows, maybe we can't even redistribute it anymore...
Re: [Mageia-dev] No time for maintainership
Op vrijdag 30 maart 2012 04:13:50 schreef Remco Rijnders: [...] > fetchmail eandry [...] > Feel free to pick any that have your fancy. I imagine that we'll want to > set to 'nobody' any packages that have not been adopted in say a week or > two from now? actually, i cannot grab one because they are still assigned. please someone set them to nobody.
[Mageia-dev] Freeze push: mariadb (rc)
Please push mariadb: mariadb (and mysql) seem to have an odd method of increasing version number for each of there alpha/beta/rc/final versions. This updates to the 5.5 RC release (it's not announced yet, but they are waiting for it to hit all the mirrors) Normally, the final is expected to be released april 9th.
Re: [Mageia-dev] dropping mysql-workbench
Op donderdag 29 maart 2012 23:03:46 schreef Juan Luis Baptiste: > On Thu, Mar 29, 2012 at 3:57 PM, Maarten Vanraes wrote: > > someone asked me to see about > > https://bugs.mageia.org/show_bug.cgi?id=5146 > > > > it looks like it needed a rebuild, but the rebuild failed with automake > > errors of some kind... > > > > tbh: i don't really care about this package, and have no idea if anyone > > (except reporter) actually uses this, is it even useful? > > This program is REALLY useful for web developers and database admins, > I use it, so I'll get maintainership of it and try to fix the errors > as soon as I can (swamped with work lately). See what it's useful for: > > http://www.mysql.com/downloads/workbench/ no offense meant, but i am in $dayjob both a webdev and sysadmin, and i don't use these kind of things, i don't even use phpmyadmin... unfortunately, atm it doesn't work, so it needs to be rebuilt, but it doesn't rebuild at all... and since we're in version freeze, you can't just update to a new version. even more is that soon is release freeze... i guess this means you have 1 week to get this fixed... otherwise i think we'll have no choice but to remove it... good luck, (if you need any pointer or help, i can still try to help/answer you though)
[Mageia-dev] dropping mysql-workbench
someone asked me to see about https://bugs.mageia.org/show_bug.cgi?id=5146 it looks like it needed a rebuild, but the rebuild failed with automake errors of some kind... tbh: i don't really care about this package, and have no idea if anyone (except reporter) actually uses this, is it even useful? so, since it has no maintainer, and it doesn't work anymore, and it can't be rebuilt... perhaps we should drop it. if someone wants to have it, he can likely get it from upstream directly? WDYT?
Re: [Mageia-dev] RFT: xen support
Op maandag 11 april 2011 10:33:30 schreef Thomas Backlund: > Hi, > > xen-4.1.0-1.mga1 is now avaliable in the repos. > > And as of kernel-2.6.38.2-4.mga1 there has been some cleanups and addons > for xen: > > There is now a kernel-xen-pvops that also should work as dom0. > > Now this is mostly upstream kenel.org code so its not as fully > featured as the old kernel-xen. You can see the features listed here: > http://wiki.xensource.com/xenwiki/XenParavirtOps. > > There is one exception: our 2.6.38 kernel has xen-netback backend driver > added. > > So those of you that have been using xen, please test atleast the > following: > > - check that kernel-server still works as a xen guest > - try to use kernel-xen-pvops as dom0 and see how it works > (you can also try to use kernel-xen-pvops as a normal xen guest) > > Have fun... > > -- > Thomas i don't know how much people have been testing, but... dom0 xen didn't work with .xz kernels, i put in a patch for that, and now it works. in a kvm guest, i've got a working xen dom0 host, but the libvirtd implementation seems unable to find the cpu architecture, and if i force to be the same as the host, i am unable to boot the dom0 anymore. (i think this is likely due to the nature of a KVM guest not really being suitable for a XEN dom0). i've tried a physical server, but when i finally got to the point of libvirtd, it seemed to not bootup anymore (it was an old disk, which i thought got broken, seeing the IO errors) I put in a new disk, only to note that the X2 suddenly only had 1 core, which i found very odd, and i noticed the IO errors before (and also now) were really sata bus errors... (and if i remember correctly this machine had been used with a semi-exploding PowerSupply)... so i think this mobo/cpu is fried... now i need to find new hardware to restart testing again :-( . note that allthough i can have everything running, i never tested with actual guests, let alone online migrations... however, i did find out that this xenpvops has 2 different toolchains: xm and xl. xl seems to do pretty much the same, but apparently doesn't require xend to be running (it reacts directly to the kernel/hypervisor?) also the xencommons init script seems to start xenconsoled and xenstored on it's own. i'm thinking of removing both those init scripts and having xend not start as default. (allthough i don't know about xendomains). i'll keep you guys posted.
Re: [Mageia-dev] Removal of sun java
Op donderdag 29 maart 2012 21:08:22 schreef David Walser: > Guillaume Rousse writes: > > If I want to keep a proprietary JRE on my computers, because I trust it > > more to run crap proprietary applications (also called > > corporate-compliants), than marvelous free-licensed environment they > > have never been tested with, that is my choice, not yours. > > If they really want to keep Sun Java, shouldn't they just download the > installer from Sun and install it themselves, rather than using some > obsolete Mageia 1 package of it? well, iinm the version that the people have, will still have the correct license and we are able to distribute it fine. i would argue that if security bugs we could remove it, but i'm not too sure on this point... i mean, can we really remove it from them? otoh, people wanting to have the proprietary ones, likely know what they are doing... perhaps we can obsolete it with one of those nonfree getters? (if security bug) or, maybe a package that gives an README.urpmi ... IMHO: i think obsoleting it is fine, but with a README.urpmi that says notifies that it's been obsoleted. (unless someone wants to have and maintain a nonfree getter application that fetches the upstream releases) we really shouldn't keep stuff we can't maintain...
Re: [Mageia-dev] freez push clamav-0.97.4
Op zondag 25 maart 2012 00:21:36 schreef Colin Guthrie: > 'Twas brillig, and Thomas Spuhler at 24/03/12 22:49 did gyre and gimble: > > On Saturday, March 24, 2012 12:36:06 PM Sander Lepik wrote: > >> On Mar 24, 2012 9:13 PM, "Thomas Spuhler" wrote: > >>> please push clamav-0.97.4 > >>> -- > >>> Best regards > >>> Thomas Spuhler > >> > >> Why? > >> > >> -- > >> Sander > > > > it's an upgrade from 0.97.4 > > We need to provide the newest version of the antivirus package > > This, by itself, is not a very good explanation. > > If this is purely a definitions update then that's fine. > If this is a bugfix update that's probably fine too (depending on the bug) > If it's a new feature update then that likely won't make it. > > People are all very busy. It only takes the person requesting the push a > minute or two to describe things properly. Please give your busy > colleagues the respect they deserve and provide good explanations to > save them having to spend time discussing and asking further questions. > > We still don't really have enough information to decide on this one! > > So please state whether it's just definitions or bugfix (and if so what > bugs) etc. > > Col IIUC older clamav engines aren't supported, and stop working. but the reason given was indeed not enough. keep in mind that new features for this often means a security fix :-D i think this'll likely go through, but the original poster should check to see how things are, and report them accurately.
Re: [Mageia-dev] freeze push: drakxtools and drakx-installer-stage2
Op vrijdag 23 maart 2012 21:56:36 schreef Thierry Vignaud:
> Hi
>
> Please let in drakxtools & drakx-installer-stage2.
>
> A lot of messages were bogus after the cleaning (replacing Mdv by %s
> without providing
> any "Mageia" to actually sprintf in...).
> There might be similar issues in other tools "cleaned".
> People can use perl_checker to find those ("not enough parameters").
>
> Also, other bugs found by perl_checker and the support for
> "splash/quiet" in drakboot.
>
> Here's the detailed changelog:
>
> 1) drakxtools
> - drakauth:
> o fix actually displaying "Domain Windows for authentication"
> - drakboot:
> o use "splash" on the kernel command line vs. "splash=silent" as per
> upstream code (e.g. plymouth, systemd and others)
> o support the "quiet" kernel command line argument to hide kernel text
> - drakbug, draksec, drakxhelp, logdrake:
> o fix displaying "Mageia"
> - harddrake:
> o fix detecting bluetooth devices
>
> 2) drakx-installer-stage2
> - better "bootloader" message (mga#484)
> - fix displaying "Mageia" in some messages
>
> See you
does i18n need to be notified?
[Mageia-dev] MariaDB: problem: final estimated release date
( see https://mariadb.atlassian.net/secure/Dashboard.jspa , look at road map ) MariaDB RC 5.5.22 29/Mar/12 MariaDB GA 5.5.23 09/Apr/12 that means that the GA (final release) is 2 days after release freeze :-( (not counting any possible extra delays) however, i would like to have the final release and not the release candidate. any thoughts on this?
Re: [Mageia-dev] installing minimal is not really that minimal
Op vrijdag 23 maart 2012 17:38:05 schreef Thierry Vignaud:
[...]
> we preselect it here so that it got installed early:
> http://svnweb.mageia.org/soft/drakx/trunk/perl-install/install/any.pm?revis
> ion=3532&view=markup
>
> because else it'll be automatically pulled later, adding a one package (or
> more) wait later:
> http://svnweb.mageia.org/soft/drakx/trunk/perl-install/bootloader.pm?revisi
> on=3581&view=markup
>
> just look mageia-gfxboot-theme
>
> Of course, that's OK for 99% of our users but for those manually
> selecting text lilo.
text grub would still need this? hmm... i'll look into this more deeply...
> That's a trade off: enforcing waiting for packages installation after all
> the other package installation so that a couple users can not have
> the bootsplash installed and select lilo or having a couple users
> unhappy
yeah, i get that, and i agree with this, but there's no reason some advanced
setting can be done to turn more stuff off, be it visible or even via kickstart
or cmdline...
> BWe could not preselect
what is 'BWe' ?
well, i was thinking to disable the preselect and/or later part when CAT_X is
disabled. that should be fairly easy to do...
> > about firewall, perhaps it's possible to just include iptables, but set
> > policy on DROP incoming? shorewall seems a bit over the top...
>
> we configure shorewall, not iptables.
>
> > but, if summary isn't completed, you can't boot into it, wrt bootloader?
> > so firewall seems useless for that...? what is the rationale behind
> > this?
>
> In the old days we let poeple choose the security level early then we
> automatically install & set up the firewall accordingly.
> Later the security choice was moved to the summary and security level
> number was reduced from to 3 (see msec or security::level)
> But since the default security level is 1 ("standard"), we automatically
> install the firewall anyway.
> For years.
sure, but i don't see the need to preselect it, again, it could be in rpmsrate
and handled that way now that the security level is "unused"
otoh, i could just use defcfg (if i ever get it working) and set security to 0
if i wanted to.
Re: [Mageia-dev] installing minimal is not really that minimal
Op vrijdag 23 maart 2012 10:42:40 schreef Thierry Vignaud: > On 23 March 2012 08:32, Maarten Vanraes wrote: > > Op vrijdag 23 maart 2012 02:08:26 schreef Maarten Vanraes: > >> Op donderdag 22 maart 2012 00:30:53 schreef Maarten Vanraes: > >> [...] > >> > >> in a chroot, i did a test with requiring plymouth or suggesting it (from > >> dracut) > >> > >> the difference is: > >> > >> with plymouth: 301 packages/335MB > >> without plymouth: 294 packages/294MB > >> > >> i'm gonna try a minimal install and see how much this'll differ > > > > ok, i was a bit wrong: > > > > i have a local dracut version overridden with urpmi-proxy so as not to > > required but suggest plymouth > > > > > > testing with which packages would become requested with rpmsrate... > > > > in a chroot, this becomes: 246 packages/299MB > > but, with suggests, this becomes 337 packages/385MB > > > > however, in an install i have 371 packages > > > > but the / contains 731MB > > > > so, where do all these extra packages come from? > > > > these are the different packages between installing with suggests, or > > chrooted rpmsrate expansion with suggests... > > > > acpi > > acpid > > bc > > coreutils-doc > > cpufreq > > dhcp-client > > dhcp-common > > dmraid > > dmraid-events > > gpg-pubkey > > hdparm > > hexedit > > ipset > > iptables > > kpartx > > lib64dmraid1 > > lib64ip4tc0 > > lib64ip6tc0 > > lib64iptables7 > > lib64mnl0 > > lib64nfnetlink0 > > locales-en > > lsof > > mageia-gfxboot-theme > > mandi > > mandi-ifw > > microcode > > microcode_ctl > > procmail > > shorewall > > strace > > sudo > > tree > > > > for one, mageia-gfxboot-theme is here again... it didn't get selected in > > chrooted install from manually checked rpmsrate settings... where does > > this come from? > > > > is there a part in the installer that hardcodes certain packages? clearly > > according to the ddebug.log file, this mageia-gfxboot-theme gets selected > > during the choosePackages step and not later on... > > > > what am i missing here? > > > > does anyone have an idea? i'd like to get to the bottom of this, so a > > pointer in a direction would help me alot... > > acpi* mageia-gfxboot-them are pulled by the installer > mandi* shorewall (& thus iptables*) too. > I've asked previously if we want a firewall installed before summary, anne > & blino said it was OK > microcode* is pulled b/c your CPU supports patching > idem for cpufreq > dhcp was selected b/c there was a network interface configured as DHCP > dmraid (& thus kpartx) was selected b/c you've some fake raid > (...) > you always got gpg-pubkey, those are fake packages containing the keys > used to verify packages thanks for the explanations, i really appreciate this, it seems logical, somehow, except maybe what i'm coming back to: mageia-gfxboot-theme is pulled by installer? how does that work? is this really required? or is this something that's somehow done in the graphic installer? i mean, i didn't select graphic grub, i chose text-grub specifically. and somehow during the choosePackages step, the mageia-gfxboot-theme is automatically selected... this is the packages that's adding via extra dep and suggests, most of the stuff... where can i find the code that is responsible for this, so i can try and fix it? about firewall, perhaps it's possible to just include iptables, but set policy on DROP incoming? shorewall seems a bit over the top... but, if summary isn't completed, you can't boot into it, wrt bootloader? so firewall seems useless for that...? what is the rationale behind this?
Re: [Mageia-dev] rescue has mount.nfs, but no statd
Op vrijdag 23 maart 2012 10:34:55 schreef Thierry Vignaud: > On 22 March 2012 20:33, Maarten Vanraes wrote: > >> nfs was available, so we wanted to mount > >> > >> but the mount failed, because nfs module wasn't modprobed, and drvinst > >> didn't fix that (maybe it should modprobe nfs as well) > >> > >> or maybe mount.nfs should try to modprobe nfs if needed. > >> > >> however, statd wasn't there and it complained that it needed that for > >> locking > >> > >> atm we're doing -o nolock and that works... but... statd would be quite > >> usefull here... > > > > perhaps i should rephrase... > > > > can i fix this by adding statd on the rescue? or would this take too much > > space? > > it's simpler to use "mount -o nolock" instead... it's what i did at the time, but would it be alot of work/space to include statd? when doing backup of files to somewhere else, you kind of want to know it's not gonna get mushed if someone just goes around opening some files or something... would it just be running statd? or would it also require portmapper etc... etc... ? if it's too much work, or too complex, it's not needed, but if it's not too much space and just having statd, then it's good
Re: [Mageia-dev] installing minimal is not really that minimal
Op vrijdag 23 maart 2012 02:08:26 schreef Maarten Vanraes: > Op donderdag 22 maart 2012 00:30:53 schreef Maarten Vanraes: > [...] > > in a chroot, i did a test with requiring plymouth or suggesting it (from > dracut) > > the difference is: > > with plymouth: 301 packages/335MB > without plymouth: 294 packages/294MB > > i'm gonna try a minimal install and see how much this'll differ ok, i was a bit wrong: i have a local dracut version overridden with urpmi-proxy so as not to required but suggest plymouth testing with which packages would become requested with rpmsrate... in a chroot, this becomes: 246 packages/299MB but, with suggests, this becomes 337 packages/385MB however, in an install i have 371 packages but the / contains 731MB so, where do all these extra packages come from? these are the different packages between installing with suggests, or chrooted rpmsrate expansion with suggests... acpi acpid bc coreutils-doc cpufreq dhcp-client dhcp-common dmraid dmraid-events gpg-pubkey hdparm hexedit ipset iptables kpartx lib64dmraid1 lib64ip4tc0 lib64ip6tc0 lib64iptables7 lib64mnl0 lib64nfnetlink0 locales-en lsof mageia-gfxboot-theme mandi mandi-ifw microcode microcode_ctl procmail shorewall strace sudo tree for one, mageia-gfxboot-theme is here again... it didn't get selected in chrooted install from manually checked rpmsrate settings... where does this come from? is there a part in the installer that hardcodes certain packages? clearly according to the ddebug.log file, this mageia-gfxboot-theme gets selected during the choosePackages step and not later on... what am i missing here? does anyone have an idea? i'd like to get to the bottom of this, so a pointer in a direction would help me alot...
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 19:04:07 schreef Maarten Vanraes: > Op donderdag 22 maart 2012 17:57:29 schreef Thomas Backlund: > [...] > > > Installer already have a option to select "do not install suggests" > > and it does... > > that's exactly what i stated in my original email... > > PEOPLE ARE HIJACKING MY THREAD!!! of course, this was a joke at the time... but i should've known better... it appears the "no suggests option" is broken, since i did minimal install, with and without this, and i have exactly the same system... both times i have messages in ddebug.log saying: "... as suggested by ..." :-( can someone fix this one?
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 00:30:53 schreef Maarten Vanraes: [...] in a chroot, i did a test with requiring plymouth or suggesting it (from dracut) the difference is: with plymouth: 301 packages/335MB without plymouth: 294 packages/294MB i'm gonna try a minimal install and see how much this'll differ
Re: [Mageia-dev] installing minimal is not really that minimal
Op vrijdag 23 maart 2012 00:44:09 schreef Pascal Terjan: [...] > next: > > - lib64pam0 > > - bootsplash > > > > am i missing something, i have the feeling there's another file that has > > effect > > to these stuff? > > Well all the packages have plenty of dependencies... bootsplash is a good thing to look for: see the relevant part of ddebug.log: http://paste.pocoo.org/show/569781/ look for bootsplash, it gets selected, but never chosen nor required, but it's somehow there... and it should need CAT_X... to get selected... also see that the lib64drm_radeon1 is the very first in the ddebug.log...? why first? somehow it's been preselected, but it's not even in rpmsrate...
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 00:30:53 schreef Maarten Vanraes: > i did a network install > > and choose 'custom', then deselected everything, pressed next > > i got to the next menu of installation and left these to default: > > - no X > - no suggestions > - basic doc still on > - truly minimal was off > > but, i ended up with x libraries, fonts, etc... > > so i dug a bit deeper as to why and looked at the ddebug.log file: i looked once more, after the choose packages step: these are the categories selected: CAT_MINIMAL_DOCS CAT_SYSTEM CHARSET"C" LOCALES"en" LOCALES"_" LOCALES"en_US" META_CLASS"download" TRUE USB UTF8 this should be: man info man-pages eject ldetect harddrake sharutils locales iputils urpmi tmpwatch dmidecode ntfs-3g pm-utils numlock lftp mageia-release-Default these should result in a selection of 235 packages (i tried to track these manually through the rpmsrate file however, somehow other packages seem to be getting extra installed anyway (during the choosePackages step)! first package being selected is: - lib64drm_radeon1 ... even in rpmsrate radeon-firmware (the closest thing i can imagine), needs CAT_X next: - lib64pam0 - bootsplash am i missing something, i have the feeling there's another file that has effect to these stuff?
Re: [Mageia-dev] rescue has mount.nfs, but no statd
Op donderdag 22 maart 2012 10:14:27 schreef Maarten Vanraes: > at $dayjob, we're testing out the rescue. > > so at first we're doing an rsync, but we need to do it on a network disk. > > cifs was not available, but that's not a big issue. > > nfs was available, so we wanted to mount > > but the mount failed, because nfs module wasn't modprobed, and drvinst > didn't fix that (maybe it should modprobe nfs as well) > > or maybe mount.nfs should try to modprobe nfs if needed. > > however, statd wasn't there and it complained that it needed that for > locking > > atm we're doing -o nolock and that works... but... statd would be quite > usefull here... perhaps i should rephrase... can i fix this by adding statd on the rescue? or would this take too much space? plz advise...
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 17:57:29 schreef Thomas Backlund: [...] > Installer already have a option to select "do not install suggests" and it does... that's exactly what i stated in my original email... PEOPLE ARE HIJACKING MY THREAD!!!
Re: [Mageia-dev] installing minimal is not really that minimal
Op donderdag 22 maart 2012 08:40:14 schreef Thierry Vignaud: [...] ic your point, i too am interested in non-bloated install. however, this mail is specifically on installing WITHOUT suggests, or X. and in this particular case, i'd like to get it really really small. atm i'm looking at 670MB... which is way to bloated. at time of mga1, i had a similar install of around 450MB IIRC. > > thing is, without a full kickstart (which i don't want to, i'd like to > > keep doing partitioning manually, but kickstart seems not to do the > > interactive requests), i can't really make a minimal system to begin > > with... > > you can still do a semi automatic install. kickstart=file didn't seem to honor the interactive steps, and gave error because no / was found. defcfg=file seemed to have a little bit of default settings, but still i had to go through every step... i haven't found a way to have the middle ground. (or it needs some love)
[Mageia-dev] rescue has mount.nfs, but no statd
at $dayjob, we're testing out the rescue. so at first we're doing an rsync, but we need to do it on a network disk. cifs was not available, but that's not a big issue. nfs was available, so we wanted to mount but the mount failed, because nfs module wasn't modprobed, and drvinst didn't fix that (maybe it should modprobe nfs as well) or maybe mount.nfs should try to modprobe nfs if needed. however, statd wasn't there and it complained that it needed that for locking atm we're doing -o nolock and that works... but... statd would be quite usefull here...
Re: [Mageia-dev] Please push
Op donderdag 22 maart 2012 05:36:47 schreef Thomas Spuhler: > Please push php-apacheaccessor > > I upgraded it in svn to 0.1.1 in Dec. 2011, but it either didn't build or I > forgot to submit it. i'm pretty sure the requirements for freeze pushes are also at least that you must know it builds and works perfectly, on top of that it usually needs to be only bugfixes, or due to client/server changes that it is required... plz add more info to this request
[Mageia-dev] installing minimal is not really that minimal
i did a network install and choose 'custom', then deselected everything, pressed next i got to the next menu of installation and left these to default: - no X - no suggestions - basic doc still on - truly minimal was off but, i ended up with x libraries, fonts, etc... so i dug a bit deeper as to why and looked at the ddebug.log file: afaict dracut seems to require plymouth, and mageia-gfxboot-theme seems to be there no matter what option i choose from the summary, it seems it was already installed before the summary. thing is, without a full kickstart (which i don't want to, i'd like to keep doing partitioning manually, but kickstart seems not to do the interactive requests), i can't really make a minimal system to begin with... for this release, if at all possible, i'd still like to get a bit smaller for minimal setups, and like to present a nongraphic grub by default when X is unselected, and also have no need for gfxboot or plymouth when i don't have a graphic grub (even though this isn't the same) furthermore, if i'm installing without X the default runlevel target seems to still be the graphic one, and not the multi-user one... perhaps it's possible to have this as alternatives or something? which could be set by the CAT_X thingie? one installing one package and the other installing the other package?
[Mageia-dev] Freeze push request: urpmi-proxy-0.3.2
plz push urpmi-proxy It's a bugfix release with only one fix
Re: [Mageia-dev] Mageia ARM on Raspberry Pi (David Sj?lin)
Op woensdag 21 maart 2012 15:11:47 schreef brett: > Sorry for the double post - n00b to the dev-list here! > > I am among those to receive one of the first batch or two of raspberry > pi devices. > I would be happy to help with testing as I would LOVE to be able to use > Mageia on the device (as well as on a smartphone!) > > It seems that the ARM port has been rather inactive over the past year, > though? iinm we're actually still starting it up... contact rtp for more info regarding this.
Re: [Mageia-dev] [Freeze] please let in xonotic
Op vrijdag 16 maart 2012 16:15:22 schreef Pascal Terjan: > On Fri, Mar 16, 2012 at 15:11, Maarten Vanraes wrote: > > Op vrijdag 16 maart 2012 08:57:45 schreef Samuel Verschelde: > > [...] > > > >> It's already the case. If you re-read Ennael's mail about version > >> freeze, it says exactly that about exceptions. > >> > >> Samuel > > > > i'm looking at this mail, but don't see the exact same exceptions? > > > > https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html > > > > which email are you looking at? > > Criteria for accepting updates > -- > Since we aim for stability, the criteria would be near the ones of > updates. ah, like this... i read this as "near" (ie: not exact) and then the next parts were clarifications on the criteria (and the client/server protocol ones weren't in there). my bad, although in my defence, it could have been worded better, or a wiki policy with a link to it in this email. imho, if this were clearer, then i would guess misc would on his original email likely ask questions regarding client/server protocol changes as well... so i can only conclude that it might not have been 100% clear for everyone. (and i wasn't the only one)
Re: [Mageia-dev] [Freeze] please let in xonotic
Op vrijdag 16 maart 2012 08:57:45 schreef Samuel Verschelde: [...] > It's already the case. If you re-read Ennael's mail about version freeze, > it says exactly that about exceptions. > > Samuel i'm looking at this mail, but don't see the exact same exceptions? https://www.mageia.org/pipermail/mageia-dev/2012-March/012533.html which email are you looking at?
[Mageia-dev] Freeze push: mariadb (beta)
Please push mariadb: mariadb (and mysql) seem to have an odd method of increasing version number for each of there alpha/beta/rc/final versions. This updates to the 5.5 Beta release (it's not announced yet, but they are waiting for it to hit all the mirrors) Normally, the final is expected to released in about 2 weeks.
Re: [Mageia-dev] [Freeze] please let in xonotic
Op donderdag 15 maart 2012 18:35:04 schreef Juan Luis Baptiste: > On Thu, Mar 15, 2012 at 12:24 PM, Bertaux Xavier wrote: > >> If this is the case, then I say that xonotic should be allowed to be > >> updated. > > > > I'm not about to be okay with that, a version Freeze only accepts > > updates on bug fixes and security warnings, so RC to Release is OK but > > not to revision's change, otherwise that would mean that if fate xonotic > > in version 0.7 just before the Release we should built. > > To me this should be pushed Backport, to limit the update after Release > > Backports are for new versions, not bug fixes. In this case even as > this is a new version, the use of an older version of the game client > with a new game server version could bring issues to users, so that > makes this release more of a "bug fix release", because we are trying > to avoid any possible problem to our users, not because we want to > have the latest version of the game. If we leave the current version > and then a user reports a problem while playing the game, the 0.6 or > 0.7 or whatever version is available at the time would be pushed as an > update, not as a backport. well, the version policy is for updates. my point here is that we should maybe equalize & simplify our policys by having the same kind of "exceptions" in both policies. of course, there may be a good reason to now similar exceptions to both policies, it's just that atm, i don't see any.
Re: [Mageia-dev] freeze push: pidgin
Op woensdag 14 maart 2012 17:33:24 schreef Damien Lallement: > Hi, > > pidgin 2.10.2 just landed! > It builds on my laptop and I use it since a few hours now. > All is working. > Can we push it to cauldron? > A lot of big improvements like: > - GNOME3 better support > - NM better support > - fix crash > - update MSN protocol to MSNP18 > > http://developer.pidgin.im/wiki/ChangeLog > > Thanks, the MSN protocol will likely be necessary for it to work? can the crash fix and MSN patches be backported? or is it not doable?
Re: [Mageia-dev] Freeze push: firefox, xulrunner
Op woensdag 14 maart 2012 09:28:07 schreef D.Morgan: > On Wed, Mar 14, 2012 at 8:27 AM, Maarten Vanraes wrote: > > Op woensdag 14 maart 2012 03:02:57 schreef Funda Wang: > >> Hello, > >> > >> Could somebody push firefox 10.0.3esr and xulrunner 10.0.3esr into > >> cauldron? Thanks. > > > > i thought the maintainer wanted to push _only_ the esr version? or has > > something changed? > > funda told "10.0.3esr and xulrunner 10.0.3esr" so what is wrong for you > ? well, i thought you said you were only gonna do esr... as such to me, it seemed unnecessary to add "esr" ... it seems to imply the other versions gonna get pushed later... but then, maybe they will be backported or something... if you're ok with it, it's fine, i just noticed it and found it odd...
Re: [Mageia-dev] Freeze push: firefox, xulrunner
Op woensdag 14 maart 2012 03:02:57 schreef Funda Wang: > Hello, > > Could somebody push firefox 10.0.3esr and xulrunner 10.0.3esr into > cauldron? Thanks. i thought the maintainer wanted to push _only_ the esr version? or has something changed?
Re: [Mageia-dev] [Freeze] please let in xonotic
Op woensdag 14 maart 2012 01:16:23 schreef Juan Luis Baptiste: > On Sun, Mar 11, 2012 at 7:21 AM, Michael Scherer wrote: > > Le samedi 10 mars 2012 à 10:26 +0100, Thierry Vignaud a écrit : > >> Hi > >> > >> please let in xonotic-0.6.0 > >> It's just a game that impacts nothing else. > > > > Niet. > > > > That's bugfix or security fixes. > > Well I vote to be updated, why ? global game servers are currently > running 0.6.0, and by personal experience over several years (omg how > much time wasted on this) these FPS games need to have the same > client/server version, in some cases different versions won't work at > all (ie. Urban Terror 3.7 -> 4.0 -> 4.1, Warsow 0.5 -> 0.8 etc). > > I just did the test of running a 0.5.0 client on a 0.6.0 server and it > works, but a big and annoying yellow announce floats across the screen > remaining you that a new version is available. I also talked with one > dev over IRC and he told me that there could be issues when running > different client/server versions. > > So just to be on the safe side this new version should be pushed. If > not then probably we will need to do it later as an update if any > problems arise. I commit my self to test the new version, I know very > well how this game works. IINM we have some kind of exception regarding games for their client/server relation regarding updates vs backports? if so, then perhaps we could have the same policy wrt updates to version freeze?
Re: [Mageia-dev] Odd Window framing in curses part of install
Op dinsdag 13 maart 2012 20:47:48 schreef Frank Griffin: > On 03/13/2012 02:40 PM, Frank Griffin wrote: > > Just a small thing, but the curses windows which appear at the start > > of isolinux prompting for the type of install, server address and so > > forth have suddenly had their borders filled with characters - "U" at > > the left corner, "A" along the top, and an upside-down question mark > > at the right corner. > > > > I assume that curses is using ASCII extended graphics characters to > > draw the perimeter of the windows, but that the install itself is > > using UTF-8 or some other character set which doesn't have them. > > My bad. This is bug 4894. I just didn't guess it from the title. my bad, if you find a better title, please do
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 22:02:56 schreef Guillaume Rousse: > Le 12/03/2012 21:27, Maarten Vanraes a écrit : > > but we should also try to prevent irritation if it's possible... we're > > short on contributors and I don't like to decrease motivation... I guess > > that makes me more lax than others. > > OK, I want a new version of cowsay. Right now. Otherwise I'm leaving. > Far away and forever. ok, fine, your point is noted...
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 10:56:57 schreef Michael Scherer: > Le lundi 12 mars 2012 à 08:29 +0100, Maarten Vanraes a écrit : > > to get back on topic: perhaps it's not unreasonable to allow a timelimit > > exception, like for instance 3 or 4 days where "i forgot it was freeze or > > didn't make it in time AND it's not likely to mess everything up" kind of > > reason... > > That was already discussed when we discussed the release cycle. And > basically, that would just "let's reduce the freeze by 3/4 days in a > more inefficient way". You just move the bickering at the 3/4 days limit > ( "but it could have bene if I had submitted yesterday" ) instead of the > beggining of the freeze, and you take time to the people who are > submitting, since they get message, have to warn packager about "it > doesn't work" ( as it happened several time last freeze period ). [...] > So next time, maybe we should have a pure good faith based system, [...] > - everybody can do as he see fit I'll take this suggestion as a cynic suggestions and ignore it for now [...] > Patch welcome, but frankly, I think there is a point where the duty of > being informed must be on the packagers. It is rather depressing to > realize that people do not read the announce you send ( and what is more > depressing is the number of those that don't once you start to dig out > ). > > If some people missed the announce, maybe we should ask them "where do > you read information about the project and where don't you read", so we > can identify the communication channel that should be used and those > that shouldn't, as i am not sure that hammering more is the solution. I do understand both your pov, and i do remember that discussion. IMHO: good strict policies are good, and exceptions are exceptions. but we should also try to prevent irritation if it's possible... we're short on contributors and I don't like to decrease motivation... I guess that makes me more lax than others.
Re: [Mageia-dev] [Freeze] please let in xonotic
Op maandag 12 maart 2012 07:53:38 schreef David W. Hodgins: [...] > My understanding was that Magea 1 supported updating from Mandriva > 2010.2 + Contrib + PLF-Free. > > There were several updates submitted to qa a few days ago, that are > only available in backports in Mdv 2010.2. [...] IMHO backports could be "supported" under Mageia backports, not in regular media. Keeping in mind our limited resources, nonetheless, several of these bugs which seemed to require workaround upon workaround, should get fixed sooner rather than later, because it seems to be getting more complicated or more discussed (and in generally too much resources being spent on it) i'm thinking of: - backports - noarch linking - bug 2317 - livemedia - or in general what we promise ( or rather to be careful what and how we promise): if we say: "there are no livemedia yet, but we're working on it to get it in the next few weeks" ... some people become angry, but you can also say: "There's a major bug preventing us from making livemedia, but we're working on them" and possibly even updating it when it becomes clear it'll be for the next release into "This beta release doesn't have any livemedia, we're hoping to have the next beta release containing livemedia" Similar with backports: it's been promised this time without timelimit, but people seem to be convinced it'll never make it. 3rd party repositories popping up etc... It does not make us look good. and I'm getting to the point where the resources spent on discussing backports seem to be larger than the eventual losses in resources that would have been due to backports being open. But now of all times, backports shouldn't open, rather in the first week after release of mga2 would be a nice timing. to get back on topic: perhaps it's not unreasonable to allow a timelimit exception, like for instance 3 or 4 days where "i forgot it was freeze or didn't make it in time AND it's not likely to mess everything up" kind of reason... But i think the point is now becoming moot if temporary freeze of Beta2 is in effect... (not sure if it is, but i think i saw something regarding it) (about communication: maybe it's more prudent to have a messagebox above http://pkgsubmit.mageia.org/ telling us about various freezes and upcoming soon freezes, even though as a packager it's my task to read meeting logs and keeping myself up2date)
Re: [Mageia-dev] Deprecating startx
Op zaterdag 10 maart 2012 22:06:09 schreef Florian Hubold: > Am 10.03.2012 14:15, schrieb eatdirt: > > On 10/03/12 10:12, Maarten Vanraes wrote: > >> I have a pentium 66MHz (not MMX) > > > > With the turbo button 33 -> 66 ? Man, that's a proper collector :) > > Normally turbo button was only effective for 468DX/586DX type > of machines, not for pentium IIRC. you likely mean 486/586 and alas 586 machines are called pentium there's a difference between pentium and pentium MMX though, even though i recall there are even pentium MMX's who had a turbo button... if it was really effective of not, that's another matter entirely...
Re: [Mageia-dev] Deprecating startx
Op zaterdag 10 maart 2012 08:23:29 schreef zezinho: > Le vendredi 9 mars 2012 23:56:28, eatdirt a écrit : > > [got another reason for startx, my pentium 133MHz running mga.1 does not > > like kdm, even xdm :)] > > Ah, I feel less alone (well, Pentium 166 MMX for my side. I have a pentium 66MHz (not MMX)
Re: [Mageia-dev] deprecate text installer
Op zaterdag 10 maart 2012 00:25:46 schreef Thierry Vignaud: > On 9 March 2012 19:44, Maarten Vanraes wrote: > > yeah i already confirmed it slightly working, there's still a curses bug > > i presume see the bug report > > You shouldn't have mixed this with that bug report. > (btw this looks like a virtuabl bios issue imho) oh, sorry, i'll try it out on a real machine tomorrow. allthough, the pictures i have from the text installer from mga1 didn't have this, and the vbox host and version is still the same...
Re: [Mageia-dev] deprecate text installer
Op vrijdag 09 maart 2012 17:42:33 schreef Thierry Vignaud: > On 9 March 2012 17:29, Maarten Vanraes wrote: > > ah, you fixed it? thanks alot, i'll go test immediately > > No, I mean you're all lyers :-) you mean liars? > More seriously, on x86_64 you 'll need the 48132096 bytes > install/stage2/mdkinst.sqfs file from Mar 9 2012 13:22 > (different size on i586 of course) yeah i already confirmed it slightly working, there's still a curses bug i presume see the bug report
Re: [Mageia-dev] deprecate text installer
Op vrijdag 09 maart 2012 14:29:42 schreef Thierry Vignaud: > On 9 March 2012 07:42, Maarten Vanraes wrote: > >> > If we deprecate and remove the abillity to use a text installer, we > >> > are effectlively blocking blind users from beeing able to install the > >> > system. > > > > I know how you guys feel, but the fact is that we're at beta1 and it's > > not working and it doesn't seem to be a simple problem... > > > > we're trying to fix it, but it doesn't seem good atm: > > https://bugs.mageia.org/show_bug.cgi?id=4724 > > > > and if it's not working, we shouldn't advertise it > > You lie. > It's working perfectly. ah, you fixed it? thanks alot, i'll go test immediately
Re: [Mageia-dev] deprecate text installer
Op vrijdag 09 maart 2012 04:29:39 schreef Liam R E Quin: > On Fri, 2012-03-09 at 04:11 +0100, Johnny A. Solbu wrote: > > If we deprecate and remove the abillity to use a text installer, we > > are effectlively blocking blind users from beeing able to install the > > system. [..] I know how you guys feel, but the fact is that we're at beta1 and it's not working and it doesn't seem to be a simple problem... we're trying to fix it, but it doesn't seem good atm: https://bugs.mageia.org/show_bug.cgi?id=4724 and if it's not working, we shouldn't advertise it
Re: [Mageia-dev] Deprecating startx
Op woensdag 07 maart 2012 22:34:50 schreef Samuel Verschelde: [...] > I apparently missed a few meetings or e-mails where this was discussed, but > wasn't the initial plan to keep sysvinit by default in mga2 and switch to > systemd by default in mga3? Wasn't the switch to systemd by default in > cauldron a temporary switch in order to get more testing? > > Samuel that is what i originally thought too, but i guess i was mistaken
[Mageia-dev] deprecate text installer
considering https://bugs.mageia.org/show_bug.cgi?id=4724 and that it's likely not working in cauldron for months, and also considering it's beyond our perl guru jq and our drakx-guru tv, and considering it looks like google didn't help... and considering there's 4 or 5 text-installer bugs i wanted to test out... perhaps we should consider in fact that text installer does not work... after all, if we get this fixed, there's still the other text-installer bugs... maybe it's premature for me, but considering this is version freeze... we're getting closer to the end... WDYT?
Re: [Mageia-dev] Minimum install of cauldron don't start console
Op dinsdag 06 maart 2012 21:19:49 schreef Colin Guthrie: > 'Twas brillig, and Maarten Vanraes at 06/03/12 20:09 did gyre and gimble: > > Op dinsdag 06 maart 2012 20:52:02 schreef Colin Guthrie: > >> 'Twas brillig, and Maarten Vanraes at 06/03/12 19:41 did gyre and gimble: > >>> Op dinsdag 06 maart 2012 14:28:38 schreef Colin Guthrie: > >>> [...] > >>> > >>>> Now I'm not sure on the logic inside the Xserver that is used to > >>>> search for a free getty. it maybe starts from the current one and > >>>> counts up. If so, this logic should (IMO) be changed to start > >>>> searching from 1 that way it would relatively consistently start on > >>>> vt1 even when restarted from tty2. > >>>> > >>>> Col > >>> > >>> have you been successfull with 2 user sessions? > >> > >> As in logging out and back in again or with fast user switching? > >> > >> The former has worked quite happily for me. Not tested the latter but I > >> expect there to be some quirks. > >> > >> Col > > > > err, no, i mean 2 X sessions. > > > > often i have one KDE session running on vt8 and one for my wife on vt9 > > and sometimes on for my daughter at vt10... > > OK, so fast user switching then. > > > the question is, with the prefdm only conflicting with the first getty, > > will several X sessions be possible? > > Yeah. They should, in theory at least, start on vt2 and vt3, tho' this > may depend on the desktop itself. With GDM+Gnome the second session > starts on tty2, the third on tty3 etc. > > There is a caveat however. If you have switched to tty2 before picking > the "Login as another user" option, then autovt will have kicked in and > started a getty there. It then "hogs" tty2 and prevents X from using it. > > Of course if I manage to get my idea working, switching to tty2 when in > graphical.target will actually give you a graphical login prompt anyway, > so pretty much the same thing as picking the "Login as another user" > option from within the first graphical session. > > Col ic... i do hope we get some kind of vt that will always be tty? i do sometimes require that, when getting too much load and OOM'ing... also, it'd be nice to have as possibility (in the dm) to start a tty session instead of a graphical session (as an alternative) but i guess the important parts are all the other things...
Re: [Mageia-dev] Minimum install of cauldron don't start console
Op dinsdag 06 maart 2012 20:52:02 schreef Colin Guthrie: > 'Twas brillig, and Maarten Vanraes at 06/03/12 19:41 did gyre and gimble: > > Op dinsdag 06 maart 2012 14:28:38 schreef Colin Guthrie: > > [...] > > > >> Now I'm not sure on the logic inside the Xserver that is used to search > >> for a free getty. it maybe starts from the current one and counts up. If > >> so, this logic should (IMO) be changed to start searching from 1 that > >> way it would relatively consistently start on vt1 even when restarted > >> from tty2. > >> > >> Col > > > > have you been successfull with 2 user sessions? > > As in logging out and back in again or with fast user switching? > > The former has worked quite happily for me. Not tested the latter but I > expect there to be some quirks. > > Col err, no, i mean 2 X sessions. often i have one KDE session running on vt8 and one for my wife on vt9 and sometimes on for my daughter at vt10... the question is, with the prefdm only conflicting with the first getty, will several X sessions be possible?
Re: [Mageia-dev] Minimum install of cauldron don't start console
Op dinsdag 06 maart 2012 20:50:11 schreef Colin Guthrie: [...] > >> Yeah. I would agree there has to be a limit. I'd say RC2 should be that > >> limit. If I've not found a better way of doing things by then, I'll do > >> whatever is needed to make a getty appear... > > > > There is no RC2 planned... > > > > Planned timetable is: > > > > beta2: March 15th > > rc: April 10th > > final: May 3rd > > OK, then I guess "by the rc" then :) > > Col release freeze is April 7th...
Re: [Mageia-dev] Minimum install of cauldron don't start console
Op dinsdag 06 maart 2012 14:28:38 schreef Colin Guthrie: [...] > Now I'm not sure on the logic inside the Xserver that is used to search > for a free getty. it maybe starts from the current one and counts up. If > so, this logic should (IMO) be changed to start searching from 1 that > way it would relatively consistently start on vt1 even when restarted > from tty2. > > Col have you been successfull with 2 user sessions?
Re: [Mageia-dev] Missing noarch package from i586 repository
Op dinsdag 06 maart 2012 15:39:53 schreef Pascal Terjan: > On Tue, Mar 6, 2012 at 14:39, Pascal Terjan wrote: > > On Tue, Mar 6, 2012 at 14:29, Oliver Burger wrote: > >> According to check.mageia.org, dmenu has a broken dependency, since > >> terminus-font is missing from i586 repositories. > >> According to svnweb, it was last commited 7 months ago as a noarch > >> package by wally. And it was not shown as broken dependency this > >> weekend so it must have been deleted from the mirrors in the last few > >> days out of some reason unknown to me. Is this a general problem on > >> noarch packages or just some isolated thing with this package? > > > > Hmm I restored it but I have no idea what happened and it is not in > > old/ (the place where we move things to be deleted so that they stay > > around for a few weeks) > > [schedbot@valstar ~]$ diff <(find > /distrib/bootstrap/distrib/cauldron/i586/ -name '*noarch.rpm' | xargs > -n1 basename |sort) <(find /distrib/bootstrap/distrib/cauldron/x86_64/ > -name '*noarch.rpm' | xargs -n1 basename | sort) | grep '^[<>]' > > > audiokonverter-5.9.1-1.mga2.tainted.noarch.rpm > > < bluez-firmware-1.2-6.mga1.noarch.rpm > > > jgoodies-animation-javadoc-1.3.0-1.mga2.noarch.rpm > > xml-commons-apis-manual-1.4.01-6.mga2.noarch.rpm maybe unrelated, i've rebuilt some packages these last few days because they were missing one of the subpackages
Re: [Mageia-dev] Network lost with last update
Op maandag 05 maart 2012 18:56:36 schreef Colin Guthrie: [...] > Of course those without internet access might have trouble reading the > mailing list :p > > Col /me facepalms
Re: [Mageia-dev] Versions freeze
Op zondag 04 maart 2012 11:47:14 schreef Michael Scherer: [...] > > maybe we could have the meetbot send it to another mailing list and the > > people who don't frequently are able to follow the meetings can > > subscribe to that. > > Send patchs upstream, and we will use it sooner or later. I'm offering it as an alternative suggestion to that person who complains of not being in the meetings... I'm almost always in the meetings, and if not, i can find the meetinglogs without a mail being sent to me... though if this suggestion is fitting for that person, he sure can file some patches...
Re: [Mageia-dev] Versions freeze
Op zondag 04 maart 2012 11:38:08 schreef Michael Scherer: [...] > Why assume that we are late ? > > If there is no post "we are late", then we are not. Such a post would usually come late :-)
Re: [Mageia-dev] Versions freeze
Op zaterdag 03 maart 2012 22:34:41 schreef Sander Lepik: > > Well, actually I'm sure it could. But why? All meeting logs are publicly > > available at https://meetbot.mageia.org/ > > Why? Because now i know this link for some time and then i forget it again > > :) Sorry but Mageia isn't the only project where i'm contributing. I just > > can't remember everything. But thanks for the link. > > -- > Sander maybe we could have the meetbot send it to another mailing list and the people who don't frequently are able to follow the meetings can subscribe to that. i don't think it's a bad idea to read what has happened in the meetings as a packager team member...
Re: [Mageia-dev] Versions freeze
Op zaterdag 03 maart 2012 10:36:55 schreef Thomas Backlund: > 03.03.2012 11:24, Michael Scherer skrev: > > Le vendredi 02 mars 2012 à 20:53 +0100, Maarten Vanraes a écrit : > >> Op vrijdag 02 maart 2012 20:16:11 schreef Thomas Backlund: > >>> 02.03.2012 21:08, Dimitri Jakov skrev: > >>>> Besides... GNOME 3.4 is going to be released on March 28 - does that > >>> > >>> Yes we know... > >>> > >>>> mean that we won't be able to ship it with Mageia 2? > >>> > >>> Nope, we have that as an exception to the freeze... > >>> (that's why we already run 3.3.x) > >>> > >>> we will have Gnome 3.4.x and KDE 4.8.x in Mageia 2 > >> > >> also, I hope mariadb-5.5.x final (right now we have 5.5.20 which is the > >> alpha version; beta will come quite soon, then the rc and finals follow > >> pretty fast and these only contain bugfixes) > > > > Next time, maybe waiting for the beta would be better, cauldron is not > > mean to be a playground for testing upstream softwares when we do not > > have a strong assurance that the stable will end i the stable release. > > Actually in this case it is ok, since we've been tracking upstream 5.5.x > branch with the target for 5.5.x final, so "alpha" in this case > only means fully synced with mysql 5.5 and afaik all intended mariadb > patches merged... yes, and so far that haven't been any complaints yet, waiting for mikala, since he's the most likely person to have issues about it. > They are only a bit late :/ yes :-( allthough according to upstream, there seems to be a good chance it will be released as final quite quickly > > If everybody start to do that, we spend more time on upgrading to > > version that should have been stable than fixing others bugs. > > > > And if upstream could also try to be a little bit less original and > > follow some easy to grasp convetion about version number. yes, it seems they will upgrade the version to +1 for beta and so forth. but they consider the major versions 5.5 the real version. but still, took me a while to figure it out...
Re: [Mageia-dev] executable libraries
Op vrijdag 02 maart 2012 21:29:05 schreef Anssi Hannula: > 02.03.2012 21:57, Maarten Vanraes kirjoitti: > > Op vrijdag 02 maart 2012 15:22:23 schreef Anssi Hannula: > >> 02.03.2012 00:17, Maarten Vanraes kirjoitti: > >>> Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: > >>> [...] > >>> > >>>>> does this mean debug info fails for these? > >>>> > >>>> I'm not immediately sure (I never remember how the debug/stripping > >>>> stuff works exactly), but I think either a) debug symbols extraction > >>>> and thus -debug packaging, b) stripping, or c) both will fail with > >>>> non-executable shared libs. > >>> > >>> in that case i guess we would need a policy or bs check to make sure we > >>> don't fail some libraries debug and strip > >> > >> Possibly. > >> > >> Interestingly, Debian policy disallows executable permission on shared > >> libs: > >> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs- > >> ru ntime > >> > >> "Shared libraries should not be installed executable, since the dynamic > >> linker does not require this and trying to execute a shared library > >> usually results in a core dump." > > > > which is sort of strange, since libc is actually executable by design. > > > > i see where they are coming from > > > > but i guess the first part of this is, why is there a find with > > executable restrictions for the code relating to stripped binaries and > > debug? > > > > is it because it's also used for real executables? > > I guess it is there just to speed up the process, otherwise it would > have to run 'file' for every file in the package (and many packages have > lots of files). still, it seems kind of weird, there are rpmlint checks for unstripped libraries, but i do have 34 libraries not marked as executable, while the stripping+ debug seems to target only executables? i wonder if we should make another check library unset as executable or even check what happened with these libraries not marked as executable?
Re: [Mageia-dev] executable libraries
Op vrijdag 02 maart 2012 15:22:23 schreef Anssi Hannula: > 02.03.2012 00:17, Maarten Vanraes kirjoitti: > > Op donderdag 01 maart 2012 23:05:35 schreef Anssi Hannula: > > [...] > > > >>> does this mean debug info fails for these? > >> > >> I'm not immediately sure (I never remember how the debug/stripping stuff > >> works exactly), but I think either a) debug symbols extraction and thus > >> -debug packaging, b) stripping, or c) both will fail with non-executable > >> shared libs. > > > > in that case i guess we would need a policy or bs check to make sure we > > don't fail some libraries debug and strip > > Possibly. > > Interestingly, Debian policy disallows executable permission on shared > libs: > http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-ru > ntime > > "Shared libraries should not be installed executable, since the dynamic > linker does not require this and trying to execute a shared library > usually results in a core dump." which is sort of strange, since libc is actually executable by design. i see where they are coming from but i guess the first part of this is, why is there a find with executable restrictions for the code relating to stripped binaries and debug? is it because it's also used for real executables?
Re: [Mageia-dev] Versions freeze
Op vrijdag 02 maart 2012 20:16:11 schreef Thomas Backlund: > 02.03.2012 21:08, Dimitri Jakov skrev: > > Besides... GNOME 3.4 is going to be released on March 28 - does that > > Yes we know... > > > mean that we won't be able to ship it with Mageia 2? > > Nope, we have that as an exception to the freeze... > (that's why we already run 3.3.x) > > we will have Gnome 3.4.x and KDE 4.8.x in Mageia 2 also, I hope mariadb-5.5.x final (right now we have 5.5.20 which is the alpha version; beta will come quite soon, then the rc and finals follow pretty fast and these only contain bugfixes)
