headers
Gunnar Thielebein | 4 Feb 2010 12:53
Picon

Re: 1.2.2 release in the near future

Hi Phil,

that are great news. I have just put my scripts for Debian/Ubuntu in the
branches dir.
Regarding changes of the new version:
What I would have a need for in my monitoring script is an option to filter out
dirs which are in version control and get a mtime update due to temporarily
created files (Thats what vi makes by default). We discussed that already last
year on mailinglist.

Is it possible to use an option like -ofilter=mtime-dir so only adapting the
existing mtime filter. Do you think this is easy possible to do or do you see
another way to do that?

Regarding the changelog:

> - Fixed config_dir, so that using other authentication paths work.
>   Previously $CONF/auth was fixed; better default.

Is it now possible to use the home folder to store the svn credentials?

> Don't do the "_base" symlink; it breaks eg. "grep -r /etc". Write an
>   readme instead.

Thats so cool! This is a solution for
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/304449

Cheers,
Gunnar
(Continue reading)

Permalink | Reply | 14 comments |
headers
P.Marek | 4 Feb 2010 14:37
Picon

Re: 1.2.2 release in the near future

Hello Gunnar!

> that are great news. I have just put my scripts for Debian/Ubuntu in the
> branches dir.
Yes, I saw that. Thank you!

> Regarding changes of the new version:
> What I would have a need for in my monitoring script is an option to filter out
> dirs which are in version control and get a mtime update due to temporarily
> created files (Thats what vi makes by default). We discussed that already last
> year on mailinglist.
>
> Is it possible to use an option like -ofilter=mtime-dir so only adapting the
> existing mtime filter. Do you think this is easy possible to do or do you see
> another way to do that?
Well, I believe that this should be an entirely new config option; the filter options
are convoluted enough.

Maybe "dir-no-mtime-only" or something like that?

>> - Fixed config_dir, so that using other authentication paths work.
>>   Previously $CONF/auth was fixed; better default.
> Is it now possible to use the home folder to store the svn credentials?
Yes, it should now.

>> Don't do the "_base" symlink; it breaks eg. "grep -r /etc". Write an
>>   readme instead.
>
> Thats so cool! This is a solution for
> https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/304449
(Continue reading)

Permalink | Reply | 13 comments |
headers
P.Marek | 4 Feb 2010 15:27
Picon

Re: 1.2.2 release in the near future

Hello Gunnar!

I had another idea some days ago, and it came back to me now that you've committed that.

How about using the package names directly, instead of parsing the logfile?

I'd suggest changing the apt configuration, but not to call something *after* dpkg, but
*instead*:
   # apt-config dump | grep dpkg
   ...
   Dir::Bin::dpkg "/usr/bin/dpkg";

Just call some shell script that commits /etc before and after the _real_ dpkg run!
It could check whether the parent is apt, so that normal commandline use wouldn't incur
the overhead.

This would allow to directly use the package names that are given to dpkg; so a "apt-get
dist-upgrade" would be split into several commits, one per dpkg run.

How about that?

Regards,

Phil

--

-- 
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!

------------------------------------------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gunnar Thielebein | 4 Feb 2010 17:14
Picon

Re: 1.2.2 release in the near future

Hi Phil,

The idea sounds great.
I tested it and I can get all parameters that are neccessary in my script.
Parsing parameters looks more clean to me than the logfile.

So for simple operations this would be a good replacement!

*But* If i am performing updates or also dist upgrades on my servers I would
like to keep apt-actions as one big transaction (and checkin) instead of
seperate dpkg ones.

The reason behind is if something went wrong during an system-update I can
investigate (via trac timeline and source browser) in exactly one changeset and
see what files were changed. Also if no config changes appear for the specific
package I can at least see an entry of the apt-action in my changelog, which is
also without configuration changes, very informational. Otherwise I need to
handle that via an empty commit, which I personally would like to avoid.
Also I see revision number raising very fast especially when performing updates
on more than one machine.

What I could do is building something like a queue via the dpkg replacement and
perform the checkin via the Postinstall hook. This way I can keep with the
yes/no for the admin, performing the checkin. I need to think about that further...

Cheers,
Gunnar

Philipp Marek wrote:
> Hello Gunnar!
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gunnar Thielebein | 4 Feb 2010 17:33
Picon

Re: 1.2.2 release in the near future

P.Marek wrote:
> Hello Gunnar!
> 
>> that are great news. I have just put my scripts for Debian/Ubuntu in the
>> branches dir.
> Yes, I saw that. Thank you!
> 
>> Regarding changes of the new version:
>> What I would have a need for in my monitoring script is an option to filter out
>> dirs which are in version control and get a mtime update due to temporarily
>> created files (Thats what vi makes by default). We discussed that already last
>> year on mailinglist.
>>
>> Is it possible to use an option like -ofilter=mtime-dir so only adapting the
>> existing mtime filter. Do you think this is easy possible to do or do you see
>> another way to do that?
> Well, I believe that this should be an entirely new config option; the filter options
> are convoluted enough.
> 
> Maybe "dir-no-mtime-only" or something like that?

So you think of a seperate option?
For a filter option I see it easier to be done because the code for filtering
mtime already exist and only needs to be extended by checking for the type of
the fs object.

> 
>>> - Fixed config_dir, so that using other authentication paths work.
>>>   Previously $CONF/auth was fixed; better default.
>> Is it now possible to use the home folder to store the svn credentials?
(Continue reading)

Permalink | Reply | 9 comments |
headers
P.Marek | 5 Feb 2010 08:34
Picon

dpkg/dist-upgrade versioning

Hello Gunnar!

> The idea sounds great.
> I tested it and I can get all parameters that are neccessary in my script.
> Parsing parameters looks more clean to me than the logfile.
>
> So for simple operations this would be a good replacement!
>
> *But* If i am performing updates or also dist upgrades on my servers I would
> like to keep apt-actions as one big transaction (and checkin) instead of
> seperate dpkg ones.
Hmmm ... I had a few cases where I had a dist-upgrade of several hundred packages and
couldn't really find out *why* some file was changed.
Maybe I didn't look closely enough ... but if the commit would have included only a
dozen packages it would be faster to find.

> The reason behind is if something went wrong during an system-update I can
> investigate (via trac timeline and source browser) in exactly one changeset and
> see what files were changed. Also if no config changes appear for the specific
> package I can at least see an entry of the apt-action in my changelog, which is
> also without configuration changes, very informational. Otherwise I need to
> handle that via an empty commit, which I personally would like to avoid.
How about "empty_commit = no" for the individual dpkg runs, and a summarizing commit
that includes the revision number range?

> Also I see revision number raising very fast especially when performing updates
> on more than one machine.
Yes, that's true.
Do you mind the number or the repository filesystem? With BDB it's a non-issue, and even
FSFS understands packing nowadays.
(Continue reading)

Permalink | Reply | 0 comments |
headers
P.Marek | 5 Feb 2010 08:29
Picon

Re: 1.2.2 release in the near future

> P.Marek wrote:
>>> Is it possible to use an option like -ofilter=mtime-dir so only adapting the
>>> existing mtime filter. Do you think this is easy possible to do or do you see
>>> another way to do that?
>> Well, I believe that this should be an entirely new config option; the filter options
>> are convoluted enough.
>>
>> Maybe "dir-no-mtime-only" or something like that?
>
> So you think of a seperate option?
> For a filter option I see it easier to be done because the code for filtering
> mtime already exist and only needs to be extended by checking for the type of
> the fs object.
Yes, but the logic for "-v" would get even harder to understand.
So yes, you're in the right place for checking, but I'd simply use a new option.

>> Do you want to do the dir-no-mtime-only option? Better name welcome.
>
> I can try but would first try with the existing code for mtime in filter, I am a
> lazy guy :-)
Would it make sense to wait with the release, ie. do you think you can make it in the
next two weeks?

> Other suggestion would be dir-exclude-mtime, exclude-dir-mtime-changes (perhaps
> open the naming for further exclude options that may follow)...
The first one seems better to me.

Regards,

Phil
(Continue reading)

Permalink | Reply | 8 comments |
headers
Gunnar Thielebein | 10 Feb 2010 19:14
Picon

Re: 1.2.2 release in the near future

Hi Phil,

> The first one seems better to me.

I use dir_exclude_mtime for now, ok?

When putting the option definition in options.c, options.h and options.dox it
builds but it don't accept the option.

> Option name 'dir_exclude_mtime=no' unknown.

Code in options.c:

> 	[OPT__DIR_EXCLUDE_MTIME] = {
> 		.name="dir_exclude_mtime", .i_val=OPT__NO,
> 		.parse=opt___string2val, .parm=opt___yes_no,
> 	},

What do I miss here?

When I looked over the code it seems to me that I need to add the exclude mtime
code for every part in fsvs where also the filter option applies.

It looks like repeating the filter behaviour again. I only wonder where to start
because I don't find a function to extend with the exclude check. Can you give
me a small hint where to start?

Cheers,
Gunnar
(Continue reading)

Permalink | Reply | 7 comments |
headers
P.Marek | 11 Feb 2010 07:17
Picon

Re: 1.2.2 release in the near future

Hello Gunnar!

>> The first one seems better to me.
>
> I use dir_exclude_mtime for now, ok?
Ok.

> When putting the option definition in options.c, options.h and options.dox it
> builds but it don't accept the option.
Maybe the name is too long?

>> Option name 'dir_exclude_mtime=no' unknown.
>
> Code in options.c:
>
>> 	[OPT__DIR_EXCLUDE_MTIME] = {
>> 		.name="dir_exclude_mtime", .i_val=OPT__NO,
>> 		.parse=opt___string2val, .parm=opt___yes_no,
>> 	},
>
> What do I miss here?
>
> When I looked over the code it seems to me that I need to add the exclude mtime
> code for every part in fsvs where also the filter option applies.
No, it should be enough to add that either to st__action() (to just avoid showing them,
because on commit it might make sense again), or to ac__dispatch() - that should be used
everywhere. (?)

> It looks like repeating the filter behaviour again. I only wonder where to start
> because I don't find a function to extend with the exclude check. Can you give
(Continue reading)

Permalink | Reply | 6 comments |
headers
Gunnar Thielebein | 12 Feb 2010 14:08
Picon

Re: 1.2.2 release in the near future

Hi Phil,

P.Marek wrote:
> Hello Gunnar!
> 
>>> The first one seems better to me.
>> I use dir_exclude_mtime for now, ok?
> Ok.
> 
>> When putting the option definition in options.c, options.h and options.dox it
>> builds but it don't accept the option.
> Maybe the name is too long?

Indeed, its the length of the optionname. Is there any reason for a restriction
of optionname length?

>>
>> When I looked over the code it seems to me that I need to add the exclude mtime
>> code for every part in fsvs where also the filter option applies.

> No, it should be enough to add that either to st__action() (to just avoid showing them,
> because on commit it might make sense again), or to ac__dispatch() - that should be used
> everywhere. (?)
> 
>> It looks like repeating the filter behaviour again. I only wonder where to start
>> because I don't find a function to extend with the exclude check. Can you give
>> me a small hint where to start?
> Do the above hints help?

Yes, that helps a lot. I was wondering if it does make sense to update the mtime
(Continue reading)

Permalink | Reply | 5 comments |

Gmane