Re: [arch-general] [arch-dev-public] [signoff] b43-fwcutter-013-1
Am Freitag 30 April 2010 schrieb Tobias Powalowski: Hi bumped to latest version, please signoff both arches. greetings tpowa anyone? -- Tobias Powalowski Archlinux Developer Package Maintainer (tpowa) http://www.archlinux.org tp...@archlinux.org signature.asc Description: This is a digitally signed message part.
[arch-general] iso's
why is it the new iso's never made the download page? -- Caleb Cushing http://xenoterracide.blogspot.com
Re: [arch-general] iso's
On 02/05/10 20:33, Caleb Cushing wrote: why is it the new iso's never made the download page? Because they were testing builds and never released... Allan
Re: [arch-general] iso's
On 02.05.2010 12:37, Allan McRae wrote: On 02/05/10 20:33, Caleb Cushing wrote: why is it the new iso's never made the download page? Because they were testing builds and never released... Allan Come to think of it, releasing a new set of official isos in a short while probably couldn't hurt. What's the holdup? The archiso config works brilliantly for me under all tested circumstances and iso feedback on the forums has been good too. -- Sven-Hendrik
[arch-general] Firefox graphics licensed under MPL
Hi archers, If you believe the comment on Mozilla's bugtracker [1] and the change to the license file [2], the previously non-free Firefox graphics are now licensed under the MPL. Does that mean that we'll be able to have official logo in the supported Firefox package? [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=541761#c3 [2]: http://hg.mozilla.org/mozilla-central/rev/99d80bc3f18b Denis.
Re: [arch-general] iso's
On Sun, 02 May 2010 12:55:19 +0200 Sven-Hendrik Haase s...@lutzhaase.com wrote: On 02.05.2010 12:37, Allan McRae wrote: On 02/05/10 20:33, Caleb Cushing wrote: why is it the new iso's never made the download page? Because they were testing builds and never released... Allan Come to think of it, releasing a new set of official isos in a short while probably couldn't hurt. What's the holdup? The archiso config works brilliantly for me under all tested circumstances and iso feedback on the forums has been good too. -- Sven-Hendrik i will build new iso's once i have the new kernel, aufs and initscripts packages available (and not in testing). once those images are properly tested, i can relabel them to become official releases.
Re: [arch-general] [arch-dev-public] [signoff] b43-fwcutter-013-1
On Sun, May 2, 2010 at 10:05, Tobias Powalowski t.p...@gmx.de wrote: Am Freitag 30 April 2010 schrieb Tobias Powalowski: Hi bumped to latest version, please signoff both arches. anyone? Signoff x86_64. Tested with firmware version 4.178.10.4. P.S.: I'm going to sell my laptop, so unless another dev has b43 device we should start relying on user signoffs for the package (I assume that the signoff procedure includes checking if the produced firmware files actually work). -- Roman Kyrylych (Роман Кирилич)
Re: [arch-general] Firefox graphics licensed under MPL
On Sun, May 2, 2010 at 7:47 PM, Denis Kobozev d.v.kobo...@gmail.com wrote: Hi archers, If you believe the comment on Mozilla's bugtracker [1] and the change to the license file [2], the previously non-free Firefox graphics are now licensed under the MPL. Does that mean that we'll be able to have official logo in the supported Firefox package? [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=541761#c3 [2]: http://hg.mozilla.org/mozilla-central/rev/99d80bc3f18b And NAME of Firefox too? Denis.
[arch-general] [signoff] kernel26 2.6.33.3-2 (and aufs2)
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. Greetings, Pierre -- Pierre Schmitz, https://users.archlinux.de/~pierre
Re: [arch-general] Firefox graphics licensed under MPL
On Sun, May 2, 2010 at 12:07 PM, Xavier Chantry Mozilla actually contradicts itself on this matter. [...] But just below, the trademark policy then says this : Again, any modification to the Mozilla product, including adding to, modifying in any way, or deleting content from the files included with an installer, file location changes, added code, modification of any source files including additions and deletions, etc., will require our permission if you want to use the Mozilla Marks. If you have any doubt, just ask us at tradema...@mozilla.com. Why not do like we're told then, and send them an email? Arch has such and such package, with such and such modifications. Firefox logo is now under MPL and it looks like we can add it to our package. Can we?. Denis.
Re: [arch-general] Firefox graphics licensed under MPL
On 05/02/2010 08:28 PM, Denis Kobozev wrote: On Sun, May 2, 2010 at 12:07 PM, Xavier Chantry Mozilla actually contradicts itself on this matter. [...] But just below, the trademark policy then says this : Again, any modification to the Mozilla product, including adding to, modifying in any way, or deleting content from the files included with an installer, file location changes, added code, modification of any source files including additions and deletions, etc., will require our permission if you want to use the Mozilla Marks. If you have any doubt, just ask us at tradema...@mozilla.com. Why not do like we're told then, and send them an email? Arch has such and such package, with such and such modifications. Firefox logo is now under MPL and it looks like we can add it to our package. Can we?. Denis. seems that you are not very inform about the lwn article about mozilla and trademark [1]. They don't want us to modifying anything without asking for permission. For us that will never happen because we have shared xulrunner, we use system libs(they don't like that at all). [1] http://lwn.net/SubscriberLink/384828/196108ecd70c38ae/ -- Ionut
[arch-general] BTRFS integration
hello, i maintain an unofficial btrfs initcpio hook in AUR: http://aur.archlinux.org/packages.php?ID=33376 the hook provides rollback support among other (future) features. hook is also required for anyone using a multi-device btrfs setup. i would like to start/be included in discussion involving btrfs integration into AIF, and other aspects of Arch. i think it would be nice for users to be able to have the option to use the new filesystem by default-ish, and have the tools needed to work with it. specifically, it would be really neat to have rollback support in a rolling distro. people would likely be more willing to ride the edge of the testing repo if they knew they could simply reboot and all could be well again when things did break. right now, the rollback feature provided by the hook is volatile, but this is only an implementation detail. what i mean by this is once you rollback, you CANNOT promote the rollback subvolume to be the new active (default) subvolume; you must fix the default subvolume manually and reboot again. anything you do in rollback mode will be lost on the next rollback. this is something i intend to change, but i need some input from other developers. what i propose is to do away with installing the system onto the default subvolume (like a typical installation); system will be installed to it's own subvolume (/root/__active). something like this: . ├── home │ ├── __active │ ├── __rollback │ ├── snap_11-11-_11-11-11 │ └── snap_22-22-_22-22-22 └── root ├── __active ├── __rollback ├── snap_11-11-_11-11-11 └── snap_22-22-_22-22-22 this is the subroot structure; underneath your / [root]. . is the original default subvolume. /root/__active is your primary (default) system. /root/ __rollback is a volatile copy of a /root/snap_XX (you boot into this [__rollback] when you rollback). since snap_XX gets copied to __rollback... if you decide you want to ditch your changes to __active (since it's messed up anyways), you just replace __active with __rollback (delete/rename), reboot, and voilà! your system's __active subvolume works again, and none of your snapshots got messed with. same logic for /home/__active and /home/__rollback (and snap_XX) except you wouldn't have to reboot... maybe we can create login manager ([xkg]dm) hooks to remount your home folder with a rollback on the next logout or something? who knows. we could take a snapshot after install (on the very first boot), called __original or something, then users would always have a copy of their system immediately after installation; they could revert/use/delete that if they wanted to at any time. however, this setup would require mounting the default subvolume somewhere else in order to gain access to the subroot structure, but it would guarantee that you could not destroy your system no matter what you did to your / [root]. any ideas on this? my attempts to generate interest in the forums are falling on deaf ears so i thought i'd try my luck here. thanks, C Anthony
Re: [arch-general] BTRFS integration
On 05/03/2010 12:13 AM, C Anthony Risinger wrote: hello, i maintain an unofficial btrfs initcpio hook in AUR: http://aur.archlinux.org/packages.php?ID=33376 BTRFS is not marked stable by the developers yet, its dangerous to include it in the interest of arch newbies. A disk crash may spoil the impression of Arch. In my opinion, we should wait some more time till the developers of BTRFS release a stable version to include it into AIF. -- Nilesh Govindarajan Site Server Administrator www.itech7.com मेरा भारत महान ! मम भारत: महत्तम भवतु !
Re: [arch-general] BTRFS integration
On 05/03/2010 12:40 AM, Nilesh Govindarajan wrote: BTRFS is not marked stable by the developers yet, its dangerous to include it in the interest of arch newbies. A disk crash may spoil the impression of Arch. In my opinion, we should wait some more time till the developers of BTRFS release a stable version to include it into AIF. +1 Till Ext4 would fill the gaps -- Regards, Gaurish Sharma www.gaurishsharma.com
Re: [arch-general] BTRFS integration
On Sun, May 2, 2010 at 2:19 PM, Gaurish Sharma cont...@gaurishsharma.com wrote: On 05/03/2010 12:40 AM, Nilesh Govindarajan wrote: BTRFS is not marked stable by the developers yet, its dangerous to include it in the interest of arch newbies. A disk crash may spoil the impression of Arch. In my opinion, we should wait some more time till the developers of BTRFS release a stable version to include it into AIF. +1 Till Ext4 would fill the gaps i agree it probably should not be visible by default (one suggested option was a flag to AIF, like aif --expert), but the tools (hooks/etc.) need to be developed and stabilized too. there are many users who want to try BTRFS regardless of the risks, and i think we should let them test other integration points along with it. what good is a stable FS if the tools to use it are alpha and buggy for 1 year afterward? that leaves a worse impression than letting advanced users, aware of the risks, use the tools and provide feedback. in my opinion we need to let AIF/etc. integration mature along with the FS itself. this way when BTRFS is marked stable the tools will be ready as well and it will be a minor transition. personally, i've been using btrfs for almost a year without issue, and i see much positive feedback from others around the net as well. my main issue is that btrfs is advanced and we have much to think about the way we want to include it. rollback support and friends are very cool (this just saved me the other day actually) and i think would provide a great benefit to the arch rolling model. additionally, ext4 developer (Tso) has been quoted as saying ext4 is little more than a bridge to BTRFS. in my opinion ext4 is of no interest. C Anthony
Re: [arch-general] BTRFS integration
my main issue is that btrfs is advanced and we have much to think about the way we want to include it. rollback support and friends are very cool (this just saved me the other day actually) and i think would provide a great benefit to the arch rolling model. additionally its not as simple as other FS's. the subvolume/pooling aspect of btrfs means that if you wanted your /var to be compressed, your /home to be (insert mount options), and your root to be (insert mount options), all RAID10 across 4 devices... you would mkfs.btrfs ONCE, then create individual subvols for each. methinks w/o looking at AIF code that this is rather exotic compared to the partition-per-FS options currently available. i just think it's a good idea to start thinking about and integrating all of this now, as btrfs is evolving rapidly and there is a tremendous amount of community interest in it across all distros. btrfs was merged at .29, declared ready for early adopters in .32, and gaining interesting features + stability all the time. i believe it will be declared stable sooner than some may think. and rollback is super useful, and would be a natural addition to the Arch's rolling model... afiak the Fedora 13 rollback is mostly useless; the hook i have created is more featureful, which makes Arch the only distro truly supporting btrfs rollbacks :-) (not OOTB however...) C Anthony
Re: [arch-general] BTRFS integration
On 05/02/10 15:27, C Anthony Risinger wrote: rollback support and friends are very cool (this just saved me the other day actually) and i think would provide a great benefit to the arch rolling model. it could save one from pacman running out of disk space when installing something (which presently leads to unpredictable behavior that might necessitate a re-install). On the other hand, by keeping the older snapshot files (which take space), it's more likely that you do run into out-of-disk when you upgrade something in a way that's protected by a snapshot, and you have a different sort of problem to deal with then... -Isaac
Re: [arch-general] Firefox graphics licensed under MPL
At Sonntag, 2. Mai 2010 19:31 Ionut Biru wrote: They don't want us to modifying anything without asking for permission. For us that will never happen because we have shared xulrunner, we use system libs(they don't like that at all). opensuse has enable-official-branding in their specfile and use system libs with a shared xulrunner too. So from my view you can ask them but i'm not an expert of it because i use my own package (kde integration). Perhaps this is more a problem for Debian than for archlinux. See you, Attila
