Re: [Mageia-dev] Shutdown button by default in Mageia 2 Gnome request
On Tue, Apr 03, 2012 at 02:21:54AM +0100, Sebastian sebsebseb wrote: > Well I guess really in general there should be a lot of extensions > in the repo's for Gnome Shell, and not just for shut down? I mean > extensions give people more choice on what can be done with Gnome, > just like Firefox extensions give people more choice in what can be > done with Firefox. Extensions are on https://extensions.gnome.org/. You'll have to manually figure out when people upload new versions of their extensions, also figure out how to download. The entire site is setup so people can install their extensions using the site. It is not setup to make it easy to package them for the simple fact that it takes development time + might complicate the UI for something that is just not the focus. So if you want to package extensions, it'll take some effort. During 3.0, some extensions were released as tarballs... but I don't think anything like that is really released anymore. -- Regards, Olav
Re: [Mageia-dev] Shutdown button by default in Mageia 2 Gnome request
On Tue, Apr 03, 2012 at 02:36:43AM +0100, Sebastian sebsebseb wrote: > On 29/03/12 10:47, Olav Vitters wrote: > >PS: Alt, not tab. And you can right click 'bkor' and see the real name ;) > Yep alt tab. Alt tab is not it. Just alt and click, press enter, whatever. -- Regards, Olav
Re: [Mageia-dev] plymouth gone nuts ?
On 04/03/2012 02:43 AM, Colin Guthrie wrote: 'Twas brillig, and JA Magallón at 03/04/12 01:13 did gyre and gimble: On 04/03/2012 02:07 AM, JA Magallón wrote: Hi... With latest updates, I noticed that GDM again started in tty2, and tty1 is still stuck on bootscreen/plymouth dots. I get a message on tty1 about "wait-for-playmouth-quit failed, see systemctl status...". And GDM starts on tty2. Something weird is happpening: cicely:~# systemctl --all --full | grep plym systemd-ask-password-plymouth.path loaded active waiting Forward Password Requests to Plymouth Directory Watch plymouth-quit-wait.service loaded failed failed Wait for Plymouth Boot Screen to Quit plymouth-quit.service loaded inactive dead Terminate Plymouth Boot Screen plymouth-read-write.service loaded inactive dead Tell Plymouth To Write Out Runtime Data plymouth-start.service loaded inactive dead Show Plymouth Boot Screen systemd-ask-password-plymouth.service loaded inactive dead Forward Password Requests to Plymouth cicely:~# ps -ef | grep plym root 161 1 0 01:56 ? 00:00:00 /bin/plymouthd --attach-to-session --pid-file /run/plymouth/pid root 29109 8671 0 02:05 pts/1 00:00:00 grep --color plym Any idea ? I have noticed this, plz correct me if I'm wrong: werewolf:/lib/systemd/system# grep After display-manager.service After=livesys-late.service systemd-user-sessions.service After=getty@tty1.service plymouth-quit.service werewolf:/lib/systemd/system# grep After plymouth-quit.service After=rc-local.service plymouth-start.service werewolf:/lib/systemd/system# grep After plymouth-quit-wait.service After=rc-local.service plymouth-start.service Should not all the chain be: display-manager.service -> after plymouth-quit-wait.service plymouth-quit-wait.service -> after plymouth-quit.service No. plymouth-quit-wait will simply hang until plymouth quits of it's own accrord. If you actively quit plymouth first via plymouth-quit then there is literally no point in running plymouth-quit-wait as it'll just exit immediately. Ah, thanks. I jus thought that 'plymouth quit' was asynchronous, and the -wait script just made sure to wait before launching DM... Also u're forgetting about the Conflicts= directives... display-manager.service:Conflicts=getty@tty1.service plymouth-quit.service display-manager specifically conflicts with plymouth-quit.service (as it internally quits plymouth or allows a smooth transition if appropriate). So the ordering is correct as it stands. Now the question is what is preventing plymouth from being quit? As I said, display-manager should do it for you (see the /etc/X11/prefdm script), or simply let GDM do it itself. I'll see what I can dig up. Col -- J.A. Magallon \ Winter is coming...
Re: [Mageia-dev] Shutdown button by default in Mageia 2 Gnome request
On 29/03/12 10:47, Olav Vitters wrote: PS: Alt, not tab. And you can right click 'bkor' and see the real name ;) Yep alt tab. In my client Konversation it's hover over the nick in the nicks list for example, which I could have done. Anyway Remmy told me soon after in #mageia-dev that it was you. By the way in my other email at the end I meant, extensions shouldn't usually delay the release of a new version of Gnome in distro's, or in most distro's that use it in general. Some distro's may rely on extensions a lot in Gnome so have to wait for them to be compatible before using a new version for example. From Sebastian sebsebseb
Re: [Mageia-dev] Shutdown button by default in Mageia 2 Gnome request
I am replying later than intended. On 29/03/12 10:46, Olav Vitters wrote: On Wed, Mar 28, 2012 at 08:07:14PM +0100, Sebastian sebsebseb wrote: Anyway going back on topic I strongly believe that Mageia 2's Gnome Shell should be showing the shut down button by default, even though like Olav and I assume Bkor as well, I would like Mageia's Gnome to stay rather close to upstream by default at the moment. I don't care about this specific topic (shutdown button). I was expecting that kind of reply, but I think the email was worth a try anyway :). Oxygen is something that I'd wish wasn't the default within GNOME 3. I was using that as an example of Mageia dong something to Gnome that wasn't upstream. Since what I was suggesting isn't upstream. For the shut down button: if someone packages it and keeps it up to date, handles bugs if any (meaning: maintainer), then cool. Well I guess really in general there should be a lot of extensions in the repo's for Gnome Shell, and not just for shut down? I mean extensions give people more choice on what can be done with Gnome, just like Firefox extensions give people more choice in what can be done with Firefox. Personally I think it would be a rather good thing from a user point of view, if Gnome Shell became much more like Firefox, as in had many extensions available for it. Don't forget that GNOME shell extensions only work with a specific version and I won't wait with updating gnome-shell or look at the shutdown button package if it happens to be packaged when gnome-shell is updated (IMO: package upgrades should be automated as much as possible). Well yes extensions should never delay the release of Gnome itself in distros, or in general. From Sebastian sebsebseb
Re: [Mageia-dev] plymouth gone nuts ?
'Twas brillig, and Colin Guthrie at 03/04/12 01:43 did gyre and gimble: > 'Twas brillig, and JA Magallón at 03/04/12 01:13 did gyre and gimble: >> On 04/03/2012 02:07 AM, JA Magallón wrote: >>> Hi... >>> >>> With latest updates, I noticed that GDM again started in tty2, and >>> tty1 is >>> still stuck on bootscreen/plymouth dots. >>> I get a message on tty1 about "wait-for-playmouth-quit failed, see >>> systemctl status...". >>> And GDM starts on tty2. >>> Something weird is happpening: >>> >>> cicely:~# systemctl --all --full | grep plym >>> systemd-ask-password-plymouth.path loaded active waiting Forward >>> Password Requests to Plymouth Directory Watch >>> plymouth-quit-wait.service loaded failed failed Wait for Plymouth Boot >>> Screen to Quit >>> plymouth-quit.service loaded inactive dead Terminate Plymouth Boot Screen >>> plymouth-read-write.service loaded inactive dead Tell Plymouth To >>> Write Out Runtime Data >>> plymouth-start.service loaded inactive dead Show Plymouth Boot Screen >>> systemd-ask-password-plymouth.service loaded inactive dead Forward >>> Password Requests to Plymouth >>> >>> cicely:~# ps -ef | grep plym >>> root 161 1 0 01:56 ? 00:00:00 /bin/plymouthd --attach-to-session >>> --pid-file /run/plymouth/pid >>> root 29109 8671 0 02:05 pts/1 00:00:00 grep --color plym >>> >>> Any idea ? >>> >> >> I have noticed this, plz correct me if I'm wrong: >> >> werewolf:/lib/systemd/system# grep After display-manager.service >> After=livesys-late.service systemd-user-sessions.service >> After=getty@tty1.service plymouth-quit.service >> >> werewolf:/lib/systemd/system# grep After plymouth-quit.service >> After=rc-local.service plymouth-start.service >> >> werewolf:/lib/systemd/system# grep After plymouth-quit-wait.service >> After=rc-local.service plymouth-start.service >> >> Should not all the chain be: >> >> display-manager.service -> after plymouth-quit-wait.service >> plymouth-quit-wait.service -> after plymouth-quit.service > > No. > > plymouth-quit-wait will simply hang until plymouth quits of it's own > accrord. If you actively quit plymouth first via plymouth-quit then > there is literally no point in running plymouth-quit-wait as it'll just > exit immediately. > > Also u're forgetting about the Conflicts= directives... > > display-manager.service:Conflicts=getty@tty1.service plymouth-quit.service > > display-manager specifically conflicts with plymouth-quit.service (as it > internally quits plymouth or allows a smooth transition if appropriate). > > So the ordering is correct as it stands. > > Now the question is what is preventing plymouth from being quit? As I > said, display-manager should do it for you (see the /etc/X11/prefdm > script), or simply let GDM do it itself. > > I'll see what I can dig up. OK, replicated here. I suspect that GDM simply isn't issuing the proper commands to quit plymouth. Will require some further investigation. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
[Mageia-dev] Freeze-push: rpm-helper
Various systemd migrations fixes. Cheers -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] plymouth gone nuts ?
'Twas brillig, and JA Magallón at 03/04/12 01:13 did gyre and gimble: > On 04/03/2012 02:07 AM, JA Magallón wrote: >> Hi... >> >> With latest updates, I noticed that GDM again started in tty2, and >> tty1 is >> still stuck on bootscreen/plymouth dots. >> I get a message on tty1 about "wait-for-playmouth-quit failed, see >> systemctl status...". >> And GDM starts on tty2. >> Something weird is happpening: >> >> cicely:~# systemctl --all --full | grep plym >> systemd-ask-password-plymouth.path loaded active waiting Forward >> Password Requests to Plymouth Directory Watch >> plymouth-quit-wait.service loaded failed failed Wait for Plymouth Boot >> Screen to Quit >> plymouth-quit.service loaded inactive dead Terminate Plymouth Boot Screen >> plymouth-read-write.service loaded inactive dead Tell Plymouth To >> Write Out Runtime Data >> plymouth-start.service loaded inactive dead Show Plymouth Boot Screen >> systemd-ask-password-plymouth.service loaded inactive dead Forward >> Password Requests to Plymouth >> >> cicely:~# ps -ef | grep plym >> root 161 1 0 01:56 ? 00:00:00 /bin/plymouthd --attach-to-session >> --pid-file /run/plymouth/pid >> root 29109 8671 0 02:05 pts/1 00:00:00 grep --color plym >> >> Any idea ? >> > > I have noticed this, plz correct me if I'm wrong: > > werewolf:/lib/systemd/system# grep After display-manager.service > After=livesys-late.service systemd-user-sessions.service > After=getty@tty1.service plymouth-quit.service > > werewolf:/lib/systemd/system# grep After plymouth-quit.service > After=rc-local.service plymouth-start.service > > werewolf:/lib/systemd/system# grep After plymouth-quit-wait.service > After=rc-local.service plymouth-start.service > > Should not all the chain be: > > display-manager.service -> after plymouth-quit-wait.service > plymouth-quit-wait.service -> after plymouth-quit.service No. plymouth-quit-wait will simply hang until plymouth quits of it's own accrord. If you actively quit plymouth first via plymouth-quit then there is literally no point in running plymouth-quit-wait as it'll just exit immediately. Also u're forgetting about the Conflicts= directives... display-manager.service:Conflicts=getty@tty1.service plymouth-quit.service display-manager specifically conflicts with plymouth-quit.service (as it internally quits plymouth or allows a smooth transition if appropriate). So the ordering is correct as it stands. Now the question is what is preventing plymouth from being quit? As I said, display-manager should do it for you (see the /etc/X11/prefdm script), or simply let GDM do it itself. I'll see what I can dig up. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] plymouth gone nuts ?
On 04/03/2012 02:07 AM, JA Magallón wrote: Hi... With latest updates, I noticed that GDM again started in tty2, and tty1 is still stuck on bootscreen/plymouth dots. I get a message on tty1 about "wait-for-playmouth-quit failed, see systemctl status...". And GDM starts on tty2. Something weird is happpening: cicely:~# systemctl --all --full | grep plym systemd-ask-password-plymouth.path loaded active waiting Forward Password Requests to Plymouth Directory Watch plymouth-quit-wait.service loaded failed failed Wait for Plymouth Boot Screen to Quit plymouth-quit.service loaded inactive dead Terminate Plymouth Boot Screen plymouth-read-write.service loaded inactive dead Tell Plymouth To Write Out Runtime Data plymouth-start.service loaded inactive dead Show Plymouth Boot Screen systemd-ask-password-plymouth.service loaded inactive dead Forward Password Requests to Plymouth cicely:~# ps -ef | grep plym root 161 1 0 01:56 ? 00:00:00 /bin/plymouthd --attach-to-session --pid-file /run/plymouth/pid root 29109 8671 0 02:05 pts/1 00:00:00 grep --color plym Any idea ? I have noticed this, plz correct me if I'm wrong: werewolf:/lib/systemd/system# grep After display-manager.service After=livesys-late.service systemd-user-sessions.service After=getty@tty1.service plymouth-quit.service werewolf:/lib/systemd/system# grep After plymouth-quit.service After=rc-local.service plymouth-start.service werewolf:/lib/systemd/system# grep After plymouth-quit-wait.service After=rc-local.service plymouth-start.service Should not all the chain be: display-manager.service -> after plymouth-quit-wait.service plymouth-quit-wait.service -> after plymouth-quit.service Trying now... -- J.A. Magallon \ Winter is coming...
[Mageia-dev] plymouth gone nuts ?
Hi... With latest updates, I noticed that GDM again started in tty2, and tty1 is still stuck on bootscreen/plymouth dots. I get a message on tty1 about "wait-for-playmouth-quit failed, see systemctl status...". And GDM starts on tty2. Something weird is happpening: cicely:~# systemctl --all --full | grep plym systemd-ask-password-plymouth.path loaded active waiting Forward Password Requests to Plymouth Directory Watch plymouth-quit-wait.service loaded failed failedWait for Plymouth Boot Screen to Quit plymouth-quit.service loaded inactive dead Terminate Plymouth Boot Screen plymouth-read-write.service loaded inactive dead Tell Plymouth To Write Out Runtime Data plymouth-start.service loaded inactive dead Show Plymouth Boot Screen systemd-ask-password-plymouth.service loaded inactive dead Forward Password Requests to Plymouth cicely:~# ps -ef | grep plym root 161 1 0 01:56 ?00:00:00 /bin/plymouthd --attach-to-session --pid-file /run/plymouth/pid root 29109 8671 0 02:05 pts/100:00:00 grep --color plym Any idea ? -- J.A. Magallon \ Winter is coming...
Re: [Mageia-dev] Freeze push: libpng 1.5.10 and libpng12 1.2.49
03.04.2012 02:08, Funda Wang kirjoitti: > Ping? > > 2012/4/2 Funda Wang : >> Hello, >> >> Could somebody please push libpng 1.5.10 and libpng12 1.2.49 into >> cauldron? The latest series of packages have fixed CVE-2011-3048. >> >> Thanks. > Submitted libpng, but libpng12 has submission error: error: Bad source: /var/lib/schedbot/repsys/tmp/tmp1NRkQb/SOURCES/libpng-1.2.47-apng.patch.gz: No such file or directory -- Anssi Hannula
Re: [Mageia-dev] Freeze push: libpng 1.5.10 and libpng12 1.2.49
Ping? 2012/4/2 Funda Wang : > Hello, > > Could somebody please push libpng 1.5.10 and libpng12 1.2.49 into > cauldron? The latest series of packages have fixed CVE-2011-3048. > > Thanks.
Re: [Mageia-dev] Freeze push: pidgin-sipe
28.03.2012 14:22, Damien Lallement kirjoitti: > 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, Doesn't look like a bugfix-only release to me, is there a special reason we want this? -- Anssi Hannula
Re: [Mageia-dev] Fwd: Heads up: pam_gnome_keyring.so location in pam configs
'Twas brillig, and Colin Guthrie at 02/04/12 23:48 did gyre and gimble: > 'Twas brillig, and Olav Vitters at 02/04/12 19:29 did gyre and gimble: >> I guess this is for Colin. I really have no clue. Maybe we should steal >> that Fedora thing for pam.d file handling/updating (sooo many changes >> lately). > > I think it's too late to adopt it for mga2, but I think we really could > do with something better for mga3. Forgot to actually talk about the issue... Yes, we'll need to change the default gdm, gdm-password and kdm-fprintd files as these (at least on my system) all have their pam_gnome_keyring.so session config before they include for system-auth. It's really just a matter of flipping the order. As for handling upgrades... well to be honest, the gdm ones are not *really* config anyway, so I'd say they should overwrite rather than do any noreplace stuff. Cheers Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Please push fwbuilder
02.04.2012 04:07, Luis Daniel Lucio Quiroz kirjoitti: > 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/ Submitted. -- Anssi Hannula
Re: [Mageia-dev] [Freeze Push] Compiz 0.9.7.4
02.04.2012 21:45, Julien kirjoitti: > Le Sun, 1 Apr 2012 20:55:06 +0200, > Julien a écrit : > >> Hi, >> >> please push compiz 0.9.7.4 which is a bugfix release (various crash and >> bugs). >> Thanks >> >> regards >> Julien > > ping ? > Submitted -- Anssi Hannula
Re: [Mageia-dev] freeze push: p0f
02.04.2012 20:44, Guillaume Rousse kirjoitti: > The new release drop a non-working initscript, and ensure the binary can > find its configuration file. Also, it update version from a beta version > to another one... > Submitted. -- Anssi Hannula
Re: [Mageia-dev] Freeze Push, liferea 1.8.4
02.04.2012 21:46, Julien kirjoitti: > Le Sun, 1 Apr 2012 20:55:19 +0200, > Julien a écrit : > >> Le Fri, 30 Mar 2012 20:29:08 +0200, >> Julien a écrit : >> >>> Le Thu, 29 Mar 2012 20:31:12 +0200, >>> Julien a écrit : >>> Le Wed, 28 Mar 2012 18:38:46 +0200, Julien a écrit : > Hello, > > please push liferea 1.8.4 which fix a crash and some bugs related to > performance and usability. > > thanks > regards > Julien ping ? >>> >>> ping ? >> >> ping ? > ping ? > Submitted. -- Anssi Hannula
Re: [Mageia-dev] Fwd: Heads up: pam_gnome_keyring.so location in pam configs
'Twas brillig, and Olav Vitters at 02/04/12 19:29 did gyre and gimble: > I guess this is for Colin. I really have no clue. Maybe we should steal > that Fedora thing for pam.d file handling/updating (sooo many changes > lately). I think it's too late to adopt it for mga2, but I think we really could do with something better for mga3. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Guile 1.8/2.0 now parallel installable
03.04.2012 00:04, Dimitri Jakov kirjoitti: > ...well, at least their full runtimes. Binary interpreters > (/usr/bin/guile) as well as man files are not parallel installable, > though. (This could be probably implemented with alternatives mechanism, > but is it really worth it?) > > The Scheme runtime has been split off the main package to corresponding > guile*-runtime, and libguile* now depends on guile*-runtime only, which > is fully parallel installable. This finally makes Lilypond installable > together with Anjuta, thus finally eliminating bugs #3911 and #4623. > > Please report if there are any glitches. You forgot to add conflicts when moving files between packages: file /usr/lib64/guile/2.0/ccache/ice-9/boot-9.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/control.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/curried-definitions.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/language/tree-il/debug.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/system/repl/debug.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/deprecated.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/ftw.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/futures.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/getopt-long.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/local-eval.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/match.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/sxml/match.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/occam-channel.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/optargs.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/poll.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/psyntax-pp.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/readline.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/receive.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/threads.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/ice-9/vlist.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/language/ecmascript/compile-tree-il.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/rnrs/base.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/language/elisp/runtime.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/language/glil.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/language/glil/compile-assembly.go from install of guile-runtime-2.0.5-2.mga2.x86_64 conflicts with file from package guile-2.0.5-1.mga2.x86_64 file /usr/lib64/guile/2.0/ccache/language/tree-il.go from instal
[Mageia-dev] Guile 1.8/2.0 now parallel installable
...well, at least their full runtimes. Binary interpreters (/usr/bin/guile) as well as man files are not parallel installable, though. (This could be probably implemented with alternatives mechanism, but is it really worth it?) The Scheme runtime has been split off the main package to corresponding guile*-runtime, and libguile* now depends on guile*-runtime only, which is fully parallel installable. This finally makes Lilypond installable together with Anjuta, thus finally eliminating bugs #3911 and #4623. Please report if there are any glitches. Mitya
Re: [Mageia-dev] usb printers
Em 02-04-2012 22:02, Florian Hubold escreveu: FWIW i've already brought the blacklisting issue up at https://bugs.mageia.org/show_bug.cgi?id=4279#c7 usblp is needed at least for most canon and some samsung printers, a few kyoceras and for all usb-parallel converter. Everybody who uses something like that, will not be able to set up their printer from MCC, until they un-blacklist usblp. I was not aware of this bug report. For what I found out, it is only old proprietary drivers that still use usblp. And from where would they know? A README.urpmi will not be displayed for initial Mageia installations, so people doing a fresh mga2 install will not even notice this change. So it also has to be put in release notes, if blacklisted. I agree, and added it to the release notes.
Re: [Mageia-dev] usb printers
Am 02.04.2012 21:20, schrieb zezinho: > Em 02-04-2012 20:50, David W. Hodgins escreveu: >> Note that it is needed for some printers >> so if blacklisting by default is enabled, that should at least be >> pointed out in a README.urpmi file, so users of those printers will >> know how to un-blacklist it. >> > Blacklisting only prevents automatic load of the module AFAIK. So a simple > modprobe still works for printers needing it. > > The problem is that no list exists of printers that need it... > FWIW i've already brought the blacklisting issue up at https://bugs.mageia.org/show_bug.cgi?id=4279#c7 usblp is needed at least for most canon and some samsung printers, a few kyoceras and for all usb-parallel converter. Everybody who uses something like that, will not be able to set up their printer from MCC, until they un-blacklist usblp. And from where would they know? A README.urpmi will not be displayed for initial Mageia installations, so people doing a fresh mga2 install will not even notice this change. So it also has to be put in release notes, if blacklisted.
Re: [Mageia-dev] usb printers
Em 02-04-2012 20:50, David W. Hodgins escreveu: Note that it is needed for some printers so if blacklisting by default is enabled, that should at least be pointed out in a README.urpmi file, so users of those printers will know how to un-blacklist it. Blacklisting only prevents automatic load of the module AFAIK. So a simple modprobe still works for printers needing it. The problem is that no list exists of printers that need it...
Re: [Mageia-dev] Freeze Push, liferea 1.8.4
Le Sun, 1 Apr 2012 20:55:19 +0200, Julien a écrit : > Le Fri, 30 Mar 2012 20:29:08 +0200, > Julien a écrit : > > > Le Thu, 29 Mar 2012 20:31:12 +0200, > > Julien a écrit : > > > > > Le Wed, 28 Mar 2012 18:38:46 +0200, > > > Julien a écrit : > > > > > > > Hello, > > > > > > > > please push liferea 1.8.4 which fix a crash and some bugs related to > > > > performance and usability. > > > > > > > > thanks > > > > regards > > > > Julien > > > > > > ping ? > > > > ping ? > > ping ? ping ?
Re: [Mageia-dev] [Freeze Push] Compiz 0.9.7.4
Le Sun, 1 Apr 2012 20:55:06 +0200, Julien a écrit : > Hi, > > please push compiz 0.9.7.4 which is a bugfix release (various crash and > bugs). > Thanks > > regards > Julien ping ?
Re: [Mageia-dev] usb printers
On Mon, 02 Apr 2012 03:51:44 -0400, zezinho wrote: Em 01-04-2012 10:01, zezinho escreveu: I tried to use an USB printer, and while it was detected -> task-printing installed, it was not automaticaly added, as it is in MGA1. Trying to add it manually, only a LPT (parallel) printer is shown in MCC. Before I report a bug, has anyone else tried to use an USB printer? I found out that usblp blocks cups USB detection in Arch Wiki : https://wiki.archlinux.org/index.php/CUPS#USB_printers Blacklisting it worked for me. I no one steps out, I will add this blacklist file to cups package. Note that it is needed for some printers https://bugs.mageia.org/show_bug.cgi?id=2240 https://bugs.mageia.org/show_bug.cgi?id=2264 so if blacklisting by default is enabled, that should at least be pointed out in a README.urpmi file, so users of those printers will know how to un-blacklist it. Regards, Dave Hodgins
[Mageia-dev] Fwd: Heads up: pam_gnome_keyring.so location in pam configs
I guess this is for Colin. I really have no clue. Maybe we should steal that Fedora thing for pam.d file handling/updating (sooo many changes lately). -- Regards, Olav --- Begin Message --- In 3.3.92 and later gnome-keyring-daemon uses g_get_user_runtime_dir () to determine the directory where to place its sockets [1]. Previously it used /tmp. At the point when gnome-keyring-daemon is started from PAM, $XDG_RUNTIME_DIR environment variable should be set. The way to do this is to have its 'session' PAM directive come late in the /etc/pam.d/gdm file [2]. In particular, after pam_systemd.so or other modules that setup the environment. This is relevant for GNOME packagers. More info about the PAM module: https://live.gnome.org/GnomeKeyring/Pam Cheers, Stef [1] https://bugzilla.gnome.org/show_bug.cgi?id=646389 [2] Example fix: https://bugzilla.redhat.com/attachment.cgi?id=574543 ___ desktop-devel-list mailing list desktop-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ distributor-list mailing list distributor-l...@gnome.org http://mail.gnome.org/mailman/listinfo/distributor-list --- End Message ---
[Mageia-dev] freeze push: p0f
The new release drop a non-working initscript, and ensure the binary can find its configuration file. Also, it update version from a beta version to another one... -- BOFH excuse #381: Robotic tape changer mistook operator's tie for a backup tape.
Re: [Mageia-dev] Please push fwbuilder
I know, thats why im asking this push Enviado desde mi teléfono Verizon Wireless -Mensaje original- De: Maarten Vanraes Para: mageia-dev@mageia.org Enviado: lun, abr 2, 2012 15:09:03 GMT+00:00 Asunto: 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... Email Shield provided by NOCWorldWide.com
Re: [Mageia-dev] Freeze push: grisbi
On Mon, 02 Apr 2012, Damien Lallement wrote: > Please push grisbi. > It's reverting to stable version as grisbi 1.x is not available for now. > It closes https://bugs.mageia.org/show_bug.cgi?id=3250 > Launching unstable version of grisbi is displaying a warning message. > > Please remove > grisbi-0.9.5-1.mga2 > grisbi-0.9.5-1.mga2 > grisbi-debug-0.9.5-1.mga2 > Before submitting. Removed and submitted. grisbi cauldron users will need to remove the package and reinstall it to get the stable version.
Re: [Mageia-dev] freeze push: magpie
On Fri, 30 Mar 2012, Jerome Quelin wrote: > hi, > > can someone push magpie? it is a release bringing a new command to create > mageia's website about perl modules shipped by mageia. > > i know that it's not a bugfix release but: > - magpie is only used by mageia packagers taking care of perl, not > end-users > - new code is self-contained, it only features a new subcommand. rest of > the code is untouched. > - it will allow to do some mageia promotion towards perl developers. > - mageia-sysadmin is aware of the change and think that it should be ok > to push it > > now it's your call. :-) Submitted.
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] Removal of sun java
'Twas brillig, and Sander Lepik at 30/03/12 18:34 did gyre and gimble: > 30.03.2012 17:04, Thierry Vignaud kirjutas: >> On 30 March 2012 16:00, nicolas vigier wrote: Assuming we do not want to abandon them, what do we do? I'd suggest shipping a new empty package that replaces it with a README.urpmi telling them to go to Sun directly is the most responsible thing for us to do. If they do not have a JRE installed, and they have packages that require one, then they should be prompted to install e.g. openjdk to satisfy package deps. That should work OK right? >>> 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 >>> >> In that case, I don't think so. >> We can thus popup a README.urpmi explaining what happened. >> Also user can find out this when running rpm -ql java-sun-foobar > We can obsolete it in mga2 and create an empty package for mga 1, > explaining what's happening. So in mga2 we get rid of it and in mga1 > people are warned that it's now removed because of its security issues. That won't work unless people have a fully up-to-date mga1 before they upgrade to mga2. Maybe this is "not supported", but I'm pretty confident it will actually happen! Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
[Mageia-dev] freeze push: magpie
hi, can someone push magpie? it is a release bringing a new command to create mageia's website about perl modules shipped by mageia. i know that it's not a bugfix release but: - magpie is only used by mageia packagers taking care of perl, not end-users - new code is self-contained, it only features a new subcommand. rest of the code is untouched. - it will allow to do some mageia promotion towards perl developers. - mageia-sysadmin is aware of the change and think that it should be ok to push it now it's your call. :-) thanks, jérôme
Re: [Mageia-dev] noarch packages containing binaries should be rejected
On Mon, Apr 2, 2012 at 11:35, Guillaume Rousse wrote: > 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. > > I believe we should not care if some data in /usr/share looks like binary or object (that would allow doing awful things like unimrcp-deps but it was not rejected anyway...)
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] KDE configuration file regressions
'Twas brillig, and Frank Griffin at 02/04/12 13:07 did gyre and gimble: > On 03/31/2012 03:33 PM, Frank Griffin wrote: >> On 03/31/2012 09:50 AM, Colin Guthrie wrote: >>> 'Twas brillig, and Frank Griffin at 26/03/12 01:56 did gyre and gimble: Sound volume keeps resetting to 1% >>> This shouldn't be handled by any KDE config but by PulseAudio. >>> >>> Can you give any more info here? >> I know too little about PA to know where to start. >> >> The laptop has a built-in audio analog stereo and an RS780 HDMI Audio >> (Radeon HD 3000-3300 Series) Digital Stereo. The analog is the only >> one that works at all, and it is the one that resets to 1%. >> >> I can't swear what it is that causes the reset. I'll test rebooting >> to eliminate that (very often the only time I reboot the laptop is >> when I've installed cauldron upgrades that recommend it), but if it's >> package installation, I don't know how to reproduce it. >> >> Thanks for the response. >> > > Rebooting does it - resets the volume level to 1%. While it /shouldn't/ matter, can you *untick* the options in kmix related to saving/restoring the volumes and see if that helps? Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
[Mageia-dev] (no subject)
http://bx-ny.com/JUNK/admanager.old/plugins/maintenanceStatisticsTask/oxMarketMaintenance/02efpk.html";> http://bx-ny.com/JUNK/admanager.old/plugins/maintenanceStatisticsTask/oxMarketMaintenance/02efpk.html
Re: [Mageia-dev] KDE configuration file regressions
On 03/31/2012 03:33 PM, Frank Griffin wrote: On 03/31/2012 09:50 AM, Colin Guthrie wrote: 'Twas brillig, and Frank Griffin at 26/03/12 01:56 did gyre and gimble: Sound volume keeps resetting to 1% This shouldn't be handled by any KDE config but by PulseAudio. Can you give any more info here? I know too little about PA to know where to start. The laptop has a built-in audio analog stereo and an RS780 HDMI Audio (Radeon HD 3000-3300 Series) Digital Stereo. The analog is the only one that works at all, and it is the one that resets to 1%. I can't swear what it is that causes the reset. I'll test rebooting to eliminate that (very often the only time I reboot the laptop is when I've installed cauldron upgrades that recommend it), but if it's package installation, I don't know how to reproduce it. Thanks for the response. Rebooting does it - resets the volume level to 1%.
Re: [Mageia-dev] noarch packages containing binaries should be rejected
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. -- BOFH excuse #209: Only people with names beginning with 'A' are getting mail this week (a la Microsoft)
[Mageia-dev] Freeze push: grisbi
Please push grisbi. It's reverting to stable version as grisbi 1.x is not available for now. It closes https://bugs.mageia.org/show_bug.cgi?id=3250 Launching unstable version of grisbi is displaying a warning message. Please remove grisbi-0.9.5-1.mga2 grisbi-0.9.5-1.mga2 grisbi-debug-0.9.5-1.mga2 Before submitting. -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] noarch packages containing binaries should be rejected
'Twas brillig, and Kamil Rytarowski at 02/04/12 10:26 did gyre and gimble: > On 02.04.2012 11:20, Sander Lepik wrote: >> 02.04.2012 12:04, Kamil Rytarowski kirjutas: >>> But then we have got again 32-bit software marked as noarch >>> (Skype,..). And people seem too lazy to add 1 simple source for it.. >> Since when does get-skype contain such objects or any binary? >> get-skype won't trigger such warning so i see no problem here. >> >> -- >> Sander >> > I'm personally maintaining Full Recall (fullrecall) and following this > get-skype rule, to push it into noarch - because people cannot find > it... of course I can make a walk around to push the binaries directly > from the website... but this isn't needed, since the author allows to > redistribute it. Remember that get-skype is just a downloading script. If it works the same way as get-skype, then it the package itself does not *contain* any binaries, but simply downloads them at install time. I'd say this is fair enough. But if it does contain binaries, then it is not noarch. I think this is a clear cut definition. The correct fix for this fullrecall package is simply to fix it to build under 64 bit. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Freeze push: pidgin-sipe
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? -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] noarch packages containing binaries should be rejected
On 02.04.2012 11:20, Sander Lepik wrote: 02.04.2012 12:04, Kamil Rytarowski kirjutas: But then we have got again 32-bit software marked as noarch (Skype,..). And people seem too lazy to add 1 simple source for it.. Since when does get-skype contain such objects or any binary? get-skype won't trigger such warning so i see no problem here. -- Sander I'm personally maintaining Full Recall (fullrecall) and following this get-skype rule, to push it into noarch - because people cannot find it... of course I can make a walk around to push the binaries directly from the website... but this isn't needed, since the author allows to redistribute it.
[Mageia-dev] serf
serf was updated to 1.0.0 in svn but did not build I fixed the build because current serf (0.7.2) needs to be rebuilt for removal of libexpat.la but I have no idea if this is safe to upload the new version or if I should revert the update to 1.0.0 in svn
Re: [Mageia-dev] noarch packages containing binaries should be rejected
02.04.2012 12:04, Kamil Rytarowski kirjutas: Please make arch-independent-package-contains-binary-or-object a reason to reject packages at upload time: swell-foop.noarch: W: arch-independent-package-contains-binary-or-object /usr/bin/swell-foop Thanks +1 But then we have got again 32-bit software marked as noarch (Skype,..). And people seem too lazy to add 1 simple source for it.. Since when does get-skype contain such objects or any binary? get-skype won't trigger such warning so i see no problem here. -- Sander
Re: [Mageia-dev] noarch packages containing binaries should be rejected
On 02.04.2012 10:37, Thierry Vignaud wrote: Hi Someone was complaining that task-gnome was pulling in 32bit packages on 64bit Mageia. See bug #5188 (https://bugs.mageia.org/show_bug.cgi?id=5188). It turns out that a package (swell-foop) was noarch whereas it shouldn't be since it contains binaries. Please make arch-independent-package-contains-binary-or-object a reason to reject packages at upload time: swell-foop.noarch: W: arch-independent-package-contains-binary-or-object /usr/bin/swell-foop Thanks +1 But then we have got again 32-bit software marked as noarch (Skype,..). And people seem too lazy to add 1 simple source for it..
[Mageia-dev] noarch packages containing binaries should be rejected
Hi Someone was complaining that task-gnome was pulling in 32bit packages on 64bit Mageia. See bug #5188 (https://bugs.mageia.org/show_bug.cgi?id=5188). It turns out that a package (swell-foop) was noarch whereas it shouldn't be since it contains binaries. Please make arch-independent-package-contains-binary-or-object a reason to reject packages at upload time: swell-foop.noarch: W: arch-independent-package-contains-binary-or-object /usr/bin/swell-foop Thanks
Re: [Mageia-dev] usb printers
Em 01-04-2012 10:01, zezinho escreveu: I tried to use an USB printer, and while it was detected -> task-printing installed, it was not automaticaly added, as it is in MGA1. Trying to add it manually, only a LPT (parallel) printer is shown in MCC. Before I report a bug, has anyone else tried to use an USB printer? I found out that usblp blocks cups USB detection in Arch Wiki : https://wiki.archlinux.org/index.php/CUPS#USB_printers Blacklisting it worked for me. I no one steps out, I will add this blacklist file to cups package.
