Re: [Mageia-dev] KDE 4.7?
On Tue, Jun 28, 2011 at 7:40 AM, Funda Wang fundaw...@gmail.com wrote: Hello, Is it the time we go with kde 4.7 (rc currently) within cauldron? Regards. mikala is currenlty packaging it. Should land in cauldron in the next few days
[Mageia-dev] schroot build problem with new libboost
Hi, can someone help me to solve the build problem here : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110628070637.philippem.valstar.17988/ what is strange is that Fedora 16 build is ok with same libboost version as our in Cauldron thanks
Re: [Mageia-dev] schroot build problem with new libboost
quote /usr/bin/ld: cannot find -lboost_program_options /quote That is the problem here, it is looking for libboost_program_options, but we only have libboost_program_options-mt. 2011/6/28 philippe makowski makowski.mag...@gmail.com: Hi, can someone help me to solve the build problem here : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110628070637.philippem.valstar.17988/ what is strange is that Fedora 16 build is ok with same libboost version as our in Cauldron thanks
Re: [Mageia-dev] Proposal of a backporting process
domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto: See the thread about policy, and the part about only packages that nothing requires should be backported. I can't see very well the leaf story... I mean any packages require something at least to build. Scripts need interpreters, so i'd expect interpreters cannot be backported, but we can find a script based package (using perl, ruby or python...) needing some other script based one, the same could happen for programs. Now what can we backport there? A and B are leaves (?) but B uses A so i can revert A for a problem, now are we sure A on stable works with B on backports? Morever we could not backport new major libraries, they would not conflicts with stable though, but sure they could affect some packages built in backports after that should not work without new major. I'm confused :/ IMO we should improve the QA (or what else) and testing to allow a safe installation and proving that will be upgraded to the next mageia release, then if we call it backports, upgrades, updates or... that's another and maybe less important thing. Angelo signature.asc Description: This is a digitally signed message part.
Re: [Mageia-dev] schroot build problem with new libboost
On Tue, 28 Jun 2011 03:23:30 -0400, Funda Wang fundaw...@gmail.com wrote: quote /usr/bin/ld: cannot find -lboost_program_options /quote That is the problem here, it is looking for libboost_program_options, but we only have libboost_program_options-mt. 2011/6/28 philippe makowski makowski.mag...@gmail.com: Hi, can someone help me to solve the build problem here : http://pkgsubmit.mageia.org/uploads/failure/cauldron/core/release/20110628070637.philippem.valstar.17988/ what is strange is that Fedora 16 build is ok with same libboost version as our in Cauldron thanks configure:8603: x86_64-mageia-linux-gnu-gcc -E conftest.c conftest.c:15:28: fatal error: ac_nonexistent.h: No such file or directory When debugging make errors, I always look at the first error, which seems to be configure:8603: x86_64-mageia-linux-gnu-gcc -E conftest.c conftest.c:15:28: fatal error: ac_nonexistent.h: No such file or directory urpmf conftest.c libwxgtku2.8-devel:/usr/share/doc/libwxgtku2.8-devel/samples/config/conftest.cpp libwxgtk2.8-devel:/usr/share/doc/libwxgtk2.8-devel/samples/config/conftest.cpp Regards, Dave Hodgins
Re: [Mageia-dev] autologin + consolekit
'Twas brillig, and andre999 at 28/06/11 02:42 did gyre and gimble: Colin Guthrie a écrit : 'Twas brillig, and Colin Guthrie at 14/06/11 09:07 did gyre and gimble: 'Twas brillig, and Colin Guthrie at 12/06/11 23:45 did gyre and gimble: Hi, The autologin package is broken due to the fact that it doesn't connect to consolekit and thus the user who is automatically logged in doesn't get any permissions etc. I've fixed this by changing the autologin pam.d definition to include login rather than system-auth. login adds the optional session module for pam_ck_connector. But I'm not sure whether this makes sense, or whether we should just add the ck_connector to the autologin pam.d definition itself. There may be other login systems that have similar problems (e.g. the autologin features of gdm or slim etc) but I've not tested. Any thoughts. Does anyone know what the right way to fix the above is? I'd like to issue an update when appropriate to take care of this. Ping!! Col A while back when I was playing with an alternate version of an application which required authentification, I added the application name to some pam-related file, and it worked. I forget the details. I just did something parallel to what other some applications did. That seems to be what you're doing ? I'm far from being an expert. Hope that helps. Thanks for the input. It's not a problem getting it working as I have this working fine. My question is rather one of which solution is best? Either adding the pam_ck_connector to individual files or simply including login over system-auth or even changing system-auth to include pam_ck_connector rather than login. Something isn't quite right here but I don't know what. Col -- Colin Guthrie mageia(at)colin.guthr.ie 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] schroot build problem with new libboost
2011/6/28 Funda Wang fundaw...@gmail.com: quote /usr/bin/ld: cannot find -lboost_program_options /quote That is the problem here, it is looking for libboost_program_options, but we only have libboost_program_options-mt. and why ? under mga1 we have libboost_program_options.so.1.44.0 and under Cauldron libboost_program_options-mt.so.1.46.1 why not libboost_program_options.so.1.46.1 ? Fedora have both , why don't we have both ? how to solve this ? (sorry it is out of my skills)
Re: [Mageia-dev] schroot build problem with new libboost
On 28 June 2011 11:13, philippe makowski makowski.mag...@gmail.com wrote: 2011/6/28 Funda Wang fundaw...@gmail.com: quote /usr/bin/ld: cannot find -lboost_program_options /quote That is the problem here, it is looking for libboost_program_options, but we only have libboost_program_options-mt. and why ? under mga1 we have libboost_program_options.so.1.44.0 and under Cauldron libboost_program_options-mt.so.1.46.1 why not libboost_program_options.so.1.46.1 ? Fedora have both , why don't we have both ? [...] how to solve this ? (sorry it is out of my skills) For some reason that particular configure check (boost::program_options::validation_error) doesn't check multi-threaded libboost_program_options-mt.so, the other ones do. I've committed a fix, hopefully it'll work. -- Ahmad Samir
Re: [Mageia-dev] Backports policy proposal
Le lundi 27 juin 2011 à 21:42 -0400, andre999 a écrit : Michael Scherer a écrit : Le vendredi 24 juin 2011 à 16:20 -0400, andre999 a écrit : Michael Scherer a écrit : [...] - cannot be backported if the package was just created and is thus basically untested in cauldron What about corner cases where a potential backport is incompatible with changes introduced in cauldron ? Should we leave such packages to third parties ? (I would tend to say yes.) Give a more precise example. Suppose leaf package fooa depends on foob. foob is part of the current release. Cauldron replaces foob with fooc. fooa is incompatible with fooc. Then why do we replace foob by it in the first place if this break fooa ? fooa is requested by some users, and future versions of fooa are intended to be compatible with fooc. In this case, even though it wouldn't be testable in cauldron, it could be tested in backports-testing, and I think it could be a good idea to allow it. Even if fooc compatibility wouldn't be available for the next Mageia release, a user could avoid updating for a release in order to keep using fooa. However, if there were no intention to make fooa compatible with fooc, maybe it should be denied. The example is bogus. If we have fooa in the distro and we upload fooc that break it, then we have to fix the breakage as a priority. Usually, that would be having foob and fooc as parallel installablable. Anyway, the question is how often does it happens ? Because it may happen is not a justification if in practice, it never happen. And not having a backport is not the end of the world so unless the problem is quite frequent ( and so far, this one is far from being frequent , especially since it is based on a wrong supposition in the first part ), I do not think this would be blocking. I like the idea of tagging backports in the package name, as well as in the package database. We cannot tag in the packages database. Yum do it with a separate sqlite file, afaik. I would like to see the source repository info available for every installed package. Maybe even stored somewhere in the .rpm file, also. Is concerns for upstream compatibility for rpm or urpm* the a reason why we can't add new fields to the packages database ? (Although a parallel sqlite file would work.) Compatibility would be indeed a concern. But if we move packages between repository without rebuilding for QA reasons, this would also be meaningless. -- Michael Scherer
Re: [Mageia-dev] schroot build problem with new libboost
2011/6/28 Ahmad Samir ahmadsamir3...@gmail.com: I've committed a fix, hopefully it'll work. thanks
Re: [Mageia-dev] KDE 4.7?
Le mardi 28 juin 2011 02:40:43, Funda Wang a écrit : Hello, Is it the time we go with kde 4.7 (rc currently) within cauldron? It's almost ready in fact. I'm just working on kdebindings4 split if you're following commits (either on irc or on the mailing list) you might see that almost everything is already on the svn :) -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Mageia Advisories Database
Hi, On Tue, Jun 28, 2011 at 15:34, Samuel Verschelde sto...@laposte.net wrote: Le mardi 28 juin 2011 15:20:33, nicolas vigier a écrit : In order to send updates advisories, and have a web page listing all previous advisories, we need to create a database to store them. So I think it should have the following info for each advisory : - advisory ID: something like MGA-[NUMBER] ? - advisory date - affected source packages - affected distribution versions - CVE numbers - list of binary packages with sha1sum - Mageia Bug # - Reference URLs - advisory text Anything else ? If using SQL, make sure to normalize the db schema a bit (that is, for instance, an advisory table, with a distributions table, and a relationship). MDV security advisory web app had a single table, with new columns added each time a new release was published and that was really not good, neither safe to maintain. In this perspective, there could be the following tables: - advisories (id, date, text, list of URLs, list of bug #) - distributions (id, name) - source packages (id, name, version) - CVE numbers Not sure about the rest; depends on the data details and what type of queries would be expected: - do we only query after the advisory id or do we plan to have stats per distribution, source package? - what screens do you expect? - are there several CVE numbers for a single advisory? - is there a link from source packages and binary packages? Romain
Re: [Mageia-dev] Mageia Advisories Database
On 06/28/2011 09:50 AM, Romain d'Alverny wrote: If using SQL, make sure to normalize the db schema a bit (that is, for - are there several CVE numbers for a single advisory? Yes, there could be -- Stew Benedict
Re: [Mageia-dev] Mageia Advisories Database
On Tue, 28 Jun 2011, nicolas vigier wrote: In order to send updates advisories, and have a web page listing all previous advisories, we need to create a database to store them. So I think it should have the following info for each advisory : - advisory ID: something like MGA-[NUMBER] ? - advisory date - affected source packages - affected distribution versions - CVE numbers - list of binary packages with sha1sum - Mageia Bug # - Reference URLs - advisory text Anything else ? - severity - whether this is a security issue or a non-security bugfix (could be 1 field) Christiaan
Re: [Mageia-dev] KDE 4.7?
I would say we need to add a lot of conflicts and obsoletes for upgrading. 2011/6/28 Balcaen John mik...@mageia.org: Le mardi 28 juin 2011 02:40:43, Funda Wang a écrit : Hello, Is it the time we go with kde 4.7 (rc currently) within cauldron? It's almost ready in fact. I'm just working on kdebindings4 split if you're following commits (either on irc or on the mailing list) you might see that almost everything is already on the svn :) -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] KDE 4.7?
On Tue, Jun 28, 2011 at 4:27 PM, Funda Wang fundaw...@gmail.com wrote: I would say we need to add a lot of conflicts and obsoletes for upgrading. mikala worked on it already from what he told me.
Re: [Mageia-dev] Mageia Advisories Database
On Tue, 28 Jun 2011, Romain d'Alverny wrote: Hi, On Tue, Jun 28, 2011 at 15:34, Samuel Verschelde sto...@laposte.net wrote: Le mardi 28 juin 2011 15:20:33, nicolas vigier a écrit : In order to send updates advisories, and have a web page listing all previous advisories, we need to create a database to store them. So I think it should have the following info for each advisory : - advisory ID: something like MGA-[NUMBER] ? - advisory date - affected source packages - affected distribution versions - CVE numbers - list of binary packages with sha1sum - Mageia Bug # - Reference URLs - advisory text Anything else ? If using SQL, make sure to normalize the db schema a bit (that is, for instance, an advisory table, with a distributions table, and a relationship). MDV security advisory web app had a single table, with new columns added each time a new release was published and that was really not good, neither safe to maintain. In this perspective, there could be the following tables: - advisories (id, date, text, list of URLs, list of bug #) - distributions (id, name) - source packages (id, name, version) - CVE numbers I am thinking about the following tables : - advisories : id, published, publish-date, update-date, text, severity - source-packages : packagename, filename, sha1, distribution, repository, version, advisory-id - binary-packages : packagename, filename, sha1, source-package-id - cve-numbers : cve-number, advisory-id - bugzilla-numbers : bugzilla-number, advisory-id - reference-urls : url, advisory-id Not sure about the rest; depends on the data details and what type of queries would be expected: - do we only query after the advisory id or do we plan to have stats per distribution, source package? We can query by advisory id, source package, cve number, bugzilla number. And we can do stats. - what screens do you expect? - are there several CVE numbers for a single advisory? Yes. We can have several CVE numbers, source packages, bugzilla numbers, URLs, distributions, for one advisory. - is there a link from source packages and binary packages? Yes.
Re: [Mageia-dev] Looking for a mentor in packaging...
Le lundi 27 juin 2011 20:40:27, Radu-Cristian FOTESCU a écrit : We will soon have a page on wiki where people can put his name on for seeking a mentor, too. Oh, is it not this one?http://mageia.org/wiki/doku.php?id=packaging#list_of_registered_peopl e It thought it was a list for people wanting to become packagers (although some people already are mga packagers), so I've added my name there too. It's not dedicated to this but rather a means to see who can work on what, if I remember correctly (and also who can be a mentor), since we have no maintainer database yet. I too said I need mentoring / I want to take care of some packages in mga. In the meantime, I am on my own: http://mageia.beranger.org/mageia/ I hope we can find you a mentor as soon as possible. If any mentor is available for beranger, please tell ! Otherwise, please give some time to the new mentoring coordination small team so that they can try to improve the process and find a mentor for you. Best regards Samuel
Re: [Mageia-dev] Proposal of a backporting process
Le mardi 28 juin 2011 à 09:25 +0200, Angelo Naselli a écrit : domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto: See the thread about policy, and the part about only packages that nothing requires should be backported. I can't see very well the leaf story... I mean any packages require something at least to build. Scripts need interpreters, so i'd expect interpreters cannot be backported, but we can find a script based package (using perl, ruby or python...) needing some other script based one, the same could happen for programs. Now what can we backport there? A and B are leaves (?) but B uses A so i can revert A for a problem, now are we sure A on stable works with B on backports? if B use A, that mean that A is not a leave package, since something requires it. Morever we could not backport new major libraries, they would not conflicts with stable though, but sure they could affect some packages built in backports after that should not work without new major. Yes. There is a moment where we need to answer do we want to backport all cauldron on stable, which is basically what we incrementally do with cauldron, or do we just backport a subset of application where we can do enough QA because changes are small enough ? I'm confused :/ IMO we should improve the QA (or what else) and testing to allow a safe installation and proving that will be upgraded to the next mageia release, then if we call it backports, upgrades, updates or... that's another and maybe less important thing. Proving is easy. The package in release must have a higher EVR than those on backports. But if we let people do cherry picking, this is much harder. -- Michael Scherer
Re: [Mageia-dev] KDE 4.7?
Le mardi 28 juin 2011 11:27:24, Funda Wang a écrit : I would say we need to add a lot of conflicts and obsoletes for upgrading. I'm already on it so please don't start changing everything until i finished. -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] KDE 4.7?
OK, and don't forget those -devel sub packages, as I've already found several of them. 2011/6/28 Balcaen John mik...@mageia.org: Le mardi 28 juin 2011 11:27:24, Funda Wang a écrit : I would say we need to add a lot of conflicts and obsoletes for upgrading. I'm already on it so please don't start changing everything until i finished. -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] KDE 4.7?
Le mardi 28 juin 2011 12:20:18, Balcaen John a écrit : Le mardi 28 juin 2011 11:27:24, Funda Wang a écrit : I would say we need to add a lot of conflicts and obsoletes for upgrading. I'm already on it so please don't start changing everything until i finished. Since you started without waiting for an answer could you please at least wrote a correct changelog (like for example fixing the requires on lib on -devel package for kate since it's not just about adding a conflict please note that fix for example was already on my next commit ) -- Balcaen John Jabber ID: mik...@jabber.littleboboy.net
Re: [Mageia-dev] Mageia Advisories Database
On Tue, 28 Jun 2011, Christiaan Welvaart wrote: On Tue, 28 Jun 2011, nicolas vigier wrote: In order to send updates advisories, and have a web page listing all previous advisories, we need to create a database to store them. So I think it should have the following info for each advisory : - advisory ID: something like MGA-[NUMBER] ? - advisory date - affected source packages - affected distribution versions - CVE numbers - list of binary packages with sha1sum - Mageia Bug # - Reference URLs - advisory text Anything else ? - severity - whether this is a security issue or a non-security bugfix (could be 1 field) What kind of severity classification should we use ? Something like redhat, with Critical, Important, Moderate, Low ? Or something more simple with only Critical and Normal ? Or no classification ? http://www.redhat.com/f/pdf/rhel4/SecurityClassification.pdf
Re: [Mageia-dev] Mageia Advisories Database
Le mardi 28 juin 2011 à 16:23 +0200, Christiaan Welvaart a écrit : On Tue, 28 Jun 2011, nicolas vigier wrote: In order to send updates advisories, and have a web page listing all previous advisories, we need to create a database to store them. So I think it should have the following info for each advisory : - advisory ID: something like MGA-[NUMBER] ? - advisory date - affected source packages - affected distribution versions - CVE numbers - list of binary packages with sha1sum Is there people that really check them ? ( since there is already gpg and checksum in rpm that can be checked automatically, I do not see the point in having this when it requires another manual check ) - Mageia Bug # - Reference URLs - advisory text Anything else ? - severity Adding severity would requires us to have precise rules about it, and would not mean much, and likely lots of bike shedding about it. And also, what is the use precisely ? - whether this is a security issue or a non-security bugfix What if there is more than 1 fix ( like a firefox upgrade ) ? And what's the use ? I would recommend looking at CVRF and OSVDB, but that's only for security issues. -- Michael Scherer
Re: [Mageia-dev] Mageia Advisories Database
On Tue, 28 Jun 2011, Michael Scherer wrote: Le mardi 28 juin 2011 à 16:23 +0200, Christiaan Welvaart a écrit : On Tue, 28 Jun 2011, nicolas vigier wrote: In order to send updates advisories, and have a web page listing all previous advisories, we need to create a database to store them. So I think it should have the following info for each advisory : - advisory ID: something like MGA-[NUMBER] ? - advisory date - affected source packages - affected distribution versions - CVE numbers - list of binary packages with sha1sum Is there people that really check them ? ( since there is already gpg and checksum in rpm that can be checked automatically, I do not see the point in having this when it requires another manual check ) Most other distributions include this in their advisories. But yes, it's not very useful, so we can probably remove the sha1. - Mageia Bug # - Reference URLs - advisory text Anything else ? - severity Adding severity would requires us to have precise rules about it, and would not mean much, and likely lots of bike shedding about it. And also, what is the use precisely ? - whether this is a security issue or a non-security bugfix What if there is more than 1 fix ( like a firefox upgrade ) ? If at least one of them is security, then it's a security update.
Re: [Mageia-dev] Proposal of a backporting process
Angelo Naselli a écrit : domenica 26 giugno 2011 alle 13:38, Michael Scherer ha scritto: See the thread about policy, and the part about only packages that nothing requires should be backported. I can't see very well the leaf story... I mean any packages require something at least to build. Scripts need interpreters, so i'd expect interpreters cannot be backported, but we can find a script based package (using perl, ruby or python...) needing some other script based one, the same could happen for programs. Now what can we backport there? A and B are leaves (?) but B uses A so i can revert A for a problem, now are we sure A on stable works with B on backports? Morever we could not backport new major libraries, they would not conflicts with stable though, but sure they could affect some packages built in backports after that should not work without new major. I'm confused :/ IMO we should improve the QA (or what else) and testing to allow a safe installation and proving that will be upgraded to the next mageia release, then if we call it backports, upgrades, updates or... that's another and maybe less important thing. Angelo A leaf package is a package that is not required by any other package. But leaf packages will always require something else. If B requires A, then A is not a leaf package, even though B could be. When backporting B, we test to make sure that it works with release A. Obviously it restricts what can be backported, but the trade-off is that backports will (almost always) work, and they won't break anything. -- André
Re: [Mageia-dev] Looking for a mentor in packaging...
I too said I need mentoring / I want to take care of some packages in mga. In the meantime, I am on my own: http://mageia.beranger.org/mageia/ I hope we can find you a mentor as soon as possible. If any mentor is available for beranger, please tell ! Otherwise, please give some time to the new mentoring coordination small team so that they can try to improve the process and find a mentor for you. I know people is now busy with bringing KDE 4.6.90 to Cauldron, and mentors are a scarce resource, yet I'd like to say that I added a few more packages in my unofficial repo (y compris calibre updated to 0.8.7): OCR-related new packages: * cuneiform-linux, at 1.1.0, a rather good multilanguage OCR (the officially-available tesseract is also a good one, but it lacks a GUI) * cuneiform-qt, a simple yet very practical GUI for the previous package * yagf, another GUI for the same OCR * kbookocr 2.0, a hard-to-find (on distros other than ALT Linux) GUI for the same OCR, able to also use PDF and DJVU for input files, offering an interface with the scanner, and an integration with the default word processor (LibreOffice Writer) All these OCR GUIs are showing up in the Office KDE menu, not in Graphics, like XSane. Screenshots: http://mageia.beranger.org/images/cuneiform-qt.png http://mageia.beranger.org/images/yagf.png http://mageia.beranger.org/images/kbookocr.png While testing cuneiform-linux with all these GUIs, I’ve already filed a bug with the upstream: https://bugs.launchpad.net/cuneiform-linux/+bug/803156 Best regards, R-C aka beranger
