Re: [arch-general] [arch-dev-public] Fwd: Arch Continuous Integration
On Mon, Nov 10, 2014 at 8:16 AM, Florian Pritz wrote: > On 10.11.2014 12:37, Allan McRae wrote: > > I think this is something we need to bring on board as an official > > project at some stage! > > +1, I'd love to see this data get merged into our main site (especially > a "not-building" table in the dev dashboard). > This is awesome. Does https://arch-ci.org/ provide any sort of JSON interface? We could add a snippet to each package page to go grab the build status, and as Florian hinted, being able to pull in dashboard-able data would be awesome. (Also, you're running your Django site in DEBUG=True mode, I wouldn't do that in production) To Joel: > > Only issue I've noticed so far is that multilib is apparently not > enabled and therefore virtualbox, chromium and syslinux fail because > they can't find lib32 dependencies. > > What kind of hardware backs this and how long does a full rebuild of all > packages take? > > Apart from that, awesome idea and nice interface (maybe missing a > maintainer filter, but you don't really have that data I guess). > > PS: I'm sending this to arch-general so discussion can continue on one > list (if you want that). > >
[arch-general] [translation] pacman 4.0.3 string freeze
Only very minor updates, very few strings have changed. More info: http://www.archlinux.org/pacman/translation-help.html Transifex page: https://www.transifex.net/projects/p/archlinux-pacman/r/4-0-3/ Due by: 2012-04-02 Thanks! -Dan
Re: [arch-general] [translation] pacman 4.0.2 string freeze
On Thu, Feb 2, 2012 at 12:13 AM, Dan McGee wrote: > More info: http://www.archlinux.org/pacman/translation-help.html > Transifex page: https://www.transifex.net/projects/p/archlinux-pacman/r/4-0-2/ Unfortunately Transifex still doesn't do validation quite right on strings and newlines, making my job harder here. I'd appreciate it if anyone that did the below languages (ca, it, pt, pt_BR, ro, sk) could look into these errors in the pacman-scripts catalog. Thanks! -Dan make[2]: Leaving directory `/home/dmcgee/projects/pacman-maint/scripts/po' make update-gmo make[2]: Entering directory `/home/dmcgee/projects/pacman-maint/scripts/po' rm -f ca.gmo && /usr/bin/msgfmt -c --statistics --verbose -o ca.gmo ca.po ca.po:502: `msgid' and `msgstr' entries do not both end with '\n' ca.po:659: `msgid' and `msgstr' entries do not both end with '\n' ca.po:1028: `msgid' and `msgstr' entries do not both end with '\n' ca.po:1044: `msgid' and `msgstr' entries do not both end with '\n' ca.po:1052: `msgid' and `msgstr' entries do not both end with '\n' ca.po:1059: `msgid' and `msgstr' entries do not both end with '\n' ca.po:1081: `msgid' and `msgstr' entries do not both begin with '\n' ca.po:1088: `msgid' and `msgstr' entries do not both end with '\n' ca.po:1093: `msgid' and `msgstr' entries do not both end with '\n' ca.po:1099: `msgid' and `msgstr' entries do not both end with '\n' /usr/bin/msgfmt: found 11 fatal errors ca.po: 336 translated messages. make[2]: *** [ca.gmo] Error 1 rm -f it.gmo && /usr/bin/msgfmt -c --statistics --verbose -o it.gmo it.po it.po:505: `msgid' and `msgstr' entries do not both end with '\n' it.po:673: `msgid' and `msgstr' entries do not both end with '\n' it.po:1037: `msgid' and `msgstr' entries do not both end with '\n' it.po:1054: `msgid' and `msgstr' entries do not both end with '\n' it.po:1061: `msgid' and `msgstr' entries do not both end with '\n' it.po:1068: `msgid' and `msgstr' entries do not both end with '\n' it.po:1088: `msgid' and `msgstr' entries do not both begin with '\n' it.po:1095: `msgid' and `msgstr' entries do not both end with '\n' it.po:1100: `msgid' and `msgstr' entries do not both end with '\n' it.po:1106: `msgid' and `msgstr' entries do not both end with '\n' /usr/bin/msgfmt: found 11 fatal errors it.po: 336 translated messages. make[2]: *** [it.gmo] Error 1 rm -f lt.gmo && /usr/bin/msgfmt -c --statistics --verbose -o lt.gmo lt.po lt.po: 336 translated messages. rm -f pt.gmo && /usr/bin/msgfmt -c --statistics --verbose -o pt.gmo pt.po pt.po:517: `msgid' and `msgstr' entries do not both end with '\n' pt.po:675: `msgid' and `msgstr' entries do not both end with '\n' pt.po:1042: `msgid' and `msgstr' entries do not both end with '\n' pt.po:1058: `msgid' and `msgstr' entries do not both end with '\n' pt.po:1066: `msgid' and `msgstr' entries do not both end with '\n' pt.po:1073: `msgid' and `msgstr' entries do not both end with '\n' pt.po:1094: `msgid' and `msgstr' entries do not both begin with '\n' pt.po:1100: `msgid' and `msgstr' entries do not both end with '\n' pt.po:1105: `msgid' and `msgstr' entries do not both end with '\n' pt.po:: `msgid' and `msgstr' entries do not both end with '\n' /usr/bin/msgfmt: found 11 fatal errors pt.po: 336 translated messages. make[2]: *** [pt.gmo] Error 1 rm -f pt_BR.gmo && /usr/bin/msgfmt -c --statistics --verbose -o pt_BR.gmo pt_BR.po pt_BR.po:508: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:666: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:925: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:1003: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:1042: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:1058: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:1064: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:1071: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:1091: `msgid' and `msgstr' entries do not both begin with '\n' pt_BR.po:1097: `msgid' and `msgstr' entries do not both end with '\n' pt_BR.po:1102: `msgid' and `msgstr' entries do not bo
[arch-general] [translation] pacman 4.0.2 string freeze
More info: http://www.archlinux.org/pacman/translation-help.html Transifex page: https://www.transifex.net/projects/p/archlinux-pacman/r/4-0-2/ Thanks! -Dan
Re: [arch-general] [arch-dev-public] Keeping stuff in /bin, /lib, /sbin
On Mon, Jan 30, 2012 at 3:26 PM, Genes MailLists wrote: > Dan - > > Forgive me emailing you directly - I follow the list but am not able > to post on it - and the reject suggested a direct email - and yours was > last post when I replied. > > If this is wrong etiquette I'm sorry (new to arch ... ) - if I should > not be doing this please let me know. I would reply to arch-general rather than just me; it doesn't help everyone else if our conversation is private. > My comment was just: > > Since kernel modules could go from /lib/modules to /usr/lib/modules, > they would need support from tools such as kmod etc .. I don't think we're even going down this road yet- the only /lib manipulation we would do at this point is actual libraries, not kernel modules or the dynamic linker. -Dan
[arch-general] [translation] pacman 4.0.1 release
I'd like to release 4.0.1 later this week. String changes are very minimal if you were up to date before; 3 new ones in pacman scripts and 2 capitalization changes in pacman. https://www.transifex.net/projects/p/archlinux-pacman/r/4-0-1/ Languages below could use some love if anyone is interested- please sign up as a team member through Transifex to get started: * Chinese (Taiwan) * Swedish * Danish * Russian * Kazakh * Slovak These are close but not quite up to date as of 4.0.0: * Polish * Turkish * Finnish * Portuguese Thanks! -Dan
[arch-general] [translation] pacman 4.0.0 string freeze
If you've helped us out before, or are looking to get involved, the string freeze for the magic 4.0 release is now in effect. Translators: http://www.archlinux.org/pacman/translation-help.html Transifex release page: https://www.transifex.net/projects/p/archlinux-pacman/r/4-0-0/ I've set the deadline 7 days from today. -Dan
[arch-general] Pacman 4.0.0rc2
You don't need to be as daring this time- we've had some 246 commits since RC1. The most relevant changes is signing is about 95% functional at this point- see directions below the links. * pacman -U http://dev.archlinux.org/~dan/pacman-4.0.0rc2-1-i686.pkg.tar.gz * pacman -U http://dev.archlinux.org/~dan/pacman-4.0.0rc2-1-x86_64.pkg.tar.gz Please report any issues you may find with this package, as it is getting very close to being an actual releasable version. These are debug builds with symbols, so getting stack traces and helpful logging should be relatively straight forward if necessary. == How to enable package signature checking == 1. Install above pacman RC package. 2. sudo pacman-key --init 3. `SigLevel = Optional` in pacman.conf is the default- for more info, see man pacman.conf, but this means signatures will be checked *if available*, and there will be no error if they are not. However, due to us not having a web of trust for Arch developer keys, you will need to add this to the [options] section: SigLevel = Optional TrustAll 4. Run -Syu or any other operation that fetches packages from sync databases. When it comes time to check package integrity, you may be prompted to import keys that are not in your keychain. If a signature is available, it will be used instead of sha256sums/md5sums. -Dan
Re: [arch-general] [arch-dev-public] [signoff] vpnc 0.5.3-4
On Mon, Aug 15, 2011 at 11:11 AM, Dave Reisner wrote: > On Sat, Aug 13, 2011 at 11:08:15AM +0200, Thomas Bächler wrote: >> Fix FS#25002 (add net-tools dep for now), FS#23452 (fix path, add >> optdepend) and FS#25095 (add supplied patch). >> >> Please sign off. >> >> I also want to mention that I don't use vpnc anymore, and haven't done >> so for years. I don't want to keep maintaining it, so if there are >> takers among the devs, please step up. >> > > Anyone else? User signoffs are welcome. > > I'd like to get this moved to core soon-ish to make way for some more > concrete changes, namely: > > * Updating to an svn tarball which has some lovely bug fixes -- several > other distros are packaging trunk. > * An updated vpnc-script maintained by David Woodhouse (intel employee > and major kernel contributor) [1]. He's added ipv6 support and a few > bugfixes as well. > > I've also sent David a pull request to get rid of the net-tools > dependency (at least in Linux) and fix a bug in his updates. > > d > > [1] http://git.infradead.org/users/dwmw2/vpnc-scripts.git 1. Why is this even in [core]? It doesn't seem essential at all to most systems. 2. The updates sound smart to me. -Dan
[arch-general] [translation] Pacman 3.5.3 release soon
If you are interested in updating any translations before I release this maint version early next week, please do so: https://www.transifex.net/projects/p/archlinux-pacman/r/3-5-3/ Thanks! -Dan
Re: [arch-general] [arch-dev-public] Developer reports
On Fri, Apr 29, 2011 at 9:24 PM, Evangelos Foutras wrote:
> On 30 April 2011 04:26, Dan McGee wrote:
>> On Fri, Apr 29, 2011 at 7:23 PM, Eric Bélanger
>> wrote:
>>> 2- The report for large packages should list the sizes in MB instead of
>>> bytes.
>> That would make the generic nature of these reports a lot harder,
>> and/or involve me sinking quite a bit of time into making something
>> generic that formats sizes. Deal with it for now. :)
>
> filesizeformat [1] built-in filter to the rescue.
Trust me, I knew it existed as we use it on the package details page. :)
> However, I'm not
> sure if it'll mess up the jQuery sort thingy.
I am sure of this, thus my reasoning above that I didn't fully
explain- I didn't think anyone would actually challenge me on it, but
I'm glad you did. In this case, I think the only two endings you will
see are MB and GB, but those will then incorrectly sort if I'm
guessing correctly.
> To run this filter for
> the package compressed/installed size, the template code [2] might be
> modified to something like this:
I guess this is what qualifies in my book as "dirty"- I don't like
having these two attributes hardcoded here. Yes, I know this extra
stuff only ever comes into play with them now, but what if we move
flag_date to extra, etc.- do we continue adding {% if %} blocks?
The correct solution to me would be:
1. add another custom tablesort ordering; see archweb.js for our
current listing of them.
http://projects.archlinux.org/archweb.git/tree/media/archweb.js#n5
2. Make the "attribute" template tag itself smarter and always return
a smartly formatted string rather than the raw attribute value (or
perhaps make a format_attribute filter or something). hopefully it
depends more on types than on attribute names for what it does. E.g.
dates go through the "date" filter, integer fields that end in "size"
always get filesizeformat treatment, etc. Then the template won't
change much at all.
3. ???
4. Profit
>
> {% for attr in column_attrs %}
>
> {% if attr == 'compressed_size' or attr == 'installed_size' %}
> {{ pkg|attribute:attr|filesizeformat }}
> {% else %}
> {{ pkg|attribute:attr }}
> {% endif %}
>
> {% endfor %}
>
> [1]
> http://docs.djangoproject.com/en/1.3/ref/templates/builtins/#filesizeformat
> [2]
> http://projects.archlinux.org/archweb.git/tree/templates/devel/packages.html?id=381e0a787205af530ae11bac1b1a17e567eecc84#n41
>
Re: [arch-general] [translation] Pacman 3.5.2 string freeze
On Mon, Apr 11, 2011 at 2:13 PM, Dan McGee wrote: > This is a message to all past/present/future translators that I'd like > to do the pacman 3.5.2 release around the end of this week, so if you > could take a look at the translations and get them up to date that > would be great: > https://www.transifex.net/projects/p/archlinux-pacman/r/3-5-2/ > > There are only a handful of new and/or changed strings (6 to 20 > depending on the language and last update), so updating should be > quick for most languages. There are also a handful of languages that > have not seen an update in a bit, and would appreciate your help: > Catalan, Danish, Portuguese, Slovak, Swedish, Ukrainian, and Norwegian > Bokmål. A reminder email for anyone still looking to get their changes in. I'd like to roll the release on Sunday, 17 April if possible so please get your changes in before then! Still in need of minor updates (<20 strings): Norwegian Bokmål, Czech, Finnish, Kazakh, French, Hungarian, Russian Slightly more intensive updates (<100 strings): Danish, Portuguese, Slovak, Swedish, Ukrainian -Dan
[arch-general] [translation] Pacman 3.5.2 string freeze
This is a message to all past/present/future translators that I'd like to do the pacman 3.5.2 release around the end of this week, so if you could take a look at the translations and get them up to date that would be great: https://www.transifex.net/projects/p/archlinux-pacman/r/3-5-2/ There are only a handful of new and/or changed strings (6 to 20 depending on the language and last update), so updating should be quick for most languages. There are also a handful of languages that have not seen an update in a bit, and would appreciate your help: Catalan, Danish, Portuguese, Slovak, Swedish, Ukrainian, and Norwegian Bokmål. To the German translator, as I got no feedback after the initial comment: https://bugs.archlinux.org/task/23575 Thanks everyone! Please direct your questions/comments to the pacman-dev ML or include me in any replies as I no longer receive arch-general mailing list posts. -Dan
Re: [arch-general] [translation] Let's start the work for 3.5.0 release
On Mon, Feb 28, 2011 at 11:33 AM, Dan McGee wrote: > We're using transifex this time around, and going cold turkey, so I > won't even look at translations submitted here. > > http://projects.archlinux.org/pacman.git/tree/doc/translation-help.txt > > The transifex help and the tx client will likely be your friend here. > `tx pull` and `tx push -t -l en_GB` were two commands I used to try > this whole system out. As I mentioned earlier, you will need > transifex-client-hg (https://aur.archlinux.org/packages.php?ID=45787) > from the AUR. > > Questions- send them to the list. Translations- please do not. OK- we have most of them in, I'm going to set a deadline of this Sunday (March 13) so we can release early next week. Here is the status: http://www.transifex.net/projects/p/archlinux-pacman/r/3-5-0/ -Dan
Re: [arch-general] [arch-dev-public] [signoff] ncurses-5.8-1
On Sun, Feb 27, 2011 at 3:04 PM, Loui Chang wrote: > On Sun 27 Feb 2011 12:01 -0600, Dan McGee wrote: >> On Sat, Feb 26, 2011 at 7:55 PM, Allan McRae wrote: >> > On 27/02/11 10:40, Allan McRae wrote: >> >> >> >> Major upstream update. >> >> >> >> Test well. There is no soname bump, but experience tells me that some >> >> rebuilds will probably be required to fix minor issues. >> >> >> > >> > I have rebuilt community/stfl to fix a crash (used by newsbeuter). >> > >> > I will start a TODO list to keep track of packages that require moved with >> > ncurses. If you do any rebuilds, please add the package to the list. >> >> $ tig >> tig: Failed to create status window >> >> I added it to the list (but didn't rebuild it). > > Rebuild won't do it. tig wants to create zero sized windows which > newwin() doesn't allow anymore. We could patch it with some arbitrary > size which kind of works, but I emailed the developer to ask how he > would deal with it. Bagh! Thanks for looking into this and following up on the details, I appreciate it. -Dan
Re: [arch-general] [arch-dev-public] [extra] repository cleanup
On Wed, Nov 17, 2010 at 7:31 AM, 甘露(Gan Lu) wrote: > On Wed, Nov 17, 2010 at 9:10 PM, Heiko Baums wrote: >> I know I'm crossposting this, but this rather belongs to arch-general >> than to aur-general. >> >> Am Tue, 16 Nov 2010 23:19:40 -0500 >> schrieb Kaiting Chen : >> >>> I think it's kind of hard for me to see why I should maintain a >>> package that's already been discarded by its developer. In my opinion >>> such packages should be moved to [unsupported] where the one more two >>> people who might want to use them can simply build them themselves. >> >> Why should those packages be removed from the repos as long as they are >> running? That doesn't make sense. And such packages doesn't make any >> work for the developers. They can just be staying in the repos without >> doing any harm like e.g. eboard. > You got my point. >> >> Regarding ding as an example doesn't make much work for the devs >> because it's updated by upstream every two years. And this package is >> really popular at least in Germany, because it's an English-German >> dictionary. And this tool is really old - but not outdated and >> unmainted. It's one of the first Linux applications and available in >> every repo of every distro. >> >> And the question is not cleaning up the repos in principle. The >> question is this mass cleanup and the removal of several popular and >> important packages even if they are orphaned. >> >> If there's an orphan quite popular then an unorphaned packages which is >> not popular or important could be moved to AUR and the orphaned and >> more popular package could be adopted by this dev. Just an example. >> >> squashfs-tools are necessary for building LiveCDs incl. the Arch Linux >> installation CD as far as I know. So I'm not sure if this package >> actually wouldn't belong to [core]. >> >> btrfs-progs also doesn't belong to AUR. This package belongs into >> [core] and should be supported by AIF. Even if it's still marked as >> experimental, many people in the web report that it's pretty stable and >> that it's only missing an fsck. And many people report that it's >> usable on systems which don't need to be absolutely reliable. >> >> Btw., instead of the stable package btrfs-progs there's a package >> btrfs-progs-unstable in [extra] which really makes sense as the repos >> are meant to be stable repos. >> >> eboard, a still working and good chess GUI, was moved from [extra] to >> AUR. It's not maintained by upstream anymore but it's still working, >> it's quite popular and doesn't make any work for the devs. Having this >> in [extra] means there's a compiled and working package which doesn't >> need to be maintained. Having this package in AUR means that every user >> who wants to install this package must compile this package by himself. >> So what sense does this cleanup make? It makes completely no sense! >> >> epdfviewer is a very popular because lightweight PDF viewer for GTK. >> Galculator is the best calculator for GTK I know and also quite >> popular, at lest recommended quite often e.g. in the Xfce wiki. What's >> such a package doing in AUR? >> >> And, please, don't tell me anything about missing interest of the devs. >> As if every dev is using every package which he maintains himself or >> every dev only maintains only packages he is using himself. >> >> This is what I name and shame. >> >> This mass cleanup was just done inconsiderately. >> >> I really respect the voluntary work of the devs and TUs. And I really >> honor their work in their spare time. And I don't expect too much. But >> if a repo shall be cleaned up this must be done a lot more considered. > We are practical people, aren't we? Please reconsider this cleanup, > thanks. I don't mean it's bad, but please reconsider some. Five step plan to success: 1) Actually contribute instead of whining on a mailing list 2) Get your name known in the TU/dev circles 3) Apply for a position where you can contribute more 4) Have your opinion actually count because we know you do work instead of act as a roadblock 5) Become jaded like the rest of us, realizing that users always think the world is ending, and when they say "this is shame", "I'm leaving", "you suck", "developers are selfish", none of the developers have ever really cared and would rather poisonous people leave anyway. Because I enjoy getting things done, I'm now done with arch-general, and I know several other devs have unsubscribed as of late because of the useless traffic and emails like this one. Add me to that list. -Dan
Re: [arch-general] Replace dcron once again?
On Friday, November 12, 2010, Allan McRae wrote: > Surely someone can run a git bisect on this issue. It is a reasonably new > occurrence. > > Or are we just going to switch software every time a bug is found... But I want my bikeshed to be red!
Re: [arch-general] Postgresql-docs is Broken
On Fri, Oct 29, 2010 at 10:37 AM, Steve Holmes wrote: > I just downloaded the latest 9.01 version of postgresql-docs which > supposedly should contain the html documentation for postgresql. > Alas, the package size is less than 1 K and when installed, a > pacman -Qql > only reveals some man directories under /usr/share. There are no > files present. Is anyone aware of this situation? It is a bug, but this isn't the place for reporting it... https://bugs.archlinux.org/?project=1 It is pretty easy to confirm yourself, note the difference in size and the files list: http://www.archlinux.org/packages/extra/i686/postgresql-docs/ http://www.archlinux.org/packages/extra/x86_64/postgresql-docs/ Finally, always include the arch of the package if it is not arch='any'. -Dan
Re: [arch-general] What's happening about libdjvu?
On Thu, Oct 21, 2010 at 10:22 AM, Thomas Bächler wrote: > Am 21.10.2010 15:56, schrieb Auguste Pop: >> I noticed this by compiling the package myself... When I sent this >> mail, the web page was not updated and I saw an old list of files that >> did not contain the .so file. I should have tried it first rather than >> relying on a presumably delayed response on the web site. Sorry for >> the false alarm. > > The update of the file list in the web interface might be delayed > compared to the update of the package data itself. > > Dan, what can we do here? Should a version mismatch between $repo.db and > $repo.files cause archweb to discard the file list, stating that "There > is currently no file list available for this package", or should archweb > print a warning "This is a file list from an older version of this > package and might differ from the current package". Is anything like > this already done in archweb? Should it? > > Right now, the delay between updating the package info and the file list > can be (in the worst case) little over 24 hours. Given that our packages > update and change frequently, I think we should avoid confusion like in > Auguste's case. It's actually updated every 12 hours, and this is an extreme case. We shouldn't hide the filelist for all new packages when 90% of the time the list doesn't change. We can put a "this might be out of date" message there quite easily, I'll look into it sometime but a feature request/bug report would be awesome so I don't lose track of it. -Dan
Re: [arch-general] [arch-dev-public] db-5.1 rebuild
On Wed, Oct 20, 2010 at 2:43 PM, Evangelos Foutras wrote: > On Tue, Oct 19, 2010 at 7:58 AM, Allan McRae wrote: >> Hi, >> >> Time to move on to the next rebuild! This time it is for db-5.1. >> >> There are the following soname changes: >> libdb-4.8.so -> libdb-5.1.so >> libdb-4.so -> libdb-5.so >> libdb_cxx-4.8.so -> libdb_cxx-5.1.so >> libdb_cxx-4.so -> libdb_cxx-5.so >> >> It is a relatively small rebuild of 39 packages. >> >> I never got around to the db-5.0 update but that is a good thing as many >> pieces of software check for a db major version >= 4 and minor version >= 1 >> when they just want db>=4.1... Now we have db-5.1 we do not have to fix >> that stupidness. As always, more evidence that laziness pays off. >> >> I have pushed the db update to [staging] and will work on the rest of [core] >> later tonight (unless someone beats me to it...) >> >> Allan > > What do we do for stuff like PHP which will get linked to PostgreSQL > 9.0.1 which is in [testing] right now? Or will PostgreSQL be moved out > of [testing] at the same time as the db rebuilds? There was no .so bump, so it shouldn't matter. -Dan
Re: [arch-general] Python 3 Rationale?
On Wed, Oct 20, 2010 at 11:02 AM, Matthew Gyurgyik wrote: > On 10/20/2010 11:45 AM, maxc wrote: >> >> There is an excellent post by Guido here, Hilton: >> http://mail.python.org/pipermail/python-3000/2008-February/011910.html >> >> Guido seems to favor using /usr/bin/python3.0 or /usr/bin/python3 and >> /usr/bin/python as symlinks to the respective versions of Python. >> >> 'Perhaps we should only install "python3.0" and not "python".' >> >> We're not here to discussion semantics ofc. :) There is a much broader >> concern which I hope we can address through friendly discourse. >> >> On Oct 20, 2010, at 11:26 AM, Hilton Medeiros >> wrote: >> >>> On Wed, 20 Oct 2010 10:58:42 -0400 >>> Max Countryman wrote: >>> >>> > That is fine unless the Python development team has decide that >>> > python3 will not become python. >>> > >>> > Python 2.7.x will be maintained for quite some time. (In excess of >>> > four more years.) Even after it is dropped in the future there's no >>> > indication that the python3 binary is intended to become the python >>> > binary. >>> > >>> > The link I posted earlier to the thread on the Python mailing list >>> > seems to indicate the opposite. >>> >>> A 'python' binary doesn't and won't ever exist, it is only a >>> symlink, Max. > > Since you have seemed to miss my previous post. I'll post again! > > Really please, please don't top post. > http://www.river.com/users/share/etiquette/ Fucking hell! Can we stop with this constant nagging on the list? It doesn't help (as you can see), you waste 1926 people's time with the message (yes, this list has this many subscribers, and it is soon to be one less), and it just doesn't need to be said. I'm sure you made it through the message content just fine, even with the top post. Things that piss list subscribers (or at least me) off: * Bitching about top posting * Repeated posts containing no new information * More than two emails without either party doing anything except having a public argument * Not understanding the subject of an email and still responding (several emails in this thread have done so...) * Changing the topic without changing the subject * Voting on something that is not a vote So you don't piss other subscribers off, if you want to bitch at/about me, please do it off-list. Getting off my soapbox now, -Dan (the Arch Developer)
Re: [arch-general] Setuptools broken?
On Tue, Oct 19, 2010 at 6:37 PM, Ray Rashif wrote: > On 20 October 2010 07:25, Norbert Zeh wrote: >> Hi folks, >> >> With the python upgrade from 2.7 to 3.1, I ran into the following snag. >> gitosis from AUR depends on python and setuptools. Now, python = >> python3.1 now and setuptools installs in the python2.7 library tree. >> This was easy enough to fix, by simply replacing python with python2 in >> the gitosis PKGBUILD. However, I would expect that python2 will >> disappear completely somewhere down the road. What then? Moreover, >> being a purist, I would like to avoid having two python versions >> installed on my machine. So what's the deal with python3.1 and >> setuptools? Is the procedure for installing python packages different >> under 3.1 than under the old 2.x series, and there simply are no >> setuptools any more? If that's the case, I guess it's the >> responsibility of package maintainers to migrate to the setup used in >> python3.1. If setuptools is still what is needed in python3.1, >> shouldn't there now be two packages setuptools and setuptools2 that >> install in the library trees of python3.1 and python2.7, respectively? >> (I'm happy to file a bug report if this is indeed a bug.) > > Python 3 should be using distribute [1] instead of setuptools. Either > way, you don't need to worry. Most software still require Python 2, > and by the time we do drop python2, everything should be working. Well if you're still around in like 2019 when python2 disappears, we might have problems, but I wouldn't hold your breath. -Dan
Re: [arch-general] [arch-dev-public] PostgreSQL 9.0.1 in [testing]
On Tue, Oct 19, 2010 at 9:35 AM, Dan McGee wrote: > On Tue, Oct 19, 2010 at 9:20 AM, Jan Steffens wrote: >> On Tue, Oct 19, 2010 at 2:39 PM, Dan McGee wrote: >>> Community feedback welcome as well, but this is now in testing now >>> that the Python rebuild has moved on. Please let me know (good and >>> bad) how things are going with it so I can move it along to [extra]. >> >> Lots of stuff seems to be missing from the package (e.g. adminpack.so). > > I'm not sure why I had that `make -C contrib uninstall` line in there; > I'll take a look. OK, stupidity should be fixed in 9.0.1-2. -Dan
Re: [arch-general] [arch-dev-public] PostgreSQL 9.0.1 in [testing]
On Tue, Oct 19, 2010 at 9:20 AM, Jan Steffens wrote: > On Tue, Oct 19, 2010 at 2:39 PM, Dan McGee wrote: >> Community feedback welcome as well, but this is now in testing now >> that the Python rebuild has moved on. Please let me know (good and >> bad) how things are going with it so I can move it along to [extra]. > > Lots of stuff seems to be missing from the package (e.g. adminpack.so). I'm not sure why I had that `make -C contrib uninstall` line in there; I'll take a look. -Dan
Re: [arch-general] Creation of startup scripts
On Tue, Oct 5, 2010 at 3:55 PM, Christian wrote: > Hi all, > I am learning more and more about Linux, but I would like to learn how to > create startup scripts for my programs, any good resource? Where should I > start? > Many thanks, > Christian Startup scripts are pretty specific to each distro. * http://wiki.archlinux.org/index.php/Writing_rc.d_scripts * http://www.justinbritten.com/work/2009/05/god-initd-script-for-centos/ -Dan
Re: [arch-general] PostgreSQL 9.0.0 PKGBUILD
On Mon, Sep 27, 2010 at 5:52 AM, Jan Steffens wrote: > On Mon, Sep 27, 2010 at 12:45 PM, Andrea Scarpino > wrote: >> Ditt fo 8.4.4-5 IS NOT attached. >> >> :) > > My outgoing email definitely had it attached. Maybe it got filtered? > > Anyway, here's a link: > http://pkgbuild.com/~heftig/pg.diff So you nixed the contrib and src/include directories because make world covers all of that? -Dan
Re: [arch-general] scp bash-completion hangs
On Thu, Sep 30, 2010 at 9:12 PM, Matthew Monaco wrote: > Anyone experiencing any issues with bash-completion for scp? > > When attempting to scp a local file to a remote machine, and I try to tab > complete the local filename, bash just hangs until I ctrl-c. > > Might be be trying to complete the file on a non-existent remote server or > something like that? https://bugs.archlinux.org/task/20775
Re: [arch-general] Booting Arch under Xen via pv-grub. Was: Re: [signoff] kernel26 2.6.35.7-1
On Thu, Sep 30, 2010 at 3:52 AM, Liu Yu Fei, Eric wrote: > My VPS is also on Linode. > I have just changed my mkinitcpio.conf to > > MODULES="xen-fbfront evtchn xenfs xen-blkfront xen-netfront xen-kbdfront > netxen_nic" > HOOKS="base udev autodetect pata scsi sata filesystems" > > However, when executing the command "mkinitcpio -k 2.6.35-ARCH", I got the > following errors: > > ERROR: module 'xen_fbfront' not found > ERROR: module 'evtchn' not found > ERROR: module 'xenfs' not found > ERROR: module 'xen_blkfront' not found > ERROR: module 'xen_netfront' not found > ERROR: module 'xen_kbdfront' not found > > And then I check for the kernel module files: > > darkwh...@www:~$ ls > /lib/modules/2.6.35-ARCH/kernel/drivers/input/xen-kbdfront.ko > ls: cannot access > /lib/modules/2.6.35-ARCH/kernel/drivers/input/xen-kbdfront.ko: No such file > or directory > darkwh...@www:~$ ls > /lib/modules/2.6.35-ARCH/kernel/drivers/net/xen-netfront.ko > ls: cannot access > /lib/modules/2.6.35-ARCH/kernel/drivers/net/xen-netfront.ko: No such file or > directory > darkwh...@www:~$ ls > /lib/modules/2.6.35-ARCH/kernel/drivers/video/xen-fbfront.ko > ls: cannot access > /lib/modules/2.6.35-ARCH/kernel/drivers/video/xen-fbfront.ko: No such file > or directory > darkwh...@www:~$ ls /lib/modules/2.6.35-ARCH/kernel/drivers/xen/evtchn.ko > ls: cannot access /lib/modules/2.6.35-ARCH/kernel/drivers/xen/evtchn.ko: No > such file or directory > darkwh...@www:~$ ls > /lib/modules/2.6.35-ARCH/kernel/drivers/xen/xenfs/xenfs.ko > ls: cannot access > /lib/modules/2.6.35-ARCH/kernel/drivers/xen/xenfs/xenfs.ko: No such file or > directory > darkwh...@www:~$ ls > /lib/modules/2.6.35-ARCH/kernel/drivers/net/netxen/netxen_nic.ko > /lib/modules/2.6.35-ARCH/kernel/drivers/net/netxen/netxen_nic.ko > > So I am wondering whether there is something wrong during the packaging > process? Are you building your own kernel? These files are in the Arch stock kernel package: $ find /lib/modules/ -name 'xen*.ko' /lib/modules/2.6.35-ARCH/kernel/drivers/net/xen-netfront.ko /lib/modules/2.6.35-ARCH/kernel/drivers/block/xen-blkfront.ko /lib/modules/2.6.35-ARCH/kernel/drivers/xen/xenfs/xenfs.ko /lib/modules/2.6.35-ARCH/kernel/drivers/input/xen-kbdfront.ko /lib/modules/2.6.35-ARCH/kernel/drivers/video/xen-fbfront.ko $ find /lib/modules/ -name 'xen*.ko' | xargs pacman -Qo /lib/modules/2.6.35-ARCH/kernel/drivers/net/xen-netfront.ko is owned by kernel26 2.6.35.7-1 /lib/modules/2.6.35-ARCH/kernel/drivers/block/xen-blkfront.ko is owned by kernel26 2.6.35.7-1 /lib/modules/2.6.35-ARCH/kernel/drivers/xen/xenfs/xenfs.ko is owned by kernel26 2.6.35.7-1 /lib/modules/2.6.35-ARCH/kernel/drivers/input/xen-kbdfront.ko is owned by kernel26 2.6.35.7-1 /lib/modules/2.6.35-ARCH/kernel/drivers/video/xen-fbfront.ko is owned by kernel26 2.6.35.7-1
Re: [arch-general] Old "news"
On Wed, Sep 22, 2010 at 2:34 AM, Dieter Plaetinck wrote: > On Wed, 22 Sep 2010 12:20:29 +0530 > Nilesh Govindarajan wrote: > >> On Wed, Sep 22, 2010 at 12:05 PM, 甘露(Gan Lu) >> wrote: >> > On Wed, Sep 22, 2010 at 2:31 PM, Mike Sampson >> > wrote: >> >> On Wed, Sep 22, 2010 at 4:28 PM, jesse jaara >> >> wrote: >> >>> Did anyone else revice some old maiöing list messages i got few >> >>> about xorg1.8 miving to extra and announment if 2010.5 install >> >>> meedia and some others >> >>> >> >> >> >> Yeah, me too. >> > My RSS reader listed 10 new "old" news too. >> >> >> >> Mike >> >> >> > >> >> I got all of them in mail from arch-announce :/ >> > > Both the rss feed and arch-announce have this behavior. I guess the > program that sends mail to arch-announce just follows the newsfeed as > well. The URLs for all news items changed, so your news feed probably saw this and thought the items were new. I'm not sure why Django uses the URL as a guid, but this should be a one-time occurrance. -Dan
Re: [arch-general] New pacman features: +package(), -return 1
On Tue, Sep 21, 2010 at 1:01 AM, Vitaliy Berdinskikh wrote: > Hi! > > Where can I read about new features? > > http://wiki.archlinux.org/index.php/PKGBUILD - nothing > http://wiki.archlinux.org/index.php/Pacman - nothing man PKGBUILD perhaps...
Re: [arch-general] [PATCH 1/3] Updating documentation
On Fri, Sep 17, 2010 at 3:34 PM, Angel Velasquez wrote: > Adding required dependencies like south, markdown and memcached > > Signed-off-by: Angel Velasquez > --- > README | 7 +-- > requirements.txt | 1 + > 2 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/README b/README > index ec0829e..a5032ac 100644 > --- a/README > +++ b/README > @@ -8,12 +8,15 @@ > - python > - mysql-python or python-pysqlite > - Django >= 1.2.X > + - python-markdown > + - python-memcached > + - python-south > > # Installation > For a simple testing installation: > > 1. Install dependencies. > - $ pacman -S django python-pysqlite sqlite3 > + $ pacman -S django python-pysqlite sqlite3 python-markdown > python-memcached python-south This works great, but I did add pip requirements.txt files. I should probably change the README to detail virtualenv creation and usage. > 2. Copy local_settings.py.example to local_settings.py and modify. > Make sure to uncomment the appropriate db section (either sqlite or > mysql). > @@ -22,7 +25,7 @@ For a simple testing installation: > $ python manage.py syncdb > > 4. Load the fixtures to prepopulate some data. > - $ python manage.py loaddata arches.json repos.json > + $ python manage.py loaddata main/fixtures/arches.json > main/fixtures/repos.json > > 5. Use the following commands to start a service instance > $ python manage.py runserver > diff --git a/requirements.txt b/requirements.txt > index 6d858a1..6dbe741 100644 > --- a/requirements.txt > +++ b/requirements.txt > @@ -1,3 +1,4 @@ > Django==1.2.3 > Markdown==2.0.3 > South==0.7.2 > +Memcached=1.45 This is in requirements_prod.txt; you don't strictly need memcached for development. > -- > 1.7.2.3 > >
Re: [arch-general] [PATCH 2/3] Fixing south scripts
On Fri, Sep 17, 2010 at 3:35 PM, Angel Velasquez wrote:
> Table main_mirror was renamed to mirror_mirrors then it fails at the
> time to re-create the schema
You're doing this completely wrong. Migrations apply sequentially. If
you can not build a database from scratch using syncdb, please let me
see those errors here. You will want to add depends as necessary to
the migrations, not change past migrations that applied when they were
created.
-Dan
> Signed-off-by: Angel Velasquez
> ---
> main/migrations/0008_mirror_tiering.py | 8
> main/migrations/0009_mirror_rsync_credentials.py | 8
> main/migrations/0010_kill_rsync_ip_hostname.py | 4 ++--
> main/migrations/0011_mirror_notes_text_field.py | 4 ++--
> .../migrations/0014_mirror_notes_rsync_optional.py | 8
> 5 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/main/migrations/0008_mirror_tiering.py
> b/main/migrations/0008_mirror_tiering.py
> index 3993289..9dfbd6f 100644
> --- a/main/migrations/0008_mirror_tiering.py
> +++ b/main/migrations/0008_mirror_tiering.py
> @@ -5,15 +5,15 @@ from main.models import *
> class Migration:
> def forwards(self, orm):
> # Adding field 'Mirror.tier'
> - db.add_column('main_mirror', 'tier', orm['main.mirror:tier'])
> + db.add_column('mirrors_mirror', 'tier', orm['main.mirror:tier'])
> # Adding field 'Mirror.upstream'
> - db.add_column('main_mirror', 'upstream', orm['main.mirror:upstream'])
> + db.add_column('mirrors_mirror', 'upstream',
> orm['main.mirror:upstream'])
>
> def backwards(self, orm):
> # Deleting field 'Mirror.tier'
> - db.delete_column('main_mirror', 'tier')
> + db.delete_column('mirrors_mirror', 'tier')
> # Deleting field 'Mirror.upstream'
> - db.delete_column('main_mirror', 'upstream_id')
> + db.delete_column('mirrors_mirror', 'upstream_id')
>
> models = {
> 'auth.group': {
> diff --git a/main/migrations/0009_mirror_rsync_credentials.py
> b/main/migrations/0009_mirror_rsync_credentials.py
> index bbfc9d6..274490f 100644
> --- a/main/migrations/0009_mirror_rsync_credentials.py
> +++ b/main/migrations/0009_mirror_rsync_credentials.py
> @@ -5,15 +5,15 @@ from main.models import *
> class Migration:
> def forwards(self, orm):
> # Adding field 'Mirror.rsync_user'
> - db.add_column('main_mirror', 'rsync_user',
> orm['main.mirror:rsync_user'])
> + db.add_column('mirrors_mirror', 'rsync_user',
> orm['main.mirror:rsync_user'])
> # Adding field 'Mirror.rsync_password'
> - db.add_column('main_mirror', 'rsync_password',
> orm['main.mirror:rsync_password'])
> + db.add_column('mirrors_mirror', 'rsync_password',
> orm['main.mirror:rsync_password'])
>
> def backwards(self, orm):
> # Deleting field 'Mirror.rsync_user'
> - db.delete_column('main_mirror', 'rsync_user')
> + db.delete_column('mirrors_mirror', 'rsync_user')
> # Deleting field 'Mirror.rsync_password'
> - db.delete_column('main_mirror', 'rsync_password')
> + db.delete_column('mirrors_mirror', 'rsync_password')
>
> models = {
> 'auth.group': {
> diff --git a/main/migrations/0010_kill_rsync_ip_hostname.py
> b/main/migrations/0010_kill_rsync_ip_hostname.py
> index 105fced..86d9a92 100644
> --- a/main/migrations/0010_kill_rsync_ip_hostname.py
> +++ b/main/migrations/0010_kill_rsync_ip_hostname.py
> @@ -5,11 +5,11 @@ from main.models import *
> class Migration:
> def forwards(self, orm):
> # Deleting field 'MirrorRsync.hostname'
> - db.delete_column('main_mirrorrsync', 'hostname')
> + db.delete_column('mirrors_mirrorrsync', 'hostname')
>
> def backwards(self, orm):
> # Adding field 'MirrorRsync.hostname'
> - db.add_column('main_mirrorrsync', 'hostname',
> orm['main.mirrorrsync:hostname'])
> + db.add_column('mirrors_mirrorrsync', 'hostname',
> orm['main.mirrorrsync:hostname'])
>
> models = {
> 'auth.group': {
> diff --git a/main/migrations/0011_mirror_notes_text_field.py
> b/main/migrations/0011_mirror_notes_text_field.py
> index cb6347d..2bcc34d 100644
> --- a/main/migrations/0011_mirror_notes_text_field.py
> +++ b/main/migrations/0011_mirror_notes_text_field.py
> @@ -6,12 +6,12 @@ class Migration:
> def forwards(self, orm):
> # Changing field 'Mirror.notes'
> # (to signature: django.db.models.fields.TextField(blank=True))
> - db.alter_column('main_mirror', 'notes', orm['main.mirror:notes'])
> + db.alter_column('mirrors_mirror', 'notes', orm['main.mirror:notes'])
>
> def backwards(self, orm):
> # Changing field 'Mirror.notes'
> # (to signature: django.db.models.fields.CharField(max_length=255,
> blank=True))
> - db.alter_column('main_mirror', 'notes', orm['main.mirror:notes'])
> + db.alter_column('mirrors_mirror', 'notes', orm[
Re: [arch-general] "$startdir/src", "$startdir/pkg" and "|| return 1" in official packages
On Fri, Sep 17, 2010 at 9:14 AM, Dieter Plaetinck wrote:
> On Fri, 17 Sep 2010 16:07:30 +0200
> Lukas Fleischer wrote:
>
>
>> > Anyway, whats the rush? They will change eventually. There should
>> > be no (or very few) $startdir/{src,pkg} in [core].
>>
>> As I already said at the beginning:
>>
>> > Although this isn't really significant... I was just curious :)
>>
>> Just thought that might be an easy way to clean up and unify packages
>> a bit.
>
> If a fix can be applied on all packages at once, that seems more
> efficient and less error-prone to me. But I'm not a packager, so do
> what you want :)
I wouldn't object to doing this to everything in trunk/, but we
shouldn't push those changes out to the repos/ unless the package
actually gets rebuilt. Those should reflect the current state of the
package as much as possible.
-Dan
Re: [arch-general] [namcap] [PATCH] Check for packages that should be 'any'
On Sun, Aug 1, 2010 at 7:47 PM, David Campbell wrote:
> If a package has no elf files but is not 'any', throw a warning saying that
> the package could be 'any'.
> ---
> Namcap/anyelf.py | 18 ++
> namcap-tags | 1 +
> 2 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/Namcap/anyelf.py b/Namcap/anyelf.py
> index f3414af..c037ff0 100644
> --- a/Namcap/anyelf.py
> +++ b/Namcap/anyelf.py
> @@ -33,20 +33,22 @@ class package:
> def short_name(self):
> return "anyelf"
> def long_name(self):
> - return "If package is 'any' architecture, check for ELF files"
> + return """Check for ELF files to see if a package should be
> 'any'
> + architecture"""
This will be really ugly when it prints; you should just use a single
quoted string.
> def prereq(self):
> return "extract"
> def analyze(self, pkginfo, data):
> ret = [[], [], []]
> - if pkginfo.arch and pkginfo.arch[0] != 'any':
> - return ret
> found_elffiles = []
> -
> os.path.walk(data, scanelf, found_elffiles)
> - if len(found_elffiles) > 0:
> - for i in found_elffiles:
> - ret[0].append(("elffile-in-any-package %s",
> i))
> -
> +
> + if pkginfo.arch and pkginfo.arch[0] == 'any':
> + if len(found_elffiles) > 0:
> + for i in found_elffiles:
> +
> ret[0].append(("elffile-in-any-package %s", i))
> + else:
> + if len(found_elffiles) == 0:
> +
> ret[1].append(("no-elffiles-and-not-any-package", ()))
> return ret
>
> def type(self):
> diff --git a/namcap-tags b/namcap-tags
> index acb8e9c..4040136 100644
> --- a/namcap-tags
> +++ b/namcap-tags
> @@ -47,6 +47,7 @@ missing-license :: Missing license
> missing-maintainer :: Missing Maintainer tag
> missing-checksums :: Missing checksums
> missing-url :: Missing url
> +no-elffiles-and-not-any-package :: No ELF files and not an "any" package
Let's drop the 'and' from here to shorten it up.
> non-fhs-info-page %s :: Non-FHS info page (%s) found. Use /usr/share/info
> instead
> non-fhs-man-page %s :: Non-FHS man page (%s) found. Use /usr/share/man
> instead
> not-a-common-license %s :: %s is not a common license (it's not in
> /usr/share/licenses/common/)
> --
> 1.7.1.1
Applied, made a few small changes as stated above. Sorry this got lost
in the depths of the inbox.
[arch-general] PostgreSQL 8.4.4-4 in [testing]
I put a new version (8.4.4-4) of Postgres in [testing] tonight that fixes quite a few issues and wanted to just give it a few days to bake before pushing it to extra. Let me know if you see any issues with the new package. * FS#20556 - [postgresql] should be compiled with more options and libs, for a features reach package * FS#16507 - [postgresql] $PG_ROOT created with incorrect permissions * FS#19687 - [postgresql] no logrotate config * FS#18756 - [postgresql] package doesn't have contribs except adminpack -Dan P.S. If you tried 8.4.4-3, ignore the fact that it ever existed...yes there were conflicting files in the two packages.
Re: [arch-general] Pacman's superslow
On Thu, Sep 9, 2010 at 8:43 AM, Nilesh Govindarajan wrote: > On Wed, Sep 8, 2010 at 10:34 PM, Dan McGee wrote: >> On Wed, Sep 8, 2010 at 11:57 AM, Nilesh Govindarajan >> wrote: >>> I have an OpenVZ VPS running arch. >>> For some reason pacman is superslow, and I'm not allowed to create/use >>> loopback devices. >>> pacman-optimize takes nearly 5 minutes per run, no matter the last run >>> was just a minute ago. >> >> Unhelpful++ >> >> * Filesystem >> * Block device configuration >> * Total RAM, free -m output >> * uptime load avg numbers >> >> -Dan >> > > FS: Reiserfs (/dev/simfs / 30 GB usrquota grpquota) > 512 MB RAM, normally only 256 used. > Load Average ~ 1-5 (Instant) This is neither `free -m` output or `uptime` output. Buffers and cache values are important, thus the original request. At least I don't have time to debug issues when I don't get the *full* details I ask for. `df -h` would be good too, but I'm not going to waste my time here unless you offer some help and at least attempt to look into this on your own. With a load average between 1 and 5, I'm guessing you have several tasks high on disk I/O. I would recommend digging into `vmstat` and `iotop -o` output and doing debugging of your own. -Dan
Re: [arch-general] Pacman's superslow
On Wed, Sep 8, 2010 at 11:57 AM, Nilesh Govindarajan wrote: > I have an OpenVZ VPS running arch. > For some reason pacman is superslow, and I'm not allowed to create/use > loopback devices. > pacman-optimize takes nearly 5 minutes per run, no matter the last run > was just a minute ago. Unhelpful++ * Filesystem * Block device configuration * Total RAM, free -m output * uptime load avg numbers -Dan
Re: [arch-general] [signoff] mdadm-3.1.4-1
On Wed, Sep 1, 2010 at 1:44 AM, Tobias Powalowski wrote: > Two fixes related to configs that aren't using udev: > - Don't remove md devices which 'standard' names on --stop > - Allow dev_open to work on read-only /dev > And fixed regressions: > - Allow --incremental to add spares to an array > - Accept --no-degraded as a deprecated option rather than > throwing an error > - Return correct success status when --incrmental assembling > a container which does not yet have enough devices. > - Don't link mdadm with pthreads, only mdmon needs it. > - Fix compiler warning due to bad use of snprintf > - Fix spare migration > > Please signoff both arches Signoff x86_64
Re: [arch-general] rc.conf man page
On Mon, Aug 23, 2010 at 1:59 PM, Dave Reisner wrote: > I threw together a man page for rc.conf based on info gleaned from the > Wiki, rc.conf itself, and my own experiences. I offer it up for for > adoption into the initscripts package along with comments, critcisms, > and rotten tomatoes. The format is asciidoc, which is the same format > used by pacman. > > If desirable, I'm willing to compile other pages for system config files > in a similar manner. I like the idea of having manpages for this stuff. netcfg(8) already has a manpage, pacman has manpages, etc. and this is in the psuedo-standard asciidoc we've used for a lot of it. Do any of the developers object to adding some documentation to this Arch-specific stuff and having it be built and installed with the relevant packages? It is also a great way for people to get involved that don't feel as confident coding. -Dan
Re: [arch-general] makepkg devel_check svn issue
On Mon, Aug 23, 2010 at 3:37 AM, Andrea Fagiani wrote: > Hello, > > A little background : > when updating a svn package with makepkg, svn info gets called (in the > devel_check function) and then the "Last Changed Rev" extracted from its > output and $pkgver updated accordingly. > > However, while compiling stjerm-svn [1] (which I maintain in the AUR, btw) I > end up with a package that has pkgver=256 , but the actual revision checked > out by svn is 262. > I suspect it may be due to the fact that rev 257 created a new branch (you > can find the repository here) [2]. > > This could be easily fixed by considering the "Revision" value (instead of > "Last Changed Rev") in the svn info output. > > Question is, is this the desired behavior or did I just stumble into a bug > (and should, therefore, report it) ? If we used the checked out revision, every change in any branch/directory of a repository would cause the version to be bumped which is less than ideal. Using the "Last Changed Rev" value should be a unique identifier of a revision that is not as volatile. -Dan
Re: [arch-general] commitpkg script than handle better splitted package
On Tue, Aug 17, 2010 at 5:12 AM, Laurent Carlier wrote: > Le lundi 16 août 2010 17:30:54, vous avez écrit : >> Le lundi 16 août 2010 17:24:29, vous avez écrit : >> > Le lundi 16 août 2010 14:10:10, Dan McGee a écrit : >> > > Patches are a lot more likely to get looked at by any of us. And yes, >> > > this should probably be more than one patch. >> > > >> > > http://projects.archlinux.org/devtools.git/ >> > >> > Hre are the patches (5), i hope i've not introduce bug while merging my >> > changes to the git repo :-p >> > >> > 0001-Moved-file-s-sending-to-the-staging-dir-to-the-funct.patch >> > 0002-Doesn-t-manage-monolithic-and-splitted-packages-the-.patch >> > 0003-Detect-if-arch-is-redefined-in-the-package-function-.patch >> > 0004-Now-manage-if-arch-is-redefined-and-not-in-default-a.patch >> > 0005-Manage-redefintion-of-pkgver-and-pkgver-in-the-packa.patch >> >> patches are available here: >> http://pkgbuild.com/~lcarlier/ >> >> Regards, > > Rebased the patches, and add another patch: > 0006-Remove-useless-number-from-continue.patch Pierre, is this something you can review since you have taken the lead on devtools/dbscripts? -Dan
Re: [arch-general] commitpkg script than handle better splitted package
On Mon, Aug 16, 2010 at 6:50 AM, Laurent Carlier wrote: > http://pkgbuild.com/~lcarlier/communitypkg > > Currently all commands that send something to the repos are commented. > > - two seperate paths : monolithic or splitted package > - script take care when arch, pkgver, pkgrel are redefined in package() > functions > - archrelease is only called for archs who need update > > I guess ther can be some mistaes done but i'm not really a bash expert, but of > course comments are really welcome. Patches are a lot more likely to get looked at by any of us. And yes, this should probably be more than one patch. http://projects.archlinux.org/devtools.git/
Re: [arch-general] [arch-dev-public] [staging] repository: Let's give it a try!
On Wed, Aug 11, 2010 at 12:15 PM, Evangelos Foutras wrote: > On Wed, Aug 11, 2010 at 7:59 PM, Pierre Schmitz wrote: >> On Wed, 11 Aug 2010 19:40:56 +0300, Evangelos Foutras >> wrote: >>> On Wed, Aug 11, 2010 at 7:34 PM, Dan McGee wrote: >>>> On Wed, Aug 11, 2010 at 11:31 AM, Evangelos Foutras >>>> wrote: >>>>> On Wed, Aug 11, 2010 at 7:24 PM, Pierre Schmitz >>>>> wrote: >>>>>> Let me underline again that [staging] would be no regular repo that >>>>>> would be used by anyone directly. It mainly meant for collecting >>>>>> rebuilds. >>>>> >>>>> However, it would have to be used by anyone wanting to rebuild a >>>>> package against a new library that has been pushed to [staging]. >>>>> Therefore, it would need to be mirrored and added to /etc/pacman.conf >>>>> in our [testing] chroots. (By `our [testing] chroots' I mean the >>>>> chroots that developers and TUs have been using until now for building >>>>> packages for [testing].) >>>> >>>> No, it doesn't need to be mirrored. Developers have always had direct >>>> access to this, ask on the developer private list if you don't know >>>> the URL. >>>> >>>> -Dan >>> >>> Oh, neat. Can we, TUs, get access to it too? (Unless we already do and >>> I missed it.) >> >> ATM there wont be a need to have TUs access this repo. The main reason >> of excluding it from mirroring is to remove it later when we decide that >> this idea wasn't that great. We might think about mirroring it later >> though..its just the db file anyway as the packages will be kept in a >> pool. The only downside is that nobody should actually use that repo. >> (by thinking it would similar to Debians experimental) >> >> -- >> Pierre Schmitz, https://users.archlinux.de/~pierre > > I'm not sure what you mean with `at the moment', but if any rebuild > that affects [community] packages goes into [staging], TUs will need > access to it so the affected packages can be rebuilt. Also, it would > be desirable to immediately have access to the private mirror as this > eliminates any delay between the time when new packages get committed > to [testing] and the moment they reach the mirrors. Pierre seems to have forgotten about community-testing I guess. :) -Dan
Re: [arch-general] [arch-dev-public] [staging] repository: Let's give it a try!
On Wed, Aug 11, 2010 at 11:31 AM, Evangelos Foutras wrote: > On Wed, Aug 11, 2010 at 7:24 PM, Pierre Schmitz wrote: >> Let me underline again that [staging] would be no regular repo that >> would be used by anyone directly. It mainly meant for collecting >> rebuilds. > > However, it would have to be used by anyone wanting to rebuild a > package against a new library that has been pushed to [staging]. > Therefore, it would need to be mirrored and added to /etc/pacman.conf > in our [testing] chroots. (By `our [testing] chroots' I mean the > chroots that developers and TUs have been using until now for building > packages for [testing].) No, it doesn't need to be mirrored. Developers have always had direct access to this, ask on the developer private list if you don't know the URL. -Dan
Re: [arch-general] Israel ftp mirror
On Mon, Aug 9, 2010 at 10:29 AM, Netanel Shine wrote: > you can also download ArchLinux from Ftp protocol: > > ftp://mirror.isoc.org.il/pub/archlinux/iso/ > > (not only through HTTP like the archlinux.org/download say) > > someone can update it please? We have no contact info for this mirror. Can you please put the above as well as contact information in a bug report which will help keep this info in a place we can find it? The mirror is also currently listed as untirered, meaning we don't know where you are syncing from, so that would be helpful as well. -Dan
Re: [arch-general] [signoff] mdadm-3.1.3-1
On Sat, Aug 7, 2010 at 12:34 AM, Tobias Powalowski wrote: > This is a bugfix/stability release over 3.1.2 Signoff x86_64
Re: [arch-general] Packages Translate.
I don't need help, I need contributions and people to help maintain translations. If it is done once and then left to rot, it would be hard to justify it's use. I think the first step would be to see if other foreign language users are willing to help and maintain translations, and from there go to work seeing how the Django internationalization would work. -Dan On Sun, Aug 8, 2010 at 11:00 AM, Netanel Shine wrote: > So, do you need some help? > > On Sun, Aug 8, 2010 at 6:19 PM, Dan McGee wrote: > >> On Sat, Aug 7, 2010 at 9:44 AM, Netanel Shine >> wrote: >> > Why Archlinux dont allow translation of the packages part in the site >> like >> > in the AUR? >> >> No one has stepped forward to make it happen, and the very few of us >> that work on the site don't see it as a priority. >> >> -Dan >> > > > > -- > Netanel Shine >
Re: [arch-general] Packages Translate.
On Sat, Aug 7, 2010 at 9:44 AM, Netanel Shine wrote: > Why Archlinux dont allow translation of the packages part in the site like > in the AUR? No one has stepped forward to make it happen, and the very few of us that work on the site don't see it as a priority. -Dan
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On Wed, Aug 4, 2010 at 6:56 AM, Thomas Bächler wrote: > Am 04.08.2010 13:28, schrieb Dan McGee: >> On Wed, Aug 4, 2010 at 6:26 AM, Ionuț Bîru wrote: >>> it was reported and we have a patch available >>> >>> http://bugs.archlinux.org/task/20353 >> >> Awesome, good to see. It might be a pain in the ass but this is going >> to get reported again and again if we don't 1) build 2.6.34.3 when it >> comes out, hopefully soon or 2) Rebuild 2.6.34.2 with this patch. >> Loosing networking really sucks the big one. > > I am already rebuilding both kernels. This screwup sucks a lot. > >> To Thomas: they are gong to have to given that this better end up in >> the next stable tree for that kernel. > > They should be careful what they merge in the future. The stable > releases should never introduce regressions. I completely agree. I appreciate your effort in doing this, it might go rather silently but it isn't unnoticed. -Dan
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On Wed, Aug 4, 2010 at 6:26 AM, Ionuț Bîru wrote: > On 08/04/2010 02:23 PM, Dan McGee wrote: >> >> On Wed, Aug 4, 2010 at 1:03 AM, Ionuț Bîru wrote: >>> >>> On 08/04/2010 05:34 AM, Dan McGee wrote: >>>> >>>> On Tue, Aug 3, 2010 at 9:24 PM, Dan McGee wrote: >>>>> >>>>> On Tue, Aug 3, 2010 at 2:39 AM, Tobias Powalowski >>>>> wrote: >>>>>> >>>>>> Latest kernel is in testing, >>>>>> please signoff for both arches. >>>>>> >>>>>> I already have >>>>>> .35 prepared, a fast signoff would be great. >>>>> >>>>> This completely broke wireless for me on my laptop. b43 driver, i686 >>>>> architecture. The wlan0 device would show up, but then you couldn't do >>>>> much of anything with it. >>>>> >>>>> 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev >>>>> 01) >>>>> Subsystem: Hewlett-Packard Company Device 365e >>>> >>>> Interesting, because the driver hasn't changed at all since the base >>>> 2.6.34 was released: >>>> >>>> dmc...@galway ~/projects/linux-2.6 (master) >>>> $ (find -name b43*) | xargs git diff v2.6.34..v2.6.34.2 | cat >>>> >>>> >>>> The diff on drivers/net/wireless didn't look odd either; specific >>>> (other) drivers changed but nothing that sticks out as affecting b43. >>>> >>>> -Dan >>> >>> it has ssb changes and b43 relies on it >> >> Thanks, Ionuț. So much for a stable release...I should probably let >> them know upstream, no? Is this something to send to linux-stable? >> >> -Dan > > > it was reported and we have a patch available > > http://bugs.archlinux.org/task/20353 Awesome, good to see. It might be a pain in the ass but this is going to get reported again and again if we don't 1) build 2.6.34.3 when it comes out, hopefully soon or 2) Rebuild 2.6.34.2 with this patch. Loosing networking really sucks the big one. To Thomas: they are gong to have to given that this better end up in the next stable tree for that kernel. -Dan
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On Wed, Aug 4, 2010 at 1:03 AM, Ionuț Bîru wrote: > On 08/04/2010 05:34 AM, Dan McGee wrote: >> >> On Tue, Aug 3, 2010 at 9:24 PM, Dan McGee wrote: >>> >>> On Tue, Aug 3, 2010 at 2:39 AM, Tobias Powalowski wrote: >>>> >>>> Latest kernel is in testing, >>>> please signoff for both arches. >>>> >>>> I already have >>>> .35 prepared, a fast signoff would be great. >>> >>> This completely broke wireless for me on my laptop. b43 driver, i686 >>> architecture. The wlan0 device would show up, but then you couldn't do >>> much of anything with it. >>> >>> 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev >>> 01) >>> Subsystem: Hewlett-Packard Company Device 365e >> >> Interesting, because the driver hasn't changed at all since the base >> 2.6.34 was released: >> >> dmc...@galway ~/projects/linux-2.6 (master) >> $ (find -name b43*) | xargs git diff v2.6.34..v2.6.34.2 | cat >> >> >> The diff on drivers/net/wireless didn't look odd either; specific >> (other) drivers changed but nothing that sticks out as affecting b43. >> >> -Dan > > it has ssb changes and b43 relies on it Thanks, Ionuț. So much for a stable release...I should probably let them know upstream, no? Is this something to send to linux-stable? -Dan
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On Tue, Aug 3, 2010 at 9:24 PM, Dan McGee wrote: > On Tue, Aug 3, 2010 at 2:39 AM, Tobias Powalowski wrote: >> Latest kernel is in testing, >> please signoff for both arches. >> >> I already have >> .35 prepared, a fast signoff would be great. > > This completely broke wireless for me on my laptop. b43 driver, i686 > architecture. The wlan0 device would show up, but then you couldn't do > much of anything with it. > > 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) > Subsystem: Hewlett-Packard Company Device 365e Interesting, because the driver hasn't changed at all since the base 2.6.34 was released: dmc...@galway ~/projects/linux-2.6 (master) $ (find -name b43*) | xargs git diff v2.6.34..v2.6.34.2 | cat The diff on drivers/net/wireless didn't look odd either; specific (other) drivers changed but nothing that sticks out as affecting b43. -Dan
Re: [arch-general] [signoff] kernel26 2.6.34.2-1
On Tue, Aug 3, 2010 at 2:39 AM, Tobias Powalowski wrote: > Latest kernel is in testing, > please signoff for both arches. > > I already have > .35 prepared, a fast signoff would be great. This completely broke wireless for me on my laptop. b43 driver, i686 architecture. The wlan0 device would show up, but then you couldn't do much of anything with it. 03:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01) Subsystem: Hewlett-Packard Company Device 365e -Dan
Re: [arch-general] makepkg patch - generate .SRCINFO file when running "--source"
On Mon, Aug 2, 2010 at 10:03 AM, vlad wrote: > On Mon, Aug 02, 2010 at 08:49:11AM -0400, Loui Chang wrote: >> On Tue 27 Jul 2010 15:25 +0200, vlad wrote: >> > Here is a patch against makepkg from git which introduces a new function >> > "write_srcinfo()". This generates a file .SRCINFO - like the .PKGINFO >> > one - when "makepkg --source" is run and then it is added to the src.tar.gz >> > archive. >> > I think having such a file is an important step for getting split >> > packages to the AUR. It is also useful for third party applications. >> > Since this file is generated during making the source archive, there >> > is no need for parsing/sourcing the PKGBUILD everytime meta infos are >> > needed afterwards. >> > This is also a way of standardizing the source archive. >> > >> > .SRCINFO looks like (generated for gcc from core): >> >> Nice. :D This is something that I had been brainstorming too. > Hehe, that's why I did it. I wanted to give this a push. >> You should submit it to the pacman-dev list and/or the pacman bug >> tracker. > Is pacman-dev public or open for non-devs? Public, but you have to sign up. -Dan
Re: [arch-general] Better NILFS2 Support
On Sun, Aug 1, 2010 at 10:30 AM, Tobias Powalowski wrote: > Am Sonntag 01 August 2010 schrieb Dieter Plaetinck: >> On Sun, 1 Aug 2010 > 16:46:33 +0200 >> >> Heiko Baums wrote: >> > I don't > think that nilfs-utils should be moved to the base group. I >> > agree with > moving it to [core] but not to base, because base is >> > assumed to be > installed on every computer and packages in the base >> > group are usually > not listed in the depends array of a PKGBUILD. >> > >> > On the contrary I > think there could be some other file system tools >> > like jfsutils, lvm2 > and xfsprogs be removed from the base group (not >> > from [core]). >> >> I > think this explanation makes sense. I just found this back: >> > http://wiki.archlinux.org/index.php/User:Allan/Base_Cleanup >> So indeed, it > seems like the goal is to remove all non-essential things >> (reiserfs, xfs, > ..) from base. >> >> > They probably should be automatically installed if a > partition is >> > formatted with one of these filesystems by AIF. But usually > people who >> > are using these filesystems know what they are doing and know > that >> > they have to select these packages for installation. >> >> Actually > it's fairly trivial to "preselect" those packagas based on the >> filesystems > used during the filesystem step. I believe some of it is >> already > implemented in aif. >> >> Dieter > My 2 cents about nilfs, > I have added it to > archboot environment some time ago. > To integrate it into an installer it is > plain not usable, because the kernel doesn't know it. > All usual filesystem > utilities like blkid etc. don't recognize it. > Sure it will be an optional > filesystem in the future, but it should be supported by the kernel and major > filesystem and core utiltities in a sane way. Except that I've seen it running on his root partition on a booting laptop without any of these problems you speak of... -Dan
Re: [arch-general] pacman segfault problem
On Sun, Aug 1, 2010 at 11:14 AM, b1 wrote: > On Sat, 2010-07-31 at 11:06 -0700, b1 wrote: >> On Sat, 2010-07-31 at 01:50 +0200, Sven-Hendrik Haase wrote: >> > On 30.07.2010 22:27, b1 wrote: >> > > ~~ >> > > Any help is greatly appreciated. >> > > >> > > Thanks >> > > >> > > Benedikt >> > > >> > > >> > >> > Use the Arch install medium and its working pacman and set the install >> > dir to your system. Assume your pacman database is corrupt as well so >> > discard it. Reinstall at least base and base-devel into your mounted >> > system from the live medium and copy the resulting db. This will only >> > make pacman recognize packages contained in base and base-devel when >> > you're booting back into your system but at least pacman will be working >> > again. >> > >> > -- Sven-Hendrik >> >> Hello Sven >> >> Thanks for your reply. I did what you suggested. I bootet the Arch linux >> live cd, removed the old databse, installed base and base-devel, copied >> the resulting db and rebooting. After readding users, adapting rc.conf >> and another reboot, I was able to log in. >> Now pacman -Syu works without errors (However has nothing to update at >> the moment, so I cant really tell). >> >> However I also saved a complete list of packages before doing the >> live-cd thing, in order to restore them now. Unfortunatelly I once again >> ran into the problem. Many packages work just fine, however a >> >> pacman -S pulseaudio >> >> segfaults again, with the already known error message. Therefore I >> assumed it had something to do with my package cache. I did a >> >> pacman -Scc >> >> However no success. Still getting the segfault. Is there any other place >> pacman keeps information about packages like pulseaudio? Any ideas what >> I could do? >> >> Anyone having any idea, what the problem might be? Again every hint is >> very appreciated. >> >> Thanks >> >> Benedikt >> >> > > Ok, I nearly managed to restore all packages, however the following > packages cause the segfault: > > gstreamer0.10-pulse > lib32-pulseaudio > libquicktime > pavucontrol > pavumeter > pulseaudio > ttf-liberation > > Interestingly the installation via pacman -fU URL succeeds and with > pacman -fS PACKAGE fails. > > Is there some debugging version of pacman? For use with gdb to track > down the problem. Or do I have to compile it from source and if so, what > flags do I have to set? Compiling it from source is the easiest way. For flags, I'd use the PKGBUILD as an example of what you should pass to configure. Once built you can run it from the source tree (./src/pacman/pacman). -Dan
Re: [arch-general] Mailman update
On Wednesday, July 21, 2010, Ananda Samaddar wrote: > On Wed, 21 Jul 2010 23:38:37 +0200 > Dan Vratil wrote: > >> Hi, >> please, could someone update the mailman package? It's outdated quite >> a long (at least since February 2009) and there is a new version >> 2.1.13 from December 2009. >> >> Thank you! >> >> Dan >> >> > > Flag it as out of date. More importantly, try bumping the version and building and *running* the new version yourself. That way you can tell the maintainers things work great and they are relieved of some of the burden of testing a very unweildy to package package. -Dan
Re: [arch-general] Archweb package update script
On Wed, Jul 21, 2010 at 10:33 AM, Netanel Shine wrote: > Hey again, > thanks but i got this error: > > Unknown command: 'reporead' > > Type 'manage.py help' for usage. No, it means you are doing something wrong. The app itself contains this command. You're going to have to do some digging yourself to figure out why it wasn't working. -Dan
[arch-general] Archweb package update script
On Wed, Jul 21, 2010 at 5:45 AM, Netanel Shine wrote:
>>
>> Date: Sun, 18 Jul 2010 21:36:42 -0500
>> From: Dan McGee
>> Subject: Re: [arch-general] RSS feed - missing feature|problem
>> On Mon, Jul 12, 2010 at 3:59 AM, Netanel Shine
>> wrote:
>> > Hey all,
>> >
>> > My name is Netanel Shine, and a few days ago i began the process of
>> building
>> > an israeli community of archlinux. I used a git clone to set up the main
>> > site. (like some other great projects file that archlinux git have to
>> offer
>> > like the wiki and the forums)
>> > Everything went smoothly and just works great, except for one problem -
>> the
>> > package rss feeds.
>> >
>> > The site address is: http://archlinux.org.il - under heavy development.
>> >
>> > The problem: As you all can see, the left rss box with the latest updates
>> > dont work and the list is empty. - because the system comes with an
>> > integrated "packages" part (you can see it here:
>> > http://archlinux.org.il/packages - not gonna use it), so the rss list
>> > updates from here (i guess)
>> >
>> > After discussions with some great people (in the irc) we concluded that
>> the
>> > rss box pull`s the data from the 'models.Package' object - that connected
>> to
>> > archlinux mainsite DB (Package.objects=PackageManager()), so if i dont
>> have
>> > any access for the database - thats not gonna work.
>> >
>> > All sorts of ideas were came up like bulding a script that will do the
>> job
>> > or, a an iframe that will copy the box from the mainsite (but the problem
>> it
>> > will not be in hebrew) and an idea to replace the table that has for
>> update
>> > in pkg_updates. (with logic that pulls from the feed) - but thats not
>> easy
>> > because the logic is a wrapped up in django MVC.
>> >
>> > So dear friends, i turn to you for help - and I`m sure I would find it.
>>
>> Check out the reporead command baked into manage.py- you can very
>> easily populate the package DB yourself.
>>
>> I have a small script I can send you for this, but I don't have it
>> handy at the moment. Let me know if that would be useful to you.
>>
>> -Dan
>
> First of all, I sorry for seeing this message just now.
> Thanks Dan, I appreciate your comment, and i would like to have the script
> you're talking about , please send him to: netanelshine at gmail dot com ;)
Something like the following:
$ cat projects/archweb/fetch_update_package_db.sh
#!/bin/bash -e
# run at nice 3. it can churn quite a bit of cpu after all.
renice +3 -p $$ > /dev/null
# setup paths
DLURL="ftp://ftp.archlinux.org";
SPATH="/path/to/archweb"
SCRIPT="${SPATH}/scripts/reporead.py"
TMPPATH="/tmp/updaterepos"
ARCHES="i686 x86_64"
REPOS="core extra testing community community-testing"
startdir="$(pwd)"
[ ! -d ${TMPPATH} ] && mkdir ${TMPPATH}
for arch in ${ARCHES}; do
[ ! -d ${TMPPATH}/${arch} ] && mkdir ${TMPPATH}/${arch}
for repo in ${REPOS}; do
#[ ! -d ${TMPPATH}/${repo} ] && mkdir ${TMPPATH}/${repo}
#cd ${TMPPATH}/${repo}
echo "Updating ${repo}-${arch}"
cd $TMPPATH/${arch}
wget -N ${DLURL}/${repo}/os/${arch}/${repo}.db.tar.gz
#${SCRIPT} ${arch} ${TMPPATH}/${arch}/${repo}.db.tar.gz
cd "$startdir"
./manage.py reporead ${arch} ${TMPPATH}/${arch}/${repo}.db.tar.gz
echo ""
done
done
Re: [arch-general] RSS feed - missing feature|problem
On Mon, Jul 12, 2010 at 3:59 AM, Netanel Shine wrote: > Hey all, > > My name is Netanel Shine, and a few days ago i began the process of building > an israeli community of archlinux. I used a git clone to set up the main > site. (like some other great projects file that archlinux git have to offer > like the wiki and the forums) > Everything went smoothly and just works great, except for one problem - the > package rss feeds. > > The site address is: http://archlinux.org.il - under heavy development. > > The problem: As you all can see, the left rss box with the latest updates > dont work and the list is empty. - because the system comes with an > integrated "packages" part (you can see it here: > http://archlinux.org.il/packages - not gonna use it), so the rss list > updates from here (i guess) > > After discussions with some great people (in the irc) we concluded that the > rss box pull`s the data from the 'models.Package' object - that connected to > archlinux mainsite DB (Package.objects=PackageManager()), so if i dont have > any access for the database - thats not gonna work. > > All sorts of ideas were came up like bulding a script that will do the job > or, a an iframe that will copy the box from the mainsite (but the problem it > will not be in hebrew) and an idea to replace the table that has for update > in pkg_updates. (with logic that pulls from the feed) - but thats not easy > because the logic is a wrapped up in django MVC. > > So dear friends, i turn to you for help - and I`m sure I would find it. Check out the reporead command baked into manage.py- you can very easily populate the package DB yourself. I have a small script I can send you for this, but I don't have it handy at the moment. Let me know if that would be useful to you. -Dan
Re: [arch-general] Why does pacman 3.4 reacts so slow to SIGINT?
2010/7/8 Lukas Grässlin : > Hi there, > > since the update from pacman 3.3 to 3.4 it reacts really slow to a > SIGINT (Ctrl+C) while syncing or installing a packet. > With 3.3 it immediately stops. > > Not a hugh problem, but I would know why it is so. I don't think we changed our signal handler at all in 3.4. I haven't noticed any difference while syncing, and you probably won't find me hitting Ctrl-C during package installation that often. -Dan
Re: [arch-general] [PATCH 01/48] Bashification of initscripts
On Tue, Jul 6, 2010 at 11:03 PM, Allan McRae wrote: > Here is a quick review on all these patches. I recommend that the lvm and > crypttab changes get a decent amount of testing before these go live as they > are the biggest changes being done. > > Why has this been removed: > -if [ -x /etc/rc.local.shutdown ]; then > - /etc/rc.local.shutdown > -fi > Ah... it has been moved to another place in another commit. Please > document these sorts of changes in your commit message and preferably do the > entire move in one commit. If there was one thing I wasn't so fond of in these patches, it seemed like there were too many. The beauty of git is the ability to go back and squash and split patches in a way that makes a lot more sense to others- it might not have been the way or order you did things in, but you should try as hard as possible to make a commit the largest logical unit that makes sense, but still small enough to grasp fully. If there are ever closely-related changes strewn across multiple patches in a patch set, you should probably think about merging those commits. -Dan
Re: [arch-general] mercurial in Extra out of date
On Tue, Jul 6, 2010 at 10:33 PM, PT M. wrote: > It's been a week since mercurial 1.6 released, extra/mercurial 1.5.4-1 is > still in the repository. OMG! Raise the alarm!!! You do realize none of us are full-time around here, right? The maintainer will get to it when he can. Until then, learn to use ABS. -Dan
Re: [arch-general] Licensing of Arch Wiki content
On Tue, Jun 29, 2010 at 5:09 PM, Ananda Samaddar wrote: > On Thu, 17 Jun 2010 23:19:09 +0200 > Linas wrote: > >> I assume this ask to have GFDL & CC-BY-SA content coexist at the >> wiki. The existing content can only be relicensed by its authors. The >> GFDL 1.3 gateway >> expired on August 1, 2009. >> > > I really need an answer on this as soon as possible. For new Wiki > articles would it be OK to add a footer in the article stating that it > is licensed under a CC license and not the GFDL? Any official word on > this please from the Arch wiki admins or developers. If you're not > willing to officially allow CC licenses could the 'override' paragraph > I'm suggesting for new content only be all right? I honestly don't know who is going to reply to you. If you were to just change the license I also don't think you'd have anyone come after you anytime soon. Who is in charge of the wiki these days I'm not sure, but I'd try to get someone's attention besides mine- maybe Pierre or Aaron would be the right guys. -Dan
Re: [arch-general] Bashification of initscripts for moderate speedup
On Tue, Jun 29, 2010 at 8:20 AM, Victor Lowther wrote: > On Jun 29, 2010, at 5:55 AM, solsTiCe d'Hiver > wrote: > >> Le lundi 28 juin 2010 à 17:55 +0200, Lukáš Jirkovský a écrit : >>> >>> Actually I see the point of doing this. Arch is a modern distribution >>> with the newest software around so why stuck with shell constructs >>> which are probably dozens of years old? >>> >>> Lukas >> >> Yes. I definitely agree. We have to pray that a dev is interested in the >> patch now ;-) > > Thomas seemed moderatly interested. > >> @Victor: >> You last commit that is supposed to fix whitespace mess in fact create a >> mess with whitespace. Also it changes all the modelines for vim: >> for example from >> # vim: set ft=sh sw=2 ts=2 et: >> to >> # vim: set ft=sh sw=4 ts=4 et: > > When it comes to whitespace, I do whatever indent-region and > whitespace-cleanup tell me to. Which is change the modelines? No thanks. http://wiki.archlinux.org/index.php/DeveloperWiki:Bash_Coding_Style -Dan
Re: [arch-general] Bashification of initscripts for moderate speedup
On Mon, Jun 28, 2010 at 7:42 AM, Caleb Cushing wrote: > On Sun, Jun 27, 2010 at 11:10 PM, Victor Lowther > wrote: >> Questions, comments, flames, etc. welcome. > > why go this way instead of the other? (clarification why go deeper > into bash instead of trying to posix-ify the scripts) Because we are never going to eliminate arrays from rc.conf. -Dan
Re: [arch-general] makepkg creates symlink to the package file
On Tue, Jun 22, 2010 at 10:48 PM, Allan McRae wrote: > On 23/06/10 10:47, Ng Oon-Ee wrote: >> >> On Wed, Jun 23, 2010 at 7:31 AM, Allan McRae wrote: >>> >>> On 23/06/10 07:01, Attila wrote: Hello together, since the new pacman a makepkg run creates a symlink to the package file in the directory of the PKGBUILD. Example: # ls -l *.gz opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz -> /server/work/archlinux/repo/opera-snapshot-10.60-6378.2ah-i686.pkg.tar.gz My differences to makepkg.conf.pacnew be this: MAKEFLAGS="-j2" CFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="-march=i686 -mtune=generic -O2 -pipe -fomit-frame-pointer" BUILDENV=(fakeroot !distcc !color !ccache) OPTIONS=(strip !docs libtool emptydirs zipman purge) PKGDEST=/server/work/archlinux/repo PACKAGER="Attila" PKGEXT='.pkg.tar.gz' [/server/work is a cifs mount point] Have i overseen something in the makepkg.conf to control this or does no one have this problem ... or is this a new feature which have to be so? >>> >>> New feature. If PKGDEST is set, it creates a symbolic link to the >>> packages >>> in the working directory. I think the idea was that most of the time you >>> will want to "pacman -U" at the end of the build and that save you >>> typing the whole PKGDEST path. >>> >>> Allan >> >> Wouldn't those who want to do that do a makepkg -i? The thing about >> leaving a symbolic link is that the next time you do pacman -Sc its >> still there. Scripting removal of dead links is dead simple though, so >> not a problem for me. >> > > Possibly... I do not use "makepkg -i" as I use "makepkg -sr" so it removed > the makedepends that will be unneeded in the future. Using "makepkg -c" > clean up the dangling symlinks. It is also a very helpful symlink for those of us that like to run namcap after building to check the package. -Dan
Re: [arch-general] Important notice on the Arch Security Team to the whole Arch Linux community.
On Mon, Jun 21, 2010 at 10:27 PM, C Anthony Risinger wrote: > On Mon, Jun 21, 2010 at 10:16 PM, Allan McRae wrote: >> On 22/06/10 12:07, C Anthony Risinger wrote: >>> >>> my point of this ramble if there is one, is that personally, i don't >>> want _anyone_ other than upstream to make security decisions regarding >>> their software.if Arch started naively backporting stuff based of >> >>> the latest alert from XYZ, i wouldn't be sticking around to long. >>> even if an security hole is found i _don't_ want the fix to be >>> included by default, unless it came from upstream in the form of a new >>> release, which Arch would just pick up as usual. >> >> >> Then you should probably move along... >> >>> find /var/abs -name *CVE* >> /var/abs/extra/libmikmod/libmikmod-CVE-2009-0179.patch >> /var/abs/extra/xmms/xmms-1.2.11-CVE-2007-0653.0654.patch >> /var/abs/extra/alpine/CVE-2008-5514.patch >> /var/abs/extra/libtiff/libtiff-CVE-2009-2285.patch >> /var/abs/extra/libtiff/tiff-3.9.0-CVE-2009-2347.patch >> /var/abs/extra/id3lib/id3lib-3.8.3-CVE-2007-4460.patch >> /var/abs/core/expat/CVE-2009-3720.patch >> /var/abs/core/expat/CVE-2009-3560.patch >> >> and these are just the patches named for the security issue they fix. >> >> The point is that the developers around here already patch for security >> issues. The only change that I think that a security team will achieve is >> to notify me (as a developer) of issues that I have overlooked on the >> upstream mailing lists and file a bug report. It is a bonus if the issue is >> pre-analyzed for me and all relevant links supplied so I can assess it >> quickly myself and release a fixed package if I deem that being suitable. > > indeed. 2007/8/9? are these patches from years ago, for dead > software (xmms?)? i don't know the state of the others. > > alright, so you're patching stuff... why? why are such old patches > not in upstream? if things were done appropriately there wouldn't be > a need for intermediary patches because glaring security holes are > quickly absorbed into upstream. or... whats the deal here? i don't > get the need to carry these around. > > at any rate i don't agree with it but meh, i'm just a worker bee :-) Do you honestly think releasing software is that easy? It *sucks*. It is the least enjoyable part of being an open-source developer. They probably are in upstream and they haven't done a release for some very good raeson, or upstream is no longer well-maintained. Does that mean we should leave people vulnerable because of some party line we have? Heck no. -Dan
Re: [arch-general] New Arch Install - Swap Won't Activate - Help the clueless?
On Mon, Jun 21, 2010 at 11:33 AM, David C. Rankin wrote: > Guys, > > I'm laughing at myself for being unable to get swap activated. > Initially, when > I breezed through the install, I forgot to set /dev/sdb6 to type 82 so the box > came up with swap off (2G of ram so not much of an issue) > > But now, I want to activate it and I get an error activating swap that > frankly, > I have never seen before: > > [11:27 dcrgx2:~] # swapon -a > swapon: /dev/sdb6: read swap header failed: Invalid argument > > Huh? man mkswap
Re: [arch-general] [signoff] kernel26 2.6.34-2
On Sun, Jun 20, 2010 at 5:42 AM, Pierre Schmitz wrote:
> On Sat, 19 Jun 2010 14:03:01 +0200, Thomas Bächler
> wrote:
>> This release will be moved to core after signoff, together with
>> linux-firmware, initscripts, udev and mkinitcpio. Changes compared to
> -1:
>>
>> Remove kernel26-firmware package, it is replaced by linux-firmware
>> added new tcp options FS#19604 (tpowa)
>> Enable devtmpfs
>> Add makedepends to build kernel26-{manpages,docs} properly
>> Fix makepkg -R
>>
>> Please sign off.
>
> signed-off x86_64
Signoff i686.
-Dan
Re: [arch-general] New Google Group for discussion and notices on Arch security.
On Thu, Jun 17, 2010 at 1:32 PM, Ananda Samaddar wrote: > I've created a Google Group here for discussion around creating an Arch > Security Team: > > http://groups.google.com/group/arch-security > > Please join it if you're interested. The reason for this group is in > response to my rejected suggestion for an arch-security mailing list. > I'll CC any policy or process suggestions to arch-general, but when > announcements happen and also discussion regarding specific > vulnerabilities and mitigation they won't be CCed. > > If an Arch Security Team comes coalesces and the Devs are happy to > integrate us officially then we can consider deleting the group and if > possible transferring the archives to archlinux.org. Sounds like a blast from the past: http://wiki.archlinux.org/index.php/Security_Task_Force http://code.google.com/p/arch-sheriff/ Best of luck this time around. -Dan
Re: [arch-general] [arch-dev-public] [signoff] pacman 3.4.0-1
On Wed, Jun 16, 2010 at 10:16 PM, Andres P wrote: > On Wed, Jun 16, 2010 at 10:04 PM, Dan McGee wrote: >> Upstream release, please signoff. > > Small detail, > > Optional Deps : fakeroot: for makepkg usage as normal user > python: for rankmirrors script usage Noted, thanks. I'll update this on SVN trunk since we are missing manpages too and will at least need a -2. -Dan
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
On Wed, Jun 16, 2010 at 6:35 PM, Dimitrios Apostolou wrote: > On Wed, 16 Jun 2010, Dan McGee wrote: >> >> On Wed, Jun 16, 2010 at 6:08 PM, Dimitrios Apostolou >> wrote: >>> >>> Hey, what do you think about this way of verifying packages? >>> >>> On Tue, 15 Jun 2010, Dimitrios Apostolou wrote: >>>> >>>> On another note, an easy but maybe a bit costly way to avoid any MITM >>>> tampering to packages, is serve *.md5 files for every package through a >>>> trusted HTTPS host. Then everyone can query that single host and check >>>> if >>>> the package he got from a mirror is safe. >>>> >>>> Costs: A little more traffic by serving hash files to everyone plus the >>>> cost of the certificate from a CA. Is the income Arch receives from ads >>>> and >>>> schwag enough for such a simple solution? >>> >>> Let me explain it a bit more: >>> >>> Pacman downloads package-1.tar.xz from a random mirror. >>> It then fetches: >>> >>> https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1 >>> >>> Pacman should then know whether the connection to sums.archlinux.org was >>> tampered, since the certificate is signed from a CA in ca-bundle.crt. So >>> if >>> the two hashes match, the package is safe (as safe as the archlinux >>> server...) >>> >>> That way any type of file can be verified (packages, db files, PKGBUILDs, >>> patches etc) provided that its cryptographic hash is in that HTTPS host. >>> Obviously to be able to verify db files, they need a timestamp appended >>> to >>> them, e.g. core-MMDDHHMM.tar.gz. That necessary change is perhaps the >>> most difficult part of this proposal. >>> >>> If too many small files is a problem, maybe the whole db.tar.gz can be >>> served (at the cost of a higher bandwidth utilisation). >>> >>> >>> This solution doesn't use package signing nor a web-of-trust. It simply >>> piggybacks on the tried and true HTTPS mechanism. Primary advantage is >>> the >>> lack of complexity which makes it easy to understand and implement. >>> >>> >>> What do you think? >> >> I think that someone could blow this apart. I break in, touch a >> package of my choosing without telling anyone, and update the checksum >> file. Bam- everyone's systems are fucked and the developers never knew >> because you didn't do anything both cryptographically secure and >> verifiable, you just added some indirection to the process. > > HTTPS is both cryptographically correct and verifiable. The case you mention > is if someone breaks the one end, that must be guarded most. The danger is > there everywhere, on the web-of-trust case someone that broke into a dev's > machine and got the key, can sign anything he wants and serve it to the > user, who would know? On the distro-wide key case, it's like someone > stealing that key, and be able to serve/sign everything. > > Here, we don't have a key to keep safe, but a server. So it needs special > attention about who has access and how hashes are submitted (although HTTPS > can secure this process too). But I admit that keeping a server safe is a > bit harder than keys, if that was your point. Yes, I probably should have clarified more. With individual package signing, if a developer's key is cracked, then *only* those packages have to be discarded, not our entire repository. With the above scheme, once you have had a break-in and are unable to know exactly what happened, the entire repository is suspect. Our verifiable server SSL cert means nothing if someone gains access to the machine. The whole idea of there being some universal but well-guarded key is a joke, in my opinion- I definitely do not think that is the right way to approach any signing outside of maybe at the DB level. At the package level, and the way we currently build things, I don't think that makes any sense. -Dan
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
On Wed, Jun 16, 2010 at 6:08 PM, Dimitrios Apostolou wrote: > Hey, what do you think about this way of verifying packages? > > On Tue, 15 Jun 2010, Dimitrios Apostolou wrote: >> >> On another note, an easy but maybe a bit costly way to avoid any MITM >> tampering to packages, is serve *.md5 files for every package through a >> trusted HTTPS host. Then everyone can query that single host and check if >> the package he got from a mirror is safe. >> >> Costs: A little more traffic by serving hash files to everyone plus the >> cost of the certificate from a CA. Is the income Arch receives from ads and >> schwag enough for such a simple solution? > > Let me explain it a bit more: > > Pacman downloads package-1.tar.xz from a random mirror. > It then fetches: > > https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1 > > Pacman should then know whether the connection to sums.archlinux.org was > tampered, since the certificate is signed from a CA in ca-bundle.crt. So if > the two hashes match, the package is safe (as safe as the archlinux > server...) > > That way any type of file can be verified (packages, db files, PKGBUILDs, > patches etc) provided that its cryptographic hash is in that HTTPS host. > Obviously to be able to verify db files, they need a timestamp appended to > them, e.g. core-MMDDHHMM.tar.gz. That necessary change is perhaps the > most difficult part of this proposal. > > If too many small files is a problem, maybe the whole db.tar.gz can be > served (at the cost of a higher bandwidth utilisation). > > > This solution doesn't use package signing nor a web-of-trust. It simply > piggybacks on the tried and true HTTPS mechanism. Primary advantage is the > lack of complexity which makes it easy to understand and implement. > > > What do you think? I think that someone could blow this apart. I break in, touch a package of my choosing without telling anyone, and update the checksum file. Bam- everyone's systems are fucked and the developers never knew because you didn't do anything both cryptographically secure and verifiable, you just added some indirection to the process. -Dan
Re: [arch-general] Package signing for the umpteenth time (was Re: unrealircd 3.2.8.1-2 contains backdoor)
On Tue, Jun 15, 2010 at 8:58 AM, Guillaume ALAUX wrote: >>How exactly is core and extra database populated? >> Moreover, instead of building all packages in the private PCs of > developers > Packages are not build on developers computers but on build machines as > explained here http://wiki.archlinux.org/index.php/Pacbuild Pacbuild hasn't been touched for years... -Dan
Re: [arch-general] [arch-dev-public] [RFC] Initialize /etc/mtab by copying /proc/mounts
On Wed, Jun 9, 2010 at 3:58 AM, Rogutės Sparnuotos wrote: > Thomas Bächler (2010-06-09 09:47): >> Am 09.06.2010 03:40, schrieb Dan McGee: >> > On Tue, Jun 8, 2010 at 5:48 PM, Thomas Bächler >> > wrote: >> >> Our current process of initializing /etc/mtab is >> >> hackish and probably error-prone, replace it by >> >> simply copying /proc/mounts. >> >> --- >> > >> > Looks good to me (but untested). This goes way back to the roots of Arch, >> > wow. >> >> The only weirdness that I found is that "rootfs" is now shown as a mount: >> rootfs / rootfs rw 0 0 >> >> Technically this is correct, but some tools might become confused. >> Another way would be to grep -v ^rootfs from /proc/mounts when creating >> mtab. I am entirely unsure what the "right way" is here. > > Not that I know the right way, but am running Arch with /etc/mtab copied > (or symlinked, on another system) from /proc/mounts for more than a year > now, without any problems. Almost all embedded distros do this as well; rootfs is there in my OpenWRT install because mtab is just a symlink. I would hope most tools can cope with this guy. -Dan
Re: [arch-general] [arch-dev-public] Namcap release coming soon
On Tue, Jun 8, 2010 at 10:15 AM, Guillaume ALAUX wrote: > On 8 June 2010 16:58, Dan McGee wrote: > >> On Tue, Jun 8, 2010 at 9:56 AM, Dan McGee wrote: >> > Forwarding to the public list is your best option; going to one >> > developer is a good way for your email to get lost. >> > >> > -- Forwarded message -- >> > From: Guillaume ALAUX >> > Date: Tue, Jun 8, 2010 at 9:54 AM >> > Subject: Re: [arch-dev-public] Namcap release coming soon >> > To: dpmc...@gmail.com >> > >> > >> > Hi Dan, >> > Didn't really how to answer your mail as I don't have write access to >> > the list so I'm just answering directly to you: >> >> If anyone [...] knows of very small issues that need fixing ... >> > When namcap'ing a package including scripts that use '#!/bin/sh' >> > instead of '#!/bin/bash', output is something like the following: >> > pkgname E: Dependency detected and not included (sh) from files >> ['script.sh'] >> > (I know the AL standard page on the wiki says we should use bash >> > rather than sh but these are scripts included in the original >> > tarball.) >> > As we don't have any sh package that error sounds strange to me (I >> > have this "issue" on one of my packages in AUR) >> > Should we change these scripts so that they use bash instead of sh or >> > should we change namcap in order for it not to yield such error? >> >> Namcap needs to be fixed to recognize provides. The bash package >> currently provides sh, so there should be no error here. >> >> -Dan >> > > Well even though bash provides sh (as a link), namcap says "Dependency > detected and not included (sh) from files" > > See the comments on one of my AUR package: > http://aur.archlinux.org/packages.php?ID=37110 Yes, I understand this. We don't care at all about links or anything in the filesystem; we are simply looking for an 'sh' package that doesn't exist. Until namcap can do reverse provides matching (e.g. look for a package that provides 'sh'), then this won't work. Of course, you can always just make your package depend on 'sh'. The depends module is extensive and has a lot to it, so this is not going to be a quick/easy change. -Dan
Re: [arch-general] [arch-dev-public] Namcap release coming soon
On Tue, Jun 8, 2010 at 9:56 AM, Dan McGee wrote: > Forwarding to the public list is your best option; going to one > developer is a good way for your email to get lost. > > -- Forwarded message -- > From: Guillaume ALAUX > Date: Tue, Jun 8, 2010 at 9:54 AM > Subject: Re: [arch-dev-public] Namcap release coming soon > To: dpmc...@gmail.com > > > Hi Dan, > Didn't really how to answer your mail as I don't have write access to > the list so I'm just answering directly to you: >> If anyone [...] knows of very small issues that need fixing ... > When namcap'ing a package including scripts that use '#!/bin/sh' > instead of '#!/bin/bash', output is something like the following: > pkgname E: Dependency detected and not included (sh) from files ['script.sh'] > (I know the AL standard page on the wiki says we should use bash > rather than sh but these are scripts included in the original > tarball.) > As we don't have any sh package that error sounds strange to me (I > have this "issue" on one of my packages in AUR) > Should we change these scripts so that they use bash instead of sh or > should we change namcap in order for it not to yield such error? Namcap needs to be fixed to recognize provides. The bash package currently provides sh, so there should be no error here. -Dan
[arch-general] Fwd: [arch-dev-public] Namcap release coming soon
Forwarding to the public list is your best option; going to one developer is a good way for your email to get lost. -- Forwarded message -- From: Guillaume ALAUX Date: Tue, Jun 8, 2010 at 9:54 AM Subject: Re: [arch-dev-public] Namcap release coming soon To: dpmc...@gmail.com Hi Dan, Didn't really how to answer your mail as I don't have write access to the list so I'm just answering directly to you: > If anyone [...] knows of very small issues that need fixing ... When namcap'ing a package including scripts that use '#!/bin/sh' instead of '#!/bin/bash', output is something like the following: pkgname E: Dependency detected and not included (sh) from files ['script.sh'] (I know the AL standard page on the wiki says we should use bash rather than sh but these are scripts included in the original tarball.) As we don't have any sh package that error sounds strange to me (I have this "issue" on one of my packages in AUR) Should we change these scripts so that they use bash instead of sh or should we change namcap in order for it not to yield such error? Thanks, Guillaume ALAUX On 8 June 2010 16:24, Dan McGee wrote: > > Hey guys, > > Allan and I have made a few patches to namcap in the last 24 hours and > we think it would be good to get a release out there. Here is the log: > http://projects.archlinux.org/namcap.git/log/ > > If anyone has any pending patches (doubtful) or knows of very small > issues that need fixing and won't take a lot of dev time, bring them > up now if we want to sneak them into the release. > > -Dan
Re: [arch-general] [arch-dev-public] [signoff] pkg-config-0.24-1
On Thu, May 27, 2010 at 8:49 AM, Ray Kohler wrote:
> On Thu, May 27, 2010 at 9:42 AM, Allan McRae wrote:
>> Upstream update. Renamved from pkgconfig to pkg-config as has been done
>> upstream for some time now.
>
> This looks funny to me:
>
> $ pacman -Qi pkg-config | grep '^Provides'
> Provides : pkgconfig=${pkgver}
>
> Isn't it supposed to be expanded?
Allan broke it! :)
-Dan
Re: [arch-general] A question about Arch Sixty Four
On Mon, May 24, 2010 at 8:13 PM, Gary Wright wrote: > 2010/5/24 Frédéric Perrin : > >> On a 64 bit machine, in « char *p; », p will use 64 bits (8 bytes), >> instead of 4 bytes in a 32 bits machine [I'm talking about p, not about >> *p which doesn't look like it exists]. Gary Wright seems to be saying >> that the impact is negligible. Nicky726 seems to be saying that there >> is a difference of up to 80%. I am surprised by such a claim, but there >> seems to be anecdotes on Google of people seeing the same thing. As I >> don't have a 64 bits machine, I can't test for myself. >> -- >> Fred > > Well, heres something vaguely empirical. Just downloaded the two > latest netinstall medias and threw them on a usb stick. I ran > precisely four commands after logging in as root on each netinstall > arch: > > 1) mkdir /mnt/tmp > 2) mount /dev/sda3 /mnt/tmp #my home partition > 3) uname -a >> /mnt/tmp/gary/memcomp > 4) free -m >> /mnt/tmp/gary/memcomp > > results to be seen here: > http://aur.pastebin.com/YwTJA6cR > > short story: ~29 MB more used on x86_64... or about 30 percent. > > But when installing a whole system, many more variables come into > play. It might have just been my dumb luck that ram usage ended up > within 1-2 mb of eachother. 47 MB - 21 MB (for a difference of 26 MB) is what you want to be looking at and nothing else. Throw buffers and cache out the window. Of course, that now skews the percentage a lot higher than what you stated to (47 - 21) / 21 = 123%. I'm not buying those numbers though as you didn't capture near enough information and not all that much was running. More useful are probably things like pmap comparison of the same binaries, etc. after doing as close to identical operations. I'm not sure even that would help, see the following pastebin to see those deceiving results: http://aur.pastebin.com/GzjTZYMe -Dan
Re: [arch-general] Why is there no tftp client in inetutils?
On Thu, May 20, 2010 at 12:57 PM, Karol Babioch wrote: > Hi, > > as I need a tftp client in order to reflash my WRT54GL I realised that Arch > Linux hasn't got one in the main repositories. Normally "tftp" is part of > Inetutils (http://www.gnu.org/software/inetutils/). Looking at the PKGBUILD of > "inetutils" confuses me, as it explicitly disables tftp. > > I know that I can easily rebuild the package, but I'm wondering why it is > disabled by default? At least you should provide a seperate tftp package, as > there are certainly people who need a tftp client, for instance me ;). tftp-hpa in [extra]
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
On Wed, May 19, 2010 at 6:10 AM, Thomas Bächler wrote: > Am 19.05.2010 10:56, schrieb Evangelos Foutras: >> Also did a diff [1] between the file lists of kernel26-firmware-2.6.34-1 >> and linux-firmware-git-20100519-1. It shows that ralink firmware has >> indeed been added to the linux-firmware repository, which should resolve >> FS#19519 [2]. > > I did that too and noticed the same. It would also replace all intel > ucode packages, and some more I don't know about. However, it is > considerably bigger than kernel26-firmware (2MB vs. 12MB). How often does it need to be updated? We now (needlessly?) have the firmware package track the actual kernel package so it ends up getting re-downloaded a lot more often than probably necessary, so the above package, while large, would probably be updated less anyway (and would be an 'any' package?). -Dan
Re: [arch-general] starting network:fail[eth0 wasn't connected] How to enable without reboot?
On Tue, May 18, 2010 at 1:45 PM, Joe(theWordy)Philbrook wrote: > > Currently my pc is a laptop. I don't use a wireless interface. I > connect to the Internet via cable broadband with a wired Ethernet > connection and DHCP... This id very reliable. I can usually disconnect > the laptop from the Ethernet cable and bring it into the livingroom > for various offline use. Then when I bring it back to my desk, all I > usually have to to is plug the Ethernet cable back in and wait a few > seconds and the Internet will start to work again. > > BUT that is contingent on the Ethernet cable having been connected > during boot up. So if for example I were to boot up my laptop in the > livingroom where there isn't an Ethernet connection the boot process > will delay at the point where it's screen message says its starting > the network. Then it says it failed and continues setting everything > else up. > > At this point, if I bring the laptop back to the desk, and plug in the > Ethernet cable, it doesn't automatically connect. I tried: > > # ifconfig eth0 up > > but ping still doesn't find my ISP > > What am I missing Your dhcp process didn't start either, so you need to start one of those. Something as simple as `dhcpcd -i eth0` might work. -Dan
Re: [arch-general] [arch-dev-public] kernel 2.6.34-1
On Mon, May 17, 2010 at 2:10 PM, Andreas Radke wrote: > Am Mon, 17 May 2010 08:23:15 -0600 > schrieb Ignacio Galmarino : > >> ATI KMS is not working. All i get is garbage on the screen. >> >> x86_64 >> >> Ignacio >> > > Works for me. Probably as useful as your report... Working fine for me too: $ lspci | grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850]
Re: [arch-general] final final testing images
On Sun, May 16, 2010 at 10:17 AM, Dieter Plaetinck wrote: > Okay guys, > > props to Thomas for finding out the problem with the initialization of > wireless cards. > > I built new images, dated 2010.05.16 (aka "final final images" ;)) in > which this should be fixed, and which also come with updated core > packages, most notably kernel26-2.6.33.4-1 > > http://build.archlinux.org/isos/ > > thanks to everyone who tested the 2010.05.13 (or earlier) images. > i received confirmation for 4 images with which a boot+installation went fine. > for netinstall-dual.iso I only reiceved confirmation that it boots fine > (but that's enough, given the other tested images). > However i got no feedback for the core-x86_64 image. > > So right now, these two things are needed: > * confirmation that archlinux-2010.05.16-core-x86_64.iso boots fine. > * confirmation that wireless cards are properly initialised now. > > cheers, and stay tuned for a release soonish :) Thanks for pulling this all together, this stuff is looking good. -Dan
Re: [arch-general] What is Arch doing vis-a-vis MySQL v. MariaDB?
On Tue, May 4, 2010 at 8:50 AM, David C. Rankin wrote: > Guys, > > Ran into a shock this morning when on one of my 2 lingering suse boxes > updates > replaced MySQL with MariaDB. After a brief bit of research, it seems that > Monte > (one of the MySQL devs) forked mysql into mariadb from the mysql code base in > the 12/2009 timeframe when Oracle bought Sun to preserve MySQL and prevent > against any funny business by Oracle in the future. According to statements > made > by Oracle, it is under an obligation to the EU to continue mysql largely in > its > present form and continue to enhance and make it freel available as part of > the > purchase. (See Oracle Statement): > > http://www.oracle.com/us/corporate/press/042364 > > Suse evidently went with MariaDB and it was somewhat disconcerting to > learn > about the switch during an update. Has Arch considered what it will do in this > situation, MariaDB?, MySQL? Definitely wouldn't do this around here without: 1. A big news item 2. Discussion first on the arch-dev-public ML Nor would we do this unless something really crazy changed in the MySQL situation, which for now it doesn't appear is the case. The most likely scenario would be packaging both and giving the users the option of which one to go with. -Dan
Re: [arch-general] [arch-dev-public] [signoff] kernel26 2.6.33.3-2 (and aufs2)
On Sun, May 2, 2010 at 11:02 AM, Roman Kyrylych wrote: > On Sun, May 2, 2010 at 18:49, Pierre Schmitz wrote: >> This new kernel just exports some additional symbols for aufs2 which was >> updated to a new snapshot. This should hopefully fix some issues with the >> .33 kernel and aufs. Related aufs packages are: aufs2 2.6.33_20100425-2 and >> aufs2-util 20100422-1 >> >> In addition to regular sign-off some feedback about aufs would be nice; >> especially if you use archiso. > > Regular x86_64 signoff. Signoff for both i686 and x86_64. Nothing special here involving aufs2 though. -Dan
Re: [arch-general] Package signing
On Thu, Apr 29, 2010 at 10:40 AM, Allan McRae wrote: > On 30/04/10 01:29, Thomas Bächler wrote: >> >> Am 29.04.2010 00:36, schrieb Linas: >>> >>> Thomas Bächler wrote: We must have a system that allows pacman to automatically verify new developer keys and revoke old ones ... even more important, revoke them in a way that signatures made before a certain date are still accepted, but newer ones aren't. I don't see this easily being implemented with PGP-Keys, but maybe someone else knows more. >>> >>> You can't trust a package made with a compromised key just because it >>> looks old. That can be falsified. >>> Packages not affected should be resigned by another developer / the new >>> developers key. >>> I would still recompile them, though (withouth necessarily increasing >>> the pkgrel). >> >> You are right, if the key has been compromised, you can easily include a >> fake date. So upon revoking a key, all packages have to be re-signed. >> >> This shows again that this is not a topic you can just solve by throwing >> some code at people. It needs a proper chain of trust and concepts to >> cover all cases - otherwise, it might be possible to compromise the >> system, giving users a false sense of security. > > Has anyone had a good look at the other implementations of package signing > (Debian, Fedora, ...) and made a summary of how they handle it? This is also a resource worth consulting: http://www.cs.arizona.edu/stork/packagemanagersecurity/ -Dan
Re: [arch-general] [arch-dev-public] [signoff] ifenslave-1.1.0-5
On Sat, Apr 24, 2010 at 7:14 PM, Allan McRae wrote: > On 19/04/10 16:50, Allan McRae wrote: >> >> Last rebuild in 2008 and upstream recommends building against current >> kernel... >> Fixed include path >> >> Signoff both, >> Allan > > Anyone? User signoffs are good. Signoff both.
Re: [arch-general] [arch-dev-public] [signoff] gcc-4.5 toolchain rebuild
On Sat, Apr 17, 2010 at 4:00 AM, Xavier Chantry wrote: > On Sat, Apr 17, 2010 at 3:48 AM, Emmanuel Benisty wrote: >> Thanks for your reply Allan. >> >> On Sat, Apr 17, 2010 at 5:30 AM, Allan McRae wrote: >>> On 17/04/10 00:03, Emmanuel Benisty wrote: Just out of curiosity, what is the plan regarding this issue (quoted from the gcc changelog): On x86 targets, code containing floating-point calculations may run significantly slower when compiled with GCC 4.5 in strict C99 conformance mode than they did with earlier GCC versions. This is due to stricter standard conformance of the compiler and can be avoided by using the option -fexcess-precision=fast; >>> >>> From what I understand, this requires passing -std=c99 (or equivalent) to >>> the compiler for it to use strict C99 mode. So most software will not be >>> affected. Of course, the maintainer of any software the does set C99 mode >>> should consider this. >> >> If it does affect only that type of code and if you recommend the >> maintainers to use this option in those cases then wouldn't it simpler >> to add it to /etc/makepkg.conf by default and thus make it a >> no-brainer for maintainers? >> > > What's wrong with stricter standard conformance ? That sounds like a > good change. > How can you tell that these apps with floating-point calculations were > not actually buggy with previous versions of gcc (or with > -fexcess-precision=fast now) ? > > It does not seem a very good idea to set that globally. I think that > should be done case per case, and not by maintainers, but by the > developers of the apps, who know well their code, and can make a > reasonable decision whether they want/need performance or > conformance/accuracy. > And you *need* to know how these two aspects are affected if you want > to make a reasoned and informed change, rather than a blind and > clueless one. You would be hard-pressed to find a program that uses C99 as default. If they do, they probably do it for good reason and the burden would not even be on the Arch maintainer but upstream to figure out why that choice was made. -Dan
Re: [arch-general] package search shows duplicate ca-certificates package in [testing]
On Fri, Apr 16, 2010 at 8:06 PM, Ray Kohler wrote: > On Fri, Apr 16, 2010 at 8:42 PM, Dan McGee wrote: >> On Fri, Apr 16, 2010 at 7:03 PM, Ray Kohler wrote: >>> Ever since the openssl rebuilds moved out of testing, the package >>> search webapp shows an extra copy of ca-certificates in [testing] at >>> the same version of the one in [core] now. This package doesn't really >>> exist in the [testing] DB and there isn't an SVN entry for it in >>> testing-any either. What's going on here? Is it a bug in the package >>> search that I should file in flyspray? >> >> You found a rather interesting bug- because this was the last arch=any >> package in [testing], we don't run the update loop and thus never >> remove the package from the repository in the web interface. > > Ok, I opened http://bugs.archlinux.org/19131 so this won't get lost. Already fixed so you made more work for me. :) http://projects.archlinux.org/archweb.git/commit/?id=8ec2e404514770cce407a34b8149097d51192a40 -Dan
Re: [arch-general] package search shows duplicate ca-certificates package in [testing]
On Fri, Apr 16, 2010 at 7:03 PM, Ray Kohler wrote: > Ever since the openssl rebuilds moved out of testing, the package > search webapp shows an extra copy of ca-certificates in [testing] at > the same version of the one in [core] now. This package doesn't really > exist in the [testing] DB and there isn't an SVN entry for it in > testing-any either. What's going on here? Is it a bug in the package > search that I should file in flyspray? You found a rather interesting bug- because this was the last arch=any package in [testing], we don't run the update loop and thus never remove the package from the repository in the web interface. -Dan
Re: [arch-general] [signoff] util-linux-ng-2.17.2-1
On Mon, Apr 12, 2010 at 12:55 PM, Tobias Powalowski wrote: > Hi > Util-linux-ng 2.17.2 Release Notes Signoff i686
Re: [arch-general] [arch-dev-public] WARNING: [testing] broken due to openssl and heimdal rebuilds
On Wed, Apr 7, 2010 at 10:16 AM, Allan McRae wrote:
> On 08/04/10 00:54, Florian Pritz wrote:
>>
>> On 07.04.2010 16:10, Allan McRae wrote:
>>>
>>> This would really not help here. Pacman does not directly link openssl,
>>> but does through libarchive and libfetch. Adding versioned libarchive
>>> and libfetch to pacman's deps and using sodeps on openssl in those
>>> packages would prevent pacman's SyncFirst from working.
>>>
>>
>> Don't add depends=(libfetch.sp libarchive.so) to the pacman PKGBUILD and
>> it won't be a problem. (Also see #2 below)
>
> Adding those or not is the same as adding versioned deps or not. Both cause
> bad issues.
>
>>> no versioned deps in pacman for lib{archive,fetch} = bad as between the
>>> openssl and lib{archive,fetch} updates vercmp is broken and so is
>>> install files.
>>
>> sodeps would ensure that pacman updates libfetch and libarchive directly
>> after openssl.
>
> Not directly after, but in the same transaction. That is the same as the
> current issue we have. Using sodeps is no improvement over versioned deps
> here.
Allan and I talked a bit on IRC and we both came to some idea that a
vercmp without any deps would probably be a good solution. We can hack
this up for now, file attached to do so.
If this goes into the pacman package dir in SVN and we just add a "gcc
-O2 -o vercmp vercmp.c" in there and put it in the right place, we can
avoid a lot of hassle with everything here.
-Dan
Re: [arch-general] Sign-offs for community-testing?
2010/4/3 Ng Oon-Ee : > Hi all, > > I noticed a new pulseaudio in [community-testing], do request for > sign-offs for that come to [arch-dev-public] as well? Or the AUR ML > (which I'm not on)? Neither. 1. If signoffs are requested, a developer will always start a [signoff] thread 2. Packages in non-core repos typically don't need signoffs unless there is a compelling reason 3. [testing] is used for rebuilds in addition to new [core] packages; all these packages are in testing due to the openssl rebuild
Re: [arch-general] rankmirrors with arch-games
On Thu, Mar 25, 2010 at 11:13 AM, Daenyth Blank wrote: > On Sat, Mar 20, 2010 at 15:18, Daenyth Blank wrote: >> On Sat, Mar 20, 2010 at 14:20, Dan McGee wrote: >>> I'm not super thrilled about this regression. Either way, I think we >>> should probably add an option to the scripts to use a designated file >>> as the target for rankmirrors testing; this way you could specify a DB >>> filename or any other file as the target to test against. >>> >>> -Dan >>> >> >> I have something along those lines; sending it out shortly >> > > For some reason I can't get git send-email to work through gmail while > keeping my +Arch intact, so mailman keeps dropping my patch emails > since it's sent as daenyth@ rather than daenyth+arch@ (my subscribed > name). > > Could a list moderator put those through? I haven't seen anything come in telling me about emails in the moderation queue; I don't think we keep those around. The only thing I get in a queue that I can release is emails > 40 KB. -Dan
Re: [arch-general] rankmirrors with arch-games
On Thu, Mar 18, 2010 at 9:42 PM, Daenyth Blank wrote: > For some reason rankmirrors seems to really hate the arch-games > mirrorlist. I don't know whether it's a bug or whether there's some > sort of server misconfiguration. > > [r...@muspelheimr pacman.d]# rankmirrors -t archgames-mirrorlist > Querying servers, this may take some time... > * * * * > Servers sorted by time (seconds): > http://pseudoform.org/arch-games/games/i686 #(Nürnberg, Germany. > Maintainer: svenstaro) : 1.01 > http://repo.exigen.org/arch/games/i686 #(Düsseldorf, Germany. > Maintainer: s4msung) : unreachable > http://repo.archlinux-gaming.org/i686 #(Toronto, Canada. Primary > mirror) : unreachable > ftp://mirror.selfnet.de/arch-games/i686 #(Stuttgart, Germany. > Maintainer: hrist) : unreachable > > All of the above servers respond to ping and their repos can be > browsed manually and synced with using pacman. So let's compare a "normal" mirror location with those from arch-games and what we know works. normal: ftp://ftp.archlinux.org/core/os/i686 works: http://pseudoform.org/arch-games/games/i686 not work: http://repo.exigen.org/arch/games/i686 rankmirrors assumes the repository name is the third component from the end; the normal URL would thus produce "core" and look for "core.db.tar.gz" and the working arch-games URL would see "arch-games" and look for "arch-games.db.tar.gz". The non-working URLs thus are guessing the db name incorrectly; the one I listed above would look for "arch.db.tar.gz" and fail to find it, thus the unreachable in the output. I cross-posted this to pacman-dev, but we have a bit of a oddity here as the rankmirrors python script was recently replaced by a bash version, and it does an absolutely abominable job on this mirrorlist due to the inline comments: $ rankmirrors test-mirrorlist # Server list generated by rankmirrors on 2010-03-20 # # Arch Games repository mirrorlist # url `' is malformed. I'm not super thrilled about this regression. Either way, I think we should probably add an option to the scripts to use a designated file as the target for rankmirrors testing; this way you could specify a DB filename or any other file as the target to test against. -Dan
Re: [arch-general] rankmirrors with arch-games
On Fri, Mar 19, 2010 at 7:14 AM, Daenyth Blank wrote: > On Fri, Mar 19, 2010 at 00:38, Nilesh Govindarajan wrote: >> Observe the ping using ping -c 100. >> >> If there is some loss in packets, you need to consult your ISP unless you're >> using wireless transmission. > 0% packet loss, and it's not just me, it's everyone who uses > rankmirrors on our mirrorlist, and it's always the same results. Where is the mirrorlist so I can try this? What version of rankmirrors are you using? You left out quite a few helpful details that might lead to people helping out that don't have time to try and track all these things down on their own. -Dan
Re: [arch-general] Bad attitude in flyspray again!
On Fri, Mar 12, 2010 at 2:59 PM, Damjan Georgievski wrote: >> Commenting on closed bugs is not doable in Flyspray. > > Actually it is doable, it's a configuration option per project. > Check http://bugs.archlinux.org/pm/proj1/prefs > >> More-over, I think it is a bad idea. The only reason people want >> commenting on closed bugs is so that they can argue with the >> developers > > assuming malicious users up-front? > >> - give reasons why the bug shouldn't be closed. That's what >> a reopen request is for. If that fails, then it's time to discuss it >> directly with the developer in question > > I see at least several good uses of allowing comments on closed bugs, > sometimes even adding aditional reasons why the bug needs to *stay > closed*. Thanks. I just turned this on for the pacman bug tracker because I do find comments after closing a feature that is a net positive (with some trolling drawbacks, of course). -Dan
